#bzr 2008-07-28
<Verterok> hi poolie
 * AfC waves to Verterok
<Verterok> hi AfC :)
<lifeless> jelmer: ping
<jelmer> lifeless: pong
<lifeless> jelmer: re your virtual files things
<lifeless> jelmer: I'm guessing you want to avoid code dup between bzr-git and bzr-svn ?
<lifeless> jelmer: if so, perhaps a good staging place would be bzr-foreignformatsupport or something ?
<jelmer> lifeless: as in a separate plugin you mean?
<lifeless> I'm not against the things you are producing coming into the core bzr, but perhaps for other core devs the overall shape of what you are producing is not visible yet
<lifeless> yes, as in bzr.plugins.foreignformatsupport
<jelmer> ah, in a plugin but shipped with core?
<lifeless> well
<lifeless> I was actually meaning 'keep it completely separate until its more clear'
<jelmer> I'd rather not require a separate plugin to be installed for bzr-svn and bzr-git to work
<lifeless> we have the open bug about shipping > bzr's tree on make dist
<lifeless> hmm, perhaps thats what I should do today
<jelmer> that means an extra plugin to package and it means requiring users to install yet another plugin for either to work
<lifeless> well
<lifeless> you've got a month till 1.7 anyway
<lifeless> so packaging would be premature right now; and I will have a poke at a dist-many thing today
<lifeless> evolution is *still* importing :(
<lifeless> Jc2k: how long did the full evo import take initially ?
<awilkins> jelmer: Has bzr-svn -.4 moved much in the last week ?
<lifeless> poolie: bug 252428 as requested
<ubottu> Launchpad bug 252428 in bzr "stacking must always grab full inventories" [Critical,New] https://launchpad.net/bugs/252428
<jelmer> lifeless: well, even though something may be planned to land rsn it may take far more than that so I'd rather not rely on anything until it's actually there
<lifeless> jelmer: fair enough
<jelmer> lifeless: alternatively, do you think it's a sane goal to allow repositories to not provide the inventories and revisions versionedfiles?
<jelmer> instead allowing functions that provide the unmarshalled objects to be returned
<lifeless> we don't generally want to go up to objects at all
<lifeless> e.g. diff shouldn't need a full Inventory; that doesn't scale
<lifeless> (for inventories I mean) for revisions we have object methods already
<jelmer> sorry, I should've phrased that differently
<lifeless> The stated goal of the versionedfiles attributes is that other objects that *understand* a particular serializer can use them to do direct access
<lifeless> e.g. stacking
<jelmer> I don't mean Inventory objects just python objections in general, e.g. inventory deltas as well
<lifeless> so, I think its completely fine to have None for those attributes as long as you have a unique serializer, and your code knows how to do all the operations that in the generic Repository are implemented in terms of those attributes
<jelmer> at the moment, that would horribly break stacking though
<lifeless> I don't think its desirable, but I will agree that having unoverridablecode require them is a bug
<jelmer> that's why I've got them implemented at the moment
<lifeless> jelmer: stacking will always depend on them
<lifeless> jelmer: at least for the foreseeable future
<lifeless> (the 1.6 format stacking logic depends on the same /representation/ to apply deltas across repositories)
<lifeless> and these attributes are about providing access to representation
<jelmer> that's what my question was though
<lifeless> if/when we get a stacking facility that does not depend on representation (which group-compress is shaping up into fwiw) then we can do the (non-trivial) work to make every single method stacking aware
<jelmer> do you think it's a sane goal to work on allowing stacking on repositories that don't have the same representation?
<lifeless> yes
<jelmer> ok, that's what I was hoping to hear :-)
<jelmer> I may look into that depending on how hard it is, but I probably won't have enough time
<lifeless> I suspect its non trivial
<jelmer> for now I'll just keep copies of my VirtualVersionedFiles classes in both bzr-git and bzr-svn
<lifeless> *every* method that accesses the storage attributes today will need to be taught to stack, and every data-access method needs to fail in such a way that lookups can then be made to the different source
<lifeless> it was hard enough doing it on just the 8 or so methods of VersionedFiles
<jelmer> lifeless: this would only be for revisions and inventories though
<lifeless> k
<jelmer> lifeless: "bzr branch" works in bzr-git now (again?) btw
<jelmer> I haven't been able to figure out why though
<jelmer> it seems just implementing get_revision(), revision_tree() and get_ancestry() on Repository was sufficient
<jelmer> which is quite scary, really
<poolie> lifeless: would it also work to require the first commit of an inventory in the new repository to require a full text?
<poolie> i mean store a full text
<lifeless> poolie: pull(other repo) can introduce deltas
<lifeless> poolie: so I don't think its sufficient, or necessary
<poolie> lifeless: it seems like we need to check the models are compatible every time we add_fallback_repo, do you remember if we do
<lifeless> poolie: yes, we do
<lifeless>         if not self._add_fallback_repository_check(repository):
<lifeless>             raise errors.IncompatibleRepositories(self, repository)
<lifeless> which is
<lifeless>         return InterRepository._same_model(self, repository)
<lifeless> jelmer: I'd really suggest a plugin for the common code rather than having duplication; one extra branch command for early adopters really shouldn't be a show stopper IMNSHO
<lifeless> jelmer: but up to you
<jelmer> lifeless: I'm getting enough bug reports from people not using the right combination of (bzr, bzr-svn, svn) as it is, would rather not make that a 4-tuple
<jelmer> lifeless: also, not looking forward to finding a sponsor for yet another debian package
<lifeless> jelmer: well, you could always roll the code into either bzr or each plugin at release time; but like I say, its your call
<jelmer> lifeless: sounds like more overhead for myself than copying two files over each time I change them
<jelmer> of course, I could always make bzr-git depend on bzr-svn.... :-P
<jelmer> lifeless: any reason why having two copies is a particularly bad idea, other than the fact that code duplication in general is bad?
<lifeless> jelmer: because it makes testing the impact of a change harder for you
<jelmer> poolie: did you see bug 251871?
<ubottu> Launchpad bug 251871 in bzr "assumes source_branch format is the same as result branch format" [High,New] https://launchpad.net/bugs/251871
<lifeless> bye bye firefox, OOM killed
<Odd_Bloke> bOOM headshot.
<lifeless> Odd_Bloke: :)
<lifeless> jelmer: can you make 'bzr branch lp:bzr-svn' DTRT - that is download the current development bzr-svn suitable for use with bzr.dev ?
<jelmer> lifeless: that should already be the case
<lifeless> jelmer: cool
<poolie> jelmer: not yet, looking
<jelmer> lifeless, did you intend to close the bzr-svn task of bug 252259 as invalid as well?
<ubottu> Launchpad bug 252259 in bzr-svn "SystemError: Parent module 'bzrlib.plugins.search' not loaded" [Undecided,New] https://launchpad.net/bugs/252259
<lifeless> jelmer: no, that was my comment 'lets see if launchpad knows what I mean' :)
<lifeless> jelmer: what did my email do to the bug precisely?
<jelmer> lifeless: it marked the bzr-search task as invalid and opened a task for bzr-svn
<jelmer> then the next email seemed to mark the bzr-search task as invalid again
<lifeless> did it mark the bzr-svn task as invalid too ?
<lifeless> (the next mail ? )
<jelmer> no, that's New atm
<jelmer> no, that just marked the bzr-search task as invalid *again*
<lifeless> so I sent one email; and  I wanted it to make the bzr-svn bug invalid and the bzr-svn one new
<lifeless> oh
<lifeless> I sent two emails
<jelmer> lifeless: You may want to rephrase that :-)
<lifeless> EContext
<jelmer> marking the bzr-svn bit as both invalid and new doesn't make sense
<lifeless> righto, I think its probably some nasty import error somewhere
<lifeless> the SystemError smells of svn bindings or something to me
<lifeless> but yeah, I would have like to close the bzr svn bit too
<lifeless> done by hand
<awmcclain> Sorry for the off-topic question, but which channel would I go to with PPA problems? ubuntu-motu?
<jelmer> launchpad I think
<lifeless> #launchpad for PPA specific issues (timeouts, crashes in the facility etc)
<lifeless> #ubuntu-motu if you just want a hand driving PPA's as they have most of the mentors etc
<awmcclain> Gotcha.
<alecwh> ï»¿Where can I read about sending bzr patches over email?
<RAOF> bzr help send?
<mlh> er
<RAOF> Too slow, apparently.
<mlh> yeah, lift your game :-)
<alecwh> ï»¿Where can I read about sending bzr patches over email?
<mlh> ooh here he is again :-)
<mlh> bzr help send
<alecwh> sorry, I accidentally quit. =\
<mlh> happens to the best of us old chap
<spiv> alecwh: also, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#sending-changes
 * mwhudson pushes the new loggerhead theme to trunk!!!
<lifeless> mwhudson: congrats
<lifeless> beuno: you too
<poolie> woo
<poolie> well done
<Peng_> Yay. :)
<spiv> http://www.toolness.com/wp/?p=71 is interesting.  I guess these people would really like bzr's checkout workflow?
<mwhudson> spiv: i wondered whether that was 'ooh, don't really like hg' or 'oooh, don't really get dvcs'
<mwhudson> (sprinting so didn't really have enough spare brain cells to actually read the blog post properly)
<spiv> mwhudson: it's hard to tell from this distance, really.  Especially if the only dvcs they've used is hg...
<poolie> spiv/lifeless: i want to give better messages when repositories are not compatible
<poolie> for stacking or other reasons
<poolie> at the moment you just get told they're not and that's it, so not much help to a user
<poolie> i'm planning to add an alternative api to InterRepository.is_compatible which raises an exception (rather than returning False) if they're not
<poolie> so we get to keep that information
<poolie> any comments?
 * bob2 gives polite 'yay'
<spiv> poolie: I like the sound of that.
<poolie> eg https://bugs.edge.launchpad.net/bzr/+bug/206258
<ubottu> Launchpad bug 206258 in bzr "incompatible repository error messages are unhelpful" [Undecided,Confirmed]
<lifeless> poolie: is_compatible is used for selecting an optimiser
<lifeless> poolie: so having one that raises an exception doesn't feel right to me, I can just see use spewing out 10 different incompatibilities
<lifeless> s/use/us/
<poolie> if you're searching for one where it passes you would not print them
<poolie> and we can keep a method that just says 'did it pass'
<lifeless> I'm talking the failure mode
<poolie> essentially we have at the moment
<poolie> if not foo(): raise Exception(generic)
<poolie> and i want to invert that
<poolie> hm unless there is one method for matching and another for checking?
<lifeless> there are N optimisers
<lifeless> when none match that will give you N exceptions
<lifeless> which one will you show?
<lifeless> I think what you want to achieve is good; I'm all in favour of clearer error messages
<lifeless> Jelmer has a patch that improves the KnitRepository __str__ to make the rich-roots->plain case more understandable
<poolie> hm
<poolie> at the moment i actually want to change _same_model, which while it lives in InterRepository is apparently not multiply-dispatched
<poolie> being a static method on the base class
<lifeless> but a different model doesn't imply an error message
<lifeless> its a very specific combination of models that generates an error
<spiv> Do we need "incompatible_model"?
<lifeless> *everything* is compatible except for "rich-root or subtrees to plain"
<poolie> i don't think that's actually true
<poolie> there are more implementations of it that check requirements with weaves and knits
<lifeless> oh?
<poolie> to answer your earlier question if we are searching for a match and none of them matches
<poolie> no, i don't think it would be useful by default to tell the user of every possible thing we tried and why it failed
<poolie> but i can believe having that information available for debugging might be useful
<poolie> into the log or something
<lifeless> via a -D flag perhaps
<poolie> right
<lifeless> quite seriously though, I don't believe there are any other cases where is_compatible falls all the way back to the default implementation
<lifeless> there are various InterFORMAT ones
<lifeless> there is InterSameData
<lifeless> and InterModel1and2
<poolie> ok
<poolie> i'm going to poke at it a bit more
<lifeless> so the only case I know of is Model2and1 that will fail
<lifeless> *other* fetch failures can occur
<lifeless> but they occur once a selection has been made
<philn> jelmer: ping
<Jc2k> lifeless: sorry i have no idea
<Jc2k> the initial import of all of GNOME ran over a few days, with me stopping and starting as i hit bzr-svn leaks
<Jc2k> and the initial import of SVN was only of trunk, i then used svn-import to "top up" and pull the 2000 branches over
<james_w> http://www.toolness.com/wp/?p=71
<james_w> I'm not posting that as "Bazaar is better than Mercurial", it's s/Mercurial/Bazaar/ as you read and get an idea of how some people dislike DVCS.
<spiv> james_w: yeah, I saw that
<spiv> james_w: although I think bzr's checkout workflow would answer a bunch of the concerns tehre
<james_w> it's odd that he seems to consider a clean merge more dangerous than a clean update
<spiv> james_w: there's room for argument, but it's certainly possible to read the core problem as "I don't want the overhead of tracking/merging lots of branches, but the tool doesn't give me any options other than to make branches"
<james_w> that's true
<luks> I think it's more about that svn allows you to do 'implicit' update
<luks> that is, you can commit even if your tree is out of date
<keithy> hi
<keithy> how do I tell bzr that the current versions I have are the latest, it seems to think that there are conflicts.
<james_w> hi keithy
<james_w> I'm not sure what you mean, could you expand on your question please?
<keithy> I found it bzr resolve --all
<TuniX12> hello
<TuniX12> when making a change in a file got by bzr how to upload only that change?
<james_w> hi TuniX12
<james_w> what do you mean by upload?
<TuniX12> upload that change to bzr branch
<james_w> "bzr push" to an existing branch will push only the difference between that branch and yours, if that's what you mean.
<TuniX12> ah thank i thought it push all files
<james_w> no, it won't, but it will push a bit more than just the diff to the changed file, as it will have to push the revision information as well.
<TuniX12> and sorry for my bad english :p
<james_w> no problem :-)
<davi_> hi, I'm testing 1.6beta3 and I get a error when trying to create a new copy of a branch. The error is AttributeError: 'property' object has no attribute 'initialize' in bzrdir.py, line 1384. Has anyone seen this? is there a fix?
<TuniX12> i get this error bzr: ERROR: Cannot lock LockDir
<TuniX12> Transport operation not possible: http does not support mkdir()
<TuniX12> any solution?
<davi_> ah, found bug report.
<davi_> would be nice to have a beta4
<TuniX12> ping
<luks> these people don't have any patience nowodays...
<beuno> yay!  new theme landed!
<strk> [24601] 2008-07-28 17:56:28.680 INFO: Committing to: sftp:/.....
<strk> Mon Jul 28 18:14:50 CEST 2008
<strk> [==========================================================================================                      ] Uploading data to master branch - Stage 4/6
<strk> 18 minutes and counting, for a few lines of commit
<strk> Bazaar (bzr) 1.5
<beuno> strk, can you take a look in ~/.bzr.log ?
<strk> low bandwidth, all used -- still, is a developer really supposed to suffer this much ? or is it a bad bug ?
<beuno> there should be something in it
<strk> lots of 601.406  SFTP.readv() 13 offsets => 1 coalesced => 1 requests
<strk> 497.074  Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x87a8c6c>, which has 17 pack files, containing 10300 revisions into 4 packs.
<strk> ^^ you're interested in this one most likely
<strk> or :
<strk> 128.259  Using fetch logic to copy between KnitPackRepository('file:///home/strk/src/gnash/bzr-local-repository/.bzr/repository/')(<RepositoryFormatKnitPack1>) and KnitPackRepository('sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/.bzr/repository/')(<RepositoryFormatKnitPack1>)
<beuno> strk, right, it's autopacking
<beuno> it happens every now and then to make things faster
<strk> it's always autopacking
<strk> is there a way to make it happen NEVER ?
<beuno> strk, no, it should only happen once every N commits
<james_w> not currently.
<Peng_> That would be bad for performance.
<beuno> there is a bug open so that bzr will tell you that it's doing that
<strk> well, until I'm back on a good connection and ready to wait x*10 minutes
<strk> performance of what ?
<strk> it's 24 minutes I'm starving on a commit !!
<james_w> hopefully we'll have server-side packing soon, which should be much much quicker.
<Peng_> james_w: That won't help sftp.
<beuno> james_w, although server-side packing probably won't work with sftp
<beuno> :)
<strk> what happens if I comment out the line where N commits is checked ?
<strk> I mean, what happens if autopack is NOT done ? where's the performance hit going to be noticed ?
<strk> or, when
<james_w> strk: without packing performance will degrade over time.
<strk> by performance you mean time a commit takes to complete ?
<Peng_> Performance in general.
<Peng_> That would include committing.
<james_w> some things will scale with the number of packs, without packing this is the same as scaling with the number of commits, with packing it scales log(number of commits)
<strk> can it be worst than it is now ? 30 25 minutes ?
<strk> I'm used to a *few* seconds for similar commits with CVS
<james_w> yeah, it would include committing. Basically anything that needs to access information in the repository.
<strk> it's a very small patch
<strk> and I can thinkg of a few lines of log
<strk> what else am I missing that needs to generate so much traffic ?
<james_w> it is packing locally, which means that it is pulling down all of the repository data and pushing it back up organised slightly differently I believe.
<strk> argh
<strk> crazy
<beuno> strk, yes, it is. It will be fixed
<strk> would a lightweight checkout avoid all of this ?
<james_w> no, I don't think so.
<strk> damnit, it's depressing
<strk> maybe we should setup a cvs commit-hook doing the bzr commit remotely
<beuno> james_w, I think he should be able to run a cron that packs?
<beuno> that may mitigate it a little bit
<strk> done
<strk> 30 minutes
<strk> I'm on low bandwidth
<james_w> yeah, that should help. I assume that the autopack logic looks at the number of packs as well as the number of commits.
<strk> can't do "offline-commit" forever
<strk> hard to collaburate with others if I keep all the commits locally
<strk> was used to do very frequent small commits
<beuno> strk, you could run a cron to execute "bzr pack" on the branches every... week?
<strk> beuno: would it need bandwidth ?
<beuno> that will probably avoid hitting autopacking remotely most of the time
<beuno> strk, not of the cron runs on the server, no
<strk> oh
<strk> that'd be savannah
<strk> well, I've been online way too much now. lifeless: I hope you can take care of this with savannah hackers.
<strk> thanks for your patience
<jam> as an aside, if you ^C during the autopack, the commit still was pushed
<jam> so it still counts as valid
<jam> though it isn't something I would generally recommend.
<james_w> I've got a test problem where calling branch.bzrdir.open_workingtree() seems to either give a different tree to the one that I expect, or doesn't have the changes that were made in the test code.
<james_w> I think it is the latter, as the path in the repr is correct.
<james_w> so I create a tree, make a couple of commits, and then make a call that eventually ends up the code I am testing. That code receives a branch, and I need a wt, so I try and open it, and the tree I am given has no revision history.
<james_w> does this indicate a problem, and that I need to modify the code to provide a working tree directly, as I can never be sure that re-opening the working tree will do the right thing?
<jam> james_w: well, re-opening the WT should give the right answer, unless you are using a MemoryTree
<jam> also, are you sure you are changing the right paths?
<jam> Often, you might have created the branch/tree in a subdir
<jam> but then possibly modified the files in the current dir
<Roumanos> hello,
<Roumanos> if it some is available, i have a question :
<Roumanos> it's possible to push on a server my modified file ( not the revision file .bzr )
<Roumanos> The commande bzr export work but only on local ( sftp not work with export ...)
<Roumanos> Thx
<beuno> Roumanos, you mean the files, but not the revision data?   You can use bzr-upload, which will just upload the working tree
<Roumanos> yes
<beuno> Roumanos, https://launchpad.net/bzr-upload
<Roumanos> Perfect !
<Roumanos> very thx !!!!
<Roumanos> exactly what i research !
<beuno> Roumanos, your welcome
<Roumanos> the download page is empty, not yet available ?
<Roumanos> need to get this by bzr ? :P
<beuno> Roumanos, not as a release. Are you on Ubuntu?
<beuno> yes, you get this through bzr  :)
<beuno> mkdir ~/.bazaar/plugins && bzr co lp:bzr-upload ~/.bazaar/plugins/upload
<beuno> and you're set
<Roumanos> no sorry, gentoo ....
<beuno> that should work on Gentoo just as well
<Roumanos> yes, just need to dl this plugin ....
<beuno> Roumanos, the command above will work in Gentoo
<Roumanos> Yes, it's working great !
<Roumanos> big thanks for this very quick reponse !
<beuno> Roumanos, it's what we do (tm)
<beuno> feel free to file bugs if you need any additional features
<Roumanos> ;-)
<Roumanos> ok, i will look on this plug-in and make a summary later !
<Roumanos> thansks
<aquarius> I'm sure this gets asked a lot (so do please point me at URLs), but what would be the benefits of using bzr rather than svn for keeping my home folder in a VCS? One .bzr folder (rather than one per folder) is good; are there other benefits I don't know about?
<luks> keeping your home folder in a VCS is a bad idea, no matter what VCS you use
<aquarius> luks: really? I'm forever losing things, and having numerous different machines and having to repeat the same configuration changes and installations on all of them is jolly awkward.
<luks> what kind of things are you losing?
<luks> versioning config files is fine, versioning your whole ~ is not (IMO)
<aquarius> random files that I accidentally delete, or that I create on one machine and then don't have on others.
<aquarius> I'm not going to drop my music collection into svn :)
<luks> if you can accidentally delete a file, I don't think you will always add and commit those random files to a VCS
<aquarius> no, I agree. I'll still miss some. Not all, though.
<luks> I don't know, I really don't like this "versioned file system" idea
<luks> or, maybe I'd like it, but not in a VCS intended for source code
<luks> but if you decide to go this way, I don't think you would enjoy using bzr for this (too slow for that kind of working tree)
 * luks waits for people to disagree
 * aquarius nods. That's useful advice, and thanks.
 * Jc2k would disagree
<Jc2k> we are thinking of using bzr instead of git for our versioned file system
<Jc2k> though, to be fair, rewriting the bits of bzr we need in c
<luks> I wonder why people in #svn so often mention a non-existing command 'bzr unversion'
<fullermd> They're just being subversive.
<aquarius> If I've got a bzr copy of a project in Launchpad, and I want to publish the changes I've made so the project team can look at those changes, am I supposed to publish them to my +junk folder on LP or to the project itself in a branch named by me? Bit confused...
<james_w> Odd_Bloke: congratulations. Isn't that your first package in Debian?
<LarstiQ> aquarius: ~aquarius/project/branch-name
<james_w> hey LarstiQ
<LarstiQ> hey james
<aquarius> LarstiQ: ah, excellent.
<aquarius> hrm. Confused, again. I bzr pushed to launchpad (thanks, LarstiQ) and it's created that branch, but it's not clear to me that there's actually code there for people to look at. https://code.launchpad.net/~sil-launchpad/gwibber/system-buttons
<beuno> aquarius, http://bazaar.launchpad.net/~sil-launchpad/gwibber/system-buttons/changes
<beuno> Launchpad takes a while to scan the commit messages
<beuno> but your branch is there
<aquarius> wow! did I miss a link to that page or is it just not there yet?
<beuno> aquarius, it's not there yet, I cheated. It should be on there soon-ish, and there is a bug open to show that link right away
 * aquarius grins
<aquarius> so I was right to be confused :) Your bug: good work there :)
<beuno> aquarius, :)
<abentley> lifeless: ping
<jam> aquarius: at the bottom of https://code.launchpad.net/~sil-launchpad/gwibber/system-buttons
<jam> it does say "This branch has not been scanned yet"
<jam> though I won't say it is very obvious
<thumper> aquarius: there is a LP rollout shortly that should fix the scanner problem
<aquarius> jam, thumper: yeah. I didn't know what "scanned" meant -- it seems to mean "no-one can get at this branch yet", which I don't mind, but having a thing which says "this can take a few hours" might not hurt. (Or, just fix the problem by making scanning happen straight away, if that's possible.)
<jam> well, it is supposed to only take 5 min or so
<jam> I don't know what the hold up is
<thumper> jam: the hold up is a bug which causes a mysql branch to fail after 12 minutes
<thumper> jam: which it tries every time
<jam> thumper: so it is a 12-min timeout, then it gets another branch scanned, repeat ?
<thumper> jam: so it gets everything to scan (which may include multiple mysql branches), then does them one after the other
<thumper> jam: any that fail, get tried the next time around (1m cron)
<thumper> aquarius: scanning takes bzr metadata and stores it in a database
<thumper> aquarius: until the branch is scanned we don't show stuff as we don't know what to show
<aquarius> aha, got it. So the branch might be private in some way or something, so the public can't pull from it until scanning has happened?
<thumper> aquarius: it is pullable / branchable, but the webapp doesn't know that
<aquarius> oh, cool. So people who already know their way around LP will be able to get it, at least?
<thumper> aquarius: yes
<ryanakca> Could someone help me figure out why I can't bzr init? http://paste.ubuntu.com/31484/plain/
<dvheumen> Can anyone tell me how to convert an existing "shared repository with trees" into a "shared repository"?
<jelmer> ryanakca: bug in bzr-svn, which has been fixed in newer versions of bzr-svn
<jelmer> ryanakca: as a workaround, try "bzr --no-plugins init"
<jelmer> dvheumen: You mean into a shared repository without trees?
<dvheumen> jelmer: yes that what I mean... I tried out 'bzr reconfigure' but I don't know how to change it to treeless
<ryanakca> jelmer: splendid, thanks :)
<james_w> dvheumen: would you file a bug about that, I think it should know
<dvheumen> james_w: do you mean as a feature request?
<james_w> yes please
<dvheumen> k, I'll do that, tnx
<james_w> dvheumen: and to do it now you can use "touch .bzr/repository/no-working-trees"
<james_w> "bzr remove-tree" will remove any existing working trees that you don't want.
<dvheumen> james_w: I already found out about that command, that wasn't the problem... it's just that new branches would still have trees
<dvheumen> james_w: should I report the bug as a missing feature for 'bzr reconfigure'?
<dvheumen> or should I just say 'Can't convert repository to treeless repository' (in a few more words)
<james_w> yes please, I've been looking for somewhere to put that function and reconfigure seems like the best place
<james_w> well, if you just report the latter I'll follow up and recommend the former.
<ryanakca> jelmer: untill I get to upgrade, any other workarounds? "bzr --no-plugins init" gives ``bzr: ERROR: No repository present: "file:///home/ryan/work/kubuntu-startpage-mockup/"''
<jelmer> ryanakca: Is there perhaps a .bzr directory in that location already?
<dvheumen> james_w: Isn't this bug report about the same issue? https://bugs.launchpad.net/bzr/+bug/145033
<ubottu> Launchpad bug 145033 in bzr "need a command to switch a repository between trees and no-trees" [Medium,Triaged]
<ryanakca> jelmer: oops, thanks
<dvheumen> okay, so on second thought I won't report :P
<dvheumen> btw, could you explain what 'triaged' means exactly? ('cause I've only got a faint clue at the moment)
<james_w> dvheumen: hey, yes it is, thanks.
<james_w> triaged is supposed to mean "enough information that a developer can start work on it"
<dvheumen> ah right, okay, tnx guys :D
#bzr 2008-07-29
<jelmer> lifeless: ping
<lifeless> jelmer: hi
<jelmer> lifeless: Any chance you can sponsor the initial upload of bzr-upload or bzr-avahi to Debian ?
<jelmer> Jeff has promised to upload bzr-stats
<lifeless> I'll see what I can do; I'll need to review the package yadayadayada
<lifeless> is the bzr-avahi you've packaged comaptible with bzr-dbus ?
<jelmer> afaik yes, but I'll double check
<jelmer> bzr-upload has already been reviewed once and uploaded to NEW but was accidently uploaded without source package
<lifeless> ahaha
<igc> morning
<jelmer> Hi Ian
<abentley> lifeless: ping
<lifeless> pong
<abentley> lifeless: Have you seen my fetch patch?
<lifeless> I didn't get to reading it yesterday; it sounds conceptually straight forward
<lifeless> I'd kind of like to remove all fetching via Packer and instead just use Packer for auto-pack, reconcile, full-pack
<abentley> I am concerned that it may not be enough.
<lifeless> but I don't know that the performance is stable enough through the generic code path yet
<abentley> The packer makes sure that all the compression parents are present.
<lifeless> in autopack ?
<lifeless> (insert_record_stream also checks for compression parents)
<abentley> I'm not sure.  That's what I'm worried about.
<lifeless> I think thats a likely hole. dammit
<lifeless> uhm
<lifeless> I think that the check for existing parents should go through the relevant VersionedFiles attributes' graph object
<lifeless> that would solve it comprehensively
<lifeless> or something ~= to that
<lifeless> I need to pop out for a few minutes
<lifeless> will ping on return
<abentley> lifeless: Yes, though it makes me wonder whether the packer should be doing it at all.
<abentley> lifeless: cool
<lifeless> k
<jelmer> poolie, ping
 * jelmer wonders if he's running into a lot of bugs today or just grumpy..
<jelmer> autoppa doesn't work for me yet; is there perhaps an Ubuntu user who could help upload bzr-svn to ppa?
<lifeless> jelmer: is it really ubuntu vs debian? or something else?
<jelmer> no, it's just several issues in autoppa
<jelmer> several minor things that scared me a bit and one thing that actually prevents me from using it
<jelmer> I think for the time being it's probably best if somebody else (perhaps the same person who uploads bzr to the ppa) can upload bzr-svn to the ppa
<jelmer> This is just not my day..
<jelmer> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<spiv> jelmer: eep!
<jelmer> ah, appears to be back now
<lifeless> poolie: ^
 * igc lunch
<lifeless> thumper: I want - http://bzr-playground.gnome.org/.mirror-log for launchpad.net
<jelmer> lifeless: aol
<poolie> jelmer, pong
<poolie> jelmer, i can do that upload, can you point me at the packaging branch
<jelmer> poolie: Sure, it's at http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/
<poolie> i'm working today on your bug re being unable to branch from bzr-svn
<jelmer> poolie, ah, cool
<poolie> i guess there is no point packaging it into the ppa until that is fixed
<poolie> what else are you hitting?
<poolie> oh, and gmail is down too
<poolie> well, what a productivity boost :)
<jelmer> poolie, Yeah, that doesn't make much sense, indeed
<jelmer> poolie: What bugs am I hitting in autoppa you mean?
<poolie> 11:44  * jelmer wonders if he's running into a lot of bugs today or just grumpy..
<poolie> but i see the context now
<poolie> i wasn't sure if you were referring to bzr or autoppa
<jelmer> I just filed 6 additional bugs on autoppa
<jelmer> and then I hit some open bugs in bzr
<jelmer> (already reported though)
<jelmer> poolie: if there's anything I can do to help with bzr-svn in ppa, please let me know
<poolie> jelmer, for bzr i was just packaging and uploading it by hand
<jelmer> poolie, the packaging branch should build without problems with bzr-builddeb
<poolie> (the method is in doc.b.o)
<poolie> this is very low tech
<jelmer> poolie: I did that for a while, but it's too much overhead for me to also upload to PPA
<jelmer> autoppa seemed like a nice way to deal with the multiple distributions you have to upload to
<lifeless> jam: ping
<jelmer> I did uploads of bzr-stats, bzr-rebase, bzr-gtk and bzr-svn to some distributions on ppa for a short while but that was just too much work
<lifeless> jam: what mail client are you using? (It seems to quote everything everytime)
 * jelmer gets some sleep
<mwhudson> beuno: http://bazaar.launchpad.net/~bzr/bzr/trunk/files :)
<lifeless> nice
<lifeless> bkor: ^
<spiv> mwhudson, beuno: hooray!
<poolie> sweet!
<jelmer> ooh, shiny (-:
<lifeless> spiv: is https://bugs.edge.launchpad.net/bzr/+bug/180996 of interest to you?
<ubottu> Launchpad bug 180996 in bzr "bzr checkout fails with 'No buffer space available'" [Undecided,New]
<spiv> lifeless: yes, thanks
<Peng_> Hmm, that theme is a little different.
<rockstar> spiv, I effing LOVE your latest blog post
<spiv> rockstar: thanks :)
<AfC> spiv: uh, Andrew, something I don't follow from your excellent essay:if you use `bzr merge -r X..Y` you still have the same problem as rebase - new revisions are made, and if someone has branched off of the old revisions they will still be on a different branch that has no relation to the new hotness one.
<AfC> This "discards the real history" if the new branch becomes the published mainline, no?
<spiv> Well, the example where I used -rX..Y, X is present so the revision history would be attached.
<spiv> I could have used -r..Y I guess.
<poolie> jml, thumper, ping?
<jml> poolie: hi
<jml> poolie: what's up?
<poolie> jml, about lp stacking, briefly
<poolie> i wanted to let you know i'm working on the two bugs found in stacking betas, being robert's one about stacking on a branch that is later upgraded
<poolie> and jelmer's about it breaking branching from bzr-svn
<spiv> So in the example I gave things Just Work as they should, but cherrypicking in general is still a problem.
<poolie> how is it on the lp side?
<jml> poolie: pretty good right now.
<RAOF> Just to check; the format for --fixes is --fixes=lp:123456, right?
<jml> poolie: you've seen abentley's patch?
<jml> RAOF: yes.
<jml> RAOF: feel free to poke me into writing better docs at some point
<poolie> also, jml, which one?
<RAOF> jml: Ta.  Maybe I'll file a documentation bug.
<AfC> You say present... but it when you do a cherry pick like that the _revisions_ (if not the text delta) and their history are not present [or is there some magic flag to bzr log|viz I'm missing out on?]
<AfC> spiv: ^
<RAOF> jml: Heh. I'm too slow :)
<jml> poolie: I'll look it up.
<jml> poolie: [MERGE] Fetch into stacked branches works correctly
 * AfC notes that this is the central problem he has been grappling with since the beginning of Bazaar, and the perennial topic of his questions, most recently in the email titled "There And Back Again" to the mailing list.
<AfC> {shrug}
<jml> poolie: without that, default stacking is unusable
<luks> AfC: the example was about grouping a branch into fewer commits, not about cherry picking
<luks> AfC: if you chery pick a revision, and the parent revision is not present in the target branch, the history won't be saved
<AfC> luks: no, I get that, but the example also claimed "without losing your history" and as far as I can tell, X..Y cherrypicking has exactly the same [adverse] properties as rebase does, future-wise.
<luks> AfC: `merge -r X..Y` with X present in the branch is an equivalen of `merge -r ..Y`
<AfC> luks: as a means of submitting patches to another branch [ie, upstream or whatever] then it's all good, no question there
<luks> is that more clear now?
<luks> it's not cherry picking, it's "merging up to revision Y"
<AfC> Ah, I'm accustomed to the X-not-present case.
<AfC> (Andrew did start at revision 0 in his essay, I certainly grant you that)
<luks> but yes, cherry picking and rebasing have the same problems
<luks> (and also similar solutions, that's why bzr-rebase provides `bzr replay`)
<spiv> AfC: I see luks has already clarified things, but you can run the shell script at http://rafb.net/p/34dlJk37.html and then use "bzr viz" on the result if you're still curious :)
<jml> poolie: sorry, I got distracted
<jml> poolie: where were we?
<AfC> spiv: no, I get it. You were starting from 0 which is "X already in branch"
<spiv> Right.
<AfC> spiv: (and I was playing along at home already)
<spiv> Cherry-picking with history would be great to have, for obvious reasons.  But you already know that :)
<AfC> spiv: in view of the fact that we are all actually talking about the same thing, I would really appreciate your thoughts about the two options in that email I sent last week if it strikes your fancy that you have anything to say on the question
<spiv> I'll take another look.
<AfC> most kind
<igc> spiv: thanks for the InventoryEntry review
<igc> spiv: can I confirm you're ok with it landing as is and for me to tweak it later as part of some other work in that area?
<igc> I'm not sure a registry is worth the complexity it adds right now personally
<spiv> igc: I am
<igc> spiv: thanks. I'd liked the feedback btw and I'll incorporate you're thinking when I add some tests in that area soon
<igc> s/you're/your/
<poolie> jml, me too
<poolie> jml, we were going to review blockers to stacking on launchpad
<poolie> i'll read aaron's patch
<poolie> is there anything else aside from that?
<jml> poolie: not that I'm aware of.
<jml> poolie: I'm currently testing my branch locally.
<poolie> which branch is that?
<jml> poolie: my launchpad branch that enables makes use of the in-development bzrlib stacking features.
<poolie> spiv, how is memory usage with bzr+ssh in 1.6b?
<spiv> poolie: not obviously worse than 1.5 IIRC.  I don't know of any big memory issues that are due to HPSS rather just bzrlib in general.
<alecwh> A friend and I are working on a project, and we have a central repository where we both push/pull from. There is one file, /inc/config.py, that contains database info, etc etc. Now, when I push to the repository, it will change the config.py file, so that when my friend pulls, HIS config.py is changed, therefore messing up his database credentials. Is there a way to include config.py in the version control, but stop it from being changed on the 
<poolie> alecwh: not at present, but there is some discussion recently about letting you persistently mask in your working tree what things should be committed or not
<alecwh> Does git have a feature like this?
<poolie> not that i know of
<alecwh> Okay, so for the time being, my friend and I should just try to have identical databases and credentials?
<poolie> alecwh: how about if you put into that file something like this
<poolie> 'from config_local import db_user, db_pass, db_url'
<poolie> and then have a config_local.py that's not versioned
<poolie> or you could for example wrap that in a try/except block
<alecwh> yeah...
<alecwh> poolie: thanks, much appreciated
<poolie> np, hope that helps
<jml> poolie: so, according to abentley and lifeless, it's likely that autopack won't work on stacked branches.
<jml> poolie: I would consider this a blocker for Launchpad.
<abentley> poolie: Thanks for your review, though.
<poolie> heh
<poolie> what will happen when it runs?
<spiv> jml: add "for b in $branches; do bzr pack $b; done" to a nightly cron ;)
<poolie> it won't repack the underlying branch?
<mwhudson> spiv: i knew we could rely on you!
<poolie> mwhudson: it would be really nice as part of the scalability work to run
<spiv> mwhudson: thanks!  I'll be here all week... ("here" == "not in NZ, so you can't hit me")
<poolie> to be able* to run pack/check/upgrade etc
<mwhudson> spiv: jml will be back in punching range sooner or later
<mwhudson> poolie: i'm not sure how that's part of the scalability work, tbh, but yes
<abentley> poolie: It will raise errors.RevisionNotPresent on autopack.
<poolie> i saw it as connected through being part of looking after a large collection of branches,b ut let's not get hung up on it
<poolie> because autopack is trying to repack things in the underlying packs
<berto-> anyone familiar with this error when trying to bzr branch an SVN repo via https:  error: (65, "necessary data rewind wasn't possible")
<berto-> bzr-svn is compiled against subversion 1.4.4
<spiv> berto-: sounds dimly familiar, maybe an interaction with pycurl if you have that installed?
<berto-> spiv: yes, pycurl is installed.
<berto-> spiv: though a standard curl request via HTTPS to a file in the svn repo works fine.
<spiv> berto-: google finds https://bugs.launchpad.net/bzr/+bug/241698 and https://bugs.launchpad.net/bzr/+bug/207734
<ubottu> Launchpad bug 241698 in bzr "POST to authenticating proxy causes "necessary data rewind wasn't possible" error" [Undecided,New]
<spiv> berto-: both when bzr tries to probe for a bzr+http service on an http:// URL when pycurl is installed
<spiv> berto-: possibly using "svn+https://" or "nosmart+https://" might workaround it.  As would uninstalling pycurl :/
<berto-> hmm, can't uninstall pycurl.  i need it for other projects.  i'll try svn+https//
<berto-> promising ...
<spiv> A hack would be to do "mkdir /tmp/disable-pycurl; echo raise ImportError > /tmp/disable-pycurl/pycurl.py" then use "PYTHONPATH=/tmp/disable-pycurl bzr ..."
<spiv> But if svn+https works that would be easier :)
<berto-> spiv: hehe, clever.  but, it looks like svn+https is working.  i've had luck branching svn repos, the question is will i be able to push changes back up.  i'll test that as soon as this is done.
<berto-> looks like i'm going to have to upgrade to svn 1.5 for this to work ...
<alecwh> Are there any notable projects that use bzr exclusively?
<lifeless> jml: autopack not working would be a bug
<lifeless> jml: Its on my short list to look at closely
<berto-> alecwh: http://bazaar-vcs.org/WhoUsesBzr
<lifeless> jml: if we extend the work poolie is already doing to make inventories never delta across a repo boundary autopack is guaranteed to work
<alecwh> berto-: thanks!
<jml> lifeless: cool.
<lifeless> spiv: https://bugs.edge.launchpad.net/bzr/+bug/246880
<ubottu> Launchpad bug 246880 in bzr "reconcile not converting deltas to full texts appropriately" [High,Triaged]
<lifeless> spiv: if you could eyeball that; reconcile bug I think
 * spiv balls it with eyes
<lifeless> poolie: I'm calling it a day; been sneezing and $hit all day - asthma etc are all playing up
<spiv> lifeless: hmm.
<spiv> lifeless: before you go, care to explain this bug a little more for me, to make sure I understand it?
<spiv> lifeless: (feel free to say "no")
<lifeless> spiv: sure
<lifeless> I've put my understanding to date in the topic
<lifeless> bzr reconcile fails to reconcile the branch
<spiv> Yeah, it's a bit hard reassembling the diagnosis from a series of bug comments, it's a bit like a stream-of-consciousness :)
<poolie> lifeless: sure, i hope you feel better soon
<lifeless> spiv: so reconcile fails
<lifeless> its meant to do 'oh thats a delta on a text we would not fetch so make it a full text'
<lifeless> but its not doing that
<lifeless> fetch fails because there is a delta on a text that is not fetched
<spiv> And it has enough info to assemble a full text, somehow?  (I guess so, because iter_file_bytes works)
<lifeless> jml: btw is there a bug open on lp to have a 'remirror from scratch please' ?
<poolie> lifeless: i've just filed bug 252821, is there anything else you can add to it?
<ubottu> Launchpad bug 252821 in bzr "autopack fails with RevisionNotPresent on a stacked repository" [Undecided,New] https://launchpad.net/bugs/252821
<lifeless> spiv: yes, because the text chain (D1 and FT) are present
<lifeless> spiv: but the revision D1 is not present, only the text is
<alecwh> Is there a service for bzr that will notify the freenode channel when a commit has been made? Something like CIA agent?
<alecwh> http://cia.vc
<jml> lifeless: umm, no, I don't think so.
<lifeless> poolie: as I said above the easiest fix is to just always ensure we have the fulltext in the local repo
<jml> lifeless: no one has asked for it yet.
<poolie> oh is it the same bug?
<poolie> as for upgrade
<lifeless> poolie: its the same situation causing it
<lifeless> it seems to me we can save on code by just using whatever fix you do for inventories to control file texts as well
<spiv> Ah, right.  So reconcile is probably being tricked by the lack of a revision, even though there is a text from that revision present (and necessary)?
<jml> lifeless: I'll note that Launchpad actually has pretty awesome search nowadays
<lifeless> jml: herewith a request
<lifeless> jml: concretely I'd like reconcile operations to propogate to the mirror
<lifeless> jml: and potentially other deeper voodoo; but reconcile would do for now
<lifeless> spiv: I think reconcile is being tricked somehow yes
<lifeless> spiv: all I really know is that:
<lifeless> the text (ID, D1) is reported as missing
<lifeless> (ID, D2) is compressed on (ID, D1)
<lifeless> (reported as missing by fetch/reconcile)
<lifeless> (ID, D1) is compressed on (ID, FT)
<lifeless> D1 and FT revisions are not present
<spiv> Right.  Ok, I think I grok the situation.  Thanks!
<lifeless> so reconcile should turn D2 into a FT
<jml> lifeless: so, a workaround is to change the branch format
<lifeless> but its not
<lifeless> and its not copying D1 either (which is correct), but that leaves D2 as unreconstructable after the reconcile which is why it fails. or something like that. DUnno.
<lifeless> jml: yes. ugh.
<mwhudson> >:)
<spiv> lifeless: right.
<jml> lifeless: can you please file a bug report for this?
<astrec> hi all
<jml> g'night all.
<astrec> q'n about bzr-svn: it has built off trunk without complaint, but tells me: Unable to load bzr-svn extensions - did you build it?
<lifeless> ok, gone
<astrec> this is bzr 1.6b3
<astrec> anyone else seen this?
<lifeless> spiv: I've uploaded the tarball if you are interested; I can probably look at it at some point myself too
<lifeless> astrec: you've run make ?
<lifeless> hmmm, really must go - sorry
<astrec> yeah, run make
<astrec> no errors
<berto-> spiv: svn+https:// is finally working; took a few tries and a ton of patience.  after ~10 minutes, it finally started downloading revisions from the svn repo.  50/1188 so far ... :\
<astrec> ok, so i add it to the pythonpath
<berto-> astrec: what platform are you on ?
<berto-> astrec: i just had that error on OS X, ended up building svn from source.
<astrec> sorry, OS X  10.5.4
<berto-> are you using the built-in svn ?
<astrec> i've tried the binary suggested in the doc, and macports. all svn 1.5.1
<berto-> i built from svn source b/c of this: http://samba.org/~jelmer/bzr-svn/FAQ.html#i-am-unable-to-access-a-repository-that-requires-user-password-authentication-or-uses-self-signed-ssl-certificates
<astrec> trying to import the plugin from python yields: http://pastebin.com/m196cc427
<berto-> astrec: you have apr in /opt
<astrec> i do
<berto-> mine linked from apr in /usr/lib and it worked fine.  that seems to be your problem.
<berto-> oh, /opt must be where macports puts svn, eh?
<elmargol> How can I pull a single revision of a branch?
<berto-> astrec: i can help you build from source, that will probably clear things up for you.
<astrec> that would be great!
<spiv> elmargol: do you mean make a branch/checkout without grabbing the whole history, or something else?
<elmargol> spiv, I have found branch containing a fix to my branch. And I need to somehow merge this change in
<berto-> astrec: ok, cool.  for stuff i compile myself i put it in ~/local
<astrec> berto-: same
<berto-> so, you can: mkdir -p ~/local/src
<spiv> elmargol: ah, so you want to merge rather than pull
<berto-> cd ~/local/src
<berto-> svn export http://svn.collab.net/repos/svn/trunk svn
<berto-> astrec: basically follow this, but change the configure line: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=show&redirect=BzrSvn#building-from-source
<spiv> elmargol: "bzr merge -r 123 OTHER_BRANCH" will merge all changes up to r123, or "bzr merge -c 123 OTHER_BRANCH" will just grab the changes from one revision.
<berto-> my configure line goes like this:
<elmargol> spiv, thx
<berto-> ./configure --prefix=${HOME}/local --without-apxs
<spiv> elmargol: if you use -c, you should be aware of http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#pseudo-merging
<berto-> astrec: make-check-swig-py is not necessary anymore as bzr-svn doesn't use swig anymore
<spiv> elmargol: (cherry-picking individual changes rather than full branches doesn't copy the revision history for those changes, so later merges are likely to have spurious conflicts)
<astrec> berto-: lol... i tried compiling it earlier in the day and make-check-swig failed so i gave up
<berto-> astrec: hehe.
<spiv> elmargol: also, "bzr help merge" will give you lots of options :)
<astrec> berto-: compiled. so what did u add to your site-packages?
<berto-> astrec: cd ~/.bazaar/plugins/svn
<berto-> look for the list basedirs; mine is on line 69
<berto-> add '/Users/<username>/local' to the front of that list, replacing <username> with your username, of course.
<astrec> berto-: i've been here before: http://pastebin.com/m5b204f5f
<astrec> i have some strange issue with apr
<berto-> astrec: me too. setup.py line 43, put apr-1-config first.
<astrec> berto-: anything else? i get the same error
<berto-> astrec: run: which apr-1-config
<astrec> "/usr/bin/apr-1-config"
<berto-> astrec: you are getting apr-config not found?
<astrec> berto-: no, it's in /usr/bin
<berto-> as the error.
<berto-> and you changed the cmds line to look like this:         cmds = ["apr-1-config", "apr-config"]
<astrec> no, that's not the error. i did change the cmds. error i get is: ld: library not found for -lapr-1
<berto-> astrec: can you paste the last compile line?
<astrec> gcc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/client.o build/temp.macosx-10.3-i386-2.5/editor.o build/temp.macosx-10.3-i386-2.5/util.o build/temp.macosx-10.3-i386-2.5/ra.o build/temp.macosx-10.3-i386-2.5/wc.o -L/Users/cam/local/lib -lsvn_client-1 -lsvn_subr-1 -o build/lib.macosx-10.3-i386-2.5/bzrlib/plugins/svn/client.so -L/usr/lib -lapr-1
<markh> is bzr likely to use the python 'compiler' package at runtime, or can I safely exclude it from the windows binaries?
<berto-> astrec: you have /usr/lib/libapr-1*.dylib, right?
<astrec> "/usr/lib/libapr-1.0.2.7.dylib	/usr/lib/libapr-1.0.dylib	/usr/lib/libapr-1.dylib"
<berto-> astrec: why are you getting temp.macosx-10.3 ?
<berto-> which python ?
<astrec> berto-: not system. /Library/Frameworks/Python.framework/Versions/Current/bin/python
<berto-> astrec: that's scary.  you're using an old version of python.
<berto-> well, maybe not old, rather not compiled specifically for leopard.
<astrec> yeah, not old: Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53). but not compiled for leopard
<berto-> astrec: try this: /usr/bin/python2.5 setup.py build
<berto-> astrec: i had MacPython on this system and had all sorts of issues.
<berto-> is there a reason you need 2.5.2 vs. system python, which is 2.5.1 ?
<astrec> berto-: only to add a bunch of packages to it
<astrec> berto-: that worked btw.
<berto-> oh, i see, it's from darwin ports or something, huh?
<astrec> no, it's macpython from python.org
<astrec> i think i will use system for bzr
<berto-> hmm, where are the extra packages coming from, then?
<berto-> astrec: yeah, just change the shebang or add an alias.
<astrec> they're part of our app
<berto-> astrec: ok.
<astrec> will do. thanks for your help berto-
<berto-> no problem, enjoy.
<kiorky>  jelmer toward bzr svn i didnt upstream you that : http://rafb.net/p/oKgQ9h69.html which facilitate compilation in non standart envs.
<kiorky> oups
<kiorky> jelmer: http://rafb.net/p/wrinSS26.html
<luks> hm, the new loggerhead theme confuses me
<jamesh> luks: then file bugs
<luks> it's more usability things, than real bugs
<jamesh> luks: then file bugs
<luks> ok :)
<spiv> usability bugs *are* real bugs :)
<spiv> After all, they're often hard to fix, like other real bugs ;)
<fullermd> "I can't figure out how to file a bug."  "File a bug on it."
<luks> ok, I think I'm done for now
<luks> bueno will probably hate me anyway :)
<Odd_Bloke> james_w: Thanks. :)  It is my first package.
<beuno> new theme in LP!
 * beuno dances around
 * markh tries again :)
<markh> is bzr likely to use the python 'compiler' package at runtime, or can I safely exclude it from the windows binaries?
<james_w> markh: hi, it's used by configobj apparently, but IronPython doesn't have it, so it handles the import error. However, there is a feature that requires it, but I don't know if that feature is used by bzr.
<markh> heh
<markh> well, that's good to know, and for the few bytes it would save, I guess it can live :)
<james_w> it appears to allow you to embed a dictionary as a value, I don't bzr makes use of that
<james_w> you could always strip it and see what fails :-)
<markh> I think I'll wait until windows gets down to less than a dozen or so failing tests before I get that brave ;)
<markh> It must do something funky with that dict though to require the compiler package...
<james_w> it stores it in repr form in the text file as far as I can see
<james_w> def getObj(s):
<james_w>     s = "a=" + s
<james_w>     if compiler is None:
<james_w>         raise ImportError('compiler module not available')
<james_w>     p = compiler.parse(s)
<james_w>     return p.getChildren()[1].getChildren()[0].getChildren()[1]
<markh> yeah - which eval could reconstruct - but I guess it wants to avoid eval
<markh> "untrusted" config files?
<markh> or maybe it supports types that repr/eval can't reconstruct... whatever :)  thanks!
<poolie> beuno: well done on the theme, it looks great on lp
<beuno> hey poolie!  Thanks  :)  I'm really happy to finally see it live
<poolie> don't stop now! :)
<beuno> heh, of course not, this is an incentive  ;)
<poolie> i think that's enough for me
<poolie> night all
<markh> night poolie
<beuno> g'night poolie
<james_w> night poolie
<james_w> hi besonen_mobile__
<james_w> hi beuno :-)
<beuno> howdy james_w!
<james_w> beuno: congratulations on the new theme landing, it looks great.
<beuno> james_w, thanks :)  although, to be fair, mwhudson's reviews have been unvaluable
<bob2> hm, I don't seem to be able to 'branch' a branch in a rich-root-pack repo over bzr+ssh anymore
<bob2> ah, B_R_P wasn't set
<james_w> hey, could someone in ~bzr and do me a favour and close bug 252894 as Fix Released and milestone for 1.6?
<ubottu> Launchpad bug 252894 in bzr "generally applicable way to refer to parent or stored locations" [Wishlist,Incomplete] https://launchpad.net/bugs/252894
<james_w> I'm having some issues today which mean I can't login to launchpad.
<Odd_Bloke> james_w: Done.
<james_w> thanks
<jam> igc: I'll be happy to review your patches, but right now BB is giving me PROXY timeouts
<jam> And abentley is in NZ, so will be sleeping during my TZ
<igc> jam: yeah - me too
<jam> Any chance you could give me the subjects, and I'll do it via email?
<igc> jam:sure
<igc> jam: Make it easier to introduce new WorkingTree formats
<igc> jam: do not export .bzrrules
<igc> jam: lookup rules using get_special_file API
<igc> that's the 3
<jam> igc: quickly, I'm a bit concerned about the 'get_special_file', the other two I'm probably happy with
<jam> But I'll review them all
<jam> igc: I'm surprised you're still awake, are you shifting your schedule a bit?
<igc> jam: just catching up some hours
<gour> igc: how is the fight against enemy?
<RealNitro> is there a tutorial about interfacing with bzr-repositories through python? Something like repo = BzrRepo(path)
<igc> gour: it has its good days and bad days
<igc> gour: week 4 of 6 now
<jam> RealNitro: http://bazaar-vcs.org/Integrating_with_Bazaar ?
<igc> (of the initial stage of the battle at least)
<RealNitro> jam: thx!
<gour> igc: keep up the spirit. have you managed to read something of that material?
<igc> gour: not a lot I must say - my reading pile is long
<gour> igc: heh, use Emacs' org-mode and run it for GTD :-)
<igc> night all
<gour> night, igc
<jam> igc: sleep well
<jam> patches reviewed
<Odd_Bloke> jelmer: python-git is in the NEW queue. :D
<Odd_Bloke> If any Mac users have a minute: https://bugs.launchpad.net/qbzr/+bug/253008
<ubottu> Launchpad bug 253008 in qbzr "Qbzr not working :(" [Undecided,Incomplete]
<james_w> yeah, I didn't know how to install python-qt4 on mac
<Odd_Bloke> I should probably have converted it to a question, but was worried that that would confuse everyone involved so didn't. :p
<tolstoy> Hi folks. Simple question. If you've branched, and then you work on the branch, etc, etc.  How can you tell exactly when/where you branched from the parent without having tagged?
<radix> tolstoy: You can use the "ancestor:branchname" revision spec
<radix> so, in the context of ../branch1, if you use "-r ancestor:../trunk", it means "the ancestor revision of this branch in ../trunk"
<tolstoy> Hm. Okay.  Thanks.
<tolstoy> I think that worked (for my colleague). Thanks!
<mtaylor> bzr: ERROR: Invalid bug 252805. Must be in the form of 'tag:id'. Commit refused
<ubottu> Launchpad bug 252805 in drizzle "./configure not detecting missing g++" [High,Confirmed] https://launchpad.net/bugs/252805
<mtaylor> I'm not sure what to put for --fixes, given the above error
<mtaylor> I tried --fixes=252805...
<radix> mtaylor: I think it's supposed to be 'lp:252805'
<mtaylor> ah
<mtaylor> There we go. thanks radix
<Odd_Bloke> mtaylor: If you don't think --fixes is well-documented enough, could you please file a bug about it?
<mtaylor> Odd_Bloke: sure
<Odd_Bloke> mtaylor: Thanks. :)
<mtaylor> Odd_Bloke: Bug 120050
<ubottu> Launchpad bug 120050 in bzr "'bzr commit --fixes' should have better documentation" [Medium,Confirmed] https://launchpad.net/bugs/120050
<Odd_Bloke> Well, I should probably have checked first. :p
<Odd_Bloke> mtaylor: Sorry to waste your time.
<mtaylor> Odd_Bloke: no problem!
<oohlaf> why doens't bazaar have a bzr copy command?
<oohlaf> next to move
<oohlaf> I just ran into having to copy a file in a repo and make some modifications to it, but then it's not annotated
<oohlaf> with the previous auther
<jelmer> oohlaf, it's planned, just not implemented yet
<james_w> jam: I was working on the bug tracker thing as well :-)
<james_w> jam: are you cleaning your patch up to submit it?
<jam> james_w: I'm not doing anything more than what I posted
<oohlaf> jelmer: ah, ok
<jam> I'm working on merge again
<oohlaf> jelmer: you prob need it for svn copy, right?
<jam> james_w: if you are working on it, make sure to assign it to you
<james_w> jam: cool, I'm working on it, so I didn't want to duplicate work.
<james_w> true
<beuno> anyone happen to know how I can convince distutils to install zope templates on the package's dir?
<jam> beuno: "package's" dir?
<jam> do you mean in-place?
<beuno> jam, I need them to be in site-packages/.../loggerhead/templates/*
<beuno> and it only copies .py in there
<jam> Like "python setup.py build_ext -i" ?
<Dossy> bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "sftp://dossy@bzr.savannah.gnu.org/srv/bzr/gnash/trunk/".
<Dossy> Suggestions?
<Dossy> $ bzr version
<Dossy> Bazaar (bzr) 1.6b3
<jam> Dossy: you are trying to push something which merged trunk
<jam> rather than merging into trunk
<Dossy> jam: I guess so.
 * Dossy is a bzr newbie.
<jam> and that cannot be pushed because someone set the "append_only" flag
<jam> the recommendation is to
<jam> bzr co gnash/trunk
<jam> cd trunk
<jam> bzr merge ../my-branch
<jam> bzr commit
<jam> (with appropriate full paths)
<Dossy> Oh.  Ack.
<Dossy> I have to duplicate commit messages?
<beuno> jam, I'm not sure what "setup.py build_ext -i" would do
<Dossy> OK, so at this point - what can I do?  LOL.  And, I should bzr checkout and not bzr pull or bzr branch?
<jam> beuno: it is what we use with bzr
<Dossy> What's the difference between bzr pull and bzr branch anyway?
<jam> it puts the .so library "in tree" rather than only building it in the build/... directory
 * beuno peaks in bzr's setup.py
<jam> Dossy: 'bzr pull' fetches changes that you don't have yet to local
<jam> beuno: that would probably be in 'Makefile'
<jam> Dossy: I'm assuming you just recently merged trunk?
<jam> (as in, the last action you did?)
<Dossy> jam, yes
<Dossy> and committed the change
<jam> then I would "bzr merge -r -2"
<jam> which would skip your merge commit
<jam> and merge the previous revision
<Dossy> Hm.  OK.
<jam> and only type the message there
<jam> well, you are technically doing it twice, but the one won't show in trunk
<jam> Dossy: alternatively you could "bzr uncommit; bzr revert" in your branch
<Dossy> Oh, my local commit messages won't show in trunk?
<jam> Dossy: well if you do "bzr merge -r -2" then the *last* revision won't be merged
<jam> andthus, not show up in log
<Dossy> Ohh - what about the commits I actually want to push?  :)
<jam> Things you "bzr merge && bzr commit "will show up in the log
<Dossy> Wow.  bzr uncommit is ... slow.
<james_w> has anyone seen a hang in blackbox.test_outside_wt.TestOutsideWT.test_url_log?
<alecwh> Are there any web services (besides Launchpad) that will host bazaar repositories?
<james_w> alecwh: alioth and savannah are two that spring to mind, though they are not completely general purpose
<alecwh> the project isn't open source...
<beuno> jam, I'm looking at it, but I'm not quite sure how I'd use that to copy over arbitrary files
<Odd_Bloke> alecwh: Anywhere that gives you SSH and HTTP access can be used as a web host for bzr.
<alecwh> What about FTP and HTTP?
<jam> beuno: it isn't for copying arbitrary files, it is for building an extension such that you can run in-tree
<jam> beuno: I don't honestly know why it isn't copying the files over
<jam> Though I don't know what command you are using
<jam> beuno: 'python setup.py install --help'
<jam> has a --install-base, --install-platbase, --install-purelib, etc
<jam> --install-platbase  base installation directory for platform-specific files
<jam>                     (instead of --exec-prefix or --home)
<jam> sounds like something compiled
<beuno> yeah, let me push real quick, and see if something obvious pops up to you
<beuno> if not, I'll keep hammering help files and google  :)
 * beuno waits for codebrowse to mirror the branch
<jam> beuno: I can get it via bzr+ssh
<jam> what branch?
<jam> (though my net connection here might be rather slow)
<beuno> jam, lp:~beuno/loggerhead/fix_setup
<jam> beuno: so... can you explain *why* you are doing this?
<jam> It seems like SimpleTAL should get installed as normal
<jam> and you just use it from there
<beuno> jam, I need the *.pt files in templates/
<jam> why?
<Dossy> grr.  bzr break-lock doesn't seem to work on win32.
<Dossy> it just hangs.
<jam> beuno: also, I would recommend using loggerhead.__version__ rather than hard-coding '1.6' in setup.py
<jam> It is generally a good idea to have a *minimum* number of places where you need to change version strings
<beuno> jam, noted
<beuno> I need the .pt files there because that's where LH looks for them
<jam> otherwise you always forget one :)
<jam> beuno: so right now, you just have them manually copied there?
<beuno> jam, right now, it doesn't work. setup.py has been broken for ages.
<jam> and you can't use a "try import from_tal else import_from_local"
<jam> beuno: well, I see .pt files in there
<jam> and I ran from source without it causing problems
<jam> beuno: are you just trying to install the .pt files that you already *have* in there?
<beuno> jam, it works from source. The problem is when you install it
<jam> I think I just caught on to what you wanted
<beuno> it installs serve-branches in /usr/bin
<jam> I thought you wanted to install *Zope* templates
<jam> not templates for the Zope engine
<beuno> ah, yes  :)
<beuno> sorry I wasn't clear from the start
<jam> beuno: "package_data"
<jam> look at setup.py for bzrlib
<jam> namely, the 'doc/api/*.txt'
<beuno> that simple?
 * beuno looks
<jam> and 'tests/test_patches_data"
<jam> PKG_DATA = {# install files from selftest suite
<jam>             'package_data': {'bzrlib': ['doc/api/*.txt',
<jam>                                         'tests/test_patches_data/*',
<jam>                                         'help_topics/en/*.txt',
<jam>                                        ]},
<jam>            }
<jam> beuno: so "package_data = {'loggerhead': ['templates/*']}"
<jam> or something along those lines
<alecwh> jam: pastebin that next time
<jam> === modified file 'setup.py'
<jam> --- setup.py    2008-07-29 19:17:53 +0000
<jam> +++ setup.py    2008-07-29 20:39:29 +0000
<jam> @@ -41,6 +41,7 @@
<jam>      scripts = ["start-loggerhead", "stop-loggerhead", "serve-branches"],
<jam>      packages = ["loggerhead",
<jam>                 ],
<jam> +    package_data = {'loggerhead': ['templates/*']},
<jam>      data_files=[
<jam>                  ('share/man/man1',['start-loggerhead.1', 'stop-loggerhead.1']),
<jam>                  ('share/doc/loggerhead', ['loggerhead.conf.example'])
<jam> alecwh: yeah, sorry
<alecwh> =(
<jam> Just trying to get done, and firing up a browser takes a while
<beuno> jam, you rock, thank you  :)
<Dossy> ok, looks like bzr uncommit is broken on win32.  i've left it running ~40 minutes, and it's not done
<Dossy> and no progress indicator.  no output at all, and I ran it with -v
<lifeless> Dossy: can you look at your .bzr.log
<lifeless> beuno: why not nuke serve-branches as a script altogether?
<beuno> lifeless, nuke it?  why?
<lifeless> beuno: 'bzr serve-branches' as an interim step, and then 'bzr serve --http'
<beuno> interesting
<lifeless> if you look at the help for bzr serve
<lifeless> 'bzr serve-branches' will give you help and option parsing etc for ~ free
<lifeless> if you look at the help for bzr serve you'll see that it is basically the same as any help you might write for serve-branches
<beuno> lifeless, makes perfect sense, I'll go down that path
<beuno> and, good morning  :)
<lifeless> hi
<lifeless> there is a thread at the moement about whether bzr serve --http makes sense, but putting that aside, having loggerhead start as a normal extension command seems uncontentious and to give benefits.
<beuno> yeap, and it will feel much more integrated
<beuno> I like it!
<beuno> I also have all this ajax-voodoo in store, now that the new theme has landed everywhere
<lifeless> cool
<lifeless> is the gnome themed loggerhead getting it too ?
<beuno> yeap, I uploaded a new branch with the new theme for 'em
<beuno> but I don't think Jc2k got around to merging it
<beuno> lp:~beuno/loggerhead/new_theme_gnome
<lifeless> nag thumper
<lifeless> playground is something he has work time for now :)
<beuno> yay!
<beuno> will do
<lifeless> beuno: I'm curious though, I did mention this in the thread
<lifeless> was I unclear?
<beuno> lifeless, you did, I just didn't see it as straightforward
<beuno> 'bzr serve-branches' tipped me off it's much simpler then I thought
<lifeless> heh ok
<pickscrape> I've just discovered the possible_transports parameter that is available throughout bzrlib
<pickscrape> Does this need to be maintained manually?
<pickscrape> i.e. if I call a function and pass a list, do I need to add the transport my code uses to the list in case it needed to create a new one?
<lifeless> pickscrape: its an optional performance improvement
<lifeless> it can also avoid giving users additional password prompts in some situations
<pickscrape> lifeless: for what I'm doing it's quite a significant performance improvement :)
<pickscrape> It reduces the number of SSH reconnects from some factor of 14 to just 1.
<lifeless> nice
<lifeless> sounds like you are opening very many new branch/repository objects
<pickscrape> Our migration split our monolithic svn repository up into smaller more focused repositories
<pickscrape> We're writing a plugin to allow some operations to be performed on a set of them at once.
<lifeless> yes, thats the sort of situation where it matters
<lifeless> branch objects etc hold open their transport
<pickscrape> Yes, it was quite magical making a simple change to the code and then watching the ssh log on the server become far quieter :)
<lifeless> but we removed a global cache we had which caused many problems
<lifeless> which is why we have this parameter
<pickscrape> Lovely feature to find :)
<chadmiller> Hi all.  I have a shared repo, containing v1, v2, and v3 branches.  "bzr tags" lists all tags, regardless of whether its associated revision is in this branch or not.  This is a bug, yes?
<chadmiller> I can't see how it's useful, but...
<lifeless> chadmiller: it lists tags in a given branch
<lifeless> chadmiller: so if you have tags that are irrelevant to a branch, you've put them in there somehow :P
<lifeless> chadmiller: possibly your converter was not selective about which tags went into which branch
<chadmiller> lifeless: Hrm.  That's possible.
<chadmiller> And lpbug#138802 won't let me delete them.  Grr.
<lifeless> bug 138802
<ubottu> Launchpad bug 138802 in bzr "tag deletion does not propagate" [Medium,Triaged] https://launchpad.net/bugs/138802
<chadmiller> Oh well.  No big deal.  Just ugly.
<lifeless> you can copy the tags file up by hand if you like
<chadmiller> Not for 175 developers.
<lifeless> oh :[
<lifeless> true dat
<chadmiller> Each with dozens of trees.
<chadmiller> Okay.  Thanks.
<lifeless> spiv: ping; that reconcile bug - I wasn't intending to ask you to hack on it, but in case you did start doing that I'm going to leave it idle until you reply
<pickscrape> lifeless: do you have a minute regarding the possible_transports stuff?
<pickscrape> One of the things we're doing is running update on a number of checkouts
<lifeless> sure
<pickscrape> I've done this by extending bzrlib.builtins.cmd_update, and calling the base class's run method for each checkout I'm iterating through
<pickscrape> It works fine, except that it's connecting to the server for each checkout, and possible_transports is initialised in bzrlib.builtins.cmd_update.run() each time
<pickscrape> I've experimentally tried moving it to a member variable of bzrlib.builtins.cmd_update instead of a local variable of run(), and that gives me what I need for free without any changes in my code
<pickscrape> But I'm not sure if such a change would be acceptable in bzrlib
<lifeless> mmm
<lifeless> you could do that
<lifeless> but the command classes are intended to be CLI layer only
<lifeless> why are you not using the WorkingTree.update method ?
<pickscrape> The advantage to using the command class is that I get functionality consistent with the main command for free
<pickscrape> It's not actually much of an advantage with update, but with things like status it means I get option handling and output consistent with the core command
<mwhudson> beuno: hi
<lifeless> pickscrape: I'm ok with run being an instance variable
<lifeless> pickscrape: long as its not a class variable
<pickscrape> lifeless: I'm embarrassed to say I'm not entirely clear on the difference with python :( I'm relatively new to it
<lifeless> class foo:
<lifeless>   bar = None
<lifeless> -> bar is a class variable
<lifeless> class foo:
<lifeless>   def __init__(self):
<lifeless>     self.bar = None
<lifeless> -> bar is an instance variable
<pickscrape> Aha, that makes sense, thanks. My little experiment used a class variable: I'll try it with an instance variable.
<pickscrape> lifeless: worked with the instance variable too
<lifeless> put it in NEWS, send a bundle :P
<pickscrape> lifeless: If I was to submit a patch, should I do this with just this one command, or others for which it would make sense too?
<lifeless> pickscrape: as many as you like
<lifeless> I'd start with one and see what the reaction is
<lifeless> (unless you've done others already)
<pickscrape> lifeless: I've just done one. I'll do that tomorrow. Thanks for the help!
<Peng_> Personally, I'd like it if remove-tree could operate on multiple dirs at once, but I've been too lazy to do anything about it.
<lifeless> Peng_: I think thats a different change; pickscrape is making the command more useful to subclassers, not changing the UI level behaviour
<Peng_> Oh, okie dokie.
<spiv> lifeless: I haven't started hacking on it, no.
#bzr 2008-07-30
<igc> morning
<cjwatson> igc: fast-import is awesome
<mwhudson> hello igc
<cjwatson> igc: I'm importing an svn archive at the moment with a vendor-branch-like arrangement for upstream, and trying to arrange that the resulting bzr branch has native merge commits for each upstream merge. It's working amazingly well
<cjwatson> (james_w gave me the last necessary clue in the form of import-marks)
<james_w> cjwatson: I'm glad it's working for you
<igc> thanks cjwatson
<lifeless> jelmer: ping
<jelmer> lifeless, ponggg
<lifeless> bug 250480
<ubottu> Launchpad bug 250480 in bzr-svn "Doesn't preserve non-lhs parents for file texts" [High,Triaged] https://launchpad.net/bugs/250480
<lifeless> I agree with john that this is critical
<lifeless> I don't understand quite where the issue is re non-lhs parents and the error
<lifeless> from my analysis I thought that there were two inventories with different values and the same revid
<lifeless> which is also known as 'corrupt distributed DB'
<lifeless> but you seem to think its something else
<lifeless> ?
<jelmer> No, I agree with that analysis (for values == "file parent ids")
<lifeless> parent ids are not stored in the inventory
<lifeless> so I don't understand what you mean when you say you agree :)
<jelmer> The actual error suggests that bzr can't find the revision of a file text
<jelmer> however, that file text is a ghost in the branch fetched by bzr-svn
<lifeless> so there are three revisions bzr will look for
<lifeless> (and need)
<lifeless> and some N that it will need when fetching IFF the revision is also present
<lifeless> the three it needs are left/right/base
<lifeless> but another possibility is that the change rev in the inventory in the target repo is actually bogus; its a change that the repository does have and can't get hold of
<lifeless> or something along those lines
<lifeless> back in 30, got to do some stuff here
<lifeless> I guess I'm really saying: lets pin down *exactly* why bzr is asking for that revision, and whether there are *any* differences in data between the repositories
<lifeless> *other* than ghosts. Ghosts are ok, different xml-inventories or revision-xml's etc are not.
<jelmer> as far as I can tell, the particular revision it was asking for doesn't occur in svn or the svn-based branched *anywhere*
<markh> I thought I heard that bzrtools has been incorporated into 1.6 - is that true, or only some parts have been incorporated?
<markh> ultimately I'm trying to work out if the windows binary should package it?
<Peng_> Um, it hasn't been.
<spiv> markh: it hasn't been incorporated, no.  So please do package it.
<markh> spiv: ok, thanks
<igc> jam: wrt export masking, do you think plugins should use another pattern if they want their magic stuff exported?
<igc> jam: I could put the rule in a function that plugins could monkeypatch over to tune it *but* that feels pretty fragile myself
<lifeless> I think there are two use cases
<lifeless> one is adding arbitrary data (e.g. version-info output) during export
<lifeless> the other is masking data that shouldn't be in the user tree (e.g. .bzrignore)
<lifeless> I'd *prefer* we fix the latter by just not putting in the users tree
<lifeless> the former seems genuinely useful though
<igc> lifeless: I'm not changing the former, just generalising the latter so that anything starting with .bzr is not exported
<lifeless> igc: yes, I saw the patch.
<jelmer> spiv: --rich-root is not an alias at the moment, were you assuming it was?
<spiv> jelmer:
<spiv> $ bzr init --help | grep -A1 -- "--rich-root "
<spiv>     --rich-root         New in 1.0.  Better handling of tree roots.
<spiv>                         Incompatible with bzr < 1.0
<mwhudson> beuno: awake?
<spiv> jelmer: so I wasn't just assuming, I checked :)
<jelmer> spiv: that's not an alias, it's a knits-based format
<spiv> Ah :(
<jelmer> it may be a good idea to get rid of it though, in favour of an alias...
<spiv> jelmer: thanks for noticing my mistake
<beuno> mwhudson, yeap, evening'
<beuno> just got home
<lifeless> hi
<mwhudson> beuno: hi, thanks for fixing loggerhead :)
<beuno> mwhudson, I felt a bit responsible  :)
<mwhudson> beuno: so i am a little confused though
<mwhudson> beuno: will the loggerhead we're running break with current bzr.dev ?
<beuno> mwhudson, no, it works with bzr.dev
<beuno> a few commits after b2
<mwhudson> beuno: good
<beuno> when lifeless's enourmous patch landed it broke
<mwhudson> so why did this method change?
<mwhudson> oh right
<mwhudson> then bzr.dev became more compatible again?
<beuno> "versioned files" and the likes
<beuno> compatible relative to what?  :)
<mwhudson> well
<beuno> one of the things I was thinking of, is having that part patched in LH for a few versions, where it tried both methods
<mwhudson> wasn't the patch you gave kiko reverting the change that was made to this method?
 * mwhudson attempts to make sense
<mwhudson> the loggerhead we're running does this:
<mwhudson> w = self._branch.repository.weave_store.get_weave(file_id, self._branch.repository.get_transaction())
<mwhudson> rather than existing_keys = self._branch.repository.texts.get_parent_map(possible_keys)
<beuno> mwhudson, yes, because you're running b2 in code host
<lifeless> mwhudson: the former won't work in b3 and abot
<mwhudson> because .texts doesn't work with b2
<beuno> and it works from b3+
<mwhudson> <mwhudson> beuno: will the loggerhead we're running break with current bzr.dev ?
<mwhudson> <beuno> mwhudson, no, it works with bzr.dev
<beuno> mwhudson, ah, my mistake
<beuno> it will
<mwhudson> is this actually what you meant to say?
<beuno> I warned matsubara
<beuno> that it would
<mwhudson> ah, ok
<beuno> I misunderstood
<beuno> I just bought a Wii and got distracted   :)
<mwhudson> ok, so this isn't ideal but at least i understand what's going on now :)
<beuno> yeah, I offered to put together a patch that would probe one, and go to the other if it failed
<beuno> but they chose reverting
<mwhudson> okidoke
<beuno> I still think it makes sense to do that for trunk
<beuno> so we can be compatible with older bzr versions
<mwhudson> yeah i guess so
 * beuno is off to dinner
<tsculpt> anybody have trouble saving commit message with emacs as editor?
<tsculpt> I get: vc-bzr-registered: IO error reading c:/bzrfun/home/main/.bzr/checkout/dirstate: Permission Denied, when tring to save
<tsculpt> bzr 1.5
<lifeless> tsculpt: bzr will have an exlusive lock on the dirstate file
<lifeless> tsculpt: sounds like some emacs thing is trying to read that file directly (not such a great idea btw :P)
<tsculpt> well, just trying to use emacs as commit editor
<tsculpt> bzr commit
<tsculpt> emacs comes up with the modified listing
<tsculpt> I write my message, and try to save, and I get the error.
<tsculpt> The vc-bzr-registered part makes me think emacs is doing something with it's built in vcs stuff?
<tsculpt> ah, I notice it loads vc-bzr
<markh> hrmph - "bzr help commands" will list 94 commands by default on Windows!!
 * igc lunch
<lifeless> igc: ping
<igc> hi lifeless
<lifeless> I'd like to chat about .bzrrules some
<igc> fire away
<lifeless> if you're up for it I could give you a ring
<lifeless> or else drop you a mail
<lifeless> or IRC works for me too
<igc> email might be best today
<lifeless> k
<lifeless> I will drop some thoughts to you directly
<igc> sure
<gambler> I read that limbo post from http://bazaar-vcs.org/BzrVsGit and I realised thats a big problem for me
<gambler> has anything been done about it in bzr?
<luks> what is a big problem for you?
<bob2> which part?
<bob2> you can alias 'commit' to 'commit --strict' if you don't want to forget to commit new files
<gambler> the files that remain in limbo...those in a directory that aren't explicitly added to the repo to track
<gambler> bob2, yeah but i prefer to automate alot of that
<bob2> as in you want bzr to run 'bzr add .' before every commit?
<gambler> i suppose
<gambler> would that work?
<gambler> <-- not a current bzrer
<RAOF> gambler: That would work, but is probably not a good idea.
<RAOF> gambler:
<RAOF> gambler: In particular it would mean that you wouldn't want to build in your working tree, since subsequent commits would then add the results of the build (plus random autotools files, etc).
<luks> you can `bzr ignore` those
<bob2> well, you would ignore that .o configure.ac etc
<RAOF> bzr doesn't do globbing in .bzrignore, right?
<bob2> it does
<luks> it supports full filenames, globbing and regexes
<bob2> it optionally does res
<RAOF> Of course; my shell's being too smart for its own good.
<gambler> so bzr add . bzr ignore *.class for my android project and I get automatic adds?
<bob2> no
<luks> gambler: commit --strict is really a better idea
<luks> automating things is nice and all that, but some things are better to review
<bob2> hey, you'll get a chance to review in the commit editor ;)
<luks> that's way too late, IMO :)
<gambler> luks: thats how it starts...then why dont I write some unit tests, and X and Y and Z....and my productivity drops like a rock
<spiv> If you do bzr alias commit="commit --strict" then bzr will automatically tell you if there are new files you haven't added or ignored yet.
<gambler> ok..maybe ill try that
<spiv> At which point you can decide what to do about them, and get on with work.  That satisfies the criterion for "automated" pretty well for me :)
<gambler> meh, the problem with all VCS is that it would be nice if all their interfaces were pure method calls, then I could design my workflow around them instead of the other way
<gambler> I could script but then you run into problems making it robust
<gambler> i script now
<spiv> More automatic would probably mean automatically guessing what to do with individual files, which wouldn't make me comfortable.  I can imagine that working fine for some people, though.
<spiv> Well, bzr is completely scriptable in Python.
<gambler> hmmm good point
<spiv> It's even pretty easy to write a plugin to add new commands or extend existing ones.
<gambler> im looking at bzrlib now...but im not really a python dude
<Ryan52> Is there any way to go through a projects history and change my name everywhere? Right now it's just <email>, but I want it to be 'Name <email>'.
<Jc2k> beuno: i hit a bug so i reverted
<Jc2k> beuno: its not finding css/imagery again..
<luks> Ryan52: no, revisions are immutable
<luks> Ryan52: something like that would need to create a completely new branch with different revision IDs
 * Ryan52 thinks he would get in trouble for doing that :)
<Ryan52> okay, thanks.
<gambler> meh too much work
<gambler> what is the status of the bzr plugin for eclipse...anyone here using it?
<lifeless> it works quite well
<lifeless> Verterok: is the main developer
<Verterok> gambler: I'm about to release a new build (with bunch of improvements)
<gambler> Verterok, will it mind my adding and deleting of files?
<Verterok> gambler: it handle moves/deletes/renames
<Verterok> gambler: but the delete is equivalent to 'bzr rm --keep' (to avoid removing non-recoverable files)
<luks> (all files deleted by `bzr rm` are recoverable)
<lifeless> yay firefoxfail
<gambler> if you could add in auto-adding of files that would be pure sex
<Verterok> luks: but if you have added (not yet committed) bzr rm --force delete them in a non-recoberable way :)
<luks> ugh
<luks> but why --force?
<lifeless> I'm not entirely happy with rm today
<lifeless> the basic tension is that unversion and rm are different operations
<lifeless> but we only have one command, because people usually want both operations to be undertaken
<Verterok> gambler: I don't fully understands the "auto-adding" thing :P
<luks> I don't think rm should be handled by a VCS
<luks> the old behavior (rm --keep) was my favorite
<gambler> Verterok, auto-add any newly created files in the root directory, unless they are in the bzr ignore list.
<gambler> Verterok, for renames....improvise :)
 * fullermd has rm aliased to rm --keep.
<gambler> Verterok, actually you can tie into Eclipse->Refactor-Rename
<luks> yeah, me too
<Verterok> gambler: mmm, there was a bug/feature request some time ago (java specific), about auto-adding newly reated classes.
<gambler> and?
<Verterok> gambler: if I can provide an option so it can be enabled/disable, I'll be glad to add this feature
<Verterok> but I don't want that behaviour as default
<Verterok> gambler: renames are handled by the plugin
<Verterok> :)
<gambler> i will love you forever
<gambler> cant wait to try it. i am an insane refactorer and I need that
<Verterok> Verterok: if you find any glitches (or missing feature), please fill a bug so I can track and plan the features for the next milestone :)
<Verterok> s/Verterok/gambler/ :P
<gambler> np..when will you release your next version
<Verterok> gambler: if all keep going as planned, in ~ 20hs :)
 * Verterok need to sleep a few hours
<gambler> ok...no rush. i've written myself a note to download it
<Verterok> I just finished a build from trunk, and testing it ATM
<Verterok> all for today, seeya later
 * Verterok heads to bed
<gambler> c u
 * igc dinner
<cjwatson> igc: hmm, so having said that I had a really good import (an svn branch for a Debian package which I'm gluing onto the side of the existing bzr branch for upstream) with bzr-fastimport, I realised that all my file-ids are screwed
<cjwatson> igc: is there any way to get fast-import to say "this commit has 'from' or 'merge', therefore all files added in this revision should take their file-ids from that other branch"?
<igc> cjwatson: hi, I can't stay and chat sorry but a few things ...
<igc> how did you generate the stream? By hand?
<cjwatson> igc: slightly hacked version of svn-fast-export.py
<igc> See the spec. You can certainly say 'get the file-ids' from another branch *assuminh* that branch is also in the stream already
<cjwatson> (I stuck in a dictionary of commit identifiers to marks that I wanted to be merged)
<cjwatson> hmm, did I miss it? I thought I looked
<cjwatson> the other branch is not in the import stream; I'm referencing it by means of import-marks
<james_w> fast-import won't look at the those revisions, it will just add the extra parents you request.
<james_w> I believe we could extend fast-import to optionally look for them and import the file-ids.
<igc> cjwatson: spec is http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html
<cjwatson> yeah, I'm reading that
<james_w> hi igc
<igc> hi james_w
<cjwatson> it seems to have a way to reference existing content from elsewhere, but not existing file-ids
<igc> cjwatson: so I won't be around but james_w knows the fastimport code pretty well and it's pretty hackable imo
<cjwatson> yeah, I certainly don't mind hacking it (and already have done), but wanted to know if this was in place already
<cjwatson> if it's not, I can always beat it up until it is
<cjwatson> it does seem like it's what you'd want to be the default behaviour when 'merge' commands are present in the stream though
<james_w> cjwatson: for a quick hack, around line 513 of processors/generic_processor.py could be extended to also look at all the revision ids listed in the marks
<james_w> _gen_file_ids_cache
<cjwatson> hmm, right, might have to do something interesting in the case where you have file added in svn branch, then deleted and copied-over-the-top
<cjwatson> since then there'll be multiple file-ids to choose from for a given path
<james_w> yeah, the cache should actually be replaced with something else as I understand it
<lifeless> personally; I'd just let bzr do all the heavy lifting
<james_w> however, I think the replacement would actually be harder for you to hack to get what you want
<james_w> hey lifeless
<lifeless> but apparently there were performance implications in doing that
<cjwatson> I have the feeling I want to special-case it at the cache user end, since I only want this check in the cases of certain commits
<james_w> bzr_file_id_and_new
<cjwatson> like bzr_file_id_and_new(self, path, sourcerev=None)
<cjwatson> snap :)
<nazgjunk> hi, do ignore files stack? I seem to have a global ignore file somewhere, can I assume that it'll still be checked when I add one to the branch I'm working in?
<james_w> nazgjunk: ~/.bazaar/ignore, and yes
<nazgjunk> thanks
<lifeless> right
<lifeless> bug fixed
<lifeless> -> off
<Jc2k> ahh that reminds me
 * Jc2k goes to read gnome-bzr log
<lifeless> igc: got busy on a bug; I'll try to mail you tomorrow; or perhaps voice would work better then; something
<lifeless> gnight all
<igc> sure lifeless; night
<pfctdayelise> hi, I'm trying to use bzr on a shared webhost. 'python' -> 2.3.4, which has the bz2 module, but there is also 'python2.4' which does not.
<pfctdayelise> can I get bzr to use python 2.3? or should i try to install the bz2 module?
<dennda> Hi. How can I fix this? http://paste.pocoo.org/show/80707/
<dennda> Doesn't work with bzr push lp:~dennda/memaker/experimental either
<dato> pfctdayelise: bzr will definitely not work with python 2.3
<andrea-bs> dennda: bzr launchpad-login "your-launchpad-id"
<luks> dennda: bzr launchpad-login <your-username>
<luks> or just use a ssh+bzr url directly
<luks> bzr+ssh I mean
<mlh> I suppose people have read http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation
<mlh> ?  haskell is moving away from darcs  - interesting discussion of git vs hg vs bzr
<jelmer> mlh, that page only lists git and mercurial as serious contenders
<jelmer> do you know why that is?
<luks> weird how 'Cherry-picking isn't very "native" to the data model' is a disadvantage of bzr, but not hg and git
<mlh> jelmer: that's what one line says, but the rest of the page seems to contradict it
<mlh> so .. not clear
 * mlh sleeps
<gour> have you seen  http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation  ?
<gour> new potential customer...
<james_w> heh :-)
<gour> ghc is not so small project and has (potential) influence on the whole haskell community
<arnarl> what are the commands for resetting/changing related branches (as listed in bzr info)
<arnarl> is it only available in locations.conf?
<james_w> arnarl: you can either edit ~/.bazaar/locations.conf, or you can use --remember on the appropriate commands
<james_w> so "pull --remember" will change the parent branch, "merge --remember" will change the submit branch
<arnarl> james_w: thnx! :-)
<jam> chadmiller: Ping, would you like to discuss the new issue privately?
<chadmiller> Sure.
<beuno> jelmer, around?
<evanton> hello, how can one force bzr to make a file executable?
<luks> chmod a+x file
<evanton> luks: let me explain
<evanton> I have to assume somebody submits a text file containing a python script from windows
<evanton> when I check out the branch, that file has 644 permission
<evanton> I would like it to have 755 instead, so there must be probably a way to tell bzr that it shall set certain permissions during a commit
<luks> evanton: on windows it's more complicated, since bzr itself doesn't support it
<luks> there is a plugin that can be used to swith the executable flag on windows
<luks> https://launchpad.net/bzr-x-bit
<evanton> do you think that chmodding the file in linux and commiting it into the branch from there instead would work?
<luks> evanton: of course
<evanton> thank you
<rexbron> hey would any of the bzr-svn guys be able to look at bug 253376
<ubottu> Launchpad bug 253376 in bzr-svn "Crash when network goes down during a checkout" [Undecided,New] https://launchpad.net/bugs/253376
<jelmer> rexbron: just replied
<rexbron> jelmer: As I mentioned, if you remove the dir your checking into and re-run the command, it will pick up where it left off. So it's not that serious. Perhaps it is worth a mention on the bzr-svn known issues section
<jelmer> rexbron, I think it's worth mentioning, but rather in the bzr docs than in bzr-svn since neither the bug nor the workaround are specific to bzr-svn.
<rexbron> ok
<beuno> jelmer, I'm working on a branch to fix loggerhead's setup, can you take a look at it and see if you need anything changed for Debian?
<beuno> lp:~beuno/loggerhead/fix_setup
<jelmer> beuno, sure, give me a few minutes
<beuno> jelmer, thanks  :)
<theuiguy> Is there any kind of plugin for bzr that allows you to modify history? Specifically, to change email/names of committers?
<theuiguy> Or perhaps some way to modify check in dates?
<NfNitLoop> theuiguy: not to my knowledge...  modifying history is not really possible in a distributed system.
<NfNitLoop> You could modify *your* history, but then you don't sync up w/ everyone else.
<NfNitLoop> which could cause problems.
<theuiguy> NfNitLoop: I see your point... in this particular case, there's only one branch right now
<NfNitLoop> ah.  Well then you could in theory do it, but my guess is that nobody has bothered to write/distribute code to do so for the above reasons.
<james_w> theuiguy: there's nothing specifically for it
<james_w> there's two things which could, but don't yet, bzr-rebase and fast-export/fast-import
<theuiguy> How about a plugin to merge commits?
<james_w> that would probably be the same tool
<theuiguy> james_w: I was thinking bzr-rebase might do something like it, but I thought you needed to do it before your commit
<james_w> interactive rebase can do the latter, I don't know if that's available yet though
<theuiguy> Perhaps you could give me an alternative solution -- I'm told I can open source some code, but need to scrub email addresses that expose internal server names.
<theuiguy> It already in bzr, with a relatively short revision history -- I think around 25 revisions.
<theuiguy> I suppose I could just create a new branch with the latest code and go from there, but it's a shame to lose the history
<james_w> theuiguy: ok, to change that I would suggest bzr-fast-export and bzr-fastimport.
<james_w> you can export to a text file, sed the file to clean up the names as you wish, and then import again
<james_w> it should work nicely
<james_w> but the new branch will have absolutely no relation to the old one in bzr's eyes
<james_w> it sounds like that shouldn't be a problem for you though
<theuiguy> james_w:  no, that sounds like it would work... just cleaning up the email addresses would be great.
<theuiguy> Thanks!
<mathiaz> Hi - I'm using the loom plugin to manage one my packaging branch. The HOWTO outlines how-to combine a thread (case where the code has been merged upstream), but I don't get how to delete a thread (the code is no longer relevant because upstream fixed it differently). How do I delete a thread ?
<james_w> hey mathiaz
<mathiaz> If I try to combine a thread, it still shows up in the thread above
<mathiaz> james_w: Hi ! :)
<james_w> I believe that's the same thing
<james_w> you mean the code that you want to get rid of is still in the thread above?
<mathiaz> james_w: I'm working on an openldap merge and the debian maintainer fixed a bug using a different patch
<mathiaz> james_w: yes
<lifeless> mathiaz: you un merge it
<lifeless> mathiaz: go to the thread above and do bzr merge -r -1..thread:
<lifeless> erm no
<lifeless> go to the thread you want to cancel
<lifeless> then do that
<mathiaz> lifeless: ok - good to know for the next time. As of now, I've already combine the thread
<mathiaz> lifeless: so I guess I'll have to fix it manually
<james_w> you can resurrect the thread I assume
<james_w> hey lifeless
<mathiaz> also pushing the branch to LP doesn't work
<mathiaz> I get the following message: http://paste.ubuntu.com/32335/
<lifeless> hi james_w
<james_w> mathiaz: I think that's fixed if you update your loom plugin to a newer version
<mathiaz> james_w: I just did that
<mathiaz> james_w: that's when I started to see that message
<mathiaz> I'm at revision 86 for the loom pluging
<chadmiller> Hi all.  A bzr user in my group complains that "annotate" is much slower in 1.6b4 than in 1.5.  For his example file it goes from 19 sec to 645 sec.
<AmanicA> which branch format?
<AmanicA>  (bzr info)
<lifeless> ah damn I knew I'd forgotten something; get_matching_blocks acceleration
<lifeless> chadmiller: I'll whip up a patch today
<chadmiller> lifeless: Cool.  Thanks!
<rexbron> hey jelmer, I have a new problem related to the bug you looked at earlier
<lifeless> chadmiller: make sure he is running with the C extensions though
<lifeless> chadmiller: that will still matter even after my patch
<chadmiller> Okay.  I will.
<mwhudson> mornings
<beuno> goooooooood mornin' mwhudson
<thumper> beuno: morning
<thumper> beuno: I've been trying to marry the gnome-loggerhead with the new trunk
<beuno> hey thumper
<beuno> oh, cool, I was going to ping you about that
<thumper> beuno: with limited success
<cszikszoy> does anyone know what this error means: bzr: ERROR: Invalid url supplied to transport: "Host empty in: http://:8080/"
<beuno> thumper, that's odd
<thumper> beuno: I might push what I have and get you to look where it's screwing up
<thumper> beuno: we have mixed css
<cszikszoy> or possibly how to fix it?
<beuno> thumper, have you changes anything to it, or is it what I originally pushed?
<thumper> beuno: and I was trying to fit some loggerhead tabs into the gnome tab area
<james_w> cszikszoy: hi, what command did you run to get that error?
<thumper> beuno: there are changes
<thumper> beuno: but fairly limited
<beuno> thumper, ah, ok. If you can push or give me access to, I can resolve and re-push
<cszikszoy> bzr branch lp:do-plugins
<james_w> mathiaz: how are you finding using loom for packaging?
<thumper> beuno: I'll actually spend some time writing up what has changed as ISTR there was some heading hackery
<james_w> cszikszoy: oh, that's odd
<thumper> beuno: so you might get something in the next 8 hours
<thumper> beuno: but not too soon
<lifeless> cszikszoy: thats very strange
<mathiaz> james_w: well - up to now, I think it's ok - I classify it as yet-another-patch-system - but I like the merge help
<cszikszoy> i thought so too :)
<lifeless> cszikszoy: it means there is no hosy
<lifeless> *host*
<mathiaz> james_w: there are still some rough edges (such as unable to push to lp)
<beuno> thumper, cool.  Another thing you may want to try, is start from the gnome branch I pushed with the new theme, and merge into that one
<mathiaz> james_w: and I've just figured out how to delete a patch rather than combine it
<james_w> mathiaz: that's true, I guess it is another patch system, but hopefully a better one.
<mathiaz> james_w: hopefully there will such a command added to the loom plugin soon
 * thumper nods to what beuno says
<frej> hmm, i'm having problems with converting a cvs repo (cvsps) with filenames in latin1 encoding :/
<james_w> mathiaz: would you file a bug for that command?
<mathiaz> james_w: it seems that the difference comes with the merging support
<frej> is this supported in any wya?
<james_w> mathiaz: also, "bzr -Derror push" would be useful to find out why you can't push.
<lifeless> cszikszoy: cszikszoy it works for me
<lifeless> cszikszoy: could you file a bug please, with a transcript? file it on launchpad-bazaar
<mathiaz> james_w: there aren't many patch system that come with a proper merge support
<beuno> sounds like a proxy tweaking things, doesn't it?  8080 port seems fishy
<cszikszoy> i'm not behind any proxy that I know of
<cszikszoy> unless my isp blocks it
<cszikszoy> i'm in Germany, if it somehow matters
<cszikszoy> but i didn't think that it would
<james_w> mathiaz: yeah, hopefully it's a killer feature
<cszikszoy> i'll file a bug report, as for a transcript, what would be helpful to include?
<beuno> cszikszoy, can you re-run the command, and add  -Dhpss
<beuno> then, file the bug, attaching your  ~/.bzr.log   file
<cszikszoy> will do, thanks
<cszikszoy> n
<lifeless> I swear
<lifeless> time to update my fail filters
<jelmer> lifeless: 'morning
<lifeless> hi jelmer
<jelmer> lifeless: wrt backslashes - bzr will error out when trying to add a file with a backslash in the name
<lifeless> yes
<lifeless> this is deliberate
<lifeless> we also error on 0x01
<lifeless> and many other characters
<jelmer> you mention encoding - what sort of encoding?
<jelmer> (bug 81844)
<lifeless> you could urlescape it
<lifeless> (for instance)
<ubottu> Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid] https://launchpad.net/bugs/81844
<jelmer> lifeless: that means an opportunity for paths to clash
<jelmer> also, it means having to determine which paths were meant to be escaped when pushing back into svn
<jelmer> bzr-svn currently just checks for backslashes and raises an exception if it encounters them
<jelmer> which works pretty well, except that there are a few rare repositories out there that contain backslashes (the lintian one, for example)
<jelmer> lifeless: is there any reason to not support \ other than the fact it means it won't be possible to create a working tree on Windows?
<lifeless> so there are two groups of characters that we don't support: Those easy to support but undesirable; and those hard to support
<lifeless> things that won't go into xml cleanly, or are separate characters for our disk formats makeup thelatter group
<lifeless> For the former group, its mainly that they aren't really consistent with bring a sccs
<lifeless> they're more 'be a unix file system'
<lifeless> dunno
<lifeless> I don't really have a strong opinion
<james_w> http://technomancy.us/113
<lifeless> cool
<lifeless> jelmer: does the file id limit matter to you as well ( the \\ is banned in ids because it would break on windows with early stores)
<jelmer> lifeless: no, file ids are generated using a checksum if they contain certain characters or exceed a certain limit
<lifeless> ok
<jelmer> lifeless: the only two characters in filenames I'm aware of that are problematic when importing from svn are \ and newline
<lifeless> jml: bit strange to close 124570 if I can't actually use it yet...
#bzr 2008-07-31
<jml> lifeless: it's consistent with the announcement of Launchpad APIs.
<lifeless> jml: I don't understand
<markh> jam: so I'm looking at disabling auto-detection of plink as (I think :) everyone agreed.  This would means that source-code users who do not have paramiko, but do have pageant/plink setup will not work at all without setting BZR_SSH.  ie, we will "fix" plink users that don't use pageant at the cost of "breaking" users that use plink + pageant to manage their keys who work today.  Is that the intent?
<lifeless> markh: why disable plink?
<lifeless> (short answer is fine, I just missed the conversation)
<markh> plink is unable to correctly interactively prompt for a passphrase
<markh> it was disable plink *detection*
<markh> so setting BZR_SSH=plink would still allow it to work
<lifeless> have we filed a bug about that ?
<markh> but - the point I was making is that plink works fine is pageant is used (meaning plink doesn't *need* to prompt for the passphrase)
<lifeless> so can we detect plink+pagent vs plink w/o pagent ?
<markh> https://bugs.launchpad.net/bzr/+bug/107593 is the closest IIUC
<ubottu> Launchpad bug 107593 in bzr "bzr unable to ask password for access over bzr+ssh:// or sftp:// when plink.exe used as SSH client" [Low,Fix released]
<lifeless> markh: well I was meaning in the plink bugtracker :P
<markh> but the resolution to that was simply to pass a param to plink that stops it even *trying* to prompt :)
<markh> there is something funky going on with windows consoles
<markh> plink executed directly works fine
<markh> so we'd need more research to file a plink bug
 * markh idly wonders how a windows GUI app could hope for either ssh or plink to prompt for a passphrase...
<markh> so - I actually think the status quo is fine.  There is almost an expectation that BZR_SSH needs to be set, and I think the current plink default behaviour helps more people than changing it would.
<markh> and later we can see if we can convince plink to prompt like ssh, and everyone remains happy (except me with ssh.exe on my path, but I digress ;) )
<lifeless> markh: sounds fine to me
<lifeless> FWIW
<markh> cool - thx!
<markh> that was my last task for the binaries too (well, apart from releasing them and submitting changes upstream and working out what we do with them once I've uploaded them :)
<markh> the bzrsvn plugin isn't working that well, but I think there is still value to including it given we aren't trying to call it anything like stable/final
<lifeless> cool
<markh> heh - bzr just logged "...  readv() read unknown bytes rather than unknown bytes at unknown for "http:..." - obviously it doesn't know much about that error :)
<lifeless> jelmer: lol @ gloom
<poolie_> hello markh, lifeless
<markh> hi poolie
<jelmer> lifeless, (-:
<jelmer> lifeless, I hadn't realized the meaning of gloom in English
<fullermd> Now all we need is a command to Dump the Original Outside Metrics...
<matthew-_> so I come from a history of using monotone which I want to move away from, I've just discovered some behaviours with Hg that I don't like and wanted to check see what bzr does
<lifeless> hi
<matthew-_> but firstly, does bzr allow you to name branches?
<lifeless> yes, our model is that every branch is a directory on disk (we do support sharing the repository and having a single working tree that switches between branches)
<mwhudson> jelmer: :)
<matthew-_> lifeless: yeah, I get the model, I just wanted to see if you can give a name to a branch and then for example, switch to that branch just by going bzr update branchname
<lifeless> matthew-_: yes, 'bzr switch NAME' will look in $branch/../NAME
<matthew-_> ahh ok. so the name of a branch isn't meta data that's attached to a revision?
<lifeless> we store a nickname in revisions
<lifeless> but its used for bzr viz and other such reporting, not for switching
<lifeless> the nickname that will be stored defaults to basename(branchdir); but can be forced via 'bzr nick'
<matthew-_> ok, so if two people share the same set of revisions, they would have the same branch names for the same revisions?
<lifeless> uhm yes but I feel like we're not connecting somehow
<lifeless> we're not at all like hg in our treatment of branches
<matthew-_> no I think we are. It's just that mtn assigns quite a lot of semantics to branch names and I just want to see how much that's carried across
<matthew-_> yeah, you seem quite different to hg and mtn
<lifeless> we don't assign any semantic to branch names
<matthew-_> ok, so let me give you a scenario
<matthew-_> let's say I'm working on the mainline of my project and then I branch to start work on a new feature. My friend then wants to help me with this new feature. So how do I identify to him which branch he should switch to?
<lifeless> just tell him the url
<matthew-_> right, of course, the branch is reflected in the url
<matthew-_> I understand. thank you for your patience :)
<lifeless> happy to help, I'm here all day :)
<matthew-_> so my next question is the following. Say I've made some changes, but not committed
<matthew-_> I then do a switch to a different branch, or even just an update to a different revision
<matthew-_> what would the output of bzr diff be?
<lifeless> your uncommitted changes
<matthew-_> so it takes the diff from the current revision and then reapplies that diff to the new current revision?
<lifeless> well
<lifeless> the switch and update operations do a merge
<lifeless> a merge preserves edits (though they may conflict and if so you get conflicts as a result)
<matthew-_> ok, so I probably didn't mean either switch or update ;) How would I change my current directory to be of a different revision?
<lifeless> switch moves you to a different branch; so that your commits will go to it
<fullermd> Depends on how deeply you mean that...
<lifeless> (its the same as switch on svn/git)
<fullermd> 'revert' will change the contents (and layout, presence, etc) of the files to be like that revision.
<lifeless> update is used when you have a tree that is out of date with its branch
<fullermd> But your WT still considers itself to be at whatever revision you were previously at, so e.g. 'diff' will show a lot.
<matthew-_> ok, sorry, so many terms get reused between DVCSs and all with different semantics!
<lifeless> matthew-_: we've tried quite hard to be consistent with cvs/svn on these common commands, because they have market dominance - less relearning for bzr users
<matthew-_> ok, so from revision X I add one line to a file. Then I do bzr revert Y where Y came before X. Then bzr diff will show all of the changes necessary to go from Y to X and to add the extra line?
<matthew-_> lifeless: sure, I appreciate that. It's just I use neither :)
<fullermd> No, revert will blow away the uncommitted changes.
<lifeless> matthew-_: so you add one line
<lifeless> matthew-_: why do you want to change the revision the tree is at ?
<fullermd> Its main purpose is its name; 'revert this {file,dir,tree}'.  That you can specify 'to a given revision' is fruit on top of that.
<lifeless> matthew-_: (as in, whats the follow up operation you want to do)
<matthew-_> lifeless: say I've done an hour's work, without committing. I then realise that I'm on the wrong branch and I should commit to another branch, and thank goodness, I realise that the file I've altered is the same in both branches, so I should just be able to switch to the head of the branch I want, and commit there, without having to redo my work
<lifeless> matthew-_: 'bzr switch BRANCH; bzr diff' will show you just the work you've done
<lifeless> matthew-_: and it is switch you want, because you want to commit to a different branch
<matthew-_> ok
<igc> morning
<matthew-_> and what happens if the branch I switch to has altered the file I've worked on but in such a way that the diff still applies cleanly?
<lifeless> same
<matthew-_> right, so it doesn't just apply my changes, it leaves the whole file unaltered
<fullermd> It's a little smarter than just 'diff'.  It's more like if you committed the change, then merged it in the other branch.
<lifeless> matthew-_: no, it does a merge
<lifeless> matthew-_: so you only see your uncommitted work, transformed as needed by the merge
<matthew-_> ok cool
<matthew-_> ok, sorry, I have another question
<matthew-_> say I want to start a branch, but I want to start it from a particular revision
<bob2> branch -r /url /tosomewhere
<matthew-_> how do I get back to that revision in order to create the branch?
<bob2> er, -r nnn /url /tosomewhere
<lifeless> matthew-_: you don't need to go bac to the revision, you just need to give -r to the branch command, as bob2 says
<matthew-_> ugh, this is my problem. I'm used to mtn where you normally have a single working directory that you move all over the place, rather than lots of directories
<matthew-_> just a mental shift I guess
<bob2> sure, that is what 'bzr switch' is for
<bob2> create a repository somewhere, check out a branch from it.  want a new branch, 'bzr branch . ~/repository/somename', 'bzr switch somename'
<bob2> it is a trivial plugin to simplify that to 'bzr tbranch somename'
<fullermd> Or it could be a useful addition to 'switch'.
<bob2> yeah, I wasn't sure how to integrate it into the existing ui
<fullermd> '-c' to create the branch (based on the current by default) and -r to specify a revision to start it from (which could include branch: revspecs or the like to specify a different one)
<fullermd> (I don't say that's the best; just the most obvious)
<matthew-_> sorry, is there an ENV Var to set to force merge to use a nice tool?
<fullermd> I think there's a bzr plugin for meld...
<bob2> dunno, but unclean merges leave the 2/3 sources files on disk so you can use any merge tool you like
<matthew-_> err, I want to force it to use xxdiff
<matthew-_> it won't automatically fire it up for me somehow?
<fullermd> Well, the existence of meld is the extent of my knowledge of "nice tool"s for merge   ;)
<markh> jelmer: for some reason, bzrsvn is causing blackbox.test_check.ChrootedCheckTests.test_check_missing_branch to hang for me.  It stops hanging with --no-plugins, or if I manually remove just svn.  It seems to be reading from a socket, but I haven't dug any deeper.  Any clues?
<jelmer> markh: No, sorry. I would guess it's related to the custom log function bzr-svn registers
<matthew-_> ahh, extmerge is clearly what I want http://erik.bagfors.nu/bzr-plugins/extmerge/
<jelmer> markh, seems strange it would hang in a socket operation though
<spiv> matthew-_: you can also do "bzr diff --using xxdiff" I think
<jelmer> markh, if you comment out the custom log code in __init__.py:160, does that fix it?
<markh> that was just a very quick break into the debugger with no symbolic info...  I'll try and repro it from a source version
<markh> apparently not :(
<jelmer> markh, where is it hanging then?
<markh> sorry - commenting 160-163 had no effect
<markh> bugger - source version is failing that test with an earlier pycurl error.  I'll dig a little and see what i find.
<jelmer> this is probably related to the bug spiv filed
<jam> markh: I think the chance of someone using bzr +plink without paramiko is vanishingly small, and shouldn't be optimized for
<jam> paramiko is about 90% away from a "requires"
<jam> Especially if you are writing an installer
<jam> we would bundle it
<jam> So I think moving the plink autodetect to *after* paramiko is fine
<markh> jam: I'd say the chance of someone using passphrase protected keys with plink on their path but without pageant is approaching zero too.
<matthew-_> ahh, so visualise doesn't show all heads of all branchs in the current repo. It just shows the head of the current branch
<jam> markh: well, if pageant would find the keys for me, I might actually use it :)
<markh> sure - but as you dont it will not be on your path, so no problem :)
<jam> matthew-_: ATM, I think there has been work to allow it to show more heads
<jam> markh: agreed, no problem
<jam> the problem with plink isn't with keys
<markh> (otoh, I think its reasonable it *may* be on your path, likes its reasonable ssh may be on mine, which is why I think paramiko is a better default, but I think we've done that already ;)
<jam> it is that you can't prompt for *any* password
<jam> markh: so with plink you can't access a password-protected page
<jam> but you *can* with paramiko
<markh> right - paramike seems to have everything going for it ;)
<jam> over plink, yes
<jam> over ssh, no
<jam> at least IMO
<jam> you can't really configure plink to use a config
<jam> without passing in a command line option
<jam> you *can* for ssh
<fullermd> matthew-_: vis can show multiple branches at a time, but normally it just shows your current branch.
<markh> I think we should wait for the "bug" reports before making things more convoluted. At least the status-quo of "we try and find known ssh vendors on your path, or fall back to paramiko" is easy to explain, and as you point out, setting BZR_SSH isn't hard either - especially when "fixing" plink and/or paramiko to overcome the limitations we are discussing would also change the "best" defaults IMO.
<jam> jelmer: just to mention, you probably shouldn't do "getattr()" on the plugins, but try a "try import except ImportError"
<jam> Because you don't know that loom will be imported *before* gtk
<lifeless> jam: hi
<jam> hi lifeless
<lifeless> jam: did you change mail client a month or so back?
<lifeless> you seem to be quoting much more than you used to
<jam> lifeless: still using T-bird, why?
 * igc lunch
<jam> probably just depends on my mood
<lifeless> its a little weird to quote 40-50 lines to reply with 7
<lifeless> IMNSHO
<markh> jelmer: it appears to be in SvnRemoteFormat._open
<markh> then calling into ra.pyd, which presumably is remote.SvnRemoteAccess
<jam> lifeless: It would be weirder if I edited *some* of the message but left the rest
<jam> in this case I just hit reply
<jam> and replied
<jam> better than top-posting, IMO
<lifeless> lol.. ok
<lifeless> I just thought I'd mention it, because I've had a feeling of wading through quotes to try and find your comments recently
<jam> I'll try to be a bit more terse
<jelmer> jam, thanks, fixed now
<lifeless> its not a big deal
<matthew-_> ok, I'm confused, again!
<lifeless> matthew-_: shoot
<matthew-_> if I do init-repo --no-trees repo; init repo/trunk; co --lightweight repo/trunk trunk; cd trunk
<matthew-_> then commits get sent to repo/trunk
<lifeless> yes
<matthew-_> so it would appear that it's bound to the repo
<matthew-_> but unbind says it's not bound to anything
<lifeless> hmm, bit of plumbing exposed here
<lifeless> so the --lightweight option means that 'trunk' has no branch object
<jelmer> markh: So it's probably attempting to open the path specified as a subversion repo
<lifeless> 'bound branches' are what you get if you omit the --lightweight parameter
<jelmer> markh: I wouldn't know why that would cause a hang though
<matthew-_> ok
<matthew-_> so why is there no --lightweight option to branch?
<lifeless> 'bound branches' are a way to emulate cvs/svn's tree facility while still having full local history
<matthew-_> yes, I understand that
<markh> jam: your last mail said you yourself stick cygwin\bin on your path, and given ssh-agent is almost impossible to use for mere-mortals on Windows, I'm surprised you think it is the "extreme minority" case that people will have an ssh.exe on their path even though they use pageant to manage their keys and use ssh.exe rarely, if at all.  But I guess we just have to agree to disagree :)
<jelmer> markh, what specifically is it hanging on?
<jelmer> file handle?
<matthew-_> because, in trunk, say I do a branch . ../mybranch; cd ../mybranch; nick mybranch
<jam> markh: well, *I* want to use ssh.exe
<lifeless> matthew-_: well, because branch makes a new branch object. We could possibly do --lightweight; however there is a command in bzrtools that you may like
<matthew-_> I then want commits to go to repo/mybranch
<jam> markh: that is why I put it in my path
<lifeless> matthew-_: alled 'cbranch'
<lifeless> matthew-_: well, you probably want to do 'bzr branch repo/trunk repo/mybranch' bzr switch mybranch
<markh> jam: I fully understand that, but its just I'd think *you* are in the extreme minority for a windows developer in this regard ;)
<markh> I want to use various cygwin tools - that's why its on my path
<jam> markh: I think the effort to put things in your path means you want them there
<matthew-_> lifeless: ahh! brilliant, thank you
<markh> and I'm not so careful to remove every tool I don't currently use
<jam> I think for *real* windows developers, they don't use cygwin
<lifeless> matthew-_: broad description - you want all your branches as repo/BRANCHNAME
<lifeless> and you want one lightweight checkout somewhere else
<markh> I don't use *everything* in my cygwin dir directly - but lots of build processes do.
<lifeless> switch in that checkout will accept just BRANCHNAME
<lifeless> most other commands want a longer relative or absolute path
<matthew-_> lifeless: right. this is closer to the mtn model I'm used to than I thought
<lifeless> this is a bug - the logic for switch just needs to be hooked into these other commands
<markh> jam: is that because they don't understand them, or have alternatives for everything cygwin provides?
<lifeless> matthew-_: is that good or bad ? :)
<markh> all windows developers I know use them!
<matthew-_> good, for me ;)
<lifeless> cool
<markh> I'd go so far to say "any windows developer who regularly uses the command prompt would use them".  My concern is that includes our "target" developer, particularly in the early days until the GUIs get better.
<markh> s/any/many/ ;)
<matthew-_> lifeless: ahh, but it doesn't seem to like switching when you have divergence
<markh> jelmer: sorry - it seems to be reading a socket, but I've not got symbolic info for the svn binaries
<matthew-_> I don't want to merge. I just want to change my lightweight checkout to a different branch
<lifeless> spiv: http://rafb.net/p/0xKkTQ77.html
<lifeless> matthew-_: thats what switch does
<lifeless> matthew-_: what is happening
<matthew-_> but it tried to do a merge. I was ci'd and everything
<markh> top of the stack is ntdll.dll, then below that is mswsock.dll, and below that ws2_32.dll, so that sure smells like a socket :)
<lifeless> matthew-_: the machinery of merge is whats used
<lifeless> matthew-_: so thats not surprising. Tell me what happened though
<jam> markh: I can agree with that, and if pageant +plink wasn't so crummy I would be fine putting paramiko first
<jam> but as it stands
<jam> pageant can't find a ssh-key
<jam> unless you add it every time you boot
<jam> whereas ssh.exe can find it in its "standard" location
<matthew-_> ok. so I added a file with some lines and ci'd. Then I branched. Then, still in trunk, I added some more lines, ci'd. Then I switched to the new branch, added further lines (creating devergence) and ci'd. So far so good
<matthew-_> then I switched back to trunk and it tried to merge
<matthew-_> which I didn't want
<lifeless> matthew-_: what do you mean by tried to merge ?
<jam> matthew-_: you might be confused by the progress bar
<jam> it shouldn't merge the changes
<lifeless> (I use switch with diverged branches *all the time*)
<jam> just uses the "merge" logic to safely reset your tree
<matthew-_> no, I got file.THIS, file.OTHER, file.BASE
<lifeless> matthew-_: did it leave the wrong content in your tree?
<matthew-_> yes
<jam> matthew-_: hm... I haven't seen that
<lifeless> ok, run bzr st
<lifeless> do you have pending merges?
<markh> jam: and you use ssh-agent, correct?
<matthew-_> err, I hit bzr revert in order to tidy up the mess ;)
<jam> markh: occasionally, but not all the time
<matthew-_> let me try again
<jam> the problem is you can't get it to start at the beginning
<jam> so I just type my password a lot
<jam> but if it couldn't find the key, then I couldn't connect to LP
<jam> at one point I had a hacked up startup script
<jam> that would check if ssh-agent was started
<jam> if not, start it, and save the env vars
<jam> so the next bash shell would re-use it
<markh> jam: right - and as paramiko can prompt for passphrases, your only practical issue with paramiko being the default is that HOME is set differently in a cygwin environment than a "normal" one, so the same keys aren't found by paramiko?
<jam> but then the prompt would hang when you exit, etc
<matthew-_> lifeless: I didn't nick the new branch. is that important?
<matthew-_> it's just the path that's important right? not the nick?
<lifeless> matthew-_: not important
<jam> markh: well, and when I *do* use the agent I can't with paramiko
<jam> and pageant being worse...
<matthew-_> ok, I must have done something wrong. It is behaving as you describe. sorry, my fault.
<markh> I certainly understand where you are coming from - I guess the question is - who is in the smallest minority, as they should probably take the "pain" of setting BZR_SSH.  So we are back to agreeing to disagree about who that is ;)
<lifeless> matthew-_: I would wager you had uncommitted changes that conflicted
<markh> I'd say ssh-agent is such a world of hurt that its use is absolutely tiny - you are the first person I've ever met who uses it on windows.  I understand why you do though.
<mwhudson> jelmer: here-p?
<jelmer> mwhudson: Hello
<mwhudson> jelmer: thumper would like to talk to you :)
<jam> well, even if you explicitly install cygwin, you have to install openssh as well
<thumper> jelmer: hi
<thumper> jelmer: we're talking about bzr-svn
<jelmer> mwhudson, He's too shy to say that himself ? :-)
<jelmer> thumper, hi!
<markh> jelmer: I can probably extract more of the stack trace if you are interested?
<thumper> jelmer: and when the version 4 mapping will be available
<markh> python stack trace
<mwhudson> we're doing the 'bzr-svn for code imports' conversation again
<jam> well, plink is far worse than ssh.exe
<thumper> jelmer: I was trying to get mwhudson to be the typer
<matthew-_> ok, thanks very much for all your help. I think I shall be using bzr from now on :)
<jam> regardless the agent
<jml> but this time we are all in a room!
<thumper> jelmer: except you
<mwhudson> jml: irc has rooms, right?
<jelmer> markh: yeah, that would probably be useful
<markh> we agree about how poor pageant is in those cases - just seem to disagree how many people use it over ssh-agent anyway :)
<jelmer> Heh
<jelmer> So it may be a good idea to list what mapping version 4 is going to be exactly
<lifeless> matthew-_: cool
<thumper> yeah, something like that
<jelmer> It's mainly about supporting the storage of bzr metadata in revision properties
<jelmer> and removal of branching schemes
<thumper> ok
<jelmer> and whatever happens to be around by the time it's put out
<thumper> jelmer: and this would be when?
<lifeless> jml: I am still confused about this xmlrpc thing
<lifeless> spiv: can you tell me if that test looks plausible to you
<thumper> lifeless: it is a way to call methods on a remote machine :)
<jelmer> Hopefully 0.4.11 + 1 or 2 months
<jml> lifeless: So, we've published the requestMirror method over Launchpad APIs. The client library (and documentation) isn't released yet.p
<jelmer> (0.4.11 is intended to be released together with bzr 1.6)
<lifeless> jml: so the bug isn't fixed - I as a user can't use it yet
<lifeless> jml: if I could, I could patch bzr's launchpad plugin to let 'bzr push' trigger a mirror
<jml> lifeless: the bug is fixed in Launchpad Bazaar.
<lifeless> so where is it not fixed, can we add a task on that
<jelmer> most of the other possible candidates for inclusion in mappingv4 rely on changes in bzr core
<jml> lifeless: Launchpad. If you add a task, I'll have to mark it as a duplicate of whatever bug is releasing the client API.
<jelmer> for the list, see https://bugs.edge.launchpad.net/bzr-svn/+bugs?field.tag=requires-mapping-upgrade
<lifeless> I think you are saying 'jml has no more code to write to make this work', which is fine; I'm saying 'I want the bug to be marked closed when I can use it'
<markh> jelmer: see /msg
<wgrant> How can I convince bzr to not attempt bzr+http? It seems to be disagreeing with SourceForge's Subversion server.
<jelmer> wgrant, svn+http://
<wgrant> jelmer: Aha, thanks.
<jelmer> wgrant: although it should work even if there's no bzr server remotely - what error are you getting?
<wgrant> jelmer: It's SF's fault:
<wgrant> Connection error: while sending POST /svnroot/ivle/trunk/.bzr/smart: (104, 'Connection reset by peer')
<matthew-_> is there some way to get bzr to show you all the branches in a given repo?
<matthew-_> or do you just tend to do an ls and assume the same layout model?
<bob2> matthew-_: bzr branches
<lifeless> bzr branches PREFIX
<lifeless> matthew-_: but yeah, I use shell tab completion :P
<matthew-_> ahh, it needs the path to the repo. ok, thanks
<lifeless> matthew-_: repositories are purely storage otimisation
<matthew-_> indeed
<lifeless> matthew-_: they aren't part of the semantic of commands
<spiv> lifeless: that does look plausible, yeah.
<wgrant> jelmer: It seems that SF is just very broken at the moment. Sorry for the noise.
<matthew-_> ok. so with mtn I wrote the tab completion for branches and there you have an attached repo, which is a sqlite db
<jelmer> wgrant, they sent out an email announcing downtime for ~12 hours
<jelmer> wgrant, apparently work on performance improvements
<wgrant> It has been ridiculously slow for a couple of weeks.
<wgrant> Minutes to commit a trivial change.
<jelmer> *.nz: Still there?
<jml> jelmer: yes.
<matthew-_> oh, branches can't be nested?
<thumper> jelmer: we're talking again
<mwhudson> jelmer: sorry
<thumper> jelmer: I think I'm pretty much done, I was just wondering about timings
<bob2> matthew-_: as in /repo/a and /repo/a/b are branches? they can.
<lifeless> matthew-_: yah. One reason we use regular directories is to allow standard toolchains like bash, nautilus etc to all be useful directly
<matthew-_> sorry, I'm an idiot. I created the branch and forgot to switch to it
<lifeless> :P
<jelmer> thumper: Within one or two months after bzr 1.6 is released I think
<jelmer> The main thing left to be done is tests for the upgrade from v3 to v4 mappings
<thumper> jelmer: ok, thanks
 * jelmer gets some sleep
<matthew-_> another question, with mtn, you commit locally, then sync with your shared repo across the network. syncing is both push and pull but does that for all branches at the same time. How would you do this for bzr? Do you have to do a push and pull for every branch?
<matthew-_> ahh ignore that, I've found repo-push
<lifeless> matthew-_: indeed; this is one of the things in mtn that is clever but doesn't work that well IMO
<lifeless> matthew-_: because you can't keep a private branch due to it always doing a full sync; the network sync logic depends on a full convergence for performance
<fullermd> The result is that I've ended up doing horrible hacks like having 2 mtn repos and very carefully crafted setups to have the private branches   :|
<lifeless> fullermd: or use bzr :P
<fullermd> Well, I do that where possible   :p
<fullermd> I'm waiting for Samba to move to mtn, so jelmer writes bzr-mtn...
<lifeless> cjwatson: ping
<jam> fullermd: doesn't mtn allow you to slightly modify history, by attaching a new certificate?
<lifeless> jam: annotate history I would say
<jam> not so much modify, as annotate/extend
<fullermd> Well, that's how you merge [propogate], but...
<bob2> matthew-_: there is a 'repo-push' plugin
<jam> bob2: yeah, he mentioned it already :)
<bob2> bah, oops
<jdobrien> any idea why a selftest run with -q would have different results than -v
<jdobrien> my blackbox tests has 3 tests...with -v (failures=2) with -q (failures=3)
<Odd_Bloke> jdobrien: That suggests that there's something wrong with the blackbox tests.  How are you invoking bzr?
<lifeless> jdobrien: interesting
<jdobrien> Odd_Bloke: ./bzr selftest RelativePathStatus
<jdobrien> this is a new set of blackbox tests
<jdobrien> there are 3 tests in all
<jdobrien> 2 are expected to fail
<jdobrien> (failures-2) when ./bzr selftest RelativePathStatus
<jdobrien> (failures=3) when ./bzr selftest -q RelativePathStatus
<jdobrien> why i am using -q with only 3 tests is related to my laziness :-)
<lifeless> jdobrien: I've never used -q with selftest
<lifeless> jdobrien: you'll need to debug the failure that is caused
<jdobrien> indeed
<jdobrien> lifeless: indeed
 * meteoroid just started a new project using svn and populated it with bzr-svn
<mwhudson> beuno: still awake?
<beuno> mwhudson, yeap
<mwhudson> so i'm looking at fix_setup
<mwhudson> and seeing some things that don't appear to make heaps of sense
<mwhudson> like
<mwhudson> class InstallData(install_data):
<mwhudson>     def run(self):
<mwhudson>         install_data.run(self)
<lifeless> mwhudson: ping; what do you know about buffer objects ?
<mwhudson> lifeless: as in 'things returned by the buffer() builtin' ?
<lifeless> http://python.active-venture.com/api/bufferObjects.html
<lifeless> PyBufferProcs
<mwhudson> oh that
<beuno> mwhudson, ah, right.  THat used to do more things, but then I moved it around. I left if as-is because I wasn't sure how complex the installer will get
<beuno> (doesn't jsutify it, just explains it)
<mwhudson> beuno: i think i'd call yagni for now
<mwhudson> beuno: also, there are both unecessary and missing imports
<beuno> distuils leftovers?
<mwhudson> lifeless: i know some stuff, what do you want to know?
<mwhudson> beuno: yeah
<mwhudson> beuno: and missing the import of bzrlib.errors
<lifeless> mwhudson: well, we do a lot of parsing
<lifeless> mwhudson: I'm wondering if we can use buffer objects to expose the raw data we have (which starts out as a python string because we get it over a transport) as a string, without causing a mem copy
<beuno> mwhudson, ok, I'll fix that.  I'm also tempted to add an uninstaller, and move the dependency-checking to somewhere we can re-use
<lifeless> PyStringFrom* copies AFAIK
<mwhudson> beuno: i think the ultimate installation thingy is going to be 'apt-get'
<mwhudson> beuno: so i wouldn't bother too much with an uninstaller
<lifeless> beuno: I suggest you don't do dep checking or uninstallers
<mwhudson> lifeless: you can't export it _as a string_ without copying
<lifeless> beuno: because they will both break badly, routinely, and you'll be in the job of writing a build tool
<mwhudson> (PyString's own their buffers)
<lifeless> mwhudson: something implementing the string protocol then, and as fast. ;)
<beuno> mwhudson, I agree, and jelmer has already packaged it, and is waiting for a release
<lifeless> beuno: two reasons not to do dep checking - installation is orthogonal to execution
<beuno> lifeless, makes sense. I may of been a bit over-cautious since dependency used to be a bit hell-ish
<lifeless> beuno: and it can be problematic to do well anyhow
<mwhudson> lifeless: maybe
<lifeless> mwhudson: top level goal:
<lifeless> actually, it starts out as the output from zlib.decompress()
<beuno> ok, so, remove dependency checking, fix sloppy imports, and remove un-needed class
<mwhudson> beuno: right
<lifeless> which happens to be a python strign because we use pythons zlib wrapper; but we could change that
<beuno> I may even do it now. DebConf is starting, and I'm housing Debian Developers at my place, so I can't do anything else  :)
 * beuno fires up vim
<mwhudson> heh
<lifeless> mwhudson: top level goal: take a 20MB region of memory, and iterate over a couple thousand full texts which have been compressed into that region
<lifeless> do that as quickly as possible
<mwhudson> lifeless: it sounds like buffer objects might help there
<mwhudson> how do you find the fulltexts?
<lifeless> the iterator needs to expose a few things, the key of the text, the sha1 (which we validate by sha1ing the fulltext when its extracted)
<lifeless> each full text is a obtained by processing a recipe contained within the region of memory
<lifeless> a recipe is a series of control codes; one code is 'insert', the other is 'copy'
<lifeless> copy references bytes from earlier in the region
<lifeless> insert embeds new bytes for the fulltext inline in the control data
<mwhudson> lifeless: "hmm"
<lifeless> so I can generate the sha by feeding the bytes referenced through a sha object, and giving them to the user at the same time; but there is no need to copy them them (the cost of copy is not the memcpy; its the allocation overhead)
<mwhudson> it seems that you can feed buffer(bigstring, start, stop) objects into sha
<lifeless> ok
<mwhudson> i wouldn't be _entirely_ certain that this won't end up being copied in the sha code
<mwhudson> but i'd hope not
<lifeless> it shouldn't be
<lifeless> is buffer() available in 2.4?
<mwhudson> (and you can tell my hard drive died fairly recently, i don't have the cpython source here)
<mwhudson> buffer() is pretty seriously ancient
<lifeless> also, this is for an extension module
<mwhudson> any python released in the last ten years or so should be ok
<lifeless> I don't care if the python version is _fast_, rather that its _clear_
<mwhudson> er
<mwhudson> then i don't entirely understand
<lifeless> :)
<mwhudson> (probably because my brain has about the consistency of blancmange by now)
<beuno> mwhudson, tweaked and pushed
<lifeless> here, have some red spraypaint
<mwhudson> but on the one hand you care about speed and on apparently the same hand you don't?
<lifeless> mwhudson: do you know the bzr policy for extension modules?
<mwhudson> lifeless: yes, so you're talking about things like patiencediff_py vs patiencediff_c ?
<lifeless> yes - we keep a python implementation for things we write extension modules of;
<lifeless> the python implementation focuses on clarity and being easy to debug in the effect that something needs analysis
<lifeless> the C/pyrex version focuses on being the fastest possible implementation
<mwhudson> so where do you want to use buffer objects for efficiency?
<lifeless> in the C/pyrex version
<mwhudson> ah
<lifeless> e.g. we might even look at have a prefixed instruction-count length so we could preallocate the right length instruction object count and so on
<mwhudson> so you'll be doing PyImport_ImportModule("sha") &c ?
<lifeless> the sha part is not important to our discussion
<lifeless> it was an example of where I know how to do zero-copy already
<mwhudson> ah
<lifeless> though being able to do it with roughly python code is easier ;P
<mwhudson> so i guess a buffer object is basically a pyobject header, a char* and a pair of indexes
<mwhudson> and some implementations of sequence methods
<mwhudson> but if you're writing c already, i'm not quite sure why you'd want it
<lifeless> mwhudson: because its smaller than strings, and less memory writes are good; because I can probably work up a array allocatable version of it so we can alloc an array and do in-place initialization etc
<mwhudson> lifeless: but i guess don't know why you'd use buffer objects over just passing pairs of ints around in your code
<lifeless> mwhudson: because the code exposes an iterator to random python usage
<lifeless> 14:06 < lifeless> mwhudson: top level goal: take a 20MB region of memory, and iterate over a couple thousand full texts which have been compressed into that region
<mwhudson> lifeless: _ah_
<mwhudson> lifeless: wasn't clear there that the client of the code was python
<mwhudson> (to me)
<lifeless> thats ok
<lifeless> unclarity FTW
<mwhudson> :)
<mwhudson> so yes, having your iterator return buffer objects would appear to make sense
<poolie> lifeless: i think you or abentley told me the other day you thought autopacking would fail on a stacked repositoyr
<poolie> my test for that is not failing
<lifeless> poolie: cool
<poolie> i'm going to poke at it a bit more and make sure it's actually exercising it properly
<lifeless> autopacking and packing should behave the same
<poolie> i'm just changing a one line file and maybe that's always storing fulltextst therefore not relevant
<lifeless> so you don't need to fiddle the code to trigger an auto pack boundary
<lifeless> the easiest test would be
<lifeless> one (say 10-line) file
<lifeless> branch --stacked
<lifeless> commit a line line change
<lifeless> run pack
<poolie> sure
<poolie> that's what i'm doing
<mwhudson> lifeless: so i expect the python code will probably have to be a little careful to avoid effectively converting the returned buffers into strings and so copying the data anyway
<lifeless> poolie: that *could* be creating a fulltext
<lifeless> so a more sophisticated test
<poolie> mm
<lifeless> base branch, 10 line file
<lifeless> branch stacked
<lifeless> in the base branch commit a 1 line change
<lifeless> scratch that
<lifeless> in a third branch made from the base
<lifeless> commit a 1 line change
<lifeless> then pull the third branch into the stacked one
<lifeless> that should guarantee a delta
<lifeless> then pack
<lifeless> igc: you have mail heading your way; its a little brief sorry - I'm fighting some sinus thing this week, got a permanent headache :(
<mwhudson> beuno:
<mwhudson>     cmdclass={'install_data':install_data}
<mwhudson> that's not doing anything, right?
<beuno> mwhudson, it *should* run install_data
<mwhudson> but what that does is change the install_data command to run ... the default install_data command
<mwhudson> i think
<mwhudson> i guess i should test it :)
<beuno> it's the first time I've fiddled with distutils, so I'm not 100% sure on anything  :)
<beuno> hm, it doesn't seem to do anything after all...
<markh> yeah, that overrides how 'install_data' is run - but doesn't force that cmd to be run
<markh> you probably also need data_files or something
<beuno> markh, ah, it makes sense now
<beuno> thanks  :)
<markh> np :)
 * beuno removes, commits, pushes
<beuno> it makes a lot of sense actually
 * beuno 's lightbulb just lit
<mwhudson> beuno: oh, i made some tweaks of my own and merged the branch
<mwhudson> beuno: i guess we should see if we made the same changes :)
<beuno> mwhudson, heh, right.  I'm just happy to scratch one more release-critical bug off the list
<mwhudson> well, i removed the import too
<beuno> ok, yours was better then  :p
<mwhudson> beuno: bug 242270 would be nice
<ubottu> Launchpad bug 242270 in loggerhead/1.6 "Directory listing page doesn't use a template" [High,Confirmed] https://launchpad.net/bugs/242270
<beuno> mwhudson, that's next on my list
<mwhudson> beuno: awesome
<beuno> I just wanted to get the setup thing out of the way before it found more victims
<mwhudson> sure
<mwhudson> thanks for that!
<beuno> happy to do it  :)
<beuno> are the current bugs filed for 1.6 reasonable to release, or is there something else you want in on this cycle?
<beuno> we should probably wait for bzr 1.6 to release, for starters
<mwhudson> just looking
<mwhudson> well yes, there's the weave_store/not weave_store thing
<beuno> ah, right
<beuno> I'll file a bug for that
<jdobrien> *
<beuno> I was planning on trying one method, and if it failed, default to the 1.6-compatible one.  We can probably remove that after a few releases
<mwhudson> beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/242806
<ubottu> Launchpad bug 242806 in loggerhead "log rotation actually doesn't save old logs (it truncates them)" [High,Confirmed]
<mwhudson> probably should be investigated
<beuno> true
 * mwhudson nominates
<mwhudson> beuno: isn't https://bugs.edge.launchpad.net/loggerhead/+bug/243420 fixed now?
<ubottu> Launchpad bug 243420 in loggerhead "Link to removed file in changelog tracebacks" [High,Confirmed]
<Peng_> I thought you just took out the link.
<mwhudson> right
<mwhudson> which seems to fix the bug :)
<beuno> mwhudson, yeap yeap
<lifeless> FWIW I think running with just current bzr is fine
<lifeless> because the older loggerheads are still available
<poolie> exclennet
<poolie> or however you spell it
<poolie> that does make it fail
<mwhudson> beuno: what's the story with https://bugs.edge.launchpad.net/loggerhead/+bug/248018 ?
<ubottu> Launchpad bug 248018 in loggerhead "slow search results override fast ones" [High,Confirmed]
<poolie> lol
<Peng_> Fully fixing the bug would mean having a functional link.
<poolie> they must be more important, i worked so hard on them? :)
<beuno> mwhudson, that's javascript-related
<mwhudson> beuno: should i nominate it for 1.6?
 * jdobrien head drops on his keyboard...........................
<Peng_> IMO, adding a functional link is low priority, but should be done before closing the bug.
<lifeless> oh yeah
<lifeless> mwhudson: beuno: did you consider my patch for sqlite3 bindings?
<lifeless> python-sqlite is older and slower :)
<beuno> mwhudson, yeah, it shouldn't be more than a few hours work
<beuno> lifeless, you made a patch for that?
<mwhudson> lifeless: i keep losing that
<mwhudson> beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/237914 ?  would be nice-to-have
<ubottu> Launchpad bug 237914 in loggerhead "please provide downloadable and applicable diffs" [Medium,Confirmed]
<beuno> either way, I have something half-baked that will use ajax to bring changed files on request, which may let us eliminate the cache completely
<lifeless> http://bazaar.launchpad.net/~lifeless/loggerhead/squid3/revision/153
<beuno> mwhudson, it would.  I've already had to ge diffs manually for people wanting them from LH  :)
<beuno> lifeless, I'll apply the patch now
<beuno> it's a no-brainer
<lifeless> probably need to update some other docs etc
<lifeless> about what packages are wanted
<beuno> yeah, although it's optional now, and I'm obsessed with getting rid of it
<lifeless> concretely python-pysqlite1.1 is what my patch offers IIRC
<mwhudson> i think there have been some loggerhead bugs reported against launchpad-bazaar since the theme rollout
<beuno> lifeless, trying for the other sqlite versions doesn't make sense anymore then, doesn't it?
<beuno> http://bazaar.launchpad.net/~lifeless/loggerhead/squid3/annotate/153?file_id=changecache.py-20061220030353-d5l6vj7xp2vff655-1
<mwhudson> but i'm hilariously far behind on my bug mail
<beuno> mwhudson, there have
<beuno> I assigned them to me
<mwhudson> beuno: did you add loggerhead tasks?
<beuno> they are all simple to fix, and generally wishlists
<lifeless> beuno: well the point is that sqlite3 is better than sqlite2 :)
<beuno> mwhudson, let me check, I think so
<mwhudson> beuno: ok :)
<lifeless> jml: so back to the xmlrpc to mirror a branch; should I open a task on launchpad ?
<jml> lifeless: no.
<lifeless> or am I just not making sense to you
<beuno> mwhudson, they where filed to LH in the first place  :)
<jml> lifeless: you are making sense to me, but opening a task isn't going to help.
<mwhudson> beuno: oh good :)
<lifeless> jml: so there is nowhere to track the further progress of this?
<jml> lifeless: https://blueprints.edge.launchpad.net/launchpad/+spec/api-python-library
<lifeless> ok, I've linked the bug report
<beuno> mwhudson, is #156453 ready to be closed?
<mwhudson> bug 156453
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Confirmed] https://launchpad.net/bugs/156453
<mwhudson> beuno: no, we still have problems in production :/
<beuno> :(
<beuno> mwhudson, btw, has the new theme changed anything in performance?
<mwhudson> beuno: not so that i've noticed
<mwhudson> i haven't checked at all mind
<beuno> it generates smaller files, so it uses less BW and does it faster
<beuno> ok, I suppose that if it didn't slap you in the face then it's not significant at the very least
<beuno> mwhudson, what about bug 156599 ?
<ubottu> Launchpad bug 156599 in loggerhead "need documentation on how to run loggerhead under apache" [Undecided,New] https://launchpad.net/bugs/156599
<mwhudson> beuno: hmm, i'm not sure about that
<mwhudson> there's some stuff in readme, i think, there could probably be more
<beuno> ok, so maybe we should confirm it as wishlist
<mwhudson> sounds good
<beuno> and the last one, I thing bug 246764 is not possible with bzr at all
<ubottu> Launchpad bug 246764 in loggerhead "Recreate "Download a Directory" feature" [Undecided,New] https://launchpad.net/bugs/246764
<beuno> and I don't want to do anything LH-specific about that
<beuno> just want to check with you before I invalidate it
<lifeless> beuno: exporting a subtree sounds useful
<beuno> lifeless, it is. How would we do it?
<lifeless> export
<mwhudson> beuno: i think it should be wishlist
<mwhudson> beuno: and edit the summary to not say "recreate" :)
<lifeless> beuno: bzrlib.export.export with a tree object
<lifeless> beuno: all it needs is a tree decorator that gives you 'doc' as the root rather than '/', for instance
<beuno> ok, if you make it sound that simple it makes me feel bad to not do it
<beuno> lifeless, is there a reason we can't do that right now in bzr?
<lifeless> beuno: none at all
<beuno> ok, so it would make sense to try and get a patch into bzr, and work on top of that
<lifeless> we could also tweak the exporter protocol to accept a limit parameter
<lifeless> rather than using a decorated tree; I don't have an opinion about which is better
<lifeless> yes, a bzrlib patch would be good
<beuno> I'll dive into it when I get to bug 240580
<ubottu> Launchpad bug 240580 in loggerhead "Ability to download a tarball for a revision" [Undecided,Confirmed] https://launchpad.net/bugs/240580
<beuno> and see which one produces cleaner code, etc
<lifeless> should be the same thing :)
<beuno> (which approac)
<beuno> approach
<beuno> well, one we can do now, the other needs bzrlib tweaking
<beuno> but yes
<mwhudson> beuno: you managed to commit a conflict marked to README on trunk :)
<beuno> mwhudson, what?  how!?
<mwhudson> +<<<<<<< TREE
<lifeless> beuno: strictly speaking it doesn't need a bzrlib tweak; its just that the tweak /can/ go into bzrlib ;P
<mwhudson> only one part of it though
<beuno> mwhudson, you mean NEWS?
<mwhudson> ah
<mwhudson> beuno: yes, sorry
<beuno> argh, yeah
<beuno> mwhudson, mind if I uncommit --overwrite?
<mwhudson> beuno: sounds appropriate
<Peng_> I already pulled it, I think.
<Peng_> Never mind; I haven't.
<lifeless> quick quick pull it
<beuno> Peng_, really??  it was like 5 minutes ago!
<beuno> Peng_, pull --overwrite then  :)
<beuno> oh, codebrowse is actually scanning in *minutes* instead of hours now
<beuno> lol
<Peng_> beuno: Yeah, I hadn't, but I have now, but that's no problem.
<beuno> Peng_, I already uncommitted and pushed
<Peng_> Yeah, you have *now*.
<mwhudson> beuno: yeah, we fixed the scanner some more
<beuno> mwhudson, neat. That should drop confusion for new people pushing code by 80%!
<mwhudson> and foundhttps://bugs.edge.launchpad.net/bzr/+bug/252481
<ubottu> Launchpad bug 252481 in bzr "readonly, chrooted, http transport fails to be smart about readvs with many ranges" [Undecided,New]
<mwhudson> beuno: fixing it even more is on the list for next week
<beuno> mwhudson, cool, I expect it may be hard to keep up with the growth in branches
<beuno> (on Launchpad, that is)
<rockstar> beuno, hi
<beuno> hey rockstar
<mwhudson> beuno: one might suspect difficulties along those lines, yes
<rockstar> It sounds like I'll be doing some Loggerhead hacking in the near future.
<beuno> rockstar, oh?  very cool!
<rockstar> Indeedy.
<beuno> anything specific in mind already?
<beuno> at this rate, it may even make sense to use Bundlebuggy!  :)
<rockstar> Just the theming support and packaging probably
<mwhudson> i guess we should really be testing that code review thingy launchpad has now
<beuno> ah, right
<rockstar> Yea, I heard the developers added something like that recently
<beuno> BB shows diffs, which is hard to give up
<beuno> of course, I could file a bug and poke people to get diffs on LP too
<beuno> even LH links would do, I suppose
<mwhudson> the bug exists
<mwhudson> and we'd like to fix it :)
 * beuno looks for it
<beuno> rockstar, if you have any questions about LH theme n' stuff, feel free to ping me about it
<rockstar> beuno, I sure will
<mwhudson> dinner time
<beuno> ok, it's bed time for me
<beuno> see you all tomorrow  :)
<poolie_> lifeless: if you didn't already could you send me that note re the new compression format
<poolie> spiv, how are you going with the cloning format seleciton?
<lifeless> poolie: its in progress
<poolie> thanks
<lifeless> I'm on cons at the moment
<poolie> thanks for your reply about the comment
<cody-somerville> When creating a repo, if I don't care about old versions of bzr is --dirstate-tags optimal?
<poolie> cody-somerville: giving no options will give you the default for that version of bzr
<cody-somerville> default doesn't mean optimal <g>
<lifeless> cody-somerville: no, dirstate-tags is not optimal
<cody-somerville> lifeless, is the default optimal?
<lifeless> cody-somerville: default is the best choice unless you have some specific need
<cody-somerville> Well, there will be very little local operations
<cody-somerville> Majority will be via network
<lifeless> cody-somerville: unless you're dealing with 10's of GB's of data in thousands of branches, default will be fine
<lifeless> and if you are dealing with that scale operation, nothing in trunk is sufficient for nice operation, though I have some plugins you may be interested in
<cody-somerville> Do you have a link?
<cody-somerville> It is 14GB of data
<lifeless> what sort of data? ISO's ?
<lifeless> 100's of thousands of files?
<lifeless> how many branches do you expect?
<cody-somerville> Sorry, was afk
<cody-somerville> lifeless, Okay, so the story is that I'm trying to complete a migration from no RCS (they're currently modifying source code on production server) to Bazaar.
<cody-somerville> There is two products but they share a lot of code and are located at /home/product1/xyz and /home/product2/xyz
<lifeless> ok, definitely go with default
<lifeless> which will be pack-0.92
<cody-somerville> Inside each respective xyz directory, there is one directory that contains backend source code and one directory containing shared code and then a whole bunch of other directories for each instance for each client
<cody-somerville> So I'm thinking of creating a repo in each xyz directory and having each client instance a branch and then the two other directories a branch
<cody-somerville> so that roughly 943 branches
<lifeless> that should be fine
<cody-somerville> Is that the best way to set it up?
<lifeless> it doesn't sound like there is actually 14GB of unique data, rather many copies of stuff
<cody-somerville> lifeless, yes, unfortunately
<cody-somerville> lifeless, is there anyway to create a repo that would encompass both products?
<cody-somerville> just bzr init-repo /home/ ?
<lifeless> sure
<cody-somerville> Actually, I think I'll create symlinks in /srv/ - that'll work, eh?
<poolie> lifeless: so it looks to me like the existing kvf code will never store texts crossing a physical repo boundary
<poolie> i'm going to check this a bit more
<poolie> you do actually have a comment in a test that asserts this though the test itself is not very robust
<poolie> because in the way described above it uses a one-line file that the code might choose to store in full regardless of the stacking
<poolie> i think this means we do not have in principle a problem with people upgrading the underlying repository
<poolie> um
<lifeless> poolie: I thought you managed to trigger a test failure?
<poolie> yes, but it's fixed by aaron's change, the one i asked about on the list
<poolie> and having re-derived that answer i think it's good
<poolie> s//a good fix
<Odd_Bloke> lifeless: If you have the chance at some point, a final checkup of http://bundlebuggy.aaronbentley.com/project/pqm/request/%3C20080718095350.18ab03f6%40lapbert%3E (which you've reviewed previously) would be appreciated.
<lifeless> poolie: oh, interesting. Let me think if I can find a hole. But this email first.
<cody-somerville> can I ignore exceptions.UnicodeDecodeError? lol
 * cody-somerville is getting a few UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 13: ordinal not in range(128)
<poolie> lifeless: np, i'm going to try some blackbox-level tests to try to poke holes in it, and also make that test more rigorous
<lifeless> poolie: my mail has been sent
<poolie> thankyou!
<lifeless> cody-somerville: probably that means you have a file on disk that doesn't match your locale
<poolie> and with 3 minutes to spare :)
<lifeless> poolie: please let me know asap if it doesn't tell you enough
<poolie> indeed
 * poolie reads
<lifeless> poolie: more needed?
<poolie> not now
<poolie> that looks cool, both in content and summary
<poolie> you should have put the 'what to do to help' at the top maybe
<lifeless> thanks :)
<lifeless> I also should have added links etc
<lifeless> but you needed it in a timely manner
<lifeless> I'm going to call it a day; started at 0630
<spiv> poolie: I think I have a fix, just waiting for the test suite to finish successfully before I mail it.
<poolie> yay way to go
<poolie> night lifeless
<cody-somerville> Whats the easiest way to make sure the remote host's working tree is always current?
<spiv> cody-somerville: there's a push-and-update plugin
<cody-somerville> Awesome.
<spiv> cody-somerville: a slightly different approach is the bzr-upload plugin, which uploads just a working tree (i.e. not a branch), which can suit web development
<spiv> Another option is just don't have a working tree on the remote host -- maybe you don't actually need one.  Or maybe you do :)
<cody-somerville> spiv, I'd like to use the former so that way if someone were to accidentally modify something on the development server the plugin will barf
<cody-somerville> err.
<cody-somerville> production server directly
<bzr> ï»¿Good morning. Is there any way to use Bazaar as a mere file synchronization tool between two computers, without having a history at all? If so, I could use it to synchronize my music and stuff between home and work computer, without wasting lots of additional disk space. I currently do this with Unison, but this tool has several drawbacks, e.g., no renaming support. Furthermore, I'd like to have only one tool for managing my code and managing my mul
<cody-somerville> ugh
<AfC> um
<spiv> bzr: not really.  bzr is pretty focussed on recording history.
<AfC> bzr: (you might want to pick another IRC nick. Just a thought)
<spiv> (Also, your IRC nick is going to be very confusing :)
<bzr> aehm ... my first time at all on irc. i probably did something wrong.
<unlink> what is the safest way to convert hg to bzr?
<lifeless> bzr: type '/nick yourname' without the ' marks
<lifeless> unlink: fastexport-fastimport is probably best today
<goldi> that should be better now
<AfC> bzr: "#bzr" is the channel you are in; each user is also identified by a "nickname"
<spiv> goldi: yep, thanks
<spiv> Oh, and welcome to irc!
<goldi> thx :-)
<AfC> goldi: so, there is a way I could think of that you could do the transferring you are talking about while constantly jettisoning history
<AfC> goldi: but as spiv noted, that's not entirely how Bazaar's authors expect the tool to be used.
<cody-somerville> Is this error bad?
<cody-somerville> KnitCorrupt: Knit <bzrlib.knit.KnitVersionedFiles object at 0xb7899f2c> corrupt: incorrect number of lines 1775 != 1774 for version
<goldi> spiv and AfC: If things are like that, I will have to find something else for this purpose. Thank you anyway.
<lifeless> cody-somerville: what bzr version?
<cody-somerville> lifeless, 1.6b3
<unlink> lifeless: thanks, checking it out now
<spiv> cody-somerville: that usually means there's a newline in a filename
<cody-somerville> How does... that happen?
<lifeless> spiv: we should error earlier though
<unlink> it's easy
<lifeless> cody-somerville: its a problem; its unexpected, and you should file a bug
<spiv> lifeless: If you have a bzr older than 1.5 and your install uses pyo rather than pyc, then you don't :(
<lifeless> spiv: well I did ask the version first :)
<spiv> Ah, good point.
 * spiv is still wary of that case after it bit Mary...
<nandersson> goldi, use rsync for keeping directories in sync
<unlink> bzr fast-import tells me to run bzr update, but bzr update says "No WorkingTree exists"
<lifeless> unlink: you can create a working tree with bzr checkout .
<lifeless> or in a different location with 'bzr checkout --lightweight URL'
<unlink> bzr checkout . gives me bzr: ERROR: Not a branch
<unlink> i've just done a conversion of an hg repository
<unlink> oh i see, it is the master directory i want to be looking in
<unlink> ok ... how do i get the bzr-gtk log viewer?
<mthaddon> lifeless, I can reproduce the problem (with PQM connecting to LP) with a simple python -c "from bzrlib.branch import Branch; Branch.open('sftp://bazaar.launchpad.net/~mthaddon/pycairochart/devel')"
<mthaddon> lifeless, works on my local machine with bzr 1.3.1, pqm box appears to be using bzr 0.93
<mthaddon> lifeless, simple matter of upgrading bzr on PQM box?
<mthaddon> going to try it with 1.5 and see if that fixes it
<mthaddon> lifeless, success!
<lifeless> mthaddon: heh
<mthaddon> lifeless, I'm not sure if I should switch ~pqm/source/bzr.dev to use bzr-1.5 or leave as is, and just set it for this project - any thoughts on that?
<lifeless> what machine is this?
<mthaddon> balleny
<lifeless> ballent already has a much newer bzre than 0.93!
<mthaddon> lifeless, not in ~pqm/source/bzr.dev, which is set in the PYTHONPATH for PQM's cron
<lifeless> oh indeed
<lifeless> I'd pull 1.5 into that directory
<mthaddon> ok, cool - thx
<lifeless> I really wish the debian maintainers for apache2 and exim would stop making spurious config file changes
<lifeless> and dovecot
<lifeless> sheese
<lifeless> comments in config files should not cause me to have to read the entire freaking thing again
<uws> Hmm. Can I diff between 2 remote revisions?
<uws> I want to diff from  e.g. 123..124 on a remote branch, to see whether to cherry pick this
<lifeless> bzr diff -r 123..124 REMOTEBRANCH
<uws> lifeless: Thanks. I was looking in the wrong place methinks... fiddling with branch: urls and stuff
<uws> bzr merge -r928..929 sftp://....
<uws> M  lib/....
<uws> All changes applied successfully.
<uws> But I already cherry-picked this one
<uws> so "bzr diff" on the local branch is empty afterwards
<uws> strange that it says "M lib/..."
<AfC> uws: I've wondered about that myself. I think it boils down to "those files were touched" even though there is no actual textual diff change. Still, it's a bit strange.
<uws> yeah. and there's no pending merge either
<uws> cherry picking would be ok
<uws> if it were tracked; )
<lifeless> cherry picks don't create pending merges today
<uws> lifeless: but is the revid stored somewhere?
<fullermd> It's because the cherry pick isn't recorded that you see the M lib/ line
<uws> AfC: (btw, how are you. you weren't at guadec)
<uws> fullermd: So how does it find out that I already have that patch in my branch?
<fullermd> If it were, you'd get a "already have that".  Since it's not, it does the same thing it did the first time around, which ends up with no diff.
<AfC> uws: (yes, I'm a bit bitter about that)
<fullermd> It doesn't.  It just ends up at the same place.
<uws> fullermd: I'm wondering why it doesn't cause a patch conflict
<fullermd> If that cherrypick were to end up in a conflict, and you resolved and committed it, doing the cherrypick again would bring you back to the conflicted state.
<uws> AfC: (IST was a great place)
<fullermd> Because there's no conflict.  It just ended up right back where it went the first time (reasonable, since it's in the same state, mod the change that's the same...  wow, that's clear...)
<fullermd> Try it this way; a 3-way merge, with an identical change on both sides, leads to a clean result with that change.
<fullermd> The first time you cherry pick, it merges in whatever that change was you were cherrypicking, with $SOME_OLD_REV as the merge base.
<AfC> uws: I think I can head this off by observing (without hostility) that Bazaar's interaction with cherry-picking type activities is unfortunately not quite as optimal as they someday hope it will be.
<cody-somerville> guh
<fullermd> The second time your cherrypick, the same old rev is still the merge base (since no new merge point is created), and the 3-way merge will, because of that, end up with the same result it had the last time, which is what you committed last time, which is why there's no visible change.
<cody-somerville> more dying on the newline in name
<uws> fullermd: ah, $SOME_OLD_REV is used as base. that makes things clear (at least form e)
<lifeless> uws: no we don't record the cherry pick todau
<uws> is there a shorthand notation for  bzr diff -r123..124 ?
<lifeless> merging in other systems (except darcs) also ignores cherrypicks
<uws> e.g. like  svn diff -c124  ?
<fullermd> (the results may be different with --weave; I think that gets crankier about the same textual change being on both sides, with different originators)
<fullermd> You mean like bzr diff -c124?   :p
<AfC> uws: bzr diff -c 124
<uws> lifeless: It's a bit annoying though. I'm hand pulling some stuff (cannot completely merge for many reasons) using  bzr log --line sftp://$remote
<uws> and then using diff (to check) and merge (to pull it in) to pick some changes
<uws> when I've done a few, they still end up in the "bzr missing --other" listing
<uws> (eh, where I said "bzr log" 3 lines ago, I meant "bzr missing")
<uws> fullermd: wow.
<uws> fullermd: but the docs should be improved
<uws>     Difference between revision 2 and revision 1:
<uws>         bzr diff -r1..2
<uws> ^^ from "bzr help diff"
<uws> the -c stuff is only in the parameter listing
<uws> if someone could add another example there, right below the one I pasted above...
<fullermd> Mmm.  That example probably should be a larger range, and another entry for -c
<uws> stating something like  "To see the changes a single revision introduced, you may also use...."
<uws> trivial fix, and I'm not running bzr.dev, so I'll leave it to you guys
<LarstiQ> hah :)
<lifeless> :)
<uws> dag wouter.
<LarstiQ> middag wouter :)
<uws> LarstiQ: je zit niet in UTC+0200?
<LarstiQ> uws: correct, although 3 minutes early, but I am in Finland.
<uws> is there already support for branch shortcuts?
<uws> I have a few "other" branches
<uws> one of which is my parent brnach
<uws> and 2 others are colleagues
<uws> I'd like to easily use e.g. bzr missing on those without typing complete urls
<fullermd> :-aliases for saved locations, bookmarks plugin for others.
<uws> fullermd: :-aliases? which help topic covers that/
<fullermd> (the former is post-1.5, though)
<uws> hmm 1.5 here.
<fullermd> Well, none, AFAIK; only doc I know of for it is in NEWS   :|
<uws> fullermd: can you give me an example syntax?
<fullermd> bzr missing :parent    bzr pull :push
<AfC> uws: missing uses against a default
<AfC> s/against //
<fullermd> The bookmarks plugin should with with 1.5 though  (and it gives you more options)
<AfC> uws: which is parent: , I believe
<AfC> uws: use `bzr info` to see what's what, and just run a bare `bzr missing` and see what happens.
<fullermd> It is.
<fullermd>         if other_branch is None:
<fullermd>             other_branch = parent
<lifeless> uws: missing won't help with cherrypicking; sorry :(
<AfC> Hm. parent: gets set to what you branched from, I know that, but is there a convenient way to reset it? I assume `bzr pull --remember` changes parent:, but I'm not certain.
 * fullermd nods at AfC.
<AfC> uws: there you go
<poolie> spiv, thanks for the #251871 patch!
<uws> fullermd: Ah, thanks
<uws> AfC: vi .bzr/branch/branch.conf   ;-)
<AfC> uws: I try to avoid recommending that sort of thing, but yes
<uws> AfC: (agreed)
<poolie> night all
<uws>     To merge the changes introduced by 82, without previous changes:
<uws>         bzr merge -r 81..82 ../bzr.dev
<uws> fullermd: ^^ same there for the -c flag
<uws> (from bzr help merge)
<asabil> hi all
<asabil> I have some troubles with loggerhead
<asabil> it seems to trigger bzr exceptions in the front page
<asabil> and it generates Html code with things like: var global_path = Exception: type object 'branch' has no attribute 'url';
<lifeless> asabil: what bzrlib do you have?
<asabil> 1.5
<cjwatson> lifeless: pong
<lifeless> asabil: hmm, I think you need 1.6b4 at the moment
<lifeless> cjwatson: the branch with the fetch error, I tracked down the root cause
<lifeless> cjwatson: its not an easy fix; can you do a baz-import of mdz's branches and fetch-ghosts, that should fix it up for you
<asabil> lifeless: oh ok thanks
<cjwatson> lifeless: ok, I was already on that road, unfortunately there are (IIRC) five branches with ghosts and I've been getting SHA-1 mismatches after fetching ghosts because evidently I haven't got the history combinations quite right
<lifeless> cjwatson: possibly they are bugs in the converter
<lifeless> cjwatson: it shouldn't be stuff *you* do triggering, so I'd suggest filing additional bugs on baz-import (part of bzr-tools)
<cjwatson> fetch-ghosts says "Still missing:" and then five further branches. 'bzr log' doesn't show the ghosts from revision 1. Has it done anything useful?
<cjwatson> 'bzr branch' in the fetched-into branch still says that a revision is missing.
<cjwatson> and it's a revision that 'bzr log --show-ids' says is in the branch I just fetched
<cjwatson> so if I can force the fetch to proceed somehow ...
<lifeless> fetch-ghosts should DTRT
<lifeless> I'm not going to dig into it right now though
<lifeless> tired/done for now
<cjwatson> http://paste.ubuntu.com/32537/
<lifeless> ls --show-ids isn't a very useful command for this
<lifeless> I'm not sure what you think it does
<lifeless> but it shows you what a specific revision refers to, not what fetch will need to do
<cjwatson> bzr branch claimed that a revision was missing in a particular file-id, and I just wanted to demonstrate that that file-id did indeed exist in the fetched-from branch
<lifeless> it doesn't demonstrate that though
<cjwatson> seemed to me that one possible failure mode would have been that the other branch had been imported with mismatching file-ids
<lifeless> it demonstrates that an inventory refers to a file id, not that the file ids content is present
<lifeless> yes, thats a possible failure mode, but more likely is a reference to an incorrect last-altered revision
<cjwatson> hm, ok, I don't see a way to do the latter from the command line
<lifeless> bzr check should be reasonable at catching most things
<cjwatson> iter_ghosts in fetch_ghosts.py simply doesn't seem to report that revision
<lifeless> it may not be a ghost anymore
<lifeless> report the current error with backtrace somewhere and throw a tarball of the current branch up too
<lifeless> I'll look tomorrow
<jelmer> menesis, hi
<jelmer> menesis, can you please submit your merge request for bzr-gtk to bundlebuggy (see details on the wiki)
<jelmer> we don't use launchpad for merge requests
<Odd_Bloke> http://twitter.com/bzr_tweet
<james_w> Odd_Bloke: nice
<james_w> the URL in the sidebar is messed up, apparently twitter doesn't believe in https://
<cjwatson> lifeless: casper material in bug 246880
<ubottu> Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880
<menesis> jelmer: ok, will try
<james_w> any clues to what may be going on in the following would be greatly appreciated:
<james_w> I have import code that imports a directory, this leads to a kind change, with a file being added to the directory that used to be a file
<james_w> tree.path2id("dir/file") gives a file id and tree.changes_from(tree.basis_tree()) lists the addition of the file and the kind change
<james_w> tree.commit() is then run, and leads to a new commit, but only the kind change is committed, not the file addition.
<james_w> the file is still marked as added if "bzr st" is run after the commit
<james_w> however, running "bzr st" before the commit leads to the addition being committed
<james_w> does anyone have an idea why the addition isn't being committed, or what "bzr st" may be doing to change this.
<luks> bzr st updates the dirstate, maybe your import code is messing it up?
<grahal> i'm trying to checkout bzr-fastimport
<grahal> bzr branch lp:bzr-fastimport fastimport
<grahal> bzr: ERROR: [Errno 2] PROPFIND request failed on '/svn/testsvn'
<grahal> ...
<james_w> maybe, but I would have thought that the changes_from() would not include the addition if the dirstate didn't have it
<grahal> it's the second day it's hapenning
<grahal> any ideas?
<james_w> grahal: weird
<james_w> bzr-svn is getting involved somehow, but I'm not sure how
<grahal> oh I see
<grahal> let me try to uninstall bzr-svn
<grahal> I thought it could be setup related on server side
<james_w> does "bzr branch http://bazaar.launchpad.net/~bzr/bzr-fastimport/fastimport.dev" work?
<jelmer> grahal, can you perhaps pastebin the full traceback ?
<jelmer> it's working fine here with bzr-svn installed
<grahal> same thing
<grahal> bzr: ERROR: [Errno 2] PROPFIND request failed on '/svn/testsvn'
<grahal> hmm, bzr-svn is not even installed..
<grahal> I thought it was
<grahal> maybe my install is completely messed somehow
<grahal> will reinstall pkgs
<luks> grahal: `bzr -Derror branch lp:bzr-fastimport fastimport` and pastebin the full traceback
<grahal> luks: http://pastebin.com/m27a0d995
<grahal> I did have bzr-svn installed
<grahal> I moved the /usr/lib/python2.5/site-packages/bzrlib/plugins/svn away
<grahal> then things worked
<grahal> pastbin tells bzr-svn version
<grahal> it was a dev version so maybe it could be that
<james_w> yeah, the dirstate still marks the directory as a file
<jelmer> grahal, it looks like you have a svn checkout in one of the parent directories of your cwd
<rexbron> hey jelmer, I snaged a copy of trunk but am having some issues. When I installed the latest intrepid ppa of bzr, it uninstalled brz-rebase and bzrtools. Do I need to get newer versions of each of those?
<jelmer> rexbron: bzr-rebase isn't maintained in the ppa
<jelmer> nor is bzr-svn, I'm not sure about bzrtools
<rexbron> jelmer: ok, I installed 1.6 because that was required. I'll look into getting newer versions of each
<TheEric> how do you set the bzr_ssh variable?
<rexbron> jelmer: would you be able to comment on http://pastebin.ca/1088418? If it is a more serious problem than just configuration on my end, I'll report a bug.
<rick_h_> anyone know what bzr-svn you need to get working with svn 1.5? I updated to 1.5 via a ppa and grabbed 0.4.9.1 bzr-svn
<jelmer> rick_h_, 0.4.10
<rick_h_> ah, ok thanks. I'll see if I can find that one then
<jelmer> rexbron, you need a newer version of bzr
<rexbron> jelmer: newer than 1.6?
<jelmer> rexbron: A recent snapshot of bzr.dev
<jelmer> rexbron, 1.6 isn't out yet
<jelmer> both bzr-svn 0.4 and bzr.dev are moving targets
<rexbron> jelmer: ok, snaging current trunk
<jelmer> rexbron, you may also want to apply the patch I just attached to https://bugs.edge.launchpad.net/bzr/+bug/251871
<ubottu> Launchpad bug 251871 in bzr "assumes source_branch format is the same as result branch format" [Critical,New]
<rick_h_> jelmer: any reason that the bzr devs ppa has 1.5 for gutsy, feisty, dapper, but no hardy.
<jelmer> rick_h_, sorry, don't know
<jelmer> poolie, ^
<rick_h_> ok, thanks
<rick_h_> yea, the bzr-svn needs 1.4 > and hardy has 1.3, so trying to get 1.5
<jelmer> rick_h_: ? Afaik there is no bzr-svn in the ppa at all
<rick_h_> jelmer: no, but you can download the plugin for .bazaar/plugins
<rick_h_> the .tar.gz
<rick_h_> jelmer: any suggestion what branch I should use to get bzr-svn 0.4.10-2? The latest tar was just 0.4.10 and there's a bug fix I need for: 246683
<grantgm> before I file a bug, I want to make sure I'm using bzr svn-push right: it should be able to create a new directory within the svn repo if I push to a location that doesn't yet exist, right?
<grantgm> because I'm getting an AssertionError when I try to do that
<TheEric> how do you set the bzr_ssh variable?
<jelmer> rick_h_: 0.4.10-2 is only available from Debian and Ubuntu
<jelmer> rick_h_, e.g. http://packages.ubuntu.com/intrepid/bzr-svn
<TheEric> how does one set the bzr_ssh variable?
<james_w> hey TheEric, are you on Windows?
<TheEric> I am.
<rick_h_> jelmer: thanks, I tried out the lp branch for debian since I saw the last commit was merge 0.4.10-2, but error so then I figured I'd try to do 0.4 trunk and gcc wouldn't build
<rick_h_> so I think I'm just going to hold off a bit and go back to just running svn against that project for now
<jelmer> rick_h_: What error did you get exactly?
<jelmer> rick_h_, ok
<rick_h_> when checking out lp:~debian-bzr-svn/bzr-svn/unstable into .bazaar/plugins/svn I still got the Assertion `*path != '/'' failed. error
<rick_h_> when trying to build the .4 series of bzr-svn I got client.c:819: error: expected â{â at end of input
<rick_h_> and then gcc exited with status 1
<james_w> TheEric: you need to set it in your environment. I haven't used Windows in so long that I've forgotten how to do that, sorry.
<james_w> TheEric: searching for setting environment variables in windows should find you something
<rick_h_> it's something like "right click my computer, go to advanced, env variables"
<rick_h_> of course that was xp
<rick_h_> http://vlaurie.com/computers2/Articles/environment.htm
<pygi> jamesh, poke
<james_w> jam: hi, do you have a moment?
<jam> james_w: a little
<james_w> jam: for a test I need to do something like find out the kind recorded for an entry in the dirstate, is that possible?
<james_w> it looks like the working tree will tell me the kind on disk
<jam> james_w: you want the kind in the dirstate, but not the kind on disk?
<jam> Technically, if you cheat and go "wt.inventory[file_id].kind" it should give you the last-recorded kind
<james_w> I currently have a problem because they disagree
<jam> but would you want to use the one in the basis_tree instead?
<james_w> it turns out my TreeTransform file->directory fix wasn't complete, as it leaves the directory marked as a file in the dirstate, which means that children of the dir aren't recorded in the next commit
<james_w> I want to write a test to check this, and the only thing I can think of is checking that the dirstate reflects what's on disk
<james_w> unless I have mis-diagnosed this and it's ok for the dirstate to be like that and I'm missing something else
<TheEric> yah, none of the fixes work...
<TheEric> putty & bazaar just don't get along
<TheEric> I've added plink.exe to the path, renamed it ssh.exe, set BZR_SSH = the path to plink
<TheEric> none of it works. The same error message : Don't know how to handle SSH connections. Please set BZR_SSH enviroment variable
<jam> james_w: Well, you could test the symptom you just described
<jam> that changing a file => directory and then committing commits the children of that directory
<jam> as an aside, calling WT4.get_file_sha1(file_id, [path=XXX]) will actually update the dirstate record
<jam> you need to call something that does 'update_entry()'
<rick_h_> TheEric: I don't think it takes a path
<rick_h_> I recall seeing a bug/ticket that it didn't
<jam> And ATM only get_file_sha1 and iter_changes() do that :(
<jam> so *commit* doesn't trigger re-reading the on-disk state
<jam> TheEric: you can only set "BZR_SSH=paramiko" or "=plink" or "=ssh"
<james_w> jam: that sounds like a more sensible test, thanks.
<jam> It doesn't take a path
<james_w> jam: do you think that TreeTransform should be leaving the dirstate correct against the disk?
<jam> james_w: as much as possible, yes
<rick_h_> TheEric: https://bugs.launchpad.net/bzr/+bug/176292
<ubottu> Launchpad bug 176292 in bzr "BZR_SSH should allow setting the path to ssh, not just the kind of ssh" [Undecided,Confirmed]
<rick_h_> you might want to follow that bug
<james_w> jam: thanks for your help
<TheEric> I never had this many issues with svn
<TheEric> Narrowed it down further, and now it's giving me another error - connection closed: please check connectivity and permissions
<TheEric> figured that out. the host key wasn't cached. a simple log on to the host with plink, and presto chango
<TheEric> anyone gets that error again. go to my computer / properties, enter a new enviroment variable / BZR_SSH / plink
<TheEric> if they get the other error, just log on to the host with plink, cache the key, and poof.
<rocky> don't suppose there's any better progress with getting bzr 1.5 and bzr-svn running on hardy at this point?
<jelmer> rocky: You can use the bzr-svn from intrepid
<rocky> jelmer: right, i think i'm still stuck with no bzr 1.5 tho
<jelmer> 1.5 should be available in intrepid as well
<rocky> an intrepid binary will work on hardy for bzr? hmm
<rocky> i guess if it's all python
<luks> it's not all python
<rocky> oh
<rick_h_> rocky: let me know if you get it working. I was trying this morning
<rocky> k
<rocky> rick_h_: well, these intrepid deb's installed fine for me... just about to start testing them (i downloaded them from the intreprid section on packages.ubuntu.com)  http://users.carterscove.com/~rocky/bzr-on-hardy/
<rocky> jelmer: when bzr-svn checks out a svn url ... does it check it out to some private location *first* and then move it into the proper local dir? i'm running a checkout here on dial-up atm and there's no status showing me how much is checked out
<rick_h_> rocky: I got the 1.5 deb from the gutsy ppa and it installed and bzr works fine
<rick_h_> but I couldn't get a working svn plugin, did you get the bzr-svn from intrepid then?
<rocky> yes i did
<rocky> hrm, how do i tell what revisions have been made to my local branch but not pushed back?
<james_w> wow, TreeTransform is actually starting to make sense to me, I never thought I'd see the day.
<rick_h_> rocky: bzr missing?
<rocky> huh?
<rick_h_> wondering if bzr missing is what you want to show local commits vs remote repo
<rocky> i dunno... i'm still learning bzr here ;)
<uws> rocky: bzr missing, perhaps with --other or --mine flag
<rocky> oh... missing is a bzr cmd
<uws> rocky: (just type "bzr missing")
<rocky> lol
<uws> no lol'ing in here please.
<rocky> heh
<rocky> if i branch a local branch as another local branch and then move the first local branch, how do i tell the second local branch that it's parent branch has moved?
<rick_h_> rocky: you can always specify the new path when doing a merge or pull I think
<rick_h_> it recalls the last path used by default, but still takes a new one if you want
<rocky> right
<rocky> just wish i could convince it to "remember" the new path
 * rocky is reading tons of bzr stuff today
<james_w> rocky: bzr pull --remember URL
<rocky> don't suppose there's a patch or something for setuptools to embed bzr rev info via setup.cfg ?
<rick_h_> rocky: there was a blog post recently on a plugin for template tags or something like that
<rick_h_> like the svn $id or whatever
<rocky> hm
<rick_h_> that's not the right term, template tags. Grrr, I know I just saw it
<rick_h_> http://jam-bazaar.blogspot.com/2008/07/last-week-in-bazaar.html
<rick_h_> rocky, keyword expansion is the phrase
<james_w> rocky: bzr version-info is something that will work now
<james_w> it takes a little bit of work to integrate it in to your build system though
<rocky> jelmer: is there anyway to turn some sort of debugging on for bzr-svn to see what svn operations it's performing?
<jam> james_w: I've done it if you want examples :)
<rocky> does anyone know if current bzr-svn trunk still works with bzr 1.5 ?
<jam> lifeless: If you get a chance, can you look at bug #198646
<ubottu> Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] https://launchpad.net/bugs/198646
<jam> I think I should actually split it out to a new bug
<jam> just a sec
<rocky> ugh, getting nasty svn error from using bzr-svn 0.4.10
<jam> lifeless: bug #253745 should have the more relevant details
<ubottu> Launchpad bug 253745 in bzr "Fail to parse boundary if multiple Content-Type headers are given" [High,Triaged] https://launchpad.net/bugs/253745
<rocky> when would "bzr add somerandomdir" return with nothing actually added?
<rocky> heh, when there are .svn dirs present apparently
<tstellar> John A Meinel from launchpad suggested you might be able to help me with this bug  https://bugs.launchpad.net/bzr/+bug/198646
<ubottu> Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released]
<tstellar> lifeless
<Tsmith> i'm in a bind...
<beuno> Tsmith, bzr unbind  (?)
<Tsmith> I need to revert just -r6, but i'm at -r18.  Should I do the typical SVN thing of bzr diff -r5..6 > bad_push.diff; patch -p0 -R < bad_push.diff; bzr ci -m'Reverted -r6.' ?
<james_w> beuno: that was bad :-)
<beuno> james_w, I know, I know...
<LarstiQ> Tsmith: 'bzr merge -r6..5 .' should work
<beuno> Tsmith, you might be able to:  bzr merge -r6..5
<LarstiQ> Tsmith: and then the commit
<Tsmith> what's that do?
<Tsmith> ::prays::
<LarstiQ> Tsmith: combines the diff and patch dance you did above
<Tsmith> o wow
<pickscrape> !seen pygi
<ubottu> Sorry, I don't know anything about seen pygi
<Tsmith> hey! THANKS!
<Tsmith> <3
<LarstiQ> well, I'm glad he's happy.
<pickscrape> Anyone know how pygi is getting on with cheezburger?
<james_w> pickscrape: what's cheezburger?
<james_w> his dinner?
<LarstiQ> pickscrape: I'm not aware of him being involved with anything cheezburger (icanhaz?)
<james_w> hey LarstiQ
<beuno> it's a project
<beuno> with bzr
<beuno> that was supposed to be cool
<beuno> but I can't remember *what* it was
<james_w> as long as it's cool
<beuno> https://edge.launchpad.net/cheezburger
<awilkins> That's not the engine that runs i can haz cheezburger is it ?
<Jc2k> no
<pickscrape> I'd supposed to be a esrver-side tool for bzr
<pickscrape> which provides things like per-branch access configuration
<james_w> I'm still none the wiser from looking at the page :-)
<beuno> to serve repositories, if IIRC
<pickscrape> I was going to ask him how he's getting on iwth it
<jelmer> re
<mcmillen> What's the recommended way of getting bzr 1.5 for Ubuntu Hardy?  I tried adding the suggested lines to sources.list (pointing to ppa.launchpad.net), but apt-get still tells me bzr is the newest version, even though I have 1.3.1 installed.
<pickscrape> 1.6 beta got accidentally uploaded to that PPA, and subsequently removed. Since then 1.5 hasn't been put back for some reason.
<mcmillen> looking at the pool/ directory directly, there seems to be files like bzr_1.5.0-1~bazaar1~{dapper,feisty,gutsy}1_i386.deb, but no hardy or intrepid.
<beuno> mcmillen, there was an issue with bzr hardy package
<beuno> 1.6 will land when it's released
<beuno> meanwhile you can get 1.6b3 from: https://edge.launchpad.net/~bzr-beta-ppa/+archive
 * beuno is off to the dentist
<awilkins> How much do you reckon using encrypted storage containers would slow Bazaar down?
<james_w> awilkins: you mean an encrypted repository format?
<LarstiQ> or just plain disk encryption?
<mtaylor> If you're sure that it's not being modified, use bzr break-lock lp-147258572:///~andrey-mysql/drizzle/cleanup-branch/.bzr/branch/lock
<mtaylor> sort of ugly error message ^^
<mtaylor> (since  bzr break-lock lp-147258572:///~andrey-mysql/drizzle/cleanup-branch/.bzr/branch/lock doesn't actually work)
<lifeless> moin
<james_w> hey lifeless
<james_w> mtaylor: yeah, there's a bug open on that, launchpad shouldn't really expose implementation details like that
<mtaylor> james_w: k. thanks
<james_w> you know how to really break the lock if you need to?
<awilkins> james_w: I mean an encryted repo format
<james_w> awilkins: I think it would slow it down considerably, but you could probably come up with a scheme that reduced the impact
<lifeless> we had a soc project to do this
<lifeless> the wiki notes are tehre as is discussion on the list
<james_w> for instance encrypting the indexes with something less than say AES, as you would just expose things like file and revision ids, which give some information, but no content
<rocky> jelmer: when i check out or do somthing with a branch from svn using bzr-svn ... does it do some sort of checks on every since dir in the svn repo (even above my branch) ?
<awilkins> james_w: I was thinking about it in terms of medical records ; I'm not sure they need a version control system.
<awilkins> james_w: But I'm thinking about multiple-encrypted master key containers protecting multiple threads of medical records producing a medical record system with proper privacy.
<james_w> awilkins: probably encrypted hard disks are the way to do
<james_w> awilkins: sounds like fun. Good luck :-)
<awilkins> Heh, yeah
<james_w> that would be an interesting problem though
<awilkins> The idea is that the record remains private while being accessible by the patient and any contributors to the record
<james_w> the bzr thing was more about storing a branch on a server you don't control where you only have bzr access and want to protect your data to some extent
<uws> awilkins: luks disk encryption supports multiple passphrases
<uws> awilkins: you can try it out if you have a spare USB disk lying around
<lifeless> I'd say for the medical records thing that bzr is a bad fit; schema evolution is important in databases
<lifeless> secondly I don't see a patient manually authorising every individual access - when they turn up unconscious at A&E they need treatment and their records available.
<lifeless> I'd look more for strong auditing and reporting
<pickscrape> Are there any plans/intentions/objections to in the future having coloured output a configurable part of bzr core?
<james_w> pickscrape: you mean "cdiff", or more than that?
<pickscrape> Yes, things like cdiff
<pickscrape> Or rather, diff
<pickscrape> I'm looking at adding coloured output to diffstat, but I want it to be optional and I don't want to have to add another command in order to do it.
<pickscrape> In this case I like the way git does it: let the user configure it how he wants.
<lifeless> pickscrape: I think its fine to have optional colourisation as part of the core
<pickscrape> lifeless: That's good to know.
<stickwithjosh> Is bzr+ssh the preferred method of setting up a remote bar repo to shoot to for backup / deployment ?
<lifeless> stickwithjosh: its the most featureful; but we support bzr+ssh just as much as sftp and http etc
<stickwithjosh> lifeless: thanks!
<stickwithjosh> Nice, I like how bzr automatically realizes that .pyc files shouldn't be added (by default).
<pickscrape> lifeless: do you have any thoughts on how color options should work in the config file?
<pickscrape> e.g. a section called [COLOR] or [COLOUR] (spelling arguable)
<pickscrape> With options under there for everything that supports it.
<pickscrape> If I'm going to add it to diffstat I want it to work in a way that will be used by other things going forward.
<lifeless> does it need a section?
<lifeless> why not just use_colour=True|False ?
<pickscrape> Because you might want it turned on for some commands but off for others
<lifeless> seriously?
<pickscrape> Yes
<lifeless> why?
<pickscrape> People are funny like that :)
<awilkins> You might want to supress it if you are piping diffs to a file or to patch?
<lifeless> awilkins: thats a one-shot task though, not a persistent config value
<pickscrape> You also might want to be able to configure what the colours are.
<lifeless> you don't want to be editing a config file just to make a patch :)
<lifeless> pickscrape: per command ?
<lifeless> pickscrape: anyhow let me rephrase
<lifeless> sections are complex
<awilkins> <voice name='Neo'>Pink. Lots of pink</voice>
<lifeless> they may not work as well in e.g. branch.conf and locations.conf
<lifeless> (then again they might, I dunno)
<fullermd> Well, if you're not outputting to a terminal, you'd never want to color anyway.
<lifeless> fullermd: cdiff | less -R
<fullermd> Hush, you.  My declamations are _simple_.  Correct is way too much work.
<lifeless> anyhow
<lifeless> I don't use colourisation - red/green colourblind
<lifeless> so I tend to avoid colour for stuff
<pickscrape> lifeless: a prime example for wanting to be able to customise the colours (if I'm understanding properly)
<lifeless> pickscrape: no, I'd rather just have them off
<lifeless> takes too long to try and figure out a set that works for me
<pickscrape> ok, but somebody else might be ok putting the time in
<lifeless> sure
<lifeless> I wasn't talking about the code, but about me
<pickscrape> yes, sure
<lifeless> colour_settings=....
<lifeless> use_colour=True|False
<lifeless> colour_commands=...
<pickscrape> My personal perference is that it helps readability enormously so I want it everywhere I can get it.
<pickscrape> But I'm also particular about the colours used
<james_w> pickscrape: I'd start with "colour = True|False", and then we can make it more configurable later
<pickscrape> Yes, I was going to say that would be the lowest common denominator for the whole thing.
<fullermd> And what about setting whether you want color?   ;p
<pickscrape> All or nothing to start with.
<radix> someone write a dict subclass which considers "color" and "colour" equivalent
<awilkins> Hmm, a buddy of mine is RGCB ; I wonder if it's correlatede with programming tendencies
<awilkins> But possibly not, it's rather common
<fullermd> I wouldn't think so; it's sufficiently common in men...
<pickscrape> Would be interesting to provide a 'theme' tailored for RGCB.
<fullermd> I've got a hint of very pale colorblindness, but it's not noticeable day-to-day.
<lifeless> awilkins: 15% of population or some huge number
<awilkins> 2% isnt it?
<lifeless> oh maybe
<lifeless> its just numbers :P
<pickscrape> About 94.2% of stats are made up anyway
<lifeless> still 2% is freaking lage
<lifeless> *large*
<awilkins> Heh, 8%
<awilkins> 2% is auxilliary nipples
<radix> hahaha
<radix> 2% could be a lot of things...
 * awilkins has a load of useless medical trivia in head from medical degree
<lifeless> theres 120MILLION extra nipples on the planet?
<lifeless> Oh Noes
<fullermd> The question is how many acres is that?
<lifeless> depends how thin you slice them?
<radix> fullermd: please don't get into an Inappropriate Comment battle with lifeless. he will probably win, and it will probably go too far
<radix> ;-)
<lifeless> hehe
<fullermd> I wouldn't try, in my pre-caffeinated state.
<awilkins> Another excellent question is how many of them are female
<AmanicA> http://www.reference.com/search?q=Colourblind
<pickscrape> That would definitely affect the potential acreage.
<awilkins> And of course, the prevalence of multiple pairs of auxilliary nipples, and the subset of them willing to wear cat ears and a furry tail :-P
<lifeless> ROTFL
<radix> take it to #furries
<lifeless> radix: theres been exactly one furry comment... has it offended you?
<radix> lifeless: no, I'm over in #furries waiting for more chatter
<pickscrape> :)
<lifeless> oh I am so tempted to check
<radix> hahah
 * lamont has a stupid question
 * lamont tries answering it himself
<fullermd> The advantage of doing that is you rarely have to explain your answer in more detail.
<lamont> yeah
<lamont> and yeah.  no worries.  thanks lamont for the answer. ;-)
<lamont> https://bugs.edge.launchpad.net/bzr/+bug/253806
<ubottu> Launchpad bug 253806 in bzr "bzr: ERROR: The file id "foo-20080731224042-7ogu3b3hk0bwnpo3-1" is not present in the tree" [Undecided,New]
<james_w> lamont: I assume adding it again is the crucial bit?
<lamont> which is the end result of my question to myself
<james_w> I would assume so
<lamont> yes.  bzr rm --keep foo will make bzr cat work again
<lamont> committing doesn't help though
<james_w> it looks up the file id in the current tree, and then uses that id
<james_w> it should look up the file id in the target tree
<james_w> we suck at this in places
<lamont> this is all separate from the fact that I didn't mean to commit the tree with that file removed...
<lamont> in the larger bzr tree where I first hit it, the re-added foo is identical to the one 4 revs back, which should not have been deleted 3 commits ago
<james_w> ah, it's not as simple as I though
<james_w> thought
<james_w> it looks up both revids, but assumes that if the newer is present then it will also be present in the earlier
#bzr 2008-08-01
<lifeless> it needs to be lazier or something
<lifeless> or resolve to both ids and then handle one being absent
<james_w> yeah
<james_w> the latter I think
<james_w> though I think it has the order backwards currently
<lifeless> so cat -r x FOO
<lifeless> can resolve to two files
<lifeless> should it cat both?
<james_w> no, I don't think so
<james_w> I think it should cat FOO at x if possible
<james_w> with a way to say cat current file-id of FOO at x
<james_w> possibly falling back to that if the path FOO isn't in x
<Odd_Bloke> 'Morning'.
<poolie> hello Odd_Bloke
<james_w> evenin'
<poolie> how's pqm/
<james_w> hey poolie
<fullermd> That falls back into 'cat [like log] should be able to take a file-id'...
<james_w> fullermd: yeah, logs even more complex I think, but we should provide a way to specify what you want
<james_w> log's I mean
<Odd_Bloke> poolie: Not bad.  I had a bit of a lull over the past few days, but I'm back on track now.
<Odd_Bloke> I intend to spend today working on XMLRPC stuff, mostly testing.
<mwhudson> Odd_Bloke: 'today' ??
<mwhudson> i see your sleep cycles are still crazy :)
<Odd_Bloke> mwhudson: Yeah, I'm not entirely sure what's going on there. :p
<fullermd> Sounds perfectly reasonable to me   :p
<Odd_Bloke> When I'm like this and want to get work done, I find it easiest to just assume I'm shifted by n hours and act as if it's a normal day.
<mwhudson> Odd_Bloke: http://www.xkcd.com/448/
<mwhudson> Odd_Bloke: i guess you're around melbourne currently?
<mwhudson> perth tomorrow?
<Odd_Bloke> I think I'm probably just off Australia's west coast ATM.
 * Odd_Bloke --> breakfast
<lifeless> lol
<lifeless> hgweb is a windows trojan
<jelmer> 'evening *
<lifeless> hi jelmer
<lifeless> poolie: so, last we spoke about groupcompress you were hazy; are you less hazy now ?
<lifeless> thumper: ping
<mwhudson> lifeless: is the graphs-in-hgweb something you have to turn on or something?
<mwhudson> lifeless: i don't see it on http://hg.mozilla.org/index.cgi/mozilla-central/shortlog (for example)
<thumper> lifeless: yes?
<lifeless> mwhudson: its a recent feature; back at europython CERN there was a beta branch
<lifeless> mwhudson: but core didn't like the performance
<mwhudson> lifeless: ok
<lifeless> its based on my merge_sort code :P
<lifeless> thumper: echannel sorry
<mwhudson> well haha
<mwhudson> lifeless: presumably it doesn't merge sort the whole graph the whole time though?
<lifeless> shurg
<lifeless> or at least, the code I saw at EP was done by grabbing merge_sort
<poolie> lifeless: that was a good summary, thanks
<poolie> lifeless: i'd like to make sure sometime before we commit to it there is a format specification separate from the code
<lifeless> shocking!
<lifeless> (do you mean like the EBNF's I write for the other low level things I create?)
<mwhudson> well if you merge sorted the revision graph of bzrlib on every request, performance would be terrible
<lifeless> I have some infrastructure I want to write
<poolie> :)
<poolie> like that
<lifeless> yeah
<lifeless> there isn't one at this point because its got a lot of room for complete changes at the deepest level
<poolie> i think it would be good to do that as a review into /doc/developers fairly early on
<poolie> not as a fait accompli with teh code
<lifeless> for instance, using a hacked xdelta rather than a custom compressor
<lifeless> poolie: uhm, that sounds like committing to it before its done; I'd rather not do that. Why not just discuss on the list like we do for other conceptual changes
<poolie> i don't mean it has to be frozen before the code is done
<poolie> obviously that would be inefficient
<poolie> just that it might be worth having some of that discussion around a spec, rather than around either the code or just an informal description
<lifeless> I'm clearly missing something
<lifeless> I'm off doing research at the moment
<lifeless> aiming to decide on what spec will work best
<poolie> i'll try again
<lifeless> where best is 'the C version will be fast enough that we are happy for a few years'
<poolie> i'd like a spec to be reviewed before it is too late to change the code
<lifeless> but without waiting for the code to stop changing
<lifeless> and the code changes change the spec
<lifeless> Whatever, we're spinning. I'll send in a doc/ patch before I send in the main code if that will make you happy, but unlike other changes where we can clearly describe what we want, this is deep down under an already defined interface
<lifeless> I don't understand what process hole doing this will solve.
<lifeless> possible conversation bug: I'm assuming you just want me to send in docs early, not to change my actual development process for thisl
<lifeless> as my development process has for a very long time had plenty of discussion on list and circulation of ideas so its not a design-bomb & code-bomb situation
<lifeless> if you want my development process to change; perhaps we should talk about what is going wrong there rather?
<lifeless> s/ rather//
<lifeless> beuno: btw, bzr-search now has '-foo' support
<lifeless> beuno: but it doesn't quite play well with suggestions; TODO
<poolie> lifeless: that was a good explanation of your concerns about .bzrrules, i thought
<lifeless> thanks
<lifeless> jelmer: ping
<jelmer> lifeless, pong
<lifeless> do you have any thoughts on how we can get jstowers productive again ?
<jelmer> lifeless, I'm working on getting those file text revids stored in file properties
<jelmer> lifeless, as to the current broken push, I think that's only really fixable by dumping the svn repo and reloading it without those properties (or adding the text-revid properties manually once bzr-svn supports them)
<lifeless> jelmer: would it be possible to script that last step for him ?
<lifeless> I think that would be really nice to do if we can :)
<jelmer> lifeless: In theory we could though it's a lot more work than just fixing it manually
<jelmer> since we don't have any functions for modifying svn dump files
<lifeless> well
<lifeless> we can't easily dump and load the svn, its gnomes production svn
<lifeless> is there some other way, perhaps rebasing rather than merging, or something
<jelmer> lifeless, well, rebasing rather than merging will prevent this problem from happening again while the fix isn't in yet
<jelmer> it doesn't help with the existing repository though
<lifeless> well I was suggesting dumping the existing bzr repo
<lifeless> doing a fresh conversion from current svn; and rebasing his personal branches
<jelmer> ah, yeah, that'll fix it as well
<jelmer> actually, I think just starting out with a fresh branch and pulling from his personal branch will do it
<jelmer> since that shouldn't try to fetch any ghosts, right?
<lifeless> right
<lifeless> do you want to note this in the bug (he is subscribed right?)
<igc> hi all
<lifeless> hi igc
<lifeless> igc: I sent the mail we discussed
<igc> hi lifeless
<igc> lifeless: thanks, I'm reading through email now
<lifeless> igc: btw - re subclassing WorkingTreeFormat4
<lifeless> I think its better to invert the relationship - to bring in newer formats as superclasses
<igc> why's that?
<lifeless> so that our latest-and-greatest is higher up the hierarchy
<lifeless> (if they are not siblings that is)
<igc> lifeless: is performance the driver?
<lifeless> I mean - having format4(format3), format3(format2) etc gets quite convoluted and makes it hard to move format2 out to a plugin
<igc> logically, a new format adds things
<igc> ah - ok
<lifeless> so when there is a hierarchy,  having format2(format3), format3(format4), format4(object) means that the oldest code is a leaf node and more easily removable
<lifeless> often though we'll actually have something like
<mwhudson> beuno: hello
<lifeless> format2(xmlformat), format3(xmlformat) format4(dirstateformat), format5(dirstateformat), xmlformat(dirstateformat)
<lifeless> dirstateformat(object)
<lifeless> or soemthing like that - more a tree
<lifeless> bug the goal over time has to be maintenance of the code base, not representing the order things got added to the code :)
<igc> agreed
<beuno> mwhudson, howdy
<mwhudson> beuno: i'm hacking at a themed directory listing
<mwhudson> beuno: but it's turning into real hackery
<Peng_> I was about to say "yay", but..oh.
<mwhudson> Peng_: red greed refactor, right?
<beuno> mwhudson, ah, yes, I did that once too
<beuno> it got so ugly I reverted
<mwhudson> heh
<beuno> lifeless, ah, I see
<beuno> - doesn't play well with suggestions?
<beuno> (cool, btw)
<lifeless> yeah, doing Robert -xml in the box gives no suggestions
<lifeless> its a search bug not loggerhead:
<lifeless> search/trunk$ bzr search -s Robert -- -xml
<lifeless> Suggestions: []
<lifeless> /search/trunk$ bzr search Robert -- -xml | wc -l
<lifeless> 46
<beuno> lifeless, ah, I see
<beuno> I don't think it's a feature you'd use with autocomplete anyways
<lifeless> why not ?
<beuno> even though it is a bug you'd want to fix
<beuno> well, if you already know that much, you'll probably search anyways
<lifeless> perhaps
<lifeless> still, ELATER
<beuno> yeao
<beuno> autocomplete currently suggest searches
<beuno> I'd like to look into providing results
<lifeless> exactly
<lifeless> mmm
<beuno> I have a few ideas for search which may be cool
<lifeless> could be interesting
<lifeless> I'd love to be able to arrow key down into the suggestions
<beuno> yes, me too. It's a tricky one though
<gerel> hey, just an easy one, is it safe to run two dedicated servers, one  read-only and another with write access, both for the same repo ?
<lifeless> works on google ;)
<lifeless> gerel: yes thats fine
<gerel> lifeless: thank, you're a bzr dever ? :-) (just curious)
<beuno> yeah, damn google makes everybody look bad
<lifeless> gerel: yes
<lifeless> beuno: actually I meant 'why not see what they do :P'
 * gerel just tried www.cuil.com
<beuno> lifeless, I know how to do it, it's just hard  :)
<gerel> big bubble on search engines these days
<gerel> lifeless: many thanks for your help
<lifeless> beuno: ah, what makes it hard?
<beuno> I could peak and see if it's easily re-usable, but google isn't usually some place you can copy javascript off
<lifeless> gerel: well, people have been trying for what, a decade now? to dethrone google
<lifeless> I suspect it needs some radical new approach rather than just tweaks
<beuno> lifeless, keyboard keys and browsers don't play well, and re-inventing widgets like drop down lists is complicated too
<lifeless> (like pagerank was when it came out)
<Odd_Bloke> What sort of message should I use with 'bzr record'?  I'm not sure what I'm meant to be describing.
<beuno> yeap, re-write parts of the javascript is needed
<lifeless> Odd_Bloke: you are recording the: list of threads, the tip of each thread
 * igc lunch, then reviewing jam's MultiWalker patch
<beuno> lifeless, either way, it's on my ToDo list. I want to make search really useful on LH
<lifeless> :->
<lifeless> Odd_Bloke:  you should record before you push; and the message would be something about where you are up to in the overall shape of things - like a commit message is for an individual branch
<Odd_Bloke> lifeless: Cool, thanks.
<poolie> lifeless: i sent a pretty small patch for bug 252428, would appreciate if you could look at that
<ubottu> Launchpad bug 252428 in bzr "stacking must always grab full inventories" [Critical,New] https://launchpad.net/bugs/252428
<gerel> lifeless: its just we need a big web classifier that keep us from the irrelevant data that makes us waste time, i thing in 20 years the inet as we know it, totally free and public, will change
<gerel> lifeless: the big corps want to control us all, kill the p2p and what not
<poolie> gerel, reminds me of the boltcutters a security engineer friend used to keep in his drawer
<lifeless> gerel: depends on which corp :) big telcos _love_ p2p - more money
<poolie> wow amazing
<poolie> gtk just fixed an incredibly long standing bug
<poolie> lifeless: thanks
<gerel> lifeless: hah, maybe but they'll earn more if they sell you a web pack with 20 sites too :-)
<gerel> lifeless: we better start mesh networks with Access points
<lifeless> well, mesh is fun
<lifeless> we have quite some engineering and political discussions to make it viable large scale
<gerel> lifeless: yeah, and it'll be the only free thing you'll be able to do :-P
<gerel> lifeless: where ?
<mwhudson> <beuno> mwhudson, ah, yes, I did that once too <beuno> it got so ugly I reverted
<lifeless> poolie: was it a bug you filed?
<poolie> yes
<poolie> i may have been filing a dupe
<poolie> basically it is that you can only click a button after your mouse moves into it
<poolie> if it appears under your mouse, or changes from disabled to sensitive while it's under your mouse, you can't
<poolie> you have to move out and back in
<poolie> sounds trivial; apparently it was really hard
<lifeless> gerel: well, we need enough spectrum reserved; we need solid p2p dns (security,robustness, etc); we need solid adhoc networking across the entire mesh etc etc - if you decentralise the entire stack its a lot of work, but thats what the end goal is IMO
<pickscrape> I bet it's nice to put things like that to bed
<poolie> i have been getting and deleting "me too" mail for the last N years
<lifeless> poolie: :>
<gerel> lifeless: correct, i guess we'll be forced to
<lifeless> I have the odd bug like that
<jelmer> lifeless: I'll follow up with him once I fix this bug (which should be < 1 day now)
<mwhudson> beuno: i see what you mean now :)
<jelmer> lifeless, Odd_Bloke: Is PQM using lp or bb for merge requests now?
<poolie> i thought it was using lp
<lifeless> jelmer: cool
<lifeless> pqm is using a bit of btoh
<gambler> just experimenting with bzr...i think i found a small bug
<gambler> http://pastebin.com/m543a24ad
<beuno> mwhudson, lol
<beuno> maybe we should generate that different
<beuno> and not hack around it
<lifeless> gambler: what are you saying is a bug ?
<gambler> it looks like it replaced the ~  with a unicode or something
<lifeless> thats URL escaping
<gambler> ssh usually expands that
<gambler> ah ok
<lifeless> it will be handled correctly
<mwhudson> beuno: well, there is some grottiness in filesystem.py that should be cleaned up i guess
 * beuno wonders why he doesn't get email when people ask questions about loggerhead
 * beuno wanders off to bed
<mwhudson> beuno: i just set up ~loggerhead-team as an answers contact a few minutes ago
<beuno> mwhudson, aah, ok. That makes sense
<beuno> I'll unsubscribe
<mwhudson> so now launchpad will send us even more mail!!!
<beuno> shouldn't that be the default?
<mwhudson> i have no idea
<beuno> oh, wait
<beuno> I think I activated answers
<beuno> a few days ago, trying to change something else
<beuno> sorry  :)
<mwhudson> ah :)
<beuno> damn people are fast to find stuff
<mwhudson> good idea
<mwhudson> but strange that the owner isn't a contact by default
<beuno> it is
<beuno> anyway, off to be for real this time
<beuno> mwhudson, if you get anywhere with the templating, let me know
<beuno> I'm planning on working on that tomorrow
<mwhudson> beuno: ok, there's a branch on lp
<beuno> not that it should incentive you to drop it in any way  :)
<mwhudson> i'm not going to be working on it much more...
<mwhudson> (today, anyway)
<mwhudson> but yeah, funny questions like
<mwhudson> "should there be tabs?"
<mwhudson> beuno: g'night
<beuno> mwhudson, yeah, sometimes giving karma to people fires back  :p
<beuno> night!
 * Odd_Bloke --> lunch
<Odd_Bloke> beuno: Sleep well!
<beuno> Odd_Bloke, you too, whenever it is you'll be doing that
<beuno> mwhudson, LP won't let me get your branch
<beuno> beuno@beuno-laptop:~/bzr_devel/loggerhead$ bzr branch lp:~mwhudson/loggerhead/themed-directory-listing
<beuno> bzr: ERROR: Not a branch: "bzr+ssh://beuno@bazaar.launchpad.net/~mwhudson/loggerhead/themed-directory-listing/"
<beuno> I suppose because it's private
<mwhudson> beuno: the push hasn't finished yet
<beuno> ah
<beuno> I still don't trust LP when it says it hasn't. It will take a while to regain it's trust
 * beuno closes laptop
<jml> poolie: hi
<igc> poolie: jam has re-posted a patch for BranchBuilder after you voted tweak. Did you want to re-review it or would you like me to do it?
<Odd_Bloke> I'm trying to write a test for a plugin that uses XMLRPC.  Do we have something in bzrlib that will allow me to capture any POST requests made to a URL?
<lifeless> the smartserver code demonstrates a post handler
<Odd_Bloke> Ah, OK, that is working, I was getting confused by something else.
<poolie> igc, hi
<poolie> jml, hi to you too
<poolie> spiv, ping?
<poolie> spiv, i saw your patch for 251871 was tweaked, is it in now, or ok to go in?
<poolie> igc, i'll re-read it but you're welcome to if you want to
<poolie> it should not be very complex or controversial
<igc> poolie: I'm looking at markh's changes to setup.py so I may not get to it
<igc> .. today
<poolie> np
<spiv> poolie: It's not in yet, I'm tweaking it at the moment (adding a test)
<spiv> poolie: the fix itself isn't being changed by the tweak though.
<poolie> ok thanks
<spiv> poolie: just fired the tweaked version to PQM, in fact.
<poolie> did it really drop my merge? :/
<igc> night all
<poolie> night ian
<poolie> sleep well
<poolie> spiv, if you're still here
<poolie> pqm says my stuff is merged but i can't see it in trunk
<poolie> what do you see as the last rev of bzr.dev?
<Odd_Bloke> "(robertc) Fix bug 150438 - dirstate corruption due to invalid..."
<ubottu> Launchpad bug 150438 in bzr "corrupt inventory deltas are not detected by dirstate" [High,Fix released] https://launchpad.net/bugs/150438
<Odd_Bloke> poolie: ^
<poolie> mm thanks
<poolie> maybe pqm has gone for the weekend :/
<lifeless> me too
<poolie> :)
<poolie> lifeless: well, if you want to poke it sometime that would be good but there's no rush on my account
<lifeless> let me finish this hardy upgrade
<lifeless> evms headaches
<fullermd> poolie: No actual code on that repo tests reorg thing?
<poolie> do you mean no patch
<fullermd> Yah.
<poolie> thanks
<poolie> BB should really say 'you silly silly boy' not 'accepted'
<fullermd> It's not really paying attention right now; it's off cavorting with pqm for the weekend   :p
<poolie> night all
<Peng_> Yikes! Loggerhead's SQL cache got corrupted, leaving most pages as 500 errors for...I dunno how long.
<Peng_> Wow, good timing! It only happened like 10 minutes ago.
<Peng_> Poor Googlebot. It even got one 503 error when I shut down LH while fixing this.
<gour> what bzr+http protocol requires on the server side?
 * gour is dissussing in #ghc about possibility to use bzr for ghc
<james_w> hey gour
<james_w> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#serving-bazaar-with-fastcgi
<gour> ta
<james_w> there may be other ways
<james_w> basically you need to make your http server hand of some requests to a bzr process
<gour> ghc is seriously considering switch from darcs, but, unfortunately, bzr is not considered seriously enough
<james_w> yeah, I saw the wiki page
<gour> james_w: have you seen irc log as well?
<james_w> no, I haven't
<gour> it's referenced there, iirc
<gour> http://hackage.haskell.org/trac/ghc/attachment/wiki/IRC_Meetings/ghc-metting-2008-07-23.log
<james_w> thanks
<gour> james_w: i wrote (on #ghc) to JaffaCake (he is one of main ghc devs) about bzr...sending blog about mysql adoption etc.
<gour> it would be nice of some bzr dev could address some of their issues 'cause wiki page has some strong Pro points
<gour> cherry-picking is the one
<fog> push push push. after 3 months of bzr use for our internal projects let me thank all bzr developers. kudos! push push push.
<james_w> 178 	[17:22] bos:
<james_w> 179 	git has about 2x the number of users of hg, and only one significant project uses bzr.
<james_w> 180 	[17:23] JaffaCake:
<james_w> 181 	that rules out bzr, I think
<gour> right, that's why i mentioned mysql to JaffaCake
<james_w> the mysql link probably helped there then, thanks
<james_w> and soon bzr will have more source code in it than any of the others, just that it won't be used by the projects themselves all the time
 * gour thinks bzr is the most balanced dvcs...and still improving performance
<Peng_> Could the ghc devs dry out different DVCSes to see which one they like best?
<gour> heh, it does not always go like that
<Peng_> Err, try out*
<gour> some people on #ghc complain about problems building on mac osx
<alsuren> I have just realised that I included an mp3 file in my bzr repo a few commits ago, so sharing it over http is going to be slow. What's the best way to remove it from the packs?
<LarstiQ> gour: that is a little bit unclear?
<LarstiQ> gour: they do know of 10.5 and 10.4 dmgs at http://bazaar-vcs.org/Download ?
<gour> LarstiQ: it looks it was some 10.4 issue and/or tiger & python-2.5
<Pilky> gour: I don't think 10.4 has python 2.5
<Pilky> if they use the OS X installers it should include it
<gour> Pilky: they wrote "python 2.5 is broken on tiger". i don't know anything about osx versioning
<Pilky> Tiger is 10.4, Leopard is 10.5
<gour> heh, funny
<Pilky> just tell them to use the OS X installers unless they have a specific need to build
<Pilky> yeah Apple is cat crazy with OS X
<Pilky> Cheetah, Puma, Jaguar, Panther, Tiger, Leopard, Snow Leopard for 10.0 - 10.6
<gour> it seemed they were able to install it
<LeoNerd> Surely they'll run out eventually...
<gour> lol
<Pilky> probably by 11.0
<LeoNerd> Have to start taking more obscure ones.... lynx, ocelot, cerval.. onyx?
<Pilky> well there's still Lion available
<LeoNerd> Though I'm very disappointed there's no Lion yet
<Pilky> but I think most people are waiting for Tabby Cat
<LeoNerd> Or maybe they're saving that for the ultimate conclusion, the pinacle, the peak in perfection. :(
<LeoNerd> :)
<Pilky> heh
<gour> what about Monkeys?
<Pilky> well they managed to push Lion off for a while with Snow Leopard
<Pilky> I can see Ocelot possibly being used, I think lynx has some issues with trademarks or something
<LarstiQ> Liger!
<Pilky> heh
<fullermd> Sphin/X
<Pilky> I just need to get enough money to get a new ADC account so I can get my hands on Snow Leopard, it's meant to have some pretty cool stuff in it. Unfortunately I don't currently have Â£300 spare :p
<Jayzee> I have a repository with 2 branches, if I want bazaar to execute a script when files have been comitted to a specific branch (for all users), what do I need to do?
<james_w> hi Jayzee
<Jayzee> james_w: hello there
<james_w> you can write a plugin that provides a post_commit hook and activate it for the branch that you want
<Jayzee> I got that but I suppose the plugin is not supposed to be in my home then?
<Jayzee> since I'm not the only comitter
<james_w> if you want it more general than running "bzr commit" in that specific branch, e.g. to run after pushing to that branch, then you can use a "post_branch_change_tip" hook, or whatever it is called
<james_w> no, it will need to be in bzrlib/plugins wherever bzr is installed
<james_w> or in every users' ~/.bazaar/plugins/
<james_w> or you could do something with BZR_PLUGIN_DIR
<LarstiQ> Jayzee: is this a centralized setup?
<Jayzee> I can't find anything abut post_branch
<alsuren> Jayzee: what does your script do? there might be a better way
<Jayzee> yes, It's one machine with 2 developers comitting
<LarstiQ> Jayzee: post_change_branch_tip
<Jayzee> basically I would like to do a "bzr export ..." when stuff has been comitted to stable-branch
<LarstiQ> but as alsuren said, what is it you are trying to achieve?
<james_w> ah, thanks LarstiQ
<LarstiQ> right
<Jayzee> I would like code for our website to be copied to www-root when changes are being made to stable branch
 * LarstiQ nods at Jayzee 
<LarstiQ> Jayzee: post_change_branch_tip sounds like the right thing then
<james_w> you *could* do it from cron, but post_change_branch_tip would work nicely
<Jayzee> one more thing, do I really need to write a plugin in python??
<Jayzee> I'm more confortable in php/bash
<Jayzee> comfortable
<james_w> I don't know what the status of the shell hooks work is
<james_w> Jayzee: this plugin should not be too difficult
<james_w> let me have a look for you
<Jayzee> thx james
<alsuren> it strikes me that having a branch type that forces the working directory to always look like the last commit would be a useful feature
<james_w> alsuren: yeah, that may be something useful
<james_w> I'm not sure what the best way to expose that would be
<lifeless> alsuren: that implies that the working dir cannot be decoupled
<lifeless> alsuren: and that it can't work efficiently over the network without a smart server
<lifeless> alsuren: and that branch changes have to fail if there are local edits that conflict in the tree
<lifeless> this doesn't mean its not usefl
<lifeless> just the implications
<alsuren> lifeless: I'll go through your points in order
<Jayzee> it would be nice if bzr export would export to a already existing directory, in that way you could have the most recent using a hook
<lifeless> Jayzee: thats worth filing a bug on I think
<LarstiQ> Jayzee: are you per chance working locally on the machine with the www-root?
<lifeless> Jayzee: btw, are you aware of the push-and-update, and also the bzr-upload plugins ?
<Jayzee> yes, I have total access to it
<LarstiQ> Jayzee: then the plugins lifeless mentioned shouldn't be too slow in operation
<alsuren> the point is for publishing branches in a read-only form that doesn't require users' knowledge of bzr. all development would happen elsewhere
<Jayzee> lifeless: I'm just started setting everything up, I come from svn-world where there's no push-update
<james_w> beuno: hey, you around?
<alsuren> lifeless: the second point is possibly valid, but if your project were big enough to care about performance, you would be using a smart server anyway. The time saved by being able to publish with a single push operation is massive
<alsuren> lifeless: you will have to explain your third point
<james_w> is there a way to get a boolean answer from a branch config?
<james_w> and shouldn't hooks be passed an outf?
<lifeless> alsuren: I think my first point is valid too
<lifeless> alsuren: your refutation is actually talking about goals not about implementation; you proposed an implementation of 'publishing branches in a read-only form that doesn't require users' knowledge of bzr.'
<james_w> Jayzee: I think this would be a useful thing to have as part of bzr-upload, and it would make the plugin much more robust. However there has to be some refactoring in that plugin first. How urgent is this for you?
<alsuren> lifeless: ok, so what's the recommended implementation currently?
<lifeless> bzr-upload or bzr push-and-update
<Tapout> is bazaar faster than svn when it comes to really large projects?  I've been running an svn commit and it's been going for about 1 hour and only 1GB done out of 4GB
<alsuren> lifeless: thanks. I suspect that bzr-upload is what I'm looking for (I assume that it is possible to use bzr pull on a bzr-uploaded branch?)
<alsuren> Tapout: what are you storing in your repository that makes it 4GB?
<Tapout> it's a website ... docs+pdf's, text files
<Tapout> svn add * ; svn commit -m "Import"
<Tapout> this is on a 1Gb network, average about 35-40MB/sec between machines
<james_w> alsuren: bzr-upload only uploads the tree
<Jayzee> james_w: since I will be not using any distributed version control any time soon I think it's better for me to stick with svn for time being (and skip python scripts :))
<james_w> alsuren: if you bzr-upload to the same location as the branch then it should all just work
<james_w> Jayzee: ah, shame. I was just wondering whether I should do a quick hack for you know, or whether you could wait a little while until we have a really elegant solution in bzr-upload
<Jayzee> james_w: you can still do it properly, sooner or later I'll look at bzr again :))
<james_w> Jayzee: great, and we'll have a really nice solution for you then :-)
<alsuren> james_w: ah. so it's still 2 commands if I want to use it as a public site and bzr repo at the ame time?
<Jayzee> james_w: yeah, hooks are good to have :)
<james_w> alsuren: yeah
<james_w> alsuren: but I'm working to make it automatic right now
<lifeless> alsuren: I'm not 100% sure, but beuno here is one of the authors of bzr-upload
<lifeless> alsuren: I'd wager you actually want bzr push-and-update though
<alsuren> lifeless: already checked, and my department doesn't have bzr installed
<lifeless> alsuren: ah thats a shame. if python is on the machine you could drop it in your home dir ;)
<alsuren> lifeless: tried that. installing bzr from source seems to require python-devel installed
<james_w> alsuren: was that for the pyrex extensions?
<alsuren> james_w: might have been... this was 3 months ago
<james_w> hmm, I don't think python-devel should be required
<james_w> except if there is something packaged in there that is really a runtime thing
<alsuren> error: invalid Python installation: unable to open /usr/lib64/python2.5/config/Makefile (No such file or directory)
<alsuren> opensuse
<alsuren> when I'm in the department, I just use git instead
<alsuren> james_w: if you fancy debugging, there's your info
<lifeless> alsuren: we don't need the extensions - you can just do 'tar xzf bzr-1.6b4.tgz' ; bzr-1.6b4/bzr help
<lifeless> alsuren: for that error, is there a 'python-dev' or similarly named package available for opensuse ?
<james_w> lifeless: do you know what change is causing "Exception: Old server API in use: <bzrlib.transport.ftp.UnavailableFTPServer object at 0x978b22c>, setUp() takes exactly 1 argument (2 given)"?
<lifeless> james_w: is that in a plugin ?
<alsuren> yeah, but I'm not root
<lifeless> alsuren: ok, well that would be whats missing for the makefile to work; but as I mention above, the C extensions are 100% optional
<james_w> lifeless: yeah, I'm testing bzr-upload
<lifeless> james_w: I'd annotate the constructor
<alsuren> okay, so if I just put a symlink from bzr to ~/bin, it should work?
<lifeless> james_w: that will give you the patch that changed the signature ;)
<lifeless> alsuren: yeah.
<lifeless> $ ls -l ~/bin/bzr
<lifeless> lrwxrwxrwx 1 robertc robertc 43 2007-08-16 20:16 /home/robertc/bin/bzr -> /home/robertc/source/baz/bzr-test-fixes/bzr
<james_w> lifeless: ok, thanks
<lifeless> alsuren: all it sacrifices is some speed
<alsuren> lifeless: okay, well using bzr 1.4, on the branch that I just pushed over sftp, I get bzr: ERROR: No WorkingTree exists for "file:///homes/courses/ugrad/05/dl325/swingbar/.bzr/checkout/"
<lifeless> alsuren: run bzr checkout . in the swingbar directory
<alsuren> lifeless: thanks (maybe that error message needs changing)
<pickscrape> Are there any bugs in beta 3 that would make it inadvisable for use server-side?
<alsuren> pickscrape: why don't you try it and find out (isn't that what betas are for? :P )
<james_w> ah, UnavailableFTPServer wasn't transitioned to the new API
<pickscrape> alsuren: :)
<ignas> what do I do with a lightweight checkout if someone deletes the branch i was bound to?
<ignas> i am getting: bzr: ERROR: Not a branch: "https://code.launchpad.net/".
<ignas> when trying to bind, unbind, switch, info or status
<james_w> hmm, I assume switch should work
<james_w> it may be a bug though
<james_w> ignas: yeah, can you file a bug please?
<ignas> :'(
<james_w> echo -n new-location >! .bzr/branch/location
<james_w> that should fix it up
<james_w> -n is important
<ignas> yeah, thought of doing that
<james_w> I don't know if >! is a zshism though
<ignas> no idea, replaced it with plain ">"
<ignas> and it worked
<jam> ignas: isn't there a 'bzr switch --force' ?
<jam> james_w: >! *is* a zsh-ism
<jam> other shells don't care if the target exists already
<fullermd> Actually, >! exists in tcsh...
<fullermd> (though I've never used it, since I keep noclobber unset)
<ignas> jam: don't know really, i'd expect that i should get a warning that tells me to do --force it instead of an error though
<james_w> --force        Switch even if local commits will be lost.
<james_w> it may still work, but it isn't obvious
<james_w> I think there's a bug there somewhere, either that it isn't possible, or that it isn't obvious
<jam> james_w: I would probably say the help should be clearer, and the switch code should be taught about not being able to open the target of the lightweight checkout and letting the user know about it
<jam> certainly bugs to be fixed
<ignas> why should I lose my local commits on a lightweight branch if i am switching it?
<ignas> i don't think current behaviour of force is related to this kind of problem
<jam> ignas: I think it *is*, it just isn't documented well
<jam> The reason we require access to the old branch
<jam> is to make sure nothing ends up lost
<jam> but the specific help just mentions the heavy-weight checkout form
<jam> where you could have local commits, and a switch will lose them
<ignas> i see
<jam> I'm 90% sure it is just a doc issue
<ignas> just that relation between - "lost checkins" and "branch that was moved" is not completely obvious
<ignas> i mean - if I would get a warning - you can't switch, we will lose your changes, because we can't access the original branch
<james_w> --force doesn't work in my test here
<ignas> then - yes
<ignas> --force would be the thing I'd try
<ignas> but not with the "old branch does not exist!" error
<lifeless> ignas: lose local commits? lightweight brnaches don't have local commits..
<ignas> lifeless: precisely, so even if  "switch --force" would fix missing remote branch problem, with --force being described as "switch even if local commits will be lost" I would not have any way of finding out that it is the option I need
<ignas> and even without local commits, you still can lose local changes
<ignas> if i have changed some file, and the remote branch disappeared, bzr won't be able to find out which files I have modified, unless you do some magic that I am not aware of
<lifeless> ignas: what changes have you list ?
<ignas> ?
<pickscrape> lost?
<ignas> ahh, well - my lightweight checkout was not modified
<ignas> I think
<ignas> ok
<ignas> it was modified
<ignas> but switching the location
<ignas> did not lose anything
<ignas> so yeah, you are doing some tracking somewhere
<lifeless> ignas: :) gotta be careful of these assertions :)
<ignas> i kind of assumed that if you are losing local checkins, chances of keeping local changes in place without the parent branch being present are pretty low
<ignas> still - having an interface to fix --ligthweight checkouts would be kind of nice
<lifeless> whats broken ?
<ignas> make a lightweight checkout, remove the original branch (or move it) try bzr st,info, switch, bind, unbind ...
<ignas> i had to edit .bzr/branches/location to fix it
<lifeless> hmm yes
<lifeless> please make sure there is a bug open for this
<lifeless> if it fails on 1.6b4
<ignas> could someone with 1.6b4 check it, because I don't really have a bzr checkout around ...
<ignas> only bzr that is available in ubuntu (ppa one)
<ignas> 1.6b3
<ignas> i can repro it on 1.6b3
<ignas> https://bugs.launchpad.net/bzr/+bug/198821 is there already
<ubottu> Launchpad bug 198821 in bzr "switch of lw checkout shouldn't require force when branch moved" [Medium,Confirmed]
<ahasenack> Hi, I'm using bzr 1.3.1 on a client and branching from a server that is running 1.6b3, and I get this warning on the client: "Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)"
<james_w> ahasenack: hi
<ahasenack> james_w: hi
<james_w> the problem is that the verb was removed, and the code just assumes that means that it is too old, but in this case it is too new
<james_w> there is a bug open, but I believe it's marked "Won't Fix"
<james_w> the message is misleading, but everything still works
<ahasenack> ok
<spiv> If you update the client to 1.6b3 you won't see that message.  That's a fix ;)
<ignas> what is the rationale behind showing this to users a.k.a. clients, it's like firefox telling me that some server is using an old version of apache :/
<spiv> The reason is that when client and server versions are mismatched things can sometimes be surprisingly slow
<spiv> Because the protocol is still in flux, so while things will still work, the mismatched versions might not be able to figure out how to do it quickly.
<james_w> yeah, I guess it's like the discussion over when to show an upgrade message for formats
<spiv> So by telling the user that there is a mismatch like that it lets them know how to fix bad performance.
<ignas> my point is - I can't access most servers, much less upgrade software on them
<spiv> That's the logic, anyway.  Ideally there would be some way to suppress those warnings if you're sure you don't care about them, but no-one has cared enough to volunteer a working patch ;)
<ignas> so the benefit of the warning is like - firefox telling me that "this site is slow, because they misconfigured caching, it's not our fault"
<spiv> Pretty much.  "We know this is sucking, here's why, now you know who to talk to to get it fixed."
<spiv> We are erring on the side of verbosity here.
<spiv> I think it'd be fine to have e.g. a locations.conf setting to suppress that warning, so you could choose not to be informed about it for particular sites.
<spiv> The long term fix is to stop changing the protocol so much :/
<alsuren> also, there's something to be said for encouraging everyone to keep their softare up-to-date. Especially with a project that's moving as fast as bzr
<ignas> well - if you are assuming that most of bzr users can do something about servers they are using ....
<ignas> then showing warning by default makes sense
<alex-weej> hello
<alex-weej> when i commit to my local repo i'd like for it to be mirrored instantly online when possible
<alex-weej> is it "bind" that i need?
<alex-weej> i'm using lp btw
<ignas> yes
<spiv> Many can, especially if you count "email the sysadmins of the server" as doing something about it ;)
<spiv> I don't much like that it makes it feel like bzr is nagging you, especially because you might not be able to do something about it, at least not immediately.  But I'd rather give more information about what is going on rather than less.
<alex-weej> so how do i tell bind to use the default push location?
<ignas> bzr info
<ignas> copy the url
<ignas> and do bzr bind url
<spiv> Anyway, it's time to sleep.
<jam> beuno: ping
<jam> spiv: sleep well spiv
<spiv> jam: thanks :)
 * spiv -> really sleep!
<beuno> jam, pong
<jam> beuno: I'm happy to see the new theme land on Launchpad, but at least here, the annotate view has far too much whitespace
 * beuno looks
<jam> I don't know if this is LP specific, or if it is part of the latest trunk
<jam> But certainly something is a bit off with the CSS
<wingo-tp> lifeless: cough poke #239499 :)
<beuno> it's the same for both
<beuno> it's the same for both
<beuno> so fixing trunk should fix LP
 * beuno files bug
<jam> bug #239499
<ubottu> Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Medium,Confirmed] https://launchpad.net/bugs/239499
<beuno> jam, does the line spacing in diffs seem fine to replicate in annotate?
<jam> beuno: checking now
<beuno> jam, http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk/revision/190
<beuno> (LH in LP seems very slow today)
<jam> beuno: it is a lot better, but compare it to: http://bzr.arbash-meinel.com/gvim_spacing.png
<jam> That is the spacing in my text editor
<jam> You can make the text bigger if you give less whitespace
<jam> Anyway, if I had to chose between current, and diff view, I'd pick diff view
<jam> But *I* would probably go further
<jam> *I* am not a web designer or graphics designer, and my fashion sense is poor, though
<beuno> sure, I'd prefer to fix everything at once
<beuno> I'll make the bug about spacing in general
<jam> I would guess the spacing in T-bird is about the same as gvim
<beuno> and see if it looks too ugly  :)
<beuno> jam, bug #253981
<ubottu> Launchpad bug 253981 in loggerhead "Line spacing for code text is too big" [Medium,Confirmed] https://launchpad.net/bugs/253981
<jam> joy.... the other day they reset LP passwords, and now I'm on Linux so I have to log in
<jam> Then I log in to the normal site
<jam> which redirects me to edge
<jam> and I'm not logged in again
<james_w> beuno: hey lp:~james-w/bzr-upload/auto_upload
<james_w> what do you think about including that?
 * beuno branches
<james_w> it don't work if you commit from a checkout in the same shared repo as the branch with the configuration, but it looks like that may be a bzr bug
<beuno> james_w, I really like the idea. How would you specify which branch you want to be auto-uploaded?
<james_w> auto_upload = True
<james_w> in wherever you put upload_location
<beuno> ah, right, I missed that
<james_w> upload_automatically may be better as it has "upload" first, but it's a pain to spell
<beuno> it would be cool to be able to set it from the command like, but the branch looks very good as-is
<james_w> yeah, sorry, didn't add any docs yet
<james_w> bzr upload --auto?
<beuno> yeah, that sounds good
<beuno> and --noauto?
<james_w> good idea
<james_w> I need to work out how to test it as well
<beuno> and, vila will kill me if I add anything without tests
<beuno> that's it  :)
<beuno> I have some LH work today, but I'll try and help you out with this so we can merge
<beuno> it looks very good, so thanks  :)
<james_w> I should finish my TreeTransform patch first though
<james_w> you don't mind adding the class in __init__.py
<james_w> I couldn't run the command from the hook, as the source branch is already write locked.
<beuno> not at all, it moves logic out of the command
<beuno> or we could move logic out of the command, actually  :p
<beuno> james_w, anyway, just a little bit of work on top of that, and it's perfect
<james_w> beuno: can you try it from inside a shared repo?
<james_w> i.e. create a shared repo with a branch in, upload that somewhere, then add the auto_upload = True
<beuno> james_w, yeap, just need to pack up and move to the office for a few hours, so I will in a bit
<james_w> then checkout in the same shared repository, and commit from there
<james_w> beuno: sure, no problem, just wanted to rule out a screw up on my end
<beuno> james_w, I have a use case for this at work, so I'll plug this right in so we can test it a bit. It even uses a shared repo already
<james_w> beuno: great, I love it when a solution finds a problem
<jam> james_w: why not just "upload_auto = True"
<james_w> that would work I guess, it just feels ungrammatical
<james_w> it's not a novel though
<jam> upload_automatically_for_thou_art_my_biznatch = True
<jam> I don't think I would read that book, though
<robtaylor> lifeless: just read your partial commits idea, sounds lovely!
<thekorn> hi all,
<thekorn> I have once again a bzrlib question,
<james_w> hey thekorn
<thekorn> let's say I know the path to a versioned file
<thekorn> hi james_w
<thekorn> how can I get the revno of this file?
<thekorn> similar to   bzr revno /boo/bar/baz.py
<james_w> I'm not sure whether "bzr revno /boo/bar/baz.py" does what you think, let me check
<james_w> yeah, that just prints the revno of the last revision on the branch containing that file
<james_w> you want to know the revno of the last revision that changed that file?
<thekorn> james_w, no just the current revision of this the branch which contains this file
<thekorn> james_w, sorry I just found it in buildins.py
<james_w> cool
<thekorn> it is BzrDir.open_containing(location)[0].revno()
<thekorn> that was easy :)
<thekorn> actually not BzrDir but bzrlib.branch.Branch, but it works
<james_w> beuno: hey, are you settled in the office yet? I'd like some testing advice.
<jelmer> any dd around that can upload a new version of trac-bzr for me?
<beuno> james_w, yeap
<james_w> beuno: it looks like the uploading is well covered by tests, so we just want to make sure that an upload is triggered by a commit
<beuno> correct
<james_w> You've got an interesting test strategy though, so I'm not sure of the best way to integrate with it
<beuno> right, it's less flexible then I'd like
<beuno> it seems like you have to duplicate a lot of code, right?
<james_w> yeah, that's what I was worried about
<james_w> it seems like I could have something completely separate fairly easily, but that might be too much duplication
<james_w> you wouldn't want this to be tested against different transports and things though, would you?
<Nyad> hi. I'm reading the bazaar in 5min guide, I'm trying to push to a branch on launchpad.net  so $ bzr push bzr+ssh://joseph.werd@bazaar.launchpad.net/~vorkasm-project/vorkasm/vorkasm-v1.0.4
<Nyad> but it's not working
<james_w> hi Nyad
<james_w> do you get an error?
<beuno> james_w, no, I think we can safely assume that if it works with one, it works with all. We just want to test it auto-commits
<Nyad> james_w: bzr: ERROR: Not a branch: "/home/jason/".
<james_w> sure, I'll put something together
<james_w> Nyad: are you in "/home/jason/" when you run the command?
<beuno> Nyad, you have to push from the dir that has the branch
<Nyad> oh, woops
<Nyad> n
<Nyad> The authenticity of host 'bazaar.launchpad.net (91.189.94.254)' can't be established.  I have created an ssh key pair
<james_w> Nyad: if you "ssh bazaar.launchpad.net" you will get a chance to verify the key
<rocky> i gotta say i'm not really sure the point of doing an init-repo when if i merely do a checkout or branch it doesn't need it
<luks> rocky: speed and disk space are two reasons for doing it
<asabil> rocky: init-repo is an optimization for making branching faster
<Nyad> james_w: I got the same error when I ran that
<james_w> Nyad: it doesn't let you accept the key?
<rocky> oh ok
<luks> rocky: without the shared repository, it has to copy all the data
<james_w> rocky: if you only ever have one branch then it's no win, but once you have more than one it is
<asabil> rocky: let's say that you have a branch "A", that has 3 revisions (1, 2, 3)
<luks> rocky: but if you branch in a shared repository, nothing is copied
<james_w> rocky: and if there's any chance of having more than one then I suggest you create one, it will save you effort later
<asabil> rocky: if you create branch "B" from "A", outside of a repo, then you will copy all the 3 revisions
<Nyad> james_w: it says "Are you sure you want to continue connecting (yes/no)?    "
<asabil> rocky: if "A" was in a repo, then the revisions were actually stored in the repo, and "A" only contained "pointers" to them
<james_w> Nyad: ah, you can then say "yes", and it will let you connect from now on
<asabil> so creating a branch "B" would be just a matter of pointing to the same revisions, instead of copying them
<grahal> for testing, i was tried to make my Documents directory into a bazaar repo
<grahal> it's about 600mb in size
<grahal> lot's o binaries as you may expect
<Nyad> james_w: ok that works, thanks
<grahal> when I ran "bzr add .", bzr ran for a while and I noticed it started eating up memory
<grahal> continuous scaling, 60% in a 1GB machine
<grahal> and growing
<grahal> is that expected? is the use case not supported at all?
<korpios> AFAIK bzr's optimized for source code much moreso than binary data
<korpios> I wouldn't say that use case is ignored, just that it's definitely not ideal right now
<grahal> it's a curious use case, at least to consider any sort of design decision when dealing with "add" operation
<grahal> certainly not top priority I believe
<korpios> for binary data, a more basic backup system is probably better (e.g., Apple's Time Machine)
<grahal> yeah... this test idea came to mind mind because I read some time ago the idea to do something a like apple's time machine in ubuntu
<grahal> and bzr was being considered as the backend
<grahal> google summer of code stuff
<grahal> not sure what happened with such idea
<james_w> hmm, maybe hooks aren't run in test code
<beuno> james_w, maybe you can steal code from lifeless' bzr-search
<beuno> he uses hooks and has tests
<james_w> ah, nice, I was trying to think of a plugin with tests
<james_w> er, I mean hooks :-)
<james_w> thanks
<beuno> :)
<james_w> but it doesn't test the hooks it seems
<beuno> ah, bad lifeless!
<james_w> aha, bzr-dbus to the rescue
<jam> grahal: was this during "bzr add" or "bzr commit"
<jam> If it was during "bzr add" that would be *quite* unexpected
<jam> commit wouldn't be as surprising
<grahal> sorry
<grahal> during commit
<grahal> you are right
<jam> so... our specific goal is to hold < 3 copies of any text in memory at a given time
<jam> (merge needs 3 copies to compare against)
<jam> I have the feeling we are missing something trivial in commit
<jam> which is causing us to hang on to old texts that we aren't using anymore
<jam> but I haven't personally spent the time profiling it, etc.
<jam> (It is hard to profile memory consumption in python)
<james_w> beuno: so, they are disabled, which makes sense. I can add a check that the hook is registered, and then tests triggering it manually, would that satisfy you?
<beuno> james_w, yeah, absolutely
<beuno> we can also add a message notifying the user it's auto-uploading
<beuno> or spit it out to ~/.bzr.log
<james_w> yup
<beuno> just so we know when it's auto-uploading
<james_w> and thankyou again for your contributions to loggerhead, I'm using it now and it's so much better
<beuno> james_w, I've really been enjoying it, so my pleasure  :)
<gerel> hey, can i maintain a working-tree on the main branch server such that it's updated when I commit/push to it ?
<beuno> gerel, push-and-update if you want bzr data
<beuno> and bzr-upload if you just want the working tree
<gerel> hmm
<gerel> i'll ty
<gerel> try
<beuno> and if you want for bzr-upload to upload automatically on commit, wait for a while for james_w's patch to land  :)
<james_w> beuno: it's working :-)
<gerel> beuno: when you say push-and-update you mean, bzr push, bzr update from my local working-tree ?
<james_w> just got to finish the tests and add --auto
<beuno> gerel, no, it's a plugin
<gerel> agggh
<beuno> james_w, rockin'
<gerel> beuno: it's weird since i tested it and when the repo is on my local disk it actually copies the working-tree
<gerel> beuno: but when the repo is remote, it doesn't
<beuno> gerel, right, locally, it auto-updates
<beuno> remotely, it doesn't
<gerel> pty
<beuno> that's the intended behaviour
<gerel> pity
<beuno> you can't guarantee remote updates, since you need bzr on the other side
<beuno> se we have plugins that work around it
<beuno> what's the problem with using a plugin?
<gerel> ah, nothing, but im kinda tired doing apt-get :-P
<beuno> gerel, well, it isn't packaged, so you don't have to worry about that
 * beuno ducks
<gerel> beuno: the other workaroun is issuing a checkout on the remote host
<gerel> beuno: hah forget it
<beuno> gerel, bzr co lp:bzr-push-and-update ~/.bazaar/plugins/pushandupdate
<beuno> should have it running in a minute
<gerel> nice
<gerel> beuno: in short, the --no-trees is useful only when doing local repos
<beuno> gerel, right
<evarlast> hello, I'm getting a LockFileEx error on win32 trying to branch from a network mapped drive.
<gerel> beuno: otherwise it's automatically used
<beuno> evarlast, can you pastebin the full error?
<beuno> !pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<jam> lifeless: when you wake up, can you check the PQM logs? I seem to have some patches that pass the test suite, but then "die". I don't get a success or failure message, and I don't see a commit going to the bazaar-commits mailing list
<jam> I checked to see that the tests really were running
<jam> and when I submitted one with an error, I got a failure right away
<jam> it seems something bad is happening after "make check" succeeds
<jam> Odd_Bloke: ^^ You *might* want to see if there is something to be fixed here. But you'll probably want to wait for a better bug report
<Odd_Bloke> jam: poolie was having issues as well.
<Odd_Bloke> But, yeah, I'll wait for a better bug report if one is needed.
<jam> james_w: You need to send your email to the list, I didn't CC so you didn't look as foolish :)
<james_w> jam: well it's twice as bad now :-)
<james_w> beuno: lp:~james-w/bzr-upload/auto_upload/ should be more to your liking
 * beuno pulls
<beuno> james_w, you rock, merging now
<james_w> cool, thanks
<james_w> beuno: I'm gonna spend some time selling bzr and bzr-upload to my web developer friend soon, I think she's going to love it. It does make a pretty easy and interesting way of deploying code.
<james_w> I'll make sure to pass on any suggestions that she has
<beuno> james_w, yay!  more users.  Any feedback will be very welcome
<james_w> and she's got a friend who does presentations and training on how to do this with svn, so hopefully I can get her to switch as well
<jam> james_w: Is there no feature that can tell if hardlinks are supported?
<jam> Or does the "create_hardlink" just fall back to create_file if it can't create a hard link?
<james_w> jam: oh yeah, I thought about that as I was writing the test, but forgot to revisit it
<james_w> but yes, there is a feature
<james_w> I'd fix it, but I'm just heading out the door
<ahasenack> guys, https://launchpad.net/~bzr/+archive is missing hardy 1.5.0 packages
<james_w> any other review comments that I could fold in would be appreciated
<ahasenack> for bzr (bzrtools is there)
<james_w> hey ahasenack
<james_w> I heard tell they were removed
<jam> james_w: "If self.tree_kind(trans_id) != self.final_kind(trans_id)" is that true when the target is being deleted?
<jam> Or does that just raise "NoSuchFile" ?
<ahasenack> I know 1.6b3 was removed from there
<ahasenack> hmm
<james_w> that will be it then, poolie should probably re-upload 1.5 with a "really" version number
<jam> I'm also a *little* concerned about raising + catching an exception in an inner loop when there maybe 1000s of content changes due to a merge
<ahasenack> the hardy one is in state "superseeded"
<ahasenack>  bzr - 1.5.0-1~bazaar1~hardy1  	  	 beuno   	2008-05-17  	Superseded  	Hardy
<james_w> jam: yeah, I tried to minimise the number of times it would be called, but it's not ideal
<ahasenack> probably because 1.6b3 was uploaded for hardy, then removed but 1.5.0 was not reuploaded
<ahasenack> ok
<james_w> jam: I don't know if I could avoid the exception
<jam> james_w: well, this is "_apply_removals" right?
<jam> So things which are actually deleted will raise the exception
<james_w> jam: but yes, I think that raises NoSuchFile, and we're not building up and exact list of kind changes, just collecting all the ones we can to make sure they get an inventory_delta entry
<james_w> yeah, it's _apply_removals
<jam> james_w: well, it seems abentley asked for this
<jam> but to be honest
<jam> it doesn't seem to fit the way everything else is tracked
<jam> specifically, apply_insertions
<jam> does a lot of
<jam> "if trans_id in self.XXX"
<jam> and now we are creating a separate local variable
<james_w> yeah
<james_w> I think actual removals go through a different code path, only modifications hit this one
<james_w> I think I understood the other approach more, I'd like to know abentley's reasoning
<james_w> my guess was keeping state is more likely to be buggy
<jam> james_w: well, his claim was that the information is already somewhere
<jam> so it would lead to redundancies
<abentley> james_w: I thought I explained.  It's redundant with other data we have.
<jam> but where is it storeed
<jam> ?
<james_w> hi abentley
<abentley> jam: TT._new_contents
<jam> abentley: so is it just as simple as:
<jam> or trans_id in self._new_contents ?
<jam> adding that to the "apply_insertions" if statement?
<abentley> jam: Well, you could.  That's a bit overkill.
<jam> abentley: then it doesn't sound redundant to have a *smaller* list
<abentley> jam: I would suggest comparing to the tree kind.
<jam>  list / set
<abentley> jam: we already know the state in the old tree.  We already know what files are getting new contents.
<jam> abentley: do we know what files are becoming directories?
<jam> aka, losing content
<jam> and getting a new kind
<abentley> jam: yes.
<jam> as that was the bug here
<jam> that it wasn't actually creating an inventory entry for it
<jam> an inventory *delta* entry
<abentley> jam: _new_contents lists all files, symlinks and directories that are getting new contents on disk.
<jam> abentley: but the idea is that you don't need an inventory entry just for a content update?
<jam> Since you pass it the full Inventory Entry, I would have thought that you would
<jam> (since the sha1sum / size / etc are changing)
<jam> And it *might* be a solution for the "commit doesn't update sha1sum" bug we are having
<jam> (I could certainly be conflating things, though)
<abentley> jam: This is working tree state that's being updated, so the sha1sum and size are not expected to be accurate.
<abentley> gotta eat.
<rocky> jelmer: i'm seeing extreme slowness when committing to a svn checkout using bzr-svn ... is that normal?
<jelmer> rocky, hi
<james_w> right, I'm off, I'll work on this on Monday probably, so any review comments will be appreciated.
<jelmer> rocky, first time may be a bit slow
<rocky> oh ok
<evarlast> http://paste.ubuntu.com/33097/
<evarlast> LockFileEx not supported in vista client and XP server with server being a USB device shared.
<jam> evarlast: sounds like you are running into a problem with accessing the working tree when doing 'bzr branch'
<jam> Unfortunately the new code path tries to copy file contents from a WT if it can find one
<jam> because it is often faster than reading it out of the repo
<jam> and we didn't add a way to say "just branch and ignore the WT"
<jam> abentley: ^^ Thoughts?
<jam> (abentley is currently eating, but he is the one that implemented the WT processing)
<jam> evarlast: if you are just looking to "get going" you can do this trivial hack
<jam> cd other
<jam> mv .bzr/checkout .bzr/checkout-hidden
<jam> evarlast: then 'bzr branch' will work
<jam> and you can "mv .bzr/checkout-hidden .bzr/checkout" later.
<evarlast> really?
<evarlast> i'll try that, thanks.
<jam> evarlast: we only use LockFileEx on working trees
<evarlast> ah, and this fakes being a non-working tree.
<evarlast> very cool. thanks.
<n[ate]vw> Quick ?: bzr status on both my laptop and desktop show no uncommited changes. Is there a way, though, to check which revision both are on?
<beuno> n[ate]vw, bzr revno
<jam> n[ate]vw: 'bzr missing' between them
<jam> bzr log -r -1
<jam> bzr revision-info
<jam> bzr revno
<jam> n[ate]vw: need any more? :)
<n[ate]vw> awesome, revno was exactly the info I didn't know how to get
<n[ate]vw> missing looks handy too, but takes almost as long as a pull so not sure how much I'll use it
<n[ate]vw> thanks!
<jam> n[ate]vw: what version of bzr?
<jam> n[ate]vw: (just to mention that 'bzr missing' is much faster in 1.6)
<n[ate]vw> 1.3.1
<jam> well, soon-to-be-released 1.6 :)
<n[ate]vw> jam: I should upgrade, I'm sure there's other good stuff too
<jam> so you may want to revisit it
<n[ate]vw> shelve is still a separate plugin, though, right?
<jam> n[ate]vw: shelve is in 'bzrtools'
<jam> mostly because it relies on "patch" being an available program
<jam> and it fails for non-text files
<n[ate]vw> ah, ok
<n[ate]vw> keep realizing I haven't gotten around to installing it on the occasional occasions I need it
<Demosthenes> with my rcs files i used the header keywords to put the RCS version # in my file header, does BZR have a similar feature?
<Peng_> Demosthenes: It's in progress. http://bazaar-vcs.org/KeywordExpansion
<jam> Demosthenes: though it may not be what you really want: http://jam-bazaar.blogspot.com/2008/07/last-week-in-bazaar.html
<pickscrape> Could anyone point me at a decent example of how to add a pre-commit hook?
<pickscrape> I found one but it used a method that was apparently deprecated in 1.5
<jam> pickscrape: what was the deprecated function? (I'm guessing install_hook versus install_named_hook)
<pickscrape> jam: yes, thanks. I found that myself by looking at the release notes
<jam> that should be the only *major* difference, which just means passing in a name at the same time
<jam> rather than installing it
<jam> and then naming it as 2 separate steps
<pickscrape> I think I have everything I need now: just need to read up on TreeDelta and RevisionTree which I haven't needed to touch so far :)
<lifeless> hi jam will you be wowing ?
<lifeless> jam: ^
<jam> lifeless: probably not, family time tonight
<lifeless> jam: kk enjoy
#bzr 2008-08-02
<jelmer> http://libwilliam.wordpress.com/2008/08/01/anjuta-bazaar-plugin-v010/
<lifeless> cool
<Odd_Bloke> jam: Is it possible the branch you were having issues with is a loom?
<jam> Odd_Bloke: no
<jam> It happened *after* the process finished
<jam> not at the beginning
<jam> jelmer: he gave a lot of caveats and problems, but he didn't really say what it was supposed to do
<jam> Is this the xml-rpc service?
<jam> Or is it a different UI ?
<jam> Ah, I guess anjunta is another IDE
<jam> I hadn't heard of it before
<jelmer> jam: yeah, it is
<jelmer> it's a GTK+ based on
<jelmer> e
<Odd_Bloke> jam: Hmm, OK.  No ideas remain. :)
<jelmer> Why does TreeDelta have an unchanged field?
<jelmer> It makes it very hard to implement an optimized version of it since knowing what was unchanged requires retrieving full contents rather than an actual delta :-(
<lifeless> treedelta is very old
<lifeless> I'd look at changing whatever needs it to not need it :)
<markh> is there an - err - canonical version of bzr.png anywhere?
<jelmer> markh, something like http://bazaar-vcs.org/LogoOptions ?
<markh> jelmer: something very much like that - thanks!
<markh> interesting - the copy of bzr.ico there is different than in bzr.dev - bzr.dev doesn't have a transparent background, which I was looking to "fix"
<RAOF> Dear me, loggerhead looks _so_ _much_ better_.  Good job!
<evarlast> new loggerhead?
 * evarlast updates
<Peng_> evarlast: There isn't a new release, but the trunk is very nice. https://code.launchpad.net/~loggerhead-team/loggerhead/trunk
<RAOF> I was just looking at the loggerhead on edge.
<Peng_> Is it just me, or could a bunch of the branches on https://code.launchpad.net/loggerhead be marked as Merged?
<RAOF> bzr upgrade over sftp is not a lightning-fast operation.
<RAOF> :(
<RAOF> Thinking of which, would it be possible to have a nice big "upgrade this branch to $DEFAULT_FORMAT" button on launchpad?
<Peng_> I like that idea. I guess you should file a bug.
<RAOF> What's codehosting's tracker?
<Peng_> I'd throw it in launchpad-bazaar, but I might be wrong.
<Peng_> Yeah, that sounds right.
<rockstar> That is right
<RAOF> bug #254135 filed.  Feel free to comment/triage.
<ubottu> Launchpad bug 254135 in launchpad-bazaar "Add UI to upgrade a hosted bzr branch" [Undecided,New] https://launchpad.net/bugs/254135
<^mo> morning
<^mo> mornign
<^mo> uh
<^mo> morning :)
<Odd_Bloke> ^mo: Morning. :)
<^mo> guys
<^mo> i am currently looking into misusing Bazaar (and other DRCS)
<^mo> the idea is to use a DRCS to backup and synchronize my files on multiple machines. mostly photos, binary documents (office), you name it.
<^mo> it's a shame there is no good dedicated tool to do that. so i thought about building one on top of a DRCS
<^mo> the idea is to monitor specified directories for changes, auto-commit them into a local repository, and auto-sync that to other repositories, either on my server or to other machines directly.
<^mo> so, i'm evalutating different DRCS for that
<^mo> unfortunately i seem to be the only one considering this "misuse"
<weigon_> ^mo: rsync is doing the big part of that
<^mo> but it doesn't do revisions, does it?
<scorpioxy> hey guys. Quick question, is there something like merge --preview but for a heavyweight checkout? As in, preview the changes before updating.
<lifeless> scorpioxy_: sorry no
<lifeless> scorpioxy_: should be straight forward to do if you'd like to file a bug
<scorpioxy_> lifeless: so you think this is something that other people might want? My use case is for a looking at changes first instead of reverting later...
<scorpioxy_> lifeless: if you say that it is straight forward to do, then i'll try and implement it myself.
<lifeless> scorpioxy_: /away
<lifeless> scorpioxy_: I think its something that other folk might use yes
<lifeless> and it makes sense to offer 'dry run' style things for commands where we can
<lifeless> robtaylor: excellent
<scorpioxy_> lifeless: yes, i thought so too...thank you
<RAOF> Hm.  So, one of the problems with the crazy-long bzr upgrade-over-sftp process is that it appears that people can try to branch the repo while it's happening, and get not-particularly-helpful error messages for their trouble.
<lifeless> RAOF: yes
<RAOF> lifeless: Is there a bug already filed about that?
<lifeless> RAOF: its kindof by design
<lifeless> RAOF: I don't think there is an explicit bug; be worth having one
<RAOF> Kindof by design that people can try to branch from a repo in the process of being upgraded?
<lifeless> we don't have read locks on branch or repository
<lifeless> nor a thing to check to see if someone is doing operations like reconcile/upgrade
<gour> what's the ETA for 1.6?
<lifeless> and we wouldn't want one that is costly/problematic
<RAOF> Where are my CDs dissappearing to?  Now I can't find Eternal Nightcap or White Blood Cells.  Grr
<RAOF> But a bug to sit around and track that it's a real problem isn't a bad thing.
<lifeless> gour: soon; don't know exactly
<RAOF> I've already filed a bug that, if implemented, would almost eliminate this problem - a Launchpad button for upgrade.
<lifeless> RAOF: doesn't eliminate the problem at all
<RAOF> No, but it makes it vastly less likely that someone will hit it.
<lifeless> RAOF: not really
<lifeless> RAOF: there are many people that host their own branches over sftp
<RAOF> But they will often/mostly have shell access to the host box?
<lifeless> RAOF: if they are hosting over sftp no
<RAOF> It makes it vastly less likely that _I_ will hit it.
<lifeless> well only you can assess that :)
<lifeless> why are you hitting it? LP has a public mirror that should protect you from hitting it on other peoples branches
<RAOF> It wasn't me who hit it, but I was upgrading the do trunk and someone tried to pull and got a missing revision error.
<RAOF> Since the upgrade took somewhat in the order of an hour, there seems to be a nice big window for breakage.
<RAOF> I can hunt down the exact error message if it'd be helpful.
<lifeless> no
<lifeless> upgrade is roughly
<lifeless> backup
<lifeless> delete the repository
<lifeless> make a new one
<lifeless> fetch from the backup
<gour> ...so, bzr-svn will follow 1.6 shortly
<lifeless> I don't know
<gour> jelmer (is he the author) told so
<gour> is there any 'bzr-idiom' for naming feature branches in shared repo for e.g. project 'prj' ?
<lifeless> I don't understand the question
<lifeless> a shared repo is just disk usage optimisation, doesn't change naming or anything
<gour> right, but if I have shared repo for the project named 'prj' any idea how to name a branch based on 'prj' which reprsents work on certain feature/bug-fix etc. ?
<lifeless> I'd name branches after the feature or bug fix
<gour> without 'prj' in the name?
<lifeless> entirely up to you
<lifeless> but if you have the project name in the url already, its a bit redundant to have it in the branch basename as well
<gour> it's a 'local' project - my study notes
<gour> thanks for the input
<lifeless> np
<gour> just pulled latest code from your search plugin ;)
<gour> lifeless: hmm, what's this - http://rafb.net/p/2UMbPn85.html
<lifeless> that branch needs 1.6b4
<gour> when was 1.6b4 released?
<gour> i built bzr from repo yesterday, r3596
<lifeless> you sure you are using that bzr?
<lifeless> bzr 1.6b3 on python 2.5.2 (linux2)
<lifeless> arguments: ['/usr/bin/bzr', 'index']
<gour> lifeless: see http://rafb.net/p/tbz8zT49.html
<lifeless> that says 1.6b3
<gour> r3596
<lifeless> no
<gour> hmm
<lifeless> 3596 is after 1.6b4, you have not installed that
<gour> built and installed yesterday
<lifeless> clearly not!
<lifeless> find the directory you have 3596 in
<lifeless> run ./bzr --version
<gour> [root@nitai gour]# ls -al /var/abs/local/gaur/bzr-bzr-3596-1-x86_64.pkg.tar.gz
<gour> -rw-r--r-- 1 gour gour 4141984 2008-08-01 14:58 /var/abs/local/gaur/bzr-bzr-3596-1-x86_64.pkg.tar.gz
<gour> i got nothing for ./bzr
<gour> i'll remove that pkg and re-build
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ ./bzr version --short
<lifeless> 1.6b4
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ ./bzr revno
<lifeless> 3596
<gour> re-built the package and now I get 1.6.b4 and same r3596...strange :-/
<gour> hmm, commiting one patch takes quite loooooong
<gour> when i'm finished with the feature or bug-fix and merge changes into 'trunk', i can safely dismiss feature/bug-fix branches ?
<james_w> yup
<james_w> once it's merged the revisions are linked in to another branch, so you can delete the one that you created them in, without risk of losing them
<gour> with darcs one had to be careful if some patch went 'out' and then it was rm-ed in another repo
<gour> james_w: it looks someone listened and tried with newer bzr - http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation?action=diff&version=59
<gour> ;)
<james_w> well, that's an improvement
<gour> right. i did not got any reply from JaffaCake after sending him some bzr-ad-info, but maybe he took a look
<luks> still too slow to downloads 90MB of data
<luks> *download
<gour> having ghc switch from darcs will impact the whole haskell community. it may happen that the whole hackage.haskell.org will adopt something else
<gour> based on that wiki page, it looks that cherry-picking is the major Cons of bzr
<luks> that is what I don't understnad, because git and hg are no better in that area
<gour> luks: have you seen that page?
<luks> yes, somebody posted the link here a few days ago
<gour> you can add (as guest) some more relevant info
<luks> heh, no I won't :)
<gour> why not?
<gour> git/hg users do the same
<luks> I just don't promote things, unless they are really good
<gour> bzr isn't?
<luks> I don't think so
<gour> i'd say it is on the level of hg and being simpler/safer than git
<luks> I'm not saying it's worse than git or hg, it's better IMO, but it's not "really good"
<gour> well, that's not pragmatic...we have to live with what we have NOW
<gour> and project are switching to new VCSs NOW, not sometime in the future
<luks> I do live with what we have now, so I use bzr, but I'm not going to promote it :)
<lifeless> you know
 * gour promotes things which he uses NOW
<lifeless> that git - bzr difference is around about the size difference in groupcompress
<gour> ...and i'm sure bzr will catch those performance issues to not be issues any longer
<gour> anyway, here is the url for anyone inspired to add some objective info to it - http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation
<gour> guest/guest are credentials
<rocky> jelmer: hey... when i bzr checkout a svn trunk, and make commits to it directly and then run bzr update, it pulls down the same commits i just made to be committed again
<rocky> am i doing something wrong?
<jelmer> rocky, that doesn't sound right
<jelmer> what version of bzr, bzr-svn?
<rocky> bzr 1.5
<rocky> lemme check bzr-svn
<rocky> bzr-svn 0.4.10
<jelmer> rocky: Can you pastebin some example output of doing a commit and an update?
<rocky> trying...
<rocky> bzr commit's to svn are still very very slow
<jelmer> that should be a fair bit better with 0.4.11
<rocky> jelmer: http://cluebin.appspot.com/pasted/561
<jelmer> rocky, how slow is slow?
<jelmer> seconds, minutes?
<rocky> well, to do that commit of that recurring item takes about 50sec or so
<jelmer> wow, ok
<jelmer> I'm trying to figure out what's going wrong
<jelmer> give me a few minutes
<jelmer> beuno, pin
<jelmer> g
<rocky> hehe, k
<AnMaster> http://rafb.net/p/2SLT6g34.html <-- I get that traceback from bzr
<AnMaster> what should I do
<AnMaster> what I did was:
<AnMaster> bzr rm util-linux-ng
<AnMaster> then bzr st crash with that error
<spiv> AnMaster: I think that error might be fixed in bzr.dev
<AnMaster> spiv, well how do I get my repo working again
<AnMaster> I need it working now
<AnMaster> how can I restore it to working order
<AnMaster> spiv, I need help with that!
<AnMaster> spiv, how can I get the repo working again!?
<spiv> AnMaster: so if you're comfortable running a copy of bzr.dev (just "bzr branch http://bazaar-vcs.org/bzr/bzr.dev", then run bzr from the bzr.dev directory), I'd try that.
<AnMaster> spiv, is that the only way?
<AnMaster> to restore the repo
<spiv> AnMaster: your repo is fine, as is your branch
<spiv> AnMaster: the only part that's having a problem is the workingtree
<james_w> AnMaster: "mkdir util-linux-ng; bzr add util-linux-ng; bzr st; bzr rm util-linux-ng" fixes it I believe
<AnMaster> james_w, not sure...
<spiv> AnMaster: so another thing you can do is "bzr branch . ../new-copy" and resume work from that
<AnMaster> it looks very strange now
<AnMaster> http://rafb.net/p/ji2wT482.html
<james_w> that is a bit odd
<AnMaster> spiv, ah thanks that worked
<spiv> Not really, "bzr add" adds new files.
<spiv> If you want to restore old files, use "bzr revert" (or potentially bzr add --file-ids-from).
<AnMaster> spiv, bzr revert did also crash
<AnMaster> actually not crash first time:
<AnMaster> bzr: ERROR: No such file: u'/home/anmaster/abs/standard-recompiled/util-linux-ng/cryptoloop-support.patch'
<AnMaster> when I tried to revert
<AnMaster> anyway branch worked
<spiv> That's probably caused by the same bug, I'd guess.
<spiv> AnMaster: that's good news
<spiv> It's late here, so I'm off to bed.
<spiv> AnMaster: please file a bug with that traceback and if possible information to help us reproduce
<AnMaster> spiv, hm I got no idea how to reproduce, I can't even manage to reproduce myself
<spiv> AnMaster: ok, just the traceback is fine then.
<AnMaster> hm ok
<AnMaster> spiv, bug tracker is on launchpad right?
<spiv> AnMaster: I suspect we may already have that bug in our bug tracker (and possibly even have it fixed for the upcoming 1.6 release), but it's good to make sure we're not missing things.
<spiv> Right.
<AnMaster> hrrm then to figure out if it exists
<spiv> (Especially bugs that are hard for non-experts to recover from!)
<spiv> AnMaster: if you're not sure, if it takes too long to figure out if it's already report, just quickly file a new bug anyway.
<AnMaster> you got a few with the same text "Could not find target parent in wt" but I got no clue if they have the same cause
<spiv> AnMaster: it's quite easy to mark a bug as a duplicate, it's harder to take a bug report and say "oh and the 'me too' in comment 11 is actually a different bug that just looked similar" :)
<AnMaster> actually I think I used normal (non-bzr) rm on some files that I did bzr add on but hadn't commited
<AnMaster> then did bzr rm on the directory that I added and didn't commit
<AnMaster> where those files were located
<AnMaster> spiv, can you reproduce that way?
<spiv> AnMaster: I'm sorry, I'm actually nodding off (it's past midnight here)
<spiv> AnMaster: it sounds plausible, though
<AnMaster> unable to reproduce that way
<spiv> AnMaster: thanks for your patience, and I'm glad we got you going again.
 * spiv -> bed
<AnMaster> ah no I need to commit after adding
<AnMaster> then it crashes
<AnMaster> https://bugs.launchpad.net/bzr/+bug/254220
<AnMaster> there
<ubottu> Launchpad bug 254220 in bzr "Crash on rm on file, bzr rm on directory and then bzr st" [Undecided,New]
<dwt> jelmer: You there?
<jelmer> dwt, hi
<dwt> Super.
<dwt> I talked to you some days ago about bzr-svn always crashing on startup on my mashine
<dwt> (mac, leopard, fink)
<dwt> Well, I found the problem
<dwt> (well one of the problems :)
<dwt> But I'm not sure what the right way to fix it would be
<dwt> The problem is, that on os x with fink
<dwt> the subversion libraries are in /sw/lib/svn15
<dwt> instead of /usr/lib where setup.py is setup to expect them
<dwt> (while the headers reside in /sw/include....
<dwt> )
<dwt> This caused setup.py to link against an old version in /usr/lib which caused the crash
<dwt> (subversion 1.4 there)
<jelmer> dwt, subversion 1.4 should work as well though
<dwt> hm.
<dwt> it used libapr in the latest version from fink though
<dwt> maybe that was the reason for the crash then?
<jelmer> dwt, yeah, I guess conflicting aprs may be a problem
<dwt> What do you think would be the best solution to this problem? I'd rather use the fink installed libraries than the apple provieded (those ar always very old)
<dwt> But looking at the setup.py (and me not knowing a lot about it) I see no simple way to just tell it to look at  a specific point in my filesystem for it's libraries
<dwt> and headers
<jelmer> it will try to find the apr-config utility
<jelmer> make sure the apr-config instance it should use is first in your $PATH
<dwt> yeah, that works and is correctly overridden by fink
<dwt> That doesn't work for subversion though
<dwt> (or maybe I'm missing something)
<jelmer> dwt, one sec, I'll add some magic for that
<dwt> jelmer: cool!
<dwt> jelmer: svn libraries are in /sw/lib/svn15, while headers are in /sw/include/subversion-1
<jelmer> I've added a SVN_PREFIX environment variable
<jelmer> (0.4 branch of bzr-svn)
<dwt> does that account for an (IMO dumb) name choice like svn15 for the library dir?
<dwt> instead of just svn?
<dwt> jelmer: well it almost works, just a small copy'n'past error
<dwt> === modified file 'setup.py'
<dwt> --- setup.py	2008-08-02 15:12:53 +0000
<dwt> +++ setup.py	2008-08-02 15:17:57 +0000
<dwt> @@ -95,8 +95,8 @@
<dwt>                  svn_prefix = basedir
<dwt>                  break
<dwt>      if svn_prefix is not None:
<dwt> -        return ([os.path.join(basedir, "include/subversion-1")],
<dwt> -                [os.path.join(basedir, "lib")], [])
<dwt> +        return ([os.path.join(svn_prefix, "include/subversion-1")],
<dwt> +                [os.path.join(svn_prefix, "lib")], [])
<dwt>      raise Exception("Subversion development files not found. "
<dwt>                      "Please set SVN_PREFIX environment variable. ")
<dwt>  
<dwt> (I believe)
<dwt> Other than that, I've just got to solve the problem of my package manager insisting to put the svn libraries in a folder called svn15 instead of just svn
<jelmer> yep
<jelmer> thanks
<dwt> jelmer: I was able to build it by doing a second patch:
<dwt> === modified file 'setup.py'
<dwt> --- setup.py	2008-08-02 15:20:48 +0000
<dwt> +++ setup.py	2008-08-02 15:25:44 +0000
<dwt> @@ -96,7 +96,7 @@
<dwt>                  break
<dwt>      if svn_prefix is not None:
<dwt>          return ([os.path.join(svn_prefix, "include/subversion-1")],
<dwt> -                [os.path.join(svn_prefix, "lib")], [])
<dwt> +                [os.path.join(svn_prefix, "lib/svn15")], [])
<dwt>      raise Exception("Subversion development files not found. "
<dwt>                      "Please set SVN_PREFIX environment variable. ")
<dwt>  
<dwt> However I don't think that this could go into the repo
<jelmer> yeah, indeed
<dwt> What do you think would be the most 'not ugly' solution to this?
<dwt> Another environment variable seems very wastefull
<dwt> though I honestly don't know of any alternative
<dwt> maybe having SVN_LIB_DIR and SVN_INCLUDE_DIR would be a bit better?
<Pilky> Is bzr really the only VCS that lets you work over S/FTP?
<bob2> no
<dwt> jelmer: Success! Now I get an exception in check_subversion_version() in __init__.py :)
<jelmer> dwt: patches are welcome :-)
<dwt> jelmer: :) I'm looking into it
<dwt> regarding the setup.py
<dwt> would you accept a patch with two environment variables that are preffered if set?
<Pilky> bob2: which other VCSs support it?
<dwt> jelmer: Do I need to run anything else besides make to build a fully functional svn plugin?
<jelmer> dwt, no, that should be sufficient
<dwt> because the error is that it cannot load the client module
<dwt> ImportError: cannot import name client
<jelmer> dwt, can you pastebin the full backtrace perhaps?
<bob2> Pilky: arch!
<dwt> in __init__.py on line 98
<dwt> sure
<dwt> any paste preffered?
<jelmer> dwt, never mind, it was the line number I was after
<dwt> :)
<jelmer> dwt, make should've built a client.so or something in the bzr-svn directory
<dwt> jelmer: well it did, and it also seems as if it is linked up correctly
<dwt> dwt@dwcp ~/.bazaar/plugins/svn % ll client.so
<dwt> -rwxrwxr-x  1 dwt  dwt  196728  2 Aug 17:37 client.so*
<dwt> dwt@dwcp ~/.bazaar/plugins/svn % otool -L client.so
<dwt> client.so:
<dwt> 	/sw/lib/svn15/libsvn_client-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
<dwt> 	/sw/lib/svn15/libsvn_subr-1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
<dwt> 	/sw/lib/libapr-0.0.dylib (compatibility version 10.0.0, current version 10.12.0)
<dwt> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
<dwt> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1)
<Pilky> bob2: ah, well it's still a surprisingly rare feature given how useful it is, I'm surprised more isn't made of it
<jelmer> dwt, perhaps it's some MacOSX-specific feature :-(
<jelmer> s/feature/problem/
<dwt> :)
<dwt> lets, see
<dwt> what is the easiest way to get pyton to give me a debugger at that point? (I'm still not very good at python myself sadly)
<jelmer> not sure if you need a debugger here, probably just a python prompt
<jelmer> you should be able to get one by simply running "python"
<dwt> :)
<rocky> jelmer: don't suppose you saw anything blatantly wrong with the paste i showed earlier? where it was recommitting the same thing?
<jelmer> rocky, sorry, I got distracted while I was looking into that
<jelmer> rocky, There's nothing obviously wrong
<rocky> hehe
<dwt> uhm... importing client.so from python directly works extremely fine.
<jelmer> rocky, can you perhaps file a bug so it at least doesn't get forgotten?
<rocky> right
<jelmer> I still intend to have a look at it soon, since I presume this blocks you from actually using bzr-svn?
<dwt> jelmer: trying from bzrlib.plugins.svn import client  however gives an error
<jelmer> dwt, you need to tell bzr to load its plugins first
<dwt> -> the same that happens in the scrept
<jelmer> e.g. "from bzrlib.plugin import load_plugins; load_plugins()"
<dwt> I'l try
<dwt> still the same error
<dwt> well not really
<dwt> interestingly if I try "from bzrlib.plugins.svn import client"
<dwt> it goes through __init__.py
<dwt> and dies there at the same line that it dies when loading the plugin in bzr
<dwt> (that is line 98)
<dwt> if I change that to drop the "from bzrlib.plugins.svn"
<dwt> it works
<dwt> (that is, it throws at a similar line further into the script
<dwt> )
<dwt> jelmer: It seems it somehow doesn't think of itself as 'bzrlib.plugins.svn'
<dwt> when being in place
<dwt> jelmer: Do you have any idea why that might happen - or am I completely on the wrong ship here?
<jelmer> dwt, No idea, sorry
<dwt> :) Ah well.
<jelmer> dwt, you could try removing the "bzrlib.plugins.svn." prefix everywhere it comes up
<jelmer> since it should work as well with relative imports
<jelmer> but I have no idea what's going on that's breaking it
<dwt> just a second
<dwt> same here
<dwt> :)
<kiorky> does anyone has knowledge about the bzr webserve plugin ? It seems to exist a branch wich support collections ala hgwebdir. Did anyone ever tried that ?
<kiorky> i mean : https://code.launchpad.net/~fdivbug/bzr-webserve/collections
<jelmer> kiorky, any particular reason you're looking into webserve rather than loggerhead?
<kiorky> jelmer: publishing a bunch of repositories
<jelmer> I don't think webserve is maintained very actively anymore
<kiorky> ok
<kiorky> jelmer: ha, i may be wrong with webserve usage
<kiorky> jelmer: can i clone over "webserve" ? Because that is what i was thinking.
<jelmer> kiorky, afaik not
<kiorky> jelmer: to do something similar of hgwebdir
<kiorky> jelmer: like http://hg.minitage.org
<jelmer> kiorky, something like http://bzr-playground.gnome.org/?
<kiorky> jelmer: To sum up, my goal is to achieve that, with bzr
<jelmer> kiorky, it's probably worth asking the loggerhead developers about
<kiorky> jelmer: yep
<kiorky> jelmer: the page you gave me is a loggerhead thing, isnt it ?
<jelmer> yeah
<bob2> is a hg "repository" along the lines of a bzr branch?
<kiorky> jelmer: i cliked on a tag, to http://bzr-playground.gnome.org/gnome-doc-utils/trunk/, then i can branch that. What i want to ask: are the modules in the same repo or there are multiple repos ?
<bob2> nm
<jelmer> kiorky, multiple repositories
<kiorky> jelmer: so what i will have to do is to setup loggehead, isnt it ? :)
<kiorky> jelmer: what i do not understand is the magic for "branching", its loggerhead but i did branch on it... What is the boilerplate between the real repo and loggerhead ?
<jelmer> kiorky, sorry, I'm not following
<kiorky> jelmer: i read the doc and answered to my question :p
<kiorky> jelmer: if i have something like that: a/.bzr b/.bzr b/c/d/f/r/e/.bzr, a and b would be served without problems i think, but will e be served ?
<jelmer> kiorky: If b/ is a branch, no. If it is just a shared repository, then e will be served
<kiorky> jelmer: someone told me about the nested tree support
<kiorky> jelmer: do you know if there is something usable or testable atm ?
<jelmer> kiorky: there is experimental support for nested trees, not sure what branch it is in though
<jelmer> LarstiQ: ping
<bob2> are you sure you wanted nested branches in your repository?
<kiorky> i like tree organization
<kiorky> i dont know how to do without nesting things
<bob2> eh?
<bob2> nesting is fine, but what would 'e' and 'b' be, for example?
<kiorky> i dont want to have to checkout from the root to get just a leaf, i prefer a bunch of repo
<bob2> that is not how bzr works
<bob2> (depending on what you mean)
<kiorky> bob2: in hg.minitage.org, the "minitage" will be "b" , and "minitage.paste" will be e
<bob2> in bzr, 'b' and 'e' would be unrelated
<kiorky> agreed
<bob2> repositories just contain a bunch of branches that share storage
<kiorky> yep, but i just need to have a mean to serve them throught http, in a tree view that reflects their organization on the filesystem
<bob2> right, but what would 'b' actually contain?
<bob2> a bare buildout or something?
<kiorky> mostly just containers direcfories, but i can also turn them into real repositories to drop inside a 'README' for example
<bob2> do you mean "branch" when you say "repositories"?
<kiorky> bob2: yep
<kiorky> bob2: "GET /projects/cryptelium.net/a/b/c/ HTTP/1.1" 404, so it does not work :)
<bob2> dunno what that is
<kiorky> bob2: i just created a repo in "/projects/cryptelium.net" and another one in "/projects/cryptelium.net/a/b/c/" and tried to see t in loggerhead.
<bob2> ok, never used that
<nekohayo> uh, wtf
<nekohayo> http://pastebin.ca/1091047
<nekohayo> why is it telling me strange stuff about locks?
<bob2> ?
<bob2> your commit failed
<bob2> perhaps bzr is still running
<bob2> if you are sure it is not, bzr break-lock file:///home/jeff/
<nekohayo> bob2: I did a killall bzr, so it shouldn't be running, didn't find it in htop either
<nekohayo> seems to work, thanks!
<kiorky> jelmer: bob2 what is the mechanism which allow me to branch over loggerhead there  : http://bzr-playground.gnome.org/glib-java/trunk/
<kiorky> jelmer: bob2 i have a repo served by loggerhead, but i cant directly branch over it.
<bob2> does hg work over bare http?
<kiorky> nope
<kiorky> bob2: you need either "hg serve" or a cgi.
<Peng_> Yes, it does, kinda/mostly.
<Peng_> kiorky: I don't think Loggerhead is involved with that. I bet the web server is just set up to send /foo/bar/ to Loggerhead and serve /foo/bar/.bzr/ directly.
<Peng_> ...Which would be the same setup as Launchpad.
<kiorky> Peng_: ha great to know
<kiorky> Peng_: maybe do you know some post/docs to achieve that ?
<kiorky> Peng_: i mean, they do that with LocationMath or such ?
<kiorky> *LocationMatch
<kiorky> Peng_: https://bugs.launchpad.net/loggerhead/+bug/248897 :p
<ubottu> Launchpad bug 248897 in loggerhead "Teach loggerhead about trunk and user branches" [Low,Confirmed]
<Peng_> FWIW, there is discussion about hafing Loggerhead support serving branches directly.
<beuno> jelmer, pong
<beuno> james_w, thanks for all the patches  :)
<james_w> beuno: no problem
<james_w> beuno: I think my friend and I are going to work a kind of tutorial for using bzr and bzr-upload and fitting it in to your workflow. Possibly to become a presentation at an upcoming conference.
<beuno> james_w, oh, that's getting very interesting!   What conference?
<james_w> something in Toronto I think, she'll be presenting, not me.
<james_w> we'll surely be asking for feedback on it
<beuno> james_w, I'll surely be happy to provide it  :)
<james_w> :-)
 * beuno wonders how loggerhead copes with stacked branches
<beuno> let's try...
<beuno> james_w, could you help me test LH's setup?   I think it's failing, but I'm not sure if it's because I've played around it so much or not:  bzr branch lp:~beuno/loggerhead/fix_setup/ && python setup.py install
<jelmer> beuno, Hi!
<jelmer> beuno, Was just wondering if you could perhaps do some bzr-gtk reviewing
<beuno> jelmer, sure. I was just answering your Release? email
<jelmer> beuno: I'll have a look at that setup.py now as I promised earlier :-)
<beuno> jelmer, heheh, incidently
<beuno> it's failing for me now
<beuno> see ^
<jelmer> beuno, works fine here
<beuno> jelmer, can you run it in a branch?
<jelmer> Just tried to install and then ran it
<beuno> serve-branches
<jelmer> Yeah, that's what I'm running
<beuno> it tells me it can't import templates when I open it up via FF
<beuno> it used to work, so I may of broken something installing/deleting
<beuno> thanks
<jelmer> yep, from the branch works as well
<beuno> jelmer, super, thanks
<jelmer> ah, now I get it as well
<jelmer> sorry :-/
<jelmer> ImportError: No module named templates
<beuno> ah, heh, ok
<beuno> yeah
<beuno> the dir is there
<beuno> so I don't understand why it doesn't find it
<beuno> there == installed
<uws> missing __init__.py perhaps?
<beuno> the dir doesn't have py's in it, just zpt templates.  Would I still need the __init__?
<uws> dunno
<beuno> jelmer, merged your 2 patches. There are 2 left that you requested phanatic's review. Would you like me to review them anyway?
<jelmer> beuno: If you feel you're familiar enough around olive's source code, please do
<beuno> jelmer, I don't. I can test as far as to make sure nothing is broken  :)
<beuno> I'll leave it for Silvester
<jelmer> ok
<nDuff> How do I export any "--local"ly committed changesets? "bundle" seems to require that I have things on separate branches.
<james_w> nDuff: does "bzr send" do what you want?
<james_w> possibly "bzr send <parent-url>"
 * awilkins sighs
 * awilkins is back from Ireland
<jelmer> 'evening awilkins
<jelmer> awilkins: Where've you been?
 * jelmer was there a couple of weeks ago as well
<awilkins> Connemara and Clare
<jelmer> Ah, nice
<Pilky> hey all, what would happen if someone was to do something like "bzr merge /somepath --weave --merge3". How would bzr handle that?
<james_w> I think --weave and --merge3 are incompatible options
<james_w> I think it may end up meaning --merge3
<Pilky> if I do a preview it runs fine
<Pilky> ok
<jelmer> awilkins: Some win32-related patches went into bzr-svn recently, so the test suite failures should've gone down again significantly
<james_w> beuno: is http://libwilliam.wordpress.com/2008/08/01/anjuta-bazaar-plugin-v010/ from the ide integration work?
<zbrown> Could someone tell me the bzr equivalent of "git reset --hard origin"
<zbrown> ?
<james_w> hi zbrown
<zbrown> hi :)
<james_w> that resets your branch and tree to be the same as the branch that you pull from?
<zbrown> ya
<zbrown> --hard being delete all changes
<james_w> hmm
<james_w> what version of bzr?
<zbrown> 1.3.1
<james_w> ok, what I'd probably do is
<zbrown> was trying to figure it out a while, but I couldn't find a solution
<james_w> bzr pull --overwrite URL-of-parent
<james_w> bzr revert
<zbrown> ah ok
<zbrown> I'll try that
<james_w> there may be a better way
<james_w> in 1.6 you won't have to look up the URL of the parent, which is an improvement
<james_w> I don't think there's a one command way to do it though
<dato> james_w: I'd do the revert first
<james_w> hey dato
<james_w> why's that?
<dato> heya
<dato> well, probably it won't matter much, but the pull could encounter conflicts?
<zbrown> james_w: 1.3.1 didn't need the URL of the parent either
<james_w> ah yeah, I guess that's probably better
<zbrown> I just tried it that way
<james_w> zbrown: ah, of course it won't
<lifeless> dato: hi
<lifeless> dato: I hear you're preferring git these days?
<dato> yep...
<lifeless> any particular thing/feature?
#bzr 2008-08-03
<lifeless> dato: ^
<dato> yeah, I was thinking
<lifeless> :P
<lifeless> james w mentioned the index's support for review etc as being very useful
<dato> yeah, the index is actually very useful for that
<dato> I tend to review my stuff before committing a lot
<lifeless> I wrote a proposal for review support in bzr
<dato> so it's very useful to say, "ok this part is definitely ok, don't show to me in `diff` again please"
<lifeless> have you seen that?
<dato> no, subj?
<dato> ah
<dato> probably RFC: supporting code review and partial commits better
<lifeless> yes I was just digging it up :)
<lifeless> if you have the time I would love your feedback on that as someone that used bzr for ages, knows the feel we aim for etc, but also is fluent with sophisticated use of git's index
<lifeless> It is not written as a comparison to the index; we wanted to derive something useful from first principles
<dato> right
<dato> ok, I can read the thread
<lifeless> but git's index is clear prior art :)
<lifeless> that would be lovely; thanks
<jelmer> ok, bzr push --overwrite and bzr uncommit work on svn repositories now >-)
<lifeless> holy cow
<lifeless> that is full of awesome
<jelmer> So (other than proper integration in push) that means full coverage I think
<lifeless> well that lhs parent bug thing
<jelmer> I've got most of that covered, working on tests atm
<lifeless> sweeet
<james_w> nice work jelmer, that's pretty cool
<lifeless> I shudder to think how it works
<lifeless> jelmer: planning merge support for svn trees now ? :)
<james_w> you could just edit the files in the svnroot
<jelmer> lifeless, probably at some point :-) There's some other things I'd like to work on first though, such as integrating the svn-push command
<james_w> jelmer: do you have the rebase based mode for bzr-svn now?
<jelmer> james_w, not sure I follow - what sort of mode of mode?
<james_w> it was discussed a little while back, more like git-svn I think
<james_w> for those that didn't want the properties tracking etc., and could put up with having one hand tied behind their back
<jelmer> ahh
<jelmer> yep, that's in now, under the command dpush
<james_w> cool
<james_w> I'll have to play sometime in case anyone asks me about it
<DBO> i can't seem to upgrade my bzr repo
<lifeless> are you getting an error?
<DBO> ok so it went like this
<DBO> my main trunk got a bzr upgrade
<DBO> so when i went to merge it into my branch
<DBO> it said to upgrade, so I did and it all worked
<DBO> I then did the merge
<DBO> that worked
<DBO> then when I do bzr push
<DBO> it tells me to upgrade
<DBO> which i already did
<lifeless> what is the exact message it giveS?
<DBO> Using saved location: bzr+ssh://jassmith@bazaar.launchpad.net/~jassmith/do/Optimizer/
<DBO> bzr: ERROR: Tags not supported by BzrBranch5('bzr+ssh://jassmith@bazaar.launchpad.net/%7Ejassmith/do/Optimizer/'); you may be able to use bzr upgrade --dirstate-tags.
<DBO> i ran the command it suggested and it says its already up to date
<Peng_> bzr upgrade sftp://jassmith@bazaar.launchpad.net/~jassmith/do/Optimizer/
<DBO> oooo
<jelmer> we really should stop recommending people to upgrade to --dirstate-tags..
<lifeless> that error is a bad one
<lifeless> jelmer: care to submit the obvious patch?
<DBO> what does it do?
<meteoroid> is sftp faster than bzr+ssh, or just shorter to type?
<lifeless> (just remove the --dirstate-tags)
<lifeless> meteoroid: sftp works ;P
<jelmer> I thought James had one which improved some of the upgrade error messages
<jelmer> james_w, Whatever happened to that?
<lifeless> jelmer: not this one
<Peng_> meteoroid: upgrade doesn't work over bzr+ssh. (I think that might've been fixed in bzr.dev last week though.)
<meteoroid> ah ok
<DBO> so erm, how long is this command supposed to take Peng_?
<james_w> I thought that was Andrew that wrote that patch
<lifeless> DBO: dirstate-tags is an older format that should be avoided generally; that error message is one we missed - it should just say 'bzr upgrade' there.
<Peng_> DBO: Well, it has to download everything and upload it again.
<DBO> Peng_, ok, long time, I'll go make a sammich
<Peng_> Hm, all you'd really have to do for tag support is upgrade the branch, though.
<Peng_> DBO: That branch isn't ver large, only ~4.5 MB. Unless you're on dial-up, it shouldn't take forever.
<lifeless> Peng_: a branch5 branch is knit based already
<lifeless> Peng_: so upgrading to packs is a good thing anyhow
<DBO> Peng_, im on something that averages around 100kbps down and slightly better than dialup up =P
<Peng_> lifeless: True.
<Peng_> DBO: Oh.
<DBO> anyhow, thanks for the wizardry that is bazaar, its the best tool we use =)
<RAOF> DBO: I've filed a bug against launchpad asking for a "upgrade this branch" button, since launchpad could do it locally much, much faster.
<DBO> RAOF, sweet
<jelmer> bzr+ssh should support upgrades properly without involving the VFS code
<jelmer> lifeless, submitted to the list
<jelmer> james_w, yeah, it was spiv indeed. sorry
<james_w> hey, I don't mind being credited with more than I've done
<jelmer> :-)
 * meteoroid wonder if it is always necessary to type the full upstream svn url when interacting with a bzr branch of an svn repo, and pushing / pulling changes.
<james_w> meteoroid: it shouldn't be
<james_w> plain "bzr pull" should use the remembered URL
<meteoroid> hm.
<meteoroid> bzr: ERROR: No pull location known or specified.
<james_w> interesting
<meteoroid> i'm a little bit old, using ubuntu package, looks like 1.3.1
<james_w> it should remember it when that happens
<james_w> that shouldn't matter for this
<meteoroid> hm.
<Peng_> In my experience, bzr-svn has a habit of forgetitng the URL. I've never tried to track down what exactly happens.
<Peng_> A pull --remember fixes it.
<jelmer> It's a known bug in older versions
<jelmer> 0.4.11 will have it fixed
<Peng_> Oh, good.
<Peng_> jelmer: Has it already been fixed in the 0.4 branch? What exactly happened?
<meteoroid> nice.  are there beta debs for bzr-svn to go with the bzr beta debs?
<Peng_> There haven't been any beta releases of the next version of bzr-svn.
<jelmer> Peng_, yes, it's fixed in the 0.4 branch
<jelmer> Peng_, Missing set_parent() call, as simple as that :-)
<Peng_> jelmer: What was it missing from? Branching?
<jelmer> Peng_, yes
<Peng_> Oh.
<Peng_> That's simple enough. Thanks for fixing it. :)
<Peng_> Did it affect svn-import too?
<jelmer> that's also doing the set_parent() call at the moment
<jelmer> I'm not sure when that was added though
<Peng_> Well, I'm gonna go. Bye. :)
<meteoroid> Peng_: --remember did the trick, thanks
 * meteoroid looks forward to a new release
<DBO> wooo, phase 3 of 4
 * DBO sighs
<RAOF> Ya.  It's not speedy.
<DBO> the best part of that last commit?  it will drop a whole 1, you heard that, 1, machine (as in assembly level) instruction from our code
<DBO> yep =)
<DBO> its an AWESOME optimization
<DBO> it also fixes a bug...
<lifeless> inner loop ?
<DBO> its inside a loop that gets run upwards of 100 million times a minute if you are a heavy user
<DBO> it can be run never also... all depends on how much you use the program =P
<lifeless> DBO: how do you make sure someone doesn't add an instruction back to the loop ?
<DBO> lifeless, i have ninjas
<lifeless> :P
<lifeless> so its GnomeDO right ?
<RAOF> GNOME Do, yes.
<lifeless> meh caps schmaps
<lifeless> anyhow
<lifeless> what search engine(s) are involved there?
<RAOF> This depends on what you mean.  Do has its own search on its item collection.  There are plugins which use locate, google, an arbitrary Firefox search provider, xesam, and others.
<james_w> hey RAOF, are you on Intrepid yet?
<RAOF> Yup.
<lifeless> so it calls into each per-keystroke I guess (for completion?)
<james_w> metacity?
 * RAOF moves stupidly early in the cycle.
<RAOF> james_w: Indeed.
<james_w> is your do window off to one side?
<james_w> mine's not central on the screen
<RAOF> james_w: Mine seems to be pretty much in the middle.
<james_w> hmm, I'll try and work out what's going on then
<RAOF> lifeless: This is currently in a bit of flux.  Currently all items are known by Do before any searching occurs, and the keypresses search through this internal list.
<lifeless> wheee memory use
<lifeless> RAOF: I'm asking because I'm doing some IR stuff at the moment
<RAOF> IR?
<lifeless> information retrieval
<RAOF> Ah.  The memory use isn't bad; Do is currently at ~30MiB.
<lifeless> RAOF: thats 50% of my free memory :)
<james_w> RAOF: I restarted it and it it's now central, but a little high, I suspect X wackiness.
<RAOF> james_w: It's intended to be a little bit above the middle.
<RAOF> lifeless: Here's 50 cents, go buy yourself another gig of ram :)
<james_w> RAOF: ah, that will be it then :-)
<lifeless> RAOF: laptop slots are full kthx
<RAOF> How much ram is _in_ that laptop?
<lifeless> well there is 300MB back by killing flash
<lifeless> 2G
<RAOF> Same here.  What's eating your ram?
<lifeless> ff hs 570M res, evo is 390M res, npviewer *was* 330M or so res (but I just killed the bugger)
<lifeless> next is xorg at 30M and a bug around that size
<RAOF> ff at 200, evo at 156, banshee-1 at 150 resident.  Everything else is below 100.
<lifeless> so do you ask xesam for a concordance before you do any search?
<lifeless> I'd have thought something like that that could be indexing gb's of data would be slow used that way
<RAOF> The xesam plugin is sitting somewhere on launchpad; it's not a default plugin.
<lifeless> ah
<RAOF> I'm not sure how it does its think.
<RAOF> s/k/g/
<lifeless> k
<meteoroid> oh, bollocks
<meteoroid> so, i want to use bzr and bzr-svn as a passthrough for a project where i am forking upstream code in one svn repo, and wish to provide an svn repo for the team working on the fork, merging perhaps in some cases bidirectionally through a bzr repo on my svn server.
<meteoroid> i get an error trying to push code to my svn which is pulled from another, is this perhaps a limitation of bzr-svn?
<jelmer> meteoroid, what error message?
<meteoroid> one sec
<jelmer> if this is a new branch you're pushing into subversion, use svn-push rather than push
<meteoroid> ah
<meteoroid> http://paste.plone.org/22937 fyi
<meteoroid> will try that RW
<meteoroid> RQ
<meteoroid> svn-push did the trick
<meteoroid> awesome! full speed ahead! :)
<meteoroid> thanks jelmer
<pickscrape> Is there a clever way to get a boolean value from bazaar.conf without having to parse it myself?
<pickscrape> get_user_option just returns a string
<meteoroid> hm, where does bzr-smart.py come from?
<meteoroid> (to run smart server in apache httpd mod_python)
<lifeless> I think the content of it is just whats in teh docs
<meteoroid> ah, just wsgi config, any idea if the smart server works with mod_wsgi?
<lifeless> I think it does
<meteoroid> that would be much simpler, i bet i can figure it out
<pickscrape> As a general rule should plugins not be using print for output?
<pickscrape> I see that builtin commands tend to use self.outf.write()
<pickscrape> Though some do use print
<lifeless> command objects should always use self.outf
<lifeless> and mutter etc
<pickscrape> Is mutter for debug info rather than general user output?
<pickscrape> OIC, the --quiet and --verbose options work by determining what mutter levels get shown to the user...
<beuno> [OT] http://adweek.blogs.com/adfreak/2008/07/then-well-grab.html
<beuno> ROFL
<ToyKeeper> Oops.  Must remember not to bzr upgrade until at least a month after bzr starts telling me to do so.
<ToyKeeper> Launchpad doesn't like the new format.
<RAOF> Which one?  bzr is only likely to ask you to upgrade to pack-0.92, I think, and that's hardly new.
<ToyKeeper> I was using pack-0.92
<ToyKeeper> Oddly enough, after updating bzr.dev (it was about a week old), it no longer tells me I'm using a deprecated format.
<ToyKeeper> Whatever was broken in the old bzr.dev seems to be fixed now.
<ToyKeeper> It complained that pack-0.92 was deprecated, and listed a '--1.6' option for upgrade which didn't work.  Both are fixed now.  :)
<kiorky> uhm, i get problems configuring loggerhead, if i have /top/a/c and /top/b/c, the second "c" wont appear :(
<kiorky> (in "auto_publish" mode)
 * meteoroid whistles innocently while branching around 600 revisions of a public subversion
<RAOF> meteoroid: How many prebuilt dlls does it contain? :)
<meteoroid> not a one, just python code.
<meteoroid> i'm just worried i'll crash mod_dav_svn and wake some poor fool up ;d
<RAOF> Soft.  I've been trying to branch google-gdata, and that contains ~15Mb worth of prebuilt code.
<meteoroid> lots of revisions of each prebuilt file?
<RAOF> Quite a number, yes.
<meteoroid> fun
<meteoroid> why prebuilt code in svn?
<RAOF> I have _no_ idea.
<meteoroid> heh
<RAOF> They have a Makefile and Visual Studio project which builds them.
<meteoroid> someone teach them about svn:ignore ;d
<RAOF> They're deliberately there.  Oh, and there's an x86 and arm build of zlib in there, too.
<meteoroid> hm.
 * awilkins is branching the SVN of JTidy
<awilkins> It's taking a looong time
<awilkins> Some things are a total sod to build on windows ; maybe those pre-built files are there for that reason
<RAOF> These things are built from the source in this very svn repo, and have no dependencies outside of the .NET corelib stack.
<awilkins> Ok then, they are daft
<RAOF> Well, the zlib dlls aren't, true.
<awilkins> With VB6, you at least have the excuse you need to preserve the GUIDS for binary compatibility
<RAOF> What, really?
<RAOF> A _rebuild_ breaks VB6?  That's awesome.
<awilkins> Yeah, VB6 uses an existing compiled binary to refer to for interface IDs and type IDs
<awilkins> Because of COM
<awilkins> And how it abstracts it all away from the developer
<awilkins> I always make a copy in a "compat" subfolder
<RAOF> That is made of pure win.
<awilkins> It's the source of endless swearing in many codebases
<RAOF> I can't possibly imagine why ;)
<awilkins> I've written build tools arranged around determining VB6 dep trees and fixing the compatibility settings
<meteoroid> and now i will find out how long it takes to branch ~10k revisions ;d
<gour> i just found out that one project us using git on savannah. is bzr also supported there?
<gour> *is
<RAOF> Yes.
<gour> really? then i can suggest to devs to move to bzr instead of CVS
<RAOF> gnash is hosted on savannah, and uses bzr.  I would be amazed if anyone was suggesting that something be moved _to_ cvs, though :)
<gour> well, they already use CVS :-)
<kiorky> pmezard: hello
<kiorky> pmezard: do you have some kind of status for the forest extension?
<kiorky> pmezard: oups, wrong chan :
<kiorky> :)
<gour> any handy url to answer question in http://article.gmane.org/gmane.comp.gnu.medical.devel/12670 ?
<gour> (how switching from CVS to bzr might help to get more contribution to the project)
<awilkins> Using Bazaar means that everyone gets the benefit of using a VCS ; using CVS limits that to a select few with commit access
<ToyKeeper> gour: No particular URL comes to mind, but it'd be easy to make an argument based on user interface and benefits of DVCS over a single central repository.
<ToyKeeper> The launchpad tour is full of good reasons too, though only some of that is bzr-related.  https://edge.launchpad.net/+tour/index
<gour> ToyKeeper: how about http://ianclatworthy.wordpress.com/2007/10/11/why-distributed-version-control-matters/
 * ToyKeeper wonders why that document is PDF instead of HTML
<ToyKeeper> gour: There's also the social aspect...  cvs these days is about as hip as having toilet paper stuck to one's shoe.  It can deter potential contributors just because it doesn't have a good "smell", so to speak.
<ToyKeeper> Even if it's used correctly, people may assume it's a bad sign.
<gour> rotfl
 * gour sent url for ian's paper
<ToyKeeper> I'm in the middle of reading his manifesto for community-agile software guidance.  He has some good texts.
<gour> that's good one too
<LarstiQ> jelmer: pong
<gnomefreak> for some reason bzr builddeb during a build using bzr bd --merge --dont-purge --builder='dpkg-buildpackage -rfakeroot -kA5C42601 -i.bzr' .  wont allow me to sign it but with -S -sa it lets me sign it
<gnomefreak> this has been happening for a while maybe a month or so now
<gnomefreak> it results in a failed build but it built fine jsut failed to sign so maybe the error message can be tweeked as well?
<LarstiQ> gnomefreak: sounds like filing a bug might be appropriate?
<LarstiQ> gnomefreak: are you sure you want -i.bzr btw?
<gnomefreak> LarstiQ: i might have already ill check since i cant remember
<gnomefreak> LarstiQ: yes im sure
<gnomefreak> we dont want .bzr being uploaded with package
<LarstiQ> gnomefreak: maybe it's specific to building bzr packages, but .bzr also ignores 'files.bzr' and such
<gnomefreak> or built for that matter
<LarstiQ> gnomefreak: right right, but that ignore pattern is ignoring more than just /.bzr/ :)
<gnomefreak> LarstiQ: shouldnt it only ignore .bzr since that is what i told it to ignore, with everything inside .bzr of course
<LarstiQ> gnomefreak: it's a regex pattern, not a shell glob.
<LarstiQ> gnomefreak: I guess if you don't have any files with 'bzr' in their name you are fine.
<gnomefreak> i dont outside of .bzr
<LarstiQ> ok, no problem then
<gnomefreak> does bzr use LP for bug tracking?
<LarstiQ> gnomefreak: yes, but you want bzr-builddeb I think?
<gnomefreak> yeah i just relized it is needed instead of bzr i was thinking it was a plugin but i remember installing it as a package
<james_w> gnomefreak: you don't need -i.bzr
<gnomefreak> james_w: when was it changed?
<gnomefreak> ok bug is filed
<gnomefreak> james_w: ive been using -i.bzr for a long time since i was told to leave .bzr out of it
<james_w> bzr-builddeb takes care of that
<james_w> if it doesn't please file a bug explaining your setup
<gnomefreak> it didnt used to so ive just been using same command not knowing it had changed
<gnomefreak> well important problem has been reported https://bugs.launchpad.net/bzr-builddeb/+bug/254400
<ubottu> Launchpad bug 254400 in bzr-builddeb "when building a package with bzr-builddep it fails to promt me for a password to sign package" [Undecided,New]
<gnomefreak> thanks for the input im gone again for store
<LarstiQ> james_w: I also needed to use -i ('^/.bzr/'?) in the past.
<james_w> interesting
<james_w> do you know why?
<gnomefreak> it was just the way it was
<gnomefreak> afaik
<gnomefreak> but i dont know the code for bzr
<gnomefreak> thanks guys ill see you later
<LarstiQ> gnomefreak: bzr-builddeb, not bzr
<LarstiQ> james_w: iirc your initial decision was to mirror svn-buildpackage?
<james_w> yeah
<LarstiQ> it's all a bit hazy in my mind, but I thought without it I'd end up with .bzr/ in my packages. I admit my memory is fallible.
<james_w> it does and "export" so it shouldn't
<james_w> maybe there's a case that I missed though
<kiorky> What will be the good place to propose a patch for loggerhead?
<james_w> the bazaar mailing list, or a bug against loggerhead probably
<james_w> you could put a branch on launchpad and propose it for merging
<kiorky> ok
<james_w> lifeless: http://repo.or.cz/w/topgit.git?a=blob;f=README
<james_w> lifeless: the announcement: http://article.gmane.org/gmane.comp.version-control.git/91197
<maploin> hi, i'm trying to do a merge, but i get a Content conflict in a file that i deleted, which also appears in the removed list. How do I solve this?
<kiorky>  /B 2
<rocky> jelmer: have a minute for more information about my mysterious can-keep-committing-same-revisions problem?
<rocky> is there any way for me to tell where a branch came from? like see that it was branched from branch1 which was branched from branch2 which was branched from trunk ?
<jelmer> rocky, hi
<meteoroid> hey rocky, didn't know you were a bzr user :)
<jelmer> rocky, still there?
<rocky> jelmer: yep
<rocky> meteoroid: yep ;)
<jelmer> rocky, is there svn repo where you're experiencing this problem public?
<rocky> jelmer: couple questions first... i should always be using svn-push when pushing a local branch changes back to svn right?
<jelmer> rocky, You can, but there's no reason to
<rocky> jelmer: i should use bzr push ?
<meteoroid> rocky; i think only if you are creating the branch, e.g. if the parent dir doesn't exist upstream.
<jelmer> rocky, the only situation where you have to use svn-push and nothing else is when nothing exists yet in svn
<jelmer> rocky, in all other situations bound branches or regular push should work as well
<rocky> gotcha
<rocky> and regular pull should work fine too right?
<jelmer> yeah
<jelmer> back in ~30 min
<meteoroid> rocky: in current release, though i believe fixed in 0.4.11 or whatever the next is, there is a wierd issue where sometimes the repo is forgotten.  if 'bzr pull' doesn't work, give it a url and --remember, e.g. 'bzr pull --remember https://svn.rocky.org/svn/rocky/rockys-stuff'
<rocky> jelmer: btw, the public svn repo for my work is at: https://dev.serverzen.com/svn/cluemapper/ClueMapper/  but i've been fiddling with this all morning so i could have everything messed up
<meteoroid> ClueMapper looks interesting..
<rocky> www.cluemapper.org
<meteoroid> jelmer: does the svn cache have to be per-user, can i set it up to be owned by a group that handles merges on the svn server?
<meteoroid> well owned by is easy, but i mean, not in some location like ~/foozle/
<jelmer> rocky, Thanks, I'll have a look at that in a sec
<jelmer> meteoroid, no, the location is pretty much hardcoded atm
 * meteoroid nods head
<rocky> jelmer: just an fyi, i figured out kinda what the problem was ... everytime i checked out ClueMapper/trunk with bzr it somehow got remembered (with the bzr svn props) that it was ClueMapper/branches/rocky so when i would do a commit, it committed to ClueMapper/branches/rocky instead of trunk ... after i removed all of the bzr svn props from the svn repo, things started working predictably again
<jelmer> rocky, that doesnt sound right
<rocky> yeah i assume i triggered a corruption bug somewhere
<jelmer> rocky, the props don't contain information about locations
<rocky> oh? well i tried blowing away all my local checkouts/branches then checking out trunk again, adding a change, committing, and voila, it went back to the rocky branch (incorrect) ... it was only after i deleted those bzr svn branches that it finally started working
<jelmer> hmm, I'll see if I can find out what was going wrong then
<jelmer> corruption is not nice :-(
<jelmer> rocky, you're running 0.4.10?
<rocky> yes i am
<rocky> atm, i'm running bzr 1.5, bzr-svn 0.4.10, svn 1.5
<rocky> ubuntu hardy heron
<rocky> jelmer: fyi, i'm writing up a blog post on my experiments with bzr-svn as in how to get started ... i'd love to have you proof-read it to ensure i'm not making gross mistakes
<meteoroid> hm, i will hang back on bzr 1.3.1, bzr-svn 0.4.9-1, and svn 1.4.6 on hardy for now.  did you build from source?  afaict these are the latest debs.
<jelmer> rocky, sure, no problem
<rocky> meteoroid: i used intreprid debs for all of those on hardy
<rocky> k, i'm not done with the post yet
<meteoroid> rocky: i wonder what sort of workflow you are describing, i also was going to write a guide on using bzr-svn to fork upstream projects while retaining the ability to push changes back into them, though i haven't quite figured out how to select only some changes for acceptance upstream.
<meteoroid> "fork, n.: a branch with a middle finger logo." :-P
<rocky> meteoroid: this is *very* basic
<meteoroid> right on, perhaps i can build on yours when i write mine so i don't have to cover all that ground
<rocky> sure
<meteoroid> hey rocky you should open up non-https svn as well read-only, will lessen the load on your server when other people follow you in svn..
<rocky> meteoroid: http://www.cluemapper.org/svn
<meteoroid> ah ok
<meteoroid> i just tried as same url
<rocky> i'm still trying to figure out the whole push/pull thing ... this is supposed to work on mirrored branches right? and won't work if the branches "diverge" ? could someone explain the simplest case of the branches "diverging" ?
<meteoroid> i have more experience with that level of usage from bk, i'm not sure how similar bzr is, but generally in DSM there is some auto-conflict-resolution, and in some cases you need to hand-merge a conflict
<meteoroid> er DSCM
<meteoroid> other than the repo itself one of bk's strengths was, in the past, the conflict resolution code - in our team at rackspace we often had more than 20 branches a piece going between 12 or more people, the web / marketing team branched our code for the customer portal, networking had branches, etc..
<meteoroid> it was pretty nice except the not having source code and the paying lots of money
<meteoroid> ;d
<meteoroid> there were only a few of us who knew how to manage merges, but we handled that by having master branches for each team, so that if two entirely unrelated projects modified the same code, they'd have to sit down at some point and talk out what each of them did, or someone who knows the code and understand both projects use a 3-way merge tool like meld
<meteoroid> i haven't tried meld with bzr yet but it's a pretty standard tool, works with svn
<meteoroid> i suggest doing some experiments, i have been testing a lot of stuff over the past couple days and learned a good bit..
<meteoroid> the simplest case, i guess, let's say you modify one file in one branch, and another file in another branch, it should be straightforward
<james_w> rocky: divergence happens if there are commits on two branches, so if I branch from you, and then we both commit on our own branch they will have diverged.
<james_w> that then means we can't push/pull between us, one of us needs to merge
<meteoroid> james_w: with non-overlapping changes, it should be straightforward though, yes?
<james_w> meteoroid: yeah, it might be, but in bzr terms you *must* "bzr merge", you can't "bzr pull"
<rocky> got it
<rocky> commits on both branches invalidates pulling/pushing until one branch does merge from another -- that pretty much covers it right?
<james_w> yeah, that's the essence
<meteoroid> james_w: ah, ok, good to know..
<meteoroid> is there an intentional reason that bzr push / pull doesn't imply a merge if required?
<james_w> so that it is an explicit step
<meteoroid> okey doke. :)
<james_w> it would be really hard to make push merge
<james_w> you can make pull merge, but bzr doesn't, for a few reasons
<meteoroid> i'm sure i'll learn more over time how bzr is different from bk, the only dscm i've used.  hg seems more like bk in ways that i don't entirely appreciate.
<meteoroid> the svn support in hg is esp wierd and sort of analogous to just doing an svn export on top of the hg branch ;g
<meteoroid> well, it's a little better than that but still awkward imo.
<meteoroid> anyway, i recall that in bk, push and pull were sort of analogous, only indicating direction, and that you could either pull changes from a developer workstation over ssh to merge them into a team branch, or push them up from the workstation, and pretty much the same stuff happened.  if the merge failed or had conflicts or whatever the terminology is, a 3-way merge tool popped up, or a message was printed saying, like, "hey, you have to
<meteoroid> i can see advantages to making it a conscious step, but it's also something else to teach users which may just fall upon more senior members of a team, creating bottlenecks.
<jelmer> rocky, looks like the bug you hit earlier was 250480
<jelmer> (bug 250480)
<ubottu> Launchpad bug 250480 in bzr-svn "Doesn't preserve non-lhs parents for file texts" [Critical,Triaged] https://launchpad.net/bugs/250480
<rocky> jelmer: ahh... great ;)
<mathrick> hiya
<mathrick> what's the status of cherrypicking support and how much of what it depends on is done?
<jelmer> mathrick, cherrypicking itself is supported (has been for a long time); I'm not sure what the plans are for tracking cherrypicks
<mathrick> that's exactly what I mean
<mathrick> non-tracking cherrypicks are rather useless/harmful
<james_w> why?
<mathrick> because it causes conflicts later on
<mathrick> and because by the time conflicts arise they will be buried deep in history, you won't even be able to uncommit them easily
<uws> mathrick: Applying cherrypicks twice will be a no-op
<uws> mathrick: uses the base revision anyway, so I don't see what conflicts it could cause
<mathrick> uws: but if they're non-tracked, bzr won't notice and will try to apply, causing text conflicts, no?
<LarstiQ> mathrick: no
<uws> NO
<uws> it will apply to the base
<uws> and end up with the same results as it already had
<mathrick> oh
<uws> i.e. bzr status won't notice
<LarstiQ> mathrick: what you describe is what svn does/used to do.
<mathrick> so what exactly would tracking do that it doesn't already?
<uws> mathrick: overview of missing patches/revisions
<uws> mathrick: I have this issue with 2 diverged branches
<uws> which I can not/do not want to merge
<uws> But some revisions needs to be applied to both
<uws> "bzr missing --line" helps listing them
<uws> but I can't see which ones have been applied, and which ones not.
<uws> (I had this issue this week, and discussed that here, so that's why I know)
<mathrick> oh, I see now
<mathrick> so they are true revisions, not just a fancy way to say patch -p0 < patch.diff?
<uws> so I constantly end up reapplying hand-picked revisions from the âotherâ branch
<uws> only to notice that nothing happened :s
<uws> mathrick: afaik (but not sure) it does just a patch
<uws> mathrick: but it handles conflicts better.
<uws> since it takes the base revision into account
<mathrick> hmm, so are the revisions visible in the history?
<uws> and if you end up with the same text result it will not bail out.
<mathrick> if so, how is it possible that bzr missing fails to notice them?
<uws> mathrick: no. that's what merge _tracking- would be.
<uws> (which bzr does not)
<mathrick> uws: no, as in no, they aren't visible in the history?
<uws> i'm not sure what you mean.
<uws> let me give an example
<uws> initial branch has revisions  a1 a2 a3
<uws> now I branch and create b4 b5
<uws> while development on the original branch continues as well: a4 a5
<uws> ok so far?
<mathrick> yeah
<uws> now, let's say I'm using the second branch
<uws> so I have a1 a2 a3 b4 b5
<uws> But I want the revision "a5" as well
<uws> but not a4
<mathrick> yep
<uws> then I can  'cd branch2 && bzr merge -c5 ../branch1'
<uws> that'll work.
<uws> bzr status will list the changes
<mathrick> yep
<uws> so I commit them with "bzr commit -m 'cherry picked fix FOO'
<uws> now I have   a1 a2 a3 b4 b5 b6
<mathrick> yep, with b6 == a5
<uws> where revision b6 is the same patch as a5
<uws> but bzr does not remember those are the same
<mathrick> mhm, so that's why I thought it'd cause conflicts
<uws> so if you now do   cd branch2; bzr missing ../branch1
<uws> it will list a4 and a5 as "missing" in branch2
<uws> and it will list "b4 b5 b6" as missing in branch1
<uws> mathrick: So that's annoying
<uws> what happens to me in this case that I try to reapply a5 again
<uws> because I forgot I already did it
<uws> ...which will not give any conflicts, but it won't do change either.
<uws> tracking cherry picks would help here, so that I can see I don't need to try merging a5 again.
<uws> mathrick: hopefully this answers your question
<mathrick> yes, except for "why aren't there any conflicts"
<mathrick> uws: I understood it exactly as you explained it previously, but that led me to thinking it'd cause conflicts
<mathrick> since it'd try to apply the same changes twice, which usually doesn't work too well
<james_w> mathrick: it does exactly what you would want it to do
<mathrick> but why?
<james_w> if both end up with exactly the same text then it won't conflict
<james_w> if one of them tweaks it slightly then it will give a conflict for that area
<james_w> and you do want that, as the cherry pick didn't preserve the identical change, so you want to get a chance to resolve them.
<pickscrape> Does the bzrlib test suite have any coverage reporting features?
<meteoroid> hm, now i am having a wierd merge issue, but i wonder if it has more to do with bzr-svn than bzr
<meteoroid> i created a bzr branch of one svn repo, made some modifications, in hopes of pushing them to a new branch in an entirely different svn repo.  i was able to push once, but the latest code is not in svn.
<meteoroid> now, when i try to push or pull from svn, it says that the branches have diverged.  bzr merge says all changes applied successfully
<meteoroid> oh, i know what changed, i applied svn properties (svn:externals) using an svn checkout
<meteoroid> but, still, seems i should be able to merge to my bzr repo, then push my bzr changes up
<jelmer> re
<jelmer> meteoroid: You need to commit your merges in bzr
<meteoroid> ah-ho
<meteoroid> yeouch segfault
<meteoroid> hm 'bzr push' rememberd the url, but segfaulted.  bzr push url worked ok
<meteoroid> well, whatever, i'm in business :)
<meteoroid> thanks jelmer!
<meteoroid> hey jelmer, i was trying to branch ~10k revisions last night, and around 5500 bzr seems to have hung, and i got an email from my web host about excessive swap usage.  does bzr-svn depend on the ability to load the entire svn repo into memory the first time around?
<bob2> if the machine ou are running it on has old subversion libs, it will leak
<meteoroid> 1.4.6 old?
<meteoroid> on ubuntu, patched
<meteoroid> so .. maybe? heh.
<meteoroid> do i still need a source compile for subversion 1.5? always seems to drain a whole weekend outta me
 * meteoroid tries to determine if it is actually faster to branch against local svn using http because apache gets its' own cpu core
<meteoroid> was seeing like 66% cpu for apache and 88% for bzr, seeing about 66-88% for bzr only using svn+file:// uri
<lifeless> I thought the leak was in the python client libs
<meteoroid> hm
<lifeless> and that current bzr-svn with its own bindings shouldn't leak
<meteoroid> maybe i should try to pull like 1000 rev at a time manually?
<meteoroid> i am at 0.4.9 right now, which is slightly older than the current stable..
<meteoroid> hm, i branched a 300M svn repo and the bzr checkout is 1.4G.  is this possibly because it contains a workingcopy that i should get rid of?
<meteoroid> still seems a bit heavy.
<bob2> du -s .bzr/repository/obsol*
<meteoroid> 3.1M
<meteoroid> i have branches, tags, trunk, and .bzr, branches and tags are around 400M each, .bzr is almost 600M
<meteoroid> so probably branches, tags, and trunk are workingcopy
<lifeless> you did svn-import ?
<meteoroid> no
<lifeless> oh, thats interesting
<meteoroid> just bzr branch svn+http://foozle/
<meteoroid> should i?
<bob2> into a shared repository?
<lifeless> sounds like bzr-svn failed to determine your branching structure
<lifeless> you should have gotten a NotBranch error trying to branch the root of the repository
<meteoroid> well, it's a client's repo and that is very possible.
<meteoroid> really?
<lifeless> really
<meteoroid> well.  i didn't.
<lifeless> because teh root is a container
<meteoroid> ok
<meteoroid> so i should use svn-import?
<lifeless> its rarely the right thing to do to turn it into a brnach
<lifeless> svn-import will probably do the same thing
<lifeless> jelmer: are there tools to diagnos the above?
<meteoroid> whether root of repo or no, is it possible to make a branch without a working copy? i know that some type of pushes or pulls default to this, but don't know if it can be specified.
<lifeless> if you have a shared repo you can create it with --no-trees
<lifeless> or you can do bzr remove-tree to remove a working copy
<meteoroid> right on
<meteoroid> wealp, it's still about twice the size of the server's master for svn, but at least it's not nine times ;d
<meteoroid> speaking of shared repo, how do i set that up?
<lifeless> bzr init-repo --no-trees PATH
<lifeless> oh for bzr-svn
<lifeless> you want init-repo --no-trees --rich-root-pack PATH
<meteoroid> should i use different shared repo for svn and for general bzr work?
<lifeless> at this point yes
<meteoroid> ok
<meteoroid> what's no-trees ?
<lifeless> we are working on unifying things
<meteoroid> i'll read the docs ;d
<lifeless> it means that branches made by 'branch' will not get working copies by default
<lifeless> you can make a copy with bzr checkout . in a branch
<meteoroid> ah ok
<meteoroid> and rich-root-pack ?
<lifeless> thats the format bzr-svn uses
<meteoroid> ah ok
<meteoroid> so, if i create a new shared repo, and i have existing bzr branches of svn repo, can i branch into the shared repo without pulling from svn again?
<bob2> yes
<meteoroid> just bzr branch from the existing copies into the new repo?
<bob2> existing branches, yes
 * meteoroid grows increasingly impressed every day
<meteoroid> nice, thanks guys, i've saved a few hundred meg and if i need more than one bzr branch of any of these, it should be fine.
<meteoroid> any quick way to reparent them to their svn urls easily?
<lifeless> bzr pull --remember
<meteoroid> sure, that's what i figured
<lifeless> you could script it with a little python if you have more than a few to update
<meteoroid> now, for a non-svn-related shared repo, if i want my repos accessible via http, i should have a working copy?
<lifeless> newbranch.set_parnet_branch(oldbranch.get_parent_branch())
<lifeless> you don't need a working copy for bzr to access things over http
<meteoroid> ok
 * meteoroid still hasn't figured out http write yet
<lifeless> you might want one if you can't run loggerhead for people to be able to browse the source code in their browser
<meteoroid> yah
<meteoroid> how's trac compare to loggerhead?
<lifeless> if you do you may want to look into bzr-push-and-update
<lifeless> totally different things
<meteoroid> well, trac has a browser
<lifeless> loggerhead is a history viewer; trac is a wiki/bugtracker/coffee-maker
<meteoroid> well, primarily it's a history browser with integrated bug tracker, designed to require and/or facilitate referencing issues on commit, and revisions in issues.
<meteoroid> i'll just .. see .. for myself .. how they are different in the history browsing department. :)
<lifeless> tis is loggerhead
<lifeless> http://bzr-playground.gnome.org/cheese/trunk/
<meteoroid> does it run in mod_wsgi or mod_py?
<meteoroid> atom feed is a nice touch :)
<meteoroid> if it runs in wsgi, actually, i could possibly run it in zope alongside our plone-based issue tracker...
<jelmer> lifeless, meteoroid: If you use bzr branch on the repository root it will consider that root a branch
<jelmer> lifeless, even if the repository contains a trunk/branches/tags structure
<jelmer> lifeless, meteoroid: bzr svn-import will do the right thing
<meteoroid> ok
<jelmer> and "bzr branch" on the repository root in bzr-svn 0.4.11 will warn you that you probably want svn-import
<Necoro> I'm trying to push a branch to my usb-stick (having fat32 as a filesystem)
<Necoro> but I always get: /usr/lib/python2.5/site-packages/bzrlib/atomicfile.py:125: UserWarning: AtomicFile(u'/mnt/usb/thesis/.bzr/README') leaked
<Necoro> googling showed no real results
<Necoro> so ... what's going wrong? =)
<Necoro> I'm using bzr1.5
<Necoro> (and running Gentoo Linux)
<meteoroid> hm
<meteoroid> now it says "ERROR: not a branch: "[svn url]""
<meteoroid> jelmer?
<jelmer> meteoroid, when does it do that?
<meteoroid> bzr svn-import svn+https://dev.pushtotest.com/svn/tm5 tm5
<meteoroid> oh, um, hm, maybe it just doesn't like my https..  http is at least paused
<jelmer> tm5 is probably not the repository root
<meteoroid> it is, i run the svn server. :)
<meteoroid> i think https fails because it has a placeholder ssl cert
<jelmer> meteoroid: ah, that would make sense
<meteoroid> need to fix that with client's cacert but he's on vacation and not sweating it himself ;d
<jelmer> meteoroid, please try running 'svn ls" against that https url
<meteoroid> ah ok just accept the cert in svn, duh
 * meteoroid has never had so much fun spending all day with SCM before ;d
<Necoro> hmm ... the real error seems to be: bzr: ERROR: Transport error: [Errno 1] Operation not permitted: '/mnt/usb/t/.bzr/README.31770.Zakarumiy.tmp'
<Necoro> but it doesn't show _what_ operation fails
<Necoro> only THAT it fails :/
<meteoroid> jelmer: the size of the bzr repo, sans tree, is still ~600M, same as before, and about twice the size of the fsfs svn repo on the server.
<LarstiQ> Necoro: there should be a traceback
<LarstiQ> Necoro: if not on the console, then in ~/.bzr.log. Or you could supply -Derror
<jelmer> meteoroid: with svn-import ?
<meteoroid> yep
<jelmer> meteoroid, Did it recognize the branch structure correctly? I.e. did it create trunk/, branches/foo directories?
<meteoroid> there is basically an import of ~300, maybe 400M of stuff, and a single tag, trunk is currently empty.
<meteoroid> well, i imported with -no-tree (that makes it like 1.4G)
<meteoroid> er, the tree makes it like 1.4G total, not no-tree
<jelmer> ? svn-import doesn't have a --no-trees option
<Necoro> LarstiQ: http://rafb.net/p/BCAK0b42.html
<meteoroid> sorry, i was following someone's advice earlier to have a shared repo and did init-repo with --no-trees
<jelmer> meteoroid: ah, ok
<meteoroid> so, how do i check if there is trunk, branches, etc.. ?
<jelmer> meteoroid, svn-import will create that shared repo for you as well
<meteoroid> ah ok
<jelmer> meteoroid, The repo that was created, does it contain a trunk directory and a branches directory similar to your svn repo?
<meteoroid> well, there's nothing but .bzr
<meteoroid> i can checkout . RQ
<jelmer> meteoroid, also, (just checking) the repository you imported into was empty before you ran svn-import?
<meteoroid> yep
<meteoroid> brand new fresh
<jelmer> meteoroid, Ah, so it must not be recognizing the branching scheme correctly
<meteoroid> okey doke
<jelmer> meteoroid, It's using a standard scheme, e.g. the repo has a "trunk" directory and other directories under "branches" derived from that?
<LarstiQ> Necoro: that is probably the chmod failing I guess.
<LarstiQ> Necoro: might want to lookup what errno 1 is in that case.
<Necoro> oh - ok
<meteoroid> well, pretty close.. it was recently imported by the client and trunk is empty.  it probably shouldn't exist at all.
<meteoroid> but we do have tags/ and branches
<LarstiQ> Necoro: but knowing fat32 where it errors if you try to chmod, that would be my guess.
<Necoro> LarstiQ: where is this defined? - is it the global errno?
<jelmer> meteoroid, You probably want to use --scheme=trunk0 as option to svn-import
<meteoroid> tags/tm52CVS, branches/tm52b6, branches/ being worked on
<meteoroid> right on
<meteoroid> i'll give it a shot
<LarstiQ> Necoro: it's just the system errno
<meteoroid> should it have to contact svn each time, or should my user's cache speed this up?
<LarstiQ> Necoro: this is reproducible for you, yes?
<meteoroid> hm, nope, looks like apache2 is pegged again :)
<meteoroid> at least slicehost lets me spike past 1cpu on this shared box when resources are available
<Necoro> LarstiQ: yes - at least now
<Necoro> I know I've done "bzr push" onto this usb stick already
<Necoro> (though not today)
<LarstiQ> Necoro: so 1 is indeed EPERM. Could you try running this with BZR_PDB=1?
<jelmer> meteoroid, the cache should help
<Necoro> ok - now I'm inside pdb ^^
<meteoroid> jelmer: coolio
<LarstiQ> Necoro: 'up' and 'print e'
<meteoroid> maybe i should dig into a branch of bzr-svn and see if i can get it to use a configurable svn cache.
<meteoroid> can't be too complex, just maybe need some tests and testing. :)
<Necoro> LarstiQ: [Errno 1] Operation not permitted: '/mnt/usb/t/.bzr/README.32365.Zakarumiy.tmp' ... so nothing new
<meteoroid> jelmer: rawk! 297M for the tm5 checkout, and it does have tags/ and trunk/ in it
<Necoro> LarstiQ: OSError(1, 'Operation not permitted')
<meteoroid> now i can be like, "hey frank, yanno how we barely moved you to svn? well, EFF svn! you should use bzr!" :-P
<jelmer> meteoroid, patches are welcome :-)
<LarstiQ> Necoro: my thinking is a bit slow at this time, sorry
<meteoroid> the past couple of days have been really educational, i'm starting to understand bzr a bit more and feel like i might be more comfy trying to contribute
<Necoro> LarstiQ: no problem ;P - we're in the same timezone ;)
<LarstiQ> Necoro: how good is your pdb/python foo? What I'd basically want to do is confirm that it is the chmod that is failing.
<LarstiQ> Necoro: are we? I'm not ircing from my timezone ;)
<Necoro> LarstiQ: my python fu should be quite to very good ... but I've never used pdb before =)
<Necoro> oh ok - it says netherlands for you ^^
<LarstiQ> Necoro: pdb needs too much thinking from me right now, so just alter bzrlib/atomicfile.py to debug printf style
<LarstiQ> Necoro: ah, but I'm in Finland this summer :)
<Necoro> hmm ... finland is even one hour later, iirc ... omg ;)
<meteoroid> LarstiQ: just put "import pdb" and "pdb.set_trace()" lines at any given point, and you can read the values of things at that point
<meteoroid> also 'up' and 'down' let you check out stuff nearby
<meteoroid> eg next line up
<LarstiQ> meteoroid: yes, I am aware of that :P
<lifeless> Necoro: can you file a bug too ;>
<meteoroid> pah it's so much easier than printf but whatev heh
<meteoroid> whatever makes ya happy
<LarstiQ> meteoroid: pdb is nice, but it could be better
<meteoroid> yah but it's not printf ;d
<LarstiQ> meteoroid: right. But I don't think we need more than printf right now, if I'm wrong and the problem isn't there, then pdb would be indeed less painful.
<meteoroid> sure, like i says, whatever makes ya happy
<Necoro> LarstiQ: ok - chmodding is the problem
<meteoroid> :-P
<LarstiQ> meteoroid: maybe you know the anwser to something I've been wondering for a while. I'd like to import pdb; pdb.set_trace() with an ipy style shell, not the default pdb one.
<LarstiQ> ipython that is
<Necoro> LarstiQ: http://rafb.net/p/rkLbL327.html
<Necoro> lifeless: ok - tomorrow ;)
<meteoroid> hm, i don't know off hand but have been meaning to learn more about ipy just for working with other folks
<lifeless> Necoro: thanks
<LarstiQ> Necoro: thanks
 * LarstiQ heads to bed
<Necoro> and I already used a repo w/o trees - so there are no filename issues ...
#bzr 2009-07-27
<DaffyDuck_> I would like to be able to specify the permissions for the repository files in branch.conf (or some repository configuration file), and that bzr always makes sure that files have the appropriate permissions.
<ronny> hmm, i have to make bzr a second-class thing in anyvc
<lifeless> ronny: why?
<ronny> lifeless: bzr is one of the 2 vcs's that think in terms of free form fs branches, basically everything else has repos that have branches
<lifeless> the other being hg? or darcs?
<ronny> darcs
<lifeless> what about codeville?
<ronny> didnt get a chacne to work with that one so far
<lifeless> hg encourages free for fs branches too, its why they make local cloning hardlink - they expect it to be used a lot
<lifeless> [and they don't support merged-branches in a single repo]
<ronny> lifeless: each of those is a full repo which may have multiple branches
<lifeless> ronny: not in the sense of a git or bzr branch
<lifeless> a branch in hg must have outstanding commits
<lifeless> its always semantic, never symbolic
<ronny> lifeless: hg's "fs branches" are full repos each with full decupling of network ops and merge ops
<ronny> what do you mean by outstanding commits?
<lifeless> a fork in the revision graph
<ronny> thats named branches
<ronny> i think they are more comparable to more explicitly used branch nicks than bzr branches
<ronny> my main gripe is the hiding of what is actually network operations, and what is local history operations
<ronny> in hg/git i do a pull, then merge, done, in bzr i say merge, and then it might end up doing network ops or not
<fullermd> DaffyDuck_: I used multi-local-accessed branches, and I haven't seen permissions get eaten in them.
<thumper> ronny: funny, in bzr I do, pull, then merge, done...
<lifeless> also, in git, you can have a single command update a branch, if its been configured that way
<ronny> thumper: but usually not within the same workdir
<lifeless> so, we want to make working with many branches substantially better
<lifeless> if you can identify things that have made your experiences doing that with different vcs's dramatically different, that would be good info to have.
<thumper> ronny: no, I have a script alias that pulls in my trunk branches
<ronny> lifeless: i think what throws me off most the emphasis on different kinds of transparency i perceive, in bzr one can do kinda whatever, and it will just work, no matter the cost, while in others stuff just wont work if its inefficient
<Tfnrsh> hey there which version of python needed for bzr ?
<Tfnrsh> notify n gtk doesnt work for me py2.6
<lifeless> Tfnrsh: it should work in 2.6; could you file a bug?
<Tfnrsh> incompatible API
<lifeless> Tfnrsh: it reports that as an error>?
<Tfnrsh> yes
<lifeless> that means your bzr and your bzr-gtk are not matching versions
<lifeless> nothing to do with your python version
<lvh> hi
<lifeless> hi
<lvh> big correlation between #bzr and #twisted again :-)
<Tfnrsh> oh okay thanks
<ronny> ok, time for me to play with commit building
<lvh> ronny: I thought you had mercurial poisoning
<ronny> lvh: well, for me it means making an api that works for hg, git, bzr and svn
<lvh> ronny: em, I'm doing the same thing. Is your code up somewhere?
<lvh> well, not svn. but hg git and bzr :-)
<ronny> http://bitbucket.org/RonnyPfannschmidt/anyvc/, not yet history sipport
<ronny> i"ll start writing more tests dor history ops now, then make em pass for hg, git and bzr
<lvh> ronny: I wrote something that bumps versions for apps automagically, based on repository status, so a universal VCS API is useful for that :-)
<ronny> lvh: i also hooked up with the roundup guys, the piano-man/pyvcs guys and the nautilus-vcs guys
<lifeless> ronny: for commits, 'tree.comm()' is the primary external interface
<lifeless> thats tree.commit
<lvh> ronny: I didn't like hg's internals very much.
<lvh> ronny: Cool. What are you doing with the roundup guys?
<lvh> ronny: Also how is what you're doing different from pyvcses project?
<Tfnrsh> hey there sorry to bother again but maybe u can take a look http://paste.arneburk.de/bzr_error.log
<lvh> wait, nvm, pyvcs isnt what I thought it was
<ronny> lvh: i'll do history building
<ronny> lvh: and i do massively test-driven development
<lvh> ronny: Cool. I found that to be hard when writing software that queries VCSes. Testing software that is entirely dependant on external state sucks :-D
<lvh> ronny: What I need is something that given a file in a repository, finds the repository (shouldn't be so hard, recursively peeking up the tree) and then finds some state about it, like tags, branches, commit mesage, etc -- and based on that, create a version.
<ronny> lvh: get me more hint, and you should have an api at the end of the week
<ronny> i'll start with commit building, then continue with historz reading
<lvh> ronny: hint?
<lvh> are you asking me for drugs? :-p
<lifeless> Tfnrsh: you need a newer bzr-gtk
<ronny> just more data on what exactly you will do
<lvh> ronny: okay, so. You have generic repository objects. How do you create them?
<lvh> Root path for a repo? or is any path below a repo fine?
<ronny> i try not to be smart about repo paths (i try to be smart about workdir paths)
<lvh> okay, that probably makes sense given 90% of your use cases.
<ronny> well, give me use-cases or give me tests :P
<lvh> ronny: well, 'finding a repository that likely manages this file' is one of my use cases
<lvh> which is sort of easy, I can do that myself and even add it to your project if you like. Just recursively peek up the tree for things like .git, .svn...
<lvh> all I really need is a sane api (preferably like a property) for branch, commitmessage, tag, things like that.
<lvh> I suppose it might be a problem that not all DVCSes agree on what the fundamental unit of a repo is.
<lvh> ronny: the reason i dont really care about cwd cleverness is because im much more likely to import your modules than to run your binaries.
<ronny> lvh: i trz to get away from invoking the tools
<lvh> okay, cool.
<ronny> *try
<ronny> need to do that for svn and git at some point
<lvh> also, it would be totally awesome if there was a more or less uniform interface for similar things, like HEAD vs tip, master vs default, etc.
<ronny> lvh: i'll try to work that
<lvh> unfortunately you're bound to pick a name, and then dvcs users who use a vcs different than the one that shares the names you pick will hate you.
<ronny> lvh: thats whz i will choose one everzone will hate equally
<ronny> get_default_master_head_tip_gtfo()
<lvh> ronny: typing on us qwerty?
<lvh> ronny: poor germans :-(
<lvh> ronny: or on qwertz and used to qwerty? :D
<ronny> lvh: yes, got a new keyboard shipped
<lvh> ronny: im learning dvorak, dont feel bad
<ronny> im used to qwertz, now i got a qwerty
<ronny> my old one for the laptop broke, and dell agreed to ship a us one
<lvh> ronny: ibm <3
<ronny> lvh: ibm for laptops is gone, and i dont like lenovo (subjective reasoning)
<lvh> ronny: I'm typing this from an X301
<lvh> it's not as good as my old thinkpad, no
<lvh> but it's still better than 90% of the shitty laptops out there
<ronny> lvh: mz m1330 is pretty decent
<ronny> lvh: btw, i"ll implement the same apis as the guy thats working on the new fs api pep
<ronny> so revisions will be like a readonly fs and commit building will be like an transaction in a writable fs
<lvh> ronny: that sounds really cool!
<lvh> although for now im mostly interested in inspection rather than mutation
<lvh> since having applications decide when versions are done is icky
<lvh> and that should be done based on passing unit tests, not repo status
<ronny> i could use such a thing to manage my release cycles later
<ronny> vellum, anyvc, pida, a set of pida plugins, some wsgi apps - release-management is a pain
<lvh> ronny: yes. I'd like to make something that makes it easier
<lvh> versioning is a part of that of course, but it would be nice if we could integrate it with unit testing and perhaps ticketing systems.
<lvh> however that would need an abstracted method of talking to ticketing systems, an abstracted method of talking to vcses (you're working on that apparetnly) and an abstracted way of running tests
<lvh> and importantly checking if they fail
<lvh> sooo, five perfect engineering motnhs :p
<lifeless> lvh: subunit
<lvh> also ,what's vellum? the only thing i can find is a weblog
<ronny> lvh: task based build system, in need of some love tho
<ronny> lvh: for an abstract way to run tests, count me in
<lvh> lifeless: hm, maybe -- but how does that keep working when you meet something like hkr's wonderful py.test, or nosetests, which don't enforce the TestCase hierarchy at all?
<ronny> i want way more metadata than subunit provides in a structured way tho
<ronny> lvh: nose builds on unittest
<lvh> ronny: yes, but py.test doesn't have to look like xUnit at all
<ronny> lvh: py.test is what i use
<lvh> ronny: yes, but you can write functional py.test like tetss in nose.
<ronny> lvh: nose simply wraps it up in testcase instances
<lvh> In fact if you dont need a setUp method (and ive had this once) the same module runs fine in both nose and py.test
<ronny> lvh: i did some aliasing and default parameter tricks to get it work in both with setup <P
<ronny> but by now i prefer pz.test
<lvh> ronny: yeah, I like py.test too
<lvh> but im afraid subunit doesnt
<ronny> subunit only provides a subset
<ronny> i"ll probablz use py.test as base and write a subunit consumer when i see fit later
<lvh> cosnumer in what context?
<lvh> maybe im too used to amqp
<lvh> but I'd expect a producer
<ronny> lvh: well, i want py.test to be the master running other stuff
<lifeless> lvh: subunit doesn't care; just need an outputter for that format
<ronny> lvh: so it consumes the result streams by others
<lvh> oh, I see.
<Tfnrsh> where to get a newer bzr-gtk just isntalled it from bzrs ppa
<Tfnrsh> at least i think so
<Tfnrsh> :D
<ronny> i dislike subunits text format tho
<lvh> ronny: so basically I see my project having a number (usually two) kinds of version numbers: releases, and nightlies.
<ronny> imho it should be pipable into a shell
<ofv> Hi. I have a very estrange problem with svn-import.
<lvh> nightlies happen on trunk, or master, or default or whatever your vcs calls it
<lifeless> ronny: perhaps bring it up on the subunit list, or file a bug? I pipe subunit around /all the time/
<ofv> it "imports" revisions that does not exist on the svn server...
<ronny> lifeless: doesnt make it valid shell code
<ofv> ... but that existed on a test svn repo that i deleted time ago.
<lvh> ronny: releases find the current release (im not sure how to do that -- do all vcses support something that looks like a tag?) and then increments it by one.
<lifeless> ronny: I think I don't understand what you're assking fo then
<ofv> the test repo was on the local machine. the real repo is on another machine.
<lvh> ronny: the biggest problem is figuring out a system for decidng what kind of version we want that's simple enough to actually use and complex enough to support peoples weird versioning fetishes
<ronny> lifeless: the subunit text format is not executable as shell code (given a few functions/executables are provided)
<lifeless> ronny: yes, I get that it isn't; but I'm not sure why that would be desirable
<lifeless> subunit does provide shell functions to output subunit
<Tfnrsh> well ok subversion then again :/
 * SamB renames bug 393349 such that "send" occurs in the title
<ubottu> Launchpad bug 393349 in bzr "Bundle (bzr send) broken with --2a format" [Critical,Triaged] https://launchpad.net/bugs/393349
<ronny> lifeless: simply cause its a text format that existed before, and allows to write dead-stupid reporters bz just creating aliases and then running the reports in their context
<ofv> found the problem. as the test repo was a copy of the real one, it had the same ID.
<lifeless> ronny: I must be lost; I created subunit, it didn't exist before ;). And making subunit output shell scripts would still be escapable by bad output, unless the output has to be escaped.
<ofv> svn-import remembered the location of the test repo(s) and imported from them insted of the real one. it imported from another test repo.
<jelmer____> ofv, svn-import will only import from the repository with the location you tell it to import from
<jelmer____> ofv, it won't try to open any repositories that it has imported from earlier, but it may cache data from repositories it has opened earlier
<ofv> jelmer____: it had this on subversion.conf:
<lvh> laptop nearly out of power, bye!
<jelmer____> ofv, it does remember those locations, but they are not used for anything at the moment
<ofv> locations = svn://qcore/tkidb;svn://localhost/repos/tkidb;file:///d:/repos/tkidb
<jelmer____> ofv, you should never have multiple svn repositories with the same uuid but different contents - it violates svn's basic model
<ofv> jelmer____: yeah, i know. it was a test. but bzr insists on remembering the test repo.
<jelmer____> ofv: You might want to remove bzr's cache
<jelmer____> ofv, or disable caching entirely - see the FAQ for details
<ofv> jelmer____: where is it?
<ofv> jelmer____: okay
<ofv> the cache is new news for me. i'm a total beginner.
<jelmer____> ofv, the cache would be in ~/.bazaar/svn-cache/<uuid> or ~/.cache/bzr/svn/<uuid>
<jelmer____> ofv, the cache is not something you would normally have to bother with
<ofv> i'm trying to find it. i'm working on windows.
<jelmer____> ofv, you'd also want to throw away any bzr repositories created from the test svn repository
<lifeless> ronny: its an interesting idea to make the output be function calls in shell, but it could be function calls in ocaml, or python equally.
<ofv> jelmer____: already did that. this seems a nightmare: revisions coming from deleted repos! :)
<ronny> lifeless: but shell is a universal standard interfacce on unix/posix, the rest not
<ofv> jelmer____: the faq link on http://bazaar-vcs.org/BzrForeignBranches/Subversion points to a non-existent page.
<jelmer____> ofv, I've fixed it to refer to the included FAQ with bzr-svn itself.
<ofv> jelmer____: fixed the problem. thanks for your help and for bzr-svn. it's great stuff.
<jelmer____> ofv, cool
<jelmer____> 'night all
<lifeless> ronny: C is also a standard :)
<ronny> lifeless: but not for on the fly execution
<lifeless> thats true.
<lifeless> I'm not getting why this is an important thing for the streaming serialisation format though
<ronny> lifeless: curently subunit is neither absilutelz stupidlz simple to parse, nor usalbe in neat powerfull hacks
<ronny> my typo rate is approaching the enforce sleep marker
<ronny> night
<lifeless> gnight
 * SamB wonders why the heck https://code.launchpad.net/~naesten/bzr/merge-1 doesn't contain anything from him at the tip ...
<spiv> SamB: what's your local revno?
<SamB> spiv: well, I think it came from a merge directive I sent in ...
<SamB> somehow!
<SamB> this one: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=7561#a7561
<SamB> or raw at http://hpaste.org/fastcgi/hpaste.fcgi/raw?id=7561
<SamB> leastwise, *I* never pushed it!
<SamB> spiv: any ideas?
 * SamB decides to report this against launchpad-code
<spiv> SamB: yeah, file it against launchpad-code, provide the raw text of the email in the report I guess
<spiv> SamB: a quick peek at the bundle suggests it does have your revision in it (as you'd expect)
<SamB> spiv: I attached it
<SamB> jelmer: you know, when you package a bzr release, you should check to see if any of the Debian bugs filed against it can be closed ;-)
<SamB> for instance, bug #339385 was imported from Debian and you forgot to close it in the changelog entry for bzr 1.17-1 ...
<ubottu> Launchpad bug 339385 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [High,Fix released] https://launchpad.net/bugs/339385
<SamB> I have, however, marked it fixed using bts(1)
<SamB> so that it shows up as fixed in 1.17-1
<SamB> as you can see at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517770
<ubottu> Debian bug 517770 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [Normal,Open]
<SamB> wonder why ubottu had it cached -- or is it using launchpad's out-of-date info?
<lifeless> ubottu only asks ubuntu
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<lifeless> sorry, launchpad
<rellis> I am trying to use the xmloutput plugin 0.8.4 with bzr 1.16.1 and I am missing the "affected-files" tag.
<rellis> Could this be a result of migrating from svn -> git -> bzr ?
<rellis> but then i figure i have new ocmmits since them igration.. and they'rem issing hte tag(s) as well
<SamB> lifeless: ah, that would do it
<SamB> apparantly launchpad has had trouble updating that debbug's status :-(
<lifeless> SamB: file a question in such cases on launchpad itself
<SamB> lifeless: I was just going to assume it was transient for the moment
<SamB> I'll come back to it if it's still stuck at the top of my bugs page next time I look at it
<SamB> right now, I'm going to file a bug against launchpad for flattening the email I attached to https://bugs.launchpad.net/launchpad-code/+bug/405111 when I submitted by email into the report itself
<ubottu> Launchpad bug 405111 in launchpad-code "improper handling of rich-root merge directives sent to non rich-root branches?" [Undecided,New]
<rellis> ah i was missing the -v switch, fail
<lifeless> spiv: if you're in a reviewing mood, 9307 please
<lifeless> EODing
<savvas0> hi, a newbie question: are the bzr commits signed with gpg? I just noticed the sign-my-commits command and was wondering :)
<savvas0> I mean, if I bzr commit, aren't the commits signed automatically?
<beuno> savvas0, no, you need to explictely sign them
<savvas0> thanks beuno! is there a command that checks which commits are signed?
<savvas0> ah.. there's --dry-run :)
<beuno> :)
<rellis_> is there a way to get bzr to tell me what changes exist in the branch source?
<rellis_> like xmllog but just the changes sine my last update
<bob2> bzr missing
<rellis_> cool, thanks
<rellis_> anyway to get that as xml instead of the normal format?
<bob2> no idea
<rellis_> fair enough
<beuno> rellis_, you should be able with the xml-output plugin
<beuno> bzr missing --xml
<rellis_> indeed
<rellis_> thanks
<stefanlsd> I keep trying to understand this but somehow fail - whats the difference in idiot terms between bzr init and bzr init repo
<bob2> init converts a dir to a branch
<bob2> init-repo converts a dir to a repository
<bob2> a repository has dirs in it, and they can contain branches (created with bzr init), but the actual revision data is stored in the repo root
<bob2> so, if you have branches that share a lot of revisions, a repository can save some disk and time
<stefanlsd> bob2: ok. thanks. that helps somewhat.   So if I understand it, in my case, i have a whole bunch of different projects non related to each other. So it would be better just using bzr init.
<bob2> you can go back and forth, but that would be simplest
<stefanlsd> bob2: great. thanks. If i start a project that will have multiple branches related to the same project, i will init repo. thanks. makes sense :)
<mwhudson> jelmer: hi, i think you upgraded a bunch of branches launchpad mirrors to 2a format
<jelmer> mwhudson, yeah
<mwhudson> hm
<mwhudson> i was thinking that in some cases the dev focus branch was a hosted branch launchpad and still in 1.9 format
<mwhudson> and things had broken
<mwhudson> but now i'm not sure what's going on...
<jelmer> mwhudson: does the dev focus matter unless they're stacked branches?
<ronny> moin
<mwhudson> jelmer: all mirrored branches are stacked on the dev focus
<ronny> can anzone point a lazy guy to a documentation on building in-memory commits with the api?
<jelmer> mwhudson, that would certainly explain the breakage since 2a doesn't stack on 1.9 :-)
<abhilashm86> i'm using ubuntu, i've installed bzr, do i have to create workspace,project files in /home/user or which is better?? bzr is installed in /usr/bin/bzr......
<mwhudson> right
<abhilashm86> i need to work in distributed CVS........
<mwhudson> i don't understand why https://code.edge.launchpad.net/~jelmer/bzr-svn/inventory is failing though
 * mwhudson will have to poke more tomorrow
<llml> hi, could anyone please help me figure out how to know at which revision the trunk has been most lately merged into certain branch as an up to date merge?
<luks> bzr qlog /path/to/trunk /path/to/a/feature/branch ?
<llml> luks: i guess qlog is not available in bzr 13.1?
<luks> qlog is from the qbzr plugin
<luks> it's the easiest way I can think of
<luks> but you can use bzr log on the feature branch, remember the revision and then look for the revision number in bzr log on trunk
<llml> luks: you mean check the log content?
<luks> yes
<james_w> bzr missing will show you what hasn't been merged, and then you can infer what has from that
<james_w> then "bzr log --show-ids" can help you identify when the merge was done
<luks> it kind of tricky to tell the last merge point from a list of "missing" revisions
<llml> james_w: against where it's pulled out from?
<luks> since it's a graph
<llml> james_w, luks: i love this trick. thanks:)
<abhilashm86> i have a file in /home/abhilash/mypro/subdirectory, so if i want to push it to my account, its not working,  bzr push bzr+ssh://abhilashm86@gmail.com/~abhilashm86/+junk/mypro
<abhilashm86> what is wrong with above command
<abhilashm86> i'm using launchpad
<awilkins> You're pushing to your email address?
<abhilashm86> awilkins: its my launchpad login account
<awilkins> How is it supposed to guess that you are pushing to launchpad when you're telling it to push to the gmail server?
<abhilashm86> i made a branch called airline, i want to push a file into my launchpad account.....how to do it
<ronny> lifeless: aware of any simple api-examples for building commits in memory?
<abhilashm86> awilkins: i followed a tutorial, there it showed, if i gave abhilashm86.launchpad.net, there was an error.....
<abhilashm86> http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html, this is the tutorial
<awilkins> abhilashm86: https://help.launchpad.net/Code/UploadingABranch
<abhilashm86> awilkins: https://code.launchpad.net/~abhilashm86/+junk/airplane, this is my account in launchpad
<abhilashm86> awilkins: ok i'll try this.........
<awilkins> abhilashm86: The first link you posted had your email address where the server should be
<abhilashm86> awilkins: oh ok, through command line, i logged into launchpad, so i thought it was right:) no problem i'll see your link, fine.......
<spiv> abhilashm86: "bzr+ssh://abhilash@gmail.com/..." tells bzr to connect to gmail.com via ssh
<spiv> abhilashm86: which is not what you want :)
<spiv> abhilashm86: in that URL, the part like "xxx@yyy" is not an email address, it's a username (xxx) and a hostname (yyy).
<ronny> LarstiQ: got any howto on building bzr commits from only the api
* You're now known as ubuntulog
<ronny> can anyone plase point me to some kind of description on how to build a commit in a branch using only the api
<Tak> builtins.py?
<ronny> Tak: nop, thats not it, i dont want to commit a workingtree, i want to commit something generated entirelz in memorz
<ronny> *y
<abentley> ronny: Use TreeTransform.commit, which is new.
<l1m5> does anyone know why i can no longer do 'bzr viz' in version 1.13.1?
<ronny> re
<ronny> abentley: uh, treetransform looks like it affects the workingtree, am i missinterpreting?
<l1m5> i used to be able to do bzr viz or bzr vis and get the visual representaton
<abentley> ronny: The TransformPreview variant does not.
<awilkins> l1m5: Have you got the bzr-gtk plugin installed?
<awilkins> l1m5: You may also wish to try qbzr (qlog command)
<jam> morning all
<ronny> abentley: i want something that doesnt affect the workingtree in any way ever, i want to operate directly on the repo
<jam> abentley: I have a question about something that is happening in the bundle code, if you have a couple seconds to chat
<jam> shouldn't take long
<jam> and the answer may be "I don't remember"
<abentley> ronny: The TransformPreview doesn't affect the workingtree in any way ever.
<abentley> jam: Shoot.
<l1m5> awilkins, ah, that's what i needed
<l1m5> the gtk plugin
<ronny> ok
<jam> abentley: in bzrlib.bundle.serializer.v4.BundleWriteOperation.write_revisions
<jam> you have the line:
<jam> (s)
<jam>         if self.target is not None and self.target in self.revision_ids:
<jam>             revision_order.remove(self.target)
<jam>             revision_order.append(self.target)
<l1m5> ty
<jam> Do you know why that was necessary?
<ronny> hmm
<jam> We first do a topological sort on the revisions, and then we have this code to push the current target to always be the last revision
<abentley> jam: Hmm...
<jam> the problem is in the bundle testing code we do "write(rev1, rev2)" and that interprets the arguments to mean that rev1 is the target
<jam> even though it is older than rev2
<jam> which causes *my* code to end up getting [rev2, rev1] which is *reverse* topological order
<jam> and means I don't get my parent text before the child text
<abentley> jam: I really don't remember.  It makes me think maybe it's backwards-compatibility code.
<ronny> ok, so i have to use transformpreview and its commit method
<jam> abentley: yeah, I tracked the line down to a rev which says "Refactor into separate reader and writer" but then it gets a bit lost
<jam> I'll poke a bit more and see what happens
<abentley> jam: It might be because bundle code interprets the last revision in the bundle as the target.
<jam> sure
<jam> if I change the test to be
<jam> write(..., [rev2, rev1]) then everything works fine
<jam> since the target is then a tip
<ronny> hmm, that transform api is awfull
<abentley> ronny: Can you offer some advice to improve it?
<ronny> abentley: i'll implement the apis like the one of the new filesystem api pep draft, they are pretty pythonic and painless
<ronny> (im doing that for bzr, hg, git and svn)
<ronny> none of the vcs's have pleasant api
<abentley> ronny: It solves a fairly awful problem, because it handles files regardless of name changes, file-id changes, parent changes, content changes, including files that have only a file-id and no contents, and files that have contents but no file-d.
<ronny> abentley: file with content but no id = yet to be initially commited?
<abentley> ronny: I don't know what you mean about initially committed.
<ronny> well, when does a file get its id?
<abentley> ronny: When you "bzr add" it, usually.
<ronny> so files without id but content are unknown/ignored things in the wd?
<abentley> ronny: yes.
<ronny> so now the api question, if all the stuff has to be managed anyway, why expose all that magic confusing number to poor programmers
<ronny> the ai should dee all the bookkeeping
<ronny> *api
<abentley> ronny: By "magic confusing number", you mean the trans_id?
<ronny> abentley: yes
<ronny> as far as i can see, i have to do at least 3/4 steps to deal with adding a file and its content
<abentley> ronny: Because any other way of referring to the file is ambiguous and leads to the risk of accidentally overwriting files, or attemting to move files from places where they no longer are.
<ronny> create path, add content, schedule for versioning
<abentley> ronny: See new_file.  That creates the path, adds, the content, adds a file-id.
<ronny> hmm, now, i also need to figure how the heck i would tell it a file changed
<ronny> all i really want to do is operate on it like on a normal filesystem
<abentley-lunch> ronny: To change a file, call delete_contents, followed by create_file.
<dobey> what does "(format: unnamed)" mean exactly? :)
<bialix> ronny: what is filesystem api pep draft
<ronny> bialix: draft for a pep to get reasonable filesystem apis into the stdlib
<bialix> it has the page?
<ronny> http://eagain.net/blog/ is a good starting point
<ronny> hmm
<ronny> ok, no matter how much i tinker with the bzr treetransforms, i cant figure how to use them, they just suck
<bialix> not very much info
<ronny> bialix: there is more in the linked git repos
<bialix> we Russians usually say about "spherical horse in a vacuum"
<ronny> abentley: why the hell did you recommend PreviewTransform over MemoryTree, i despiese you now
<abentley> ronny: because we've put a lot of work into making TreeTransform.commit work recently.
<ronny> abentley: that doesnt change the amount of pain on using those
 * Tak feel the love
<abentley> ronny: I'm sorry that you feel that way.  I recommended the interface that I know works.
<ronny> all i know is that the treetransform interface is a huge confusing pain
<abentley> ronny: Not to me.
<ronny> abentley: then you are appearantly very trained at bearing it
<ronny> it fails at being intuitive and it fails at keeping practically useless data away from me
<abentley> ronny: Well, I am its author, so that helps.
<abentley> ronny: It is a low-level API.  It is designed to solve difficult problems.  The suggestions you've proposed to make it more intuitive would make it unable to solve those problems.
<dgoulet> Hey people, someone can tell me how to get the committer string of the last revision of a branch via bzrlib ?
<LarstiQ> dgoulet: branch.repository.get_revision(branch.last_revision()).committer
<dgoulet> i need to open a Branch before? (branch.Branch.open(BRANCH_PATH) ?
<dgoulet> from this object, can I get the get_revision function ?
<LarstiQ> dgoulet: opening a branch like that is one way to get the `branch` object in my line, yes
<LarstiQ> dgoulet: after that, exactly what I wrote will get you the committer for the last revision on that branch
<LarstiQ> dgoulet: note that get_revision is on branch.repository, not on branch
<dgoulet> hmm ok
<dgoulet> i'll try right now
<dgoulet> fantastic
<dgoulet> thx a lot
<LarstiQ> ronny: looking at some scrollback (but not all), if all you want to do is commit snapshots, memorytrees and perhaps commitbuilder sound easier than TreeTransform
<luks> note that you migh want .get_apparent_authors instead of .committer
<luks> .get_apparent_authors()
<LarstiQ> dgoulet: right, what luks said.
<LarstiQ> synic: are you the author of the synic vim colorscheme?
<synic> in a post hook in a bzr plugin, how do I obtain the commit's comment?
<synic> LarstiQ: yes.
<dgoulet> ok ok
<dgoulet> works very well
<dgoulet> thx
<ronny> LarstiQ: i'll use memorytree now
<LarstiQ> ronny: did you get anywhere on the hg backend btw?
<ronny> LarstiQ: didn't work on it yet
<ronny> i decided to make the fun game again
<ronny> ie do it for bzr, then do it for hg in a small fraction of the time
<LarstiQ> ronny: I'll grant you that you might know hg better, but it is a bit of a cold vs hot cache comparison
<ronny> LarstiQ: not really, hg is kind of a pleasure for reading and understanding and bzr reliably fails at that
<LarstiQ> ronny: still allows for experimental bias *shrug*
<ronny> well, everz time i hac something that uses bzr i end up reading 2 orders of magnitude more code than when i do the same for hg
<LarstiQ> synic: assuming you mean post_commit, looking at `bzr help hooks` output but not testing, I'd say master.repository.get_revision(new_revid).message
<LarstiQ> ronny: could you give me a hg codebase tour next time we're geographically colocated? (were you going to HAR?)
<synic> LarstiQ: ok, thanks
<ronny> LarstiQ: sure, btw, whats HAR?
<LarstiQ> ronny: har2009.org
<LarstiQ> ronny: Chaos summercamp, but in .nl
<ronny> hmm, i wont be there
 * LarstiQ nods
<LarstiQ> after that the next event I'm attending is the CCC itself I think
<LarstiQ> or maybe Maschinenfest, but that's not ideally suited to hacking :)
<ronny> hmm, maschienenfest looks like fun tho
<LarstiQ> I hope so :)
<LarstiQ> synic: also, to be complete, post_change_branch_tip might be interesting as well
<jfroy> Is there a way to get finer-grained changes for bzr shelve?
<jfroy> A few of the clusters I get are too coarse :|
 * SamB has been wanting the same from "darcs record"
 * SamB also wonders why "bzr commit" doesn't offer even that level of control to those that want it
<Raim> jfroy: yeah, hunk-splitting would be good
<abentley> jfroy: No, sorry.  I plan to support pulling launching an external program for that case.
<Raim> jfroy: but unfortunately there is no way at the moment
<jfroy> :sad:
<ronny> jelmer: sup, gout anz code around where you build complete commits with subvertpy?
<ronny> (using the remoteaccess api)
<jelmer> ronny, Yeah, see the examples/ directory
<jelmer> (ra_commit.py)
<ronny> jelmer: it doesnt add/change files tho, and i have no idea how fileeditors work
<dobey> can anyone tell me how i can get the repository format updated for a branch on launchpad?
<verterok> dobey: did you upgraded the branch in lp?, eg: bzr upgrade --<format> lp:<branch-name>
<dobey> verterok: that's what i typed on the command line, yeah
<dobey> verterok: it looks like Branch format: changed, but not Repository format:
<verterok> dobey: and the upgrade finished ok? :)
<dobey> it didn't die, and said it was ok
<dobey> so i presume so
<dobey> https://code.edge.launchpad.net/~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk
<verterok> dobey: it's a stacked branch?
<mwhudson> it can take a while for the web page to update
<dobey> verterok: no
<mwhudson> (well, until you push a change basically)
<verterok> dobey: I think lp will update the format info once it's re-scanned, e.g: type filter texta enw commit
<dobey> hrmm
 * dobey tries
 * verterok can't write :/
<mwhudson> bzr info nosmart+lp:~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk
<mwhudson> try that ^
<dobey> hrmm
<dobey> ok
<dobey> i wonder why it doesn't say 2a though
<lifeless> dobey: what does it say
<dobey> Standalone branch (format: 1.14-rich-root or 1.9-rich-root)
<lifeless> can you add -v to the command please
<lifeless> the paste the repository line
<dobey> to info or upgrade?
<lifeless> info
<dobey>     repository: Packs 6 rich-root (uses btree indexes, requires bzr 1.9)
<dobey> which is what lp now says as well
<lifeless> so, its definitely not 2a
<poolie> hi jam
<dobey> indeed
<poolie> hi lifeless
<jam> hi poolie
<lifeless> and whats the exact upgrade line you used?
<dobey> which is odd, given i did upgrade --2a and it said it succeeded and updated the repository
<lifeless> hi jam, poolie
<dobey> lifeless: i upgraded to 1.9-rich-root, and then i did 2a
<jam> dobey: doing "bzr upgrade --2a repo/branch" only upgrades the branch, not the repo
<lifeless> dobey: I'd like you to copy and paste the line you used
<jam> and the latest format branch is the same as the 1.9-rich-root branch
<lifeless> jam: its on lp, no shared repo
<poolie> jam, shall we talk?
<dobey> lifeless: bzr upgrade --2a lp:ubuntuone-client
<dobey> lifeless: after a successful --1.9-rich-root upgrade
<lifeless> do you have its output? could you pastebin it
<jam> poolie: sure
<jam> call the house or skype directly
<dobey> lifeless: http://pastebin.ubuntu.com/234769/
<lifeless> extremely odd
<dobey> indeed
<lifeless> dobey:
<lifeless> robertc@lifeless-64:~$ bzr info -v nosmart+bzr+ssh://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/trunk/
<lifeless> Repository branch (format: 2a)
<lifeless> dobey: the upgrade worked, whatever info command you are using is failing
<dobey> weird
<lifeless> whats the info command you're using?
<dobey> bzr info -v nosmart+lp:~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk
<dobey> oh crap
<dobey> wow i'm dumb
<lifeless> ubuntuone-storage-protocol != ubuntuone-client
<dobey> yeah, i see that now
<lifeless> I wish we had more flexible urls
<lifeless> so
<lifeless> ~
<lifeless> ~group/ubuntuone/client/trunk
<lifeless> would be nice
<dobey> hrmm, though now i can't seem to upgrade --2a ubuntuone-storage-protocol
<dobey> bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/9a/14/backup.bzr'
<lifeless> you'll need to remove that backup
<dobey> how?
<lifeless> or pivot it back into place
<dobey> ssh lp rm -rf?
<lifeless> well, firstly, check the branch is currently intact
<lifeless> info -v will do
<lifeless> assuming it is, lftp sftp://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk
<lifeless> rm -rf backup.bzr
<dobey> yeah it looks ok
<lifeless> win 35
<dobey> ok, cool. now they are both upgraded to 2a
<dobey> lifeless: thanks, sorry for my pebkac :)
<lifeless> np
<lifeless> its happened to folk before
<lifeless> I think allowing more freeform branch structure would help
<lifeless> as you are squashing multiple bits into a single directory component
<dobey> i don't think it would have helped. my problem was that i just typed a completely different thing than what i wanted. if i would have typed the same thing in a different format, i still would have been just as confused at the results :)
<lifeless> it may have been easier to spot
<ronny> jelmer: how does FileEditor.apply_textdelta work ?
<dobey> maybe. but i don't think i would have spotted it as it didn't occur to me that i might have typed the wrong thing there, especially since it succeeded, just on the wrong project. and i guess one still wouldn't be able to arbitrarily replace - with / in a project name, as it would cause problems if someone started a foo-bar-baz project to implement foo-bar for baz, and they both were on launchpad.
<dobey> but eh
<dobey> it's all good now
<jelmer> ronny, apply_textdelta will return a function that you can feed txdelta objects, to be terminated by a call with None
<jelmer> ronny, you can use subvertpy.delta.send_stream(<file-like-object>, <txdelta-handler>) if you don't want to do this manually
<ronny> jelmer: so i get the txdelta handler bz calling apply_textdelta, and then use send_stream?
<jelmer> bz?
<ronny> *by
<jelmer> apply_textdelta() will return a txdelta handler
<ronny> still getting used to the us layout
<jelmer> ronny, yes
<jelmer> ronny, :-)
<jelmer> ronny, you had me wondering what bz was an abbreviation for :-)
<ronny> well, i have a new found hate for many of bzr's apis tho
<lifeless> ronny: ?
<ronny> jelmer: so many things that are painfully more complex/complicated than necessary
<lifeless> ronny: my guess would be you're using overly low level apis
<ronny> lifeless: someone pointed me to TreeTransform instead of MemoryTree
<ronny> lifeless: but both of them are pretty painfull
<ronny> lifeless: both api"s require too much bookkeeping about magical id's
<lifeless> ronny: bzr's data model is built around inodes, not paths
<lifeless> ronny: but there are trivial mappings
<lifeless> ronny: what are you trying to achieve?
#bzr 2009-07-28
<ronny> lifeless: im going to build the api's of the filesystem draft pep on top of hg, svn, bzr and git for viewing revisions/building commits
<lifeless> to build a commit, use tree.commit()
<ronny> thats what i use now
<lifeless> or if you like, you can use branch.get_commit_builder, which is a lower level API; under some specific circumstances it would be easier (e.g.. if you have a delta to apply)
<lifeless> I'm not sure what you mean when you say 'building commits' though
<lifeless> generally, if you have a tree on disk, its just 'tree.commit("foo")' and you're done
<lifeless> I don't really get why that requires /any/ bookkeeping
<ronny> open a revision as a 'filesystem', do highlevel operations, commit the results
<ronny> this is a repo op that doesnt involve workingtrees
<ronny> for normal commits all i do is wt.commit
<ronny> the workdir apis work quite well
<ronny> now im dealing with creating and viewing history
<lifeless> ok
<lifeless> so for viewing history, the same readonly api as wt's have should work
<lifeless> unless you're doing remote operations nearly any api will be plenty fast
<ronny> i plan to keep a larger distinction betwen network ops and local ops
<ronny> and i need to figure what the heck to do with bzr repos, they actually do matter in some situations
<lifeless> if you want to be able to do arbitrary operations to create commits, MemoryTree should be fine - but it may be incomplete. Its a test helper, which, while correct, is not complete. It only does what we have needed it to do so far.
<lifeless> TreeTransform - I am not extremely familiar with it, but it is the core workhorse for merge/revert/checkout style operations.
<ronny> transform seemed pretty painfull to use
<lifeless> Using a TreeTransform on top of a revisiontree has a commit method these days, and as long as you use bzr 1.18 there are good checks that the deltas it commits will be consistent
<ronny> it seems to make absolutely no sense, and the implementation is quite scarry
<lifeless> As I say I'm not extremely familiar with it. Its model is to assign a unique id for every operation in the transform, accumulate your changes, then check everything is consistent.
<lifeless> There is some confusion between fileids (inodes) and transform ids (temporary to the operation)
<lifeless> My tendancy, if I wanted to present a tree like interface, would be to improve MemoryTree
<ronny> yeah, it seems more workable
<jam> spiv: are you around?
<spiv> jam: I am.
<poolie> hullo spiv
<jam> hey spiv
<spiv> poolie: good morning
<jam> Just wanted to let you know that I'm interested in reviewing whatever you have for the inventory delta code
<jam> (as I finally got the bundle stuff  finished)
<jam> I can review your last patch more thoroughly
<jam> or you can resubmit something if you've had a chance to look at why it wasn't actually being active
<lifeless> jam: I had a question
<spiv> jam: review what I have, please.
<lifeless> the serializer that you use, what format does it actually output? xml?
<lifeless> [and if so, /which/ xml?]
<jam> spiv: ok. I still know that it doesn't actually work, but I can look over the code assuming it does :)
<spiv> jam: I'm digging into why it doesn't seem to be used today, but it shouldn't make a large difference to the patch...
<jam> lifeless: xml v7
<jam> IIRC
<lifeless> jam: Are you using CHKrepo._serializer.write_to_string ?
<jam> it is fairly obvious in the patch, because I had to change away from being v5
<jam> lifeless: write_inventory_to_string, yes
<lifeless> I have a proposal
<lifeless> make that not work
<lifeless> and instead make CHKRepository.get_inventory_xml work
<lifeless> or at least, change the method to say that it gives xml
<jam> as in documentation or as in changing it to
<jam> write_inventory_to_xml_string
<lifeless> CHKRepository wasn't meant to output xml ever
<lifeless> so this is kindof a backdoor
<lifeless> One I understand the need for, at least until we get a semantic delta based bundle
<jam> right
<lifeless> I think it would be good to make it more explicit about whats going on
<jam> With spiv's code close to landing, I'd like to make a bundle which is a "GenericStream"
<lifeless> and the method that seems clearest to me is the repo.*inventory_xml* set of functions
<jam> which then knows how to stack on another repo, etc.
<lifeless> jam: I think that would be lovely; I've wanted to do that for ages too :)
<jam> lifeless: i suppose. Though the bundle code was already dealing with "target_format.serializer.write_inventory(source_format._serializer.read_inventory(bytes))"
<jam> we need a reasonably efficient generic stream implementation, which I think Andrew is getting close to
<lifeless> jam: its not clear that xml is involved there; I'd like it to be clear that it is xml.
<jam> so I'm a bit concerned about the deprecation dance of introducing a different name for the same function
<lifeless> Its up to you.
<lifeless> I realise its not immediately-in-scope.
<lifeless> that said, other folk who use this API will be surprised when huge amounts of IO are done to satisfy 'write_inventory_to_string'
<jam> well, given that it is inherently a whole-tree operation
<jam> regardless of whether it is XML or not...
<lifeless> jam: well, its a thought
<lifeless> ust trying to deter people from using  it
<jam> lifeless: so what we need is a code level "did you really mean to do this check". :)
<jam> Issue a warning when vim saves the file
<lifeless> that would be lovely
<lifeless> perhaps a code test for uses of that function
<spiv> We should rename get_bytes_as, I think.
<lifeless> to?
<spiv> Something else ;)
<spiv> it returns more than bytes...
<lifeless> it shouldn't
<lifeless> it should always be returning a bytestring
<spiv> It already returns lists of bytes ('chunked')
<lifeless> mm
<spiv> My inventory-delta patch further (ab)uses it to return inv deltas.
<lifeless> oh
<lifeless> I'd rather you didn't do that
<lifeless> doing that doesn't fit with the layering
<lifeless> If you'd like more bandwidth to discuss, we could have a call; I'd be extremely happy to help find a good home for the deserialisation call that is needed
<spiv> Well, it wouldn't be a big deal to add a new method to just InventoryDeltaContentFactory.
<lifeless> spiv: so CF are meant to be just about byte storage and transport
<lifeless> you should pass the bytes they transfer to something that knows how to handle them
<lifeless> IDCF sounds like a layering mistake in the first place
<spiv> But for in-process streams I don't want to serialise down to bytes and back.
<lifeless> right, so don't!
<spiv> I'm not ;)
<lifeless> it sounds like you'e using a byte transport mechanism though
<lifeless> which is where the layers are confused.
<spiv> Well, I'm using "record streams", which appear to actually be "content factory streams".
<spiv> What mechanism would you expect?
<lifeless> may I call?
<spiv> lifeless: sure, but give me a minute
<lifeless> record streams are for transfer of bytes
<lifeless> inventory deltas have a in memory representation (though I was thinking we should make an object for them, just recently)
<lifeless> when we stream inventory components using content factories, we are streaming ytes
<lifeless> and we [de]serialise on both sides
<spiv> lifeless: you can call now
<EricInBNE> hihi....so what is the status of bzreclipse?
<EricInBNE> eg - what doesnt it support
<EricInBNE> (coming from a svn POV)
<lifeless> EricInBNE: I'm not sure
<lifeless> what does svn support ? :)
<EricInBNE> commit, merge, show history, revgraph, revert, etc
<EricInBNE> lifeless, BzrEclipse says: update supported (very basic)
<EricInBNE> what does that mean
<lifeless> I'm not sure - I don't use eclipse often
<lifeless> folk do use it - you could drop guilherme an email if you need more detail than the wiki page has
<EricInBNE> ah - it doesnt support authentication
<EricInBNE> cheers
<Jemsquash> Does anyone know when there is going to be an update for the bzr eclipse plugin so that it will work with the Galileo release?
<lifeless> Jemsquash: I don't - could you file a bug on it?
<Jemsquash> Yes I can.
<poolie> it looks like the nightlies still don't have all the right extension libraries
<poolie> i wonder if the releases are missing them too - that could cause some performance problems
<poolie> anyhow putting head down now
<lifeless> time for your nap?
<poolie> nice idea
<poolie> i'm going to dream of long release cycles
<poolie> and drool a bit onto an editor
<lifeless> \o/ very close now
<lifeless> dirstate children-of-removed-dirs + dirstate-C version to go, and we're golden
<RenatoSilva> I've downloaded bzr 1.17-1 windows installer, but bzr version is reporting 1.17 (msising the "-1")
<lifeless> thats correct
<lifeless> the installer suffix is the installer suffix
<lifeless> 1.17.1 would be 1.17.1-1
<RenatoSilva> ah ok
<RenatoSilva> I'd never grok that
<lifeless> if the installer has a bug you get 1.17-2
<lifeless> if bzr has a bug you get 1.17.1-1
<RenatoSilva> ok
<RenatoSilva> how to list saved locations? I know I asked this before, but I can't recall
<lifeless> bzr info?
<RenatoSilva> thanks
<RenatoSilva> now, I have a problem on applying a patch built with bzr send
<RenatoSilva> ok solved
<RenatoSilva> How to merge with a patch without having to commit?
<RenatoSilva> I mean, imagine you commit 2 new revisions, then bzr send -o patch.diff, then in the target branch, you bzr merge patch.diff, but you get uncommitted changes. You have to commit something like "merge with xyz"
<lifeless> thats right
<RenatoSilva> But actually you just want to put the 2 new revisions in the top of the tree
<lifeless> if you want that, do bzr pull
<RenatoSilva> lifeless: thanks!
<lifeless> EODing
<crisb> hi, i'm getting a hang running bzr selftest on AIX at bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch
<crisb> can anyone give me some pointers in order to figure out whats happening?
<crisb> from the bzr.log i can see its running bzr check --branch http://localhost:47422 and returning "ERROR no branch found at specified location" - which seems to be the point of the test?
<crisb> i can see from netstat that it seems to still be listening on that port but when i try bzr check myself i get "Unable to handle http code 504: Gateway Time-out"
<crisb> should it still be listening at this point?
<spiv> lifeless: btw, that mysql branch with the slow get_parent_map HPSS requests is 1.9: https://code.edge.launchpad.net/~mysql/mysql-server/mysql-next
<AfC> Did the dotted revno numbering scheme change recently? I know jam and others have talked about it.
<spiv> AfC: I don't think so.
<AfC> Then I think that loggerhead thing on your launchpad site is buggy.
<AfC> Someone [else] mentioned this URL when closing a bug http://bazaar.launchpad.net/~afcowie/java-gnome/mainline/revision/654.1.3
<AfC> that web page says "This revision was merged to the branch mainline in revision 654."
<spiv> Hmm, odd.
<AfC> but that's not true; this revision was merged to 'mainline' later, in 655 as it happens.
<AfC> http://bazaar.launchpad.net/%7Eafcowie/java-gnome/mainline/revision/655
<AfC> note appropriate commit message.
<spiv> Right, that does sound like a loggerhead bug.
<spiv> Care to file it?  Or I can do it if you like, I'm at the bug tracker atm anyway.
<AfC> [I was hoping it was a case of "Bazaar upstream has changed numbering, but my bzr / bzr viz hasn't" but the commit messages give it away (even without comparing revids]
<AfC> spiv: if you would
<AfC> I'm about to step out
<spiv> AfC: sure.
 * AfC admits that he doesn't use loggerhead
<AfC> (or launchpad, for that matter) so I appreciate you confirming that this was a glitch.
<spiv> Not a problem.
<AfC> spiv: incidentally, now that those URLs are out there (apparently), should bzr change its dotted revno scheme, then you might want to consider changing the URL scheme in use above, perhaps to http://bazaar.launchpad.net/~afcowie/java-gnome/mainline/revno/655.1.3 or something
<AfC> just something to mull over
<AfC> (or put in a wizard mod_rewrite rule, or...)
<spiv> lifeless: ah, the slow get_parent_map is probably the C extension regression bialix just reported!
<spiv> Yeah, that's true.  We'll definitely need to tread carefully if we do change the scheme to avoid too many disruptions.
<spiv> Silently giving different pages would probably be worse than 404ing, too.
<AfC> spiv: at the end of the day, this is what HTTP 301 Moved Permanently is for; if you had some code that understood both schemes then you could use a redirect like that (ie 301 from .../revision/654.1.3 to .../revno/655.1.3/ in this contrived example)
<AfC> spiv: [we just went through that when we moved our blog]
<spiv> The revision/... scheme also allows revids, so just changing "revision" to "revno" in the URL might not be quite right.  Just "rev" might do, though.
<spiv> AfC|out: https://bugs.edge.launchpad.net/loggerhead/+bug/405686, btw
<ubottu> Launchpad bug 405686 in loggerhead "Revision page for a dotted revno has incorrect "was merged into" revision" [Undecided,New]
<spiv> AfC|out: thanks for the report.
<AfC|out> spiv: sure. Glad I noticed. Just a little glitch.
<ronny> lifeless: aware of any bts for subvertpy? i have it crashing my unittests here and jelmer is missing
<luks> https://bugs.launchpad.net/subvertpy ?
<ronny> ok, im blind and need coffee
<crisb> i'm getting a hang running bzr selftest on AIX at bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch can anyone give me some pointers in order to figure out whats happening?
<spiv> crisb: I'd love to but I'm about to log off for the day :(
<spiv> crisb: hopefully someone else will turn up soon, otherwise you can file a bug or post to the list.
<crisb> spiv: cheers :)
<Kinnison> Is there an easy way to alter my whoami information based on which directory I'm in?
<Kinnison> e.g. to have ~/work say "Daniel Silverstone <dsilvers@simtec.co.uk>" but ~/personal be "Daniel Silverstone <dsilvers@digital-scurf.org>" ?
<spiv> Kinnison: yes
<Kinnison> spiv: can I ask for a pointer to the right bit of docs, or else an example?
<spiv> Kinnison: put an "email = Daniel Silverstone <dsilvers@simtec.co.uk>" line in a [/home/dsilvers/work] section of ~/.bazaar/locations.conf
<spiv> And similarly for ~/personal, of course :)
<Kinnison> thanks
<spiv> I do exactly that myself.  Well, with slightly different directories and identities ;)
<Kinnison> oddly
<Kinnison> :-)
<poolie> spiv, nice catch there
<poolie> :) hello kinni
<crisb> i'm getting a hang running bzr selftest on AIX at bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch can anyone give me some pointers in order to figure out whats happening?
<jelmer> abentley, hi
<jelmer> abentley: "bzr shell" currently repeats the previous command on empty commands, that's intentional I presume?
<spiv> poolie: bialix caught it, originally.
<spiv> (assuming you mean the broken C extension import)
<bialix> accidentally
<Kinnison> poolie: hihi
<ronny> jelmer: found the issue
<jelmer> ronny, cool, what was it?
<ronny> jelmer: appearantlz svn does an abort if the path in get_file starts with a /
<bialix> jelmer: IIUC it's default behavior of std python cmd lib
<jelmer> ronny: subvertpy should be taking care of that
<jelmer> ronny, perhaps we don't yet in that particular situation
<ronny> well, now you know, so it will get fixed
<jelmer> ronny: What version of subvertpy are you using?
<ronny> jelmer: im tracking your bzr version
<jelmer> ronny, we're already canonicalizing
<jelmer> ronny, hence my question about what version you are running
<jelmer> ronny, actually, I can reproduce it now - thanks
<SiDi> Hello. I'm trying to push to a lp bzr repo from behind a proxy using corkscrew, and i'm getting this error : bzr: ERROR: Connection closed: please check connectivity and permissions. Any idea what this means ? :/
<amanica1> SiDi: its trying to go through ssh
<amanica1> which is probably blocked by your proxy
<amanica1> I mean it doesn't try to go through the proxy, and is blocked by your firewall
<spiv> SiDi: the TCP connection is being closed (or failing to connect?) on bzr
<SiDi> Alright
<SiDi> So i'm doing something wrong, i guess :/
<spiv> Push to lp is via ssh, as amanica1 says.
<amanica1> I'm not sure if lp supports pushing over bzr+https
<awilkins> SiDi: You need to ask your network admin to open port 22 for you
<spiv> So if you can ssh bazaar.launchpad.net, bzr should work.
<spiv> amanica1: not yet, unfortunately
<spiv> if "ssh bazaar.launchpad.net" doesn't work (even with your lp username added), then bzr can't work either.
<SiDi> awilkins: my network admin is a guy who thinks a QoS allowing 3KB/Sec when there are 6MB available and 100 people on the network (and its a residence, not an office) is a good idea :p
<SiDi> ok thanks for the infos
<SiDi> Im gonna stab my network admin >_>
<ronny> jelmer: you got twitter by any chance?
<jelmer> ronny, yeah, http://twitter.com/ctrlsoft
<ronny> k
<luks> jelmer: wow, I've just seen the svn send format. thanks a lot for finishing that!
<abentley> jelmer: Actually, I think it's the default behaviour.  But I'm okay with changing it to do nothing, like bash.
<jelmer> luks: No problem, thanks for starting that.
<jelmer> luks, I've also done a "bzr send --format=git" based on the svn send format
<jelmer> luks, Which creates "git am"-compatible patches, although as one concatenated file at the moment rather than individual attachments.
<jelmer> abentley: Thanks - I'll file forward the Debian bug then.
<lifeless> jelmer: what does the svn send format do?
<jelmer> lifeless, send svn-like diffs without bzr-specific metadata
<jelmer> lifeless: Including mentioning the svn revision numbers that the delta's of individual files are against
<lifeless> cute
<thekorn> hi, is there a release of bzr-gtk somewhere for jaunty (ideally in a PPA) which works with bzr 1.17?
<thekorn> I get a lot of messages like """Unable to load plugin 'gtk'. It requested API version (1, 13, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 17, 0), and the maximum is (1, 17, 0)""" when using bzr from the ~bzr team ppa
<jelmer> LarstiQ, ^
<OllieR> Is it normal for bzr to be uploading 3000kb to commit a one character text change?
 * dobey pleas for help
<bialix> OllieR: perhaps your commit triggers repack
<OllieR> bialix: what on earth does that mean?
<bialix> are you aware of `bzr pack`?
<bialix> current repository formats store committed data in the form of "packs"
<bialix> every new commit add new "pack"
<bialix> when there is many pack files in repository it should be repacked otherwise things become slower than needed
<bialix> commit or push or pull can trigger automatic repack of repository
<bialix> unfortunately in remote repo case bzr do repack on client side, i.e. it has to download big amount of data, repack it into single file and upload it back
<bialix> OllieR: hth
<bialix> repacking on server side should be implemented in recent bzr versions, but I don;t know for sure
<bialix> dobey: if you want to ask it's better to just ask in IRC. somebody will answer or not
<awilkins> It repacks server side as long as you're using a smart protocol
<bialix> I suppose it was fixed recently
<awilkins> Dumb protocols... I think it still repacks over the wire. Which is a bummer when your dumb protocol is a windows fileshare over VON
<awilkins> VPN
<bialix> why it's bummer?
<awilkins> Because VPN is slow
<awilkins> (well, over my 512Kbit/s upload, repacking a 70MB repo is
<awilkins> I usually get someone in the office to do a repack locally before I touch it if I see the packing start
<fullermd> NEWS says the server-side autopack was in 1.9, so it's been around a while (doesn't help on dumb transports of course, but not much does)
<dobey> bialix: yeah. i'm just trying to understand what to ask, because i'm not sure if it's a bzr issue or a lp issue
<bialix> may be some sort of server-side daemon that repack onsite will help with VPN?
<awilkins> bialix: That would be a reasonable idea. I call it "users".
<bialix> haha
<dobey> but basically, i can't seem to push a branch to launchpad successfully that is stacked on a 2a branch
<fullermd> "bio-cron"   :p
<awilkins> It would be nice.... we serve some of the branches out of an IIS box and sometimes I think it would have been nice to just have that since it has a smart server.
<bialix> Neo: the Matrix has you...
<eydaimon> bzr plugins lists blow 1.11
<eydaimon>     Loggerhead web viewer for Bazaar branches.
<eydaimon> but when I do bzr serve --htt[
<eydaimon> http evenI get errors
<awilkins> I'm currently racking my brains thinking about porting Mercurial pbranch to Bazaar.... there must be an easier way than reading the pbranch.py file and trying to trans-code it to bzrlib
<eydaimon> bzr help blow does say This provides a new option "--http" to the "bzr serve" command, that ...
<bialix> pbranch instead of loom?
<bialix> awilkins: is not bzr-pipeline is another alternative to loom?
<ronny> jelmer: what are the plans for doing all lower level workdir operations of git in dulwich?
<eydaimon> what's the easiest way to track one particular file and see revisions only for that file?
<eydaimon> I don't want to have to do bzr log on it, check revision, and keep doing diffs by hand. it's tedious
<bialix> bzr log FILE?
<eydaimon> as I said, bzr log only tells me that the file has changed
<eydaimon> I'd easily like to be able to navigat the revisions and see what has changed
<eydaimon> which means bzr log FILE ... look... bzr diff revno... bzr log FILE ... look ... bzr diff other_revno... etc
<abentley> eydaimon: log can also show diffs, if you want.
<awilkins> bialix: bzr-pipeline is stacked branches, like loom
<eydaimon> ok, thanks
<bialix> bzr log -p FILE
<awilkins> bialix: I have two ways to what I want ; add parallel featues to pipeine or port pbranch
<bialix> or bzr qlog FILE ;-)
<bialix> I have not tried pipeline yet, but from abentley announce I was under impression it's more than stacked branches
<eydaimon> the annoying thing is I have to keep track of all the revisions since I only want to look at what's changed between them
 * awilkins pulls the latest version of bzr-pipline
<dobey> guess it's a lp issue mostly
<lllama> Hello everyone. I've started making some changes to a program that I'd now like to work on as a branch. I've yet to commit the stuff I've changed, so was wondering what the best way would be to go about doing this.
<awilkins> lllama: Are you working in a free standing branch or a checkout?
<lllama> awilkins: checkout
<lllama> awilkins: but I can unbind if required.
<awilkins> lllama: If you unbind, you are now working in a branch - you might want to do `bzr nick project.fix-my-bug` or another sensible name before you commit.
<awilkins> lllama: I tend to work with a local no-trees repository containing all the related branches I'm working on, and use lightweight checkouts and `bzr switch` to move between them.
<awilkins> lllama: Other people make their parent folder a shared repository, and keep a "trunk" checkout for merging, and branch from that for work packages.
<lllama> awilkins: Interesting. I've got a remote no-trees repo, so I could look into something similar.
<lllama> awilkins: If I unbind though can I copy the dir (keeping the uncommited changes as a result) and then revert the existing branch to back them out?
<awilkins> You should be able to do that, yes
<awilkins> Or branch your existing folder to your new "trunk" branch
<awilkins> e.g. cd .. ; bzr branch work trunk ; cd work ; bzr commit -m "My Changes"
<awilkins> (presuming "work" is the existing folder with changes in it"
<lllama> I tried that but I don't get the uncommited changes in the new branch (natch). Just wondering whether there's a better procedure. I could do with a little rethink of my repo layout methinks. It's a little flat ATM..
<awilkins> lllama: You keep the old folder as your work branch, and the new one is your "trunk" branch
<awilkins> lllama: The not-getting-the-changes is intentional in this case :-)
<lllama> awilkins: of course. Thanks for the help. I'll look into 'switch' as well.
<awilkins> lllama: You're welcome
<ronny> lifeless, awilkins: btw, if bzr is basically inode based, shoudn't there be a rather simple way to expose commit building/tree changing as if it was a posix fs
<awilkins> ronny: Not sure about that, I think Subversion is sort of like that but I have the impression that the undergarments of Bazaar are rather different
<LarstiQ> jelmer: hmm? the context of that '^' was a bit scarce
<ronny> well, i'll gradually put complete in-memory filesystems on top of hg, bzr, svn and git based on the api"s of the fraft spec for the new filesystem apis
<ronny> *draft
<jelmer> LarstiQ, sorry
<jelmer> LarstiQ, somebody was asking about bzr-gtk in the PPA's
<jelmer> LarstiQ, are you doing those or johnf?
<LarstiQ> jelmer: I haven't been doing them
<LarstiQ> jelmer: it seems you and jam have, I can pick those up
<LarstiQ> jelmer: although I'm not really a user of bzr-gtk nowadays
<jam> LarstiQ: bzr-gtk hadn't done a release in long enough, that I don't think anyone was doing them :)
<franck_> hello there, does anybody know how to use the --nested options ???
<franck_> i can't find the option with 1.3 and 1.17 release (ubuntu jaunty)
 * LarstiQ heads out
<abentley> franck_: I think you're talking about features that are still in the planning phase.
<abentley> awilkins: I'm open to supporting parallel pipes, I just haven't really needed it.
<awilkins> abentley: I'm scratching my head ans starting at a pipe called "parallel" ATM :-
<awilkins> staring
<awilkins> I don't think the Mercurial lot are 100% decided on what to do either, it's clear that people want features like this but they've notarrived at the mbest way to do it yet.
<awilkins> I found a page where they compare 4 ways of doing it. And pbranch credits loom for inspiration!
<awilkins> http://mercurial.selenic.com/wiki/PatchHandlingUnificationRFC
<awilkins> I think the worst thing is that "get_(next|prev)_pipe" becomes a bit awkward instantly
<awilkins> They just resort to moving around on names only
<franck_> abentley: ok it's that i've seen with more search on mailing list, by the way do you know a good method in order to merge already versionned branches within a new versioned project, i need that cause i got some libraries wich are managed via bzr, but i can't add them only if i delete .bzr folder within module...
<awilkins> franck_: `bzr help join`  ?
<franck_> awilkins: many thanks i haven't seen that, i'm gonna try it !
<macinjosh> I'm new bazaar can i ask a question?
<macinjosh> I've read a lot of documentation and cannot find an answer
<macinjosh> I have a repository on a web server with a checkout that are the files actually being served as as a website, if another developer changes those files being served  is there a way to commit those changes?
<LarstiQ> macinjosh: `bzr commit`? I'm not sure what you're asking
<macinjosh> well i only have FTP access
<macinjosh> I do not have shell access to this server
<awilkins> macinjosh: you can commit via FTP but it's not the ultimate in effciency
<LarstiQ> macinjosh: preferably, imo, you would not edit at the website, but only deploy to it
<awilkins> macinjosh: And note that this does not necessarily change the working tree on the server to match your commit
<macinjosh> yeah I realize that, we're working with a web designer who doesn't use or want to user version control :-(
<macinjosh> I've tried this: bzr commit ftp://josh@mywebserver.com
<macinjosh> and i get this error bzr: ERROR: Path(s) are not versioned: "ftp:/josh@mywebserver.com"
<awilkins> macinjosh: Does the tree correspond to the root of the FTP home on the server?
<macinjosh> yes the .bzr folder is at the root of the FTP home
<awilkins> macinjosh: Oh, hang on, you're trying to commit that file
<awilkins> macinjosh: You want to commit the changes to the folder, remotely, via FTP?
<awilkins> macinjosh: Which OS are you using as your client?
<macinjosh> yes, but not changes to the .bzr folder if thats what you are thinking. The changes would be in versioned folders like public_html
<macinjosh> im on mac os x, the server runs redhat
<macinjosh> these are the files/directories in the FTP home .bzr .bzrignore public_html views www models
<macinjosh> changes will be made in public_html views www and models
<LarstiQ> macinjosh: can you ssh into the server, and run bzr there?
<LarstiQ> macinjosh: the checkout needs to be updated anyway
<macinjosh> in need to commit those from my machine into the repository in .bzr
<macinjosh> no i don't have shell access (its a shared server)
<awilkins> macinjosh: The only other way to do it I can think of is ... i) run a smart server on the server ii) mount the folder into your local filesystem
<macinjosh> ok, thanks
<macinjosh> you've been helpful. bye
<reggie> hey bzr devs
<reggie> i just branched 4 svn branches into bzr and uploaded them to lp.  now I need to inform bzr that they are fully merged
<reggie> is null-merge the only way to do that?
<jelmer> reggie, full merged in what sense?
<jelmer> reggie, and what do you mean by null-merge?
<reggie> well, since svn doesn't support true merging, in the sense that newer branches have the changes I want them to have from older branches
<reggie> null merge meaning do the merge and then revert the changes
<reggie> and since the merge from one branch to another will likely find all sorts of conflicts and I'm going to revert them anyway, I can just tell bzr to merge it "any way it can" right?
 * LarstiQ blinks
<beuno> poolie, let me know when you're around
<LarstiQ> reggie: if the branches share ancestry, then merge will know about merged changes, and not bork on lines already being added
<lifeless> moin
<agrippa> any idea when https://bugs.launchpad.net/bzr/+bug/98836 will be fixed?
<ubottu> Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed]
<lifeless> agrippa: likely after 2.0; it is very important to us to fix
<lifeless> but the core devs have a full plate already
<agrippa> lifeless:  When will 2.0 be?
<lifeless> very soon :)
<agrippa> lifeless: Can't use bzr on any of our Windows shares, and all we have are Windows file servers :(
<lifeless> agrippa: :(
<lifeless> agrippa: bzr only uses OSLocks on the working tree copy
<agrippa> lifeless: And git is good and all, but our designers here will not like it
<agrippa> lifeless: And I like bzr's compatibility with opendiff
<agrippa> and comparing revisions is easy since I don't have to type in a stupid hash
<lifeless> agrippa: you should be able to use bzr by using either checkouts from a central branch, or local branches on each machine
<agrippa> lifeless: Well, I've had no such luck on this version on OS X 10.5.7
<agrippa> lifeless: bzr co, bzr status, bzr init, bzr branch won't work
<lifeless> agrippa: is the location you're checking out to on the server, or on the local disk?
<agrippa> agrippa: local disk
<lifeless> agrippa: then its not bug 98836 :)
<ubottu> Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] https://launchpad.net/bugs/98836
<agrippa> lifeless:  Hmm, could be something else?  I found a similar bug that was marked a duplicate of 98836 that matched my issue
<agrippa> lifeless: I am also getting the Errno 45
<lifeless> which dup were you looking at?
<agrippa> lifeless:  This is the one I originally found: https://bugs.launchpad.net/bzr/+bug/31006
<ubottu> Launchpad bug 31006 in bzr "dirstate file locking doesn't work on smb mount on osx - bzr add, bzr status, and bzr commit fail over a SMB share (dup-of: 98836)" [High,Confirmed]
<ubottu> Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed]
<lifeless> so, that is on an smb mount
<lifeless> but you just said you were checking out onto local disk
<agrippa> Yeah
<agrippa> Well, onto local disk, from an smb mount
<lifeless> does the source have a working tree itself?
<lifeless> (If you just created it by doing bzr init, or bzr branch, then it probably does)
<agrippa> I believe so, I originally created a repo from a Windows machine with bzr init and then tried checking out from OS X
<lifeless> o
<lifeless> ok
<agrippa> then I added all the files in there and committed
<lifeless> so, here's whats happening
<lifeless> [I think]
<lifeless> a backtrace would help diagnose to be sure.
<lifeless> I think bzr is trying to read lock the source tree, to read its files from disk
<reggie> thanks everyone who responded.  I got my merge all fixed up
<lifeless> this isn't particularly helpful in your case
<agrippa> How do I do a backtrace?
<lifeless> so, if you don't need the working copy on that central branch, running (from the machine that created it), 'bzr remove-tree', will get rid of the source tree and files, and then bzr won't try to lock it
<lifeless> run with -Derror
<lifeless> kfogel: bug 405595 - you might like to weigh in with your opinion
<ubottu> Launchpad bug 405595 in bzr "bzr-svn on Windows does not support Subversion 1.6 format" [Undecided,New] https://launchpad.net/bugs/405595
<agrippa> lifeless: Do you want me to run that on the repo located on the Samba share?
<lifeless> agrippa: yes
<agrippa> Alright
<kfogel> lifeless: I have no strong opinion; either solution seems fine for now, though eventually the auto-upgrade seems like the right thing to do.
<agrippa> lifeless: Want me to paste the output into here?
<lifeless> agrippa: sure, or a pastebin
<agrippa> http://pastebin.com/m718a691f
<lifeless> agrippa: you need to run this from a machine that is working :)
<lifeless> agrippa: or are none of them working?
<agrippa> Oh, I can do that too
<beuno> lifeless, re: bug 405972
<ubottu> Launchpad bug 405972 in bzr "Pushing a new stacked branch to the Launchpad project does 18 VFS calls" [Undecided,New] https://launchpad.net/bugs/405972
<lifeless> beuno: yes
<beuno> I see 2 VFS calls for branches with tags
<beuno> not 18
<beuno> which is why I filed that bug
<lifeless> beuno: yes, and no
<lifeless> beuno: do to any vfs calls takes about 16 calls in setup
<beuno> :)
<lifeless> its why doing any vfs based operations is so expensive
<lifeless> we have to read .bzr/branch-format, .bzr/branch/format, .bzr/repository/format, .bzr/branch/branch.conf, .bzr/repository/pack-names, etc etc
<beuno> I see
<beuno> why do I only see 1 or 2 VFS calls sometimes then?
<lifeless> beuno: if you enable the back-trace-on-vfs stuff, which we had enabled previous
<lifeless> you'd see that the backtrace for the earlier vfs calls comes from tags.set_tags_dict, or something like tat
<beuno> lifeless, sure, what knob do I have to twirl to do that?
<lifeless> beuno: -Dhpssvfs
<lifeless> or set that in your config
<beuno> thanks
<beuno> I already have hpss
<lifeless> it was on by default, but folk felt it was too noisy
<beuno> I'll add vfs
<beuno> let's try this again then with that enabled
<lifeless> this will produce a backtrace at the point vfs access is triggered
<beuno> yeah, I remember those
<beuno> they sure where noisy, but if it helps pin point the issues and someone is working on it, it's good noise  :)
<beuno> hrm, with hpssvfs, it doesn't give me the counts
<beuno> lifeless, http://paste.ubuntu.com/235454/
<beuno> it does seem to go through tags
<agrippa> don't know if I got anything useful for you lifeless
<lifeless> agrippa: well if the command worked, your mac checkout should work now
<agrippa> http://pastebin.com/m6d29d96d
<lifeless> agrippa: try checking out on your mac machine again now
<lifeless> beuno: thus, its tags :)
<agrippa> with branch or co?
<lifeless> agrippa: either
<lifeless> beuno: hpssvfs and hpss are separate flags; they don't imply each other
<agrippa> lifeless: Wow, that worked.
<lifeless> agrippa: you just need to make sure your branches on the mount don't have trees, and it should keep working
<beuno> ah
<beuno> thanks lifeless
<beuno> do you know when spiv's branch is landing?
<lifeless> yes, but it doesn't matter
<lifeless> the right question is 'when will launchpad be running with spiv's branch'
<agrippa> lifeless: So is this a bug or just the way bzr works?
<lifeless> agrippa: needing OS Locks is a design defect we'll be fixing. Using them at the moment is situation-normal.
<lifeless> agrippa: we made the [wrong] assumption that OS locks were in fact a reasonable and reliable tool to use.
<agrippa> lifeless: So in the future, it should be possible to have trees on the mount?
<lifeless> agrippa: yes, once we fix the bug about OS Locks
<agrippa> lifeless: Thanks a bunch, man.  I think I might be able to get my coworkers to start with Bazaar soon enough then.  I'm tired of flashFile1000000.flah
<poolie> beuno, hi, i'm here now
<beuno> poolie, hi
<lifeless> agrippa: cool. Please do drop in with any more questions, there is usually someone around.
<beuno> poolie, want to talk about the website today?
<poolie> yes, very much
<poolie> i was hoping to catch kiko first...
<beuno> poolie, sure, I'm on the hpone now anyway
<lifeless> the hpone eh
<poolie> like an iphone but better
<poolie> lifeless/spiv, are these "%d byte part read" things really necessary?
<poolie> they use a lot of space...
<lifeless> poolie: turn off -Dhpss :P
<lifeless> (yes, I think they are. We want to gather detailed data when people are gathering data)
<awilkins> lifeless: Are OS locks going to be removed for 1.18 ?
<awilkins> lifeless: Or 2.0 ?
<lifeless> awilkins: no
<lifeless> probably no
<poolie> awilkins: only if you send a patch :)
<awilkins> Waah
<awilkins> Shelve just doesn't work on Windows until you kill them off
<poolie> lifeless: making things so verbose that people turn them off is missing the point
<poolie> my question really is, what kind of thing do they help you debug?
<awilkins> Which means no pipeline or anything else that needs shelf to work
<poolie> john had some kind of patch towards addressing that particular problem
<poolie> i think it was hard to refactor transform(?) to fix it
<awilkins> poolie: Yes, last commit to the lp mirror of that was in February AFAIR
<poolie> therefore he stopped
<lifeless> poolie: the command line output is very minimal
<poolie> i think that is an improvement to the code but it's arguably better to change the locking model to avoid the whole thing
<poolie> the .bzr.log output is definitely not
<lifeless> poolie: how many people are really looking in .bzr.log all the time?
<awilkins> OS locks have never been a good idea, they are just to inconsistent
<awilkins> I remember maintaining code that used semaphores specifically for that reason
<lifeless> poolie: I want to be able to say to someone who files *any* bug based on the command line output of -Dhpss: 'please attach the log from that run', and get enough detail to identify and fix it
<awilkins> Anyway, sleepytime
<poolie> awilkins: that's great, i thought the same thing, but...
<poolie> lifeless: right therefore my question about what kind of bug that helps with
<lifeless> poolie: I don't think I saw that question
<awilkins> Maybe I'll look at it on the train tomorrow (not that it'll do much good :-) )
<poolie> 08:00 poolie: my question really is, what kind of thing do they help you debug?
<poolie> lifeless: ^^
<lifeless> poolie: They have helped in the past find interactions between buffer layers
<lifeless> like the TCP ack/psh issue
<poolie> by, say, showing that it starts reading tiny little buffers?
<lifeless> yes
<lifeless> do we need them every time? no
<lifeless> unfortunately, I can't say when we will need them in advance :(. It may be that spiv who has done much more networking over the last few months will say 'I haven't looked at these for ages, we can dump them'
<poolie> k thanks
<lifeless> however, in terms of bug round trips, I really prefer a single large debug hammer to repeated incrementally larger requests
<lifeless> if what you really want is to know when bzr does lots of round trips, perhaps we could give you [and other folk that want a feel] a dedicated ui-only reporting flag
<lifeless> -Dnosy :P
<poolie> possibly for bug reports we want -Deverything
<lifeless> (which could show a range of different summary numbers)
<poolie> oh i see we do already have -Dhpssdetail
<poolie> i thought we might
#bzr 2009-07-29
<thumper> can I set remote locations in locations.conf?
<thumper> like Launchpad?
<lifeless> yes
<mwhudson> hm
<mwhudson> does anyone have a nice rsync recipe for copying all the .bzr directories and contents out of a directory tree, but not the working trees?
<lifeless> not offhand
<lifeless> -i **/.bzr or something, I guess
<mwhudson> ah, i'd missed the top down application of rules
<lifeless> \o/ :!./bzr --no-plugins selftest intertree.test_compare.*test_specific -x '\(C\)'
<lifeless> passing
<lifeless> poolie: spiv: review requested please
<lifeless> my dirstate infrstructure change will be blocking a later review in about 2 hours. Maybe less
<SamB> what is the preferred way to assert that something is either an iterable or None?
<poolie> SamB in a test?
<poolie> SamB i guess i'd first ask, is that really what you want to test?
<poolie> don't you know which one it should be?
<poolie> but, if you did want that then i guess i'd do
<poolie> if result != None:
<poolie> l = list(result)
<SamB> poolie: not in a test
<SamB> in a method
<poolie> then either assert something about l or just add a comment that the cast will fail
<lifeless> poolie: 'result is not None'
<SamB> actually, now I'm not sure what type this argument is supposed to be
<poolie> oh noes
<poolie> SamB: in general we don't make assertions about arguments
<poolie> unless either the api changed or it's error prone
<poolie> and in the second case it's better to change it
<SamB> poolie: change it to what?
<poolie> so just go ahead and use it in the way it should be used
<poolie> if thing is not none:
<poolie>   return ', '.join(thing)
<SamB> I just want to make sure that all the callers are passing things with a compatible interface ...
<poolie> for instance, by change the api, i mean that apis that take either a string or list of strings are  a really bad idea, because strings look so much like lists
<lifeless> SamB: we don't do that in bzr, as a stylistic choice.
<SamB> igc: what is the file_iter argument to CommitCommand.__init__ *supposed* to be?
<SamB> poolie: well, some of the tests here are passing callables that return iterables, and some of them are passing iterators
<SamB> right now I'm not sure which tests are right, but wouldn't it be best to check in the constructor that the arguments are remotely like we want them to be?
<poolie> igc is away this week
<SamB> oh :-(
<poolie> sick
<poolie> SamB: this might just be the python generator pattern here?
<poolie> you can often treat those things as the same
<poolie> (kind of vague description)
<spiv> i.e., iterators are iterables.
<SamB> well, the most key difference is that some of the tests pass *callables* returning iterables, but some just pass iterables
<lifeless> SamB: whats CommitCommand?
<SamB> it's in bp.fastimport.commands
<lifeless> oh
<lifeless> so, no idea.
<lifeless> what we generally do is;
<lifeless>  - ensure the docstring is clear
<SamB> yeah
<lifeless>  - let the caller do what they want
<SamB> and I guess
<SamB>  - make sure the tests are consistant with the docstring
 * SamB wishes fast-import had a --dry-run mode where it did *everything* except actually create the branches ...
<poolie> Samb, nice idea
<poolie> spiv, there is a 1.17 branch, https://launchpad.net/bzr/1.17
<poolie> afaics you should be able to target bugs to it
<lifeless> spiv: ping
<poolie> note that the control is hugely mislabelled as 'target to release'
<poolie> and there's a bug for that
<lifeless> SamB: we don't generally need the last one :) if the tests are inconsistent with the docstring, so is the code, or the tests are failing.
<poolie> well, quibble
<poolie> they don't always have precisely the same information content
<spiv> poolie: Ah ok.  I don't fully understand the difference between setting a milestone on a bugtask and targetting to a release.
<lifeless> spiv: hi you promisedish me a review yesterday.
<poolie> launchpad has succeeded then :)
<lifeless> spiv: targetting is a new bugtask
<poolie> with its cunning strategy of labelling one as the other
<lifeless> spiv: there is a link 'nominate for ...'
<SamB> lifeless: yeah ... maybe
<SamB> depends how often those attributes get used, possibly ...
<spiv> Especially when targetting to a release then offers me a list of series, not releases, to choose from...
<poolie> Bug #132733 in Launchpad Bugs: âConfusing use of the term "Target to release" on bug pages.â <https://bugs.edge.launchpad.net/malone/+bug/132733>
<ubottu> Launchpad bug 132733 in malone "Confusing use of the term "Target to release" on bug pages." [Medium,Triaged]
<ubottu> Launchpad bug 132733 in malone "Confusing use of the term "Target to release" on bug pages." [Medium,Triaged] https://launchpad.net/bugs/132733
<poolie> that was odd
<SamB> lifeless: anyway, I figured out that using "bzr fast-import" definately results in callables being passed ...
<spiv> poolie: possibly because you gave the bug # and the url?
<poolie> i guess so, though it's odd the first one didn't include the url
<poolie> oh maybe that's for the one that did have the url
<SamB> must be!
<lifeless> spiv: ping [review] - I'll keep pinging till I get ack or nack
<psynaptic> so I have 2 files which I have modified which I don't want to have anything to do with what I'm doing
<psynaptic> (uncommitted changes)
<RenatoSilva> lifeless: quick suggestion about setup versioning. Instead of bzr-setup-1.17-1.exe, bzr-1.17-setup-1.exe
<psynaptic> in git I would just not stage those files
<psynaptic> how do I get around this in bzr
<bob2> psynaptic: bzr commit takes a list of files to commit
<bob2> psynaptic: or ytou can shelve the changes
<lifeless> RenatoSilva: good idea! please put in a bug
<lifeless> psynaptic: bzr commit -x foo -x bar, I think
<psynaptic> bob2: I already committed what I wanted
<psynaptic> by cding to the dir and bzr commit . -m "message"
<bob2> psynaptic: so what do you want to have happen?
<psynaptic> but now it won't let me push or pull
<bob2> shelve them
<lifeless> psynaptic: push --no-strict
<lifeless> psynaptic: the --no-strict thing is recent, and we don't like it. we're going to make it warn rather than error
<bob2> what's the rationale for strict push?
<psynaptic> I see.. my version of bzr seems old
<psynaptic> no such option
<lifeless> psynaptic: ok, what actually error are you getting then?
<lifeless> psynaptic: we're really trying to guess at the moment
<psynaptic> ok..
<SamB> bob2: it's clearly not a good enough rationale ;-)
<psynaptic> bzr push bzr+ssh://user@example.com/home/cnpopen/public_html/dev
<psynaptic> This transport does not update the working tree of: bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/. See 'bzr help working-trees' for more information.
<psynaptic> bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".
<psynaptic> so I tried $ bzr pull
<psynaptic> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<psynaptic> so I tried $ bzr merge
<psynaptic> bzr: ERROR: Working tree "/private/var/www/subdomains/cnp/" has uncommitted changes.
<lifeless> psynaptic: someone else (or you from another macine) has pushed to that branch
<lifeless> psynaptic: do this:
<lifeless> bzr shelve --all
<lifeless> bzr merge bzr+ssh://user@example.com/home/cnpopen/public_html/dev
<lifeless> bzr commit
<lifeless> bzr push
<lifeless> bzr unshelve
<lifeless> if this is a shared branch between multiple developers, you may wish to work with a checkout, which won't let you commit if someone else has pushed stuff up
<psynaptic> bzr: ERROR: Working tree "/private/var/www/subdomains/cnp/" has uncommitted changes.
<psynaptic> Macbook-Pro: /var/www/subdomains/cnp> bzr diff
<psynaptic> === modified file 'sites/default/default.settings.php' (properties changed: +x to -x)
<lifeless> psynaptic: the shelve didn't remove the change? Interesting (and a bug)
<psynaptic> well
<psynaptic> it removed 2 other files
<psynaptic> with content changes
<psynaptic> but not the property change
<psynaptic> Macbook-Pro: /var/www/subdomains/cnp> bzr diff
<psynaptic> === modified file 'sites/default/default.settings.php' (properties changed: +x to -x)
<psynaptic> Macbook-Pro: /var/www/subdomains/cnp> bzr shelve --all
<psynaptic> No changes to shelve.
<psynaptic> I'll change it to +x
<psynaptic> save the hassle :)
<lifeless> I'll file a bug on shelve now for you
<psynaptic> thanks a lot
<lifeless> are you on MacOSX/linux/win32?
<psynaptic> mac os x
<lifeless> sent in
<lifeless> sorry about that; its disconcerting to suggest a recipe that fails
 * lifeless pings spiv again
<lifeless> spiv: hai
<SamB> where should constructor arguments be documented -- in the class' docstring, or __init__'s?
<lifeless> I prefer __init__
<lifeless> some folk use the class
<SamB> any good examples?
<psynaptic> lifeless: no, thanks a lot for your help
<lifeless> I like to put instance and class attributes in the class docstring, and constructor params in the __init__
<lifeless> SamB: not offhand
<psynaptic> so this bzr commit after the merge
<psynaptic> seems to only contain the merge changes
<psynaptic> should I add a merge commit message
<psynaptic> then bzr add my stuff and commit/push again
<lifeless> yes, something like 'Sync with dev'
<psynaptic> thanks
<spiv> lifeless: hi
<spiv> lifeless: I'll look at it in about 15 minutes.
<lifeless> spiv: thanks!
<spiv> lifeless: thanks for the nags :)
<psynaptic> lifeless++
<lifeless> spiv: I've finished all the python changes in the patch on top of it
<lifeless> spiv: so I'm porting to pyrex, updating docs, and submitting
<psynaptic> hmm, very odd
<psynaptic> now I can't see my changes
<psynaptic> I asked another dev to pull and it just says nothing to pull
<psynaptic> there files are there in my working copy!
<psynaptic> *the
<psynaptic> bzr diff only shows the files that were unstashed
<psynaptic> *unshelved
<RenatoSilva> lifeless: bug 406099
<ubottu> Launchpad bug 406099 in bzr "Better file name for bzr windows installer" [Undecided,New] https://launchpad.net/bugs/406099
<psynaptic> what am I doing wrong! lol
<bob2> bzr missing remotebranch
<psynaptic> I think I did something stupid earlier
<psynaptic> bzr push origin
<psynaptic> bzr branch origin
<psynaptic> randomly did those 2
<psynaptic> :/
<psynaptic> I don't even know the branch I'm supposed to be working on
<psynaptic> in git you can view your available branches using $ git branch
<lifeless> RenatoSilva: thanks
<psynaptic> in bzr the command seems to do something differnent
<lifeless> psynaptic: it makes a new branch
<lifeless> psynaptic: 'bzr branches' will list branches
<lifeless> or you can just look on your filesystem
<psynaptic> Macbook-Pro: /var/www/subdomains/cnp> bzr branches
<psynaptic> origin
<psynaptic> not sure I was supposed to have origin
<lifeless> spiv: you may, if you're clever find bugs in the thing I've asked you to review; I won't land it independently as I'm fixing them now :)
<psynaptic> but does that mean I had zero branches?
<spiv> lifeless: hah
<lifeless> spiv: its worth getting your feedback on the conceptual change and how its presented, regardless
<bob2> psynaptic: branches are directories
<psynaptic> oh ok
<lifeless> psynaptic: it means you had no other branches under your current branch
<lifeless> psynaptic: you can give a url to push - bzr push <URL>
<psynaptic> so I can just delete /origin in the filesystem,?
<lifeless> psynaptic: ./origin, yes
<psynaptic> thanks
<psynaptic> I'm a bit confused because bzr diff is not showing anything but the changes I don't want to push
 * RenatoSilva gtg
<psynaptic> I added the dir with the files I wanted to commit and committed them
<psynaptic> but this was before this merge
<psynaptic> maybe I have committed changes
<psynaptic> that I haven't pushed
<psynaptic> right ok
<psynaptic> bzr log shows the history
<bob2> bzr missing remotebranch
<bob2> ^ changesets that aren't in both
<psynaptic> what is remotebranch though?
<psynaptic> Macbook-Pro: /var/www/subdomains/cnp> bzr missing remotebranch
<psynaptic> bzr: ERROR: Not a branch: "/private/var/www/subdomains/cnp/remotebranch/".
<psynaptic> I don't know what remotebranch is
<bob2> whatever branch you think is missing things
<psynaptic> I don't know ANY branches
<psynaptic> maybe HEAD?
<psynaptic> master
<bob2> this isn't git
<psynaptic> something like that?
<lifeless> psynaptic: bzr missing bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/
<psynaptic> ahh
<lifeless> psynaptic: thats where you pushed to before
<lifeless> its therefor a branch
<psynaptic> riiight
<psynaptic> You have 2 extra revision(s):
<lifeless> bzr push bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/
<lifeless> if you want to save that as the default this branch pushes to do
<lifeless> bzr push bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/ --remember
<psynaptic> This transport does not update the working tree of: bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/. See 'bzr help working-trees' for more information.
<psynaptic> Pushed up to revision 53.
<psynaptic> thanks for the tip
<psynaptic> bzr update then?
<psynaptic> why am I at a different revision to the repo?
<psynaptic> a fellow developer says he is at rev 56 and I am at 53
<psynaptic> Macbook-Pro: /var/www/subdomains/cnp> bzr update
<psynaptic> Tree is up to date at revision 53.
<lifeless> psynaptic: 'update' is only useful if you are using a checkout
<psynaptic> right
<lifeless> you are using a separate branch, so update just checks locally and has nothing much to do
<psynaptic> so do you think this method I'm using is inefficient?
<lifeless> as for your fellow, they have some different stuff in their branch
<psynaptic> I was given instruction on how to use their bzr repo
<lifeless> bzr missing will tell them whether they have additional things, or are missing what you pushed
<lifeless> branches and checkouts work very similarly
<psynaptic> why can't we push to the same branch?
<lifeless> you can, but you'll end up changing commit  orders a lot
<psynaptic> right
<lifeless> checkouts automate that for you
 * psynaptic pasted http://pastie.textmate.org/private/makewfs23qan1jwpxwuu0a
<psynaptic> this is what we were told to do
<psynaptic> there are 5 devs
<poolie> spiv, i filed bug 406113
<ubottu> Launchpad bug 406113 in bzr "need checks or tests that compiled extensions are loaded properly" [High,Confirmed] https://launchpad.net/bugs/406113
<psynaptic> all working in their own environment
<poolie> did you catch jam at all?
<lifeless> psynaptic: for that situation I'd be inclined to use two branches
<psynaptic> how would that work?
<lifeless> one sec
<lifeless> http://paste.ubuntu.com/235578/
<psynaptic> lifeless: ahh I see
<psynaptic> thanks for taking the time to do that for us
<psynaptic> looks like a good idea
<psynaptic> I have added it to our project wiki so hopefully we can start using it
<psynaptic> so what does "This transport does not update the working tree of: bzr+ssh://cnpopen@openlyconnected.com/home/cnpopen/public_html/dev/. See 'bzr help working-trees' for more information." actually mean?
<psynaptic> is it important?
<bob2> working tree = checked out files
<psynaptic> are my changes actually in the central repo?
<psynaptic> yeah, I get that bit
<bob2> push will update the branch data, but it won't update the checked out files
<psynaptic> ok, so in this case it will update the central server but not my own working copy
<bob2> "push will update the branch data, but it won't update the checked out files" [on the remote server]
<bob2> push has nothing to do with updating your local working copy
<psynaptic> that's what I thought was the working copy
<psynaptic> but you have a working copy on the server too, yes
<psynaptic> right
<psynaptic> I'm still no closer to understanding
<lifeless> spiv: actually, the bug is in a local change anyway; that branch should be independently golden
<psynaptic> it's probably just too late for me today
<psynaptic> 3.35am
<psynaptic> not a great time to be trying to work out somewhat abstract ideas
<bob2> so, your "branch" is really three things: a working copy (the checked out files), the repository (all the revision data) and the branch (a pointer to a series revisions in the repository).  they're each in a separate dir in .bzr
<psynaptic> ok
<poolie> lifeless/spiv: quick yeah/nay sought on bug 406113 - specifically, whining about missing extensions unless BZR_PURE_PYTHON=1
<ubottu> Launchpad bug 406113 in bzr "need checks or tests that compiled extensions are loaded properly" [High,Confirmed] https://launchpad.net/bugs/406113
<bob2> push updates the remote branch and repository, but not the working copy.  "update" updates the working copy
<psynaptic> right
<lifeless> poolie: I don't think we should whine
<psynaptic> so how do I see that my changes where pushed into the remote repo?
<poolie> or erorr
<psynaptic> so I can happily go to bed
<bob2> bzr missing urltoremotebranch
<lifeless> poolie: I think we should make bzr --version, or similar, make it clear if there are any missing extensions, and get build scripts to grep the output
<poolie> that would be another option
<poolie> not very obvious though
<psynaptic> Branches are up to date.
<bob2> excellent!
<poolie> could also go in backtraces, though lack of them is unlikely to cause tracebacks
<bob2> ah, also, "bzr log urltoremotebranch"
<lifeless> poolie: for debs etc it doesn't matter how obvious it is, as we should be checking it and failing the build anyway
<poolie> lifeless: but, anyhow - why not?
<lifeless> poolie: its only for people that grab a tarball or branch bzr themselves that the obviousness matters
<poolie> or for cases where there's a hole in the previous process
<lifeless> and we already make setup.py die if the extensions don't build
<lifeless> poolie: which is why I'm suggesting we patch the previous process usin the same logic as whining would
<psynaptic> thanks bob2
<lifeless> as for why not, well I don't like programs that whine at me
<lifeless> it gives a bad impression
<lifeless> and I don't think our users will like it either
<poolie> you think most people who don't have extensions loading have made an informed decision not to have them?
<psynaptic> if I do bzr commit and I have added files, modified and unknown.. will only added get committed?
<poolie> or at least would agree with it if asked?
<lifeless> poolie: most people with the power to fix it, yes.
<psynaptic> or should I back out and shelve
<lifeless> psynaptic: added and modified will be committed
<psynaptic> thanks
<lifeless> psynaptic: if you run 'bzr commit',it will list the things being committed in the editor window
<psynaptic> I did that :)
<poolie> hm, i don't think so
<psynaptic> but it doesn't make a distinction in that output
<poolie> why would they want that?
<psynaptic> I know now tho
<psynaptic> thanks
<lifeless> psynaptic: everything it lists will be committed ;)
<lifeless> psynaptic: except for unknowns
<lifeless> poolie: e-thread-lost
<poolie> i think running without compiled extensions should be very opt-in
<poolie> more so than at present
<psynaptic> thanks lifeless and bob2, I can get some sleep now!
<lifeless> poolie: so, I'd like to discuss this, but not now.
<thumper> lifeless: how to I tell pqm-submit that I don't have a local copy of a branch?
<psynaptic> c u :D
<lifeless> thumper: I don't know; pqm-submit --help may.
<poolie> i'll try it, if it works propose a merge, and we can handle it there
<thumper> damn
<thumper> I don't think I can
<lifeless> poolie: What I think is that the people *doing builds* should do the QA
<thumper> which kinda sucks
<lifeless> poolie: not everyone executing bzr
<thumper> I'm trying to submit jml's branch for him
<poolie> thumper: either branch it yourself
<poolie> or make up a submit message by hand
<poolie> use --dry-run to see a template
<thumper> huh, good point
<lifeless> thumper: bzr pqm-submit LOCATION
<lifeless> thumper: did you try LOCATIOn?
<thumper> yes
<poolie> also please do merges inside launchpad, thanks :)
<thumper> poolie: :)
<lifeless> poolie: do you mean landing target stuff? lp can
<thumper> it is on my mega plan
<lifeless> just need a queue hooked in for pqm
<thumper> lifeless: we don't have queues in LP yet
<thumper> lifeless: well, not exposed anyway
<lifeless> thumper: how does tarmac work then? :P
<thumper> lifeless: it just grabs all approved ones
<JoaoJoao> hello
<lifeless> thumper: thats a queue, effectively.
<thumper> lifeless: it isn't an ordered queue
<thumper> grr!
<lifeless> though personally, I would really want a button to say 'ok land this now', separate from approval to dosol
<JoaoJoao> Is there any way to shelve changes to binary files?
<lifeless> JoaoJoao: bzr shelve --all, should do so
<lifeless> poolie: anyhow, I'm worried that bzr whinging will not prevent bad debs, and will annoy a very large number of users very quickly
<poolie> ... because there's a large number of user who're using the slow python implementations and like it that way?
<JoaoJoao> lifeless: does it also work with bzrtool's shelve? (shelve1 on windows)
<lifeless> JoaoJoao: no
<JoaoJoao> :(
<lifeless> poolie: no, because *when a bad deb is made* a lot of users get flipped from C to python in one hit.
<JoaoJoao> no go to me then
<lifeless> JoaoJoao: sorry :(
<lifeless> JoaoJoao: you could commit the file, uncommit and revert it
<lifeless> and then use merge -r revid:xxxx, to restore it later
<poolie> yeah, if we add this we'd presumably want to check it in the deb build process
<lifeless> poolie: and thats my point, if we check it in the deb, I don't think we need to be obvious at runtime for users.
<lifeless> we already check in setup.py
<JoaoJoao> lifeless: that would work, but too much of a hassle to me... thanks for the tip anyway
<lifeless> its just that the setup.py check doesn't check that the things built are used afterwards
<lifeless> (there is a bug about builds on karmic, they put the .so's in bzrlib/bzrlib/*.so
<lifeless> which setup.py should arguably catch as well
<thumper> just for a laugh: bzr branch lp:hg-git :-)
 * SamB hopes the LP devs remembered to use bignum for bug numbers rather than fixnum ;-)
<meaton2veggies> Hey all, I'm after a bzr pkg (v1.17.1) for Ubuntu Jaunty powerpc (arch)? Can't use Karmic as want to install Launchpad
<mwhudson> meaton2veggies: it's probably easy enough to build from source using the source package bits in the ppa?
<meaton2veggies> mwhudson: ok great, is there any doco for building bzr from src
<mwhudson> meaton2veggies: it's just 'debuild' isn't it?
<lifeless> debget <<.....dsc>>
<lifeless> then dpkg-buildpackage
<lifeless> or debuild
<meaton2veggies> lifeless: thanks
<lifeless> spiv: I'm landing that branch w/o the fixes- they are in my next patch anyhoo, ok ?
<lifeless> I'm down to three failures on the pyx code
<spiv> lifeless: sure
<lifeless> 2 failures
<lifeless> \o/
<lifeless> guess what
<poolie> way to go robot
<lifeless> I'm integrating/improving the docs now
<lifeless> then its up for review, and qa to see if it improves commit :)
<meaton2veggies> lifeless: installed deps for building, however error on install of packages trying to do 'make DEST=blah install'
<meaton2veggies> lifeless: should this be changed to something in debian/rules?
<lifeless> meaton2veggies: hmm?
<meaton2veggies> python setup.py?
<lifeless> meaton2veggies: dpkg-buildpackage
<lifeless> this will build a debfor you
<lifeless> then you can install the ppc deb
<lifeless> isn't that what you wanted?
<meaton2veggies> yes
<meaton2veggies> but its failing on install part, compiles fine
<lifeless> pastebin?
<lifeless> spiv: now, if you want dirstate patches to review
<lifeless> 112K of bundle on its way to lp now
<meaton2veggies> http://pastebin.com/d3905e25a
<lifeless> meaton2veggies: thats odd; are you using the source package from launchpad?
<meaton2veggies> lifeless: yes from launchpad
<meaton2veggies> theres no install target in the Makefile i think, that correct?
<lifeless> thats correct
<lifeless> so the debian/rules file you have is broken or something
<meaton2veggies> yeah
<lifeless> which is confusing, as to have a binary buld it has to have been correct when we uploaded it
<lifeless> what url did you use to get the source from?
<meaton2veggies> the debian/rules were created locally
<lifeless> meaton2veggies: don't do that
<meaton2veggies> the source didnt come with debian/
<lifeless> use debget and get the whole source package from the ppa
<meaton2veggies> i did do that im sure
<lifeless> if you did that you would have gotten a debian dir
<meaton2veggies> ok
<meaton2veggies> using this package https://launchpad.net/~bzr/+archive/ppa]
<meaton2veggies> using this package https://launchpad.net/~bzr/+archive/ppa
<lifeless> yes
<meaton2veggies> lifeless: u use debget with the *.dsc file?
<lifeless> thats my recollection
<meaton2veggies> i'm not getting anything for some reason
<lifeless> yes, ddsc
<lifeless> I'll test
<lifeless> oh
<lifeless> debget is apparently toast
<lifeless> an easier way
<meaton2veggies> ok
<lifeless> add the https://launchpad.net/~bzr/+archive/ppa to your sources.list, as per the web page
<lifeless> apt-get source bzr
<lifeless> then do
<meaton2veggies> yeah im not gettin source for 1.17 though for some wierd reason
<meaton2veggies> its giving me 1.13 from ubuntu repos
<lifeless> have you added the ppa?
<meaton2veggies> wait correction
<lifeless> done apt-get update?
<meaton2veggies> its fine
<meaton2veggies> YAY!
<lifeless> :)
<meaton2veggies> lifeless: cool, bzr (powerpc) deb created and installed thanks for assistance
<lifeless> my pleasure
<lifeless> EODing
<lifeless> poolie: ping
<chrispitzer> i'm having problems with bzr upload.  when I try to upload a repo, i get bzr: ERROR: Invalid url supplied to transport: "README.txt"
<chrispitzer> what's up - is this a permissions issue or something...?
<lifeless> what url are you giving bzr upload to push to?
<chrispitzer> bzr upload bzr+ssh://my.server.com/srv/foo
<poolie> lifeless: pong
<chrispitzer> it should be using the user 'chris' just like when i ssh in.
<poolie> this sounds familiar
<poolie> is there a backtrace in .bzr.log?
<chrispitzer> when i ssh in I can make files in that folder easily
<lifeless> poolie: I'm done with the most recent arc, modulo review feedback and excludes (which we can defer a little, I think)
<chrispitzer> there is no .bzr.log
<poolie> ~/.bzr.log
<poolie> nice one
<lifeless> poolie: Unless you have specific requests, I'm just going to be popping 2.0 things off the milestone
<lifeless> poolie: as I start before you, you have until I wake up to leave something here giving a specific request ;P
 * lifeless is gone but can be rung
<poolie> sounds good to me :)
<poolie> lifeless: bombs away re 6m cycle rfc
<chrispitzer> http://dpaste.com/72786/
<poolie> chrispitzer: so it looks like a bug or an incompatibility between bzr and the upload plugin
<poolie> i assume you do actually want the tree contents uploaded?
<poolie> i mean, that you want a full checkout on the server
<chrispitzer> yea
<chrispitzer> it works great for a bunch of sites I use it on... bzr upload that is.
<chrispitzer> it just doesn't want to work this time.
<chrispitzer> *shrug* time to get on with my life I guess. :P
<chrispitzer> thanks anyway - later
<mdke_> hi all. Is there an easy way to merge a git branch into a bzr one? I tried using a simple "bzr merge" command but no luck
<poolie> mdke_: what happened?
<poolie> you probably need to specify the revision range
<poolie> and obviously you need the bzr-git plugin
<lifeless> if the bzr branch wasn't made from git, you can't trivially merge
<mdke_> poolie: it said that it wasn't a branch
<mdke_> lifeless: ah, damn
<mdke_> lifeless: I'm working on an Ubuntu branch which was imported from the upstream svn project (gnome), but now that gnome has moved to git, I need to figure out some way of merging in the changes
<mdke_> short of using the "cp" command...
<mdke_> lifeless: I suppose the solution is to use Launchpad's import service to import the upstream project into bzr and then merge from that
<mdke_> poolie: is the bzr-git plugin available in Ubuntu, do you know?
<mdke_> I couldn't see it
<mdke_> brb
<lifeless> mdke_:  you need to essentially recreate your history on top of the git import
<lifeless> we should make a tool to do this for you
<lifeless> but you can approximate it with bzr fast-export and then fast-import on top of a bzr-git import
<lifeless> lp does bzr-git imports
<mdke_> lifeless: ok, so I'll wait for the Launchpad import to take place, and then try those two commands. So I'm basically going to have to scrap the Ubuntu branch and make another one, right?
<AfC> Is bzr-git built into bzr-1.17?
<AfC> (my distro hasn't posted a new package yet, so I can't see for myself)
<lifeless> AfC: no
<lifeless> mdke_: sadly yes
<mdke_> lifeless: that's ok, we'll blame gnome for switching
<lifeless> mdke_: you'll need to provide -r parameters to the export :P
<mdke_> ok
<lifeless> oh AfC hi
<lifeless> I want to make a little progress bar
<AfC> lifeless: hello Robert
<lifeless> sitting on the right hand side of my screen, at the bottom
<lifeless> is there a precanned gtk thing for this?
<mdke_> thanks for the help lifeless, gtg now
<lifeless> I knowof the ProgressBar widget, I mean the rest
<AfC> lifeless: I'm sure you want to make "a little progress". The rest of us are also hoping you'll make "a little progress".
<lifeless> feh
<AfC> lifeless: by "at the bottom" do you mean "on the panel" or "always on top (ie, small docked [sic] window)" or...
<lifeless> its the output from test runs
 * AfC presumes that if lifeless meant on the panel, he would have said "applet" in there somewhere.
<lifeless> so I want something reasonably unobtrusive
<AfC> yeah
<lifeless> I guess having a window that shows on the task list, with the content on the task list being a progress bar would be lovely.
<AfC> lifeless: that's gonna be hard
<fullermd> What do you want more than a little window with geometry -0-0 or some such?
<lifeless> AfC: yeah, I'm not shooting for that today. Just completing a TUIT I've had for a while for subunit.
<AfC> lifeless: [as an aside, it's a shame that applets are such an insanely convoluted API, since applets are what most of us want in these cases]
<lifeless> I can pipe subunit through subunit2pyunit --progress, to get bzr progress bars
<lifeless> but thats nowhere near as bling
<AfC> lifeless: well, there's the "shell bindings", ie `zenity`
<AfC> so if you're already thinking in terms of pipes that might do the trick
<AfC> let me russle up an example for oyu
<lifeless> zenity progress bars?
 * lifeless looks around in alarm
<AfC> zenity anything, really
<lifeless> wheee
<lifeless> http://library.gnome.org/users/zenity/stable/zenity-progress-options.html.en
<lifeless> its scary
<MT-> What does an error like this mean? No handlers could be found for logger "bzr"
<lifeless> MT-: commonly it means that your ~/.bzr.log is readonly
<MT-> Is 770 ok, or does other need read permissions?
<AfC> lifeless: so, try
<AfC> $ zenity --progress --title "bzr test" --auto-close --percentage 80 --text "Current module: format stabiltiy"
<lifeless> AfC: yeah, thing is I need a subunit converter on it anway; that makes me inclined to just do the whole thing in python
<AfC> as I recall, you feed stdout 0-100 and #blah
<lifeless> cleaner for the user than typing
<AfC> lifeless: in that cast, yes, just use pygtk
<lifeless> <setup stream>  | subunit2zenity | zenity ...
<lifeless> AfC: yah
<lifeless> I'm going to crib from http://www.andrew.cmu.edu/user/skey/research_prev/checker/working%20now/gui/pygtk2tutorial/pygtk2tutorial/sec-ProgressBars.html I think
<MT-> lifeless: I added o+rx to everything...
<AfC> lifeless: dunno. I'm not a Python guy :)
<lifeless> MT-: your ~/.bzr.log needs to be _writable_:)
<MT-> lifeless: that is
<lifeless> MT-: try stracing bzr
<MT-> um..
<lifeless> MT-: or file a bug
<lifeless> I'm actually not really here right now
<AfC> lifeless: [but you might want to ask if there's anything newer. The screenshot there looks OOOOOOLD]
<MT-> I screwed up somewhere..
<AfC> always a give away
<MT-> I doubt it's a bug
<MT-> lifeless: does that file need to exist on the setver?
<lifeless> MT-: the path to it does
<lifeless> bzr will create the file in the directory if it doesn't exist, and needs to be able to do so to do log rotation
<AfC> lifeless: a slightly better idea might be notification area icon + a docked window with the progress bar in it
<AfC> (ie, click icon, see progress bar)
<lifeless> AfC: how hard is it to do rendered icons?
<AfC> lifeless: you mean ... what do you mean?
<MT-> lifeless: so, the .bzr.log you're referring to - is that my system or the server?
<AfC> lifeless: you mean how hard is it to design icons
<AfC> lifeless: or,
<AfC> lifeless: how hard it is to change icons through a series to visually represent progress?
<lifeless> AfC: I mean, to create the icon on the fly using code to create the pixmap/svg/whateverthebackendneeds
<MT-> has to be server...
<AfC> lifeless: (gnome-power-manager's battery indicator being a good example of that, although last I saw Ubuntu they heavily fuck with the theme & icon set there, so as usual all bets off for people who don't use upstream)
<lifeless> all of the code I've seen so far wants icons paths on disk, I think.
<AfC> lifeless: ah
<AfC> lifeless: not too hard, actually.
<AfC> lifeless: Cairo is good at that sort of thing
<lifeless> so, I don't want to make 100 icons all 1% further complete
<AfC> yeah
<lifeless> or, better
<AfC> disk? Hm.
 * AfC looks
<lifeless> a complete mix of fractions for pass/not run/error/fail
<lifeless> actually, -> gnome-hackers I think
<AfC> we've got StatusBar's setFromPixbuf(), so worst case you can draw the image to a Pixbuf and then feed that to that method
<AfC> [there is an IPC barrier in the way, so it's not like you're going to be able to talk to an XlibSurface / GdkPixmap directly]
<MT-> lifeless: any packages not installed that could cause that?
<lifeless> AfC: yeah, I don't care about htat :P
<lifeless> MT-: if the error only shows when you do something with your server, then its probably permissions on the server.
<MT-> lifeless: if I set 777 on them, it still shows up :S
<lifeless> MT-: then its something else.
<MT-> When I create the repo, everything is michael:bzr
<lifeless> MT-: Like I said, I'm not really here right now. Your best bet is to file a bug, so that we can gather some data and help you solve the problem.
<lifeless> We'll likely also find why bzr is giving an opaque output to you and fix that so its easier for other people.
<MT-> hm - bzr:bzr did the same
<MT-> lifeless: any reason 770 wouldn't be good enough?
<lifeless> please file a bug
<lifeless> I'm having dinner and stuff like that
<lifeless> I can't help you at the moment, for all that I can feel your pain.
<MT-> well... I verified it's not permissions
<MT-> it's something with the system
<MT-> I'll file a bug later on it
<MT-> If I can't figure it out
<MT-> anybody else have any other ideas?
<MT-> Sleep time - If anybody does know though, please hilight - I installed bzr on the server using aptitude install bzr and let it install its deps. Then I setup permissions and did bzr push bzr+ssh://x.x.60.226/bazaar/branches/test. It seems to work, but I get the error No handlers could be found for logger "bzr"
<lifeless> MT-: as I said, _please_ file a bug
<lifeless> its the best way to help us help you
<MT-> lifeless: ok, I'll do that tomorrow - it's too late to make sense when I detail it
<MT-> lifeless: thanks
<sabdfl1> hi folks
<Kinnison> hihi mark.
<Kinnison> como esta?
<sabdfl> Kinnison! long time no speak
<sabdfl> well thank you, and you?
<sabdfl> is there work afoot to make explicit commit (bzr commit a b c) follow the new codepath for bzr 2.0?
<Kinnison> sabdfl: getting on, getting on.
<Kinnison> sabdfl: gearing up for the final production run on http://www.entropykey.co.uk/
<Kinnison> sabdfl: Lots of interest here at debconf for it.
<sabdfl> i hear debconf has been fun
<Kinnison> It has been good. Lots of "interesting" announcements, especially the release team's announcement about trying to sync up debian releases with Ubuntu LTS releases
<fullermd> sabdfl: I think lifeless posted a patch for it earlier.
<sabdfl> thanks fullermd
<sabdfl> Kinnison: how was that received?
<Kinnison> sabdfl: mixed. At the conf itself, reasonably well. On -project and -release, marginally more whinging.
<Kinnison> sabdfl: I'm not yet convinced we won't see an attempted GR to reverse the decision
<sabdfl> anything can happen in Debian
<Kinnison> Aye.
<Kinnison> So, congrats on the Launchpad/AGPL release
<sabdfl> thanks much
<LarstiQ> sabdfl: I admit to not knowing what you mean by that codepath, but coupled with fullermd's remark http://www.advogato.org/person/robertc/diary.html?start=104 seems to fit
<jelmer> LarstiQ, dude!
<LarstiQ> jelmer: I see you're not plaintexting over untrusted networks anymore ;)
<jelmer> LarstiQ, I'm not sure how I can be signed in, I don't recall sending my password..
<fullermd> Don't worry, I sent it for you   8-}
<fullets_> Is this an appropriate channel for bzr-svn questions?
<jelmer> fullets_, yeah
<jelmer> fullermd, (-:
<fullets_> I pushed a commit to a Subversion repo using bzr, and it was the first commit to that repo via bzr. The bzr:base-revision property of the commit was set to the commit preceding its immediate ancestor though
<fullets_> So my commit via bzr is revision 15993, it thinks its ancestor is 15991, and new bzr branches of that repo omit completely 15992
<fullets_> Is there an easy way to fix this?
<jelmer> fullets_, what sort of operation happened in svn ?
<fullets_> From subversion's point of view it's all just a bunch of commits
<jelmer> fullets_: does "svn log <branch-url>" include that particular commit?
<fullets_> Yes
<jelmer> Not on the repository URL but on the branch URL?
<fullets_> Oh, one sec
<fullets_> Sorry, what do you mean by branch URL?
<jelmer> The URL to the branch in the Subversion repository
<jelmer> e.g. if the repository is at svn://svn.gnome.org/svn/gnome-specimen then perhaps the branch is located at svn://svn.gnome.org/svn/gnome-specimen/trunk
<fullets_> Ah, then yes, it shows up via svn log http://stuff/trunk
<jelmer> hmm, odd
<jelmer> bzr-svn should be warning when the order of the commits in svn doesn't match the bzr metadata
<jelmer> do you get any warnings during a clone?
<fullets_> No. There have been warning during pulls into an existing bzr branch about tags moving round, which I shut up with --overwrite, but the problem is still present in a fresh clone in a fresh repo
<jelmer> fullets_, So, the easiest way to cope with this problem would be to simply remove that property
<jelmer> I would be interested to know though how you ended up with that property
<fullets_> A-ha, but it's a versioned property on the branch root - is there a better way to do that than svnadmin dump -> hack hack hack -> svnadmin load into a fresh svn repository?
<fullets_> Oh, wait, no
<jelmer> it would be a revision property
<fullets_> I deleted *all* the non-versioned revision properties, including bzr;base-revision, from subversion
<jelmer> bzr-svn doesn't set base revision information in file properties
<jelmer> fullets_, did you also remove the bzr-svn cache?
<fullets_> A-ha!
<fullets_> I was thinking of the bzr:see-revprops property
<fullets_> That lives under ~/.bazaar somewhere, no?
<LarstiQ> fullets_: ~/.cache/bzr/svn or ~/.bazaar/svn-cache (legacy)
<fullets_> Thank you
<LarstiQ> SamB: you asked about Ubuntu packaging branches, right? https://code.edge.launchpad.net/ubuntu
<aquarius> when trying to check out a branch, I get this error: bzr: ERROR: KnitPackRepository('file:///home/aquarius/canonical/ubunet/.bzr/repository/') is not compatible with RemoteRepository(bzr+ssh://bazaar.launchpad.net/~ken-vandine/ubuntu/karmic/desktopcouch/karmic/.bzr/) different rich-root support
<aquarius> what do I have to do to upgrade my local repository?
<LarstiQ> aquarius: upgrading your local repository is one option, or you could branch --standalone to tell it to not use your repository
<LarstiQ> aquarius: bzr info will tell you what formats are for each branch
<Chocobo> Hi all.  I am setting up my first vcs and I am considering bzr.   The only problem I am having so far is how to handle users...  I will be following mostly the centralized layout and when users push I want them to be able to use a unique username/password.   sftp seems like it will not fit the bill for this application.
<LarstiQ> Chocobo: why not?
<LarstiQ> with sftp or bzr+ssh://, the straightforward setup is to have everyone use their own username/password
<Chocobo> Hrmmm...  would each user just be part of a group for the bzr repo?   I am trying to figure out permissions, where to out the repo, etc.
<LarstiQ> Chocobo: yes
<LarstiQ> Chocobo: and I highly recommend making use of posix acls
<Chocobo> Do you know of any documentation that describes setting up bzr this way?
<LarstiQ> Chocobo: I'd check the user guide
<Chocobo> ohhh I see, so I would do something like "setfacl -m user:USERNAME:rwx bzr-repo"
<aquarius> LarstiQ, if I upgrade my local repository will it upgrade all the branches that are in it?
<LarstiQ> aquarius: all branches will have their revision storage upgraded (by definition).
<LarstiQ> aquarius: can you tell me what format `bzr info` thinks the desktopcouch branch is?
<aquarius> LarstiQ, cool; I'll do that, then. How do I upgrade my repository?
<aquarius> bzr info bzr+ssh://bazaar.launchpad.net/~ken-vandine/ubuntu/karmic/desktopcouch/karmic/ -> Standalone branch (format: unnamed)
<LarstiQ> Chocobo: I'd go for group:bzr:rwx and default:group:bzr:rwx
<LarstiQ> Chocobo: but yes, that's basically it, since standard Unix permissions are a bit fidgetty in this regard, but posix acls solve it properly
<LarstiQ> oh feh
<Chocobo> Ok, thanks.  I have never used acl so I will have to look into it some more.  Basically I need to make sure that files added have the appropriate permissions.
<LarstiQ> aquarius: do note that since in this case there is rich-root discrepancy, if you have branches that need to interact with other non rich-root branches this will then shift the problem
<LarstiQ> Chocobo: yes
<LarstiQ> aquarius: do you only have desktopcouch branches in that repository?
<aquarius> LarstiQ, no, I have loads of branches of loads of things
<LarstiQ> aquarius: then I would not recommend upgrading all of that to a rich root format just yet, the pain with the distinction will soon be something of the past with 2a
<LarstiQ> aquarius: so, my recommendation is to either branch it standalone, or use a seperate repository for it
<aquarius> LarstiQ, ok, cheers
<SamB> LarstiQ: I don't think I would be able to find anything on that page ;-P
<SamB> LarstiQ: also, what is this "password" thing of which you speak?
<LarstiQ> SamB: where?
<LarstiQ> SamB: to Chocobo? ssh
<Chocobo> hrmm?
<SamB> LarstiQ: do you want me to be quiet, or are you talking about secure shell?
<LarstiQ> SamB: I still am not sure what you were referring to, but we discussed secure shell accces to a centralized server, yes
<SamB> LarstiQ: I'm being facetious, actually ;-)
<SamB> pretending I forgot that SSH supports password-based authentication
<LarstiQ> SamB: ah, I didn't catch on to that :p
<Mez> what does
<Mez> bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "chroot-139854732:///home/sites/"')
<Mez> mean?
<Mez> (I'm trying to branch from another server in our local network)
<Mez> bzr branch bzr+ssh://root@webutils/home/sites/
<jelmer> Mez: The error should be formatted better, but it usually means the server on the remote site was unable to find a repository related to the branch it has opened.
<jelmer> if you log in as root@webutils and run "bzr log /home/sites", does that work?
<Mez> how would that happen? I can branch locally
<Mez> bzr: ERROR: No repository present: "file:///home/sites/"
<Mez> root@webutils:/home/sites# bzr log | head -n 2
<Mez> ------------------------------------------------------------
<Mez> revno: 513
<Mez> works though
<LarstiQ> Mez: `bzr info` says the repository is where?
<Mez>          shared repository: /home/webteam/bzr
<Chocobo> WOW!  ACL's are awesome.
<Mez> ah, ok, I see.
 * LarstiQ blinks
<LarstiQ> Chocobo: they are! :)
<Mez>  /home/sites is a symlink
<Chocobo> that default: thing is crazy cool.  :)
 * LarstiQ nods at Chocobo 
<LarstiQ> Mez: aha.
<Mez> Thats better, 10000kB/s rather than 18
<awilkins> Can ConfigObj return lists of values?
 * awilkins RTFS
<bialix> hi guys, anybody has copy of monotone's document about daggy fixes? their wiki is down during last several weeks and I can't find the way how to get it from google cahce
<awilkins> bialix: I think the gist of it is "find the revision that introduced the bug and branch from there to fix it", but you probably knew that
<awilkins> bialix: Frustratingly, many of the wiki pages are in the google cache but I couldn't coax this one out
<bialix> I knew the gist, I'm interesting in document to show to other people
<bialix> me too
<reggie_bzr_newbi> what does it mean when bzr 1.17 complains that a folder is not versioned but has versioned children?
<bialix> in one branch child file was changed, but in other branch folder+child were deleted
<reggie_bzr_newbi> bialix, that doesn't seem to be the case here.  I can't seem to find much in google about this.  is there a command to show me what bzr thinks is the status of my folders?
<bialix> bzr status
<bialix> bzr ls -v
<luks> bialix: maybe an older version, but http://web.archive.org/web/20071115025521/http://venge.net/mtn-wiki/DaggyFixes
<bialix> luks: many thanks, it's enough
<ronny> how do i get a tree for a specific revision?
<bialix> see revisiontree
<ronny> hmm
<ronny> its not exactly self explaining :(
<luks> repository.get_revision_tree(revision_id) or something like that
<luks> it's simple enough
<bialix> found mirror for mtn site: http://mtn-wiki.1erlei.de/wiki/DaggyFixes/
<kfogel> loggerhead 1.10 works fine with Bazaar 1.17, right?
<kfogel> (the 1.10 release is from so long ago, it seems like a good idea to ask)
<LarstiQ> kfogel: its require_any_api includes 1.17
<LarstiQ> kfogel: so it should, yes
<LarstiQ> oh wait
 * LarstiQ slaps self
<kfogel> ?
<LarstiQ> kfogel: ahem, that was the loggerhead copy for my bzr.dev
<kfogel> LarstiQ: I'm not sure I understand.  Do you have local mods?
<LarstiQ> no, but it is very likely not 1.10
 * LarstiQ downloads and checks 1.10
<LarstiQ> kfogel: which has required_bzrlib = (1, 6)
<kfogel> LarstiQ: does that translate to "1.6"?
<LarstiQ> kfogel: so 1.10 might complain with 1.17
<kfogel> meaning anything higher than 1.6 will work?
<LarstiQ> kfogel: I think so
<LarstiQ> beuno: time for a new loggerhead release?
<Tak> is the progress indicator with "Fetching revisions: Inserting stream" the revision-fetching progress, or the overall (branch) operation progress?
<Chocobo> hrm: No handlers could be found for logger "bzr"
<reggie_bzr_newbi> I need a bzr expert.  I have two repos that have the exact same directory structure but bzr apparently thinks that one of them has folders that are non-versioned
<ronny> LarstiQ: any idea where jelmer is?
<CardinalFang> reggie_bzr_newbi, hey hey.
<beuno> LarstiQ, ooooh yes
<beuno> I dream about it
<jfroy> bah
<jfroy> Just converted a large repository (used for bzr-svn) to 2a
<jfroy> Repacking it now, bzr is taking upward of 1 GB of memory
<jfroy> Seems to be an endemic problem with bzr -- several operates take incredible amounts of memory...
<jfroy> *operations
<maxb> Is there a convenient command to find the common ancestor revision between two branches?
<Tak> bzr merge --show-base?
<CardinalFang> maxb, The revision specifier can do that.  See "ancestor" under   $ bzr help revisionspec
<CardinalFang> reggie_bzr_newbi, Still have a problem?
<reggie_bzr_newbi> CardinalFang, yes.  this is really maddening
<CardinalFang> reggie_bzr_newbi, Ignoring the directory bit for a moment -- what is it you're trying to do?
<reggie_bzr_newbi> CardinalFang, I have two branches in a repo that I can't merge between.  do folders have to have the same id between branches?
<reggie_bzr_newbi> CardinalFang, we have a small svn repo that we are converting to bzr.  we just did a fresh bzr svn-import that finished without error
<reggie_bzr_newbi> branches and tags all look ok
<reggie_bzr_newbi> we did  a series of null merges so that bzr thinks that everything is merged up
<reggie_bzr_newbi> essentially cd verY; bzr merge ../verX; for each topleveldir bzr revert X; bzr revert .; bzr commit
<reggie_bzr_newbi> at that point, doing a bzr merge ..\verX in verY shows 'nothing to do'
<reggie_bzr_newbi> now we make a small change in verX and try to merge to verY.  it gives conflicts complaining about a directory not being versioned.  pretty sure I've found the problem but not surehow to fix
<reggie_bzr_newbi> doing a bzr ls --show-ids in the root of verX shows that one of my folders (the one that is causing the problem) has an id that is different than what it has under verY
<CardinalFang> reggie_bzr_newbi, That final  "bzr revert ." should revert all file contents and leave all metadata.  That's special.  "bzr revert $subdir" will undo changes, file contents and metadata, for files beneath that directory.
<CardinalFang> Is that what you intended?
<reggie_bzr_newbi> well, I had 3 files in the root that existed in verX but not verY
<reggie_bzr_newbi> so after the merge I had file.base and file.other
<reggie_bzr_newbi> I couldn't revert by filename, it just gave me an error
<reggie_bzr_newbi> bzr revert . removed them
<reggie_bzr_newbi> it was correct for them not to exist in verY, but I didn't bzr to understand that
<reggie_bzr_newbi> but I wanted bzr to understand that
<CardinalFang> reggie_bzr_newbi, I'm not sure what "bzr revert $dir" will do for a merge.  I'm trying to decide if it makes sense.
<CardinalFang> We take it to a private discussion.
<LarstiQ> ronny: jelmer is at Debconf
 * jelmer waves
<ronny> oh, sup
<ronny> jelmer: what are the future plasn for dulwich, stay protocols + data formats, or more
<jelmer> ronny, Basically fix bugs, improve performance
<ronny> i see
<jelmer> ronny, If git ends up implementing a new format (which seems unlikely at this point) dulwich will implement it as well
<ronny> jelmer: i'd like to be able to do in-memory-merges at some point for all vcs's
<ronny> so i want to see if they have things to offload the tricky bits
<jelmer> ronny: Ah
<jelmer> ronny: I'm not particularly interested in maintaining an implementation of merge in Dulwich, to me it is mainly about the formats and the protocols
<ronny> basic retarded commit building works
<ronny> jelmer: a rename finder might suffice to make my life easy thon
<ronny> (i kind of dont want to do that one)
<jelmer> ronny: I don't have any plans to do one, but there might just be somebody else who is interested in contributing one
<ronny> jelmer: dont you need one for bzr-git anyway?
<jelmer> ronny: A rename finder?
<ronny> jelmer: yes
<jelmer> ronny: Eventually we'll need a rename finder for bzr-git, but there already is one in bzr that we might be able to use there.
<jelmer> ronny, And it doesn't look like it will happen in the short term since tracking renames means changing the bzr-git mapping format and that will cause all revision ids to change.
<ronny> i see
<jelmer> ronny: I'm open to the idea of having one in Dulwich, it's just not really something I particularly care about myself.
<ronny> i'll take a look at implementing one later on
<ronny> hmm, i despiese the launchpad bugtracker, so many clicks, so long loading times
<kfogel> ronny: it does have a hugely redeeming feature, though: you can interact with it entirely by email.  That's a huge win.
<kfogel> ronny: not saying that long load times are a good thing, of course.
<ronny> kfogel: given todays email clients neither is nice
<kfogel> ronny: are you saying that today's email clients are worse than yesterday's, in certain ways?  (Couldn't quite tell.)
<ronny> kfogel: no
<ronny> kfogel: they are shit since ages
<kfogel> ronny: :-)
<ronny> this might be the fault of the email protocols
<ronny> i dont expect anyone that touched a imap implementation to be able to do reasonable userinterfaces
 * Tak blink
<abentley> salgado is reporting that he can reproducibly create a branch that is unpullable using "bzr branch" and "bzr push": "A request was made for key: ('sha1:f4bb3cbd77a7fa6ed7b4a9df79d4e3b69c0cc1c6',), but that content is not available"
<LarstiQ> ronny: I'm rather happy with mutt actually
<ronny> LarstiQ: never managed to warm myself up to that one
<LarstiQ> ronny: somehow it seems to mesh well with my vi mindset
<ronny> LarstiQ: not with mine tho
<ronny> LarstiQ: whats the usual amount of mail you manage, i got hundreds if megabytes of dozens of mailinglists
<LarstiQ> ronny: I switched my non-work mail around november of 2006, the Maildir since then is 730M
<ronny> LarstiQ: i see, sounds like a fit quantiy
<LarstiQ> but I've removed a lot of mailinglists from that I'm no longer subscribed to
<LarstiQ> like debian-devel, really can't keep up anymore
<LarstiQ> (and low on disk space, so..)
<ronny> i keep buying larger harddisks
 * LarstiQ wants to move to a new server but has some inertia there
<LarstiQ> ronny: work mail since the same period, 11051 entries, but that also has seen a bunch of deletions
<ronny> those are quite good amounts
<ronny> hmm
<LarstiQ> good as in not yet too much that clients croak?
<ronny> ops
<ronny> i just noticed i that anyvc doesnt deal with ignored files
<ronny> (in bzr)
<Savvas_P> want to ask something regarding "removed" files
<Savvas_P> lets say i remove some files from one branch and i "keep" them, when I push the changes to another branch , when the branch is updated the files are removed, how can I keep them on the other branches as well?
<LarstiQ> ronny: that should be easy to fix?
<ronny> LarstiQ: well, as soon as i have tests, and a generic working ignore command
<ronny> LarstiQ: so its more work, but a easy fix
<ronny> i"ll give vellum some love now
<LarstiQ> Savvas_P: you can't (got mentioned in https://bugs.launchpad.net/bugs/402196 but I don't think a specific feature request got filed)
<ubottu> Launchpad bug 402196 in bzr "remove --keep deletes files from disk in remote branches" [Wishlist,Triaged]
<LarstiQ> ronny: right.
<LarstiQ> ronny: vellum?
<ronny> LarstiQ: a task based build tool
 * LarstiQ looks it up
<LarstiQ> ronny: like (n)ant?
<LarstiQ> (or, not that I think of them that way, scons or waf)
<Savvas_P> LarstiQ: OK thanks
<ronny> LarstiQ: its not an inference machine
<ronny> LarstiQ: its supposed to automate things around a python style project
<abentley> lifeless: Salgado is reliably producing corrupt branches when he pushes to launchpad.  He was unable to reproduce it locally, even pushing stacked over the smart server.
<abentley> lifeless: He is using 1.18dev.
<LarstiQ> ronny: Zed Shaw is involved with pida?
<ronny> LarstiQ: nope, i just kind of started working on vellum and he stopped for now
<LarstiQ> k
<lifeless> abentley: hi
<lifeless> salgado: have you filed a bug?
<abentley> lifeless: Hi.
<lifeless> abentley: whats the nature of the corruption? ACF on pull/scan ?
<abentley> lifeless: https://pastebin.canonical.com/20552/
<salgado> lifeless, not yet
<abentley> lifeless: On my stale version of bzr.dev, it gave an ACF, but when I updated, I got the same error.
<lifeless> abentley: this is ACF still, jam added a method to raise
<lifeless> I'm not sure ValueError was the best exception to raise, but anyhow
<lifeless> it does the job
<abentley> The ACF is on branch.
<lifeless> this is missing a CHK page
<abentley> lifeless: I thought so.  It wasn't created using a bundle, though.
<abentley> lifeless: Or at least, salgado can reproduce it with push.
<lifeless> salgado: when did this start happening?
<salgado> lifeless, I first noticed it yesterday
<lifeless> salgado: does it happen to all branches, or just this specific one?
<salgado> lifeless, any branches on this project
<salgado> lifeless, other than (my own) trunk
<lifeless> are you working from a shared repo?
<salgado> yes
<lifeless> so, this suggests several bugs to me
<lifeless> the smart server isn't asking for enough follow up data
<lifeless> or the smart server is trying to read data it doesn't need
<lifeless> the former would be on push,the latter on pull
<lifeless> salgado: could you please file a bug
<lifeless> so we can start recordin the data we gather
<salgado> will do
<salgado> abentley, got the same error when branching from a branch pushed with bzr-1.17
<lifeless> one possibility is that you have managed to trip the trie size expansion in your branch
 * salgado tries branching with bzr-1.17
<lifeless> but that doesn't seem likely if *all* your branches that you push are bong
<salgado> right
<salgado> lifeless, when I branch from within my shared repo I don't get the error.  (not sure you've seen that in the discussion)
<salgado> actually, when I'm within the shared repo and branch from lp.net, I don't get the error
<lifeless> is the bug filed?
<salgado> filing now
<salgado> lifeless, https://bugs.edge.launchpad.net/bzr/+bug/406597
<ubottu> Launchpad bug 406597 in bzr "ACF when trying to branch from any of my canonical-identity-provider branches" [Undecided,New]
<lifeless> is this a new project?
<lifeless> cd /tmp/
<lifeless> salgado: ok, so I've got a handle on it.
<lifeless> data that is referenced isn't being copied
<lifeless> if you just 'bzr push /tmp/new', does that work?
<salgado> lifeless, yes, it works and I can later branch from there
<salgado> same thing when using bzr+ssh
<lifeless> how about this
<lifeless> bzr branch lp:<trunk> /tmp/trunk
<lifeless> bzr push --stacked-on /tmp/trunk /tmp/mine
<salgado> the initial branch is going to take a while, but we'll see
<salgado-afk> lifeless, the push succeeded and I'm now branching (bzr branch mine/ mine2), which is working fine -- it'd have failed already if the problem existed
<lifeless> salgado-afk: ok
<lifeless> salgado-afk: now, please try with bzr 1.17
<lifeless> it should be fast as the trunk is reusable
<salgado-afk> lifeless, redoing just the push with 1.17?
<jam> lifeless: so in your iter-changes-partial-parents patch, what part of that is "already present in a branch that will be merged" ?
<jam> ah, the set_tags_bytes stuff?
<salgado-afk> lifeless, worked as well
<lifeless> jam: the change to the signature of _process_entry, which has now landed so hopefully isn't visible in the diff
<jam> lifeless, salgado-afk: This is the missing chk page issue?
<lifeless> jam: yes
<lifeless> salgado-afk: redo the push --stacked-on, yes
<lifeless> salgado-afk: using bzr 1.17 for the push and then branching from it and so on
<jam> lifeless: unfortunately: +            result, changed = self._process_entry(entry, self.root_dir_info)
<jam> is, indeed, present in the diff
<jam> I'll create my own, I guess
<lifeless> salgado-afk: lp is running bzr 1.17, so if its a 1.17 bug we'll need to use 1.17 to trigger it
<salgado-afk> lifeless, right; I did the push with 1.17 and was later able to branch from the pushed branch
<lifeless> salgado-afk: branching from it using 1.17 ?
<lifeless> and [obviously] branching into /tmp as well, because we want the failure case
<salgado-afk> lifeless, both 1.17 and 1.18, but I'm not waiting until it finishes because the error happens early on
<lifeless> salgado-afk: erm, the backtrace shows that it happens during tree building, which is nearly the very end of it
<salgado-afk> lifeless, it takes exactly 20s for the error to happen when I branch lp:~salgado/canonical-identity-provider/test4
<salgado-afk> (just timed it)
<lifeless> salgado-afk: outside your shared repo?
<salgado-afk> yes
<lifeless> thats nuts
<lifeless> jam: so, were you ok with the test progress patch?
<jam> lifeless: truth be told, I think it makes figuring out the test suite one step harder to understand
<jam> And I don't quite understand when you know to use SEEK_SET vs SEEK_CUR
<lifeless> so, the concept is being built in subunit
<lifeless> I'll be taking it to testing-in-python once its a tad more mature
<jam> At least, when I saw it originally
<jam> I would have thought you would be doing SEEK_CUR, but you have SEEK_SET
<lifeless> generator tests (that we don't have) would use SEEK_CUR
<jam> ah, I see now, you are still calling countTestCases
<jam> you just do it in a decorator
<lifeless> right, I move from using it as part of the contract, to it being used by the public contract
<jam> I guess I'm just really confused by the layering
<jam> As in, I barely have an idea what is going on
<jam> level of confused
<lifeless> wow ok
<lifeless> uhm
<jam> you're wrapping this with that
<jam> at a random time
<jam> and expecting it to have all the values
<jam> or not
<lifeless> so, we have some main steps
<lifeless> we make a suite, something honouring run(result)
<lifeless> we pass that into TextTestRunner.run(suite)
<lifeless> which creates a result and does some UI stuff
<jam> k, following so far
<lifeless> currently, TTR.run calls countTestCases
<lifeless> which removes any opportunity for lazy evaluation
<lifeless> (and subunit doesn't support countTestCases at all)
<lifeless> so, layering wise, test cases should be responsible for knowing if they are lazy or know how many tests they have
<lifeless> this patch doesn't go all the way to achieve that. But it does change TTR so that it no longer assumes the test case its running does know
<jam> lifeless: but unittest.TestSuite *does* support countTestCases, right?
<lifeless> yes
<lifeless> its a design bug that that method exists at all
<jam> Why wouldn't a TestSuite know how many tests it has aggregated?
<jam> Given that you have a separate TestCase instance for each test
<jam> AFAIK
<lifeless> the method returns it transitively
<lifeless> countTestCases isn't len(self._tests)
<lifeless> its sum(test.countTestCases for test in self)
<lifeless> its a Composite pattern
<lifeless> the problem though, is that if one of the tests *doesn't* know
<jam> well, self._tests can contain a TestSuite as well, right?
<lifeless> (say its a generator test)
<lifeless> then you have to actually run that test to find out how many tests it has
<jam> given that we don't have generator tests...
<jam> nor does unittest support it, afaik
<lifeless> yes, but I'm not doing this for bzr I'm doing it so that I can reuse TTR outside bzr
<lifeless> unittest supports it fine
<lifeless> except for countTestCases
<lifeless> one example of a generator test is LazyLoadingTestSuite, which I posted to TIP a couple months back
<jam> so some of the confusion is just Unittest issues
<jam> like having a Runner.run(suite) which calls suite.run(result) etc
<lifeless> right
<jam> and then you are decorating run()
<jam> to do all sorts of random stuff
<jam> like call *back* into Runner.progress()
<lifeless> startTesetRun and stopTestRun go some way to allowing the deletion of Runner
<jam> or is that result.progress()
<jam> i guess it is result
<lifeless> Test.run calls into result.progress
<lifeless> the decorators run that is
<jam> right,which is actually the suite, but TestSuite conforms to the TestCase api?
<lifeless> yes
<lifeless> suites are tests are suites
<jam> well, *a* suite
<jam> well, to clarify, *a* suite is *a* test, as well as being a collection of tests.
<lifeless> externally its just *a* test; the fact it is composed of many children is hidden from the public API that TestRunner is allowed to use
<jam> so...
<jam> I think your patch adds complexity
<jam> if it is necessary, then so be it
<lifeless> so without it, TTR calls test.countTestCases, and subunit (because its just reading from a socket) can't answer that sensibly
<jam> but it certainly isn't something that I'd go "oh yeah, that is what I want"
<jam> lifeless: sure, but it could return 0, which is what we are doing now anyway
<jam> since you just aren't setting num_tests
<jam> which means it stays 0
<lifeless> nope, it gets set
<jam> or you could return a sentinel "-1"
<lifeless> this is what happens with the patch:
<lifeless> TTR.run(test)
<lifeless> result = result_class(num_tests=0)
<lifeless> test.run(result)
<lifeless> now, for bzr's normal runs, the next step is
<lvh> Hi!
<lifeless> (inside test), result.progress(self.countTestCases, SEEK_SET)
<lifeless> which sets result.num_tests
<lifeless> for subunit2pyunit --progress, the same thing happens, except rather than calling self.countTestCases, the subunit stream has a progress: item in it
<jam> so given that you are trying to show progress, it is a little bit icky to have the "num tests" keep getting bigger, as that means whatever progress indicator you have is invalid anyway.
<lifeless> jam: yes, and this is one of the main difficulties with doing progress of things with unknown length
<jam> and if the stream has "progress:" why couldn't it return that as part of countTestCases... because it hasn't read it yet at the time of "result=XXX" ?
<lifeless> right
<lifeless> also because cat stream1 stream2 | subunit2pynit --progress
<jam> lifeless: though that again doesn't have any valid meaning for progress info...
<jam> not to mention... does it have any meaning anyway?
<jam> catting a saved stream doesn't seem like it is actually running anything
<jam> and hence... who cares about its progress
<jam> or is that "cat FIFO1 FIFO2" ?
<lifeless> jam: so the point is to decouple things such that the result object doesn't know or care
<lifeless> saved streams are useful for timing analysis
<jam> lifeless: I can understand why one would save the output
<jam> I'm not sure why you would want --progress with saved output
<lifeless> jam: pragmatically, one is unlikely to do that
<jam> lifeless: anyway, it sounds like you solved a problem you're having, which isn't one I'm having. And it adds complexity, though not a tremendous amount.
<jam> personally
<lifeless> combining FIFO's is a very common case though, ec2test does that
<jam> just having subunit.countTestCases() == 0
<jam> seems like a perfectly reasonable alternative
<jam> lifeless: though again, combining FIFOs would mean that your info is a bit bogus
<jam> and you really should intermix them
<jam> rather than read one and then the next
<lifeless> right, we do
<jam> but you can use something fancier than 'cat' I'm sure
<lifeless> we get progress from both
<jam> so I certainly wouldn't block your patch
<lifeless> and transform them into CUR as you combine them
<jam> I'm not *happy* about it, but if you need it, do it.
<lifeless> ok; I wish I knew how to make you happy about it :)
<jam> well, I'm not "super happy that this has finally landed"
<jam> lifeless: I'm not *unhappy* either
<lifeless> ah good
<poolie> hello jam, hello all
<jam> hi poolie
<poolie> can i call you briefly?
#bzr 2009-07-30
<lifeless> salgado-afk: I'm trying to reproduce now
 * SamB wonders why poolie has to ASK jam if he can call him
<jam> SamB: because it is 1.5 hours past the end of my work day
<SamB> oh, right, work relationship ...
 * SamB isn't used to many people in an IRC channel working for the same company
<lifeless> more a work call
<shikibu> I am trying to do bzr init; bzr add in a quite small directory tree, and bzr seems determined to ignore one of my directories (formassembly/). Any idea why? http://pastebin.com/d5c84f4f1
<lifeless> many of us have relationships preceeding working at the same company, but if we're communicating about work respecting work/family balance is easy and important
<shikibu> poolie: ?
<shikibu> ^
<SamB> oh, and not terribly used to people having lives ;-P
<lifeless> shikibu: odd
<lifeless> shikibu: what does 'bzr add formassembly' do ?
<jam> lifeless: global ignores?
<lifeless> shikibu: also, perhaps a global ignore as jam says
<shikibu> lifeless: http://pastebin.com/d41406944
<poolie> shikibu: hi; i'm on the phone to jam
<lifeless> shikibu: cat ~/.bazaar/ignore
<jam> lifeless: formassebly is a bzr branch
<shikibu> not there
<jam> shikibu: bzr status formassembly?
<shikibu> http://pastebin.com/d515abbf0
<lifeless> oh
<lifeless> ls -a formassembly
<jam> lifeless: that is my guess, at least
<shikibu> lifeless: http://pastebin.com/d1c3ef6ca
<lifeless> jam: I'm betting svn
<shikibu> lifeless: http://pastebin.com/d7427da4a
<jam> shikibu, lifeless: could be anything but "bzr status formassembly" makes it clear it is a separate project
<jam> which is why we aren't adding it
<lifeless> jam wins
<jam> and I believe there is an open bug about it
<shikibu> ah, I see. thank you@
<lifeless> shikibu: you've bzr init'd the subdir formassembly already
<shikibu> thank you!
<shikibu> yes, i understand now
<lifeless> jam: python 2.4 doesn't have SEEK_SET/SEEK_CUR, I'll just define them locally if thats ok
<lifeless> jam: but I'll call them SUBUNIT_SET/SUBUNIT_CUR
<jam> lifeless: or COUNT_SET/COUNT_CUR, but sure
<poolie> lifeless: do they really have to be variables pointing to ints?
<lifeless> poolie: well, its an enum
 * spiv yawns
<poolie> lifeless: that mp was pretty damn timely :)
<poolie> it's the secret of good comedy you know :)
<lifeless> :)
<lifeless> spiv: ping
<lifeless> salgado-afk: still up?
<salgado-afk> lifeless, yes, but not for very long
<lifeless> have you tried with bzr 1.17 or 1.16 ?
<lifeless> do they also fail?
<salgado-afk> just bzr 1.17
<lifeless> and did it fail too?
<salgado-afk> I don't quite understand your question, but locally I can't reproduce the error, either with 1.17 or 1.18dev
<lifeless> I meanm have you tried to branch from lp with 1.17
<salgado-afk> not sure; let me try again
<salgado-afk> abentley did that, IIRC
<salgado-afk> AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'
<salgado-afk> that's what I get when branching from lp using 1.17
<lifeless> ok
<lifeless> does the backtrace look the same otherwise?
<salgado-afk> I think so, let me paste it
<salgado-afk> https://pastebin.canonical.com/20572/
<salgado-afk> lifeless, as I mentioned earlier, my temp branch on that project looks weird.  that was the first thing I pushed on that project, and it is a launchpad branch, IIRC
<salgado-afk> I pushed it from the DC so that I'd have something to stack on
<lifeless> its the same in 1.17
<lifeless> which is good
<lifeless> thanks
<lifeless> I hope to have something for you overnight
<salgado-afk> lifeless, great, just let me know if there's anything else I can help with
<spiv> salgado-afk: just checking, local and remote are both 2a in this case?
<lifeless> don't fix it :)
<lifeless> spiv: yes
<spiv> Ok, good.
<lifeless> I haven't checked if trunk's format is 2a
<spiv> lifeless: (bzr.dev currently fails to push between CHK repos with different serializers)
<lifeless> but it stacks ok, so I assume it is :P
<spiv> (at least in the presence of stacking)
<lifeless> spiv: https://bugs.edge.launchpad.net/bzr/+bug/406686
<lifeless> and
<ubottu> Launchpad bug 406686 in bzr "get_stream_for_missing_keys does not include inventory CHK pages." [Undecided,New]
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/406687
<ubottu> Launchpad bug 406687 in bzr "insert_stream doesn't check references are satisfied" [Undecided,New]
<lifeless> spiv: mayI call?
<spiv> lifeless: sure
<lifeless> spiv: nosmart+lp:~salgado/canonical-identity-provider/test4
<poolie> biab
<spiv> lifeless: curiously, your merge proposals (and only yours) display in mutt with ^M at the end of every line of the attachment.
<lifeless> \o/ evo
<lifeless> its probably being correct
<fullermd> spiv: ping
<spiv> fullermd: pong
<fullermd> spiv: Did you ever find anything on bug 389413?
<ubottu> Launchpad bug 389413 in bzr "ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked running diff across hpss" [High,Confirmed] https://launchpad.net/bugs/389413
<fullermd> I just had a coworker hit what looks like it with merge.
<spiv> fullermd: it's probably quite shallow, but I just haven't got it it.
<spiv> Presumably a lock isn't being held long enough.
<fullermd> 'k
<spiv> fullermd: if the traceback isn't obviously the same, feel free to add it to the bug, though.
<AfC> Is there a diffstat equivalent in Bazaar land?
<mwhudson> AfC: we still have diffstat ?
<lifeless> there is a diffstat plugin
<AfC> I'm not even sure if it means anything, but it seems the closest I've come across to an abstract quantification of the size of a delta
<lifeless> also bzr diff | diffstat :P
<AfC> lifeless: oh, it's a command? Sorry didn't know that.
 * AfC goes a hunting
<AfC> lifeless: so, what would a bzr diffstat plugin be doing that bzr diff | diffstat doesn't? Is that plugin something I should go find?
<lifeless> AfC: its easier for folk on windows
<AfC> {snort}
<AfC> ah
<AfC> right
<lifeless> it can also do things like hook into the commit template, I suppose
<ronny> does bzr have something like keywords that get expaneded to the current data
<fullermd> Sorta kinda.
<fullermd> Alternately, "Yes, with a plugin, but they mostly don't work, and where they do, they're inconvenient to enable."
<ronny> hmk, i'll just add some calls to the bzr version info thing then
<ronny> hmm, works fine
<ronny> whats the propper way to merge, if a file got created independ in 2 branches
<ronny> (it created a .bzrignore.moved file)
<bialix> merge old a new file by hands, select wich file history to stay, delete other file and resoove conflict
<ronny> ok
<sender> anyone an idea of a way to integrated bzr and mantis bugtracker? that bugtracker tab under settings, looks quite promising :)
<bialix> it depends on what you mean by "integrate"
<sender> bialix: tx, assign a bugnumber to a commit for example
<bialix> ah, this should be very easy
<bialix> can you show the typical URL to your bugs?
<sender> something from the mantis website itself, this is the url to view a certain bug: http://www.mantisbt.org/bugs/view.php?id=7721
<sender> bugnumber: 0007721
<bialix> so you can assign
<bialix> bugtracker_mantis_url = http://www.mantisbt.org/bugs/view.php?id={id}
<bialix> and then use
<bialix> bzr ci --fixes mantis:7721
<sender> great!
<bialix> qlog can show you bugs assigned to revisions
<bialix> hmm, it seems qlog does not support mantis yet
<bialix> I'll add such support
<sender> wow that's great
<sender> the abbreviation is configurable? "mantis:" could be "bug:" or "m:"?
<bialix> it should be the same you put in bugtracker_???_url name
<sender> nice. bzr, plugins and support keeps amazing me =)
<lifeless> jelmer: I'm doing a talk on subunit at slug tomorrow, ok to mention samba as a user?
<sender> bialix: after commit --fixes, I don't see any info on this show up in bzr log, is this correct? bzr qlog crashes (probably the same error that you saw - I guess I don't need to report it?)
<bialix> plain log does not show this info, yes
<bialix> try to update qbzr from trunk branch
<sender> Is there an other way to see that the bugfix is attached to the commit?
<sender> ok
<bialix> can you pastbin qlog error anyway?
<sender> http://pastebin.com/m57605735
<jelmer> lifeless: Hi
<bialix> sender: no it's different error maybe
<jelmer> lifeless: Yes, of course :-)
<bialix> sender: try to update your qbzr from trunk and say me if my change helps
<bialix> sender: but it smells like new bug
<bialix> sender: will be nice to file it as bug report
<lifeless> jelmer: whats the name of your C test library?
<jelmer> lifeless: libtorture
<sender> bialix: qlog from trunk looks perfect
<jelmer> lifeless, it's not really usable standalone though, and quite specific to samba at the moment
<lifeless> yeah, I know
<bialix> sender: file a bug please, mention that qlog crashes when bug_url is unknown
<sender> no errormessage and a nice red bar to show bug id, great =)
<sender> ok i will, can i retrigger? just remove bugtracker setting?
<bialix> no, you have to comment line 59 in qbzr/lib/logmodel.py
<bialix> this one: r'|bugs/view.php\?id='      # Mantis bug tracker URL
<sender> bialix: if I remove the mantis url from settings, the new qlog still works. commit --fixes refuses. Seems like "qlog crashes when bug_url is unknown" is not the actual bug?
<bialix> no
<bialix> sender: you have to comment line 59 in qbzr/lib/logmodel.py
<bialix> this one: r'|bugs/view.php\?id=' # Mantis bug tracker URL
<bialix> qlog does not use bugtracker_XXX_url settings at all
<bialix> qlog using internal regexp to parse final bug url
<bialix> this is what I mean by bug_url is unknown
<bialix> unknown to qlog regexp
<bialix> sender ?
<sender> yes bialix
<bialix> sender: can you test with commented regexp?
<sender> yes, def, jst a sec
<bialix> ok
<sender> bialix: no crash, just no "bug tag"
<bialix> hm
<bialix> oh
<bialix> I know
<bialix> recently Gary fixed bug around this feature
<fullermd> Darn those people sneakily fixing bugs!
<sender> :)
<bialix> fullermd: it was actually different bug!
<fullermd> If you fix a bug accidentally while fixing another bug, is the bug fix a bug?
<sender> ghehe
<bialix> err, no
<bialix> Gary fixed bug with not very clear symptoms, and in fact he has fixed 2 bugs
<fullermd> I think it is.  Luckily, it's easy to fix; you just say "Oh, yeah, I meant to do that".
<bialix> or maybe this new bug symptom makes those symptomps more clear
<bialix> anyway!
<bialix> ta-da!
<bialix> and everything worked!
<bialix> :-0
<sender> great, btw I installed mantis on localhost, and the url for bugs is: http://localhost/view.php?id=1 so without '/bugs/', it seems that mantisbt.org is the exception
<konnertz> hi. Pls how to find out the central repository of a checkout?
<sender> konnertz: try bzr info
<sender> bialix: should: "http://bazaar-vcs.org/3rdPartyTools#Integrated Bug Trackers" be updated with LP, Bugzilla, Redmine, Sharepoint, Fogbugz, Roundup and Mantis?
<konnertz> ok sender thx
<sender> bialix: I see I can edit the page, can I add those?
 * bialix back
<bialix> sender: um?
<bialix> sender: about localhost: ok, so my regexp is wrong
<sender> bialix: but still i got the bug tag in qlog
<bialix> sender: about 3rdPartyTools: I don't think qlog support does count there
<bialix> sender: I don't understand you, it won't work once you setup different url
<sender> bialix: ok will test again
<bialix> sender: on commit bzr store exact URL as part of revision metadata
<bialix> you can see it in qlog revision details window (bottom left)
<sender> ok without the correct regexp I don't see the red tags, but the urls are in (revision details window)
<sender> changing the regexp to r'|view.php\?id=' makes those visible
<sender> btw it's possible to commit with --fixes mantis:2 eventhough bug nr 2 doesn't exist. is this intended?
<fullermd> --fixes doesn't _do_ anything with the bug tracker.  It just saves a URL along with the rev for reference.
<sender> fullermd: understood, I guess thatdistributed means
<sender> being able to work without connection to the bugtracker (sorry for the newline)
<fullermd> Well, not just that...  who knows how $RANDOM_BUGTRACKER works.  How could bzr _tell_ whether the bug existed?
<fullermd> (first, you embed an HTML parser...   then an AI engine...)
<sender> fullermd: check for 200OK?
<sender> fullermd: AI enigine would be nice anyway ;)
<fullermd> That wouldn't help.  The bug tracker will return a "WTF?  I don't know what that bug is" page, but it's still a HTML page that's HTTP 200 OK
<sender> fullermd: ok that should be part of the bugtracker specific settings then, but def. nasty to implement
<fullermd> Yeah.  VERY nasty to implement, exponentially so to maintain.  And what if it needs authentication?  Session state?  etc.  It's an endless garden path.
<sender> :) btw would it in a way be possible to show the diff(s) along with the bug in mantis?
<fullermd> That would be going the other way; teaching mantis about bzr.
<sender> yeah, too bad bzr log doesn't seem to support bugnumbers, or am I missing something?
<bialix> you can have more than one revisions with the same bug url
<sender> bialix: is there a way to enlist them with log?
<bialix> I don't know. fullermd, you know almost everything, what you say?
<fullermd> I'm not aware of one offhand.
<fullermd> I never use --fixes though, so I'm not much of an authority on it.
<bialix> right. I've started to use --fixes heavily after I've started to use QBzr
<bialix> QBzr has full support: in qcommit you can easily provide bug url, and then see it in qlog
<bialix> IIRC this bug url feature was introduced in bzr core to use with lp as primary target
<fullermd> In a quick look around, the only place I see it showing up through the CLI is the long-form testament.
<fullermd> It's probably just gotten at the API level anywhere that actually uses it currently.
<fullermd> So, as soon as someone reimplements bzrlib in a sensible language like perl...   O:-}
<bialix> lol
<salgado> lifeless, how can I test your fix for that bug we were debugging yesterday?
<dvheumen> Hi, does anyone know which sentence is (more) correct? "warning: \'--allow-writes\' enables unauthenticated ' \
<dvheumen>                 'write access to anyone with network access to the server.
<dvheumen> woops, sorry
<dvheumen> ... enables unauthenticated writes access {to,for} anyone with network access to the server ... (Which is better, 'to' or 'for'?)
<bob2> by
<dvheumen> bob2: by?
<bob2> enables unauthenticated write access by anyone with network access
<theAdib> hello all,I am working on a project where I have to program on a win32/linux/mac box. I tried bazaar on my web server using ftp. Bazaar fails updating: FTP temporary error: 451 /repository.bzr/TDD/.bzr/repository/upload/eexq0mvoqcyo
<theAdib> zaxulmqz.pack: Append/Restart not permitted, try again. Retrying.
<theAdib> and then aborts after 3 failures. I can not change the settings in the ftp server (is part of the webhoster)
<theAdib> Do you have a suggestion how to work using bazaar? (My win32 and linux is on one computer)
<bob2> they don't provide ssh access?
<theAdib> bob2, no, they don't
<SamB> theAdib: break out your *old* computer
<SamB> use it as an SSH server
<theAdib> any way to use the ftp server as a collector for patch-sets and merge them back in an intelligent way?
<theAdib> is it possible to put the bzr-repository on an usb stick? And then move this from computer to computer?
<bob2> sure
<sigmonsays> Does anyone know what bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKintPack6 (bzr 1.9)\n' can be avoided?
<sigmonsays> s/what/how/
 * sigmonsays mumbles, back in his day you used to cvs checkout without a login. Now I need to give them a shared key, my e-mail and make an account in their system
<sigmonsays> oh, and install their crappy RCS command
<sigmonsays> that doesn't work...
<sigmonsays> this is rediculous
<Tak> sigmonsays: what version of bzr do you have?
<sigmonsays> Bazaar 1.5
<sigmonsays> they should seriously fix their crap if i'm forced to use it
<sigmonsays> this just pisses me off
<Tak> so...you have bzr 1.5, and it can't understand a bzr 1.9 format
<Tak> seems pretty straightforward
<Tak> who's "they", and how are they forcing you to use it?
<sigmonsays> everyone
<sigmonsays> jumpin through hoops just to get some code
<sigmonsays> git just works
<sigmonsays> none of this version crap
<sigmonsays> no account on launchpad
<sigmonsays> no shared key uploaded
<sigmonsays> no e-mail given
<sigmonsays> wtf is all that
<sigmonsays> they want some piss and blood too?
<Tak> git works? there must be a new release...
<Tak> you don't have to have a launchpad account to checkout code
<Tak> what you apparently need is a version of bzr that's less than 15 months old
<ToyKeeper> D'oh.  I still can't 'bzr diff -r parent:' even though 'bzr diff -r submit:' works fine.
<Tak> although it would be nice if lp allowed one to grab a tarball of a particular revision
<jelmer> Tak: bzr export -r<revision> lp:bzr foo.tar.gz
<jelmer> with the last two arguments swapped, sorry
<Tak> yeah, but I mean from the web ui
<jelmer> ah, right
<jelmer> I think there was some work happening in loggerhead to support that
<jelmer> Not sure if it's landed yet though, and/or if it is enabled on launchpad
<Tak> I can't find it anywhere on launchpad, although it could just be some place I haven't thought to look
 * kfogel is away: kfogel-food
<askogrand> This might seem like a silly question, but with bazaar can someone check out a single file?
<askogrand> as opposed to a folder.
<bob2> no
<askogrand> is there any version control system that will?
<bob2> svn
<captainc> Alright, I downloaded the bzr windows installation package and its giving me errors about plugins that are supposed to be in my local python site-packages directory. should i uninstall and reinstall in a different way?
<Raim> bob2: svn does not support checkout of single files, only unversioned 'svn cat $URL'
<captainc> How do I fix or work around this win32 symlinks issue?
<captainc> without cygwin
<phinze> hi folks, can someone point me in the direction of (or just give your own offhand) definition for "upstream" and "downstream" in the VCS domain?
<phinze> is upstream towards trunk and downstream towards the most remote fork?
<phinze> or the other way around?
<phinze> actually, just found this, which helped: http://strategiesforsustainability.blogspot.com/2005/10/upstream-vs-downstream.html
<Linkadmin> is there a way to configure a plugin against a branch instead of in ~/.bazaar/ ? I'd like to set up the bzr-email plugin to send an email to the dev mailing list on update without making all users install/configure the plugin in their homedirs...
<phinze> Linkadmin: you can install the plugin systemwide on your central server and then configure that branch to send emails; let me see if i can find a link that describes that
<Linkadmin> i've installed it system-wide already. Wasn't able to find docs on binding a plugin to a branch. That would be *much* appreciated
<phinze> ah ok
<phinze> so bzr help email is telling you to set post_commit_to and post_commit_sender ... i'm not completely sure but i think you should be able to set those in .bazaar/branch/branch.conf
<phinze> s/.bazaar/.bzr/
<Linkadmin> tried that on my local branch then bzr commit resulted in a pointlessCommit. I'll try on the central branch instead
<phinze> hah, that's a sassy error
<Linkadmin> lol yes
<phinze> Linkadmin: the other thing to look into would be https://launchpad.net/bzr-hookless-email
<phinze> i used that to some success for awhile
<phinze> it's nice because it doesn't have to be tied to a particular branch
<Linkadmin> it appears the branch.conf change in the central branch on the server worked  :D
<Linkadmin> i'll bookmark the other one too, thanks a ton!~
<phinze> awesome; good to hear -- i was always wondering whether bzr-email could worth that way :)
<Linkadmin> yeah i was really worried that it wouldn't hehe.
<lifeless> moin
<flvr8> hey, what's the proper thing to do with uncommitted trunk changes before doing a bzr switch to a branch? committing them locally fails (switch complains). we have a central repo, so there'd be nowhere to push them otherwise
<lifeless> flvr8: do you want them committed to trunk?
<flvr8> nope. (actually i'm asking on behalf of one of the guys in my team). typically the situation is he's working on a feature that'll end up in trunk, but he's not ready to commit. and some fire comes up on production that requires a change to the branch
<lifeless> bzr shelve --all
<lifeless> when hes done, bzr unshelve
<flvr8> excellent. thanks
<lifeless> moin jam
<abentley> lifeless: bzr-pipeline has that built in-- every branch has a shelf, and switching shelves and unshelves changes.  It works pretty nicely, and I'd like to have it in core.
<lifeless> abentley: Something I have with looms that I don't with regular branches is shelve-in-one-place, unshelve-in-another
<jam> morning lifeless
<jam> evening abentley
<abentley> jam: evening.
<lifeless> abentley: I really like that; its for moving changes across branches (similar to switch merging)
<lifeless> abentley: I think both cases are useful; I agree that having a solid answer to 'stop working on this bit now, but its not ready to commit' is needed, I'd also like to have an easier story for 'move this bit elsewhere' - which is currently 'switch elsewhere' for me
<lifeless> abentley: if we can satisfy both use cases in core I'll be ecstatic, and change loom to match the idiom
<abentley> lifeless: We already have merge --uncommitted and switch for the second case.  Why don't they satisfy?
<lifeless> abentley: merge --uncommitted isn't as interactive as shelve; it doesn't satisfy the 'get one hunk case'. I currently do that by 'shelve; select all but the bit I want to move elsewhere', then either switch or merge --uncommitted
<lifeless> then an unshelve
<abentley> lifeless: merge --uncommitted -i is exactly as interactive as shelve.
<lifeless> oh thats landed. Nice one1
<lifeless> s/1/!
<lifeless> so, in pipeline, how do you move an uncommitted change to the pipe before/after ?
<abentley> lifeless: Yep.  I was also thinking about supporting merge --shelf.
<abentley> lifeless: I move changes with standard switch, or with merge --uncommitted PIPE.
<lifeless> abentley: salgado's bug yesterday, was it affecting the lp puller/scanner/review stuff?
<lifeless> abentley: I thought you said that switching shelves first ?
<abentley> lifeless: I was simplifying.  "switch-pipe" shelves first.
<lifeless> jam: as you'll have finished work when I get these tweaks done, is there more after them? and do you want a re-review, or can I just grab a local tz-er for an incremental ok?
<lifeless> abentley: ah, ok.
<abentley> lifeless: I would expect salgado's bug to affect the puller, but I don't actually know.
<lifeless> abentley: ok. His bug is a bug in the remote streaming code, the branch itself is intact
<jam> lifeless: pretty sure an incremental is fine
<lifeless> if the puller is using file: or http: urls it won't be affected
<lifeless> jam: thanks
<jam> I don't remember any major review that was needed
<abentley> lifeless: Those pulls use http IIRC, so we might be okay.
<lifeless> cool
<lifeless> I won't make a lp task for the bug at this point then
<abentley> hmm, no, the scanner uses http.  I bet the puller uses file:  mwhudson?
<lifeless> so, you'd like to add per-branch shelves to core?
<abentley> lifeless: Yes.
<lifeless> along-with or replacing per-tree shelves?
<lifeless> It seems like along-with will add some complexity to the ui and how to explain/work with shelves
<abentley> lifeless: along-with, I think.  I tried to replace shelf with bzr-pipeline, but it wasn't really nice.
<lifeless> by replace with bzr-pipeline, you mean something like doing a commit on switch-pipe (from), and an uncommit on switch-pipe (to) ?
<abentley> lifeless: I was trying to unify shelves and (threads|pipes) into a single concept, but it didn't really work out.
<lifeless> ah interesting
<lifeless> so I was thinking during this conversation that for a branch, just doing a commit on the tip is ~= shelve
<abentley> lifeless: You can do "add-pipe -i --no-switch" to get an effect similar to "shelve"
<lifeless> when the use case is that you're getting rid of the attached tree (due to switch), and implicitly popping it off when the user returns to the branch
<lifeless> but thats likely going to surprise users that attach to the branch with a checkout, so its probably just a completely crack idea
<mwhudson> abentley: yes
<mwhudson> (well, it used lp-hosted/lp-mirrored, which backs onto a local transport)
<lifeless> abentley: so, +1 on some way to stash changes for a branch when there is no tree; I think users wanting to bzr switch will appreciate this a lot
<abentley> lifeless: I think you *could* do it as a commit, as long as you record the head somewhere other than last_revision.  Though you lose some of the potential for recording missing files, etc. that shelves have.
<lifeless> abentley: I'm not sure about the mechanism of shelf-per-branch, rather than (say) shelves-named-by-branches-in-the-tree
<lifeless> abentley: what do shelves do for missing files?
<lifeless> abentley: my concern about the mechanism is just ui complication/confusion. It would be good to get a few possible mechanisms under evaluation (something it sounds like you've been doing already) and do set based design on them
<abentley> lifeless: Being based on PreviewTree, shelves can represent basically any working tree state.  So if you added a file-id but not a file, you could shelve that.
<abentley> lifeless: But I said "potential", because most of our code, like merge, ignores unversioned files.
<lifeless> abentley: that makes me start speculating about having a kind of 'missing' in inventories ;)
<abentley> lifeless: The shelf on pipes only has space for a single set of changes, and it seems to work out alright.  Maybe I should see about making shelve/unshelve actually use pipes.
<abentley> lifeless: That would give us a single concept, but retain the specific shelve/unshelve UI.
<lifeless> so, in a non-pipeline, shelve would be as it is, in a pipeline it would add pipes ?
<lifeless> abentley: I think there are two broad questions: does shelve need a supercapability over commit? If yes, then we have to use shelve storage. If no we can look at temporary commits.
<lifeless> Secondly, what places do we need to be able to shelve things *to* - both for users comfort and tools like pipe/loom/bzr-explorer
<abentley> lifeless: sorry, on phone.
<lifeless> abentley: no worries, just finishing overnight mail+reviews anyhow
#bzr 2009-07-31
<lifeless> jam: oh, also - the new ACF exception is harder for people to match on
<lifeless> jam: how do you feel about:
<lifeless>  putting the string AbsentContentFactory in the string,
<lifeless>  changing the exception to BzrError (or something like that, that doesn't spew a backtrace)
<lifeless>  having it ask for a bug to be filed, with ~/.bzr.log's contents for that command
<poolie> emmajane: hi, are you around?
<lifeless> mwhudson: bug 406898
<ubottu> Launchpad bug 406898 in bzr "rocketfuel-setup (Launchpad) SHA1KnitCorrupt error" [Undecided,New] https://launchpad.net/bugs/406898
<mwhudson> lifeless: yeah, don't really know what's going on there
<mwhudson> lifeless: it's probably a bzr-git bug?
<mwhudson> (it's also intermittent, which is really strange)
<lifeless> not sure at all
<mwhudson> or maybe it's not intermittent, but only happens over http or something
<lifeless> is the branch in 2a format?
<spiv> poolie: good morning.
<poolie> hullo spivvo
<poolie> jam: i have comments on the lock-warning branch, please don't merge it yet
<spiv> Ugh, the bazaar@ moderation queue has gotten huge.
<poolie> spiv, oh probably, i haven't done it for a while and not many other people do
<poolie> and i think the spam filteringthere is poor
<spiv> Yeah.
<mwhudson> lifeless: borrow your cvs knowledge very briefly?
<lifeless> sure
<mwhudson> lifeless: https://pastebin.canonical.com/20636/ <- a chunk of rlog
<mwhudson> lifeless: the date for 1.20 seems a little bong, correct?
<lifeless> yes
<lifeless> client had the date wrong
<lifeless> rule 1 of distributed systems, you can't trust anyones dates except your own
<mwhudson> unless it's just a coincidence, i think this is confusing cscvs
<mwhudson> (very hypothetical as of yet)
<lifeless> cscvs has a huge chunk of code to deal with this - it generates a DAG of the versions
<lifeless> then walks that DAG, in parallel for all files, for each branch
<mwhudson> oh
<lifeless> theres a 'fun' test case in there
<lifeless> for the case of two files
<lifeless> with revs 1.1 @ time A, 1.2 @ time B in file F
<lifeless> and revs 1.1 @ time B, 1.2 @ time A, in file G
<lifeless> with the same commit messages
<mwhudson> lifeless: the CVS/Catalog thats getting generated in this case has revision 1.20 as the only 'add' for this file
<lifeless> [you need to turn this into 3 commits - A 1.1; A1.2,B1.1; B1.2
<lifeless> mwhudson: I think you're pulling on the right thread
<lifeless> this is one of the fundamental issues with CVS though; its not pretty
<lifeless> (I have actually seen that test case in the wild. Debugging that weirdness was Not Fun)
<mwhudson> the only 'mainline' add, rather
<lifeless> its definitely wrong
<lifeless> so the /intent/ is that date is a hint but the DAG wins
<mwhudson> ok
<lifeless> we start with N parallel DAGS, one per file
<lifeless> we collect across the DAGS by commit message
<lifeless> within that, cycles are broken - such as that vicious case above
<lifeless> finally, we walk in DAG,date order
<lifeless> so that if two commits on different files have no ordering to each other, date order wins
<lifeless> thats the intent. the reality - I think you've found damage :)
<mwhudson> i think there are probably two bugs here
 * lifeless is shocked
<mwhudson> one is this case (it's from sane-backends)
<mwhudson> the other, and this is rather more common, is that there seems to be a problem updating the catalog when a merge creates a file
<lifeless> mwhudson: I'm lunching/prepping LCA submission before the deadline
<lifeless> mwhudson: which is in 1 hour IIRC. So after that hassle me more :P
<mwhudson> lifeless: cool, thanks for the thoughts so far
 * mwhudson is off for a haircut soon in any case
<abentley> lifeless: (in a non-pipeline, shelve would be as it is, in a pipeline it would add pipes?)  All branches are single-pipe pipelines, so that's not a way to distinguish.  I think we'd start with separate commands.
<abentley> lifeless: (does shelve need a supercapability over commit?) shelve is meant to be a stepping stone to a true undo feature, so it will need more capability than commit has.
<lifeless> poolie: around?
<poolie> hi
<lifeless> a) quick call and b) still on for slug? I'm meeting horms et all @ the red oak at 5pm if you want a little pretalk social
<poolie> a- sure; b- i doubt i can make it
 * spiv heads out for a run and lunch.
<thumper> any bzr talks proposed for LCA2010?
<lifeless> yes
<lifeless> I put the groupcompress one in a minutes ago
<thumper> cool
<jml> thumper, I proposed a talk on Ubuntu Distributed Development.
<mwhudson> jml: hooray
<thumper> jml: hey, I just proposed two
<thumper> more launchpaddy though
<jml> thumper,
<thumper> jml: yes...
<jml> thumper, oh sorry, typo.
<thumper> jml: ok
<mwhudson> lifeless: borrow your thoughts again?
<lifeless> sure
<mwhudson> lifeless: so there is a problem in cscvs something like this:
<mwhudson> a branch is imported from cvs, all fine
<mwhudson> hm
<mwhudson> terminology :)
<mwhudson> a module is imported from cvs, all fine
<mwhudson> a file is created on a non-MAIN branch in cvs
<mwhudson> the import is updated, the catalog gets some entries, all still fine
<mwhudson> the branch is merged to MAIN in cvs
<mwhudson> when cscvs goes to update the import, the Revision that adds the file is a Revision.CHANGE
<mwhudson> so applying it goes boom
<mwhudson> if you generate the catalog from scratch, the Revision that adds the file to MAIN is a Revision.ADD, and it all works
<mwhudson> lifeless: makes sense so far?
<mwhudson> i've chased this as far as CacheGenerator.set_rev_type -- when you do an initial import, this is where the CHANGE gets overridden to an ADD
<lifeless> so 1.0 of the file is dead
<lifeless> 1.1 is alive, but datewise there are 1.0.1.1 versions alive before hand?
<lifeless> it makes sense to me; the incremental analysis is incorrectly thinking the CHANGE can be applied to trunk.
<mwhudson> lifeless: well, cvs has 1.1 not 1.0, but yes
<lifeless> magic black holes aside
<lifeless> ;)
<mwhudson> lifeless: http://pastebin.ubuntu.com/238150/ <- the full log
<mwhudson> lifeless: so i'm currently thinking that set_rev_type should dip into the catalog to check for this case, but i've nfi if that's at the right level
<lifeless> it should be already
<lifeless> but yes, I think you're in the rightish spot
<lifeless> its cscvs, by definition you're in the right spot
<mwhudson> holy crap, my fix works!
<mwhudson> the complexity is all kinds of wrong, but nm that
<lifeless> i am sorry
<lifeless> its a _very_ organic codebase
 * lifeless is not here anymore (\o/ starting at stupid o'clock)
<mwhudson> thanks for being a teddy bear
<lifeless> anytime
<lifeless> however, right now, I has talk to finish.
<lifeless> so, I actually mean, anytime except now.
<arjenAU> lifeless: has anyone played with inotify and bzr combo?
<lifeless> arjenAU: I wrote an inotify watcher at guadec 2008
<lifeless> dunno were it went...
<lifeless> arjenAU: but that was for repositories
<lifeless> there is a mail sender demon that uses inotify to detect changed branches too
<arjenAU> lifeless: pondering it for redundant webservers
<lifeless> arjenAU: how do you mean?
<arjenAU> auto-syncing them, but with revisioning and through bzr rther than rsync
<arjenAU> just talking static files and php scripts, not db data ;-)
<lifeless> oh hmm
<lifeless> probably a little shell love could glue them together well
<lifeless> a little program to watch for changes and run bzr update; bzr commit
<lifeless> myself, I'd just deploy via bzr upload to both servers
<arjenAU> with a push trigger. and it'd need to make sure of conflict resolution etc
<lifeless> and smack, hard, anyone touching them otherwise
<arjenAU> yea not disagreeing there, but there are other uses... pmwiki for instance uses plain files by default rather than a db.
<lifeless> right
<arjenAU> which has benefits.
<lifeless> surely it has a hook to call into things on changes?
<arjenAU> yep it has, but inotify would solve it more generically
<lifeless> with risk though
<arjenAU> regardless of which stupid app the server has.
<lifeless> inotify has some latency, and you could record inconsistent state
<arjenAU> yes, hence the pondering and asking you ;-)  right now it's an evil thought.
<lifeless> anyhow, I don't know of anyone doing this particular scenario, but bzr can coexist with inotify in python progreams - thats known for sure :)
<arjenAU> yaya
<arjenAU> there's a pyinotify too
<lifeless> yes, using that
<arjenAU> lifeless: already using etckeeper with bzr. rocks.
<lifeless> nice!
<arjenAU> I suggested something like that years ago except only bk was around then. happy someone actually did it and integrated with apt and such.
<arjenAU> it's like essential on a box. shouldnt be without it
<poolie> hi arjen
<poolie> spiv - did your comment before mean that you emptied the mailman greasetrap?
<spiv> poolie: no, just that I noticed the list admin mail about it.
<poolie> :/
<poolie> it's such an annoying chore
<poolie> i'll do it
<spiv> Yeah, it sucks.
<poolie> geez, look at them all
<spiv> Are we still getting bazaar-ng@ mail forwarded to that?  If not then decommissioning might cut down the problem a little.
<poolie> i think not
<poolie> i can't believe our spam system thinks all this crap about acai berries is relevant
<poolie> spiv, i might call it a day
<spiv> poolie: ok.  Have a good weekend.
<timeless_mbp> hello, is bzr supposed to fail when there's no disk space available?
<timeless_mbp> http://pastebin.mozilla.org/665240
<fullermd> Well, I wouldn't expect it to _succeed_  :)
<fullermd> I don't think python has built-in support for growing hard drives.
<timeless_mbp> well... as an end user, i expect that 'st' is a readonly operation
 * timeless_mbp gets out an end user's list of unreasonable expectations and points to this one
<fullermd> Well, it's potentially a write operation, since it may want to rewrite the dirstate file about the checkout (I don't think it does every time there are possibilities, for efficiency reasons).
<fullermd> In this case, though, it blew up on writing the logfile.  In that sense, _every_ bzr operation writes.
<fullermd> Even 'bzr rocks', which is as near a no-op as imaginable, writes an entry into .bzr.log.
<timeless_mbp> is there a --please-do-not-right
<timeless_mbp> or --please-do-no-write
<fullermd> There's no general such option, no.  You could hack around this _particular_ case by seeing the BZR_LOG env variable to something like /dev/null (or something on a partition with space).
<timeless_mbp> so, this is a design decision, and not bugworthy?
<fullermd> Well, the two aren't necessarily exclusive.
<fullermd> It _is_ a conscious decision.  That doesn't mean it can't be changed, though I wouldn't expect this one to be.
<fullermd> If it's actually a significant problem or a big surprise for you, it's worth registering in a bug or on the ML; the decision would certainly never be changed if nobody argued against it.
<timeless_mbp> essentially my system has a bunch of version controlled directories
<timeless_mbp> they automatically grow with changes from "upstreams"
<timeless_mbp> i was looking for trees which had changes, to decide whether i could delete them (if there aren't any changes in the tree, i could get it back later, when my disk space problems were resolved)
<fullermd> .bzr.log won't grow without bounds; bzr rotates it when it gest to a few megs.
<fullermd> You can use $BZR_LOG to shut it off temporarily, or rm the existing one/backup manually to free up a little space.
<timeless_mbp> in this case, i'm pretty sure my repositories were fairly tiny
<timeless_mbp> they were network-manager and network-manager-gnome
<fullermd> (stat may still try to write metafiles and fail if the partition is full, but one problem at a time)
<timeless_mbp> and had only a couple of uses
<timeless_mbp> sorry, i had to delete stuff, and the bzr repos were going to go, once i found the files i needed :)
<fullermd> The error you got isn't from writing anything in those branches, it's from the ~/.bzr.log  (though that may be the same partition)
<fullermd> So `env BZR_LOG=/dev/null bzr st` would get you past that at least.
<timeless_mbp> -rw-rw-r-- 1 timeless timeless 168K Jul 31 13:35 /home/timeless/.bzr.log
<fullermd> File a bug with the stacktrace anyway; we should probably handle it a little more gracefully.
 * timeless_mbp puts on a clueless hat
<timeless_mbp> "where's your bug tracker?"
<fullermd> https://bugs.launchpad.net/bzr
<timeless_mbp> thanks
 * timeless_mbp goes to find the password
<timeless_mbp> heh, it seems i've filed a couple of bugs against bzr :)
<timeless_mbp> oh, no
<timeless_mbp> it seems i can't understand launchpad's UI.. great
<fullermd> Don't think that makes you special   :p
<timeless_mbp> yeah, probably not
<timeless_mbp> https://bugs.launchpad.net/bzr/+bug/407295
<ubottu> Launchpad bug 407295 in bzr ""bzr st" failed to handle No space left on device for ~/.bzr.log" [Undecided,New]
<timeless_mbp> anyway, thanks. have a good weekend or something
<vxnick> does bzr-keywords work well?
<fullermd> In itself, it seems OK.  But various issues in the filtering layer keep it from being really useful.
<vxnick> as long as it doesn't break anything :)
<vxnick> are there any docs about the 2a format and a description of stacked branches?
<awilkins> Louder
<awilkins> Oops
<dolphy> Hi all, quick question. When contributing to a project generating a bundle sent by mail for a feature I added
<dolphy> if I want to work on a new fix feature meanwhile it's being reviewed, should I remove my branch and start from scratch again so that all bundles I m pushing are all coming from the original current branch ?
<beuno> emmajane, hi
<beuno> dolphy, you just create a new branch from trunk, yes
<beuno> so your diff is clean
<beuno> "feature branches"
<dolphy> beuno: any faster way to do that than rm -rf and a brand new bzr branch command ?
<beuno> dolphy, don't rm -f!
<beuno> leave it
<beuno> until it gets approved
<beuno> you may need to make changes   :)
<beuno> branch should be pretty fast if you're using a shared repository
<homy> Hi! Do you usually also put compiled binaries under revision control?
<LeoNerd> Generally not
<LeoNerd> But as with general vauge questions you'll get general vague answers. :) can you be more specific about your use case?
<luks> anything automatically generated
<homy> LeoNerd: no special use case. Just this one:  http://bazaar-vcs.org/Workflows#Solo.
<LeoNerd> Oh.. well, generally, don't then.
<LeoNerd> Half the point of a DVCS is you can do things like branch and merge. bzr won't be able to merge a compiled binary.
<LeoNerd> Best just to keep the source which it can merge, and have the binary handled separately by some build system.
<homy> LeoNerd: But I do put binary files like images under Revision control?
<LeoNerd> Well.. again.. it's partly up to you. bzr -can- store binary files... it's up to your situation if that's a good idea.
<LeoNerd> There can be valid use cases. E.g. storing GIF images as part of a webapp source.
<homy> or icons for a qt programm.
<LeoNerd> Indeed.
<awilkins> I wonder if you could bolt on that Google x86-binary-diff algorithm
<homy> ok, thanks. In what use case *would* you store compiled binaries?
<awilkins> Or something that unpacked JAR files and diffed the classes before
<awilkins> homy: Maven repository?
<awilkins> homy: Backup archive?
<awilkins> homy: I;m storing compiled binaries, but that's because I'm using Bazaar as an update mechanism for my users on a particular project - and the binaries are not in the source tree
<awilkins> homy: thinking about it I could probably just install Maven on their machines and make them run a maven goal to update their software...
<awilkins> .. they could have a working tree of the sources
<awilkins> But the project is basically done with now
<homy> sorry, what is "maven repository"?
<awilkins> Maven is a build-and-dependency system, primarily for Java applications
<emmajane> poolie, pong
<emmajane> beuno, hey :)
<homy> the same as apache maven?
<awilkins> homy: Yes
<awilkins> homy: We're using Apache Archiva as our repository
<beuno> emmajane, how's your day today to have a call?
<emmajane> beuno, pretty good. I'm just dealing with allergies right now so I'm snuffling lots.
<beuno> emmajane, in 2 or 3 hours would be great for me
<emmajane> beuno, that would be just after lunch which could work for me nicely as well.
<beuno> emmajane, perfect. Lets ping-pong later then  :)
<emmajane> beuno, sounds good :)
<corporate_cookie> I have a development branch; which is out of sync with a production branch. I want to merge some changes (entailed in 2 revno's) from the development into the production branch; but only the changes entailed in those two revnos. Anyone know how that can be done ?
<jam> sidnei: ping
<Tak> does bzr+ssh:// require server software other than ssh?
<LarstiQ> Tak: bzr installed on the remote end
<LarstiQ> Tak: or well, invokable. bzr_remote_path=~/src/bzr/bzr.dev/bzr works too
<Tak> ok, but there doesn't have to be any kind of server running?
<Tak> not like svnserve
<LarstiQ> Tak: no, bzr is just started up over the ssh session and shut down again
<Tak> cool
<Tak> is it possible to preauthorize a password with bzr+ssh using the auth mechanism?
<LeoNerd> Isn't that what an ssh key is for?
<Tak> heh, not possible sometimes
<sidnei> jam: pong
<jam> hey sidnei, I was hoping we could get buildbot working to build the latest installer
<jam> have you done anything with it recently?
<sidnei> jam: not recently no, but i haven't forgotten about it.
<jam> so at this exact moment I'm a bit preoccupied with something
<jam> but in about an hour it would be nice to work on it with you
<sidnei> jam: ok, i should get to a stopping point in one hour too
<jam> sidnei: ok, I'll try to ping you if I don't hear from you first :)
<sidnei> jam: awesome, thanks!
<nilg> hi, I've a problem, I've modified source files wrongly, it was after a local commit but before pushing on lauchnpad, does a revert command will do the trick, that is ignoring my last modifications?
<nilg> I tried to push directly (since I did not commit the changes), but it says: bzr: ERROR: These branches have diverged.  Try using "merge" and then "push".1
<nilg> but I certainly not want to merge I just want to ignore these last modifications
<SamB> nilg: "bzr uncommit"
<blackxored> hello everybody
<SamB> or maybe "bzr pull --overwrite"
<blackxored> how to export a part of my bzr branch to a svn repository without lose of history
<blackxored> ?
<SamB> blackxored: what part?
<blackxored> a debian/ directory without the .bzr/* files at the root
<SamB> blackxored: what does the repository actually consist of ?
<SamB> the bzr one, I mean
<nilg> SamB, no this will ignore my last commit, right? but I don't want this I want to ignore my last changes not committed
<SamB> nilg: oh!
<SamB> well, the diverging has nothing to do with that
<SamB> run "bzr missing" to see how they diverged
<nilg> and I'm scared to do bzr revert and loose my last commit
<SamB> bzr revert doesn't lose you commits
<SamB> only "bzr uncommit" or "bzr pull --overwrite"
<SamB> (and you can still *probably* find them again even then)
<blackxored> SamB, I got this branch: rootdir => .bzrignore and etc debian/ dir I need to push the debian dir only without the .bzr oens
<SamB> blackxored: you can't skip .bzrignore without losing history
<nilg> SamB, bzr revert has exactly what I wanted, thank you so much!!!!
<blackxored> then .bzrignore has to be checkout?
<blackxored> ci,I mean
<SamB> the .bzr directory, though, isn't part of the bzr-managed tree -- it's where bzr keeps it's notes -- so that won't show up if you just "bzr push" to the SVN URL of your choice
<SamB> hopefully, either your bzr repository originally came from the SVN repository or the SVN repository is empty?
 * SamB wonders what exactly a "chk" *is*
<blackxored> SamB, the svn repo is empty
<SamB> blackxored: so, why does it even need to be an SVN repository?
<blackxored> SamB, because is where the team is
<blackxored> anyway, my three is something like .bzr .bzr-builddeb com debian edu org .pc , and I only need to push debian/
<SamB> blackxored: and do you have bzr-svn installed, and is it a SVN 1.5 (or greater) format repository?
<blackxored> yes it is
<SamB> hmm, why do you only want to push the "debian" directory?
<blackxored> because I'm doing debian related work and that's all I need to commit
<SamB> I think it would make a lot more sense to keep using the bzr repository if Debian makes you jump through so many hoops to use SVN
<blackxored> SamB, sure but I'm part of a team
<blackxored> SamB, so solutions/?
<jam> sidnei: ping for great justice
<blackxored> SamB, I just want to keep history under debian
<SamB> well, you could either commit it all, or you could lose some of the history by filtering the branch ...
<blackxored> SamB, and push debian
<sidnei> jam: wrapping up, 2 minutes
<Tak> can you make another branch of the svn repo, merge in just the commits to debian/, then push those back up to the repo?
<jam> k
<blackxored> Tak, right, the question is how?
<SamB> but that would probably make it very difficult to collaborate with Ubuntu ...
<Tak> was your bzr branch originally branched from the svn repo?
<blackxored> Tak, no It was private
<SamB> blackxored: it would make things way more complicated unless the people who made the bzr repository aren't going to continue using it ...
<blackxored> SamB, I hosted my branch in launchpad initially
<blackxored> SamB, I could assume that won't be used anymore
<Tak> I'm not sure if you can automatically merge two branches that don't have the same ancestor...
<SamB> blackxored: and did you already try to talk the rest of the team into joining you in using the bzr branch?
<SamB> Tak: SVN repo is empty
<SamB> Tak: that's why I'm wondering what is so important about using SVN!
<blackxored> SamB, because the team uses svn!
<SamB> blackxored: they can't use anything but svn?
<blackxored> SamB, I'd be glad if they use bzr, actually, I'll jump and jump and jump...
<blackxored> SamB, I'm quite new , so won't ask them to switch
<Tak> hmm, could you push the branch to the repo, then merge out non-debian/-relevant revisions?
<sidnei> jam: ok, ready
 * sidnei updates bzr.dev
<blackxored> the branch has no upstream code
<blackxored> only debian dirs, and bzr-related ones
<SamB> blackxored: com edu and org are debian-related?
<Tak> must be a java project ;-)
<SamB> I mean, what do they do?
<blackxored> Tak, is a java project
<SamB> blackxored: oh, so there *is* upstream code!
<jam> sidnei: so the first (small?) issue, is that I don't think Tortoisebzr actually makes releases
 * Tak winnar
<blackxored> those files are ignored
<jam> so we don't really have tags to use
<jam> per se
<jam> is the solution to just force it?
<blackxored> SamB, *are* ignored
<Tak> so...everything but debian/ is ignored anyway?
<blackxored> Tak, yes!
<sidnei> jam: what you mean by 'force' it?
<Tak> so what's the problem?
<SamB> blackxored: so what bzr branch do you want in svn?
<SamB> step 1: make that branch
<jam> sidnei: force them to start using tags and releasing
<jam> or faking it my making my own branch with tags in it
<blackxored> ok, listening
<jam> to date, I've just grabbed whatever the current tbzr tip revision is
<SamB> step 2: bzr push svn://alioth.debian.org/path/to/repo/and/branch
<sidnei> jam: tip would work, but of course it would be best to have a tag
<sidnei> jam: who's upstream for tortoizebzr?
<jam> random people
<ronny> hmm
<jam> It was originally written a while ago, then updated by Mark Hammond
<jam> right now I'm not sure who is really maintaining it
<jam> I've seen updates from both bialix and Naoki
<ronny> reminds me, i need to get a hold of all the tortoise kinds of people (there shouldnt be one for each vcs)
<SamB> blackxored: if you don't really care about anything but debian/, you could just use jelmer's filtering plugin to remove everything else from the entire history before pushing
<ronny> more like one for all of the vcs's
<jam> sidnei: beyond that I think I can go through and update some of the bits.
<sidnei> jam: how does tagging work in bzr? can you tag a remote branch?
<jam> sidnei: tags are maintained as part of the branch meta-info
<jam> so if you are deleting the target, you can't just set a tag there
<jam> if you were copying into your own branch, then you could have your own set of tags
<jam> sidnei: what is this:
<jam> rem Enable this when this branch is merged.
<jam> rem make python-installer PYTHON24=${settings:python24} PYTHON25=${settings:python25} PYTHON26=${settings:python26}
<jam> rem @if %ERRORLEVEL% NEQ 0 (set BUILD_ERROR=%ERRORLEVEL%) & goto End
<SamB> why aren't tags part of the repository ?
<jam> You seem to copy the code from "python-installer" into your own set of lines w/ bdist_wininst
<jam> SamB: read the mailing list
<jam> lots of discussion there
<jam> stuff like, 2 projects using the same shared repo, and using "release-1.2" style tags
<jam> but being different ancestries
<SamB> jam: yes! I'm not exactly going to reread the whole thing
<SamB> jam: oh, point
<SamB> okay, that's good enough for me for the moment
<jam> yeah, there was a *lot* of discussion about possible tag mechanics
<jam> I'm not very satisfied with what we have, but at least we have something.
<SamB> and it's not a case where there is an obvious improvement
<sidnei> jam: hold on, let me finish this thought about tags, then i will look into that
<jam> sidnei: so I'm wondering if I should uncomment the "rem" and then remove the next few lines.
<sidnei> jam: so just tagging a specific revision (the one included in the installer) of tortoisebzr trunk in launchpad with the installer release version would be enough, if that's possible
<jam> sidnei: I would guess I actually have write access to lp:tortoisebzr or if necessary, I could *get* it.
<sidnei> jam: seems like you have access. in fact, i now have access to. the owner is an open team *wink*
<SamB> wow, that's got pugs beat!
<ronny> hmm
<jam> sidnei: what is "gf.recipe.bzr" ?
<ronny> now, how to persuade all the different tortoiseFoo teams to work togeth
<SamB> I mean, I have joked that if you so much as *sneeze* in #perl6, they will give you pugs commit access, but ...
<sidnei> jam: it's a buildout recipe that calls bzr
<ronny> i managed to end up in the pugs contributors list
<sidnei> jam: just so the branches to be pulled for the plugins are in the buildout.cfg
<jam> sidnei: sure, but where is that recipe, and how is it maintained?
<jam> as I don't see the code anywhere
<SamB> (assuming your sneeze includes an email address and possibly an SSH public key ;-P)
<sidnei> jam: oh, it's in launchpad, lp:gf.recipe.bzr
<jam> sidnei: how is that found by the boostrap code?
<SamB> sidnei: that's your girlfriend's recipes?
<jam> as I don't see a reference to that sort of thing
<sidnei> SamB: could be :)
<ronny> what is gf ?
<sidnei> jam: oh. it's downloaded from pypi with easy_install
<sidnei> gf == greenfinity
<sidnei> company from hungary
<SamB> hmm, what's the correct Ubuntu release to list in my sources.list to get the nightly builds at the moment?
<jam> sidnei: so should we be using the rc6 release, and/or #strict ?
 * SamB wishes bzr would up an additional progress bar when it has to do a repack ...
<sidnei> jam: rc6 should work yes, i haven't used strict, i believe it's not needed
<jam> sidnei: I'm concerned about this:
<jam> On update, if "pull" is unsuccesful, the recipe will give an error with the bzr command output, but it will not cause buildout to stop with an error. The developer needs to look at this output to realize that the update has not taken place.
<jam> I'd rather buildout failed if it doesn't manage to update properly.
<jam> IMO
<sidnei> jam: ok. i believe strict fails in that case, so we can use strict.
<SamB> jam: that *is* the usual configuration, yes
<jam> SamB: what is the usual configuration?
<jam> At least from what I can tell, gf.recipe.bzr changed what is happening
<jam> and if I read pypi correctly, it seems to say that the latest release is more relaxed then before
<SamB> having buildbot fail when it can't pull / checkout from the VCS
<sidnei> jam: looking at the source for strict, seems like it does what you want.
<jam> now, do I need to set:
<jam> gf.recipe.bzr#strict = 1.0rc6
<jam> or do I just set
<jam> gf.recipe.bzr = 1.0rc6
<jam> and then later use
<jam> recipe = gf.recipe.bzr#strict
<sidnei> jam: the latter, though it's ':strict' not '#strict'
<jam> sidnei: k, though that isn't what pypi said
<jam> according to this page: http://pypi.python.org/pypi/gf.recipe.bzr
<jam> perhaps the docs for gf.recipe.bzr need to be updated?
<sidnei> jam: yeah, i don't remember #strict working, but i could be wrong.
 * sidnei files a bug
<jam> (given that you seem to have commit rights there)
<jam> sidnei: so I had #strict and it didn't fall over immediately
<jam> but that could be because it treated # as a comment
<jam> and just ignored it
<sidnei> likely yes
<sidnei> i have a couple branches to merge there, will sneak this fix in
<jam> sidnei: this doesn't seem like the correct place for an official zlib dll:
<jam> http://www.zlatkovic.com/pub/libxml/zlib-1.2.3.win32.zip
<jam> not to mention I noticed because I got a timeout while trying to download
<sidnei> jam: that's the one i've been using for building lxml for ages, where you've been getting zlib from?
<jam> I'm not sure what you were doing with it, but I would think:
<jam> http://www.zlib.net/zlib123-dll.zip
<jam> sidnei: and the fact that the dir is "libxml" means it would be a reasonable place for *libxml* but not necessairly zlib :)
<jam> argh
<jam> getting a traceback inside "hexagonit.recipe.download"
<sidnei> jam: if i remember correctly, the version provided at zlib.net is not statically compiled, but i could be wrong
<jam> sidnei: http://paste.ubuntu.com/239887/
<jam> sidnei: the one at zlib is a dll, yes
<jam> but the one *I* compile against is a dll, as well
<jam> I've been packaging zlib1.dll into the installer for a while
<sidnei> jam: ah, so you're shipping the dll, ok.
<jam> well, py2exe is :)
<sidnei> jam: for lxml, it is all statically linked, so the dll doesn't need to be shipped
<jam> also, is there any chance to not have "make installer-all" pollute my working dir?
<jam> sidnei: well, python itself statically compiles against it
<jam> and if they *didn't* then we wouldn't need to do it ourselves
<jam> we want like 1 function out of it, but python hides the zlib dependency
<jam> so even though all the functionality is there... ;(
<sidnei> :/
<sidnei> jam: log is not defined, ha!
<SamB> sidnei: import math, duh ;-P
<jam> sidnei: yeah, so bug in hexagonit... I think we can work around it somehow by unsetting: 'strip-top-level-dir'
<jam> sidnei: what does that setting do?
<jam> since I see you set it on almost all the recipes
<sidnei> jam: it unpacks the file in the target directory, instead of creating a sub-directory with the zip file name
<jam> sidnei: so the zlib.net zip file puts everything into the root dir
<jam> should we be unsetting this?
<sidnei> jam: give it a try, i believe so
<jam> sidnei: it at least doesn't crash
<jam> so a good strat
<jam> start
<jam> I'm all the way to "Getting release from bzr repository...."
<sidnei> jam: awesome
<jam> course, it breaks after that
<jam> but at least a start :)
<sidnei> :P
<sidnei> jam: whats the failure
<jam> "C:/Users/jameinel/dev/bzr/work/tools/win32/qbzr/trunk@tag:release-0.12/"
<jam> (I'm pretty unhappy about all the droppings in my WD, I'll probably try to clean that up next.)
 * SamB wishes you didn't need a special build of python just to get backtraces in GDB...
<jam> sidnei: As near as I can tell, it isn't trying to use "trunk -r tag:XXX" but an actual branch named "trunk@tag:..." and it never actually created it
<jam> my guess is something about not handling the "@"
<jam> bzr *itself* doesn't treat it like svn does
<jam> it just considers it another character
<jam> not an indication that it is a specific rev in that branch
<sidnei> jam: yes, that seems like a bug in gf.recipe.bzr, which is odd because it worked when i tried
<jam> sidnei: might be 1.0rc5 versus 1.0rc6?
<jam> also: lp:///~jameinel/bzr/1.18-win32-buildbot
<sidnei> jam: maybe, want to change versions.cfg and try again?
<jam> is the latest of what I've been doing
 * sidnei gets it
<jam> I had to back up the setuptools version
<jam> do you know any reason why I would need setuptools...9 instead of 8?
<sidnei> jam: no specific reason, just the latest available
<jam> k
<jam> I seem to have 8 installed
<jam> and if I leave it at 9
<jam> it fails
<jam> claiming incompatibility
<sidnei> nasty
<sidnei> jam: what's the parent branch for your branch?
<sidnei> seems like it has a couple extra changes from bzr.dev
<jam> sidnei: only things that landed in bzr.dev, but probably not mirrored to lp: yet
<sidnei> jam: ah, ok.
<jam> namely: 4580 Canonical.com Patch Queue Manager 2009-07-31 [merge]
<jam>      (jam) Support SIGBREAK on Windows dropping you into the debugger.
<sidnei> xactly
<sidnei> jam: whats your complaint about the WD?
<jam> sidnei: building the installer creates about 10 directories in tools/win32
<jam> which means "bzr status" is no longer clean
<sidnei> jam: where should they be created? under build?
<jam> sidnei: something like that
<sidnei> jam: makes sense
<jam> sidnei: working on it now
<nevans> I'm looking for the simplest command line to restore a previously deleted file/dir (assuming that I know the rev id that I want)
<nevans> "bzr cp foo/bar@123 foo/bar" was my first instinct (coming from svn-land)
<Raim> nevans: bzr revert foo/bar  restores the file
<nevans> oh yeah.
<Raim> nevans: think like reverting the deletion
<nevans> :)
<jam> sidnei: so since i'm creating this new location, would it make sense to always nuke it as part of "make installer-all" ?
<jam> and I'm getting the same failure with 1.0rc5
<sidnei> jam: im investigating the failure, seems like an actual bug
<sidnei> jam: not sure about nuking, i would prefer it to be part of make clean
<nevans> Raim: hmm... no luck.
<jam> sidnei: so the way "build_release" works, is that it keeps branches of everything it wants
<nevans> bzr revert -r 123 foo/bar just does nothing.
<jam> but then nukes a new directory
<jam> and stages everything into that
<jam> so it doesn't necessarily do a fresh download of everything
<jam> but it *does* copy everything into a clean build location
<jam> sidnei: revno 4583 of my branch now stages everything into a 'build-win32' directory
<nevans> it's possible that the containing dir was also deleted at some point (and then recreated).  but I don't even get a conflict
<sidnei> jam: yeah, i remember that.
<sidnei> jam: i would say go for it then.
<Raim> nevans: maybe I did not understand you correctly, but you just deleted a file and want the last version back, right? why would you need a revision number?
<nevans> ahh! I just figured it out.  It turns out that I never *actually* deleted the file dir.
<nevans> I simply moved it from src/foo to src/shelved/foo
<jam> sidnei: so the main problem is that it is going to download everything from remote *from scratch* based on what I'm seeing now
<jam> (it seems to copy everything into $project)
<nevans> so, when I tried to "bzr src/foo/bar", that was a no-op, because src/foo/bar actually still exists in my HEAD (albeit in a different location)
<jam> which would be inside $BUILD/$project
<nevans> however, when I ran "bzr revert -r 123 src/foo" it renamed src/shelved/foo back to src/foo
<sidnei> jam: ok, found the bug. the 'strict' recipe is out-of-sync with the other one, i have a branch ready to merge to fix that. i will make a release with this asap
<jam> k
<nevans> Raim: to answer your question, it wasn't *just* deleted.  I thought it was deleted a long time ago.
<sidnei> jam: you can change where it's checked out, just change the 'destination'
<nevans> when actually it was merely renamed a long time ago.
<jam> it seems to be trying to re-use my local shared repo, which means it inherits certain flags like "by default don't create working trees"
<sidnei> jam: for the [bzr] part, set the shared-repo to true
<sidnei> jam: that makes it create a new shared-repo
<jam> sidnei: though for testing, I don't really want to wait 10min for it to download bzr from scratch... :)
<sidnei> jam: eh :)
<jam> as long as it is only bzr, its probably fine
<sidnei> jam: for landscape, i've made 'destination' a configurable option and i pass it a path outside the tree
<sidnei> jam: so all checkouts are on a central directory
<jam> sidnei: so gf.recipe.bzr has another small bug
<jam> it seems to assume that "bzr branch $OTHER" will create a local working tree
<jam> but you can create a local repo and set "no_working_trees"
<jam> which is how mine work
<jam> works
<sidnei> jam: true. is there a command line option to force working tree?
<jam> sidnei: so there is "bzr branch --no-tree" I don't know if the other way works
<jam> checking
<jam> no, it looks like the flag only disables creating a tree
<jam> setting it to True, gets overridden by the repository policy
<jam> you *can* do "bzr checkout ." to make it create a workingtree
<sidnei> jam: so bzr checkout after bzr branch
<jam> potentially
<jam> I'm trying to understand gf.recipe.bzr a bit to be sure
<jam> sidnei: shouldn't bzr_strict inherit from bzr ?
<jam> (or something to that effect)
<jam> I suppose you could do "bzr get --no-branch" and then "bzr checkout ." after that
<jam> which should always succeed
<jam> otherwise I'm not sure what "bzr checkout ." does when you already have a checkout
<sidnei> jam: that could work
<jam> sorry "get --no-tree" :)
<jam> sidnei: so without :strict (since it is currently broken) if it fails to get the branch at all
<jam> it then fails during "os.chdir()"
<jam> rather than giving you the error at the time it happened
<jam> namely, that it can't get the code...
<jam> anyway, I don't quite understand why the default isn't strict
<jam> but hey, I'm not the one writing it
 * SamB wishes Python supported compacting collection ...
<sidnei> jam: strict wipes out the branch if it fails to pull *wink*
<jam> also, it seems that gf.recipe.bzr requires that you have a valid "bzr.exe" in your path, as  Ihave 'bzr.bat' and a really old version of bzr.exe
<jam> hmm
<jam> failing the build because you failed to pull
<jam> is different than nuking a dir
<sidnei> jam: i agree. it should never nuke a dir. i am not using strict because of that, so i should fix it
<sidnei> jam: if you get your old version of bzr.exe out of the path, it should call bzr.exe i believe
<sidnei> s/exe/bat on the latter
<jam> http://paste.ubuntu.com/239952/
<jam> "no such file"
<jam> http://paste.ubuntu.com/239953/
<jam> works if I explicitly state "bzr.bat"
<jam> let me try it in a different shell
<sidnei> jam: pass 'shell=True'
<jam> ah, yeah, shell=True changes that
<sidnei> jam: does it call bzr.bat then?
<jam> sidnei: yes
<jam> and gf does use shell=True
<sidnei> jam: awesome. that's the intended behaviour
<jam> sidnei: I was wondering if we could get it to run the local copy of bzr
<jam> but that is probably a pain to get working
<sidnei> jam: uhm, that could work. maybe an option to the gf.recipe.bzr recipe 'executable=/path/to/bzr.py'
<jam> sidnei: yeah, I'm not sure that it is generally useful
<jam> as only *bzr* is going to have that
<sidnei> jam: or people that don't have bzr in the PATH
<jam> while gf.recipe.bzr is about building everything else with bzr as just a mechanism to get the code
<sidnei> (or even more than one bzr in the PATH)
<jam> sidnei: also, how does all of this work if you want to try packaging $TIP for bzr + plugins?
<jam> The idea being a "nightly" build
<jam> is it that you would use $TIP for bzr, but explicit versions for everything else?
<sidnei> jam: should work both ways. did i show you this? http://buildbot.sidneidasilva.com/
<sidnei>  argv: ['make', 'installer-all', 'BZR_TARGET=release', 'PLUGIN_TARGET=plugin-dev',...
<jam> So I think I have the "boostrap" stage all working
<jam> I get to the point of:
<jam> cd build-win32 && bin/build-installer.bat release plugin-release
<jam> Removed: c:\Users\jameinel\dev\bzr\work\build-win32\release\bzr.1.17
<jam> so it seems like it makes it all the way to the end
<jam> but "build-installer.bat" sort of falls over
<jam> now, it could be that "foo.bat" can't find my "make"
<jam> as I have make in cygwin
<jam> but not a mingw32 or other more "pure windows" make
<sidnei> jam: could be. is it in your PATH?
<jam> well running "cmd.exe" and then typing "make"
<jam> seems to find it
<sidnei> should be enough
<jam> so, is there a way to get the .bat file to say something about what is going wrong?
<jam> or alternatively, why are we using .bat here, rather than python?
<sidnei> jam: no specific reason, other than passing environment variables in python is a little more sucky
<jam> sidnei: just to set PYTHONPATH?
<sidnei> jam: no, there's a boatload of environment variables in build-installer.bat, check it out
<sidnei> jam: is there a way to make a branch remember its pull location without doing 'bzr pull --remember'? i wanted 'bzr get --remember'
<jam> ah sure
<jam> sidnei: "bzr get" defaults to remember
<jam> or I should say
<jam> if you are creating a new branch it should remember its source automatically
<jam> sidnei: Popen(env = {dict}) doesn't seem that bad to me
<sidnei> so 'bzr get BRANCH' followed by 'bzr pull' with no args should work just fine?
<jam> sidnei: yes
 * sidnei fixes gf.recipe.bzr once more
<sidnei> jam: im fine with rewriting it as a python script, just that it sounded like too much work at the time. not sure it will gain you anything though
<jam> sidnei: easier for *me* to support :)
<jam> won't gain a lot today, sure
<jam> more about maintenance, etc
<jam> I guess what it would give me right now is a way to drop into pdb to figure out why it thinks it is building just fine, but I'm not actually getting any results
<sidnei> jam: there's no output at all?
<jam> sidnei: I showed you the output
<jam> it seems to build everything
<sidnei> jam: it should exit with an errorcode if it it fails
<jam> well, dependencies
<jam> and then I get:
<jam> root is c:\Users\jameinel\dev\bzr\work\build-win32
<jam> Removed: c:\Users\jameinel\dev\bzr\work\build-win32\release\bzr.1.17
<jam> with exit code 0
<sidnei> doesn't sound right
 * sidnei checks
<jam> (I added the "root is" line)
<jam> It removes the directory, seems to checkout a new directory
<jam> and then stops
<sidnei> jam: that's all checked in to your branch? i will give it a try
<jam> the message isn't
<jam> but having everthing "work" is checked in
<jam> ah, let me push
<jam> sidnei: rev 4586.
<jam> if I remove the @echo off
<jam>  line
<jam> it does the checkout
<jam> and then just stops
<jam> oh I know why....
<jam> bzr.bat
<jam> calling a .bat file *from* a .bat file
<jam> transfers control
<jam> and stops running locallly.
<jam> thats a reason to use python
<sidnei> :P
<jam> using "CALL bzr" makes it return control
<sidnei> jam: try adding '%COMSPEC% /c' before bzr
<sidnei> or that yeah
<jam> but I don't know what it does if it is a .exe
<sidnei> %COMSPEC% will work with an exe
<sidnei> i am mostly confident
<jam> right, it is just effectively "sh -c"
<sidnei> yup
<jam> so it at least gets to the point of:
<jam> c:\Python25\python.exe: can't open file 'setup.py': [Errno 2] No such file or directory
<jam> and I think *that* is because I don't have checkouts
<sidnei> seems so
<jam> k, 4587 uses COMSPEC
<jam> now I'm having failures related to 'msginit'
<jam> seems I have a copy on my path that doesn't work
<jam> man, getting the dependency stack for pygtk on windows sucks
<jam> everything is a .zip download
<jam> and there are all sorts of version questions
<sidnei> jam: you will start bundling pygtk in the installer too?
<jam> no
<jam> It is just where I have "msginit" on my system
<jam> k, found another small problem with "rebase" vs "rewrite"
<sidnei> jam: i made a release of gf.recipe.bzr with a fix for strict and a couple others that were pending merge, want to try that?
<sidnei> jam: 1.0rc7 it is
<jam> sure
<jam> I assume I just change the version nmu?
<jam> num?
<jam> (and add :strict back)
<sidnei> jam: yep
<jam> sidnei: so I'm getting a failure now ,because qbzr optionally supports pygments, and py2exe is failing when it tries to import pygments
<jam> any suggestions?
<jam> would we put that into boostrap ?
<jam> or is it just use whatever people have installed
<jam> like we do for PyQt etc
<sidnei> jam: depends on how hard it is to get pygments in. if it's trivial, i would add it
<sidnei> i guess size also matters
<jam> well, it is an "easy_install" sort of thing
<jam> I think we want it in the final package
<jam> PyQt dominates the size of everything else
<sidnei> jam: let's do it then
<jam> I'm pretty sure it is installed on kerguelen
<jam> sidnei: of course, we aren't staging PyQt at this time
<jam> how does buildout handle the fact that you may have libs in your python install
<jam> which differ from what you are building
<sidnei> jam: there are some recipes that can be told to ignore all of site-packages in your python install
<sidnei> jam: gary is polishing that up for launchpad usage
<sidnei> jam: but that's different from what we are doing, which is to call 'python setup.py py2exe', going completely around that
<jam> sidnei: so far, 1.0rc7 "just works" for me
<sidnei> jam: there is a way of generating a 'custom interpreter' with buildout, which would mean we can get things installed locally without polluting the system-wide site-packages, but i wonder if that will play well with py2exe
<jam> sidnei: well, you could boostrap into downloading python.msi and installing it to a local dir, etc
<jam> so it seems that on kerguelen, if I use setuptools c8 (like I have here) it fails with the same "incompatible" error
<jam> (just opposite)
<jam> so perhaps I'll just install c9 here and live with it
<sidnei> jam: that's probably a good idea
<sidnei> c8 is like 2 years old by now ainnit?
<jam> well not much older than that
<jam> this machine isn't much more than 1.5 yrs old
<jam> can you update setuptools using setuptools?
<sidnei> jam: you can! easy_install -U setuptools
<sidnei> on windows you might need to call it with python easy_install-script.py
<sidnei> otherwise it fails to replace the .exe
<sidnei> (easy_install.exe that is)
<sidnei> jam: if you want to give the buildout python thing a try, see the section 'custom interpreter' on this page: http://grok.zope.org/documentation/tutorial/introduction-to-zc.buildout/recipes-to-install-eggs-scripts-and-custom
<sidnei> jam: if you add eggs = Pygments there, then run setup.py with the the generated 'bin/py', it *might* work
<jam> sidnei: Couldn't find index page for 'zc.recipe.eggs' (maybe misspelled?)
<jam> ahh, singular
<sidnei> jam: yes, mispelled, it's 'egg'
<jam> well zc.recipe.egg:eggs
<jam> so the plural form is in there
<sidnei> eh
<jam> sidnei: hmm... that gets me to the point where it thinks "build-win32/subvertpy" should be a checkout
<jam> when the checkout should be "build-win32/subvertpy/release"
<jam> perhaps a bug in gf?
<sidnei> jam: could be, traceback?
<jam> http://paste.ubuntu.com/240101/
<sidnei> jam: your branch is pushed?
<jam> sidnei: everything except the 'zf.recipe.egg' stuff
<jam> I get the same failure without it
<jam> it seems that :strict and uninstall aren't playing well together
<jam> though getting rid of :strict seems to cause the same failure
<sidnei> jam: yeah, uninstall is called by both. removing the directory manually will get you going for now, while i figure out what's wrong
<jam> on kerguelen it is up to "getting trunk for bzrtools"
<jam> sidnei: if I delete subvertpy, then it has the same failure for bzr-rewrite
<jam> I have the feeling, it is going to keep chaining until it is all deleted
<sidnei> jam: yeah, all of them
<jam> though maybe it is because I did a manual "bzr co" ?
<jam> so it doesn't actually build at home because I don't have VC9
<jam> weird, transient error downloading svn-lib
<jam> Connection Refused now
<jam> of course, it doesn't do anything nice like tell me what url it couldn't download:
<jam> http://paste.ubuntu.com/240118/
<sidnei> ;/
<sidnei> jam: i figured the uninstall problem
<sidnei> jam: os.listdir() found the .bzr dir, because of the shared-repo
<jam> ah, so it says there is something there other than just the directories it knows to remove?
<sidnei> jam: well, it's a plain bug. it tries to do 'bzr st .bzr' :)
<jam> oops
<jam> it seems subversion.tigris.org is down right now anyway...
<jam> so not much I can do to try it at this point
<jam> not a big deal
<jam> as I should have stopped working 10 min ago :)
<sidnei> me too :)
<sidnei> jam: what timezone are you on?
<jam> central US
<jam> chicago
<jam> what about yourself?
<sidnei> jam: BRT (GMT-3), freezing southern brazil
<jam> interesting, as I'm GMT-5
<jam> I guess you work later than I do :)
<sidnei> yes, i work from 10-8 with long break for lunch
<jam> sidnei: well thanks for working on this with me
<jam> I think it is close
<jam> will you be available at all on Mon?
<sidnei> jam: it's been a pleasure! thanks for pushing me!
<sidnei> jam: i will
<jam> k, I'll see you around then
<jam> hopefully the subversion web host will be back up :)
<sidnei> jam: except 16UTC, for an irc meeting, but that should be no trouble
<sidnei> see ya!
<sidnei> jam: fwiw, i made a 1.0rc8 of gf.recipe.bzr with the fix for uninstall
 * sidnei disappears now
#bzr 2009-08-01
<paperMonolith_> hello, i just installed bazaar in vista64, i seem unable to revert fils to previous versions, i tried command line and it does nothing and in the browser the option appears greyed out. in the log it shows that  there clearly are several revisions. if this is a common issue, could you please point me to the solution, if this is a noobish thing, please point me in the right direction, thank you.
<bob2> paperMonolith_: what command are you running?
<paperMonolith_> the one in the docs: in the intended folder i do "bzr revert <file>"
<paperMonolith_> but i think i now understand the problem
<paperMonolith_> if i change the file, and don't comit, it lets me revert. but i can't seem to revert to previous commits
<paperMonolith_> should i be using uncommit?
<jam> paperMonolith_: bzr revert -r -2 file
<jam> you have to specify what you want to revert back to
<jam> by default "bzr revert" reverts to the last commit
<paperMonolith_> oh, i see. thank you then :)
<paperMonolith_> it worked. thank you :)
<paperMonolith_> when i do this, the last commit for this file dies or does it have a backup? if it has a backup, how do i access it?
<fullermd> revert doesn't do anything with commits.
<fullermd> It only changes the file in your working copy.
<paperMonolith_> ah. ok. i understand. thank you.
<pst> I would like to use NestedTrees and have read http://bazaar-vcs.org/BazaarFormats. It looks like I need dirstate-with-subtree but it says not recommended for use - what are my options for nested trees?
<fullermd> pst: There aren't really any, NestedTrees are only partially implemented.
<pst> fullermd: well thats a pitty, do you have any advice on how high the risk is? :)
<fullermd> Well...   what's there is incomplete, what is complete mostly doesn't have a UI, and I think it bears an incomplete relationship to the feature as it's currently planned to actually be completed.
<fullermd> I wouldn't try using it unless you were planning to catch up and help develop it...
<pst> I doubt my programming skills are good enough for that
<pst> thanks anyway, now i need to find another way to accomplish something similar
<fullermd> You can look into the scmproj plugin (I think that's what it's called)
<pst> I will do that, thanks a lot
<LarstiQ> it is, http://launchpad.net/bzr-scmproj
<pst> found it already will give it a try and see if it is a fit
<LeoNerd> I may have asked before, how but safe is it to use rsync to push a mirror of a bzr repo tree, for offsite backup purposes?
<jetole> hey guys. I just started working with bzr from two different locations, how do I update my files on this computer so they are current from the commit I did on another computer when this computer already has the repo setup
<jetole> i.e. I was working from home computer. Did a commit, checked out from work and did a commit at work and now I want my home computer to have the commit I did at work?
<LarstiQ> jetole: `bzr pull` if you are working with branches, or `bzr update` for checkouts
<jetole> I think update since I want all the local checkout on each computer to be kept in sync?
<jetole> does that sound right?
<jetole> they are both working with the same branch I believe
 * jetole tries update
<jetole> update looks right. It shows the modded file and shows that I have changed to the latest commit #
<jetole> thanks LarstiQ
<LarstiQ> np
<lifeless> jelmer: hi
<jelmer> lifeless, moin
<lifeless> got, oh 10 minutes for me?
<lifeless> https://code.edge.launchpad.net/~lifeless/subunit/progress-gtk/+merge/9487 got partially reviewed by you the other day
<lifeless> https://code.edge.launchpad.net/~lifeless/subunit/subunit2junitxml/+merge/9534 is a new [tiny] branch
<jelmer> lifeless: so, the gtk one I did fully review but my network was gone by the time I was submitting my review
<lifeless>  /o\
<ronny> hmm
<ronny> i could use some sample code doing a directory rename with MemoryTree
<jelmer> lifeless, submitted again
<lifeless> thanks jelmer
<lifeless> the subunit2junitxml one is _tiny_
<lifeless> (just skip the untouched gtk stuff :P)
<jelmer> heh, that's trivial indeed
<lifeless> thats really the point of subunit :P
<lifeless> so, with that, you could replace the buildfarm with hudson rather easily ;P)
<jelmer> how'd your talk go?
<lifeless> well I think
<lifeless> couple of interesting after-talk discussions
<jelmer> lifeless, Thanks, there's things I enjoy better than setting up java on outdated and remote tru64 machines :-P
<lifeless> would have been nice to point at lots of projects using it; but at the heart of it I don't think thats actually important - it simply reflects network effects
<lifeless> jelmer: well, thats true. [64, heh, heh]. What I mean to say is that splitting out separate projects can be good :)
 * jelmer nods
<jelmer> lifeless, do you know if there's a release of check with the subunit support yet?
<lifeless> no
<lifeless> I've been meaning to poke about doing a release.
<lifeless> jelmer: why the objection to catching AE?
<jelmer> lifeless, it doesn't necessarily mean that accessing that function was what threw the AttributeError
<lifeless> fair enough; I flip to and from on this point
<lifeless> heh, typo you missed
<lifeless> jelmer: http://paste.ubuntu.com/242682/ - incremental
<SamB> jelmer: what's this other thing on fetch.py:1073?
<jelmer> lifeless, +1
<jelmer> SamB, replay range allows you to do multiple replays in a row
<jelmer> saves some roundtrips
<jelmer> once replay works it may be interesting to look at it
<lifeless> jelmer: I'll probably play with stacked progress during the week
<lifeless> jelmer: after thats finalised I'm going to look at a 0.2 release
<jelmer> lifeless, anyway, looking forward to trying out the gtk stuff with samba :-))
<jelmer> lifeless, cool
<lifeless> jelmer: I'd really love it if you could fix the perl bugs soon
<lifeless> https://bugs.edge.launchpad.net/subunit/+bugs
<SamB> jelmer: oh, any particular reason the UA field is so wierd looking?
<SamB> User-Agent: SVN/1.6.1 (r37116)/bzr1.18dev+bzr-svn0.6.4dev0 neon/0.28.4
<jelmer> SamB, because of the svn client libs
<SamB> jelmer: which part do you supply ?
<jelmer> SamB, the string bzr1.18dev+bzr-svn0.6.4dev0
<SamB> okay ...
<SamB> so why the heck do they put that after a slash ...
<jelmer> the rest is not controlled by bzr-svn
<SamB> jelmer: yeah, I realize you don't control all of it -- that's why I asked ;-)
<lifeless> jelmer: do you think thats possible?
<vxnick> hello sailors
<vxnick> wrong channel... :P
 * vxnick slips back into the shadows
<lifeless> lol
<SamB> jelmer: so what repositories do you test this on, anyway?
<jelmer> SamB, testsuite
<lifeless> jelmer: do you think you'll have time to fix the perl bugs in the subunit bugtracker over the next weekish ?
<jelmer> lifeless: Not sure, I'm a bit short on time at the moment having just come back from 4 weeks of travel
<lifeless> ok
 * SamB *still* wants DWARF frame info in subvertpy
<lifeless> jelmer: have you written perl output bindings at this stage?
#bzr 2009-08-02
 * amanica thinks I should make the log-lowerbound-exclusivity change at the highest level possble, so that I break less stuff?!
<ronny> hmm, http://bazaar-vcs.org/BzrVsHg is full of lies and massively outdated crap
<SamB> jelmer: hmm ... it looks like svn_ra_replay_range calls svn_ra_replay
<jelmer> SamB, in the subversion code you mean?
<SamB> jelmer: well, that's what I see here:
<SamB> (gdb) frame
<SamB> #0  0xb76dc926 in svn_ra_replay () from /usr/lib/libsvn_ra-1.so.1
<SamB> (gdb) frame 1
<SamB> #1  0xb76dd553 in svn_ra_replay_range () from /usr/lib/libsvn_ra-1.so.1
<SamB> (gdb) frame 2
<SamB> #2  0xb76ef673 in ra_replay_range (self=0x8a7f770, args=0x8a7fd4c)
<SamB>     at subvertpy/_ra.c:1240
<SamB> it might not always happen, haven't looked at the source ...
<jelmer> SamB, That seems perfectly fine, I don't think all transports implement ra_replay_range so falling back to ra_replay in that case seems sensible
 * SamB looks at code now ...
<SamB> jelmer: hmm, yeah, that does seem to be a fallback
<SamB> huh, how would I run a testcase but break into pdb when it fails ?
<spiv> SamB: there's no command line option for that, we really ought to add one.
<spiv> SamB: insert "import pdb; pdb.set_trace()" into your test case by hand :/
<abeaumont> hmmm, i'm wondering, any chance that bzr-git + git-svn works better than bzr-svn for large repos?
<AfC> abeaumont: I seriously doubt it
<abeaumont> i see
<AfC> I put "parent_branch = file:///home/andrew/src/quill/mainline/" into .bzr/branch/branch.conf, but `bzr info` isn't reporting that as the parent branch. Any idea what's up with that?
<LarstiQ> AfC: parent_location iirc
<AfC> LarstiQ: ah.
<AfC> LarstiQ: yeah, that did it. Thanks.
<AfC> (why, oh why)
<LarstiQ> why it worked? ;)
<AfC> LarstiQ: no... why on earth a file that we force users to edit would have an asymmetrical naming pattern for things.
<AfC> LarstiQ: submit_branch:
<AfC> LarstiQ: parent_branch: would therefore make sense
<AfC> but no
<LarstiQ> AfC: I agree there is some consistency to be had, but I don't agree with user editing of branch.conf
<AfC> LarstiQ: is there a UI for setting locations now?
<AfC> (if I've missed something new and shiny, then I do apologize)
<LarstiQ> AfC: not as it should be, specifically parent though, `bzr pull --remember`
<ElMonkey> hola
<ElMonkey> anyone happen to know if i can get files from bzr repo A into bzr repo B without making B a branch of A, while preserving file history?
<ElMonkey> eg, i just want to pull out a specific subset of files from a repo to use in another project
<fullermd> No, files are in history, not the other way around.
<fullermd> (and in bzr terms, you probably mean 'branch' rather than 'repo')
<ElMonkey> hmm
<ElMonkey> there's no fairly doable workaround, i presume?
<fullermd> You can sweet-talk it into using the same file-id's, which would make merging work, but that doesn't sound anything like what you'd want.
<LarstiQ> ElMonkey: can you explain more fully what you are trying to solve?
<fullermd> There are various ways one can go about rewriting a branch to create new, unrelated history that looks similar to the existing history.
<fullermd> But you can't turn existing revisions into different content; that goes against the idea of history.
<ElMonkey> well, its like this: i have a mac app, and i am porting it to the iphone
<ElMonkey> now the mac app is older, and there's already an iphone scaffold in place from another app
<ElMonkey> and now i'd like to load the relevant pieces of the mac app onto the iphone template
<LarstiQ> and you want to keep the history of the iphone template?
<ElMonkey> i'd like to keep the history of both :)
<LarstiQ> I'd value the mac app more than the template
<LarstiQ> ElMonkey: you could `bzr merge -r 0..-1` them together
<ElMonkey> hmm
<ElMonkey> well, thanks for the input, i'll have to think some more about how to do this :)
<LarstiQ> ElMonkey: tried the merge command?
<LarstiQ> ElMonkey: keeping histories/files of two branches is way easier than selectively transplanting some files
<ElMonkey> LarstiQ, no, i havent tried it yet
<ElMonkey> i think i have to adjust the directory structures a bit before i can
<LarstiQ> ElMonkey: for best effect, likely. You can try and revert to see what happens before that though :)
 * SamB wonders why he thought there were no failures with the replay code enabled ...
<SamB> hmm ... 2a seems slow via HTTP, at least when samba.org is involved ...
<LarstiQ> SamB: if -Dhpss shows a million requests, that would be why
<SamB> actually, it just seems to be doing far too much computing
<LarstiQ> SamB: there are a couple of bugs about poor http 2a performance at least
<SamB> or, wait, samba.org doesn't have a smart server anyway I think
<SamB> at least not people.samba.org
<SamB> but -Dhttp doesn't seem to indicate that it's the making of many HTTP requests that is the issue
<SamB> since I'm seeing a lot of BIG gaps between bzr recieving one response and sending the next request ...
<SamB> which agrees with my bandwidth meter
<SamB> hmm ... there is always a chance that my actual problem is that it's doing a lousy job in reporting it's progress ...
<pigmej2> hey
<GungaDin> How do I tell bzr diff to show only the names of the files that have changed and not the contents?
<LeoNerd> Try   bzr st
<GungaDin> thx
#bzr 2010-08-02
<GungaDin> how can I know when was the last time a line in a file changed?
<GungaDin> I tried bzr blame.. but not sure how ot access the revision I see
<lifeless> bzr log -r 12.34.56
<GungaDin> it says it wasn't in the branch
<GungaDin> sorry, my mistake
<Vornicus> How portable is a bzr repository?  If I create one on a flash drive, will it work on multiple computers and multiple platforms?
<lifeless> it should
<lifeless> we try pretty hard to make it portable
<Vornicus> Yay!
<spm> lifeless: huh, that's a cool achievement! the old 32bit machine vs 64bit machine (tho usually for me it was also x86 to sparc) shifting on 'binary' formats is a pita
<lifeless> spm: because we work directly over the network on FTP, we're basically lowest common denominator across the board.
<spm> sweet
<lifeless> only thing likely to cause any issue is symlinks, which are different on different OS's.
<lifeless> but we don't use them internally, its only if the project has one
<spm> nod
<Vornicus> And since my project already needs to deploy on several devices and I'm building it on the flash drive, I don't think that issue will arise.
<bialix> hello bzr
 * fullermd waves at bialix.
<bialix> heya fullermd !~
<jjann> Hey. Is there a way to easily restore some (deleted) files/directories from an older revision using the gui? I tried bzr qbrowse, which is very nice to browse the older revision but I'm a bit stumped that on right-click on a folder I don't get anything like "restore"
<jjann> also, waht's the easiest/best way to query for something like "what is the latest revision that still had path/to/file?"?
<jelmer> hi jjann
<jelmer> jjann: I generally just use "bzr log | less" and then search for the filename.
<jjann> I need log -v for the filenames to be shown but ok, using the pager's search feature is quite alright, thanks
<jjann> although, I also have the use case of "what's the last revision in which $file still contained $some_string?"
<jjann> mercurial had 'hg grep' for that
<jjann> (I don't want to play the "hg is better" card, I wouldn't have switched if I thought that, just mentioned it to maybe help others understand what kind of functionality I'm looking for)
<LeoNerd> I believe you can just   bzr log [filename]  can you not..?
<jjann> LeoNerd: that doesn't help as it doesn't print the contents of the files, even with -v (also, $file might not exactly been known, sometimes I used hg grep for cases like "there has been some function called 'foo' at some point in some file, I want it back now")
<LeoNerd> Oh... if you want the contents of the file you can  bzr cat   it
<LeoNerd> bzr cat -r123 path/to/file  >path/to/file
<jjann> well, then I'd need to know the revision to cat.. :)
<LeoNerd> Which is what  log   would have given you
<jjann> as I said, I want to find the latest revision that still contained the string 'foo'
<LeoNerd> Ahh
<LeoNerd> Could you somehow bisect it?
<jjann> sure, I could script that using cat and for loop
<LeoNerd> bzr bisect   I mean
<jjann> but I was really hoping for something nice, I mean, isn't using a VCS for restoring old content kind of a major use case?
<LeoNerd> Oh indeed...
<jjann> where are all the tools to support that? ;)
<LeoNerd> *shrug* Where's the tool to find the last revision where a prime number of files all contained a square number of lines in them? I suspect in practice relatively few people have ever had to ask such a question
<bialix> jjann: grep plugin may help you, IMO
<jjann> well, my case is quite a bit more general than that
<jjann> bialix: if it does something like hg grep, it will be perfect, I'll look it up. thanks
<bialix> grep plugin searching in the history
<jjann> should have looked for a plugin to begin with, still not used to so much functionality being in plugins coming from other systems
<bialix> jjann: https://launchpad.net/bzr-grep
<jjann> yep, it pretty much exactly does what hg grep does. yay. :)
<LeoNerd> bzr is very plugin-friendly... A lot of plugin devs write lots of interesting tools
<jjann> LeoNerd: yeah, that I'm used to from mercurial. the difference with bzr is that quite a few things that are builtin with most other systems I've used are plugins too, just takes some getting used to as I have to start looking for plugins earlier instead of spending too much time searching for the functionality I want in bzr core
<LeoNerd> I tend to view it differently... Don't look at it as useful core + random addons... It's more a case of "here's a universe of all the possible things, but here is a small bootstrapping core of essentials; feel free to expand it"
<bialix> jjann: bzr core already has many many features
<jjann> quit being so deffensive, I already like bzr. :)  It is just a difference, no judgement. bzr does have fewer features in its basic distribution than other systems. it's not even hard to argue that this is an advantage as then all these features can be developed and released independently. :)
<jjann> I was simply noting that I didn't think to look for grep as a plugin as I'm not that used to that difference :)
<jave> hello
<jave> I'm using the bzr plugin with hudson to build emacs, and I'm finding it fairly flaky
<jave> how can I reduce the bzr issues I get?
<jave> I get "locked" issues
<jelmer> jave: Hi
<jelmer> jave: Can you be more specific about the errors?
<jave> here is one type of error
<jave> bzr: ERROR: Could not acquire lock "LockDir(file:///var/lib/hudson/jobs/emacs-trunk/workspace/.bzr/branch/lock)":
<jave>  
<jave> the problem is that it happens randomly.
<jave> can you suggest some workaround so I at least get consistent builds?
<jave> can I just remove the "held" file in the lock dir?
<jave> heres another type of error:
<jave> ,----
<jave> | Started by user hudson
<jave> | $ bzr revision-info -d /var/lib/hudson/jobs/emacs-trunk/workspace
<jave> | [workspace] $ bzr pull --overwrite http://bzr.savannah.gnu.org/r/emacs/trunk
<jave> | http://bzr.savannah.gnu.org/r/emacs/trunk is permanently redirected to http://bzr.savannah.gnu.org/r/emacs/trunk/
<jave> | We expected 214886 entries, but created 214885
<jave> | ERROR: Failed to pull
<jave> | Getting local revision...
<jave> | $ bzr revision-info -d /var/lib/hudson/jobs/emacs-trunk/workspace
<jave> | null
<jave> | Finished: FAILURE
<jave> `----
<jave>  
 * Toksyuryel bops jave over the head with pastebin
<jave> oops
<jave> sorry
<jave> heres the pastebin link then, for completeness
<jave> http://emacs.pastebin.com/cBZv4HwC
<gerard_> http://vi.pastebin.com/qmuT2CXD ;)
<jelmer> jave: You have two instances of bzr trying to access the same branch at once
<jave> not according to ps
<jelmer> jam might be able to look more closely into the issue when he joins
<jave> just to cliarify, I'm trying to set up a hudson buildserver for emacs, and I want the bzr polling and building to be very reliable
<jave> I can of course to occasional cleanup operations, but I rather wouldnt
<jelmer> jave: Of course
<domas> can I import another bzr branch as a subdirectory to my "umbrella" bzr branch?
<domas> hmm, bzr merge-into?
<rubbs> domas: I'm assuming you're looking for something similar to svn-externals?
<rubbs> you should lookinto bzr colocated branches and possibly bzr-scm
<rubbs> I'll see if I can dig up links for you
<domas> was looking something like merge-into
<domas> this is one-time action
<rubbs> oh, I c
<rubbs> so, just to clarify, you have a branch and you want to import another branch in as a subdirectory within the first branch. Am I understanding this right?
<domas> yes
<rubbs> do you still want them to have separate histories? or just to merge the histories once and continue on as one project?
<domas> merge histories once and continue as one project
<rubbs> k. let me think a little on that. I'm sure it's possible, I just haven't done it yet.
<seanh> I've heard bzr has a nice diff utility. Is it possible to use it to diff two files? (not in a bzr repository) If so, where can I find the command?
<rubbs> domas: I'm not sure if there is an easier way, but you could in the "subdirectory" branch, create a directory under the root with the name you want the subdir to be and then move all the files in that subdir. Then commit, and then try to merge the two projects together. If I'm understanding this correct, you would then merge in the "new" folder into the umbrella branch.
<rubbs> if any of that doesn't work you can use uncommit
<rubbs> seanh: I'm not sure, but bzr help diff says something about --using
<domas> rubbs: I just lost histories, nobody cares about them
<rubbs> I've got a meeting, but I'll be back in a bit. someone else may be able to help too.
<domas> :)
<rubbs> domas: oh, ok
<domas> it wasn't that important to preserve them
<domas> only me worked on that sub-project yet :)
<domas> thanks for assistance though!
<seanh> Apparently something to do with python bzrlib/patiencediff.py, but I can't find patiencediff.py on my system. Might have to checkout the bzr source
<seanh> Hmm, no, bzr is installed, I just don't know how to find the damn file
<mgz> seanh: `python -m bzrlib.patiencediff -h` ?
<seanh> Yes! Thanks mgz
<seanh> diff was giving completely f*cking useless output on some simple config files and making life suck, this works!
<GaryvdM> Hi all!
<GaryvdM> jam: Please could you turn on the ec2 machine. I would like to another build.
<jam> GaryvdM: spinning it up now. probably takes ~10min to start
<GaryvdM> jam: Ok thanks.
 * jelmer waves to GaryvdM, jam
<jam> morning jelmer
<GaryvdM> Hi jelmer
<mgz> jelmer: quick question re 587074
<mgz> +bug
<jelmer> hi mgz
<jelmer> bug 587074 ?
<ubot5> Launchpad bug 587074 in Bazaar Git Plugin "Branching tree with non-ascii filenames fails (affected: 1, heat: 6)" [Medium,Fix committed] https://launchpad.net/bugs/587074
<mgz> I take it rev 984 only fixes the utf-8 case?
<jelmer> mgz: sure, what about it?
<mgz> as you don't seem to have touched the other path.
<mgz> do you want a child bug spun up on the other issue with nix any-bytes-will-do repos?
<jelmer> mgz: I'm not sure I follow. what do you mean by the other issue?
<jelmer> mgz: supporting non-utf8 characters in paths imported from git?
<mgz> well, what happens if .decode("utf8") fails. yeah.
<jelmer> mgz: If you have suggestions as to how we should handle that...
<mgz> well, a nice error explaining the problem might be step one :) (but yup, a sensible end solution is not easy to devise)
<jelmer> we have no way of knowing the encoding for sure, and since we need to have a deterministic way of handling these situations, I think we should not support non-utf8 paths at all.
<jelmer> Having a better error message would be nice, indeed. Bug reports and patches welcome :-)
<mgz> okay, I'll spin one off.
<jam> jelmer: .decode('utf-8').decode('latin-1') is a fairly common solution, as long as it is done consistently
<jam> but yeah, avoiding the temptation to guess for now is probably reasonable
<jelmer> jam: The problem with falling back to latin-1 is that I need to have a way of reconstructing the original bytestring
<jam> ah
<mgz> 's similar to problems with checking out bzr repos onto filesystems with smaller idea of what a valid name is
<mgz> need some kind of rename, but not mess up the repo for everyone else when pushing
<GaryvdM> jam: We need to upgrade paramiko, as version we are currently packaging gives off hashlib DeprecationWarnings. I'm going to try make the scripts pull a set verison using buildout, rather than us the installed version.
<jam> GaryvdM: is there a properly fixed version of paramiko?
<jam> The other option is to hack pycrypto, which we've done in the past
<jam> I agree using a script version would be nice, I don't think it is easy to do.
<GaryvdM> jam: Oh - I just assumed there is a fixed version. I'll check...
<mgz> seems like there's no release since 2009
<mgz> there's also http://www.lag.net/pipermail/paramiko/2010-May/001303.html
<mgz> did andrew do a ppa or something?
<GaryvdM> I'm busy looking at the ubuntu package to see if it is patched..
<GaryvdM> I'm confused now. How dose pycrypto relate to paramiko? alternates, or is the one dependent on the other.
<GaryvdM> ah - paramiko depends on pycrypto...
<jam> GaryvdM: right, paramiko uses pycrypto to do all of the actual encryption-on-the-wire
<GaryvdM> jam: Right. I was going to ask you where the patch version is, but It's better if I do a clean room patch so that I can submit it.
<GaryvdM> http://www.dlitz.net/software/pycrypto/submission-requirements/
<jam> GaryvdM: well, I think you actually need to patch paramiko if you want something that you can submit
<GaryvdM> They only accept non US submissions
<jam> pycrypto chose to deprecate (verbosely) an old api
<jam> I believe there is a new one you can use
<GaryvdM> Oh - ok..
<jam> robey hasn't seemed very interested in maintaining paramiko, though I'll also note it switched hosting to git+github
<jam> http://github.com/robey/paramiko
<jam> shows that there is *some* activity, not sure why there isn't a new release which is compatible with the new pycrypto
<jam> there was a bit of a chicken-and-egg since we couldn't have paramiko use the new functionality, until pycrypto released it
<jam> and then the question is, does paramiko then *require* the new pycrypto
<Larsigoreng> Hi, is ther somebody online able to help me with a (hopefully) simple question? I want to go back in history to version 1 of my files, but I am lost in the meanings of all the words revert, uncommit etc.
<GaryvdM> Larsigoreng: Do you want to commit the old version into the history permantly, to just go back to the old version temporaly?
<Larsigoreng> anyone alive in here? :)
<Larsigoreng> Hi GaryvdM! I have old versions of configuration files. I changed these files, committed them...
<Larsigoreng> and fpound out that these changes are no good. So I want to revert that
<GaryvdM> bla - sorry Larsigoreng. I press ctrl q by mistake
<Larsigoreng> and fpound out that these changes are no good. So I want to revert these changes and this committing
<Larsigoreng> no prob. You got my story?
<GaryvdM> Larsigoreng: yes
<GaryvdM> Larsigoreng: Is this in the last revision, or a couple of revisions back?
<Larsigoreng> So, to be honest, I don't understand your question in the necessary details.
<Larsigoreng> there is revision 2 with the new versions
<Larsigoreng> and revision 1 with the old versions
<Larsigoreng> I want revision 1 to reappear
<GaryvdM> Larsigoreng: The easy answer is to do a revert + commit
<GaryvdM> and the safest...
<Larsigoreng> bzr revert -r 2    ; bzr commit   ?
<GaryvdM> yes
<GaryvdM> or bzr revert FILE -r 2
<Larsigoreng> there is not yet a change before I do the bzr commit?
<Larsigoreng> Â´cos I did the revert already, but np commit
<GaryvdM> Larsigoreng: There should be
<GaryvdM> oh .. wait
<GaryvdM> Larsigoreng: bzr revert -r 1
<GaryvdM> -r 2 = the current version
<GaryvdM> you want to go back to -r 1
<Larsigoreng> okay! So -r 1 is the target-version?
<GaryvdM> Larsigoreng: Yes
<Larsigoreng> (and not the version I want to revert) Oh then I misunderstood the manual! Let me try!
<Larsigoreng> okay, that looks good. So I reverted it back to version one, and when I committed it, it says this is now version 3.
<Larsigoreng> version = revision
 * Larsigoreng has to do a lot of learning...
<GaryvdM> Larsigoreng: So you build a better understanding: revert + commit will show in the history (which may or may not be a good thing.)
<Larsigoreng> *puh* thank you very much, GaryvdM
<GaryvdM> Larsigoreng: uncommit + revert won't show in the history, but will cause problems  for any body else who has a copy, so only use uncommit if you have not pushed.
<Larsigoreng> "will show in the history" = is logged and anyone interested in that can find out about that?
<GaryvdM> Larsigoreng: Yes
<GaryvdM> Larsigoreng: run bzr log to see
<Larsigoreng> GaryvdM: sorry, I accidentally pressed CTRL+W... ;)
<jam> jelmer: meliae-0.3.0 is released with a tag and a tarball uploaded, can you package it?
<jelmer> 0.3.0 \o/
<Larsigoreng> GaryvdM: Thank you very much, you saved my evening!
<GaryvdM> Larsigoreng: Glad I could help :-)
<jelmer> jam: sure
 * Larsigoreng waves goodbye.
<GaryvdM> jam: How are you using meliae to debug gcc if gcc is in c?
<jelmer> GaryvdM: I think he means the gcc branch :-)
<GaryvdM> Oh - I see...
<GaryvdM> lol
<GaryvdM> Hmm - having to use git. I'm finding gitk a bit lacking.
<GaryvdM> Maybe it's just because I expect gui's to behave ..
 * GaryvdM must not be prejudice...
<GaryvdM> jam: We are packaging pycrypto 2.0.1, and 2.1.0 is out, which claims to add python 2.6 support. May I install 2.1.0
<jam> GaryvdM: 2.1.0 adds different deprecation warnings, but you can use it if you want
<jam> 2.0.1 gives the hashlib warnings
<jam> 2.1.0 gives paramiko RandPool warnings
<GaryvdM> Ok - I see :-(
<jam> *1* of the reasons we stayed with 2.5 for so long
<GaryvdM> Do you think I will be a lot of work for me to patch paramiko?
<jam> GaryvdM: I don't *think* it would be a huge amount, but it is enough that nobody has done it yet...
<jam> I don't know why robey hasn't updated, for example
 * GaryvdM dives in...
<GaryvdM> jam: Please will you shut down the ec2 machine. I'm done for now.
<jam> k
<jam> will do
<jam> GaryvdM: if you are going to use it, say, tomorrow, I'll leave it for you
<jam> but if you are done for a while, I'll shut it down
<jam> (especially given the TZ differences and my desire to be asleep when you wake up :)
<GaryvdM> jam: I work on bzr in the same tz as you (after work)
<GaryvdM> jam: Expect last week when I was on leave
<jam> up to you. It is nice to shut it down, but I know it adds a fair amount of startup overhead for you to get your stuff done
<GaryvdM> jam: I'll want to do a release when I have a paramiko/pycrypto solution, or when the next release comes out...
<GaryvdM> s/release/installer build
<jam> sure. probably later this week. I think it was actually targetted for the end of last week.
<jelmer> jam: Any chance I could get you to take a brief look at lp:~jelmer/bzr/controldir, to check if what I'm doing is vaguely reasonable ?
<GaryvdM> jam: deadline is 12 Aug. Maverick feature freeze...
<GaryvdM> Next week Thursday.
<jelmer> jam: (in-progress MP here: https://code.edge.launchpad.net/~jelmer/bzr/controldir/+merge/31573)
<jam> jelmer: I think you accidentally submitted this for review 2x, or maybe you just directly requested my review?
<jelmer> jam: I submitted it for review earlier as well but removed that MP
<jam> jelmer: ah, different numbers, but 2 emails about review, anyway looking
<jelmer> jam: Thanks. I'm basically splitting ControlDirFormat and "Prober" out of BzrDirFormat
<jam> jelmer: changing bzrdir.sprout is going to break a *lot* of tests
<jelmer> jam: I haven't changed it, just moved it to the new base class of BzrDir.
<jam> jelmer: it seems ok, but at this point it is just moving code around, so I'd have to understand your rationale of why you want it moved
<jelmer> jam: Mainly I'm looking at running some of the tests that currently live in per_bzrdir only against BzrDir instances and not against other ControlDir instances.
<jelmer> jam: The reason for splitting out Prober is so that we can add more advanced probing mechanisms later. SvnProber would never need to recurse down - if the current directory doesn't have a .svn/ control directory then the parent won't either. Or we can do probing based on the reply of the OPTIONS HTTP request, etc.
<jelmer> jam: And in general just cleaning up the distinction between the API and Bazaar-specific stuff.
<jam> GaryvdM: I submitted your bzrw patch
<GaryvdM> jam: Thanks
<jam> GaryvdM: however, i get a text conflict in NEWS
<GaryvdM> jam: I'll fix.
<jam> jelmer: I like the concept of splitting things up a bit. BzrDir is a rather large interface ATM.
<GaryvdM> jam: Done.
<jam> GaryvdM: submitted
<GaryvdM> Thanks.
<jelmer> jam: So, did you manage to find the issue with lp:gcc?
<jam> jelmer: it is a few issues, the original post is sort of long
<jam> but basically, 150+MB is from loading the whole chk index (.cix)
<jam> and then about as much memory is in the actual chk maps themselves
<jam> and about 50M in the dirstate
<jam> some of that we can shrink easily, some not very easily at all
<jam> cix stuff...
<jam> the gcc-linaro code is large enough to cover 50k chk pages
<jam> because .cix is content addressed, the sha hashes spread that evenly over the whole index
<jam> so while there are >700k entries, we fit 100 per block, so there are only 7k blocks
<jam> so to read 50k evenly spaced we have to read *all* 7k
<jam> I don't have great answers here other than a) custom data structure that is more compact, b) new index for .cix (which I've described some possibilities before)
<jam> but that is a disk-format change
<cwr> hi
<jelmer> hi
<cwr> I'am trying to pull new revisions from a repo hosted on sf.net to my laptop. unfortunately i get this error message
<cwr> http://pastebin.org/442651
<cwr> am i doing something wrong?
<jelmer> are you trying to pull into a branch that is bound to another (readonly) branch perhaps?
<cwr> hmm, not so sure about that. it is bound to a different branch, yes. I used a second branch to commit experimental changes and want to pull them on my laptop now
<jelmer> cwr: In that case, you should unbind the branch first
<jelmer> cwr: it wants to keep the remote ("master") branch up to date but is failing when trying to put the revisions you're pulling in there.
<cwr> ok, did what you said and it is working. nice thank you!!
<jelmer> lifeless: Hi
<lifeless> hi
<GaryvdM> jam: Patched paramiko: http://github.com/garyvdm/paramiko
<jelmer> lifeless: Thanks for having a look at my controldir branch. To answer your question, the only reason I didn't use ControlComponent as baseclass for ControlDir was that not all ControlDirs would have a ControlTransport that is accessible.
<GaryvdM> I'm off to bed now.
<lifeless> jelmer: so, the contract that Martin introduced with ControlTransport is that they will have.
<lifeless> jelmer: or many bzr commands will go boom, AIUI.
<jelmer> lifeless: what about e.g. git branches that are basically files on disk or an entry in a dictionary?
<jelmer> poolie: Hi
<jelmer> Perhaps control_url and user_url can be mandatory but control_transport and user_transport optional?
<lifeless> jelmer: they still have a conceptual url (;branch=xxx), and where there is a url there is a transport
<lifeless> jelmer: but, controldir is the .git dir, not the branch object *anyway* so that seems an unrelated question
<jelmer> lifeless: A similar argument applies to e.g. remote git servers though
<lifeless> jelmer: it seems pretty weak; git: transports can in principle exist
<jelmer> lifeless: In that case we have only one transport that basically only provides a method for getting a Git smart server client.
<lifeless> jelmer: a command that prints branch.bzrdir.user_transport, should still do something sensible there.
<lifeless> no?
<jelmer> lifeless: I don't particularly see why it needs user_transport rather than user_url.
<jelmer> I can of course provide two dummy stubs for Git that just implement Transport.base, but I'd like to understand why that extra code is necessary.
<lifeless> jelmer: consistency of interface is the argument I'd use
<lifeless> or rather
<lifeless> controltransport is meant to be a base for all these things.
<lifeless> please either refine it appropriately, or meet the contract - I don't have an opinion as to which is better.
<jelmer> lifeless: s/ControlTransport/ControlComponent/ ?
<lifeless> *I* consider transport == url in all regards
<jelmer> ControlComponent has both control_transport/user_transport and control_url/user_url properties
<lifeless> so if I was doing the work, I would probably drop the _url attributes and use the transport ones only, but thats me.
<jelmer> poolie: ping
<poolie> jelmer: hi! i'm on the phone at the moment
<jelmer> poolie: Ah, ok
<jelmer> lifeless: Anyway, you make a good point. I'll derive ControlDir from ControlComponent.
<lifeless> jelmer: thanks!
<maxb> Is anyone else experiencing lp:bzr/2.2 not clearing its progress displays from the terminal properly?
#bzr 2010-08-03
<spiv> Good morning.
<poolie> jelmer: hi?
<poolie> spiv, hi
<bendj> I've setup bzr on a box that's behind a fairly tight firewall. I thought bzr+ssh:// just needs port22 access -- apparently not sufficient.  Are the required ports doc'd somewhere?  I'm digging, not finding :-/
<mwhudson> bendj: it should just require 22
<bendj> mwhudson: Hm.  getting, "ssh: connect to host bazaar.launchpad.net port 22: Connection timed out.  bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. "
<bendj> 'normal ssh' from the box works fine.
<bendj> gremlins.  sigh ...
<mwhudson> bendj: can you run 'ssh bazaar.launchpad.net' from the command line?
<bendj> mwhudson: I get "No shells on this server. Connection to bazaar.launchpad.net closed."
<mwhudson> ok that's good
<mwhudson> bendj: if you look in the ~/.bzr.log file i think you'll see the command line bzr is launching ssh wiht
<mwhudson> *with
<mwhudson> maybe there's something obviously funny in there
<bendj> mwhudson: hm.  that's full of non-ascii garbage.  not good.  uninstall/rebuild/reinstall, i s'pose?
<mwhudson> bendj: what platform/bzr version?
<mwhudson> bendj: maybe just delete .bzr.log to start with
<bendj> opensuse 11.3, x86_64, Bazaar (bzr) 2.3.0dev1 (r5361)
<bendj> mwhudson: hey, deleting the log file wokred!
<bendj> er, worked
<bendj> 1st time i've seen that :-|
<mwhudson> odd
<bendj> thx!
<bendj> tt4n
<mtaylor> is there anyway to tell where the bzr twisted impl of ssh is going to look for ssh keys?
 * mtaylor is battling a windows machine at the moment
<poolie> mtaylor: i think it prefers to look in the putty agent "pageant" if that's installed
<poolie> i don't know of a way to say "what directory are you looking in" beyond boking into the source
<mtaylor> poolie: nevermind actually - the wiki saved me
<mtaylor> poolie: http://wiki.bazaar.canonical.com/Bzr_and_SSH ... it llooks in %USERPROFILE% apparently
<spiv> mtaylor: actually, bzr doesn't use a Twisted client for SSH, I think that's a paramiko bug (it logs the server's name as the client's)
<mtaylor> spiv: hehe
<spiv> I guess because paramiko uses the same class for the client and server, but didn't parameterise that bit of the logging...
<spiv> (I just filed a bug on paramiko about it.)
<cwr> hi
<lokkju> .join #dorkbotpdx
<lokkju> oops
<cwr> i created a new user and tried to push a new revision to a existing branch. unfortunately i get this error
<cwr> http://pastebin.org/444166
<cwr> creating a new branch on the server is no problem, so the new user has write permissions
<fullermd> Having permissions to write a new branch doesn't mean they have write permissions in the existing branch.
<cwr> was it the wrong to just commit the changes? do i have to do something like merge?
<cwr> fullermd: how can I give a user permissions to write to an existing branch?
 * fullermd shrugs.
<fullermd> chmod as appropriate.
<fullermd> As a first approximation, whatever perms are up a level that let the user create a new branch.
 * spiv is done for the day
<knittl> what data model uses bzr to store history? i.e. how is history recorded, and _what_ is recorded?
<knittl> git uses commit/tree/blob, mercurial uses revlogs (changelog, manifest, filelog)
<LeoNerd> I'm not sure the question makes much sense...
<LeoNerd> bzr has its own names for these things, yes... but that doesn't really help answer the question
<knittl> LeoNerd: i wasn't able to find documentation for this in bzr terms
<knittl> and git and hg were just given to have examples, it's not easy to describe what i want
<LeoNerd> bzr branches contain revisions... if that answers your question?
<ddaa> you want a description of the models and datastructure used in the current achive format?
<knittl> no, it doesn't
<knittl> ddaa: yes!
<ddaa> I'm not familiar enough to give a good answer, but I know it would be pretty long.
<knittl> i take pointers to documentation
<ddaa> First, unlike git, and probably hg, bzr has a layered design.
<knittl> but i wasn't able to find proper docs
<knittl> not even in bzr.bzr/docs/developers/â¦
<ddaa> There's a model layer, that deals with trees, branches, repositories, revisions, bzrdir, file revisions, etc.
<knittl> i'm interested in how revisions go together with trees and files
<ddaa> and there are various transport/storage layers that translate that into actual storage/protocols
<ddaa> those involve things like indexes, packs, weaves, etc.
<ddaa> Then there is the tree format, with things like dirstate.
<ddaa> all those things are pretty much orthogonal
<ddaa> and most have multiple implementations
<ddaa> mostly historical
<knittl> let me try explain what i want :D
<knittl> if i do bzr commit (locally)
<ddaa> knitti, on the model level, a revision has some commit information, and an inventory
<knittl> inventory = tree?
<ddaa> an inventory is a tree-like model that maps file ids to names, parent ids, and file revisons.
<knittl> but i'm really wondering why there is no documentation?
<ddaa> (and probably a number of other metadata)
<knittl> where/how are files stored?
<ddaa> The repository is a model that (among other things) store file contents addressed by file revision ids.
<ddaa> (other things include commit/revisions, inventories, and metadata such as tags)
<knittl> why is there no documentation?
<ddaa> probably because nobody has bothered to write it.
<ddaa> Also, the source code is relatively well document.
<ddaa> documented
<bialix> there is documentation on repository storage format
<bialix> when packs was introduced
<knittl> bialix: where?
<ddaa> bialix: I think he's more interested in the API model than in a specific storage format.
<bialix> in docs/developers/
<ddaa> the latter is not going to help much without the former, anyway.
<bialix> ah
<knittl> ddaa: no, i'm not interested in api
<bialix> then, there is no docs because all devs have this knowledge implanted in their brains?
<knittl> bialix: yes, it seems so
<ddaa> well, if you are interested in "the bzr storage format", know that there are number of them, and it's subject to change.
<ddaa> why would you want to access the on-disk storage format w/o bzrlib anyway?
<ddaa> That's an actual question.
<bialix> I would like to
<knittl> i know bzr changes format quite often, but i'm only interested in the current implementation/format
<bialix> 2a?
<lifeless> knittl: it doesn't change much at all
<knittl> and i don't want to access it, i am comparing various dvcss
<knittl> write about advantages/disadvantages
<ddaa> lifeless knows everything
<bialix> heh
<lifeless> knittl: the formats are documented in bzrlib.repofmts.*
<knittl> and that includes describing on-disk storage format and relations between different types of objects
<lifeless> knittl: yes and no
<lifeless> relations are covered by the model stuff ddaa spoke about
<bialix> knittl: and what it will say?
<lifeless> on disk format for individual things is determined by the classes the repo format uses - e.g. btree vs a linear index vs no index
<lifeless> what you are asking is kind of like asking 'what is the drizzle disk format'
<lifeless> where the answer is 'well, it depends. What plugin are you using?'
<lifeless> (or the mysql, or the postgresql, or oracle etc)
<knittl> let my try again â¦
 * ddaa gestures over at the svn repository format
<knittl> git hashes every object
<knittl> commit points to tree, tree points to trees and blobs
<knittl> every object is stored in .git/objects/xx/xxxxxâ¦
<lifeless> well you were right up to the last point
<ddaa> knitti wants to know how the bzr2 repository stores commits and trees, specifically
<lifeless> when you become wrong.
<knittl> where xx/xxxxxâ¦ is the sha1
<knittl> hg has changelog, manifest and filelog (all a form of revlog)
<lifeless> you're conflating different layers
<knittl> revlog stores sha1, 2 parents, length, base revision for delta and finally id of changeset (quasi a backreference)
<knittl> so there's: 1 changelog, 1 manifest and for each file a filelog. in .hg/store/data/$filename
<ddaa> he's not really interested in all the nice layering in bzrlib, just in the current storage strategy
<lifeless> git has an object model and a storage model; the object model uses hashes as keys and has commit, tree and blob object types (and more these days). The storage model can have loose objects or packed objects, and they are indexed either by fs path or by a page based index.
<knittl> is it really so much i'm asking for or am i being uncleaar what i actually want?
<lifeless> ddaa: I can see that, but he is confusing him self by analysing two wholly independent layers as one. So when we answer either question, we get told we're answering the wrong thing.
<knittl> lifeless: i'm more interested in the object model (references between types)
<knittl> but storage is also important. and storage models change often in bzr
<lifeless> knittl: bzr object model has commit -> inventory -> blobs
<knittl> weave, knitpack, etc.
<lifeless> knittl: and commit -> signature
<bialix> knittl: maybe this helps: http://doc.bazaar.canonical.com/bzr.2.1/developers/packrepo.html#technical-notes
<lifeless> knittl: this is documented in the developer docs in the very entry point under 'basic concepts' or something like that.
<knittl> lifeless: i've read that page
<knittl> what i took from it so far: knitpack is superior to older formats
<lifeless> knittl: I think you're answering bialix
<knittl> hm?
<lifeless> http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html - 'core concepts'
<lifeless> bah, 'core classes'
<knittl> i think i can only understand on-disk after i've fully understood object model
<knittl> core classes are workingtree/branch/repository?
<knittl> where's commit? where are blobs?
<lifeless> yeah, there is less there than I thought :) its handwaved at under repository
<lifeless> sorry
<bialix> knittl: there is no "blobs" in your understanding
<bialix> you're using wrong terms
<knittl> bialix: 11:24 < lifeless> knittl: bzr object model has commit -> inventory -> blobs
<bialix> okay, but we call them differently
<bialix> commit is revision object
<bialix> blobs are file objects
<bialix> something like that
<knittl> (also there is a formatting issue on that page: the list under repository)
<knittl> bialix: ok, revision. i use git a lot, so i'm used to the term 'commit'
<knittl> and storage and object model go hand in hand. at least in hg and git
<knittl> *grin*
<bialix> it depends how you're looking at things
<lifeless> knittl: they don't go that hand in hand
<lifeless> knittl: google have a bigtable implementation of hg, which has _very little_ to do with the revlog implementation in the public code, from what I hear.
<lifeless> and git has multiple storage engines too (loose vs packed)
<knittl> but somewhat
<knittl> so, how are revision objects, inventory objects and file objects in bzr linked together?
<bialix> with references, of course
<knittl> and they reference what? revnos? hashes?
<bialix> [12:26]	<knittl>	bialix: 11:24 < lifeless> knittl: bzr object model has commit -> inventory -> blobs
<bialix> GUID
<knittl> bialix: yep. but how?
<knittl> guid. good
<knittl> what's that signature object you talked about earlier?
<bialix> signature? I guess you're asking about revision signature. This is gpg signature for revision object
<bialix> something similar exists in git too
<spiv> A signature's ID is the ID of the revision it is a signature of.
 * bialix bbl
<knittl> but that would mean signature -> revision
<knittl> ?
<spiv> What does the "->" denote, precisely?
<spiv> That a signature references a particular revision via the revision ID?  Yes.
<knittl> spiv: yes
<knittl> the example/explanation i was given before was Â»and revision -> signatureÂ«
<knittl> which made no sense for gpg signatures
<spiv> Well, if you have a revision, you can use it's ID to lookup the signature.
<spiv> (And perhaps find that there is no signature for that revision)
<spiv> s/it's/its/
<spiv> So, in that sense, "revision -> signature" is also correct.
<knittl> but revision has no pointer to signature id
<spiv> It has exactly as much as a pointer as signature has to revision.
<ddaa> kind of, a revision has a revision id. This one is not strictly a reference, it's an association. Like two relational tables with matching primary keys.
<knittl> revision id is stored with signature
<knittl> and signature can be looked up if revid is given
<knittl> but revision does _not_ store the id of the signature
<ddaa> yes it does, the id of the signature in the revid
<spiv> Let's say you have a revision ID 'xyz'.  You can retrieve the revision record from the repository's revisions store with the key 'xyz'.  You can also retrieve the corresponding signature from the repository's signatures store with the key 'xyz'.
<ddaa> s/in/is/
<spiv> That is to say, having the revision ID means you have the signature's ID (and vice versa).
<spiv> If you like, you can represent the keyspace for bzr's internal storage as tuples that look like (store_name, key_part_1 [, key_part_2, ...])
<knittl> revid and signature id are the same?
<ddaa> yes they are
<ddaa> different namespaces, I guess
<knittl> ok
<spiv> In that unified keyspace that revision's key would be ('revisions', 'xyz') and the signature's key would be ('signatures', 'xyz').
<spiv> Obviously it is trivial to determine one from the other.
<knittl> that means forging signatures is possible?
<spiv> No.
<knittl> or is this prevented somehow?
<ddaa> signatures are GPG signatures
<spiv> The ID of the signature is not the content of the signature.
<knittl> spiv: yes
<knittl> so how can i verify the gpg-signature is the original?
<ddaa> what do you mean by original?
<knittl> i create a new revision
<knittl> i sign it
<spiv> You have a revision.  You have a signature.  You can determine with GPG if that signature is a valid signature for the revision, and you can then decide how much you trust the signer.
<ddaa> spiv thank you
<ddaa> knitti, then I sign it too
<knittl> ok, trusting the signer. thanks spiv, makes sense
<knittl> ddaa: why do you always write knitti with an i? xD
<ddaa> knittl:because my typing skills are better than my eyesight.
<ddaa> knittl: you need to be a bit familiar with how gpg is used for this stuff to make sense. The GPG notion of "trust" is a bit peculiar.
<knittl> ddaa: i understand now
<knittl> i was only a bit confused
<knittl> public key is tricksy stuff ;)
<jelmer> poolie: pong
<bialix> spiv: ping, if you still around
<bialix> spiv: question about smart server aka `bzr serve`.
 * bialix waves at GaryvdM
<GaryvdM> Hi bialix.
<bialix> GaryvdM: thanks for bzrw
<GaryvdM> \o/
<bialix> \o/
<spiv> bialix: slightly around
<bialix> spiv: bzr serve uses port 4155 (IIRC). when client connects to this port server creates separate thread for this client, is it correct?
<bialix> if that correct does server creates new socket pair for particular client? or this is wrong question?
<bialix> I mean it won't be possible to another client re-use the previous connection and server states
<spiv> The server creates a new thread, yes.
<spiv> The server doesn't create a socket pair, it just calls accept on the listening socket, and that returns the socket object for the new connection.
<spiv> (See the Python docs for socket.listen and the accept() method of socket objects)
<spiv> Er, actually, they are both methods of socket objects, but you know what I meant I'm sure :)
<bialix> ok
<bialix> spiv: what is state of VFS calls?
<spiv> bialix: no recent changes.  They are still used by many common operations.
<bialix> ok, I wonder is it possible to create new hpss protocol version via plugin to address Bug #126911
<ubot5> Launchpad bug 126911 in Bazaar "Smart server has no built in authentication (affected: 2, heat: 34)" [Medium,Confirmed] https://launchpad.net/bugs/126911
<bialix> at least as experiment
<spiv> I'm not spending much time on improving that at the moment.  I occasionally fix one more case, but there's still lots to do...
<spiv> I think that would be possible.
<bialix> it should be fixed at client side first?
<spiv> The VFS calls?
<bialix> yes
<spiv> Well, most remaining cases need a new verb to fix, so both sides.
<bialix> verb are not documented?
<spiv> The SmartServerRequest subclasses have docstrings.
<bialix> I found network-protocol.txt and it has some gaps about requests and errors with XXX contributions welcome
<spiv> And the complete list of verbs (and what classes are used to implement them) can be seen at the bottom of bzrlib/smart/request.py
<bialix> ok
<spiv> Contributions certainly are welcome! :)
<spiv> Currently for anything not in that document the code is the best (and only) reference.
<bialix> I may try to add this to docs as part of my learning of hpss
<bialix> yes, that's right
<spiv> That would be lovely, thanks!
<bialix> request_handlers.register_lazy(
<bialix>     'Branch.set_tags_bytes', 'bzrlib.smart.branch',
<bialix>     'SmartServerBranchSetTagsBytes')
<bialix> what is the verb here? the first?
<lifeless> yes
<bialix> so idea is to have verb similar to python expression used to do the work on local objects?
<bialix> and IIUC things like request_handlers.register_lazy('list_dir', 'bzrlib.smart.vfs', 'ListDirRequest') are VFS calls
<spiv> Yes, the VFS verbs are the ones implemented in bzrlib.smart.vfs
<hrw> hi
<hrw> how to revert changeset in bzr? with git I would do "git revert REVISION" but how in bzr?
<spiv> And we do try to keep the network API matching the Python one where possible, unless there's a good reason not to.
<spiv> hrw: merge the reverse of the revision, and commit that
<spiv> "bzr help revert" mentions the recipe: 'For example, "merge . --revision -2..-3" will remove the changes introduced by -2'
<spiv> (-2 is the notation for "2nd most recent commit")
<hrw> spiv: like in cvs then
<spiv> See also "bzr uncommit".
<hrw> I want to remove HEAD~3 so uncommit is not a solution
<hrw> will export patch, revert it etc
<spiv> You don't need to export a patch.
<spiv> Simply do "bzr merge . -r -3..-4 && bzr commit"
<spiv> (Exporting a patch has basically the same effect, except it isn't as good at undoing deletes or changes to binary files)
<spiv> (Or at undoing renames of directories...)
<hrw> thx
<spiv> Huh, I think I just found a cheap way to shrink the size of inventory file instances by about 20%.
<bialix> GaryvdM: ping
<GaryvdM> bialix: Pong
<bialix> GaryvdM: I need your expertise on http://groups.google.com/group/qbzr/browse_thread/thread/af4d21e4f6cd2a79 (last mnessage)
<bialix> GaryvdM: and we need tree name for 0.19 final, something related to meerkats maybe
<GaryvdM> bialix: Looks good.
<bialix> okay, I will land it
<bialix> GaryvdM: I've decided to prepare 0.18.7, to get me in the qbzr-dev mindset
<rubbs> I'm getting this crash when trying to clone a git repo on github with bzr-git. http://pastebin.com/DMXFS1ds
<rubbs> I'm using the ppa stable version for lucid if that makes a difference
<rubbs> I can just download the source, the history isn't really that important.
<jelmer> rubbs: Hi
<jelmer> rubbs: This is a known issue, fixed in newer versions of bzr-git
<jelmer> rubbs: What PPA are you using? I don't think there is one...
<rubbs> jelmer: sorry didn't know it was fixed. I just have the bzr ppa, I guess I for some reason thought bzr-git was packaged in that, but now that I think about it, it doesn't make sense
<rubbs> I installed bzr-git with aptitude
<rubbs> I'll do a manual install with the newest git.
<jelmer> rubbs: You probably want to add this PPA that packags the latest bzr-git:
<rubbs> jelmer: awesome will do thanks.
<jelmer> https://edge.launchpad.net/~mathiaz/+archive/bzr-git
<jelmer> (well, not recent but recent enough)
<rubbs> jelmer: that worked perfectly thank you. I guess I should have googled before bothering you ;)
<jelmer> rubbs, no worries. we should proball
<jelmer> ly upload this newer version to lucid as well, but I haven't found time to do that yet.
<rubbs> understandable. I'm only barely starting to get some free time left. I am hoping to get back into helping the bzr-doc team again. I've been busy with a new job so I've had to cut back a little.
<BjornT_> i get a traceback when running 'bzr status': http://paste.ubuntu.com/472713/
<BjornT_> any idea of what's wrong?
<BjornT_> on a related note, why is the latest upload to the bzr-nightly ppa two months old, and the latest beta isn't in the bzr-beta ppa?
<BjornT_> james_w: ^^^
<maxb> They've not been very well maintained
<maxb> Maybe I should volunteer
<maxb> I'm already managing PPAs of svn and mercurial :-)
<BjornT_> maxb: that would be excellent :)
<maxb> and tortoisehg
<maxb> Then I'd just need git to complete the set
<maxb> I wonder how many people actually care about bzr-nightly - wouldn't you just run bzr from a branch?
<BjornT_> maxb: well, it's quite handy letting apt handle the updating, and being able to easily revert back to older released versions, if needed.
<BjornT_> maxb: also, not having to bother about building it properly is also a plus (considering 'make' just failed to build the C extensions :) )
<maxb> heh
<BjornT_> https://bugs.edge.launchpad.net/bzr/+bug/613066
<ubot5> Launchpad bug 613066 in Bazaar "IndexError when running bzr status (affected: 1, heat: 6)" [Undecided,New]
<Ursinha> jam, hi
<jam> hi Ursinha
<Ursinha> jam, I just submitted the mp for the bzr-pqm changes: https://code.edge.launchpad.net/~ursinha/bzr-pqm/add-noqa-incr-lpland/+merge/31703
<jam> Ursinha: I see it, and it showed up for review normally (though there are 2 review requests)
<Ursinha> jam, ah, please, ignore the first one, trigger happy here and I submitted before I should
<maxb> Anyone else using bzr 2.2 and finding it has a regression in clearing progress messages from the terminal?
<mgz> bug 611127
<ubot5> Launchpad bug 611127 in Bazaar "progress bar does not clear correctly (affected: 2, heat: 12)" [Medium,Confirmed] https://launchpad.net/bugs/611127
<maxb> ah :-/
<poolie> hi mgz, maxb
<mgz> hey poolie. just getting back to working out what breaks with python 2.7
<mrjazzcat> poolie: hey Martin.  Hope all is well with you.  Is there a trick to getting companies behind a proxied firewall to speak lp: (bzr to LP)??
<mrjazzcat> poolie: if it's documented, you could point me there.  Still haven't found it
<lifeless> mrjazzcat: http_proxy and https_proxy both need to be set, and you need bzr 2.2
<lifeless> mrjazzcat: also, if you're logged in, you need port 22 - ssh - open
<mrjazzcat> hey lifeless: thanks.  I'll go mess with that.  Yes, I was thinking it should go through ssh.  Thank you!
#bzr 2010-08-04
<poolie> doc patches welcome :)
<mgz> lifeless, bug 613247 may interest you.
<ubot5> Launchpad bug 613247 in Bazaar "TestCase instances may not be collected till selftest finishes (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/613247
<lifeless> mgz: I saw, it scared me. \o/ qa.
<mgz> should have found the time to work that one out fully ages ago, given how annoying it's been and easy it is to fix.
<mgz> ^ah, this is a special new bug filed for the underlying testing thing, rather than just the logging module related fallout
<Meths> Should bzr just work with 2.7 or only some versions?  Is there a list somewhere or compat matrix of some sort?
<mrjazzcat> lifeless: sorry to be dumb.  I updated to https://edge.launchpad.net/~bzr-beta-ppa/+archive/ppa, but it doesn't include the bzr package, so how do I get that package to 2.2?
<mgz> Meths: there are some bugs, but it's not far off working. I've got another five or so to file with bzr and/or python
<Meths> mgz: Okay, thanks.
<lifeless> mrjazzcat: I'm not sure, I'm not really up on the bzr ppa story these days.
<mrjazzcat> lifeless: makes sense.  I'd rather point this customer to a package than to source, that's all.
<lifeless> sure; spiv or poolie may have more answers
<mrjazzcat> lifeless: I see the answer.  bzr beta package is here; https://edge.launchpad.net/~bzr-nightly-ppa/+archive/ppa
<poolie> mrjazzcat: it's only in the nightly for now
<poolie> we should get it in the beta ppa soon
<mrjazzcat> poolie: hey Martin.  Got it.  Thanks.  Good luck with it all.  cheers
<LeLutin_> hello. I'm working on an external tool (a git remote-helper for interacting with bazaar) and I'm having difficulty with figuring out some things about how to use bzrlib..
<poolie> LeLutin_: what in particular?
<poolie> hi spiv
<LeLutin_> poolie: for now, I'm trying to discover branches that can be found on a URL. I think I may have found what I needed (BzrDir.open_containing) but I'm not sure yet..
<poolie> yes, that's where you should start
<LeLutin_> poolie: oh.. also, I was wondering what made urls like "lp:something" work. I checked out the code from the bzr-fastimport plugin and it seems to automatically receive a "canonical" url
<poolie> there's a directory service
<poolie> i think looked up by get_transport
<poolie> that ends up asking lp what actual url it should use
<LeLutin_> hmm ok. I tried giving Branch.open an "lp:.." url and it raised an exception saying that $pwd/lp:.. is not a branch
<poolie> you may need get_transport/open_transport
<poolie> what are you trying to build?
<LeLutin_> oh wait.. must be a plugin that's responsible for handling those then
<poolie> yes, the lp plugin does them
<poolie> calling bzrlib.initialize should register it
<LeLutin_> oh ok. I'll try that
<poolie> hm, i'm not sure if that loads plugins by default
<LeLutin_> to answer your question: I'm trying to build a remote-helper script for git that will make it possible to add bzr branches/repositories as native git branches
<LeLutin_> poolie: is it possible to selectively load bzr plugins?
<poolie> interesting
<poolie> probably, i don't recall how
<poolie> if you look in plugin.py something like calling _load_plugin_module should do it
<LeLutin_> poolie: oh ok.. well... thinking a bit more about it, maybe it's a bad idea. people could have other transport plugins that implement different types of urls
<poolie> right
<poolie> unless you specifically expect some plugins to cause trouble, i'd just load everything
<poolie> most of them should only register their capabilities and not actually do anything until asked
<LeLutin_> right
<LeLutin_> hmm.. AttributeError: 'module' object has no attribute 'initialize'. ipython to the rescue
<LeLutin_> hmm. the bzrlib installed on my laptop doesn't have an initialize function
<LeLutin_> I'm at bzr 2.1.1-1 (in lucid lynx)
<poolie> LeLutin_: ah in that case you have to set up some things manually
<poolie> primarily set up the ui_factory and load plugins
<LeLutin_> poolie: is it possible to find the API documentation for another version than the last one?
<poolie> LeLutin_: hm
<LeLutin_> for now, I have this: http://people.canonical.com/~mwh/bzrlibapi/bzrlib.html -- but it's reffering to the latest revision of bzr
<poolie> you can run 'make apidoc' in a tree
<LeLutin_> oh.. have to d/l the whole 2.1 branch then
<LeLutin_> aha, there's a bzr-doc package :) should be faster to d/l than having to wait for launchpad
<LeLutin_> poolie: good, bzrlib.plugin.load_plugins() seems to have added the necessary.
<LeLutin_> I thought using BzrDir.find_branches(..) would get me a list of branches, but I don't know where to find the transport object that I need to give to it :\
<poolie> LeLutin_: transport.get_transport()
<LeLutin_> oh, good. I had found BzrDir.root_transport but it spit out an error about list_dir not being implemented for http :(
<GungaDin> how do I bzr log commit made by a specific committer?
<mwhudson> spiv: hi, did you get anyone to land your codebrowse-oops branch yet?
<spiv> mwhudson: not yet
<mwhudson> spiv: ok, let's see if i have the necessary bits set up then :-)
<mwhudson> spiv: can you add a commit message?
<spiv> I'm not really here today.
<mwhudson> ok, i'll think of something
<poolie> GungaDin: i'd either use grep or maybe write a log formatter that does it
<poolie> hi spiv
<BjornT_> poolie: hi. could you get someone to look at bug 613066? it's currently blocking work on a branch, although i hope that recreating the branch and copy over the files will work around it (haven't had time to test it yet)
<ubot5> Launchpad bug 613066 in Bazaar "IndexError when running bzr status (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/613066
<poolie> hi BjornT_
<poolie> BjornT_: can you tar up that tree and put it on eg chinstrap?
<BjornT_> poolie: sure, just a minute
<poolie> it sounds a bit like a dupe but i don't think we've hit exactly that
<poolie> also if you recall what you did in this tree that would help
<BjornT_> poolie: the tree and repository (it's a lightweight checkout) is in ~bjorn/bug-613066 on chinstrap
<BjornT_> poolie: i'll look through the command history to see if i'll find something special. the only thing i can remember is that i used bzr-pipeline and switch pipes just before doing changes, and then getting this error when trying to run bzr diff
<BjornT_> poolie: more specifically, before the error i did: bzr pump; bzr lp-propose; bzr switch-pipe :next
<BjornT_> after that i modified some files, and got this error running bzr diff
<knittl> hi. how does bzr handle the case when one branch adds a file 'test' and another adds a dir 'test'?
<fullermd> It would be a conflict, just like if two branches both added files 'test'.
<svaksha> i have registered a branch on LP and did an initial commit. later i've added more files to the local dir and tried to push them to LP with 'bzr diff' which was unsuccessful. any idea what am i missing here? TIA.
<parthm> svaksha: i am not sure i understand. is 'bzr push' failing?
<svaksha> parthm: i'm only able to push the diff's for the old commit. the newly created files dont get pushed.
<parthm> svaksha: are you seeing an error message on 'bzr push'?
<abeaumont> svaksha: you need to add the new files to the repo with 'bzr add'
<ddaa> then commit, then push that
<ddaa> unless the files are added, they show as "unknown" in "bzr status", and don't show up in the diff
<ddaa> bzr add w/a argument adds all unknown files in the tree
<svaksha> abeaumont: that gives the error,  ERROR: No WorkingTree exists
<ddaa> svaksha: the add needs to be done wherever you do the commit
 * svaksha checks again
<ddaa> a working tree is the stuff with the actual content files, when you can make changes, run the code, commit, produce diffs, etc.
<ddaa> s/when/where/
<svaksha> ddaa: i repeated the process --bzr add, diff,commmit and push, but it only commits to the local dir and push/add does not push new files into LP
 * svaksha is missing something
<parthm> svaksha: what does 'bzr push' say?
<svaksha> parthm: ssh: bazaar.launchpad.net: Name or service not known
<svaksha> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<svaksha> ^^ latest ..earlier i didnt get this error
<parthm> svaksha: looks like a transient network error. i have seen this sometimes but it works when i trying again.
<svaksha> parthm: i hope so. /me will check later then. thanks for the help
<svaksha> ddaa: thanks
<svaksha> parthm, it worked just now. probably was a network issue afterall :)
<parthm> svaksha: :)
<LeLutin> is it possible to set options for bzr-grep in the bazaar config file?
<jelmer> LeLutin: You can set an alias
<LeLutin> jelmer: yes of course :)
<LeLutin> jelmer: hmm well in fact I can't really set an alias for a command with a space in it.. alias 'bzr grep'=.. is not valid
<jelmer> LeLutin: Don't include the 'bzr ' bit, that is implicit.
<LeLutin> I already have an alias for grep but bzr-grep doesn't use it
<jelmer> LeLutin: not when invoking "bzr grep"  ?
<Ddorda> hey there, i'm looking for a way to check what's the current revision i use
<LeLutin> jelmer: right. the alias is defined as "alias grep='grep --colo=auto'". when I do a normal "grep something" the color argument is there but when invoking "bzr grep ..." it's not activated
<LeLutin> Ddorda: "bzr revno" inside the workdir
<Ddorda> LeLutin: awesome, thanks
<jelmer> LeLutin: is this in ~/.bazaar/bazaar.conf ?
<LeLutin> jelmer: nope. this is in my .bashrc :P I don't know how to add the necessary config in bazaar.conf
<LeLutin> jelmer: nm, I've found a web page about how to setup bzr command aliases and it works fine.
<LeLutin> jelmer: thanks for your help
<jelmer> np
<mtaylor> FAIL: ShortReadvError: readv() read 0 bytes rather than 6046 bytes at 4096 for "d33aaa4aea5de86f6370880d52c949f5.cix"
<lifeless> mtaylor: shoot your file system
<fullermd> Right between the inodes?
<mtaylor> lifeless: ok
<mtaylor> lifeless: well, my local solution was to delete the shared repo, recreate it and re-branch
<mtaylor> lifeless: but, tbh - that's still sort of fail
<lifeless> mtaylor: your file system only wrote some of the file to disk. It is epic fail.
<mtaylor> lifeless: indeed. but I'm not sure I have any control over that filesystem ... so I'd sort of like the thing on top of it to re-fetch from remove if local file is ass ...
<mtaylor> fwiw
<lifeless> mtaylor: it doesn't have a clue where remote is at the point it finds out that failure
<lifeless> mtaylor: it would be like drizzle going back to an appserver a week later and saying 'hey, can you give me that users full name again? thanks!'
<mtaylor> hehe
<lifeless> mtaylor: or are you saying this happened without a crash of some sort in the middle?
<mtaylor> lifeless: it is possible there was a disk-full situation on the machine
<lifeless> ah
<lifeless> mtaylor: and your fs didn't tell userspace. win.
<lifeless> mtaylor: you might like to put that in the 'perhaps we should fsync' bug
<mtaylor> ah. that explains it - we're running xfs there
 * mtaylor shoots stewart 
<lifeless> bzr assumes, reasonably, that when it writes and closes a file, the fs considers it 'ok'
<mtaylor> lifeless: just for my edification - in the future, is there any way to say to bzr "hey, could you just delete any corrupted shit you've got" so that on a subsequent pull operation it would just fetch unknown objects as usual?
<lifeless> rm -rf :(
<mtaylor> k
<lifeless> it would be nice to have a fsrepair thingy
<mtaylor> well, that's what I did this time
<mtaylor> and then I was like "wow, I haven't branched drizzle from scratch in a VERY long time"
<thumper> LeLutin: there is also a 'bzr alias' command that operates very similar to the bash alias command
<jelmer> abentley: Hi!
<jelmer> abentley: I've had another look at implementation infrastructure for custom merge directives in bzrlib, and was wondering if you could have a quick look to see if my approach is reasonable, when you have a moment.
#bzr 2010-08-05
<cody-somerville> If I have a git import into bzr that has moved a bunch of files around (basically, moved a directory with files in it into another directory) is there a way for me to tell bzr about this when I merge that branch into my branch?
<poolie> cody-somerville: possibly using 'mv --after' will help
<poolie> is this imported using bzr-git
<cody-somerville> yup
<cody-somerville> so I figure the files all now have new file ids since git doesn't have that concept
<jelmer> cody-somerville: yeah, there isn't really a good way around that atm.
<cody-somerville> :(
<mwhudson> cody-somerville: live-helper/live-build by any chance?
<cody-somerville> mwhudson, aye
<jelmer> poolie: thanks for the heads up
<jelmer> poolie: so the intention is to get 2.2 into maverick I assume?
<poolie> yes
<poolie> i think we're still good for that
<spiv> Good morning.
<jelmer> G'tag spiv
<poolie> oh hi spiv
<poolie> spiv, hi, is bug 522637 still open?
<ubot5> Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 14, heat: 84)" [High,In progress] https://launchpad.net/bugs/522637
<poolie> lifeless, do you know anything about just what U1 is doing with bug 607850?
<ubot5> Launchpad bug 607850 in Bazaar "RevisionNotPresent in repository directory synced to UbuntuOne (affected: 1, heat: 9)" [Undecided,Incomplete] https://launchpad.net/bugs/607850
<spiv> poolie: yes, it's the main thing I'm working on.  The root cause has been fixed, now I'm making a repair tool.
<poolie> maybe we should mark that bug fixed and file another asking for a repair tool?
<poolie> i can do it
<lifeless> have we done a point release on all the old versions ?
<poolie> do you mean a backport of this to 2.0 and 2.1 etc?
<lifeless> poolie: they are changing their directoy sync code, introducing a thing called 'generations'
<poolie> i see you declined the tasks for that.?
<lifeless> poolie: yes, that was way back
<poolie> so we can be confident u1-client is actually broken in this way at present?
<lifeless> yes
<poolie> ok
<lifeless> because the old client is still live on lucid etc
<poolie> istm we should backport bug 522637
<ubot5> Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 14, heat: 84)" [High,In progress] https://launchpad.net/bugs/522637
<lifeless> once they SRU everything and disable the old API, then we have t reevaluate
<spiv> It already is, I think.
<spiv> Yeah, it is.  I'll update all the various bug targets, I guess I forget to update them in the relative chaos of being at the epic.
<poolie> np
<poolie> i'll do it, i have things open
<spiv> Ok, thanks.
<lifeless> poolie: that john gilmore bug comment was a bit of a zinger wasn't it
<poolie> kind of disappointing
<lifeless> yes
<lifeless> I think he had just had a bad experience
<poolie> probably
<poolie> it would be disappointing
<MTecknology> If I'm running lenny, would there be any issues adding the bzr nightly ppa?
<MTecknology> or maybe a stable ppa for it?
<MTecknology> or maybe I should just grab the .deb?
<MTecknology> https://edge.launchpad.net/~bzr/+archive/ppa <-- looks close if it actually had bazaar in it
<MTecknology> there's no .deb :P
<MTecknology> https://edge.launchpad.net/bzr/+download
<spiv> MTecknology: the package is called 'bzr'
<spiv> So not sure what you're saying the PPA is missing?
<MTecknology> spiv: there's qbzr - but not bzr
<MTecknology> unless they're the same?
<spiv> They're not the same (qbzr is a plugin for bzr), but I see bzr in that PPA.
<MTecknology> spiv: I guess it helps if I'm not looking at the lucid series
<MTecknology> lot more going on in anything prior to lucid..
<MTecknology> spiv: sorry
<poolie> spiv, nice test patch :)
<fullermd> Hm.  The progress-stipple-all-over-my-terminal bug isn't a 2.2 block?
<poolie> it should be
<poolie> i should do it now
<fullermd> Yeah.  Bugs like that are minor, purely cosmetic, hurt nothing...   and have a hugely disproportionate "wow, this is a crappy broken tool...  next!" effect   :|
<spiv> poolie: thanks, nice to have an idea you can implement and try nice and quickly :)
<spiv> The full test suite is now taking about 8m 42s on my laptop, and I haven't experimented with ram disks yet.
<mwhudson> spiv: i ran one launchpad windmill test on my netbook in 4 minutes earlier :-)
<poolie> fullermd: i agree
<spiv> Hmm, and as a side effect I think partitioning that way tends to help avoid the "can't start new thread" problem, because the thread leaks are spread more evenly :)
<poolie> hrm
<spiv> (At least, I'm not seeing it now, and I think I was before.)
<poolie> it probably will fix it
<poolie> it's probably the best way
<bialix> hi poolie
<bialix> poolie: I need your help or somebody else of admin
<bialix> poolie: this page http://doc.bazaar.canonical.com/explorer/en/index.html supposed to be auto-generated from lp:bzr-explorer-website branch
<poolie> hi bialix
<bialix> yesterday I've made some small changes to that branch, but it's not visible on the website yet
<poolie> ok
<poolie> and it's not?
<poolie> i'll check
<bialix> see left side bar with NEWS
<poolie> btw i went to see igc last friday
<poolie> he says hi
<bialix> I've changed to 1.0.2
<bialix> how's igc?
<poolie> he's pretty thin but he's still hanging in there
<poolie> he went home from hospital on tuesday
<bialix> sad
<bialix> good he's still fighting
<bialix> poolie: I have a question about english. recently you wrote in the answer that igc left big shoes to fill. "big shoes to fill" means many work to do?
<poolie> well, kind of
<poolie> more that it will be hard to do it as well as he has
<poolie> he sets a high standard
<bialix> ah, in that sense
<poolie> spiv, bialix, would one of you review https://code.edge.launchpad.net/~mbp/bzr/611127-2.2-progress/+merge/31824
<bialix> poolie: about bzr-explorer-website more details: initially lp:bzr-explore-website has pointed to https://code.launchpad.net/~ian-clatworthy/bzr-explorer-website/trunk, then igc changed owner of that branch to be ~bzr. maybe cron script still trying to update from his personal branch?
<poolie> ah maybe
<bialix> pollie: sorry, I'm a bit busy wih urgent call on work. also today I want to release qbzr 0.19 final and explorer new beta
<poolie> np
<poolie> yes, that was it
<spiv> poolie: reviewed
<spiv> And with that I'm done for today I think, little Vincent is a bit sick again :(
<poolie> thanks
<poolie> :( get well soon V
<poolie> i'm still a bit sick myself
<spiv> (little Vincent: not to be confused with big Vincent! :)
<shakaran> Hi, I have a launchpad project with a branch. Only I can commit, but how I can give permissions to another person to commit with the same prileges as me?
<bialix> big Vincent is vila?
<poolie> bialix: yes
<spiv> right :)
<bialix> Big Vincent :-D
<spiv> shakaran: change the owner of the branch to be a team
<poolie> shakaran: this will change the branch url to be eg
<spiv> Then anyone in that team can change that branch.
<poolie> ~myproject-dev/myproject/trunk
<spiv> (But if you mark that branch as the development focus, then you can also use lp:myproject as the URL for it, regardless of who owns it)
<spiv> Ok, really gone now :)
<spiv> Have a good night everyone.
<poolie> me too, unless there's anything else i can do for you bialix?
<poolie> thanks fro maknig a relrease
<poolie> obviously i should stop with typing like that :)
<bialix> good night poolie :-)
<bialix> I've sent you mail about book earlier, but this can wait
<bialix> thanks poolie, website updated!
<shakaran> spiv: and pollie thanks, all working
<magcius> gooooOOOOOOOO bizarre!
<magcius> http://paste.pocoo.org/show/246221/
<magcius> this was from
<magcius> bzr revert -r .
<magcius> which I know is wrong
<bialix> magcius: can you file a bug report?
<magcius> bialix: unfortunately, nVidia, so that means that Launchpad is unbearably slow
<magcius> Let me see if I can remember how to do the email bug report thing
<magcius> would it be bzr@bugs.launchpad.net?
<bialix> I guess so
<bialix> you may need to gpg sign mail though
<magcius> bialix: hm, should I put the backtrace in the body or attach it?
<magcius> (or use a pastebin)
<bialix> in the body please
<bialix> magcius: wait
<magcius> bialix: waiting
<bialix> magcius: https://bugs.launchpad.net/bzr/+bug/613804
<ubot5> Launchpad bug 613804 in Bazaar "`bzr revert -r . ` failed with traceback (affected: 1, heat: 6)" [Undecided,New]
<bialix> for you
<magcius> bialix: oh hey thanks
<Lebannen> Hi all - at the company I work at, we have ~160 projects sitting in a bzr repository.  A load of these projects are deprecated or replaced.  I'd like to move them to a "legacy" repository - what's the best way to do this? If I init-repo and pull stuff across, can the source then be deleted...?
<bialix> np
<bialix> Lebannen: do you mean shared repository?
<Lebannen> almost certainly :)
<Lebannen> we store them in one location for neatness, but I think many of the projects are treated as branches by bzr in terms of sharing storage
<bialix> you'd better create 2 new shared repos: first for old stuff, and second for actual stuff. and branch from old to corresponding new one
<bialix> then backup/rename/kill old repo and replace it with second new (with actual branches)
<Lebannen> Aha, ok
<bialix> thus you will filter out the old cruft
<bialix> otherwise old repo will still keep revisions of your old branches
<Lebannen> good point.
<bialix> there is no other way to collect garbage from shared repo
<Lebannen> Hmm, could current checkouts be rebased, or is the easiest thing to blow it all away?
<bialix> bzr switch --force
<Lebannen> perfect :D
<Lebannen> Many thanks, I'll work through that
<bialix> np
<dakira> Hi... I am using the nautilus-integration of bazaar and really like it. But when I right-click on a file and select "view changes" it'd be nice to have the changes dislayed in meld instead of the graphical diff that comes with bzr-gtk. Is that possible?
<jelmer> dakira: not at the moment, can you file a wihlist bug about it perhaps?
<dakira> jelmer: that bug should go to bzr-gtk, right? I think nautilus-bzr only displays context-menu shortcuts to the dialogs of bzr-gtk.
<jelmer> dakira: yeah - it's the same project thugh
<jelmer> *though
<dakira> okay
<dakira> jelmer: I added my suggestions to an existing (very old) bug.. should I report a new one? https://bugs.launchpad.net/bzr-gtk/+bug/70477
<ubot5> Launchpad bug 70477 in Bazaar GTK+ Frontends "integrate meld (affected: 3, heat: 5)" [Wishlist,Confirmed]
<jelmer> dakira: No, that's fine - thanks
<jave> id like to run bzr break-lock non-interactively, -q doesnt seem to do it
<jelmer> jave: please file a wishlist bug
<jelmer> jave: it should be possible to do from python, but I don't think we have that exposed on the command-line
<jelmer> jave: Why would you like to break locks non-interactively though?
<jave> jelmer: because I have a hudson server building emacs, and sometimes bzr leaves locks, so I want to do break-lock non-interactivly from hudson as a workaound
<jelmer> jave: That could lead to repository corruption, I'd recommend fixing the underlying issue.
<jave> sure, but I have no idea what the underlying issue is
<bialix> you may want to inspect .bzr.log
<jelmer> jave: two bzr processes running on the same repository at the same time?
<jave> then its a bug in the hudson bzr plugin
<maxb> jelmer: Can I get your thoughts on what it will take to convince you to merge https://code.edge.launchpad.net/~maxb/bzr-svn/fetch-svn-rev-info-progress-bar/+merge/28960 ? You expressed some hesitation on the basis that that code has been "fixed" several times in the past, but I'm quite convinced that my branch is better that what's there now.
<jelmer> maxb: I'll give it another look.
<maxb> thanks
<jave> why doesnt this work? bzr checkout bzr://rudel.bzr.sourceforge.net/bzrroot/rudel/future
<jelmer> jave: I think you need http://, afaik sourceforge doesn't run the bzr smart server
<jelmer> oh, they do.. nevermind
<jave> this seemed to work though: bzr init . && bzr branch bzr://rudel.bzr.sourceforge.net/bzrroot/rudel/branches/future
<jelmer> jave: The bzr init . isn't necessary
<jelmer> jave: according to http://rudel.bzr.sourceforge.net/bzr/rudel/ there is no branch called future, only branches/future
<jave> yes aparently
<lamalex> Hi, I keep getting a crash when trying to branch a repo
<lamalex> http://pastebin.com/zaqSp7Sx
<lamalex> and bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:576fa262710cb8cadf998f50c33f4fa28ac6f57b',)]
<lamalex> does anyone have any idea what the problem could be?
<jelmer> lamalex: I think there might be an open bug about this issue
<lamalex> oof
<lamalex> it seems I already have the latest bzr from the lp ppa
<lamalex> is there anything I can do?
<lamalex> not being able to branch is pretty critical for me, heh
<jelmer> lamalex, see https://bugs.edge.launchpad.net/bzr/+bug/522637
<ubot5> Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 14, heat: 86)" [High,In progress]
<lamalex> jelmer: so it looks like it's fixed in 2.0, when will 2.2 be released?
<lamalex> would an bzr upgrade possibly fix the problem? or is there some kind of metadata fixups that can be done?
<jelmer> lamalex: 2.2 is due out on friday I believe
<jelmer> lamalex: upgrade won't help as lp:do is already in the latest format
<jelmer> lamalex: There is an open bug about "bzr reconcile" fixing this issue in existing repositories: https://bugs.edge.launchpad.net/bzr/+bug/613698
<ubot5> Launchpad bug 613698 in Bazaar "need reconcile fixer for bug 522637 "missing referenced chk root keys" (affected: 1, heat: 6)" [High,Confirmed]
<lamalex> yeah, I guess I'll just watch https://bugs.edge.launchpad.net/bzr/+bug/613698 and cry
<jelmer> lamalex: Anyway, spiv is the right person to talk to, he has fixed the first bug and is assigned to fix the second.
<maxb> How do I ask bzr diff for the differences between a revision and one of its merged parents?
<maxb> I tried bzr diff -r parentdottedrevno..revno, and it gave me the differences *of* parentdottedrevno AND revno
<maxb> Oh. No it didn't. jelmer just did bunch of other stuff whilst merging my change, and confused me :-)
<jelmer> sorry :-)
<sussler> how cheap is branching in bzr respect to git? If i get this right, it has to do a WHOLE directory again for every branch even if it is a shallow copy
<sussler> please explain, i am interested in adopting bzr
<bialix> to work in git-style you need bzr-colo plugin
<jelmer> sussler: Only if you use a new working tree for each branch. you can also re-use an existing working tree, in which case the overhead is only a couple of files.
<bialix> in this case you can share the same working tree for several local branches
<sussler> ok let me make an example here
<sussler> let's just say that i have a really, really complicated merge history in git
<sussler> like more than 20 branches merged in various ways one with the other and then merged back to master
<sussler> would a similar model be possible without losing history of every working tree when doing the merge?
<jelmer> sussler, sure
<sussler> hmm
<sussler> ok, let me get this right then
<sussler> branches 1 - 5 with different history getting merged with multiple bzr merge --force commands (if i am not mistaken)
<sussler> each of them done with a --notree option
<sussler> then i simple rm -rf the branch "dirs" and it is bye bye
<sussler> correct?
<sussler> nothing lost
<jelmer> right, their history lives on in the branch you've merged them into.
<sussler> ok
<sussler> there is no branch "delete" option because a branch is a physically contained directory in the filesystem
<sussler> am i right
<sussler> you poof the dir, cleaned up the mess
<jelmer> sussler, yes
<sussler> sorry for being newbiesh, but i am trying to get a grip of bzr, since launchpad is so effin nice :P
<sussler> ok, so, lesson learned: 1) use shared repositories 2) do branches as physical dirs inside them, 3) use no tree option 4) proceed with --force in octomerge style
<sussler> correct guys?
<jelmer> sussler: For octopus merging --force is indeed requirement; the other points are all optional and depend on your personal preferences and workflow.
<sussler> ok
<sussler> thanks a lot
<sussler> will study a bit more before i ask something else, you have all been very very helpful
<sussler> instead of telling me to RTFM
<sussler> :P
<bialix> jelmer: who is active maintainer of bzr-gtk now?
<jelmer> bialix: There are a couple of people that fix urgent  bugs when they come up, but nobody is really doing any active maintainance.
<bialix> my proposal re language option is not urgent fix, of course. ok, will know
<jelmer> bialix: bzr-gtk doesn't really have any translation support
<bialix> hmm, strange
<bialix> I remember there was one in olive in old days
<jelmer> bialix: Yes, olive is translated but bzr-gtk is not (they're separate projects again nowadays)
<bialix> ouch
<jelmer> bialix, Hmm?
<bialix> I've missed the divorce, it seems
<bialix> okay, thank you for information, I was under wrong impression bzr-gtk has i18n support
<jelmer> happened about 2 months ago I think
<jelmer> olive still depends on bzr-gtk, it's just that they're two different projects again
<jelmer> in a similar way as bzr-explorer and qbzr are different
<bialix> I see
<bialix> I really did not know that bzr-gtk has no i18n inside
<mpg> Hi, I'd like to share a repo between two users on the same (Unix) machine. With SVN, I know you can run into problems if users don't have a proper umask when accessing the repo. Is there the same kind of problem with bzr?
<ddaa> yep, at least if you use SSH (or direct filesystem) access
<mpg> ok, that's what I was thinking
<ddaa> also
<mpg> I'm surprised because friends of mine are using such a setup (sftp acces rpecisely) without taking any precautions (no setgid bit on the repo, umask 022) and didsn't have any problem (yet)
<ddaa> you should have your shared repositories dirs (esp. stuff below .bzr) set to u+rwx,g+rwxs
<ddaa> I guess they are not both writing to the same repository
<mpg> okay, so precisely the same as with svn
<ddaa> or maybe the permissions issues became less significant with newer repository formats
<ddaa> bzr repos used to rely a lot more on the filesystem as a database than they do nowadays
<ddaa> other would know better
<mpg> they are writing to the same repo
<mpg> it's a repo without a tree, in case it makes a difference
<ddaa> bzr tries to preserve dir permissions when creating subdirs, but I read that sftp servers will lie about those
<mpg> they both have a checkout on their own machine, and are pushing to the repo using sftp, but with different Unix accounts
<ddaa> mpg... well, if it works, don't fix it :-)
<ddaa> you know where to look if it ever breaks
<mpg> ;-)
<ddaa> mh random guess
<ddaa> maybe they are actually using bzr+ssh, not sftp
<mpg> well, my question is, whether I can recommend this setup
<mpg> because it's so easy to configure
<mpg> no, I'm sure they are using sftp (that's what bzr info in their checkouts says, anyway)
<ddaa> so that's what they're using
<ddaa> better to recommand bzr+ssh, if bzr can be installed server-sid
<ddaa> it's significantly faster
<ddaa> I'm trying to find specifics about multi-commiters repos in the doc
<mpg> I must say, I'm slightly disapointed by the doc (or what I have read of it); the svn book is much more specific about the pros and cons of various server setups
<ddaa> well, it's not a book
<mpg> right
<ddaa> the doc does not say anything about setting permissions or umask
<mpg> yep, I checked before asking here
<ddaa> so either my knowledge is outdated and the problems were fixed, or the doc is incomplete :-)
<mpg> I would have felt more confident if the doc stated explicitely that there is no need to setgid and set umask
<mpg> :-)
<ddaa> in my experience, the permission problems occured very soon, with the repository lockng system
<mpg> ok
<ddaa> bzr used a clever dumb-filesystem lockin scheme that was invented by gnu arch
<mpg> since history never changes, it does not seem impossible (besides the locking issues you mentioned) that files created by one user never need to be modified (possibly by another user) afterwards
<ddaa> that was very clever, basically it started from "what, if anything, has atomicity guarantees on NFS"
<ddaa> that would not be the case with newer formats
<ddaa> I do not know the specifics of things now, but used to have "one file per atomic chunk of data", and it was terrible performance wise.
<ddaa> as the linux hackers say, "the filesystem is not a database"
<mpg> ^^
<ddaa> if anything, it's better to just append to a file and have file format that supports easy synchronization.
<ddaa> and indexes, bzr uses a bunch of indexes
<ddaa> so, I'd say, go for it
<ddaa> "the document does not say anything against it, it must be good, and it works for them"
<ddaa> or do your own testing if you are unsure
<ddaa> it's quite likely that a sensible umask is needed though
<ddaa> but it might be already be set sensibly on their server
<mpg> right, but I'm afraid I don't know enough what to test
<ddaa> create a repo with one user, push a single commit there
<ddaa> have another user get a checkout make another commit
<mpg> I checked the file permission in the .bzr on the server (to which I happen to have access), ther umask seems to be the usual 022
<mpg> Yep, I'll try
<mpg> ok, so according to my tests:
<mpg> * if you are using a single branch, chgrp -R <common-group> && chmod -R g+w on the repo is enough
<mpg> * but if you want people to be able to create and chare new branches on the repo, you have to rely on the usual setgit & umask 002 trick
<mpg> I'm still not very confident about the first point, but I just didn't get any problems in my tests
<ddaa> you tested that on local filesystem, or through some other transport?
<Buttons840> when i do bzr info i see a "Related branch" which no longer exists, can i remove it?
<ddaa> Buttons840: cannot parse that. If the push/parent branch no longer exists, you cannot remove it anymore, right?
<mpg> tested on local filesystem
<Buttons840> ddaa: i don't know, that's why i'm asking
<mpg> is it different from sftp?
<ddaa> I'm pretty sure you cannot delete anymore something that was already deleted.
<ddaa> mpg: might be :-) I'm asking because I'm curious myself.
<Buttons840> i don't want to delete literal files, but i do want to remove the reference which says Related branches: submit branch: bzr+ssh://192.168.0.104/home/buttons/Code/CallNSee/Working/
<mpg> Buttons840: you want to deleted the reference to the delete branch in the other branch, maybe?
<mpg> oh, you just said precisely that as I was writing
<Buttons840> basically i have my code on my desktop, and i branched it to my laptop to take it with me;   i've since deleted that branch entirely from my laptop but this "submit branch" still lingers
<ddaa> Buttons840: the submit branch is a setting that's used by commands like bzr send, bzr bundle, etc.
<Buttons840> so will i always have this non-existent "submit branch" as part of my project?
<ddaa> it does not do any harm as it is, but if the bzr info output annoys you, you can remove the setting by editing .bzr/branch/branch.conf
<ddaa> it's not part of the project, it's not even versioned data
<ddaa> it's just a convenient branch-specific default value for some bzr commands
<Buttons840> ddaa: ok, editing the branch.conf will work
<Buttons840> is there a more friendly way to remove it?    i'm not so concerned about this one particular "listing" (what are they called?), but in one project i have 3 or more "listings" none of which actually exist (probably a fault of my playing around), but i would like to keep the list from growing permanently every time i make a mistake
<Buttons840> anyways; problem solved; thanks
<dobey> is there a command to see the entire configuration for a particular working tree that i'm in?
<mgz> `bzr info`? what do you mean exactly?
<dobey> i have a path in locations.conf with create_signatures = never, and bzr seems to be trying to sign commits in that tree
<dobey> bzr info shows a very limited set of things
<mgz> if there's something specific you want shown, file a bug.
<dobey> i want to see all the configuration affecting bzr in that working tree. so that i can debug why this suddenly stopped working
<mgz> you want it to cat your conf files to the terminal? why not just open them in your favourite text editor...
<james_w> there would be value in showing the values it was using and where it was taking them from, given that you can have multiple files that stack
<dobey> no, i want to know if something is overriding what is in my locations.conf
<james_w> and multiple stanzas in locations.conf
<mgz> printing something about specific locations.conf rules seems a reasonable idea, but "all the configuration affecting bzr" isn't going to be helpful.
<dobey> well having "bzr help configuration" actually show me what the current configuration is, in the context i'm in, would be more helpful than dumping pages and pages of hard to read, unsearchable text :)
<mgz> `bzr version` shows you where the conf files are.
<dobey> right, but bzr hasn't been updated in maverick in 10 weeks, and i haven't manually changed the config, so by all means, i shouldn't be having this problem
<mgz> if you want help debugging what has msyterously gone wrong when you haven't changed anything, more details might assist those able to help you
<dobey> if i had more details, i wouldn't be asking how i can get them :)
<dobey> is there any way to view the value for specific configuration variables, within a working tree?
<dobey> (if the answer is python -c "import bzrlib.blah.blah; do stuff" that's fine by me for now)
<james_w> only from python as far as I know
<dobey> how do i do it from python?
<james_w> python -c "from bzrlib.branch import Branch; branch = Branch.open("."); config = Branch.get_config()"
<james_w> you want "print config.signing_policy()" at the end I think
<dobey> hrmm, i guess that doesn't work so well with a lightweight checkout?
<james_w> no
<james_w> use bzrlib.workingtree.WorkingTree for the open, and then branch = wt.branch
<lamalex> How can I tell bzr to stack on a different remote branch?
<dobey> ah lovely, it just prints "1"
<lamalex> I tried --stacked-on=lp:branch
<dobey> whatever that means
<lamalex> but it only seems to look for local ones
<lamalex> do I need to do the bzr+ssh:// full uri?
<james_w> dobey: SIGN_ALWAYS unsurprisingly
<james_w> lamalex: possibly
<james_w> worth a try
<lamalex> heh, ok
<dobey> james_w: :(
<dobey> james_w: i guess it's using the default setting, rather than the one from locations.conf
<james_w> quite possibly
<dobey> this makes no sense
<dobey> it was working fine yesterday!
<james_w> you just have it set in bazaar.conf, and trying to overwrite it for one location in locations.conf?
<dobey> yes
<james_w> I don't know then
<dobey> it's definitely ignoring what's in locations.conf though :(
<james_w> dobey: you have the path to the branch, or the path to the working tree in locations.conf?
<dobey> i have [/var/cache/tarmac] in locations.conf, and the lightweight checkout is in /var/cache/tarmac/libubuntuone/trunk
<dobey> is it because it's a lightweight checkout?
<james_w> probably
<dobey> :(
<dobey> definitely :-/
<dobey> ok. /me files bug
<dobey> https://bugs.edge.launchpad.net/bzr/+bug/613986
<ubot5> Launchpad bug 613986 in Bazaar "locations.conf settings ignored for lightweight checkouts (affected: 1, heat: 6)" [Undecided,New]
<mwhudson> abentley: hi, is there a way with bzr-pipeline to copy a remote pipeline to your machine?
<mwhudson> i tried a few things with sync-pipeline but didn't get it to work
<abentley> mwhudson, not unless you can do it from the remote side.  That's a desired feature, but not done yet.
<mwhudson> abentley: ok
<mwhudson> the remote side in this case was lp. so...
<norton-> How can I edit a log message from the last commit?
<thumper> norton-: you can't edit
<thumper> norton-: but you can uncommit, then commit again
<norton-> thumper: ok, thanks!
#bzr 2010-08-06
<mkanat> The buildbot release notes say that they're going to drop Bazaar support for their next release unless somebody maintains it.
<lifeless> baz or bzr
<lifeless> whats unmaintained about it ?
<mkanat> lifeless: I'm not sure if they mean baz or bzr.
<mkanat> lifeless: I'm not sure, I just noticed it in the release notes. I'm guessing they mean baz, because it would seem weird to drop bzr support.
<mkanat> Hmm, yeah, I think they refer to baz as "Bazaar" and bzr as "Bzr".
<mkanat> Yeah, they removed baz and said they were removing Bazaar.
<cnd> I'm trying to use bzr fast-import with git fast-export
<cnd> but every time I try it aborts on a specific commit
<cnd> anything I can try to make it work?
<jelmer_> hi cnd
<jelmer_> cnd: That depends on why/how it is failing..
<cnd> ABORT: exception occurred processing commit :25
<cnd> bzr: ERROR: exceptions.IndexError: list index out of range
<jelmer_> cnd: I think I've seen that error before; have you checked the bzr-fast-import bugtracker to see if there are any similar issues listed there?
<cnd> jelmer_, not yet
<cnd> I'll look now
<jelmer_> cnd: Alternatively, have you considered doing the import with bzr-git or the Launchpad import service ?
<cnd> yeah, I haven't yet
<cnd> are there differences in how bzr-git and bzr fast-import work?
<cnd> as in, will the outputs be the same or different?
<jelmer_> cnd: bzr-git generates consistent output, bzr fast-import will generate different output if run by different people independently.
<jelmer_> cnd: The output they generate is different.
<jelmer_> (The Launchpad import service uses bzr-git)
<cnd> ahh, ok
<cnd> thanks
<cnd> jelmer_, I think I got it working using bzr-git instead
<cnd> thanks!
<jam> jelmer_: morning. I have a question about meliae
<jam> looking here: http://packages.debian.org/sid/python/python-meliae it looks like it only built 0.3.0 for 1 platform?
<jelmer_> cnd: No problem
<jelmer_> jam: 'morning
<jelmer_> jam: Uhm, aren't you generally the person providing *answers* about meliae ? :-P
<jelmer_> jam: yes, so far it's only built on my local machine (I use amd64).
<jelmer_> jam: At some point the Debian buildds will also build it for other architectures.
<jam> jelmer_: k, I just wanted to request a sync to Maverick, and I wasn't sure what I need to wait for there.
<jam> james_w: ping if you are around
<james_w> jam: pong
<jelmer_> jam: You should be able to request a sync
<jam> james_w: any chance you could sync meliae 0.3.0? I can do the official thing if you're busy
<james_w> jam: I can
<jam> james_w:  /thank /cheer /train :)
<MacSlow> james_w, there I am
<james_w> hi MacSlow
<james_w> jam: MacSlow is having an odd problem pulling from lp
<james_w> bzr hangs, but ssh works fine
<james_w> https://pastebin.canonical.com/35554/
<james_w> MacSlow: there's no extra lines in your ~/.bzr.log now are there?
<MacSlow> james_w, these are just the last 10 lines... my whole ~/.bzr.log is 36716 lines long (2234253 bytes)
<james_w> MacSlow: yeah, I just wondered if it had written any subsequent debugging information
<MacSlow> james_w, nope... the "bzr -Dhpss branch lp:clutk" command still hangs
<MacSlow> and I don't expect it to move anytime soon
<james_w> MacSlow: could you do a "pstree -p | grep -C2 bzr" please?
<MacSlow> james_w, pastebin taking its time to respond
<MacSlow> james_w, http://pastebin.ubuntu.com/474081/
<james_w> MacSlow: and "strace -p 2206"
<MacSlow> james_w, wait... it (bzr) moved
<jam> james_w, MacSlow: strange, I just did "time bzr branch lp:clutk" and it finished in about 19s
<MacSlow> seems it just finished the branch
<jam> it isn't a very large branch
<james_w> MacSlow: odd, in response to the strace, or before you got to that?
<MacSlow> james_w, before that
<MacSlow> why do I always have to run into such kind of problems
<MacSlow> james_w, doing a "bzr -Dhpss branch lp:clutk" again and doing a strace on it's process id
<MacSlow> that just sits there at "read(6 ,"
<james_w> jam: synced
<jam> thanks james_w
<james_w> MacSlow: seems that lp is taking its time in talking to you for some reason
<james_w> that's my guess, maybe 6 is something else
<jam> MacSlow: any chance to do an strace across the whole run?
<MacSlow> james_w, ~/.bzr.log -> http://pastebin.ubuntu.com/474085
<jam> 50s to do an open() call? that is strange
<jam> now, that includes the ssh handshake, etc
<jam> MacSlow: what is your ping time to bazaar.launchpad.net?
<jam> (I wonder if there is something strange is the ssh handshake, but if normal ssh/sftp doesn't take that long then it is probably something else)
<MacSlow> jam, ~33 ms
<jam> MacSlow: do you have a lot of ssh keys in your agent?
<MacSlow> jam, how to check?
<jam> MacSlow: if you don't know, then I expect it will be small :), let me find it real quick
<jam> MacSlow: ssh-add -l
<MacSlow> jam, that reports just  one line, my key
<jam> yeah, that's what I figured
<jam> so it isn't like launchpad is spending a lot of time determining which key to use
<jam> MacSlow: is it repeatable? (as in, if you try to branch again, it still takes >1min?)
<MacSlow> jam, certainly... just trying it again... it just sits there
<MacSlow> jam, on my desktop machine (running lucid) it works super fast
<MacSlow> jam, other network-traffic (e.g. browsing some webpage) works at normal speeds
<jam> MacSlow: try typing this:
<jam> echo hello | ssh bazaar.launchpad.net bzr serve --inet --directory=/ --allow-writes
<jam> that should at least connect, talk to the remote server and stop
<jam> and then we can try adding "-v" to the ssh command
<MacSlow> jam, waiting for 10 seconds now after triggering that "echo hello | ..." command... nothing
<MacSlow> ah wait
<MacSlow> now it tells me again I don't ahve a registered ssh key
<jam> MacSlow: probably your lp username is different from your local one
<jam> just add "lpuser@bazaar." for whatever your launchpad username is
<MacSlow> jam, figured that out... trying... but still sitting there doing nothing
<jam> MacSlow: so trying again with "ssh -v" would be worthwhile I think
<jam> it should tell us if ssh is sitting there waiting for something
<jam> or if it is something in bzr
<MacSlow> jam, "ssh -v ..." what else?
<jam> (note that it is about 7s here, and that is *with* typing in my ssh passphrase)
<jam> echo hello | ssh -v lpuser@bazaar.launchpad.net bzr serve --inet --directory=/ --allow-writes
<jam> MacSlow: I have an idea, there was an issue I've seen in the past with dns reverse lookups
<MacSlow> ok
<jam> let me see if I can find the ssh config
<jam> wait, maybe it was kerberos
<MacSlow> right now it sits at: "debug1: expecting SSH2_MSG_KEXDH_REPLY"
<jam> I wish I could remember better, checking
<jam> MacSlow: http://llbb.wordpress.com/2007/07/11/ssh-takes-exactly-1-minute-20-seconds-or-80-seconds/
<jam> or
<jam> http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2007-02/msg00033.html
<MacSlow> jam, there they talk about sshd
<jam> well, they talk a little bit about both, I'm still looking
<jam> https://bugs.edge.launchpad.net/ubuntu/+source/openssh/+bug/174168
<ubot5> Launchpad bug 174168 in openssh (Ubuntu) " expecting SSH2_MSG_KEX_DH_GEX_GROUP (affected: 1, heat: 15)" [Undecided,Invalid]
<jam> seems pretty close to what you are seeing
<jam> claims to be fixed in ssh v5.2
<jam> what does ssh --version give ?
<jam> and this: http://www.snailbook.com/faq/mtu-mismatch.auto.html
<jam> MacSlow: so you might try ifconfig eth0 mtu 576 and see if that "fixes" it.
<jam> MacSlow: what platform are you on?
<jam> (the bug report is about Jaunty)
<MacSlow> jam, that would be wlan1 on my laptop here... does the MTU also apply to wifi-nics?
<MacSlow> jam, maverick
<jam> MacSlow: it should apply to any TCP/IP network
<MacSlow> jam, still hangs at "debug1: expecting SSH2_MSG_KEXDH_REPLY"
<MacSlow> jam, this is taking too long... I need to work-around this some other way... thanks for the help sofar.
<jam> MacSlow: just to check, what was your "ssh --version" ?
<jam> (though as you say, if it was just that, lucid should be older than maverick)
<jam> regardless, it is an ssh handshaking bug
<jam> not something with bzr
<pickscrape> Hi, I seem to have managed to "lose" a revision by a combination of bzr rebase, switch and rebase-abort. Anyone know of any tricks to find revisions?
<jam> pickscrape: bzr heads --dead
<pickscrape> jam: unfortunately that hasn't found the revision I'm looking for :(
<MacSlow> jam, ssh -version reports "OpenSSH_5.5p1 Debian-4ubuntu3, OpenSSL 0.9.8o 01 Jun 2010"
<pickscrape> It has actually found a parent of it though
<pickscrape> Or it could be a parent: may have previously been rebased away of course.
<jam> pickscrape: if it found a parent and not a child, then it would be tricky to find (a head is the most recent *child* with no other children)
<jam> which would indicate that the revision really isn't there
<jam> or the parent wouldn't be a head
<pickscrape> Ah, the parent I thought I'd found must have been due to a rebase then.
<pickscrape> What's happened is I tried rebasing branch A, which must have failed, though I didn't notice the message telling me so. Later on I swithed to branch B, and tried to rebase.
<pickscrape> It said there was already one in process, so I opted to rebase-abort. That left me with branch B looking like branch A.
<pickscrape> I'm wondering if it's a bug for switch to be allowed while there's a pending rebase in process?
<jam> pickscrape: perhaps. If you're in the same repository, though, rebase shouldn't be deleting any revisions, just changing the branch pointers
<jam> so they should all still be there
<pickscrape> jam: I actually have found the head I was looking for in the heads output. There's quite a few listed there. :) Thanks for your help.
<jam> james_w: I just got a "The source meliae - 0.3.0-1 is already accepted in ubuntu/maverick and you cannot upload the same version within the same distribution." error message
<jam> did you try to upload it 2x ?
<jam> Was it already synced by someone else?
<jam> (ISTR that gary poster had some interest in getting the latest Meliae for launchpad developers)
<james_w> jam: I made a mistake and attributed the sync to "jam", and then unsuccessfully tried to cancel that and set you as the requester.
<james_w> jam: so it's there, just you don't get the credit for it. I forgot you would get a failure mail too.
<jam> james_w: well, I can live without credit. I'm glad it got in
<jam> anyway, back in a bit
<rubbs> quick question. It's been a while since I've used bzr, if I want to connect to a server via ssh, I can't tell bzr to use a key right? I have to have it in some sort of agent correct?
<abentley> jam, the revision-id requiring a username is a strict requirement with bzr 2.2b4.  My traceback shows that it is.
<jam> abentley: I'm saying that to create Revision content we require Whoami, I think that requiring it to create revision-ids is not much of a step beyond that
<abentley> jam, we require a committer_id, not a whoami, to create Revision content.  But we require a Whoami to create a revision-id.
<jam> abentley: and if you don't supply a commiter_id directly, we get it from whoami, right?
<abentley> jam, correct.  The committer_id replaces Whoami for generating Revision content, but not for generating a revision-id.
<abentley> jam, which is what I'm saying is a bug.  If the commiter is me@example.com, the revision-id shouldn't contain aaron@aaronbentley.com
<jam> abentley: it looks like we will pull the username from the "EMAIL" env variable, and the bzrlib test suite sets that
<jam> abentley: sure
<jam> abentley: line 244 of repository.py
<jam> _gen_revision_id() could know if the commit has a committer id and take it from that
<jam> rather than always using _config.username()
<abentley> jam, right.
<jam> self._committer is available there, and happens to be self._config.username() if it wasn't supplied anyway
<jam> so probably we could just change that line
<mgz> selftest should pass on Python 2.6 right?
<jelmer_> mgz: yeah
<mgz> just tested a failure from upstream changes to gzip.py and it's from a change that shipped with Python 2.6
<mgz> ...maybe the struct side of it is Python 2.7 only...
 * mgz goes to see
<jam> mgz: probably a 2.6.5/6 thing, as I believe they broke some stuff in the recent 2.6 releases
<jam> I'm running 2.6.4 here
<jam> (I think it is stuff they are officially allowed to break, but it broke nonetheless)
<mgz> if you do... `python -c "import struct;print struct.pack('<L', -1)"` what happens?
<GaryvdM> Hi all.
<GaryvdM> What is the 2.2.0 status?
<mgz> well, nominally frozen I guess garyvdm
<mgz> ...two bugs to blame on lifeless-of-2006 in one day
<mgz> jam is doing a bug-closing spree.
 * mgz gets one before jam arrives there
<jam> GaryvdM: I'm releasing today
<jam> and cleaning up the bug tracker while I'm there
<mgz> I'm not sure bug 531746 is fixed so much as mostly hacked around, but I guess that's nitpicking.
<ubot5> Launchpad bug 531746 in Bazaar "Intermittent test failure during _finishLogFile (affected: 1, heat: 1)" [Low,Fix released] https://launchpad.net/bugs/531746
<mgz> okay, two more Python 2.7 bugs to file, will do that later this evening.
 * mgz wanders off for food
<jam> mgz: you are welcome to post-triage however you want. For some things, a new bug is more relevant as it can be more focused
<mgz> yeah, really that code just needs changing from a different angle, can quite happily be another bug.
 * jelmer_ makes a note to ignore all bzr-related email traffic for the next couple of hours.. too much :-)
<jam> jelmer_: you generated at least as much as I did in the last week :)
<jelmer_> jam: Sorry :-)
<jam> but yeah, a bigger storm of updates than I realized at first
<jam> we had a *lot* of bugs that were fixed but not marked that way
<jelmer_> are you using the script to check?:
<jam> jelmer_: yeah, though after trimming just the 2.2 series over to a new file
<GaryvdM> jam: Ok thanks.
<GaryvdM> jam: I want to get the installers built as soon as possible.
<jam> I'll have a tarball real-soon-now and I've submitted the code to pqm
<jam> do you want me to spin up ec2?
<jam> GaryvdM: ^^
<GaryvdM> but not tonight, so tomorrow evening or sunday.
<GaryvdM> jam: So yes please.
<jam> well, I can't guarantee to be around, but we can leave it running for you, I guess
<jam> GaryvdM: the instance is now launching, I can ping you when I know it is up if you want
<GaryvdM> jam: I'm planing to make 2 releases. one with old paramiko, and one with my patch. I'll upload the old paramiko to launchpad, and the one with my patch, i'll mention it on the mailing list so that people who test understanding what they are testing.
<jam> GaryvdM: I would just do your new paramiko
<jam> up to you, though
<GaryvdM> jam: Ok - then I would just like for someone to review my changes.
<jam> GaryvdM: has robey noticed yet?
<GaryvdM> Nope :-(
<jam> GaryvdM: the big thing I saw, is that I think it breaks compatibility with pycrypto 2.0*
<GaryvdM> jam: Yes, but if we control the pycrypto, that does not matter.
<GaryvdM> For robey that probably does matter.
* jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.2-final has gone gold, build those installers
<jelmer_> jam: w00t!
 * jelmer_ looks into building 2.2.0 for debian
<jelmer_> lifeless: 'moin
<jelmer_> lifeless: I know you already have quite a few MPs to review on your list, but just wanted to make sure you were aware of the open ones for bzr-dbus.
<lifeless> jelmer_: don't block on me :)
<jelmer_> lifeless, ok :-)
<lifeless> jelmer_: get john or jamesh or poolie to review
<lifeless> or jfdi
<jelmer_> lifeless: right
<jelmer_> 140 more tests to go :-)
<mgz> okay, that's the last Python 2.7 issue turned up from running the testsuite
<mgz> just need to put up some more fixy branches now.
<jelmer_> jam: still there
<jam> jelmer_: just about to leave
<jelmer_> jam: I have trouble merging bzr 2.2 into the debian unstable branch :-(
<jelmer_> bzr: ERROR: An inconsistent delta was supplied involving u'bzrlib/help_topics/es', 'bzrlibhelp_topicses-20091223160038-qyu0zdzjfbx76ud7-1'
<jelmer_> reason: Attempt to add item at path already occupied by id 'bzrlibhelp_topicses-20100104142927-3zk9dhyzgw3dqtkl-1'
<jelmer_> any idea?
<jam> sounds pretty odd to me. Looks like a wt.update() failure. Something thinks a dir shouldn't exist but it is already there
<jam> anyway, I need to get going
<jam> eo-week for me
<jelmer_> Sorry, didn't mean to hold you up.
<jelmer_> Enjoy your weekend!
#bzr 2010-08-07
<fullermd> Um.  Well.  So, all this apport crap is new...
<fullermd> Am I just being dumb and not seeing the magic switch to stop blatting that around?
<lifeless> fullermd: how do you mean?
<fullermd> Well, it seems like setup.py is using "if sys.platform != 'win32':" as a shotgun way of saying "if ubuntu:" or something...
<fullermd> Unless I'm dainbramaged (which I don't rule out, it being a weekend and all), I can't see any way to make it keep those steenkin' files out of my install short of patching setup.py.
<lifeless> fullermd: what steenkin files - do you mean the apport hooks?
<lifeless> fullermd: cause apport works on more than Ubuntu ..
<fullermd> Well, it doesn't on BSD, so by themselves the files are pointless.  But it's especially egregious that they install themselves in absolute paths away from the $PREFIX files are supposed to install into.
<lifeless> fullermd: file a bug!
<fullermd> Well, after I get it packaged.  I hoped there might be some simpler shortcut than brute force.
<lifeless> snakes on a package :P
<fullermd> And packaging comes after I finish cleaning my desk.  Jeez Louise...
<fullermd> Y'know I found a travel itinerary from 2002 on the bottom of one stack of stuff?
<fullermd> What's disturbing is that I moved in 2008.  How the heck...
<lifeless> nice
#bzr 2010-08-08
 * jelmer waves
<Fweeb> Apologies if I'm asking this in the wrong place, but I'm researching the potential of using bzr instead of svn for an animation production pipeline. The bzr FAQ states that there are better tools for large binaries or multi-GB trees. My question(s): Is that still accurate? What might those tools be?
#bzr 2011-08-01
<lifeless> spiv: hey, you might like to know your quiescing code for bzr+ssh bazaar.launchpad.net is now live in HA mode.
<poolie> just in time :)
<poolie> anyone up for a review? https://code.launchpad.net/~mbp/bzr/test-errors/+merge/64485
<jelmer> poolie: sure, I'll have a look
<Noldorin> ah hi jelmer
<poolie> hi there
<Noldorin> seems weekend is not a godo time to catch you ;-)
<jelmer> hi Noldorin
<jelmer> hi poolie
<jelmer> Noldorin: Usually it is, but I spent 27 hours of this one on trains
<Noldorin> ah i see
<Noldorin> soudns fun. :-P
<Noldorin> jelmer, well if you got my email, i replied to your messages...had actually already submitted the bug report on friday when speaking to you :-)
<Noldorin> jelmer, you gone again??
<jelmer> Noldorin: no, sorry, but going through mail backlog at the moment
<jelmer> Noldorin: I'll follow up to the bug
<Noldorin> jelmer, ok, please :-)
<Noldorin> jelmer, this is very imporant to me, so i will be happy to help you with this. have some free time either now or tomorrow night (for you)
<jelmer> Noldorin: unfortunately it just requires a lot of time debugging
<jelmer> Noldorin: I can provide you with some hints if you would like to have a look at it yourself
<Noldorin> jelmer, certainly...
<Noldorin> jelmer, obviously leave it on your own task list, but it doesn't hurt for me to have a go as well. :-)
<Noldorin> as i understand, the issue is a missing item in the Git database...don't know anything more
<jelmer> Noldorin: one of the bzr-git routines doesn't properly generate an entry for a particular src directory in the _revision_to_objects method
<jelmer> it seems to happen specifically with r47 of ircdotnet, but I'm not sure why (which change in that revision is problematic)
<jelmer> a good first step might be to try to push r46 into a git repository, and confirm that that works
<Noldorin> interesting
<jelmer> and then see if you can reproduce the issue with a subset of the changes in r47
<Noldorin> jelmer, what do you mean "particular src directory"?
<jelmer> Noldorin: see the comments on the bug report
<Noldorin> jelmer, link please? for some reaons i am not getting notifications :-(
<jelmer> Noldorin: Sorry, I don't have it handy here. You should have the bug# though, as you filed the bug.
<Noldorin> hah i wouldn't assume
<Noldorin> i will have to search for it...
<Noldorin> i rely on LP to update me. oh well
<Noldorin> got it
<Noldorin> jelmer, what does Triaged mean?
<poolie> it means accepted by a developer
<Noldorin> ok heh
<Noldorin> such an obscure term in normal English ;-)
<poolie> heh, http://markmail.org/message/jt2psgctve3riact#query:+page:1+mid:jt2psgctve3riact+state:results
<jelmer> poolie: great to hear about HA for codehosting, looking forward to seeing jam & spiv's forking server code land!
<poolie> isn't it great
<spiv> lifeless: ha, thanks :)
<Noldorin> jelmer, yes pushing as r46 works... will investigate the issue tomorrow; thanks!
<Noldorin> good night for now
<jml> loom is so close to being great
<jml> anyone seen mgz around recently?
<jelmer> jml: I think I talked to him last week
<GRiD> hi everyone. i'd like to try some bzr hacking. if anyone has any suggestions on a good starter bug for exploring the code base, let me know. otherwise i'll pick the first "easy" bug that makes sense to me.
<jelmer> GRiD: I think the bugs tagged "easy" are indeed the best place to start
<GRiD> jelmer, ok thanks
<dreamkxd> Is there anyone here to answer my bzr-svn problems?
<dreamkxd> Silence....
<jelmer> dreamkxd: can you be more specific?
<jelmer> dreamkxd: what is your question?
<dreamkxd> Well, I want to modify bzr-svn to handle multiple branch in an single path, where to start?
<dreamkxd> Or in other words, I want to ignore some content in svn branch. how to do that.
<jelmer> dreamkxd: those two things seem like different things
<jelmer> dreamkxd: what do you mean with multiple branches in a single path?
<dreamkxd> I think they can be handle in the same way.
<jelmer> ah, you're luoyonggan
<dreamkxd> Yes.
<dreamkxd> For example there is an path /branches/branchA/BranchB
<dreamkxd> ??
<jelmer> right
<jelmer> at the moment you would have a different layout for interpreting that layout differently
<dreamkxd> so, the files under BranchB should be fully ignore by branchA
<dreamkxd> yes. that's right, that's why such an condition appeared.
<jelmer> dreamkxd: that's not really possible without changing the mapping format, and breaking all existing revision ids
<dreamkxd> So, that's an impossible task?
<dreamkxd> almost?
<jelmer> dreamkxd: yes, and I don't really see the value of branches that exclude certain data. I don't think it's a natural way to work, because "svn co" works with full subtrees.
<dreamkxd> That's the problem, svn co works with full subtrees.
<dreamkxd> but bzr is dvcs. So it's didn't accept redundant data in the repo, or the repo will be very large.
<dreamkxd> that's the value of bzr-svn. and bzr-svn should be able handle such an condition.
<jelmer> dreamkxd: The problem with excluding certain files is that it creates different history
<jelmer> ergo, different revision ids that are incompatible with checkouts that do have all the files
<jelmer> Excluding things like big files seems like a better idea for just the working tree (which bzr already supports) or by using ghosts.
<jelmer> Sorry, I meant to say:
<jelmer> It seems like a better idea to just limit what files are created in the working tree (which bzr already supports) or by using ghosts.
<jelmer> dreamkxd: I don't have any objections to support for considering multiple things in a path branches
<dreamkxd> to specify the file name?
<jelmer> dreamkxd: but I don't think considering /branches/branchA/branchB a branch means that /branches/branchA would no longer include the contents of BranchB
<dreamkxd> I am just considerating the fact condition.
<jelmer> dreamkxd: what do you mean?
<dreamkxd> because at some time, and because the dirty part of svn, some one like to copy the full project B as an subdirectory of project A.
<dreamkxd> so when convert, we should exclude project B when converting project A.
<jelmer> dreamkxd: that makes it impossible to create sensible revision ids
<dreamkxd> That means /ProjetA/branches/ProjectA/ProjectBForEasyBuild copy from /ProjectB
<dreamkxd> no, I need only one thing, that's ignore all files under directory  /ProjetA/branches/ProjectA/ProjectB
<dreamkxd> we won't create rev id for projectB, because it's virtual, won't convert when we converting ProjectA
<jelmer> dreamkxd: sorry, but that means we change the contents of an existing revision (because we delete data from there)
<jelmer> dreamkxd: and that requires a format bump
<jelmer> dreamkxd: this would also be an issue for svn users of ProjectA
<jelmer> so is that really all that common?
<dreamkxd> common?
<dreamkxd> do you means that the data from bzr on an path is different from svn's path?
<jelmer> dreamkxd: that too
<dreamkxd> that's means the bzr's branch  /ProjetA/branches/ProjectA/ 's content is different to svn's /ProjetA/branches/ProjectA/ path? because ProjectB is removed from bzr? but bzr still have?
<dreamkxd> So what's they other problems? That will affecting bzr-svn's codebase a lot?
<jelmer> dreamkxd: I think this should be entirely different of your autolayout work, it's a lot larger project (and I don't think it's a good idea)
<dreamkxd> Er...
<jelmer> dreamkxd: you can't simply change what data bzr-svn imports for a particular revision-id; excluding a directory that older versions of bzr-svn do import will break.
<jelmer> dreamkxd: this is wholly different from layouts
<jelmer> dreamkxd: unless I'm misunderstanding what you're proposing
<dreamkxd> well, may patch won't affecting other layout's work.
<dreamkxd> I means, there current layout works as-is.
<dreamkxd> and only when using layout auto, we handle such a conflict.
<jelmer> dreamkxd: the layouts don't have any influence on the revision-id; the revision-id depends just on the repository UUID, revnum and path
<jelmer> dreamkxd: your layout can't adjust history, it can only help in what primary paths get imported as a branch
<dreamkxd> adjust history? what's that means?
<jelmer> dreamkxd: if you'd like to support multiple branches for a single path (e.g. interpreting both /branches/branchA and /branches/branchA/branchB as a branch) that should mostly be a matter of patching RepositoryLayout.parse() to return multiple results rather than just one
<jelmer> dreamkxd: however, even if you do that and somebody does "bzr branch <url>/branches/branchA" they will get a branchA bzr branch that has a "branchB" directory in it.
<jelmer> dreamkxd: does that make sense?
<dreamkxd> Er.. That's doesn't make sense.
<dreamkxd> except the orginal branchB and /branches/branchA is the same.
<dreamkxd> But that's almost impossible.
<jelmer> dreamkxd: Sorry, I'm having a really hard time understanding what you're saying.
<dreamkxd>  orginal of( branchB and /branches/branchA )
<dreamkxd> i means /prefix/branches/branchA copied form /prefix/trunk, and /prefix/branches/branchA/branchB both copied from /prefix/trunk.
<jelmer> in that case, "branchB" would still be a directory if you check out "/prefix/branches/branchA"
<dreamkxd> so bzr branch <url>/branches/branchA checkout withou direcotry "branchB" at most case.
<dreamkxd> yes, that's right.
<jelmer> dreamkxd: it will checkout *with* branchB
<dreamkxd> it possible checkout *with* branchB
<dreamkxd> and the possiblity of possible is very low. in most case, it's not.
<jelmer> no, it will always checkout with branchB. If you want to make the presence of branchB optional, you should work on per-file ghost support in bzr core first.
<dreamkxd> do you means geting directory branchB as an ghost, then the problem will be resolved?
<jelmer> dreamkxd: a ghost is basically something that bzr knows about but doesn't existing the repository
<jelmer> dreamkxd: a ghost is basically something that bzr knows about but which it does not actually have
<dreamkxd> indeed, i have no knowledge about ghost at all.
<jelmer> dreamkxd: it currently supports ghost revisions (e.g. holes in the revision graph) and in principle there are ghost files as well, though they aren't really supported at the moment.
<dreamkxd> So where to start? I means in the current codebase?
<jelmer> dreamxkd: in bzr-core. It would probably be very hard to implement them, but it's the right place to do it.
<jelmer> dreamkxd: It also will be hard to implement what you're proposing in bzr-svn, especially considering performance.
<dreamkxd> not in bzr-svn?
<jelmer> dreamkxd: well, it would require support from bzr-svn too, but that's a fraction of the work required in bzr.
<dreamkxd> I have to say, it's makes me afraid.
<dreamkxd> well, i have a simple hack to avoid this problem, just directly ignore branchA, getting it to be death, even lost some data, but at least it works.
<dreamkxd> btw, didn't bzr ghost works like svn-externals?
<jelmer> dreamkxd: getting to directly ignore branch*B* you mean?
<jelmer> dreamkxd: ghosts are different from externals; svn-externals are a lot like bzr nested trees.
<jelmer> although I guess in some regard ghosts can be seen as absent by-value nested trees
<jelmer> svn-externals are like by-reference nested trees
<dreamkxd> no, I means ignore branchA.
<dreamkxd> only perserve the last(tailing) one, so that's didn't need to ignore it's subdirectories.
<dreamkxd> for example /branches/branchA/branchB.
<dreamkxd> we won't create /branches/branchA, but branchB.
<jelmer> ah, ok. fair enough
<dreamkxd> I meet antoher problem under bzr-svn, when an branch X exist before, but then it's deleted, it won't be converted by bzr-svn, am I right?
<jelmer> dreamkxd: if you're referring to "bzr svn-import", it will only be converted if you specify --all
<dreamkxd> Ok. I see it.
<Noldorin_> hi jelmer
<jelmer> hi Noldorin_
<Noldorin_> jelmer, so i'm going to check into the issue now a bit :-)
<Noldorin_> jelmer, pushin r46 indeed works... btw how can i dpush to another remote branch?
<jelmer> Noldorin_: how do you mean?
<jelmer> Noldorin_: fwiw, you can also push to a local git repo
<jelmer> that might make testing easier
<Noldorin_> jelmer, exactly that...what's unclear?
<Noldorin_> ok sure
<jelmer__> Noldorin: if you want to push to a different branch, just specify a different URL
<Noldorin_> jelmer. how exactly does the URL change?
<jelmer__> Noldorin_: if you want to push to /tmp/some/repo, use "bzr dpush /tmp/some/repo"
<Noldorin_> wel...
<Noldorin_> git+ssh://git@github.com/alexreg/ircdotnet.git
<Noldorin_> jelmer, that pushes to master branch...how do i change that url for other branches?
<jelmer> Noldorin_: ah
<jelmer> Noldorin_: it's not possible to specify colocated branches to push to yet, that's one of the things I'm working on
<Noldorin_> jelmer, ah i see... Git/Hg have collocated branches but not Bzr right?
<Noldorin_> jelmer, will this feature be ready any time soon? :-)
<jelmer__> Noldorin_: There is a plugin that provides it for regular bzr branches (lp:bzr-colo)
<jelmer__> The work I'm doing is about adding it to the core, so it can also be used for other things like the bzr-hg and bzr-git plugins
<jelmer__> 20:19 <jelmer__> Noldorin_: There is a plugin that provides it for regular bzr branches (lp:bzr-colo)
<Noldorin__> jelmer, ah ok. do let me know when it's implemented please!
<jelmer__> Noldorin_: Subscribe to bug #380871
<ubot5> Launchpad bug 380871 in Bazaar "support for colocated branches" [High,In progress] https://launchpad.net/bugs/380871
<Noldorin__> jelmer, thanks
<Noldorin__> jelmer, it says fix released for bzr-git?
<Noldorin__> hmm oh well
<jelmer> Noldorin__: the required fixes for bzr-git have happened, but that doesn't really matter until the bzr part is there
<Noldorin__> jelmer, got it.
<Noldorin__> cheers
<Noldorin__> brb
<Kraln> what bug tracking software integrates the best with bzr? :)
<jelmer__> Kraln: Probably Launchpad
<Kraln> probably; what about self-hosted stuff
<jelmer> Kraln: I'm not sure; I know there is e.g. sloecode, I don't know if that does bug tracking though
<jelmer> Kraln: things like trac also have plugins that add bzr support
 * jelmer__ realizes he doesn't actually have a lot of useful info
<jelmer__> sorry
<maxb> What does 'lost connection during test' mean?
<maxb> https://launchpadlibrarian.net/76377611/buildlog_ubuntu-natty-i386.bzr-svn_1.1.0~bzr3767-1~bazaar1~natty1_FAILEDTOBUILD.txt.gz
<jelmer__> maxb: it's a subunit error
<jelmer__> basically, it can mean various different things - in this case I suspect it means that the test runner crashed
<maxb> worth retrying the build to see if it goes away?
<jelmer__> Is this using the latest subvertpy, 0.8.0 ?
<maxb> 0.8.3
<jelmer__> There were some ref counting issues in subvertpy fixed a while ago that were causing segfaults during the bzr-svn testsuite
<jelmer__> in that case, it's probably a new one :(
<poolie> hi all
<jelmer> g'morning poolie
<jelmer> how are you today?
<poolie> hi, welcome back
<poolie> good thanks
<poolie> going to do some reviews and piloting today
<poolie> my own queue is almost empty which is good
<jelmer> thanks, it's good to be back.. though I think I got quite a bit of stuff done last week too :)
<jelmer> poolie: thanks, I'll make sure to have a look at your MPs
<poolie> thanks, welcome back
<systemclient> how can I split my ./debian folder into a separate branch and move it out of the repository into a completely differnet folder?
<jelmer> systemclient: bzr split in your debian directory will create a separate branch
<jelmer> systemclient: after you commit that, you can safely "bzr branch /path/to/thefolder/debian /tmp/newlocation"
#bzr 2011-08-02
<systemclient> jelmer: thanks, I forgot the commit part â¦
<bob2> hah, awesome, google code is using dulwich for their git support
<lifeless> bob2: interesting
<kgoetz> jelmer: awesome. thakns for that (that being what you told systemclient) - i've been wondering that too
<poolie> o/ thomi
<RenatoSilva> is it possible to merge changes from a specific file?
<RenatoSilva> of a different branch?
<RenatoSilva> example branch 1 is a tree of dirs and files and one of them is foo. Branch 2 is contains only foo and I want to merge changes from branch 1, but only the foo file
<Noldorin> hey jelmer
<Noldorin> so co-located branches...what's the point?
<jelmer> Noldorin: hi
<jelmer> Noldorin: how do you mean?
<Noldorin> jelmer, i mean i am quite happy (prefer?) having all my branches in separate dirs
<Noldorin> is there any real reason to have co-located branches?
<Noldorin> appart from Git interop
<jelmer> Noldorin: you only need a single working tree for multiple branches
<jelmer> which means less disk space, and potentially having to recompile fewer files if you're in a C project
<Noldorin> jelmer, good point, i suppose.
<Noldorin> jelmer, will bzr-git allow pushing to co-located branches from separate local branches though?
<jelmer> Noldorin: sure
<jelmer> 'morning Riddell
<Noldorin> jelmer, oh great. :-) but that still requires bzr to get co-located brnaches support eh?
<Riddell> morning
<Riddell> I can't find my headphone/microphone :(
<jelmer> Riddell: it looks like it's just the two of us today, don't hurry
<Riddell> hmm, mumble freezes when I try to reconfigure it to my internal microphone
<jelmer> Riddell: please ping when you're ready, I'm putting down my headset for a bit, not sure how much battery it still has left
<jelmer> Riddell: we can also do skype if you prefer
<Noldorin> jelmer, which version is it on the roadmap of bzr for anyway?
<jelmer> Noldorin: probably 2.5
<jelmer> well, almost certainly 2.5
<Noldorin> jelmer, right, so i'll have everything i need then
<Noldorin> i'm guessing that will happen by end of 2011?
<jelmer> yeah, though the first 2.5 beta release is only a few months away
<Noldorin> oh cool
<Noldorin> and that will have co-located branches support in?
<Noldorin> official bzr-git integration would be nice heh.
<jelmer> Noldorin: official in what regard? what would that add?
<Noldorin> jelmer, well bzr-svn is. it would make it easier for everyone to push to git without going through the installation process
<Noldorin> saying that however...
<Noldorin> since bzr-windows got the site-packages/ dir everything is MUCH easier
<jelmer> Noldorin: bzr-svn is no more official than bzr-git
<jelmer> (or less official)
<jelmer> do you mean inclusion in the windows installer?
<Noldorin> jelmer, well official in the sense that it's included as standard with bzr installations
<jelmer> Noldorin: That's only really relevant for the windows installer
<jelmer> Noldorin: Once the kinks with running bzr-git on windows are ironed out, I think it would be a good idea to propose it for inclusion in the windows installer.
<Riddell> jelmer: let's do skype, I'm jriddell
<Noldorin> jelmer, oh right, i see now
<Noldorin> jelmer, that's good to know. :-)
<Noldorin> jelmer, btw sorry i haven't had much time...will be looking into that issue i'm having soon
<jelmer> Noldorin: in that regard, it would also be useful if you can write down your experiences so the bzr-windows-installer folks can use them when adding bzr-git support
<Noldorin> jelmer, definitely. will do that blog post once all is working. remind me if i forget :-)
<Riddell> jelmer: bug 816376
<ubot5> Launchpad bug 816376 in bzr-builddeb "bzr bd-do for full source packages" [Low,Triaged] https://launchpad.net/bugs/816376
<Riddell> https://code.launchpad.net/~jr/qbzr/785967-ghost-revisions-in-qlog/+merge/69798
<maxb> jelmer: fyi a retry of that bzr-svn 'lost connection' build succeeded. So now all I have to do is backport debhelper 8.1.0 to <<natty, and the beta ppa should be in sync with sid
<maxb> oh, no, I forgot the bzr-builddeb fail
<jelmer> maxb: which fail?
<jelmer> missing python-lzma?
<maxb> bzr-builddeb 2.7.7 FTBFS on <= maverick due to test failures due to missing pristine-tar lzma support.
<maxb> is what I wrote down about it when investigated
<maxb> *ing
<maxb> Should just be a matter of guarding tests with an appropriate feature, I hope
<jelmer> hmm, hanging up skype calls with "pkill -9 skype" is sort of suboptimal
<jelmer> maxb: pristine-tar doesn't have lzma support nowadays either
<jelmer> though it may have some way of dealing with unknown formats (such as lzma)
<bigjools> guys, is there a way to remove orphan revisions in a shared repo?
<jelmer> bigjools: not really, there are plans for a "bzr gc" command. Until then, the best way is to create a new shared repo and cloning the branches you care about into that.
<bigjools> jelmer: ok thanks
<bigjools> I think that's what I did last time :)
<jelmer> Riddell: did you still need a review of that qbzr branch?
<jelmer> I can't find it in the +activereviews queue
<Riddell> jelmer: no alex did it
<lifeless> jelmer: hi
<lifeless> https://launchpad.net/bugs/819604
<ubot5> Ubuntu bug 819604 in Bazaar "when an idle ssh transport is interrupted, bzrlib errors" [Undecided,New]
<lifeless> ok, internet fail
<jelmer> Riddell: cool
<lifeless> jelmer: hi
<lifeless> https://launchpad.net/bugs/819604
<jelmer> lifeless: thanks though, I got the bug #
<lifeless> jelmer: any chance that can get prioritised ?
<jelmer> lifeless: yep
<jelmer> (wrapping up some Launchpad QA at the moment, but I'm following what's happening on -ops)
<lifeless> jelmer: awesome, cool
<Riddell> would be good to have a review of this https://code.launchpad.net/~jr/bzr-explorer/814408-lock-contention/+merge/69653
 * jelmer looks
<exarkun> What's going on here?  $ bzr branch dummy a
<exarkun> bzr: ERROR: The branch dummy has no revision None.
<exarkun> Hmmmmmm
<exarkun> Something about shared repositories
<jelmer> exarkun: branch moved out of a shared repo manually?
<jelmer> hey mwhudson
<exarkun> Yes, that was it
<mwhudson> jelmer: hello
<jelmer> mwhudson: you're up late :)
<mwhudson> jelmer: i'm in the uk :)
<jelmer> Riddell: reviewed; I'm not sure about what the right thing is to do when refresh() is hit instead.
<jelmer> Riddell: what do you think?
<jelmer> mwhudson: ahh
<Riddell> jelmer: I'm not sure we have better options, on the other hand I don't think it happens much, this is a long standing problem but people only noticed it when I added the auto-refresh feature
<jelmer> Riddell: ah
<jelmer> Riddell: for auto-refresh I certainly think it makes sense to silently ignore lock retention problems
<Riddell> where would be the best place to put out a notice about bug 814408 ?  I think it's important enough to notify the bzr explorer packagers
<ubot5> Launchpad bug 814408 in Bazaar Explorer "Exception "bzr: ERROR: Could not acquire lock" occurs very often. " [High,Fix released] https://launchpad.net/bugs/814408
<Riddell> on the qbzr mailing list?
<jelmer> Riddell: there is also a bzr-packagers list, that might be most appropriate if you want to inform the packagers
<Riddell> so there is
<Riddell> if I have a trivial change to bzr that doesn't need approval what's the easiest way to get it into trunk?
<Riddell> do I have to do a merge proposal and self approve and send to pqm?
<mgz> that's what I generally do.
<mgz> I find pushing lp:~gz/bzr/trivial_whatever and proposing, accepting, and running feed-pqm is easy enough I've never looked into the hydrazine bypassing methods
<henninge> Hi!
<henninge> How do I fix a pipeline after I removed a pipe (not remove-pipe but removed the directory) ?
<henninge> I now get "Not a branch: " errors when I do a  show-pipeline.
<mgz> no idea, I'll try searching the mailing list archives
<jelmer> abentley: ^
<abentley> henninge: You edit .bzr/branch/branch.conf in the neighbouring pipes to remove references to the missing pipe.
<henninge> abentley: thanks!
<abentley> henninge: if the pipe was in the middle, you'll need to fix the remaining pipes to point to each other, or else you'll have two disconnected pipelines.
<henninge> it was at the end but thanks
<abentley> henninge: were you deliberately avoiding remove-pipe?
<henninge> no, I was cleaning out unsused branches from my repository and forgot that this one was part of a pipeline.
<henninge> abentley: now that you mention it, I don't think remove-pipe --branch ever worked for me - the branch always remained.
<abentley> henninge: Odd.  I don't use it much, but I'll check it.
<henninge> abentley: worked now. Dunno what I was remembering there ...
<abentley> henninge: Cool.  I imagine you'd still prefer if there was a "repair" command?
<mwhudson_> if i want to list the files in a directory in a tree, what's the easiest api to use?  list_files(recursive=False)?
<mwhudson_> there is also iter_children
<henninge> abentley: yes, that is really missing.
<abentley> mwhudson_: I would say list_files(recursive=False)
<mwhudson_> abentley: ta
<exarkun> I want to try the bzr beta but apt wants to uninstall bzr-svn in order to upgrade to bzr from the beta ppa
<exarkun> just a fact of life?  or what?
<exarkun> okay, out of time.  filed https://bugs.launchpad.net/bzr/+bug/819964 sort of relatedly.
<ubot5> Ubuntu bug 819964 in Bazaar "bzr: ERROR: No such file: .../.bzr/repository/indices/...rix" [Undecided,New]
<ablmf333> I tried to use bzr to merge 2 svn branches.  And something went wrong.  Now I can't use "bzr branch/checkout" to get a new copy from svn.
<ablmf333> The error is : InvalidBzrSvnRevision: Revision id xxx@gmail.com-20110801193839-e85w184hqg35dxjy was added incorrectly
<ablmf333> Is there any way to clean up bzr's local cache of svn and let me get a fresh new checkout from svn?
<ablmf333> nvm, I found it.
<SpamapS> I'm having trouble with bzr import-dsc in Oneiric.. http://paste.ubuntu.com/657500/
<krow> Are nested repositories (i.e. hg sub repositories) working at this point? The website is confusing on this point.
<thumper> krow: I don't think they are
<RenatoSilva> is it possible to merge a single file?
<AnAnt> Hello, I lost a couple of .pack files, how can I fetch them from repository ?
<systemclient> is it a problem if I use bzr 2.1.2 (debian stable) on Branches created with 2.3.1 (ubuntu natty)?
<beuno> systemclient, no, it should be fine
<systemclient> beuno: where can I find the striking differences between the version?
<beuno> systemclient, not sure, but in the source tree, the NEWS file keeps track of all the changes
<beuno> too fine-grained for what you're looking for, I'm sure
<systemclient> beuno: I just care for my commits to be safe, that is all
<beuno> systemclient, there haven't been any format changes since 2.0, so you can safely use those 2 versions
<beuno> and even if there are format changes, nothing will break
<systemclient> beuno: even going down?
<beuno> systemclient, yeap, bzr won't break things. Ever.
<systemclient> beuno: +1 for bazaar then!
<systemclient> it would be intersting if git behaves the same way
<systemclient> so bzr would just say "I do not know this typo of repo, exiting"?
<jelmer> systemclient: yeah
<poolie> hi all
<poolie> hi jelmer?
<jelmer> hi poolie
<poolie> hi there
<RenatoSilva> ~offtopic: how can this *diff between pacthes* result in *the same* patched file? http://pastie.org/pastes/2311489/text
#bzr 2011-08-03
<poolie> jelmer, so i was going to say,
<poolie> the connection going idle is a nice straightforward clue it can be migrated to another back end
<poolie> which is actually what we want to have happen
<jelmer> poolie: that makes sense
 * jelmer tries to imagine how this works on a code level
<poolie> so one thing is we ought to be able to distinguish "connection dropped as we were starting to send" from dropping at any other time
<poolie> which may be harder to cope with
<poolie> but this should mostly produce the first case
<poolie> if we can detect it we should be able to build a new lower-level object wrapping the ssh connection
<poolie> 'medium' i think
<jelmer> poolie: ok, so there's a fair bit of code we'd probably have to wrap to make sure it retries as necessary
<jelmer> that seems reasonable
<poolie> mm
<jelmer> at least in theory :) it might be tricky to handle all the odd cases
<poolie> it does feel like it might
<poolie> i think we want to be careful about not having retry code scattered all over the place
<poolie> i'm thinking of something like an erlangish supervision pattern where a lower level object dies cleanly, and then a higher one restarts a new instance
<jelmer> it seems like most of the remote code all goes through RemoteTransport._call*, which then does a call on self._client
<jelmer> it seems like that would be the right place to transparently create a new self._client as necessary
<jelmer> RemoteTransport also has the right data (and SharedConnection) to create the new connection for the client
<poolie> that sounds right
<poolie> and that puts it at just one bottle neck, not all over
<poolie> we might need a special exception for a clean disconnect saying it can be retried
<poolie> maybe we should retry it always
<jelmer> poolie: I wonder if that wouldn't make it seems sluggish if e.g. you get disconnected and bzr silently tries to connect again but e.g. has to wait for things like DNS to time out
<jelmer> maybe we should just try it out
 * jelmer gets some sleep
<stylesen> poolie: ping
<poolie> hi there
<stylesen> poolie: pm?
<poolie> yep
<thomi> poolie: ping?
<poolie> hi thomi, on the phone atm
<thomi> no worries.
<poolie> thomi, your patch landed, or at least one of them did, yay
<thomi> poolie: I saw that, thanks!
<thomi> I'm integrating your latest suggestions to the other - I wanted to ask you about the factory methods to replace The *Store classes in config.py
<poolie> ok
<poolie> will be with you soon
<thomi> oh, sorry
<poolie> np
<poolie> hi thomi
<thomi> Hi
<poolie> i'll just reply on the mp
<poolie> thanks for coming back on it
<thomi> no worries, I was hoping to get it done sooner, but work happened.
<Riddell> hola chicos
<Noldorin> jelmer, hi
<jelmer> hi Noldorin
<Noldorin> jelmer, was just going to ask...how do i set up a local repo for testing this issue?
<Noldorin> jelmer, i thought just a git init was required...but maybe not
<Noldorin> jelmer, perhaps you can let me know anyway. feel free to send me an email :-)
<Noldorin> i'm off to bed now.
<Noldorin> g'night
<jelmer> Noldorin: bzr init should create a branch. I realize it looks a bit odd
<jelmer> Noldorin: "git init /tmp/foo; bzr init /tmp/foo; bzr dpush /tmp/foo"
<Noldorin> jelmer, oh they have to be the same dir eh?
<Noldorin> git and bzr
<jelmer> Noldorin: no
<jelmer> Noldorin: but "git init" only creates a repository, not a branch
<jelmer> Noldorin: bzr init creates a (git) branch in the repository
<Noldorin> so how do i create the branch?
<Noldorin> ohh
<Noldorin> i see
<Noldorin> jelmer, that is very odd :-S
<Noldorin> jelmer, surely there is a git command to do the same?
<Noldorin> never mind though
<Noldorin> bzr: ERROR: No module named posix
<Noldorin> when i bzr init
<Noldorin> oh well
<Noldorin> jelmer, talk to you tomorrow i guess
<Noldorin> bye
<exarkun> Anyone have any suggestions about installing beta bzr from the ppa on Lucid without first uninstalling bzr-svn?
<exarkun> http://codepad.org/66u1Vy1A
<jelmer> maxb: ^
<maxb> Oh, right, because I haven't got the debhelper backport in place to build subvertpy to build bzr-svn
<maxb> exarkun: You'll have to uninstall bzr-svn for now
<exarkun> I'll wait.  I can't test what I want to test without bzr-svn.
<chrisvj> I have a script for a CIA commit bot. How do I add it to bazaar?
<maxb> OK, that's weird. I'm getting a UnicodeDecodeError inside chk_serializer.py trying to commit a trivial merge, in an UDD branch of debhelper.
<mgz> maxb: I love such things, any more details?
<maxb> mgz: Turns out it's bzr-builddeb's fault
<maxb> Not only is it specifying a fixed commit message, it's specifying it as a non-ascii bytestring
<mgz> eugh, I wish those kinds of errors didn't reach as deep into bzrlib
<maxb> exarkun: beta ppa bzr-svn now updated
<exarkun> awesome, thanks
<poolie> hi maxb, exarkun
<maxb> Hello
<maxb> Right, beta-ppa is now fully installable
<poolie> excellent
<poolie> i hope we can set up a babune job to test that soon
<maxb> Now all we have to do is shepherd plugins on snapshot versions toward real releases
<poolie> mm
<poolie> real releases for oneiric, or for o+1?
<maxb> I think we should do it for oneiric
<maxb> After all, cutting a release of a current trunk shouldn't be a challenging task
<poolie> right
<poolie> so that's, fastimport, git, gtk, loom, pipeline, pqm, svn, upload, loggerhead
<poolie> are they all passing their tests, i wonder?
<poolie> it would be nice to get them there before releasing
<maxb> Yes, I think everything is running tests during package build now, so we'd see FTBFS in the PPA if not
<poolie> oh, ok
<maxb> uhoh
<maxb> daily ppa looks less than happy
<maxb> many tests failing on older ubuntu distroseries only
<poolie> hm, a few failures
<poolie> some look like version skew with meliae
<poolie> do you have a special trick to get the failures out of the build logs?
<poolie> all i mean is, it's  a shame it doesn't just show you the errors
<poolie> i find the build failure mails nearly pointless
<mgz> are the new canonical lp links meant to have the tilde escaped in them?
<mgz> just noticed bzr+ssh://bazaar.launchpad.net/~testtools-dev/testtools/trunk/ no longer exists and I need bzr+ssh://bazaar.launchpad.net/%2Bbranch/testtools/ instead
<mgz> a newer version of bzr might not have that issue...
<poolie> hi mgz
<poolie> %2b is a plus not a tilde
<mgz> ah, right. still doesn't need escaping in that portion of the url.
<mgz> but I guess not a change from before.
<poolie> so, it's a way of saying "the default branch for testtools"
<poolie> yeah, i don't think it does
<poolie> i think + only needs special treatment in a query parameter?
<mgz> yup.
<mgz> which... does ssh even have as a concept?
<poolie> hopefully not ;)
<poolie> but we don't currently have, and probably don't want, different escaping rules depending on the scheme
<poolie> so, in short, we could print that as a + in unescape_for_display or similar
<mgz> I think I was just getting confused over the ~ vs %7E issues and the url I had stored going stale
<mgz> ...but prettier display is always good :)
#bzr 2011-08-04
<maxb> I previously planned to work on getting the %2B displayed unescaped, until I got scared off by the problems %7E vs. ~ was causing
<maxb> But yes, there's no real justification for escaping that +
<poolie> abentley: hi?
<abentley> poolie: hi
<poolie> hi i think i have better tc instructions, i was wondering if you could try them on your machine
<abentley> poolie: sure thing.
<poolie> http://doc.bazaar.canonical.com/bzr.dev/developers/testing.html#simulating-slow-networks
<poolie> basically, just omit the third line
<poolie> i think that's all that's needed
<poolie> like http://typewith.me/7hBAzi2MYN
<abentley> poolie: tc qdisc add dev lo parent 30:1 handle 40: prio
<abentley> RTNETLINK answers: Operation not supported
<poolie> yeah, leave that one out
<poolie> just add the root discipline, the netem, and then the filters
<abentley> poolie: If I continue, it errors: http://pastebin.ubuntu.com/658315/
<poolie> oh, omit the 'handle 800::800'
<poolie> i realize randomly cutting things out does not generally seem to work but in this case it does  :)
<poolie> i think more stuff is now done automatically and is no longer allowed to be done manually
<abentley> poolie: The typewith.me version doesn't error for me.
<poolie> hooray
<poolie> and does it work?
<poolie> presumably you'll want different ports to 4155
<abentley> poolie: dunno, I don't have anything on 4155 :-)  Let's try again with 80...
<poolie> you might need more than 500ms for it to be clearly visible
<mgz> poolie: when you have a moment, do you have the new PQM output for <lp:~mbp/bzr/test-errors>?
<spiv> If you can't notice 500ms latency then you aren't making enough roundtrips ;)
<abentley> poolie: I think it's working.
<mgz> I'd like to build of that branch to resolve some remaining issues and get it landed at last.
<poolie> btw i'm so happy to hear of lp people testing with that
<poolie> were you going to use it for html/js ui stuff, or something else?
<poolie> mgz, sure, me too
<poolie> mgz, i put it on the mp; it looks very similar to what happened before
<poolie> abentley, thanks, i'll update the bzr docs
<abentley> poolie: yes, it's working.  Thanks!
<poolie> https://code.launchpad.net/~mbp/bzr/doc/+merge/70386
<mgz> poolie: thanks! I'll have a crack at that tomorrow.
<poolie> thanks for fixing the knownfailure mismatch
<poolie> i think there's a bug for that?
<GRiD> hi poolie, did you have a moment to talk about bug #54624?
<ubot5> Launchpad bug 54624 in Bazaar "warn when committing large (binary) files" [Medium,Confirmed] https://launchpad.net/bugs/54624
<poolie> oh hi
<poolie> sure
<poolie> so, you asked about doing it from 'add'
<poolie> in bzr, add just means 'mark this as versioned' of course
<poolie> so, we could usefully give a warning there i suppose
<poolie> but, perhaps people also want to be warned if an already-added file grows very large?
<poolie> maybe not
<GRiD> ah, hadn't thought of that
<GRiD> well, the original idea seemed to be to prevent people from adding large files they didn't really mean to
<poolie> yeah, i think you're right
<poolie> also it's a bit easier to undo at that point
<poolie> and just a warning will do
<GRiD> ok, so it seems it should check the file during the list it's running through during an add, and warning at that point, skipping it if it's over the threshold.. ?
<GRiD> which should probably be configurable
<poolie> yes
<poolie> and this needs to cover files implicitly added by recursion
<GRiD> i hadn't dug into it, but it seemed there was a per branch config file. is that the right place?
<poolie> that sounds good
<poolie> you should get the branch config stack, which will look there and in the globla config etc
<GRiD> ok. and how are those adjusted usually - by manually editing a file? should there be a command line to override and force this?
<poolie> either by editing the file or by 'bzr config' or the gui
<poolie> there's a separate bug about adding a command line option to set config flags
<poolie> so, i wouldn't worry about that right here
<GRiD> ok
<GRiD> ok, so i'll work something up and push it early to a branch for review, like you mentioned.
<poolie> cool, thanks
<poolie> don't feel it has be perfect before you ask for review
<poolie> i have to go out in a bit but i'll be back within about 2 hours
<poolie> i'm going to do lots of reviews today
<GRiD> ah well it's night for me, i wouldn't have anything before tomorrow at least
<poolie> hi thomi
<thomi> hi poolie
<thomi> poolie: I notice that the diff on my lp merge proposal has merge conflict markers in it, but they're not in my local branch. LP bug perhaps?
<thomi> also, if you're happy with my latest suggestion I'll go ahead and push that up now
<poolie> thomi: i guess those conflicts are because the trunk changed since you started
<thomi> poolie: oh, of course. Sorry, it's been a long week ;)
<poolie> np, thanks for the patches
<thomi> hmm, in trunk there's a half-written docstring in config.LocationStack that's causing the conflict.
<thomi> poolie: are you happy with the approach I took in the config stuff? I'm done for the evening, but if you'd like me to change them let me know and I'll do final tweaks tomorrow.
<poolie> i haven't reread the patch yet but it sounded good
 * poolie looks now
<maxb> jelmer: hi. do you think we should care about shipping subvertpy 0.8 and bzr-svn 1.1 for hardy?
<jelmer> hi Max
<jelmer> maxb, I guess so, is there anything in particular that makes it hard to build subvertpy 0.8 on hardy?
<maxb> jelmer: debhelper 8.1 :-)
<poolie> hi jelmer!
<poolie> hi maxb
<jelmer> hi poolie
<jelmer> maxb: ah, argh
 * jelmer tries to remember what we need 8.1 for
<poolie> wow
<poolie> ok, that's confusing
<poolie> oneiric's unity shows the wrong title bar text
<poolie> or, slightly out of date
<poolie> that was nearly embarassing
<jelmer> ouch
<jelmer> I'm finding unity fairly bleeding edge in oneiric too
<poolie> it still says #canonical when i've clicked in to #bzr
<poolie> i'm just going to file about that then perhaps you can help me with something small
<fullermd> Are we expecting a 2.4 RC sometime, or is .0 final the next up?
<poolie> .0 is next unless there's a showstopper
<poolie> vila should be back from his break in a day or two
<poolie> did you want to put something in it in particular?
<poolie> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/820836
<ubot5> Ubuntu bug 820836 in unity (Ubuntu) "window title gets out of date" [Undecided,New]
<fullermd> Nah, just curious.
<vila> hi all !
<fullermd> Speaking of the devil...
<vila> hmm, should I read the logs or can I get a summary ? ;)
<jml> mgz: welcome back
<fullermd> vila: Oh, nothing too interesting really.
<fullermd> 04:49 <poolie> vila should be back from his break in a day or two
<jml> mgz: I hope my fix for testtools actually fixed it, I don't have a windows install to test against
<fullermd> Apparently, 13 minutes is a day.  Or maybe two   ;)
<mgz> jml: thanks for the quick fix, I can pull again
<vila> hehe, I'm back online but working from a friend's place, network needs to be tweaked, should be done soon
<jml> mgz: cool.
<vila> poolie: still around ?
<jml> mgz: fwiw, I want to get the unicode bugs fixed, and then release asap
<poolie> hi vila, welcome back
<vila> jml: same here (but different project ;)
<poolie> otp with jelmer atm
<vila> ok
<mgz> jml: that sounds good. I've got some ugly things I can do to make doctest work, can propose those and see how horrible you think they are
 * mgz waves at vila
<jml> mgz: cool.
<vila> mgz: _o/
<jml> mgz: now that I have an actual reliable way to run the tests across lots of Pythons, I feel much better about the whole thing
<jml> oh
<jml> never mind
<mgz> well, that's also a good thing ;)
<cheater> hi
<cheater> how do i set up a bzr workflow where i can do local commits?
<LeoNerd> bzr unbind  ?
<LeoNerd> Or just  ci --local
<LeoNerd> I usually opt for the latter on my laptop when I'm on the train
<LeoNerd> then just  push  it later online
<jpds> cheater: Isn't that the default?
<jpds> With bzr branch?
<poolie> the easy answer is to just branch and then you can commit locally
<poolie> hi vila?
<maxb> jelmer: For building subvertpy-dbg, and not having the #! lines sometimes point to the dbg python?
<maxb> Anyway, I'm not too concerned, given I've already backported dh 7.3.15 to hardy .... 7.3 -> 8.1 can't introduce that many more requirements, right? :-)
<jml> mgz: I feel like I'm still missing something re bug 804127
<ubot5> Launchpad bug 804127 in testtools "assertThat(..., verbose=True) sometimes generates unprintable AssertionErrors" [Medium,Triaged] https://launchpad.net/bugs/804127
<jelmer> maxb, :)
<poolie> hullo jml!
<jml> mgz: I guess Mismatch.describe() has a poorly defined interface, since it's not clear if it returns bytes or unicode
<jml> poolie: hi :)
<poolie> ... "sometimes generates unprintable comments from developers"
<jml> poolie: hah
<jml> poolie: you'll like the new release actually, it's much less noisy. much better errors (when they work)
<poolie> oh excellent
<poolie> mgz and i were working on a branch to suppress some of the bzr-side noise
<jml> mgz: but perhaps you mean something else by not having a clear interface
<jml> gahr. I should reply to the comment. I always hate it when people take things to IRC & then don't update.
<poolie> vila, hi?
<mgz> jml: right, if it's not clear what describe is allowed to return, you'll risk mixing non-ascii byte strings and unicode strings
<mgz> okay, I need to nip out for a bit now, will be around again later
<jml> mgz: cool. I'll update the bug report. Am keen to get this one nailed.
<cheater> jpds, oh, i did bzr checkout.
<cheater> thanks guys.
<jml> mgz: thank you again for helping!
<jelmer> cheater: bzr checkout creates a branch that's bound to the master branch, so every commit automatically goes there as well. bzr branch creates an independent branch.
<poolie> night all
<cheater> jelmer, gotcha :)
<exarkun> oops, looks like bzr-hg plugin is not happy with beta bzr (or maybe I need beta bzr-hg to go with it)
<exarkun> What's the quickest way to toggle a bzr plugin on and off?
<exarkun> moving it out of the plugin directory I guess
<jelmer> exarkun: yeah, either that or setting BZR_DISABLE_PLUGINS=hg as environment variable
<vila> jelmer: what happened to the idea of making tag fetching optional for 2.4 ?
<vila> jelmer: and more to the point should I delay the 2.4.0 release because of it ?
<jelmer> vila: hey, welcome back!
<vila> :)
<jelmer> vila: Did you have a good vacation?
<vila> yup, tons of hot weather
<jelmer> \o/
<vila> I'm in Val's baggages visiting a friend in Bretagne where the weather is.... different ;)
<jelmer> Bretagne, nice :)
<jelmer> Well, if the weather is nice :)
<jelmer> vila: there hasn't been much progress on making tag fetching optional, as it's been pretty quiet around here
<vila> yeah, it rains only once a year
<jelmer> vila: I do think we really should make it optional before 2.4.
<vila> but it almost never stops ;)
<jelmer> vila: hehe
<vila> jelmer: ok, so I should postpone the release for a week then
<vila> jelmer: do we have a bug number for that ?
<jelmer> I don't think we do yet
<vila> ok
<vila> anything else I should be aware of ? (I haven't read all backlogged mail yet)
<vila> (but noticed babune being red in anger all over the place ;)
<jelmer> vila: Yeah :-(
<jelmer> vila: The other big news is that haproxy is now enable for codehosting \o/
<vila> \o/
<jelmer> there is one bzr bug related to that, but it's been present for a while so I'm not sure how important it is to fix before 2.4.0
<jelmer> bug 819604
<ubot5> Launchpad bug 819604 in Bazaar "when an idle ssh transport is interrupted, bzrlib errors" [Critical,Confirmed] https://launchpad.net/bugs/819604
<jelmer> vila: I vaguely recall you had some plans for running the tests against bzr.dev on babune, is that correct?
<vila> jelmer: err, babune is running all tests against bzr.dev :) Which tests are you reffering
<vila> referring to ?
<jelmer> vila: sorry, I meant plugin tests
<vila> ha, right, yeah, still planned, no ETA ;-}
<abetterlie> hey all, I have a quick question about push-and-update plugin
<abetterlie> I'm running bzr 3.2.1, and I moved the __init__.py and the push_and_update.py to my .bazaar/plugins
<abetterlie> and no matter which transport I use, either bzr+ssh or sftp, I get This transport does not update the working tree of  bzr+ssh://matt@192.168.12.164/etc/puppet/
<abetterlie> can anyone explain how to use this plugin?
<abetterlie> ... please?
<jelmer> hi abetterlie
<jelmer> abetterlie: You need to add the plugin directory as a whole to ~/.bazaar/plugins
<abetterlie> ah
<abetterlie> ok
<abetterlie> and it also needs to be renamed push_and_update, because - is not allowed for some reason
<abetterlie> weird, becuase I have some precommit hooks that are bare .py files in .bazaar/plugins and they work just fine
<fullermd> That only works if $pluginname is entirely contained in $pluginname.py
<abetterlie> I see.
<abetterlie> when I push, bzr is still spitting errors, but the plugin seems to be working fine.
<abetterlie> should I file a bug?
<fullermd> It'd be an enhancement, maybe.
<fullermd> bzr's push still doesn't do anything with the remote working tree.  The plugin just makes it so when you run 'push', it does bzr's push and then _also_ does something else that does the update.
<fullermd> I could see arguments both ways about supressing the message.  Not sure how easy it would be to do.
<fullermd> Hm.
<fullermd> https://bugs.launchpad.net/bzr-push-and-update/+bug/360521
<ubot5> Ubuntu bug 360521 in Plugin to Update Remote Trees "Warning about working trees not updating not suppressed" [Medium,Fix committed]
<fullermd> That sounds like it should already be there.
<abetterlie> ah
<abetterlie> that's the one
<abetterlie> http://pastebin.com/XU9ybkka
<abetterlie> I don't see why it was ever changed from a seprate command push-and-update
<eridu> is there any way to disable SSL certificate checks in pycurl, or to enable authentication caching in urllib2?
<poolie> hi all
<jelmer> mÃ¸rning poolie
<poolie> moin
<GRiD> hello
<poolie> hi grid
#bzr 2011-08-05
<GRiD> poolie, is there a specific test (or test type) you recommend i look at as a pattern for creating the large-file-add test? is the shell-like interface appropriate?
<poolie> hi grid, i think that would be a reasonable way to do it
<GRiD> ok, i suppose it makes sense to add it to blackbox/test_add.py even
<poolie> so, pros and cons
<poolie> using shell-like tests:
<poolie>  - tests most of the stack integrated together
<poolie>  - therefore catches integration bugs
<poolie>  - and also is slower
<poolie>  - is a somewhat less precise mechanism for setting things up and evaluating them
<poolie>  - requires less prior knowledge
<poolie> so... for a first patch overall it's pretty good
<poolie> if you wanted to cover dozens of different cases probably using api tests would be better
<GRiD> ok thanks. tomorrow (fri) is the first chance i'll get to write some code so i'll see how it goes, maybe have some questions.
<poolie> cool
<poolie> i hope you enjoy it, ask here on the list if you want
<thomi> Hi
<TiffanyAngel87> Suppose I have some revision X and it's ruining my life, how do I revert just those changes?
<AfC> TiffanyAngel87: and X is not the latest revision?
<TiffanyAngel87> AfC: correct
<AfC> TiffanyAngel87: you have to commit the "reverse" of what that revision introduced.
<AfC> TiffanyAngel87: you do that by using merge, backwards:
<AfC> if X is 47
<AfC> say
<AfC> then
<AfC> $ bzr diff -r 46..47
<AfC> shows you the change set introduced by (resulting in) that revision (state)
<AfC> TiffanyAngel87: right?
<TiffanyAngel87> with you so far
<AfC> so, to get rid of it, you merge the inverse. You can first see that with
<Noldorin> jelmer, hi?
<AfC> $ bzr diff -r 47..46
<AfC> (note the + and - inverted)
<TiffanyAngel87> ohhhh
<AfC> but to do it, use merge
<TiffanyAngel87> then patch -p0?
<AfC> no merge:
<AfC> $ bzr merge -r 47..46
<AfC> [that's implicitly "from this branch"]
<AfC> $ bzr merge -r 47..46 /path/to/branch
<TiffanyAngel87> I'll give it a try. Thanks!
<AfC> would have pulled that delta from somewhere else
<TiffanyAngel87> the reverse merge is effectively the same as the diff and patch, right?
<AfC> I'll let someone else answer that; my belief is that there's more to it than that
<AfC> ie, merge can be (dramatically) smarter about base revisions, ancestors, etc
<AfC> There's a reason we don't throw history away in Bazaar land
<TiffanyAngel87> cherrypicks don't carry their history though, right?
<TiffanyAngel87> well, I'll try it :)
<AfC> Don't forget to `bzr commit` the merge once you've reviewed its impact;
<AfC> and `bzr revert --no-backup` if you screwed up and need to retry.
<AfC> TiffanyAngel87: no, cherypicks don't, but they merge logic can still be [much] smart about what to do and how to apply the delta [especially normal forward cherry picks]
<TiffanyAngel87> makes sense
<TiffanyAngel87> AfC: I think that worked. And no conflicts thank god. thanks
<poolie> vila, hello?
<poolie> thomi: hello?
<thomi> Hello
<vila> hi all !
<vila> thomi: hi, thanks for your work on the system config file, can we talk about it here or is it too late for you (what TZ are you in by the way ?) ?
<thomi> I'm in New Zealand, so +1200 I think (or maybe +13? +11?)
<thomi> by all means...
<thumper> +12
<thumper> +13 in summer
 * thumper leaves
<thomi> Thank you thumper.
<vila> thomi: I haven't look in details so far, but roughly the missing parts are:
<vila> 1) I suspect the tests are not isolated yet and use the real /etc/bazaar.conf if it exists (instead of one specific to tests)
<vila> 2) the 'bzr config' command needs to taught about this new file (which means some heavy lifting)
<vila> 3) I'd strongly prefer if this new config file were implementing the planned features  (path matching mainly) rather than duplicating the actual bazaar.conf
<vila> (3) could be simplified as a first step by duplicating branch.conf instead and forget about path matching as a first step
<thomi> okay...
 * thomi thinks
<vila> thomi: roughly, it means, the new file can be used for any options without any section
<vila> thomi: will that match your intended use ?
<thomi> sure, I'm just hacking this for fun, we don't need this for sloecode...
<vila> ha, cool :)
<thomi> so the plan regarding "bzr config" is to make the confi command use the new file, and then at some point in the future port the config command to use the new Stack API?
<thomi> ...or do we port bzr config to the Stack-based API now?
<vila> that would be a different merge proposal, but yes, the plan is to move to the stack-based API asap
<vila> I haven't considered doing it so far because I wanted to migrate all the existing options first
<vila> but your proposal triggered a new way to think about the whole issue and may be we can use the system wide config to drive the introduction of the new features
<thomi> ...but won't moving to the stack-based API give you access to the new system config file? I'm not sure what needs to be done for (2) in that case...
<vila> right
<vila> bzr config has a few needs that are not covered yet
<vila> from the top of my head: iterating all options returning (config-id, section, name, value)
<thomi> okay, that makes sense.
<thomi> just to make sure I'm not missing something, PathMatcher does not currently exist, right?
<vila> indeed
<vila> there are various candidates PathMatcher, URLMatcher, AbsolutePathMatcher, RelativePathMatcher
<vila> I don't think we need all of them ;)
<vila> but from a user point of view they address different needs
<thomi> okay - I think I need to read the devnotes a couple more times :) I'll start by refining the unit tests and seeing how I can modify bzr config
<thomi> Should be able to make some progress this weekend.
<vila> cool, I'll try to define a clearer roadmap for the missing bits and work on migrating more options myself
 * vila hunts coffee
<thomi> hah
<thomi> On an unrelated note, is there an example someone can point me at of calling loggerhead to render *part* of an HTML page? I.e.- calling it from within another WSGI app?
<thomi> It must be do-able because LP does it for merge proposals, but launchpad code makes my head hurt.
<poolie> thomi: so lp is doing not in-process in a wsgi app, but from the client
<poolie> proxied through the app server
<poolie> it requests a diff url
<thomi> ahh, that'd be why it looked odd. So is it something that's not currently easy to do in loggerhead?
<poolie> from what i know of the structure i'd think it should be pretty possible
<poolie> hm
<poolie> depending on just what part it is that you want to get out
<poolie> if it currently only serves one monolithic page for, say, annotate, and you want to get just part of it , you might need to refactor it
<thomi> well, I'd like everything, but rendered within a sloecode page...
<poolie> so, with sloecode navigation stuff inserted into the loggerhead page?
<thomi> yeah, or rather loggerhead inserted into a sloecode page ;)
<thomi> so how does LP do it for the diffs on merge proposals... I assume those diffs are created by loggerhead.
<maxb> I don't think they are
<thomi> oh, ok, cheers.
<poolie> hi vila
<poolie> do you want to chat?
<vila> yup, if my network agrees with that reasonable task ;)
<poolie> jelmer: hi?
<poolie> vila, so re http://doc.bazaar.canonical.com/devnotes/configuration.html compatibility
<poolie> i agree we want to change section names
<vila> and delete some
<poolie> right, more precisely we want to use sections to describe when the value applies, not what the key is
<poolie> however, it seems pretty feasible to migrate while using the current files
<poolie> i'd really rather not put users through a flag day
<vila> me neither
<vila> but we can support haveing both files defined
<vila> and even create one from the other
<vila> and even update the old one in parrallel (that one is probably overkill ?)
<poolie> so istm the common case will be that people just simply have a bazaar.conf
<poolie> with a default section, without bookmarks or aliases
<vila> trying to address all issues while keeping the same file gave me headaches and I never came to a satisfying solution either
<poolie> and the simplest thing in that case is to just leave it alone
<vila> leave it alone and handles the new one or leave it alone and change its semantic ?
<poolie> don't create a new file, just keep reading and writing the current location
<poolie> support having this kind of section marker as a backward compatibility feature or something
<vila> :-/
<poolie> too hard?
<vila> my gut feeling is that it will make the code more complex with no guarantee that the end result will work correctly
<vila> roughly, we make assumptions about the file content and semantics that allow us to be lazy
<vila> as soon as you require looking at the file content to define the semantic, you lose the lazyness
<poolie> what do you mean?
<vila> it matters less if we guarantee that we will read the file only once but we're not there yet
<vila> I mean: using [DEFAULT] as a backward compatibility marker means the file needs to be read first before deciding how we want to interpret it (not mentioning that it forbids using 'DEFAULT' as a valid path)
<poolie> ok, so what i had in mind was
<poolie> the per-user file is called bazaar.conf
<poolie> we match sections by path in there
<poolie> or, perhaps [path ...]
<poolie> there's an api that will let the bookmarks and aliases plugins find other things
<poolie> find values from other sections
<vila> right, but it's far easier to let the old file implements the old semantics and the new file provides the new ones
<vila> then people can decide when they want to switch
<vila> and we can deprecate bazaar.conf in 2.6 or 2.7
<poolie> i don't think that's a thing people want to make a decision about
<vila> using new features is a decision
<lifeless> deprecate bazaar.conf?
<poolie> that's vincent's proposal
<poolie> what do you think?
<lifeless> seems like a lot of people will need to change their config
<poolie> vila, so, i'm kind of -1 unless it's really necessary, and i'm not convinced yet that it is really necessary
<poolie> please don't land it until i am convinced
<poolie> i think there are other things we can do towards this that don't require that migration
<poolie> like, getting rid of config-variable-specific apis, and updating callers to use stacks?
<vila> yes, that's what I refer to as 'migrating existing options'
<poolie> ok
<poolie> once we do that, we should be pretty much set to read them from a global file, the command line, or environment variables?
<vila> last time I looked at env variables the use cases seem to be that *multiple* env variables for *one* config option is the rule rather than the exception, but nothing blocking
<vila> command line will be ok
<vila> adding a global file (as in system-wide ?) without addressing the compatibility sounds like a waste of time
<poolie> why?
<vila> ensuring single read/write of a given config file can also be done first (if only to free our minds about the related issues)
<vila> because it means we'll have to do the work twice
<vila> and the users too
<poolie> uh
<vila> now, the migration to new files can probably be automated for the most common cases if not all
<poolie> if you're suggesting adding a global file with a structure we later have to deprecate, that does seem like a waste, but i don't see why that would be needed
<vila> ha
<vila> I thought *you* were suggesting a system-wide file with the same semantics as bazaar.conf :)
<poolie> i don't think we would need to handle the corner cases of bazaar.conf in the global one
<vila> right, that's why I suggested to make the system-wide conf file more like branch.conf: a single no-name section
<vila> to start with
<vila> but an obvious use case would be define aliases there...
<poolie> cool
<poolie> so then i think we'd have to update the alias code to look in both places
<poolie> or, maybe add an api with a backwards-compatibility thing
<vila> or even better, let the config file define this kind of semantic so the backwards-compatibility tricks are easier to define and manage overall and clearer for users that could be pointed at the doc associated to the config file itself :)
<vila> but let's discuss about that later when things are clearer
<vila> just keep in mind that I'm fully aware that introducing new files and deprecating old ones is not easy/use-friendly, should be done with care and the costs/benefits balanced against keeping the same files
<poolie> so step 0 is to send a roadmap and then step 1 is to migrate the existing callers
<poolie> ok :)
<vila> poolie: in short: I damn well know the issues and I'm eager to convince you :)
<poolie> ok :)
<poolie> the other thing that would be really helpful now is your attention to http://package-import.ubuntu.com/status/
<poolie> config stuff is a good feature, and good for enabling other stuff, but not top of the list
<vila> jam: hello !
<jam> morning vila
<poolie> hi jam, welcome back
<jam> hi poolie
 * vila biab
<cheater> hi!
<cheater> i've done multiple changes to a file which i'd like to put into separate commits. how can i do that?
<AuroraBorealis> remove one set of changes, commit, add the second changes back , commit
<cheater> is there no way to edit the diff i'm committing?
<AuroraBorealis> probably not.
<AuroraBorealis> and i dont think there is a way to do that in any versioning system
<AuroraBorealis> you can select what files that have changes get commited but not certain changes in a file.
<cheater> that sucks :(
<AuroraBorealis> commit more often i guess!
<AuroraBorealis> also, is there a way to make the mac version of bzr explorer have a dock icon?
<AuroraBorealis> its a one liner, but i have no idea where the program starts
<poolie> cheater, use bzr shelve
<poolie> or install bzr-interactive and i think it adds a commit -i
<cheater> oh let me try that!
<jelmer> hi jam, welcome back :)
<AuroraBorealis> because its annoying to have the default python icon in the dock =/
<jelmer> poolie: pong
<poolie> hi jelmer
<poolie> i think i was just saying hi
<cheater> so what would i do? bzr shelve file, edit changes to just leave in the ones i need.. and then bzr ci.. and then how do i get my changes back?
<poolie> bzr unshelve
<cheater> ah
<cheater> great - let me try that
<cheater> wow bzr shelve is really great
<cheater> thanks a lot for the tip!
<cheater> AuroraBorealis: look, bzr is better than any other VCS :)
<AuroraBorealis> i didn't know it allowed you to choose what changes
<cheater> yep! pretty cool! :)
<cheater> btw, i wrote a lightweight text editor for use with bzr commits
<cheater> i just do bzr ci, enter my message, then press Ctrl-D (or Ctrl-C) to abort). It doesn't do anything else and doesn't display any user interface, etc.
<cheater> i find it better than nano and vim for this purpose, and you don't have to use -m (using -m means that you can't just press up and enter to commit new changes)
<vila> so, wanting to file a bug for making tags fetching optional for 2.4.0, I see we have 3 critical bugs ?
<vila> jelmer: bug #771184 sounds like the one I'm after
<ubot5> Launchpad bug 771184 in Bazaar "option to disable/enable fetching of all tags" [High,Confirmed] https://launchpad.net/bugs/771184
<jelmer> vila: ah, yep
<vila> jelmer: do you know the fetch code enough to fix it ?
<vila> jam: or may be you do ?
<jml> mgz: Would really appreciate you looking over https://code.launchpad.net/~jml/testtools/unprintable-assertThat-804127/+merge/70530
<jam> vila: enough to make fetching tags optional, or enough to fix the underlying bug?
<vila> anyway, I've marked #771184 as critical and targeted to 2.4.0 so we don't release without fixing it
<vila> jam: enough to make fetching tags optional
<vila> jam: so we can fix the underlying issue for 2.4.1 or trunk
<vila> jam: I don't understand the details but the underlying issue seemed to be tricky enough to require more time. I don't want to block the release for that
<Noldorin> hi jelmer
<jelmer> vila: Yeah, I think I know the fetch code well enough, though I'm also trying to finish off my current WIP
<jelmer> hi Noldorin
<Noldorin> hey
<Noldorin> jelmer, haven't had any time to investigate that bzr-git issue yet really..... have you?
<jelmer> Noldorin, no
<Noldorin> jelmer, might have some time tomorrow. was going to ask...
<Noldorin> jelmer, you said to test "part" of the r47 commit. how do i do this?
<jelmer> Noldorin, creating a new revision with some of the changes present in r47 and seeing if that gives the same problem
<jelmer> then doing that until you can narrow down which combination of changes triggers the bug
<Noldorin> jelmer, i would have to create a whole new branch, no?
<Noldorin> jelmer, because just adding a new revision still leaves the old r47 and this gets pushed...
<Noldorin> afaik
<Noldorin> well, i tried indeed.
<jelmer> Noldorin: yeah, you would have to have these changes instead of your current r47
<Noldorin> jelmer, ok, thanks for confirming :-)
<Noldorin> jelmer, bit mor time tomorrow, so we'll see! good night for now
<jelmer> Noldorin: g'night
<spiv> jml: don't be shy, just call the branch f---ing-assertThat ;)
<jml> spiv: :)
 * mwhudson wishes for hunk splitting in shelve
<LeoNerd> If shelve can't cope I usually revert and vimdiff
<cheater> will anything bad happen if i edit a file that is shelved?
<jml> spiv: What I'd like to say about supporting unicode across Python 2 & 3 is unprintable.
<james_w> mwhudson, you know you can set it up to allow you to edit hunks to achieve that?
<mwhudson> james_w: no!
 * james_w searches
<james_w> bug 708716
<ubot5> Launchpad bug 708716 in Bazaar "config change_editor is undiscoverable" [Low,Confirmed] https://launchpad.net/bugs/708716
<james_w> bug 781871
<ubot5> Launchpad bug 781871 in Bazaar "change_editor for bzr shelve is still not documented enough" [Medium,Confirmed] https://launchpad.net/bugs/781871
<james_w> mwhudson, id:4D417FEE.3070409@ukr.net
<mwhudson> oo
<mwhudson> thanks
<james_w> mwhudson, I think you edit the whole file to look like what you want after shelve completes, and it ignores any previous decisions you made in that file
<james_w> I may be wrong though
<cheater> is it possible to have one editor in bzr for commit messages, and another "general" editor?
<LeoNerd> Seriously people...
<LeoNerd> bzr co $URL; edit stuff; bzr ci --local because I'm on the train.. bzr push => "ERROR: No push location known or specified"
<LeoNerd> Would it be -that- much work to have this specialcase default to "Oh I'll just push up to the branch" since bzr info knows full well what it is
<LeoNerd> I don't think in $N years I have -ever- bzr checkout'ed anything that I ever wanted to push anywhere else other than back to its branch.
<jelmer> LeoNerd: please file a bug
 * fullermd cues round 73 of bound-age.
<LeoNerd> Where do bugs go these days?
<jelmer> LeoNerd, http://bugs.launchpad.net/bzr/+filebug
<LeoNerd> Hrmmm... needs login..
<jelmer> fullermd, I'm also not sure how useful bound branches are anymore these days
<jelmer> they seem to cause a lot of confusion for new users
<LeoNerd> I use them almost exclusively
<fullermd> They sound very useful, as that's what LeoNerd is wanting.
<LeoNerd> I want to work against my centralised repo server; the same workflow model as CVS or SVN
<fullermd> Me, I'm quite the opposite.  I can't remember the last time I wanted a bound branch, but I use checkouts all the time.
<LeoNerd> To be honest, I mostly treat bzr as a "better svn", which has real branches/tags/renames/...
<LeoNerd> Ah, turns out to have been filed already.
<LeoNerd> https://bugs.launchpad.net/bzr/+bug/539996
<ubot5> Ubuntu bug 539996 in Bazaar "bzr push should default to parent branch if that's writable" [Wishlist,Confirmed]
<LeoNerd> over a year ago
<spiv> LeoNerd: "patches welcome" :)
<LeoNerd> Bah
<LeoNerd> I find that rarely to be the case.
<LeoNerd> I usually ask for a feature and then do nothing until someone official upstream says "please send a patch"
<LeoNerd> as in the past I've wasted lots of time and effort building patches that don't get accepted
<jelmer> LeoNerd, that's a different issue
<LeoNerd> Sure
<jelmer> LeoNerd, bug 539996 is a different issue from what you were describing I mean
<ubot5> Launchpad bug 539996 in Bazaar "bzr push should default to parent branch if that's writable" [Wishlist,Confirmed] https://launchpad.net/bugs/539996
<LeoNerd> But to the outsider it's never clear if a feature is missing intentionally, or simply because nobody happens to have got around to it yet
<LeoNerd> That looks the same, no?
<jelmer> LeoNerd: That's also another issue :)
<spiv> LeoNerd: at least I didn't say "patches accepted" :P
<jelmer> LeoNerd: you want "bzr push" to default to the *master* branch, which is different from the parent branch (which is the location a branch was "forked" from)
<LeoNerd> .. oh.
<LeoNerd> OK. I'll write another one
<jelmer> LeoNerd, I'd be interested in talking about patches and discussion around them
<spiv> LeoNerd: obviously it can be a good thing to discuss what you're doing with the people that will need to approve before sinking too much effort into it, to make sure you're not doing something that will never be taken
<LeoNerd> spiv: Yes. I usually try
<LeoNerd> Quite often nobody replies ever
<spiv> LeoNerd: "patches welcome" was just meant to be a shorthand for that.  If you like, "feature suggestions and discussion about proposed patches also welcome."
<LeoNerd> Nono..
<spiv> Yeah, that's a tough problem.
<LeoNerd> those are -massively- different
<jelmer> LeoNerd, I've had similar issues in the past, but I think the process has improved significantly since
<LeoNerd> I am quite happy to talk, discuss, rant, foam-at-the-mouth about the feature(s) I happen to want or the bugs or whatever..
<spiv> If you invent a way to solve the finite amount of time developers have, well, we wouldn't need to ask for help with fixing bugs ;)
<LeoNerd> But I pointblank-refuse to write a single line of code unless someone semiofficial at least vaguely hints at "we will consider a fix if you supply one"
<spiv> Sure
<spiv> I agree that's wise
<spiv> And if at first you get silence, make more noise (if you want, giving up is also fine!).  Sometimes the right person is just really busy that week.
<LeoNerd> Sometimes..
<LeoNerd> Depends on the project.. I have features/bugs/etc.. outstanding in some places for -years- unreplied
<spiv> I think bzr is increasingly defaulting to "well none of the core devs care strongly either way, so if you want to write that patch go ahead and we'll accept it (if it meets the quality requirements etc)"
<spiv> Oh yes, me too.
<spiv> It depends very much on the project.
<spiv> Whether your bugs/posts languish or get responses is a fairly good indicator for how pleasant it will be for you to work with that community, I think.
<LeoNerd> Heh...
<LeoNerd> Doesn't fill me with confidence then.. :/
<LeoNerd> But then some aren't quite my problem. I have a bug open on FreeBSD that's basically in a state of "I really don't care, but I can't support your platform until this is fixed"
<fullermd> Things vary a lot there.
<fullermd> I submit port updates a lot, and they rarely take more than a couple days.  And occasionally single-digit hours.
<LeoNerd> This isn't a simple ports issue
<fullermd> Meanwhile, I've got a 3-line manpage patch that's coming up on its 3rd birthday, without evidence of a glance.
<LeoNerd> This is a "er.. your kernel API is lacking a feature"...
<LeoNerd> I wrote a unit test and documentation and everything.. Just no -actual- implementation
<LeoNerd> But I handwaved in vague terms how it should be doable
<fullermd> Yes, but my point is that when the only things required is "patch ; cvs ci", the response time varies enormously (even before counting the random factors).
<fullermd> Getting somebody interested enough to write the code is an even larger can  ;)
<spiv> LeoNerd: that is a shame.  Not that long ago I had a perfectly good (and complete) patch sit around for months and months in a project bug tracker, despite promises it would be looked at "soon" or "in a couple of weeks" and it was deeply frustrating.
<LeoNerd> Oh, I don't usually expect people to write code
<LeoNerd> I'm quite happy to write it _after_ I have the vague commitment that they might acutally consider it
<LeoNerd> I just dno't like that large upfront investment on such risky odds of return
<LeoNerd> Its' basic economics :)
<spiv> Yes, very sensible! :)
<fullermd> I usually figure I might as well go for it.  If it just gets taken, I look smart.  If it languishes for years, eventually someone else will hit the problem, and I can point at the long-waiting solution and be all smug.
<fullermd> Kinda win-win   :)
<spiv> FWIW, the bzr team does try to be aware of these problems and fix them.  We've spent a bunch of effort making sure the patch review queue never grows too long, and that bugs aren't left as "new" indefinitely, etc.
<spiv> LeoNerd: hmm, and although it's not explicitly written down, I think it's part of the Patch Pilot role (which rotates weekly) to be someone you can talk to get a "yes we'd be interested in that patch / no we wouldn't" indication for something you might want to write.
<spiv> LeoNerd: it might be a good idea to make that fact explicit and visible :)
<LeoNerd> fullermd: That only really works if the cost of writing the patch is small. I have a ~50line change to make to the core of the BSD kernel's kqueue handling. Kernel dev. requires a very large initial investment in setting up the dev. environment, virtual machnie, etc...
<LeoNerd> Again economically, it's a large outlay of capital on a risky venture
<spiv> LeoNerd: I'll ping poolie about that, thanks for prompting the idea.
<LeoNerd> spiv: Hehe.. Oh; I'm not complaining about bzr specifically here; just open source in general. :) But if you guys can manage to be above-average, then great.
<cheater> i'm still fairly annoyed at bzr not really working well when my internet access is faulty
<cheater> i'll even get corruption
<spiv> LeoNerd: yes, we'd like to be :)
<cheater> or rather, the checkout goes into an unworkable state that's probably non-trivial to fix
<cheater> is there a way to convert my checkout done with sftp:// to bzr+ssh:// ?
<cheater> i really don't want to re-download half a gigabyte of stuff
<exarkun> cheater: Do you have a shared repository?
<LeoNerd> ?
<LeoNerd> vim
<LeoNerd> The checkout -data- is the same
<LeoNerd> The URL used to access it is transient
<LeoNerd> vim .bzr/branch/branch.conf  :%g/sftp/bzr+ssh/
<LeoNerd> er..  :%s/
<cheater> LeoNerd, is that really all?
<cheater> i have noticed that, but i was wondering if there's any caveats
<cheater> if it's this easy that's great
<LeoNerd> I've done it loads of times
<LeoNerd> Never broken anything for me
<cheater> thank you
<exarkun> I guess a way to do it without editing the config directly is 'bzr pull --remember newurl'
<LeoNerd> Yah, but that only updates the pull location
<fullermd> If you're talking a _checkout_, you want 'switch'.
<LeoNerd> I often end up with three locations
<LeoNerd> parent, pull, push
<LeoNerd> .oO( because of that stupid bug )
<cheater> yeah it's a checkout
<cheater> would you say that bzr+ssh is more durable/robust than sftp?
<cheater> it certainly seems *faster*
<jelmer> cheater, it is faster, because the transport is not "dumb"
<cheater> ok
<jelmer> cheater, It should generally be as reliable as bzr+ssh
<cheater> sftp you mean?
<jelmer> yes
<cheater> i'm having problems with the transport handling, e.g. if i ctrl-c out of a bzr update or commit i get runaway processes that keep spamming my console
<jam> cheater: the only time I've seen an advantage with sftp was on a *very* low-powered CPU machine on a fast local network.
<cheater> i'll see in the future whether bzr+ssh does the same
<jam> cheater: can you describe/paste "spamming" ?
<cheater> sure, i'll ctrl-c out when bzr is doing something, and then when i'm back in my shell i continuously get prompts for the password written out, and an information that the authentication failed (probably because the password doesn't get entered because there's nothing connected to the stdin)
<cheater> i can't paste it right now but let me try to reproduce it
<jam> and is that with bzr+ssh or sftp
<cheater> it's with sftp. i have just started using bzr+ssh.
<jam> I believe we tried to block ssh from receiving the ^C immediately, so that when connected, we can clean up more-cleanly
<jam> (we try to unlock, etc, and if SSH has been terminated, we can't do any of that.)
<cheater> sometimes when i ^C i get bzr: interrupted
<cheater> it seems to be handling it well then
<cheater> but sometimes i get a python trace with KeyboardInterrupt
<cheater> aha, no it doesn't
<cheater> i have just triggered it
<cheater> let me test a bit more
<cheater> ah yes, and it also messes up my terminal prompt
<cheater> http://pastebin.com/0cmU0fhv
<cheater> happens with both bzr+ssh and sftp
<cheater> jam ^
<jam> cheater: as mentioned above, we trap SIGINT to let the ssh subprocess die "gracefully" under certain circumstances
<cheater> that's ok - it would be nice if you could make it not break my terminal though =)
<jam> cheater: don't kill it before typing your password, and it won't spam your terminal :)
<cheater> i want my money back :)
<jam> cheater: use ssh keys instead of passwords
<cheater> i know. can i have my $0 back though? ;-)
<fullermd> I'm afraid your argv[0] has already been spent  :p
<jam> jelmer: how are you submitting your branches? I see the 'commit message' change, and the branches in pqm, but it doesn't tell me that you are sending it to pqm. (which 'feed-pqm' does.)
<jelmer> jam: I am actually using feed-pqm
<jelmer> jam: ah, local changes from when I was hacking on hydrazine (I had the lp comment thing commented out)
<jelmer> reverted now
<jelmer> jam: thanks for those reviews
<mwhudson> jelmer: hi?
<jelmer> mwhudson: hey
<jelmer> how's the sprint going?
<mwhudson> jelmer: do you know what is required to implement imports of non-master git branches in lp?
<mwhudson> jelmer: it
<mwhudson> jelmer: it's going well, pretty intense
<jelmer> mwhudson: I sent an email to the bazaar list about that two days ago
<mwhudson> jelmer: ah ok
<jelmer> mwhudson, https://lists.ubuntu.com/archives/bazaar/2011q3/073304.html
 * mwhudson hasn't been reading email
 * mwhudson reads
<mwhudson> jelmer: ah ok, so it's actively in progress then?
<jelmer> mwhudson, yup
<mwhudson> jelmer: great
<jelmer> mwhudson, though help is of course always welcome
<mwhudson> jelmer: any idea of an eta?  a few weeks?
<mwhudson> jelmer: heh, well...
<mwhudson> (linaro cares about this though, so there is a slight possibility of help...)
<jelmer> mwhudson: Presumably a few weeks, but there are probably a few too many things I have in progress at this point
<mwhudson> ah ok
<jelmer> mwhudson: It's good to know this is important for linaro, that helps when deciding what to finish next.
<mwhudson> cool
<mwhudson> i'll keep on asking then :)
<jml> mgz: \o/
 * mgz is just commenting on unprintable-assertThat-804127
<jml> mgz: cool, thanks.
<jml> mgz: I've reviewed your patch.
<jml> just one question.
<mgz> jml: answered, and nearly done on review.
<hexsprite> new to bzr, is common for bar diff on lightweight branch to consume 1meg on a medium size repo for each time i run it with no caching etc?
<hexsprite> s/bar/bzr/
<hexsprite> downloads 1meg that is from remote
<jimis> if the branch is lightweight, it always fetches from remote
<fullermd> Lightweight checkout, you mean?  Yes, it's always gotta transfer stuff down.
<fullermd> Really, on anything but local disk or a rather fast LAN, lightweight checkouts are usually not gonna be a great idea.
<jimis> hexsprite: latest releases (2.4 for sure, not sure about 2.3) have fixed some bugs that download much less data in some cases
<jimis> maybe you want to check them out
<hexsprite> ahh this machine is ubuntu 10.4â¦ ancient ;)
<jimis> but still nothing is cached when it's lightweight
<jimis> How do I commit specific changes in a branch different than the one I'm on (i.e. without doing bzr switch)?
<RenatoSilva> how do I commit without any message
<jimis> RenatoSilva: did you try bzr commit -m ""?
<RenatoSilva> jimis: nham, that's boring :P I want to be cool :P
<RenatoSilva> jimis: even if I have to bzr commit --type-much-more-huh. Now serious, I just think that there is indeed and option rather that yours
<RenatoSilva> jimis: *an option, maybe I'm not recalling correctly
<fullermd> jimis: merge --uncommitted ?
<jimis> fullermd: nice one. But from all changes I need to pick 2 files
<fullermd> merge --uncommitted /this/file ?  :p
<jimis> hmmm I thought that "bzr merge" took a branch location as argument...
<jimis> and based on the help I assumed it would be the branch to commit *to*
<jimis> fullermd: so how would I write the command, to commit uncommitted changes of file F to branch B?
<fullermd> You can point it directly at a file in the branch as well.
<fullermd> (alternate answers; merge then revert everything else.  Or, shelve all but the files you want, then merge.  Or, commit just those files, branch from that, then uncommit that.  Or...)
<jimis> thanks fullermd
<jimis> what I did:
<jimis> bzr switch B   (I didn't know this would preserve uncommitted changes)
<jimis> bzr commit F1 F2
<jimis> bzr switch A   (switch back)
<jimis> (now only the rest of the changes are there)
<fullermd> Oh, yes.  That works too.  I presumed you had individual branches.
#bzr 2011-08-06
<Noldorin> what's the difference between bzr update -r and bzr revert -r ??
<lifeless> one merges and one overwrites
<Noldorin> lifeless, update merges, right?
<Noldorin> lifeless, and what about bzr merge -pull and bzr pull - any difference?
<lifeless> Noldorin: yes they are different - the docs should cover that one ;)
<Noldorin> lifeless, you have too much confidence in the docs heh. the difference isn't explicitly stated ;-)
<lifeless> Noldorin: sorry ;( - try bzr help merge; I have to head away from the keyboard, its why I'm pointing you at the docs.
<lifeless> cao
<Noldorin> ok sure
<Noldorin> bye
<Noldorin> what happens if i shelve changes, make some edits, then unshelve...do the shelved changes get merged or pulled with overwrite?
<Noldorin> hmmm
<Noldorin> what makes bzr say "working tree is out of date" ?
<sili> You need a bzr update
<Noldorin> what does that actually *mean* though?
<Noldorin> why does it think i need a bzr update?
<sili> you issued a command it determined the version you're working with is older than the checkout branch
<Noldorin> sili, not using checkouts here...
<sili> hmm. https://bugs.launchpad.net/bzr/+bug/55383
<ubot5> Ubuntu bug 55383 in Bazaar "bzr status should say if the working tree of a branch is out of date" [Low,Fix released]
<Noldorin> sili, the branch is not bound to anything...don't know how it can possibly claim it's "out of date"!
<sili> did someone push a change to your branch?
<sili> or commit there
<Noldorin> sili, i guess not, since bzr revno gives 46, which is the latest revision in bzr log
<Noldorin> sili, ?
<Noldorin> well this sounds like a definite bug to me
<Noldorin> i see no reason for it
<aminpy> http://dpaste.com/587804/ <- can anybody help me?
<Noldorin> hi again jelmer
<jam> aminpy: http://dpaste.com/587804/ that is a timeout resolving "lp:"
<jam> 2 options
<jam> use "bzr+ssh://bazaar.launchpad.net/..." directly
<jam> or
<jam> upgrade to the bzr 2.4 series which will resolve lp:~... on the client instead of via Launchpad XLMRPC
<Noldorin> hi jam. any idea about my issue?
<Noldorin> anyone?
<Noldorin> jelmer, let me know when you are back :-)
<aminpy> http://dpaste.com/587858/plain/ <- can anybody help me?
<Noldorin_> can anyone please tell me exactly why im getting "working tree out of date" on my branch?
<Noldorin_> can anyone please tell me exactly why im getting "working tree out of date" on my branch?
<idnar> anyone know if setuptools_bzr is still maintained? it seems to have a completely broken setup.py so I'm guessing not, but maybe I missed something
<sam_> looking for beta testers for a new chat site www.chatnearme.com also available on mobile devices at same url
<RenatoSilva> There's repo version of project foo. I want to patch it with a feature so I branch it as bar. But upstream goes on, and my bar branch becomes a mix of feature commits and upstream merges. I want to produce a version of the feature for last release, which is a changeset before the one I branched from, for example tagged as R_1.0. This is called backport, right?
<RenatoSilva> But in the process of backporting the feature, I'll have to differentiate between those upstream update and feature commits, and I've got the impression it's a lot of trouble. Am I right? Is this workflow weird or ok?
#bzr 2011-08-07
<Noldorin> hi jelmer
<benonsoftware> Question: How do I on Win upload to my Launchpad PPA?
<benonsoftware> How do I set my SSH keys with bazzar explorer?
<thomi> benonsoftware: I believe you must use pagent (part of putty) - at least that's how I do it.
<benonsoftware> thomi: I have my private and public keys in .ssh and I get bzr: ERROR: Don't know how to handle SSH connections. Please set BZR_SSH environment variable.
<thomi> oh, I assumed you were using windows, based on your previous question.
<benonsoftware> thomi: I am that is what I get
<thomi> what ssh program are you using?
<benonsoftware> thomi: pagent
<benonsoftware> thomi: I am not sure what is happening with it
<thomi> benonsoftware: it's a bit old, but perhaps this might help you? https://answers.launchpad.net/bzr/+question/50360
<Noldorin> jelmer, hey>
<cheater__> can i somehow make bzr automatically check out the latest version of the branch?
<exarkun> what other version of the branch would it check out?
<cheater__> sorry, i meant:
<cheater__> can i somehow make bzr automatically update to the latest version of the branch?
<exarkun> Like "bzr pull"?
<cheater__> yeah
<cheater__> or more like bzr up
<cheater__> i commit to branch from my workstation, and want the server to automatically see it and update to the latest version.
<cheater__> or i commit to the main branch from a checkout, or something.
<exarkun> So you want to automatically update an arbitrary checkout, somewhere in the world, when a new revisions appears in a another checkout of that branch somewhere else in the world.
<exarkun> I don't know, maybe there's a plugin or something.
<cheater__> exarkun, i think it just needs to be something that runs "bzr up" every 10 seconds
<cheater__> i could do a cron job.. but i thought maybe there's some better way to do it
<exarkun> Sure, but you don't need #bzr to tell you that.
<cheater__> yeah
<cheater__> i thought, maybe there's some sort of, uh, trigger or something.
<cheater__> there are always those triggers for everything!
<cheater__> i guess that's mostly wishful thinking though :)
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer, was about to do some testing yesterday but ran into problems
<Noldorin> jelmer, bzr is telling me "working tree is out of date" and i have no idea why
<jelmer> Noldorin: when is it telling you that?
<Noldorin> jelmer, bzr st, bzr dpush, bzr most things :-)
<jelmer> Noldorin: is this after you hit the bug you were debugging?
<jelmer> Noldorin, or on a different branch?
<Noldorin> jelmer, same branch
<Noldorin> i just uncommited to r -46
<Noldorin> err
<Noldorin> -r 46
<Noldorin> so i cna investigate
<jelmer> Noldorin, right, so that's probably because it crashed halfway through
<jelmer> Noldorin, "bzr up" should get the working tree up to date again
<Noldorin> i see
<Noldorin> jelmer, many many conflicts now
<Noldorin> jelmer, ok fixed....somehow! :-)
<Noldorin> jelmer, will investigate which directories cause the issue later
<RenatoSilva> I had an weird merge problem, I deleted all branches but it was like this
<RenatoSilva> I have a branch which works on a feature for foobar release 1.2.3, then I created another branch and merged upstream repo changes, for getting that feature working with foobar dev version
<RenatoSilva> 1. the merge pointed some conflicts out of order. That is, I had to figure out that if I just fixed each conflict individually from top to bottom, I'd get a completely wrong result
<RenatoSilva> 2. the merge didn't merge one of upstream changes, it was supposed to replace some two lines with one single line from upstream
<RenatoSilva> are these two normal problems of merging or bugs?
#bzr 2012-07-30
<jelmer> moin
<mgz> morning!
<jelmer> sup mgz!
<vila> hi all !
<mgz> jam around yet today?
<jelmer> he was around in #-kitchen earlier
<mgz> ace.
<jam> mgz: /wave
<jelmer> mgz: do you still happen to have the PQM output for merge-grep?
<mgz> forwarded
<mgz> and you have too many email addresses with no obvious pattern for when you use which ones :)
<jelmer> mgz: gracias :)
<Peng> Solution: CC all?
<Peng> :)
<jelmer> mgz: hmm, there are also a bunch of tests that fail in a different locale
<mgz> hm, I'll branch and see
<jelmer> I'm running with spanish here - it at least appears to have enough things translated
<mgz> you're learning spanish?
<jelmer> mgz: different computer :)
<jelmer> laptop is German, desktop is Spanish
<jam> jelmer: IIRC lifeless was using Latin for a while
<jam> that, and vila tried to use French, but found it too confusing
<vila> :)
 * jelmer chuckles thinking of vila being confused by French
<vila> yup, same here ;)
<vila> truth is, to clear confusion, the best way for me is often to translate back to english...
<jelmer> vila: do you "think" in English when you speak it, or do you translate back to French mentally?
<vila> jelmer: I'm at the point where I sometimes think in English but need to speak in French ;)
<vila> family hate that ;)
<jelmer> :)
<vila> mostly depends on the topic discussed
<vila> so, for technical matters, I often don't know how to translate idiomatically
<vila> but people around me are helpful ;)
<jelmer> heh
<vila> mgz: ping me when you're ready to discuss some resolve proposals of yours
<mgz> ping!
<vila> I'm looking at the introduction of the auto action and I
<vila> meh
<vila> I'm not sure I agree
<vila> --done seems fine to me to include what you put in --auto
<mgz> wait, which one?
 * mgz went a bit overboard with different branches
<vila> I'm back to resolve_auto_refactor
<mgz> okay
<vila> back to the basics: merge creates a conflict because bzr cannot decide which action is required
<vila> resolve should be taught to recognize that the user did something and the conflict is not there anymore
<vila> that's what '--auto' seem to do in your proposals
<vila> but in fact, I'd prefer that --done cover that
<mgz> so, really 'auto' here is "I've done some changes to the tree, have another look and see if you still think there are conflicts"
<vila> i.e.: the context has changed, bzr does not see a conflict anymore, the conflict object can be deleted
<vila> yup
<mgz> which is mostly what people want
<mgz> but --done is still needed
<vila> when ?
<mgz> otherwise, how for instance, with a conflict that involves a deletion
<mgz> do you say "no, really, keep it"
<mgz> deleting the object and --auto works, you clearly want the deletion to stick
<vila> say that again in commands executed by the user ?
 * vila tries to get it
<mgz> but there's nothing to distinguish "haven't decided if I want this object still" and "want to keep the object"
<mgz> eg, I delete d/
<mgz> you add d/f
<mgz> I merge your branch
<mgz> get a conflict on d/
<mgz> filesystem looks like [d/, d/f]
 * vila nods, that's 'merge' this specific case
<mgz> if I want my change to stick, I delete d/ (and maybe move d/f somewhere else)
<mgz> if I decide against deleting d/ because you're now using it, I need bzr resolve --done d
<mgz> I don't see a neater way out of that
<vila> what does --auto does in this case then ?
<mgz> we could alos move d/ to d.conflicted/ and make the user delete or move it back
<mgz> but that doesn't seem easier.
<vila> the key is that an action should automate what is manual otherwise, --auto sounds a bit like 'just do the cleanup' which --done is already targeted at
<mgz> there's also the "my file has the line '=======' in it" case
<vila> and preferably the action comes in two flavors: favor this or favor other
<mgz> auto is bascially just a generalisation of `bzr resolve` which is pretty much all I ever use
<mgz> it's unlikely to ever be passed in, it's just a good safe default
<vila> still sounds like a variation of --done rather than a different action
<mgz> --done is by definition not safe
<vila> yup
<mgz> it's a shut-up-and-believe-me option
<vila> that's what the thread was about IMHO: make it safer
<mgz> okay, so I disagree
<vila> when in doubt, requires --force
<mgz> we still need the unsafe option
<vila> --done --force
<mgz> and I don't see the benefit of `resolve --done` and  `resolve --done --force` over using `resolve --auto` and `resolve --done`
<vila> may be we just disagree on the name
<vila> --auto sounds magical: do the right thing (including actions like deleting a file or add'ing it or whatever)
<mgz> they're clearly different options, --done already does the right thing, our auto logic already does the right thing just isn't exposed as a flag
<mgz> we can name auto whatever, I doubt anyone will ever actually pass it, it's just the default
<mgz> it's auto in the existing code is all
<vila> what triggered my question is that you modified existing tests by adding --auto, as if the default behavior (or command-line option default value) has changed
<mgz> right, the whole point is to change `bzr resolve FILE` to be 'safe'
<mgz> but then go back around and make `bzr resolve FILE` still do the right thing
<mgz> (by making auto smarter)
<vila> still blurry
<mgz> I need to write up some user story type things for the list really
<vila> some conflicts just can't be "checked" without asking tree-transform to rebuild the conflicts
<mgz> it doesn't help that a lot of the conflict cases we have are bugs at about three different levels
<vila> yeah, hard stuff
<vila> also, action_* in conflict objects should *always* use a tree transform
<mgz> like... not having precious/junk distinction, switch being unsafe, doubling conflicts on deleted directories...
<vila> I made the mistake in the past of using direct actions, that's not robust and may introduce subtle failure modes
<vila> yeah, lots of entangled stuff
<mgz> as in, the ones using tree.remove are wrong?
<vila> yup
<vila> there are still some left right ?
<vila> bah, better check myseflf
<mgz> yup, and I added a another one because I couldn't work out how to change state 'missing' to unversioned/gone
<mgz> basically just want to remove the file_id from the inventory but couldn't find a good way of doing that
<vila> right, DuplicateEntry is wrong and should be rewritten
<vila> right, so tt.unversion() or something
<vila> tree.revert may be ok (if it relies on tt under the hood)
<mgz> unversion checks that the file exists
<vila> urgh
<vila> err, are you sure you don't just need to register a trans_id ?
<mgz> no, not sure, I didn't try using a tree transform.
<vila> right, then that's an example of why tt should be used ;)
<vila> hmm, I wonder if just building a tt against the current working tree will get rid of the conflicts already resolved by the user...
<mgz> hm, and there is a bug in the current auto resolve logic, though earlier than I thought:
<mgz> <http://pastebin.ubuntu.com/1119180/>
<vila> with a pristine bzr.dev  ?
<mgz> yup.
<vila> hmm, sounds like a fallout from a very old fix, here, kind() should just returns None (if the file does not exist anymore, it's kind is None)
<mgz> and a similar one with bzr rm rather than rm: <http://pastebin.ubuntu.com/1119185/>
<vila> great :-}
<vila> worth fixing
 * vila still paging in context
<mgz> okay, so I think that check wants to be `if not tree.has_id(self.file_id) or tree.kind(self.file_id) != 'file': return`
<mgz> in otherwords
<mgz> we have a conflict in a text file
<mgz> if the user has removed the file - it's resolved, they deleted it
<mgz> if the user changed the file into a symlink or directory - it's also resolved, it's not text any more
<mgz> otherwise we peek at the bytes on disk looking for conflict markers, if they're gone, it's resolved
<mgz> otherwise we should raise ConflictUnresolved or whatever we go for over NotImplementedError
<mgz> ideally with contenxt like line number
<vila> "not text anymore" and we never try to keep the file-id when the kind changes, it makes no sense
 * vila agree with ConflictUnresolved of StillThere or whatever
<vila> coming back to the internal 'auto' action"
<vila> s/"/:/
<vila> when I started working on 'resolve' I first thought that it should have been called 'resolveD'. Then I started added actions which made 'resolve' get some meaning
<vila> but really, 'done' and 'auto' (as internal actions) are still in the 'resolved' realm
<vila> which is also part of my reluctance to accept --auto as an action from the user pov
<vila> in fact, the idea while discussing with poolie at the time was that the user should never have to issue 'bzr resolve --auto FILE' because other parts of bzr will have taken care of the conflict
<vila> another way to look at it is that if --done cannot clean up safely, the user still have to do something.
<vila> If there are multiple choices there, --auto won't be able to decide
<vila> it's ok for the conflict markers because there is a single possible action: remove the markers
<vila> but I fear it won't be true for all conflicts
<mgz> hm, `bzr resolve -d g g/f" ... does not work
<mgz> the path is taken as relative to the repo
<mgz> not cwd.
<mgz> is that the normal form for -d?
<vila> ha ha, and that's not mentioning multiple conflicts that can interact and should be resolved in the proper order :-}
<vila> regarding -d, I think you've just entered unexplored territory :)
<mgz> okay, I agree there's a lot of mess in resolve currently
<vila> right, which is why I'm unclear about whether --auto is legit or would just add to the confusion
<mgz> but... the current state is we have a number of broken common cases
<mgz> which are not actually hard to fix, and the code basically supports doing it in a sane manner
<vila> in other words: if you were talking about enhancing 'resolveD' I'll be +1, for 'resolve'... it's less clear
<vila> but the content of your auto_* methods are certainly valuable
<mgz> I don't see the benefit in the kind of procrastination over details, like in that bazaar mailing list thread
<vila> right
<mgz> when we can just make the code a bit better and get most of the pain resolveD
<vila> right too
<vila> how about just rewriting auto_resolve then and don't touch the command itself yet ?
<mgz> I'm not attached to the name 'auto', but the behaviour from `bzr resolve` is useful and is worth generalising
<vila> seem we are in agreement ?
<mgz> doing that takes me back to this just being a code refactor
<vila> 'that' 'this' /me lost :)
<mgz> without also making auto understand when other kinds of conflict are done with, we need the unsafe --done or --all far more often
<mgz> so the extra pain of requiring that isn't worth the interface breakage for users
<vila> so you still agree with turning auto_resolve into conflict.action_auto kind of refactor ?
<vila> that may not be enough to address all multiple conflict cases but neither does the actual code
<mgz> yes. there's a nice mechanism for removing conflicts, using that rather than having a seperate method on tree clearly makes sense.
<vila> great
<vila> lunch here but after that I'm still available to discuss or even help writing tests and/or code
<mgz> I understood 'just rewriting auto_resolve' as you not wanting bzrlib/conflicts.py touched.
<mgz> jelmer: so, I didn't get any different failures in another locale with -d bp.grep, do they only show up when the other failures are fixed? or can you give me a test that fails and the traceback?
<jelmer> mgz: those were other bzr tests
<mgz> okay, will do a full test run over lunch
<vila> mgz: back, indeed, I do want to pursue the efforts in conflicts.py
<mgz> okay, bb.test_debug.TestDebugBytes.test_bytes_reports_activity is broken
<mgz> needs to either not install translations or not check for the english string
<mgz> I expect there are a few others like that
<vila> a way to force english messages (as expected by tests) sounds like a useful resource
<mgz> we've got one :)
<mgz> I assumed all the blackbox tests used it, but apparently it's just some of them
<jam> jelmer: is it ok if we push back our call by a couple of minutes?
<jam> like at 2:30?
<jam> (I have a 3:30 with Francis, so I still need to finish on time.)
<mgz> ...I thought Francis was on holiday still?
<jam> mgz: I think he is in Isle of man this week, and he was still hoping to get ahold of me
<jam> at least, he still has our meeting scheduled
<mgz> ah, yes, that might be it.
<jam> mgz: it is possible that *next* week is Isle of Man, though.
<mgz> I think it's this week, but then he's off next week as well.
<jam> jelmer: anyway, I'm going to go for a quick run, I'll check back in when I get back.
<jelmer> jam: sure, that's okay for me
<vila> mgz: damn, according to bug #688506 I've changed my mind...
<ubot5> Launchpad bug 688506 in Bazaar ""bzr help conflict-types" suggests incorrect "bzr resolve --auto" command line" [Undecided,Confirmed] https://launchpad.net/bugs/688506
 * vila goes back to the attic to find the read-my-own-mind-in-the-past machine
<mgz> I'm far too polite to point such things out...
<mgz> but yes, you wrote all the code to make this easy.
<vila> so at one point I considered that the disctinction auto/done was valid, why I don't get that feeling *now* is... either irrelevant or indicates a source of issues ;)
<vila> on the other hand, I was knee-deep in the code at the time and may have missed the distinction I'm making today: --auto carries the idea that suddenly bzr knows how to resolve the conflict (that's wrong because bzr wouldn't have generated a conflict in the first place otherwise).
<vila> mgz: and I think you captured the right idea with: `bzr resolve` followed by `bzr resolve --done FILE` if the auto resolution fails for something in particular
<vila> which doesn't require auto to be an action the user can specify
<vila> in summary: let's make auto an internal action used by `bzr resolve` or in other places (bzr rm), keep --done for the cases where it fails
<vila> and may be rename it to carry the idea that the intent is to get rid of the conflict is there enough evidence that the user did what was needed
<vila> mgz: are we still in agreement ?
<mgz> vila: so, mulling over that while I had much lunch
<mgz> I think we basically agree on the implementation?
<vila> that's my feeling as well
<mgz> I don't see the benefit in having three choices for actions to remove conflict markers, and a fourth that's only selected if you don't specify one of the others
<vila> err, which choices ?
<mgz> generally with pick-one options, we include all the options, even if one is a default and won't normall be passed
<vila> indeed
<mgz> we have --done, --take-this and --take-other
<mgz> I don't see why it's important to avoid adding a new option if that's how the underlying implementation actually works
<mgz> and it wouldn't get in the way of future ui reshuffling should anyone want to take that on.
<vila> because --done is already an alien and adding another one makes this even more confusin
<vila> g
<mgz> okay, but I don't think it's less confusing having a magic differen behaviour when there's no --action
<vila> some people don't even understand that they need to resolve the conflicts, give them --auto... and they will complain that it doesn't resolve the conflict ;)
<mgz> at least with a flag it can be documented in the help.
<vila> because as you argue, `bzr resolve` will clean up what it can
<vila> both done and auto should not be needed in an ideal world, auto would be called as soon as bzr it involves and --done shouldn't be needed at all
<vila> s/bzr it/bzr is/
<vila> I don't mind keeping done, adding auto seems to go in the wrong direction though, if it's auto, why the hell should I tell you ??
<mgz> vila: because bzr is not a daemon
<vila> fewer cases
<vila> in presence of conflicts you can imagine 'bzr st' calling 'bzr resolve'
<vila> what will be left then ?
<mgz> or `bzr commit` for that matter.
<mgz> not much, but that doesn't really matter. we have a legacy command to deprecate that happened to grow a name for a default switch more recently.
<mgz> and in the mean time, things at least reflect the current state of the code.
<vila> which default switch ?
<mgz> `bzr resolve --auto` as a new alias for `bzr resolve`
<vila> huh ? This didn't land right ?
<mgz> sorry, confusing you with tenses
<mgz> I was using the past, but from imagining a future state where we make `bzr st` and other things remove resolved conflicts
<mgz> so, *when we land better conflict handling*, we *would* have a legacy command...
<vila> ha right, which is why I arguing (and thought you agreed) to keep things as they are but internally add action_auto
<mgz> this kind of thing is much easier in german...
<vila> i.e. do not add --auto
<mgz> okay, so that's the disagreement
<mgz> I think changing the internals to use the fanciness in conflict is good
<mgz> which you also think
<vila> yyes
<mgz> but think it makes sense for the ui to reflect the implementation, given it's a small but real change
<mgz> simplest thing and all that.
<vila> well, I say it's confusing and doesn't provide additional feature. Simpler to explain: if you don't know: `bzr resolve`, if you know `bzr resolve --action=xxx ITEM`
<vila> and 'bzr resolve` is getting better
<mgz> but the docs will be the same regardless
<mgz> magic is bad, but refusing to name it doesn't make it any better
<vila> then you should be able to give a better explanation between auto and done
<mgz> that would be good indeed
<mgz> and the help in general would benefit from some polish
<vila> because, really, my reluctance to document auto is that I can't describe what it does (especially because it's currently undefined for most of the existing conflicts) :)
<vila> whereas done, well, as brutal as it is, is clear
<mgz> it tries to detect conflicts that have been manually resolved and marks them as such
<vila> for a given conflict
<mgz> fitting that in a flag description isn't terribly easy it's true
<vila> but they are cases where several conflicts can be involved which there is still hope to address as a whole
<vila> if --auto were --check or something innocent  like that evoking a non-destructive action (as far as user data is concerned), that will be different
<vila> 'resolved --auto' makes sense 'resolve --auto' implies that bzr will magically resolve the conflict, that's the part that I dislike
<vila> 'resolved --done' makes sense, 'resolve --done', well, is acceptable
<mgz> check doesn't seem bad
<mgz> any other suitable names?
<vila> cleanup ( less good IMHO)
<vila> --refresh ?
<mgz> have we got a less lame way of creating a branch in memory than bzrlib.branchbuilder?
<vila> no
<vila> mgz: don't feel bad writing less than perfect tests for conflicts, that would still be better that the actual lacking tests ;)
<vila> I mean, missing ones
<vila> mgz: and keep in mind you are starting a new kind: action between merge and resolve, none of them exist IIRC
<nessita> hello everyone. I was wondering if I could get some help on fixing an issue I'm consistently having with bzr pipelines: every time I pump changes in the pipeline, the pipes get broken with a "IndexError: list index out of range" (full traceback here http://pastebin.ubuntu.com/1119547/ )
<nessita> I asked about this a couple of weeks ago, I was told to run bzr repair-workingtree, and if I run it with --force it fixes the IndexError, but I would like, if possible, not to have to run the repair eveyr time after a bzr pump
<mgz> nessita: is there a bug against bzr-pipeline for creating the dirstate corruption in the first place?
<mgz> if you can reliably reproduce it, I'd try to get as minimal a case as possible
<nessita> mgz: makes sense, will try to do so
<mgz> the pyx and py versions look much the same, so you could also try running in a clean bzr source dir with BZR_PDB=1 set then poking around the entry that's broken
<nessita> mgz: got a minimal example, will file the bug now, what project shall I file it against? bazaar? (or is there a pipeline specific project?)
<mgz> bzr-pipeline
<mgz> there's possibly a core issue as well as we should really let plugins break dirstate, but it's easy to add tasks and move things later
 * mgz branches the source and looks at what pump actually does
<mgz> ...various aarony magic, but basically switch/merge/commit repeated
<nessita> mgz: bug filled at https://bugs.launchpad.net/bzr-pipeline/+bug/1030923
<ubot5> Ubuntu bug 1030923 in bzr-pipeline "After bzr pump, "next" pipelines have a broken dirstate (got IndexError: list index out of range)" [Undecided,New]
<nessita> mgz: let me know if I can help debugging any further
<nessita> mgz: shall I also attach the "/var/crash/bzr.1000.2012-07-30T15:07.crash" that the bzr st reported?
<Dan_> Hi ... I have a question.  I thought my branch was bound and I made a bunch of commits that turned out to be local.  I did bzr bind.  I did bzr update which made my local commits show up as a pending merge.  But I don't want it to show as a merge, I wanted to bzr push instead.
<Dan_> I see that my head is still in the repo.
<Dan_> Hold on I skipped a step.
<Dan_> I then did bzr revert and I'm back to before I started my commits.
<Dan_> I can see that my revision is still in the repo by doing bzr heads --all.
<Dan_> But I don't know the command to make that dead head the head of my branch.
<Dan_> I found it:  bzr pull . -r revid:blahblahblah
<vila> Dan_: out of trouble ? Looks like you understood what happened and did what was needed :)
<Dan_> Yes, I figured it out ... thanks ... I just couldn't find the answer with google very quickly and thought IRC might be faster.  :)  I just uncommitted a revision because I know it prints out some message like, "You can restore the revision you just uncommited by using this command."
<vila> yeah, also, you could have done the pull earlier and just push
<vila> with a valid use case for 'bzr revert --no-backup' (which I never recommend otherwise)
<vila> and finally, I'm pretty sure 'bzr missing' would have ring a bell about the commits while unbound
<vila> never heart to use bzr missing
<vila> or 'bzr config' even
<mnn> vila: when I created a branch, added files, then I ignored a folder... however then I decided to move this ignore into bzr user config file (bazaar\2.0\ignore)... but when I remove ignore from .bzrignore in branch 'bzr status' shows unknown folder (the one I wanted bzr to ignore)
<mnn> vila: well that's weird - Bazaar Explorer (I believe correctly) doesn't show that folder as unknown (in working tree I see that it's ignored)... however 'bzr status' shows that folder as unknown
 * vila blinks at mnn 
<vila> mnn: even if you quit/start explorer ?
<mnn> vila: still the same
<mnn> isn't this a bug? I mean bzr must be using bazaar\2.0\ignore because it works on my other repo/branch
<mnn> bzr add obviously isn't helping (adds whole directory and its children)
<vila> you can test your ignore file with 'bzr ignored
<vila>  grrr
<vila> you can test your ignore file with 'bzr ignored' and 'bzr add --dry-run'
<mnn> yeah ... 'bzr ignored' returns nothing
<mnn> bzr add --dry-run wants to add supposedly ignored folder
<vila> I can't imagine why explorer differs... but if 'st'and 'add' agree, then there is something fishy there...
<vila> dinner time here, file a bug giving as much context as you can
<mnn> ok, thanks for the help in the meantime
<mnn> I can't reproduce it :(
<mnn> ... on a new, clean repo/branch
<vila> already added files are not taken into account when dealing with ignored files, this matters only for 'bzr add'ing unversioned files
<mnn> well... I removed the folder: 'bzr remove --keep folder'
<mnn> I must have broken something here
<mnn> > when dealing with ignored files, this matters only for 'bzr add'ing unversioned files
<mnn> I believe that ignored files should be taken into account by 'bzr status' as well, right?
<vila> mnn: right, but displayed as unknowns there *iff* they are unversioned
<mnn> so basically there's no way to make bzr ignore these files without adding them to .bzrignore?
<mnn> *this folder
<tsdh> Hi.  Is bzr-fastimport-0.13.0 incompatible with bzr-2.5.1?  At least I get "ImportError: cannot import name error" at "from bzrlib.trace import error, note" in bzrlib/plugins/fastimport/branch_updater.py and checking bzrlib.trace in the 2.5-branch, there's indeed no error function.
<vila> mnn: err, the way to make nzr ignore these files *is* to add them to .bzrignore OR add the right regexps in ~/.bazaar/ignore
<vila> s/nzr/bzr/
<mnn> well they already are in %AppData%\bazaar\2.0\ignore (I'm using WinXP)... and the same ignores work for other repos/branches
<mnn> the problem is that I removed the ignores from .bzrignore and added them to global ignores (in bazaar\2.0\ignores)
<mnn> and now bzr is showing them as unknown (Bazaar Explorer doesn't show them)
<vila> doesn't make sense, so I should be missing some info
<vila> or there is a bug
<vila> if you can't reproduce in  a clean branch, something is going on in your branch
<mnn> wait I might just have reproduced it... need to try it again
<mnn> vila: sorry for bothering you - when I discovered this "bug" I was using different BZR_HOME path than normal in %AppData%... when I used regular one in %AppData% unknowns doesn't show up
<mnn> but thanks for help anyway
<vila> doh, then of course you don't find the right ignore file, no worries, thanks for giving the answer to this puzzle :)
<mnn> yeah, I'm aware of that... just didn't notice it :(
<DrDynamic2> Hey folks, I recently upgraded to OS X Mountain Lion and it borked my bzr install. Upon running any bzr * command, it tells me bzrlib is not in my pythonpath. How can I add it back?
<mgz> in mac ignorance, just reinstall it?
<vila> DrDynamic2: better file a bug against bzr-mac-installers on launchpad (https://bugs.launchpad.net/bzr-mac-installers), I don't have osx ML to test so I can't tell which python version is provided nor where your bzrlib is installed
<vila> or rather was installed nor whether it's compatible with your installed python
<DrDynamic2> vila: It's 2.7 that is provided, that seems to be the cause.
<DrDynamic2> Alright I'll file a bug and reinstall :(
<txomon|home> hi, is bazaar recommended to be a DAM ?
<txomon|home> I want to get Versioned a Maya project, and I know git is not very keen on big files, so I am looking for a native support (git-annex)
<lifeless> bzr has the same issue git does
<mnn> could someone explain to me, when does iter_changes() returns (None, None) for kind?
<mnn> because right now it seems that it does for delete directories... but I noticed that just now
<mnn> also what are the exact meaning of versioned tuple? it's all fuzzy to me, what's written in InterTree.iter_changes()
<mnn> really? nobody? oh, come on... :(
<wgz> the two tuple from iter_changes?
<wgz> it's like the others, first item is state in the old tree, second is state in the new tree
<wgz> ah, you'd quit
<mnn> yeah, it shut me down
<mnn> did you wrote something?
<wgz> by versioned tuple you mean the 2-tuple that's the fourth item in iter_changes results?
<wgz> it's like the others, first item is state in the old tree, second is state in the new tree
<mnn> yeah
<mnn> ah
<mnn> yes, thanks
<wgz> but note aloo want_unversioned defaults to False
<mnn> because my auto-rename-fix has failed on one autorenaming a few hours back and now I want to reproduce it and got into situation where kind is (None, None) (which I really didn't anticipate)
<mnn> also why is kind (None, None) - both for old tree and new tree?
<wgz> it does seem a little suprising
<mnn> could it be because it's a directory that's ignored?
<wgz> I suspect it could happen if a file was added in this revision
<wgz> but is then removed from disk
<wgz> so, 'missing' state with no parent in the last revision
<lifeless> yes, exactly that.
<mnn> wgz: thanks for approving auto-rename-fix, but that was a bit to early... I mean I just reported that it does not work on the situation described above
<wgz> I also put it up for another review at the same time :)
<wgz> I should have added a text string as the review time to emphasise I've not actually thought about the logic in it yet
<wgz> *review type
<wgz> adding more failing test cases for things that break is a good way to proceed I'd say if you're still having issues
<mnn> well first I need to wrap my head around whole iter_changes() and its return values for various tree states
<wgz> maybe grep for some tests that use iter_changes and add some variations on your test that also check its output maybe?
<wgz> ...anyway, I need to go to bed before I get any more cross-eyed
<mnn> I will go as well
<mnn> thanks for help and guidance
<mnn> good night
<wgz> night!
#bzr 2012-07-31
<txomon|home> thank you lifeless
<txomon|home> but anyway, bzr can work in non-distributed mode?
<txomon|home> I am talking about http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/bazaar_workflows.html?highlight=distributed#centralized-with-local-commits
<txomon|home> is there any sharing of data between same elements in different branches? or is just like svn?
<txomon|home> I mean when storing
<bob2> unclear what you mean
<bob2> do you mean "Do repositorities dedupe revisions common to multiple branches in that repo"? if so, yes
<bob2> ps bound branches are imvho a bad idea
<jelmer> moin
<mgz> morning!
<jam> mgz, vila, jelmer: morning
<vila> morning
<jam> care to join me in mumble?
<vila> <shudder> bzrlib.tests.blackbox.test_serve.TestBzrServe.test_bzr_serve_supports_configurable_timeout hanging rings anyone's bell ?
<vila> ha, never mind, there is a TODO in the test: TODO: Use something like signal.alarm() so that if the server doesn't
<vila>         #       properly handle the timeout, we end up failing the test instead
<vila>         #       of hanging forever.
<vila> ...and using alarm() has been implemented indeed
<mgz> alarm is dodgy
<mgz> but so is our serve setup in general, so hey.
<vila> the way we use it in features.TimeoutFixture should be ok though (at least on unix)
<frathgeber> hi all
<mgz> hi!
<frathgeber> i'm (still) looking for a way to reliably interact with bzr branches through git
<mgz> why?
<frathgeber> because bzr doesn't have interactive rebasing
<frathgeber> i know you'll hate me for that
<mgz> sigh
<mgz> I said that just for the rhyme
<frathgeber> hehe. it's a bit heretic to come to #bzr and declare you want to use git on bzr branches, i appreciate that
<mgz> well, tell us if you find a way that works for you.
<vila> yeah :) Especially since what you're asking for as to be implemented in git :)
<frathgeber> but maybe you can give me some advice whether my current plan could work
<frathgeber> vila: yes, that's the problem
<mgz> I'm curious, how often do you modify an n-2 commit vs just the n-1 commit?
<tbf> what's bzr's version of "git add -p"?
<frathgeber> i've given up on git-bzr-ng and all the other so-called git-bzr bridges because they use fast-im/export, which is a horribly bad idea
<mgz> tbf: shelve and the 'e' option where needed, does the inverse
<frathgeber> because you don't get a stable history
<frathgeber> mgz: all the time. we have another project where the repo is in git and i've got so used to the workflow that i don't want to miss it when working with a bzr repo
<tbf> mgz, hmm... seems  my bzr is too old to have that option.
<mgz> tbf: you need to have EDITOR set to something
<mgz> or change_editor in bazaar.conf, see `bzr help shelve`
<tbf> mzr: 2.5.1 really just says "bzr: ERROR: no such option: -e"
<mgz> it's one of the things you can type during shelve, it's not a command line switch
<tbf> ah! ok!
<mgz> if you need to split a diff hunk into two parts, for instance
<frathgeber> my current plan is as follows: 1) import the bzr branch into a git repo via fast-import 2) bzr branch the git repo so i get a bzr-git branch 3) work on the git repo 4) git push to the bzr-git branch 5) bzr push to the upstream bzr branch from the bzr-git branch
<frathgeber> is that going to work?
<mgz> frathgeber: ...I don't think so
<frathgeber> is step 5) going to fail?
<mgz> you're just making two git branches that share history, but are different to the bzr branch
<frathgeber> because the fast-import will destroy the relationship, right?
<mgz> right. isn't there a much simpler way?
<mgz> hm... how do you tell bzr-git to create a local git branch from bzr...
<tbf> how do i tell bzr to always print logs in --forward order? is there a list of all configuration options?
<frathgeber> mgz: i'm not sure you can, but i'll have a look. unfortunately the docs on bzr-git are rather sparse, maybe jelmer can help
<mgz> frathgeber: so, you can dpush to a branch created `bzr init --format git`
<mgz> but you still have the problem that you're trying to work backwards
<mgz> it would be easier for you to spend this time just making bzr-rebase do what you want.
<frathgeber> you may be right
<frathgeber> it just seems so silly it works fine in the one direction and not at all in the other
<mgz> bzr is flexible, we can store extra stuff required for git interoperability
<frathgeber> i guess the git community is to blame because they're not keen enough to interact with bzr branches
<frathgeber> and launchpad
<mgz> git is also flexible, but not in a way that's useful for storing extra stuff for bzr interoperability
<frathgeber> yep
<frathgeber> i just found another possible way: bzr serve --git (see https://bugs.launchpad.net/bzr-git/+bug/544776)
<ubot5> Ubuntu bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,Triaged]
<jelmer> frathgeber: bzr serve --git doesn't really work at the moment - it depends on roundtriping support
<frathgeber> which is exactly what i'm looking for :)
<frathgeber> so at the moment it's basically read-only?
<jelmer> frathgeber: yes
<frathgeber> are there any other ways to make it work?
<frathgeber> i haven't found any yet. git-bzr-ng makes promises it cannot keep
<jelmer> frathgeber: no, the roundtripping support is really required for this kind of thing.
<frathgeber> jelmer: thanks, that was the answer i anticipated
<frathgeber> does that require work in dulwich? bzr-git? both?
<jelmer> frathgeber: bzr-git
<jelmer> the work has mostly actually been done, but there are some smaller kinks to work out
<frathgeber> anything i can beta test?
<frathgeber> i'm happy to be a guinea pig
<jelmer> frathgeber: see mapping.py line 457
<frathgeber> in bzr-git/trunk?
<jelmer> frathgeber: yep
<frathgeber> that's what your comment refers to in #544776 i guess?
<jelmer> yeah
<frathgeber> brilliant. i'll bash on it and report back if and when it breaks
<frathgeber> what's the easiest way of experimenting with it then? via bzr serve --git?
<frathgeber> or can i convert the bzr branch to a git repo via bzr-git in other ways?
<mgz> you can just push into a fresh branch in git format
<frathgeber> grand
<mgz> followed by `bzr co` or `git reset --hard` to get a tree
<mgz> (or pull, to avoid that, for that matter)
<frathgeber> so getting back to the earlier conversation: will i then be able to push my changes back to the upstream bzr branch?
<jelmer> frathgeber: you're welcome to report issues with the roundtripping code, but I don't think there is anybody actively working on it anymore
<mgz> he's welcome to *fix* issues... :)
<frathgeber> i guess via a detour of pulling into a bzr branch in bzr format and pushing upstream from there?
<jelmer> frathgeber: bzr serve --git should allow pushing
<frathgeber> ok
<frathgeber> mgz: sure, i'll see what i can do (no promises at this point)
<jelmer> frathgeber: but I doubt if that actually works
<frathgeber> jelmer: i'll give it a try
<frathgeber> it's not fast, so much i can already say ;)
<frathgeber> should have started on a smaller repo
<mgz> yeah, doesn't look hopeful: <http://pastebin.ubuntu.com/1121209/>
<mgz> I might be missing a few fixes though, not sure what bzr-git version I'm running
<mgz> better but no win: <http://pastebin.ubuntu.com/1121220/>
<frathgeber> i've got this far:
<frathgeber> http://paste.ubuntu.com/1121260/
<jelmer> frathgeber: are you running an old version of dulwich perhaps?
<jelmer> another option is that this bitof bzr-git just isn't unit-tested well enough and wasn't updated
<frathgeber> yep, i'm running on bzr-git trunk but dulwich 0.8.5-2
<frathgeber> will see if dulwich trunk does better
<AfC> off topic, but perhaps you might know: why would pycrypto depend on a debug package (python-all-dbg in this case)?
<jelmer> AfC: generally speaking, that seems like a bad idea
<AfC> you would have thought so.
<jelmer> AfC: this is a dependency in the binary package rather than a build-depends?
<AfC> jelmer: I tried stripping it out, and sure enough the build broke. There's actually some command python-2.7-dbg or something the package tries to execute.
<jelmer> AfC: if it's a build-dependency then it would make sense
<AfC> jelmer: looks like a Build-Depends
<jelmer> AfC: since it might want to install debug symbols in e.g. python-crypto-dbg, for those that want them
<AfC> jelmer: [why does it make sense? Other languages use -dev packages for that sort of thing]
<AfC> weird
<AfC> anyway, thanks
<jelmer> AfC: there are -dbg packages for C libraries too
<AfC> sure, but you don't need them installed to build a package, no sir!
<jelmer> AfC: you do need to install the dbg packages for their dependencies sometimes during build
<AfC> anyway
<AfC> never come across that before
<AfC> </offtopic>
<AfC> thanks
<jelmer> AfC: sure
<frathgeber> jelmer: with updated packages from the bzr nightly ppa the issue remains
<jelmer> frathgeber: I guess it's just regressed :-/ I haven't touched that code in ages
<frathgeber> yep. i might have a chance to look into it. but not now i'm afraid
<mnn> wgz: question about RenameMap
<mgz>  hit me.
<mnn> if user has an ignored directory in his repo, but decides to add it... but then decides to move that directory around, currently RenameMap ignores new location of that directory (even though it's that (ignored) directory that was added)
<mnn> shouldn't RenameMap handle such situation and add such directory?
<mgz> I'm not sure I follow, is the a commit involved too?
<mgz> or is this all in pending changes?
<mnn> well all without commit
<mgz> but also without a state refresh?
<mnn> because if there was a commit, such situation wouldn't exist
<mgz> because with that, it all seems normal
<mnn> well because if user manually adds such directory (bzr add --no-recurse dir) and then runs autorename, he gets "removed <old_dir>" and "added <new_dir>"
<mnn> (+ renamed children of that directory)
<mgz> ah, so not bzr mv, which works as intended: <http://pastebin.ubuntu.com/1121522/>
<mgz> autorename isn't the most robust thing in the world
<mnn> yeah... but I'm trying to make it at least a bit better :) because sometimes I move/rename things around and I'm just too lazy to do it with Bazaar (well I basically won't leave my IDE (Visual Studio) when doing this)
<mgz> go for it.
<mnn> or if I move/rename stuff I'm just used to use file manager rather than bazaar
<mnn> *used to do it in file manager
<mnn> I'm thinking of making RenameMap taking into account filenames - because I have some files that have exact contents but different filenames
<mnn> and maybe make it optional
<mnn> also: https://code.launchpad.net/~mnn282/bzr/sftp-unsupported-operation-more-info/+merge/116849/comments/252345
<mnn> I didn't understand this very well:
<mnn> Including the path, and just using the operation name rather than the text form would work for everything but the symlink/rename case, which could just be an optional target_path param to the exception.
<mnn> mgz: I've adjusted RenameMap a bit to handle a bump from yesterday, however, I'm not sure about the whole old tree, new tree stuff from InterTree.iter_changes()
<mnn> original code in RenameMap had this:
<mnn> missing_parents.setdefault(parent[0], set()).add(file_id)
<mnn> I
<mnn> I'm not sure why would it check for parent in old tree... I changed it to parent[1] (new tree parent)... that fixed the bump from yesterday and didn't break any tests
<mgz> mnn: haven't got any particular insight there, but I don't really like rename_map doing actions on the tree that change its state
<mnn> well, true but that's what dry_run is for, right?
<mnn> mgz: don't you think?
<mnn> and IMO it should change tree state - I mean it has to remap delete/missing files/directories to new ones (e.g. move/rename)
<mgz> mnn: so, specifically I don't think _make_inventory_delta should be using tree.smart_add
<mnn> well I don't like it either
<mnn> but otherwise it can't create new entry correctly
<mgz> it's fine that guess_renames fiddles with the tree, that's what it promises, and as you say is guarded by dry_run
<mnn> because parent_id is None for new directories... that's why it has to add them
<mnn> but that smart_add is not guarded by dry_run... I fixed it just now
<mgz> it might mean making the logic in guess_renames two-pass
<mgz> I'll think about it a bit and see if I come up with anything
<mgz> no, I think one-pass is fine, you just need a level of parent indirection
<mnn> hmm... that's little fuzzy to me... what do you mean by that?
<mgz> the sticking point is you need a parent_id for the containing directory before you can create a delta for it's contents, right?
<mnn> right
<mnn> otherwise new_entry.parent_id becomes None and that causes real trouble
<mgz> so, you create a delta adding the parent dir, then a pseudo-delta that refers to the parent so the add logic can lazily look up the parent id
<mgz> I'd just refactor to defer entry creation till just before add
<mgz> then provided you detect missing parents and insert them before children in the stream, you're all set.
<mgz> so, don't put new_entry in the delta, put entry in and add a helper that does the copy and details fill in
<mgz> follow me?
<vila> mgz: you may not like the suggestion but this sounds like a tree transform job to ensure a safe result (as a bonus you get some sort of rollback protection)
<mgz> feel free to guide mnn through doing that...
<vila> yeah :-/
<vila> EOD here
<vila> On the other hand, if this leads to dirstate/inventory bugs (which is what occurred when I didn't use tt for conflict resolution :-/)...
<vila> tt should accept rename attempts by just feeding it with adjust_path() calls
<vila> then tt.apply() should generate conflicts or a proper tree/dirstate
<vila> this doesn't require ordering either
<vila> oh, and there is a magic call to register trans_id...
<vila> tt.trans_id_tree_path() or some variant
<vila> mgz: i.e. renames are what PathConflict._resolve handle, here this may be even simpler
<vila> mnn, mgz: I'll look into it tomorrow if there are some failing tests somewhere ;)
<mgz> the mp is pretty simple, and includes a failing test.
<mgz> see your inbox :)
<mnn> mgz: I've been able to tackle that problem with adding new directory... however I can't handle this situation:
<mnn> add directory (with files), move that directory under existing versioned directory
<mnn> those files underneath the new directory get kind == (None, None) from InterTree.iter_changes()
<mnn> and I don't think that's right - it should be kind == (None, 'file') right?
<wgz> yeah, sounds more reasonable.
<mnn> however this goes beyond me... that stuff is really complicated :(
<mnn> could you take a look why it is returning (None, None) ?
<wgz> mnn: I need to cook and stuff right now, but will poke try to have a look later on
<mnn> no problem, thanks for help
#bzr 2012-08-01
<bradm> afternoon
<bradm> I'm seeing a weird error in a bzr tree:
<bradm> AssertionError: get_next() called when there are no chars left
<bradm> any hints on what it could be?
<lifeless> bradm: yes, you have a truncated dirstate file.
<lifeless> bradm: e.g. something powered off or killed a bzr process mid-write.
<lifeless> bradm: you'll need to replace the dirstate with a fresh one.
<bradm> lifeless: that's enitrely possible with this system
<bradm> lifeless: I've fixed similar type bugs by branching and then copying the dirstate file back, that seemed to help
<lifeless> yes
<lifeless> thats exactly what you need to do.
<lifeless> And try not to kill bzr so willynilly ;)
<bradm> the last error message was a bit more helpful, this one suggested it was an internal error and to file a bug
<lifeless> ah
<lifeless> worth reporting a bug
<lifeless> same root cause but the error could indeed be better
<fullermd> Y'know there's some command to write out a fresh dirstate.  Saves the manual branching and copying around.
<vila> bzr help repair-workingtree
<bob2> bzr atomically-write-to-files-to-begin-with
<vila> bob2: bug #98836 ?
<ubot5> Launchpad bug 98836 in Bazaar "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] https://launchpad.net/bugs/98836
<bob2> hahaha
<bob2> :)
<vila> AFAIR, dirstate is the only file bzr modifies in place
<mgrandi> i used to get a lot of errors relating to locks >.>
<vila> mgrandi: on windows ?
<mgrandi> yeah
<mgrandi> can't really reproduce it consistantly though
<vila> yeah, that's a pita, we know there is something going on but lack reproducible recipes :-/
<vila> or may be I'm not up to date with the details...
<mgz> morning
<bob2> vila, why's it done in place?
<vila> bob2: hysterical raisins :-/
<vila> there is code somewhere to switch to a different implementation but I can't remember where :-/
<bob2> heh
<vila> mgz: ghaa, I looked at the rename_map stuff... looks like I was over-optimistic :-(
<mgz> :)
<vila> mgz: on a more positive note, I've got a test for bug #957049
<ubot5> Launchpad bug 957049 in Bazaar "bzr config -d lp:bzr is broken" [High,Confirmed] https://launchpad.net/bugs/957049
<mgz> ace, so you can stick that on top of larsiq's branch and land
<vila> what ? Without review ? :-D
<vila> submitted against 2.5, will merge up when it lands
<mgz> well, you could have put it up for review
<mgz> but I trust you to have got the small details right, and trust pqm to tell you if you got anything major wrong :)
<vila> hehe, yeah, sure, but indeed the fix was quite simple (and right to the point), so a test failing without the patch was all that was needed
 * mgedmin wants $(bzr nick) in his bash prompt
<LeoNerd> Easy enough to arrange
<LeoNerd> I have all sorts of crazy magic in my bash prompt; multiple VCS integrations, colours, job counts, pushd status,...
<mgedmin> I think I managed: https://github.com/mgedmin/dotfiles/commit/b8a3cbb9074ba6d6309835f2b884168f88975fbe and https://github.com/mgedmin/dotfiles/commit/80d0430c6181ac817ac3f63fa9fe7d5b42bf801f
<mgedmin> (this was going to be url to commit #1 followed by "but it is amaaaaaaaaaaaAAAAAAzingly slow in svn checkouts", but then I discovered bzr help global-options)
<mgedmin> job counts is interesting; could I see your bashrc?
<LeoNerd> Mm.. not terribly easily; it's split across about 20 files
<LeoNerd> I'll dig out some piece
<mgedmin> also, I'd like to compare the bzr solution -- maybe there's something more efficient/cleverer compared to what I have
<mgedmin> no github url?
<LeoNerd> er.. no?
 * mgedmin suddenly realizes github urls might not be the most politic thing to wave around in a #bzr channel
<LeoNerd> http://pastie.org/4371428   some bits and pieces
<mgedmin> and the bzr bits?
<LeoNerd> http://pastie.org/4371445
<mgedmin> ooh, clever, only look for dotted dirs when $PWD changes
<mgedmin> (at the cost of not noticing when 'bzr init .' takes place, I suppose)
<LeoNerd> Yeah; I considered that reasonable
<LeoNerd> bzr is fast enough without that, but p4 is waaaaaaayslow
<yolanda> hi, can i get some help? i'm having a problem doing a merge, it says 2 revisions are identical, but they do have changes
<thomi> Is there a way to stop bzr checking the host authenticity for bzr+ssh connections? Alternatively, can anyone suggest why it might keep asking again and again for the same host?
<LeoNerd> Something in your .ssh/config file?
<LeoNerd> Have you set the hostkey file to /dev/null?
 * thomi checks
<thomi> LeoNerd: nope, the IdentityFile and User is set for that host, but nothing else
<mgz> yolanda: need more details to give any kind of answer
<mgz> thomi: do you get the same thing if you just ssh to the host? if so, it's not a bzr issue, use `ssh -vv` to debug
<mgz> I'd guess something like known_hosts having the wrong perms
<thomi> mgz: yes, the same thing happens if I ssh manually. If I manually accept the key, it works for a while, and then starts failing sgain :-/
<thomi> ...almost as if somthing is overwriting the known_hosts file
<thomi> anyway, i guess we know it's not a bazaar issue :)
<mgz> ah, if it accepts it for a bit sounds more like something along those lines
<mgz> I'd try and catch a few that fail with -vv, and double check the fingerprint is actualy static, and keep a few known_hosts copies
<mnn> hi, everyone... is cherrypicking that bad?
<mnn> because I somehow managed to do it and now in bazaar explorer's log's context menu is showing Reverse cherrypick
<mnn> is it something I need to worry about?
<mgz> nope, it's a useful thing, but doing it by accident doesn't sound normal
<mgz> basically it's a merge of a revision range, which is then just the content of those changes, rather than any of the revision data
<mnn> ^^ well, if I remember correctly, I merged into my trunk just one file from other branch
<mnn> mgz: and why no revision data is merged?
<mgz> because you're not actually merging that revision
#bzr 2012-08-02
<mgz> morning
<mgedmin> if I can't see the diff I'm committing while I'm writing a commit message, I'm going to cry
<mgedmin> is there a solution?
<mgedmin> a config setting of some kind to make bzr ci equivalent to bzr ci -p?
<jelmer> mgedmin: you can use an alias; "bzr alias ci='ci -p'" I think
<mgz> `bzr alias ci="ci --show-diff"`?
<mgz> lost by milliseconds...
<mgedmin> thanks!
<fullermd> And then you can join me in complaining about how it doesn't let you turn off the prefixes in the diff...
<mgedmin> what prefixes?  the a/ b/ thing?
<jelmer> mgedmin: I suspect so
 * mgedmin discovers that vim's builtin syntax/bzr.vim can highlight the diff portion, but only if you put :let bzr_highlight_diff =1 in your ~/.vimrc
<jelmer> mgedmin: hmm, seems odd that's not the default?
<mgedmin> upstream appears to be https://github.com/hdima/vim-scripts/blob/master/syntax/bzr.vim
<vila> I think I've got a track about which tests try to use disk resources (most notably .bzr.log) while not using the right base class
<mnn> mgz: if cherrypicking does not store revision data, how should I proceed with stable branches?
<cielak> hello everyone
<cielak> I have a problem with bazaar I cannot troubleshoot
<cielak> can anyone give me a hand?
<jelmer> cielak: what's the error?
<cielak> jelmer: whenever I try push things to launchpad, it uploads few kB, and then completely freezes
<cielak> without any error message
<cielak> it stays in this state for 10-15 minutes
<cielak> and then says:    Write failed: Broken pipe
<cielak> on the other hand, I can pull things without any problems
<mnn> does anyone know what's status of nested trees?
<mnn> http://wiki.bazaar.canonical.com/NestedTreeProgress
<mgrandi> is there a installer for bzr 2.5.1 for mac? its not ont he webpage
<mgrandi> also, the bzr dmg is not signed so  now with mac os x mountain lion it wont install by default >.>
<jono> hey all
<jono> I am getting this area when trying to push to LP:
<jono> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~jonobacon/ubuntu-accomplishments-system/adminportal/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<jono> any idea how I fix this?
<lifeless> bzr launchpad-login
<lifeless> if you're using an lp: branch alias.
#bzr 2012-08-03
<bignose> I've accidentally done âbzr pull . -r revid:blahâ on the wrong branch
<bignose> and now I want this branch to be back to where it was
<bob2> do you know where it was
<bignose> I know the revid I need to get back to, but when I pull to that it just says âNo revisions or tags to pull.â
<bignose> but the history is still for the wrong branch.
<bob2> can you just reclone
<bignose> I don't know, will that not destroy things like shelves?
<bignose> I'd prefer to do it with âpullâ since that seems the right operation for fixing this non-destructively
<bignose> so, âpullâ both pulled in the revision, and switched the history of this branch.
<lifeless> bignose: bzr pull -r xxx --overwrite
<bignose> now attempting to âpullâ it already has the revision it needs, but refuses to change the history this time.
<lifeless> pull won't do anything if you are pulling a successor
<lifeless> sorry, a predecessor
<lifeless> unless you tell it you mean it
<bignose> bizarre. now I'm getting âUnable to obtain lock filtered-46882576:///~benf/Projects/bnv/cam/trac-380_setup-supertues-2012-09/.bzr/branch/lockâ
<bignose> and every time I break the lock, then âbzr pull â¦â again, it complains about the lock again.
<lifeless> is the branch bound ?
<bignose> yes
<lifeless> so pull is locking both the master and the slave
<bob2> bound:|
<bignose> and âbreak-lockâ is different?
<lifeless> there are two possible things here, IIRC break-lock only checks the specific branch
<lifeless> so you may need to break-lock both branches
<bignose> the thing is, it appears to be a new lock each time
<bignose> âlocked 2 seconds agoâ every time
<bignose> i.e. the lock is occurring within the execution of âbzr pull â¦â, but then it's complaining about it before it completes.
<lifeless> can you pastebin, bzr info -v, the exact command you're running to do the pull, and the contents of .bzr/branch/branch.conf somewhere?
<bignose> shall do, thanks
<bignose> lifeless: <URL:http://dpaste.org/ZNWIt/>
<lifeless> ok, its possible that you have found a bug (well, clearly its a bug that this doesn't work, but you know what I mean)
<lifeless> I suggest:
<lifeless> bzr unbind
<lifeless> do the pull
<lifeless> do a bzr push --overwrite <full url here>/trac-380_setup-supertues-2012-09
<lifeless> then bzr bind
<lifeless> which should get you past the situation
<lifeless> and then file a bug describing it, the version of bzr, and include the contents from that pastebin
<bignose> lifeless: thank you.
<bignose> (using âbzr bindâ before âbzr push --overwriteâ worked, and meant I didn't need to specify the remote location.)
<lifeless> np
<bignose> :-( still won't let me file a bug without making a new Launchpad identity
<lifeless> in your case I believe that that is 'a' Launchpad identity
<bignose> so I'll have to leave that to someone with an account there.
<bignose> $ bzr version
<bignose> Bazaar (bzr) 2.6.0dev2
<bignose> on Debian Wheezy.
<lifeless> thanks
<bignose> thank you all!
<vila> jelmer: ping, can you look at bzr.dev revno 6207.3.2 (merged in revno 6214) and explain me why you changed bzrlib/tests/__init__.py there ?
<vila> jelmer: I found that while investigating an almost unrelated issue and couldn't understand the comment about  http://pad.lv/825027
<ubot5> Launchpad bug 825027 in Bazaar "create_safety_net is brittle" [High,Fix released]
<mgz> morning!
<vila> morning mgz
<mgz> how are you vila?
<vila> fine :)
<vila> found another weird merge circa revno 6214, see my last mp
<mgrandi> why would libsvn.dylib not be loaded? or missing?
<mgrandi> do i need to reinstall svn or something?
<jimis> hi all, I work on light checkout of a tree-less repo. To rename a branch on that repo can I just rename the directory?
<jimis> What about the checkout dir, will it understand the change?
<fullermd_> mv'ing the branch by itself is fine.  You'll have to update things that point to it to the new location.
<fullermd_> Checkouts would be one such thing.  Saved locations (push, pull, etc) in other branches referring to it would be another.
<jimis> thanks fullermd, I'll try it
<jimis> how do I update a checkout?
<mnn> mgz: if you're here, have you looked into InterTree.iter_changes(), why it does kind = (None, None) in some cases?
#bzr 2012-08-04
<fullermd> jimis: With switch, I'd say.
<lifeless> mnn: (None, None) is a new but missing file
<mnn> thanks
<mnn> but I kinda forgot, what the exact context was :(
<mnn> lifeless: if (None, None) is new, but missing file, how do I get it's kind - directory/file from InterTree.iter_changes()?
<lifeless> mnn: there is no kind for such a file
#bzr 2013-07-29
<tacorwin1> could anyone help me connect to a branch on launchpad using the windows version od Bazaar?
<karlis> Hi there. Can anyone please help me figure out what be the best layout for our branches. We want to be hooked in to our bzr server and also publish our work on Launchpad. We have a small 2 developer team.
<karlis> At first I figured we could just commit everything to our server then let Launchpad mirror our code, but that didn't work out since we have a bzr+shh setup.
<LeoNerd> I bzr+ssh to my server, which also has an HTTP server pointed at it. LP only needs to read, so HTTP is fine for that
<karlis> I see thanks. Now i just need to figure out the layout
<LeoNerd> Layout?
<karlis> Something like explained here
<karlis> http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/shared_repository_layouts.html#nested-style-project-branch-sub-branch
<karlis> I'm new to VCS
<karlis> Right now we use a centralised approach where me and my colleague checkout and commit to the same branch
<karlis> I envisioned a trunk, dev branch and releases. Seems a lot of devs are going for a layout where series are major releases and milestones represend sub-versions.
<karlis> Would it be adequate to tag a revision and upload that as a milestone or a release?
<jelmer> karlis: sure
<karlis> Okay, it seems its starting to click together slowly
<karlis> Lets say i go for something like here: http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/shared_repository_layouts.html#sorted-by-status-dev-merged-experimental
<karlis> And i have a trunk, releases, merged, dev folders. How do i go about them not being part of the of the main branch?
<karlis> I tried bzr init-repo --no-trees, but then all branches say they have no working directory and don't work until i make a checkout.
<karlis> Is that a feature or a limitation. I don't get whats the use for it, besides the combined history
<karlis> LeoNerd: Sorry for the long pose on the subject. But what do you mean by HTTP server pointing at it? Would i have to setup our sever to redirect to the bzr URI?
<karlis> I'm not an admin so I'm not entirely sure what to look for
<LeoNerd> ?
<LeoNerd> HTTP servers just serve the contents of a filesystem. A bzr repo is a filesystem
<LeoNerd> That's sufficient
<LeoNerd> Mine is here  => http://bazaar.leonerd.org.uk/
<karlis> Cool domain name ;)
<karlis> So they are leading to the .bzr folders. That is all launchpad needs?
<jelmer> karlis: yeah, that should be sufficient
<karlis> Thank you both :)
<m_tadeu> hi...how can I get the last tag string?
#bzr 2013-07-30
<joako> The problem I have with bzr is it consumes too much memory. I simply wish to Â¨downloadÂ¨ some code. After 12mb is downloaded 225mb of RAM has been consumed
<thumper> and that is a problem because...
<joako> After about 50mb is downloaded approx 500mb is consumed and I am out of memory and bzr abruptly exits with a message Â¨KilledÂ¨
<joako> In dmesg there is the message: Out of memory: Kill process 3572 (bzr) score 500 or sacrifice child
<joako> I just wish to download the code of launchpad.net but I donÂ´t see any direct download option
<SamB> joako: you might want to consider adding some swap
<joako> SamB, Yes but why is it so complex to download a software? Why does it need 10x more memory than what it downloads?
<SamB> joako: who knows :-(
<thumper> python possibly
<SamB> whoever knew probably moved on
<thumper> lifeless probably knows
<SamB> thumper: pretty sure that's not why
<joako> Is there any other way? E.g. in sourceforge.net there is a download zip option direct from the browser
<thumper> joako: what are you trying to get?
<spiv> There's extensive discussions on the list archives about why it consumes so much memory.
<spiv> The simplest workaround is usually to download incrementally; "bzr branch -r 1000 URL; cd proj; bzr pull -r 2000; bzr pull -r 3000; â¦"
<SamB> hmm, true
 * SamB couldn't remember if that would actually work until he just now realized "well otherwise 'bzr pull' would always take AGES on lp:launchpad" ...
<spiv> (Btw, âpythonâ isn't why)
<spiv> Well, mostly ;)
<SamB> yeah, Python can only explain a small amount of it
<SamB> like I might believe a 2x-4x lossage to Python
<lifeless> thumper: oh hiai?
<thumper> lifeless: joako above was complaining about the memory use of bzr
<thumper> lifeless: I said you'd probably know why it was as high as he was reporting
<lifeless> oh
<thumper> because I have NFI
<lifeless> so  last I recall a big chunk was the slab cache
<lifeless> if you're pulling off of a smart server it can mostly blat stuff to disk but we still need to do some processing for integrity
<SamB> lifeless: he was particularly complaining that it's many times as big in RAM as on the wire
<lifeless> SamB: that's partly because we get 1000's
<lifeless> SamB: -> 1 compression
<SamB> probably it would be better if validation could be performed by reading it back off the disk
<lifeless> so the thing to do would be to oke at it with jameinel's memory profiler and see where the usage is
<lifeless> my bet is on cached gc slabs, which is a tunable tat can be tuned down
<lifeless> (in exchange for more reads off of disk...)
<SamB> that sure beats being OOM killed ...
<karlis> How would you go about creating a folder in launchpad? Something like lp:~team/project/container-folder/branch?
<thumper> karlis: you can't
<karlis> thumper: thats what i started to figure
<thumper> karlis: branches are a flat namespace in launchpad on a project
<thumper> well, flat in that it goes ~owner/project/name
<thumper> so that tuple has to be unique
<thumper> no folders
<thumper> it complicates traversal
<karlis> So what is the convention? I just create my structure locally and push the branches straight to my project?
<karlis> Seems things could get cluttered if you make to many release branches.
<karlis> thumper: Ether way thank you for the explanation
<thumper> well, it depends
<thumper> launchpad tracks merges,
<thumper> so if a branch is merged into trunk, it gets marked as merged
<thumper> so doesn't show up in the default branch listing
<thumper> normally you'd have the development focus series branch set
<thumper> it becomes the short lp:project name
<thumper> other series can have linked branches too
<thumper> to be lp:project/series
<karlis> Good to know
<karlis> Thanks btw ;)
<karlis> Is there a way i could move branches around my repository. But so they change there bound URI to an appropriate destination on the bzr server?
<karlis> I guess what I'm asking is there a bzr way to do mv,init,bind?
<maxb> I can't underderstand what you're trying to do
<karlis> i want to move a branch from folder dev to merged
<maxb> If you want to move whole branches around on disk, you just do it (subject to the restriction that if they use a shared repository, you can't move them outside it)
<karlis> I guess that makes perfect sense if i think about it
<gakins> I'm having permission problems with bazaar.  (I'm also new to bazaar so forgive me if this is stupid).  It looks like when I do a bar pull that I'm can't access the 'lock' did because my user only has read) access.  Is it sufficient to give a 'group' write access to the entire project directory?  Or is there more finesse required?
<gakins> bzr pull.. not bar pull (Stupid autocorrect)
<mgz> try creating a new branch from what you're trying to pull from
<gakins> No.  I have a local repo which another developer created.  I'm trying to get the most recent code from the remote repo
<mgz> right, so find the url of the remote repo `bzr info`
<mgz> then create a new branch `bzr branch REMOTE NEW-LOCAL`
<mgz> you can fiddle with the bits you have on disk if you like, but it's just as easy to get a new copy of what you actually want
<gakins> It appears that you're saying just to ignore the current local branch and create a new one.. am I understanding that correctly?
<gakins> mgz:Ah.. OK  Thanks!
<mgz> yup. there are other options, but that's simple and doesn't matter how screwed up the perms are with what you have currently.
#bzr 2013-07-31
<rgomes> hello guys. How can I find the origin of a branch (from command line interface), please ?
<jelmer> rgomes: what do you mean with origin exactly? The location of the branch it was originally cloned from?
<jelmer> "bzr info" should tell you that location ("parent location") if it has not been changed since
<andrewuk> Hello
<andrewuk> i am after some help on installing bazaar on a synology NAS drive
<andrewuk> I have install py26-bzr from ipkg and py26-bzrtool but i am stuck now as to what to do next
<andrewuk> seems the world of bazaar had gone very quiet recently :(
<vila> andrewuk: nah, same as ever, people asking a question and leaving before anybody could answer have followed a constant rate over the years
<fullermd> I tried increasing the rate by being slower at answering questions.  But I realized I _can't_ get any slower, so...
<vila> Now that I haunt other channels though, I realize #bzr has always been a comfy and friendly one ;) Or is it cozy ?
<fullermd> I dunno who keeps moving the couch, but I wish they'd stop.
<vila> hehe
#bzr 2013-08-01
<rgomes> jelmer: hello. I'm sorry for delay. Yes: bzr info informs about the parent location. It also informs about stacked branches, if it is the case. thanks a lot :)
<rgomes> jelmer: I found this information in bzr explorer, but had trouble to find via command line. I assumed that it was much more 'hidden' than it actually is.
<andrewuk1> Hello Vila, I thought it might take a while for someone to read my question so i did make sure to check the irc logs :)
<SamB> andrewuk1: maybe you should have mentioned your intention to do so before so people would still bother to take a stab at your qustion despite your not actually being here
<andrewuk1> yes true i should of done so
<andrewuk1> is it worth me posting the question again or are people likely to look back through the logs and spot it?
<SamB> so what exactly isn't working that you were hoping to get to work?
<andrewuk1> I am trying to setup Bazaar on a Synology NAS drive. I have installed py26-bzr and py26-bzrtools
<andrewuk1> but now that i have done that i am unsure what to do next as simply typing in bzr just returns an error as if nothing has been installed
<andrewuk1> i have have installed py26-bzr and py26-bzrtools through ipkg
<andrewuk1> right time for me to go and start my working day but i will keep track of the logs until i finish work
<vila> andrewuk1: Damn, I've not started my day yet, but you need to be able to run bzr first before we can really help ;) I don't know how synology works nor which kind of OS it is (though I guess it's some sort of GNU linux so you need to find *where* the 'bzr' script has been installed and make sure the containing directory appears in your $PATH)
<vila> andrewuk1: From there we can help but you're almost done (especially if you have ssh access)
<jelmer> vila: IIRC synology is basically linux on ARM with a fancy GUI on top of it in a dedicated device
<vila> jelmer: yeah, but which distro, what's an ipkg ? (And HI ! ;)
<jelmer> vila: hey :)
<jelmer> vila: it's something custom, not sure what it's based on. I think it has ports
<vila> right, so we need andrewukN to come back or read the log ;)
<jelmer> vila: oh, and congrats on getting 2.6 out the door :-)
<vila> jelmer: thanks ;) Will finalize this week-end
<davekong> Can anyone point to a guide for adding a new command to bzr? I want to hook in some static analysis code that leverages bzr's knowledge of what files have been updates or created that will be part of the next commit.
<davekong> http://doc.bazaar.canonical.com/plugins/en/plugin-development.html#defining-a-new-command
<andrewuk> Hello again
<andrewuk> i am just trying to check where bzr has been installed to and if that path is in my $PATH
<andrewuk> As for details of the Synology nas drive it runs a distro called busybox and ipkg is a package manager that seems to be the most popular one to use amongst the Synology community.
<davekong> andrewuk: if you type 'which bzr' in a unix shell, you will get the path to bzr if it is in your path.
<davekong> andrewuk: you can search for the location of a bzr with 'find / -name bzr'
<andrewuk> hello davekong:
<davekong> andrewuk: hello :)
<andrewuk> 'which bzr' is not returning anything so i assume it is not in my path
<davekong> yeah
<andrewuk> i will try searching  for it now
<andrewuk> NAS drive is whirling away now :)
<yoh_> Hi bzr gurus.  is there anything like 'git reflog' to discover at which revision I was before recent "bzr pull" so I could revert back to that state?
<andrewuk> found where bzr has been installed to by ipkg it lives at /volume1/@optware/bin
<andrewuk> cd /volume1/@optware/bin/bzr-2.6 rather
<andrewuk> so when i am inside the folder cd /volume1/@optware/bin i can run bzr and brings up all the options for the basic commands etc
<smw_> hi all, I modified a bzr lib and committed the change to my local repo. What is the best way to share it with the original author?
<smw_> Is there an easy way to make a patch so I can email it to him?
<andrewuk> so do i need to add the path to bzr-2.6 to my $PATH?
<yoh_> and I guess the answer to my question is: https://launchpad.net/bzr-tiplog  which is probably of no use "post-portem" (i.e. I should have enabled it before I did the pull)
<andrewuk> Yay i have bzr working on my nas drive
<andrewuk> i just need to work out how access bzr over the network instead of just through ssh
<vila> yoh_: there is a bzr-reflog plugin for the pull use case (I resort it to it a few days ago).
<vila> snw_: bzr lp-propose
<vila> errr
<vila> yoh_:  bzr lp-propose is one
<vila> yoh_: ghaaa, yeah, bzr-tiplog and yes, no post-mortem. But you can inspect your !/.bzr.log for hints
<vila> andrewuk: so, if you have ssh, you're almost done, you probably need to specify:
<vila> [bzr+ssh://nas.local/]
<vila> bzr_remote_path = /bin/bzrssh
<vila> bzrssh being a wrapper if you need to setup additional PATH or PYTHONPATH or whatever
<vila> I only ever needed it when bzr was run from sources (i.e. a non-standard location but you seem to have it installed in a non-standard location ;)
<yoh_> vila: thanks... I see no .bzr.log though anywhere
<vila> just noticed my tyop: it was ~/.bzr.log 'bzr version' will tell you the exact path
<vila> yoh_: ^
<andrewuk> thanks vila:
<andrewuk> just having a play round trying to connect  through a simple http;//
<vila> andrewuk: http is far harder than ssh
<vila> andrewuk: for ssh you just need... ssh access
<andrewuk> haha yes maybe your right as i haven't got it working yet
<andrewuk> i will give ssh a go now
<vila> andrewuk: say you have ssh access to andrewuk@nas.local, all you have to test is bzr push bzr+ssh://andrewuk@nas.local/~/testbzr
<yoh_> vila: thanks -- got it now... but unfortunately nothing which would help me is there ;)
<vila> yoh_: damn, sorry completely forgot that hole once I started using the plugin :-/
<yoh_> no problem! thanks
<vila> yoh_: depending on how many time it's worth spending on it, I see hints in .bzr.log in the pull commands: 0.096  fetching: <SearchResult search:(set(['vila@XXX-20130731091908-1ruz29rkl90gmz4v']), ['vila@XXX-20130
<vila> those revision were pulled, you should be able to locate them with 'bzr qlog'
<andrewuk> i am getting the error 'ash: bzr: not found' i think because on my nas i have to use bzr-2.6 instead of just bzr
<yoh_> 'grep fetch' on mine is empty ;)
<vila> yoh_: aaaargh, could be a from a debug flag I set locally, damn, you're a hard sale ;-D
<vila> andrewuk: good, so you need bzr_remote_path set as mentioned above
<yoh_> vila: LOL ;)
<vila> yoh_: install bzr-tiplog for the *next* time you'll corner yourself ;)
<yoh_> vila: it is in place already ;)
<vila> \o/
<yoh_> but also tried git clone "bzr::lp:python-mode" python-mode.gitbzr -- unfortunately failed ;)
<andrewuk> think i am setting this correctly i have tried BZR_REMOTE_PATH=volume1/@optware/bin/bzr-2.6
<andrewuk> as volume1/@optware/bin/bzr-2.6 is the path to where bzr-2.6 resides
<vila> andrewuk: with a leading / right ? That is 'BZR_REMOTE_PATH=/volume1/@optware/bin/bzr-2.6 bzr push bzr+shh://a@nas:~/test' ?
<vila> andrewuk: damn forgot another one ;) 'BZR_REMOTE_PATH=/volume1/@optware/bin/bzr-2.6 bzr push bzr+shh://a@nas/~/test
<vila> aargh and that's ssh not shh, damn it my very first bzr tyop is coming back ;-D
<vila> time to sleep ;)
<vila> have fun all !
<andrewuk> thanks vila
<andrewuk> yay success :)
<andrewuk> just need to learn how to use all the bzr commands now
#bzr 2013-08-02
<davekong> Is there a command to determine whether a branch has a working tree or not?
<davekong> Just look for a .bzr/checkout dir?
<Wiz_KeeD> hello everyone!
<jelmer> davekong: yes, or "bzr info" and grep for the relevant data
<davekong> jelmer: thanks
#bzr 2013-08-03
<wolter> Hi, I'm having problems merging two different branches; From the branch I'm working on I run bzr merge lp:otherbranch, but I get as output "Nothing to do."
#bzr 2013-08-04
<Wiz_KeeD> hey guys
<Wiz_KeeD> if i have a conflict in a file of my bzr repo
<Wiz_KeeD> How can i ignore it and just use the latest revision/commit?
<Wiz_KeeD> I did bzr revert file
<jelmer_> Wiz_KeeD: bzr revert should be sufficient. is it not?
<Wiz_KeeD> yes it is aparently :D
#bzr 2014-07-29
<Laney> hey, can I push a revision which is tagged without pushing the tag too?
<fullermd> Conceptually, sure.  UI-wise, I don't think so.
<fullermd> You could do stupid-dances with things like deleting the tag, pushing, and reapplying it.
<Laney> Yeah, thought so ...
<jelmer> Laney: the API will allow you to do that, but the UI won't
<Laney> jelmer: ah well
<Laney> hi, btw!
<mark06> http://i.imgur.com/PtfK5y5.png :-/
#bzr 2014-07-30
<mark06> http://i.imgur.com/PtfK5y5.png
<jelmer> mark06: is the ghost revision perhaps in the branch it was stacked on, rather than the branch itself?
<jelmer> launchpad only stores revisions in each branch that were not in the branch it is stacked on (in other words, trunk)
<mark06> yeah both revisions 16 and 63 are from the cloned branch pidgin++
<mark06> maybe it's something related with tip handling? since rev 63 is just the latest
<mark06> just tested it again and bzr tags -d :parent complains about the latest rev again, which is now 69
<jelmer> mark06: it looks like it's a bug in the implementation of the smart server
<mark06> could not get revno 16 because its ancestry shows a ghost at 69... but isn't it the opposite, 16 is ancestor of 69?
<jelmer> mark06: what version of bzr are you running?
<mark06> 2.5.1 on windows
<jelmer> mark06: can you reproduce it if you use "bzr tags -d http://bazaar.launchpad.net/~ren.../" instead?
<jelmer> mark06: I can't reproduce the issue here FWIW, but I'm not logged into launchpad
<mark06> http works :) http://i.imgur.com/Wk019f3.png
<mark06> much better than http://bazaar.launchpad.net/~renatosilva/+junk/scripts/revision/224 :)
<jelmer> mark06: so, seems like a smart server bug. please file one
<mark06> bug 1350438
<ubot5> bug 1350438 in Bazaar "Cannot fetch remote tags through SSH for some branches" [Undecided,New] https://launchpad.net/bugs/1350438
<jelmer> mark06: thanks
<mark06> thanks jelmer
#bzr 2014-07-31
<mark06> is there any command to revert back to previous commit, but instead of removing the current commit, add another for reverting it?
<Peng> like hg backout? Um. Not sure.
<mark06> e.g. 1=x, 2=y, 3=undo y --> so bzr diff -r 1..3 is empty
<mark06> I want to undo a commit but keep it saved somehow... I'm not like branching and marking as abandoned in launchpad...
<mark06> hmm maybe that's better
<Peng> right, like hg backout. I'm scratching my head but I don't remember if bzr has a specific command for it. You can use a 'bzr merge' incantation to make the changes to your working copy, and then commit it.
<Peng> There's probably information available online.
<jelmer> Peng, mark06: yeah, you can do a "reverse merge" and then commit that
<jelmer> bzr merge -r4..3 && bzr commit -m "Revert commit 4."
<mark06> cool
<mark06> thanks all
<mark06>  is there an easy way to convert a bzr+ssh url to http?
<mark06> just replacing the protocol isn't always enough
<mark06> or maybe a way to make bzr use the http url for the given ssh one?
<fullermd> In general?  No chance, you have no idea how the server is setup.
<mark06> so bzr+ssh urls can be really arbitrary?
<fullermd> Well, they're (theoretically/virtually, anyway) filesystem paths on the server.  HTTP requests often, but nowhere near always are, and the HTTP root is almost certainly totally different from the root you get via ssh.
<mark06> launchpad support would be enough... anyway I'm just writing a manual conversion now
<fullermd> LP would be an easy case.
<mark06> from the samples I have here, it's basically s/bzr+ssh/http, and s/ 'launchpad.net/+branch/project' / 'launchpad.net/~<owner>/project/trunk', is that it?
<fullermd> Something like that.
<fullermd> All the paths are virtual, and defined by LP's particular rules, so they all follow the same pattern on both methods, whatever it is.
<mark06> hmm, it's problematic since how can we know branch owner?
<mark06> no they don't follow the same method.... just replacing protocol fails for '+branch' urls.... but it's just ok if ~user/project/branch format is used instead
<mark06> I mean '+branch' fails under http
<fullermd> Mm.  I've never tried going that way around.
<fullermd> s/http/bzr+ssh/ works fine though.
<mark06> hmm http://launchpad.net/project works, good... except for an inconvenient message at the bottom, e.g. http://launchpad.net/moin-solenoid/ is permanently redirected to https+urllib://launchpad.net/moin-solenoid/
<mark06> hmm not ideal but 2> /dev/null
<mark06> hmm https:// doesn't show that...
<mark06> any reason to always use https over http?
<mark06> is lp:foo called an url?
<fullermd> More directory lookup, maybe.
<mark06> hmm "location"
<Peng> it's a syntactically valid URI, whatever we call it
<mark06> http://bazaar.launchpad.net/~renatosilva/+junk/scripts/revision/224 :)
<mark06> http://i.imgur.com/hwnjZlt.png
<qquark> hi guys! Can someone help me with a problem I have after migrating from GIT repository to Bazaar? My problem is that bzr repo is 3x times larger than GIT - or 2.24 x time if I use "bzr pack --clean-obsolete-packs"
<qquark> My questions are: Why is it so big? How can I see which objects create this large size?
<mark06> does the size change if you branch from it?
<qquark> yes
<mark06> what rate
<qquark> its still very big: 5.2 GB instead of 1.4 GB
<qquark> the repo size in git is about 4.1 GB
<qquark> and in bzr is 12 GB. And after I do: bzr pack  --clean-obsolete-packs, it becomes 9.4
<qquark> So, the trunk in git: 1.4 GB and bzr branch of trunk: 5.2 GB
<fullermd> My impression has been that a factor of two difference is a ways out on the bell curve, but not totally shocking.  A factor of almost 4, though, that's a lot of sigma...
<`nik`> how do i configure bzr to show me colored diffs?
<`nik`> there seems to be a bug in the docs. this section (http://doc.bazaar.canonical.com/bzr.2.6/en/user-guide/configuring_bazaar.html#looking-at-the-active-configuration) links me to this page (http://doc.bazaar.canonical.com/bzr.2.6/en/user-reference/index.html#configuration-settings) but the configuration-settings anchor doesn't exist. it should link to here: http://doc.bazaar.canonical.com/bzr.2.6/en/user-reference/configuration-help.html
#bzr 2014-08-01
<jelmer> `nik`: try "bzr cdiff" or "bzr diff --color"
<`nik`> jelmer: both are unrecognized commands. maybe its a bzr extension i dont have
<jelmer> `nik`: you need bzrtools
<`nik`> thx
<qquark> how can I see how objects are stored/compressed ? Someone saied about using history in GIT
<jelmer> qquark: "bzr info" will give you some basic detailsa bout the format
<qquark> sure, but I'm interested to know how much are binary files compress. And if I can do something about this in order to reduce disk usage of the repository
<jelmer> qquark: they're compressed; the main question is probably whether they're delta'ed against the right file base
<jelmer> the developer docs have some details on the internals
<qquark> jjelmer: thanks! I'm a programmer but not proficient with administrating versioning systems. Can you direct me where to look for (docs for which functions)?
<jelmer> qquark: not sure from the top of my head. look for brisbane-core and groupcompress under doc/dveloeprs/
<qquark> I'll look into this
<qquark> If I fix this, I will have a better chance to convince my boss to move to bzr from git
<achiang> hello, what does the ? in this output mean? http://pastebin.ubuntu.com/7925363/
<fullermd> Generally, that the rev isn't in the branch.
<achiang> that's what i guessed. thank you!
#bzr 2014-08-03
<superfly> hi folks. Mac OS X 10.9.4 (Darwin-13.3.0-x86_64-i386-64bit), bzr 2.6.0 (Python 2.7) installed via MacPorts. I have two files with umlauts in them which bzr seems to struggle with. I know that my code is up to date with the remote repository (I actually just removed it and re-branched it), but it keeps on getting two files confused. Anyone have any ideas? http://pastebin.com/wrLXiEt9
#bzr 2015-07-27
<AbuDhar> hey!!!!
<AbuDhar> _:D
<AbuDhar> why should I use bazaar over git? :D:D:D I am reading this...:
<AbuDhar> http://wiki.bazaar.canonical.com/BzrVsGit
#bzr 2018-08-01
<aaron7> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<aaron7> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<aaron7> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<aaron7> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<macky16> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<macky16> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<macky16> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<macky16> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Loki16> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Loki16> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Loki16> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Loki16> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<hammer0652> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<hammer0652> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<hammer0652> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<hammer0652> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Kazuto> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Kazuto> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Kazuto> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Kazuto> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<SunTsu9> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<SunTsu9> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<SunTsu9> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<SunTsu9> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<pilottage> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<pilottage> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<pilottage> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<pilottage> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<okdas> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<okdas> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<okdas> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<okdas> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<chek1> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<chek1> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<chek1> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<chek1> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Andre483> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Andre483> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Andre483> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Andre483> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Faylite14> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Pyrotechno> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Pyrotechno> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Pyrotechno> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Pyrotechno> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<elkalamar> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<elkalamar> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<elkalamar> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<elkalamar> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<thejoecarroll4> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<thejoecarroll4> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<thejoecarroll4> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<thejoecarroll4> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Freejack14> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Freejack14> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Freejack14> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Freejack14> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<RyZum> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<RyZum> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<RyZum> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<xous6> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<xous6> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<xous6> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<xous6> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<pokk26> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<pokk26> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<pokk26> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<pokk26> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<andries4> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<andries4> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<andries4> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<andries4> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<dan-28> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<dan-28> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<dan-28> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<dan-28> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<johnny5621> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<johnny5621> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<johnny5621> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<johnny5621> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<jeggott12> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<jeggott12> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<jeggott12> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<jeggott12> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<DarthGandalf9> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<DarthGandalf9> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<DarthGandalf9> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<DarthGandalf9> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<SiLuman1> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<SiLuman1> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<SiLuman1> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<SiLuman1> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<TBloemink5> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<TBloemink5> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<TBloemink5> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<TBloemink5> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<ManyRaptors22> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<ManyRaptors22> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<ManyRaptors22> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<ManyRaptors22> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<dlcastc> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<dlcastc> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<dlcastc> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<dlcastc> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Ohelig5> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Ohelig5> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Ohelig5> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Ohelig5> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<apollojustice28> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<apollojustice28> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<apollojustice28> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<apollojustice28> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<RoyK12> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<RoyK12> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<RoyK12> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<RoyK12> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Waggie7> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Waggie7> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Waggie7> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Waggie7> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<bolt27> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<bolt27> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<bolt27> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<bolt27> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<siinus`6> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<siinus`6> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<siinus`6> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<siinus`6> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<pavlushka10> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<pavlushka10> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<pavlushka10> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<pavlushka10> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Torgeir> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Torgeir> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Torgeir> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Torgeir> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Asoka0> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Asoka0> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Asoka0> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Asoka0> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<rigel22> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<rigel22> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<rigel22> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<rigel22> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<nurupo6> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<nurupo6> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<nurupo6> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<nurupo6> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<dan3wik> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<dan3wik> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<dan3wik> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<dan3wik> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<sm0rux_> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<sm0rux_> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<sm0rux_> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<sm0rux_> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Alex`27> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Alex`27> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<grit2> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<grit2> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<grit2> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<grit2> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<steven6> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<steven6> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<steven6> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<steven6> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<siso_> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Auctus23> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<grumble225> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<grumble225> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<grumble225> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<grumble225> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Xlbrag_> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Xlbrag_> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Xlbrag_> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Galixte> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Galixte> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Galixte> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Galixte> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<supercool3> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<supercool3> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<supercool3> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<supercool3> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<Bahhumbug4> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Bahhumbug4> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Bahhumbug4> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Bahhumbug4> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<fullermd> Whack-a-mole is probably doomed   :|
<jelmer> fullermd: yeah, I'm not sure if I want to go there
<jelmer> lots of other channels seem to go to quiet mode
<Pyrotechno> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<Pyrotechno> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<Pyrotechno> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<Pyrotechno> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<wsm> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<wsm> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<wsm> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<wsm> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
<knolle13> With our IRC ad service you can reach a global audience of entrepreneurs and fentanyl addicts with extraordinary engagement rates! https://williampitcock.com/
<knolle13> I thought you guys might be interested in this blog by freenode staff member Bryan 'kloeri' Ostergaard https://bryanostergaard.com/
<knolle13> Read what IRC investigative journalists have uncovered on the freenode pedophilia scandal https://encyclopediadramatica.rs/Freenodegate
<knolle13> A fascinating blog by freenode staff member Matthew 'mst' Trout https://MattSTrout.com/
#bzr 2019-07-31
<eweg> Hi, I'm debugging a bzr plugin. From what I understand I'm supposed to run the plugin unit tests like this: "bzr selftest -v bzrlib.plugins.fastimport.tests"  My question is, how can I see debug output?
<eweg> The plugin code is calling trace.note(...) etc but I don't see this output in the terminal or ~/.bzr.log
<jelmer> eweg: trace.note output should show up on the terminal
<jelmer> As well as trace.mutter, etc
<eweg> ah ok, you only get the output when the test fails
