#bzr 2007-09-17
<DShepherd> bzr is pretty neat..
<DShepherd> bzr uncommit feature is what I have been wanting for svn for the paste couple days..
<DShepherd> is it possible to check out an svn branch with bzr?
<luks> yes, with http://bazaar-vcs.org/BzrForeignBranches/Subversion
<DShepherd> aahh sweet
<DShepherd> How can i undo what bzr init does?
<radix> I guess rm .bzr -r
<DShepherd> radix, hmm.. ok
<radix> beware of doing that, though :)
<DShepherd> no fancy command :-)
<DShepherd> radix, why?
<radix> well, .bzr is where everything is kept that bzr knows about it
<radix> if you delete it, you're deleting all history, etc.
<DShepherd> radix, ok thanks for the heads up.
<DShepherd> bzr init-repo #what does that really do? and when is it a good time to do it.
<radix> DShepherd: It creates a shared repository, which there is a document about
* DShepherd is a bit confused.. svn guy
<radix> DShepherd: basically it makes it so that if you have a bunch of branches with common revision data, it can be shared in one place
<DShepherd> hmmm..
<radix> DShepherd: this helps with disk space usage, but more importantly (IMO) network I/O
<DShepherd> radix, ok
<radix> DShepherd: because if you "bzr branch" a remote branch *into* your shared repository, if that branch largely has revisions that you already have, it won't have to download them again
<radix> DShepherd: but yeah, for extension info please read the document on bazaar-vcs.org (I'm sure a search will find it, I don't remember the name)
<DShepherd> kool
<radix> s/extension/extensive/
<DShepherd> ok kool.. i am going thru the document now.. but its so much nicer to talk to people :-).. thanks for the heads up though
<DShepherd> does svn even have selective commit?? cause that's kool
<radix> committing individual files instead of the whole tree?
<radix> both bzr and svn have that, with "<bzr/svn> commit <file>"
<DShepherd> radix, oh.. never used it before
* DShepherd apparently is a under-user of svn
<fullermd> I'm not sure I know of ANY VCS that doesn't do that (I'm sure there are some, but I don't think any of the majors)
<igc> morning
<lifeless> hi igc
<igc> morning lifeless - have a good weekend?
<lifeless> yuo
<LaserJock> hi lifeless
<lifeless> bucks night; I'm still tired :)
<lifeless> hi LaserJock
<igc> :-)
<Verterok> Hi y'all
<lifeless> hi
<Verterok> lifeless: Hola!
<Verterok> I'm going to start working to add multiple (eclipse) project per branch, to bzr-eclipse (the current implementation only support the branch at the root of the project)
<Verterok> my idea was to support one level up in the hierarchy, I'ld like to hear your thoughts about it
<Verterok> with one level, bzr-eclipse would support a branch with multiple eclipse projects as it's childs directories
<lifeless> I'm just going to run an errand, I'll be back shortly
<lifeless> back
<poolie> hello
<LaserJock> hola poolie
<poolie> hi
<poolie> igc, would you like a call today sometime?
<igc> poolie: yes that would be good. How's 2.30 say?
<igc> or whatever time suits you
<poolie> sounds good
<lifeless> igc: were you going to review the bytes_to_gzip patch ?
<igc> I can yes
<igc> still wrapping up the review of abentley's reconfigure one - when it's done, your patches are next
<luisfelipe> Hey guys, I need help. I'm using bazaar here on a project, I'm trying to pull some changes another guy did on his repo, but both pull and merge says that there's nothing to pull
<poolie_> ok
<lifeless> luisfelipe: bzr missing can tell you the difference between branches in terms of commits
<poolie> luisfelipe, if you run 'bzr log' on his repo, what do you see?
<lifeless> luisfelipe: I suspect he has not pushed, or you are not pulling/merging from the correct URL for his branch
<luisfelipe> the url is correct
<luisfelipe> I tried to pull, and it said that the branches had diverged
<luisfelipe> then I merged, and some of his changes came, but not all
<luisfelipe> oh, I think I've got it
<luisfelipe> sorry
<luisfelipe> lifeless, he had not pushed, only commited his changes
* igc food
<lifeless> poolie: lol, win65
<abentley> lifeless: No one would buy the first release of win64.  Personally, I'm holding out for win67.
<lifeless> :)
<Peng> Hmm. I'm getting a traceback when pulling from a knit branch into a pack branch.
<lifeless> oh ?
<lifeless> from bzr.dev ?
<Peng> Yeah.
<poolie> abentley, heh
<Peng> Pulling a local copy of bzr.dev. I'm using your repository branch.
<lifeless> Peng: thats the known data issue
<lifeless> Peng: use abentley's delta fixing 'bzr check' patch on your copy of bzr.dev first.
<Peng> abentley's delta fixing?
<Peng> As in not bzr 0.90?
<lifeless> Peng: yes
<lifeless> Peng: this was all covered in the list
<lifeless> Peng: And I know I chatted with you about it before. bzr.dev has delta's that are not referenced from the inventory
<lifeless> this has to be fixed to use packs on them.
<Peng> Okay.
<Peng> (I *have* been reading the list, through Gmane's web interface. Guess I haven't gone far enough back?)
<Peng> So...what do I need to do?
<lifeless> easiest is to take a branch of my copy of bzr.dev using packs
<lifeless> (you are failing on a new pull right ?, or incremental ?)
<lifeless> bbiab, lunch
<Peng> Incremental?
<Peng> Easier than using your copy of bzr.dev is simply not keeping a pack copy of bzr.dev. I was just doing it for fun.
<Peng> I already have a knit copy.
<lifeless> ok
<lifeless> you shouldn't have trouble with any other project in pack form
<poolie> !!
<poolie> i didn't know '123' in '1234' was true
<poolie> but it is
<poolie> but only for strings, not other sequences
<lifeless> poolie: yay special casing
<poolie> lifeless, can you have a look for me at test_selftest_benchmark_parameter_invokes_test_suite__benchmark__
<poolie> it does not seem to test anything like what the name says
<poolie> i think it's a reasonable test but misnamed
<lifeless> igc: ping
<igc> h lifeless
<lifeless> poolie: are there dots in that name ?
<poolie> not in the method name
<keir> hello
<poolie> it is in test_selftest.TestSelftest
<lifeless> igc: does TestWorkingFormat4.test_id2path sound familiar ?
<igc> yes
<igc> is that a leading Q?
<lifeless> poolie: annotate it; I'll bet its misnamed due to refactoring
<poolie> apparently not
<lifeless> heh
<lifeless> anyway I agree
<lifeless> igc: it is. I think that rename_one is buggy
<lifeless> igc: because it allows a rename to a non-normalized, non-accesible path
<igc> yes - the fix for that is in my patch. Digs ...
<lifeless> igc: you have a test for rename_one ?
<lifeless> whats the topic of the mail to search for
<Vantage13> hi, i'm trying to use bzr-cvsps-import to import a cvs repository, but I always get "bzr: ERROR: Must end write groups before releasing write locks.".  Any idea what might cause that or how to get more information?
<lifeless> Vantage13: api skew has affected the plugin
<igc> lifeless: see the end of http://bundlebuggy.aaronbentley.com/request/%3C46DC2EB1.3010901@internode.on.net%3E
<lifeless> Vantage13: if you use 0.18 it will work; I will try to fix that shortly if I can get a minute spare
<igc> that's the iter_changes commit one
<igc> lifeless: the fix was recommended by jam
<lifeless> igc: yah, thats the test change needed but its buggy
<igc> in which way?
<lifeless> rename_one() is broken
<igc> lifeless: You're very likely to be right. There are several emails ...
<igc> between jam and myself (all on list) re this.
<lifeless> yah, I was asking about the topic :)
<lifeless> so I could find em
<igc> There was talk about taking out some of the checking also. I'll dig so a moment ...
<lifeless> --- bzrlib/tests/test_workingtree_4.py  2007-04-26 22:56:01 +0000
<lifeless> +++ bzrlib/tests/test_workingtree_4.py  2007-09-17 04:28:02 +0000
<lifeless> @@ -420,6 +420,8 @@
<lifeless> 
<lifeless>          try:
<lifeless>              tree.rename_one('a', u'b\xb5rry')
<lifeless> +            tree.unversion(['a-id'] )
<lifeless> +            tree.add([u'b\xb5rry'] , ['a-id'] )
<lifeless>              new_path = u'b\xb5rry'
<lifeless> that patch demonstrates the problem
<Vantage13> lifeless: thanks.  what's the command to grab 0.18?
<lifeless> clearly it should be a no-op. But it errors. So rename_one is facilitating a buggy api
<igc> That will fail I think
<igc> The problem is that add does extra checking that rename doesn't
<lifeless> igc: indeed, thats precisely the point, rename_one is allowing broken data into the dirstate.
<igc> yup
<igc> but whether add was being over strict was related
<lifeless> Vantage13: have a look at http://bazaar-vcs.org/src/releases IIRC
<igc> poolie: I'll call in 5
<lifeless> Vantage13: our downloads page links to the tarballs, but the folder is listable; you can just 'tar xzf bzr-0.18.tar.gz && bzr-0.18/bzr' - you can run it without installing it
<lifeless> igc: so the topic was?
<igc> lifeless: https://lists.ubuntu.com/archives/bazaar/2007q3/030187.html
<lifeless> gah
<igc> Filename normalisation handling is the topic
<lifeless> just the topic please
<lifeless> I have no browser on this terminal ;)
<igc> :-(
<Vantage13> lifeless: is this 0.18 of the bzr-cvsps-import plugin or 0.18 of bazaar?  I thought bazaar was 0.90?
<igc> lifeless: Aug 21 from me
<lifeless> Vantage13: you need 0.18 of bzr, because 0.90 breaks the plugin
<Vantage13> lifeless: That's an odd versioning scheme, isn't it?
<lifeless> Vantage13: we jumped from 0.18 to 0.90 as we approach 1.0
<lifeless> igc: I see no discussion of add or rename_one in that thread
<Vantage13> lifeless: so is this something that will be fixed in bzr or in the plugin?
<lifeless> Vantage13: Like I said, I will try to get around to fixing the plugin shortly; for now it will work fine if you just use an older bzr
<Vantage13> lifeless: ok.  I'm just curious which I'll need to upgrade in the future for the long term fix
<lifeless> the plugin ;)
<Vantage13> lifeless: I usually use bzr from my distro and pull the plugin separately
<Vantage13> lifeless: thanks!
<lifeless> poolie: seems to be no bzr-cvs-ps luanhcpad page; or am I searching with bad terms ?
<igc> lifeless: I'll look again. John and I have never discussed rename_one, only add. I'll just call poolie first then look as soon as I'm off the phone
<lifeless> hmm, Ill just fix it and mail the list
<lifeless> oh, bzr-cvsps-import got it
<lifeless> Vantage13: I'm reporting a bug on the plugin for you
<Vantage13> lifeless: excellent.  I'm just getting started with bzr and this was my first snag :)
<lifeless> bug 140048
<ubotu> Launchpad bug 140048 in bzr-cvsps-import "needs update to use write groups (incompatible with bzr >= 0.90)" [Undecided,New]  https://launchpad.net/bugs/140048
<ubotu> New bug: #140048 in bzr-cvsps-import "needs update to use write groups (incompatible with bzr >= 0.90)" [Undecided,New]  https://launchpad.net/bugs/140048
<lifeless> igc: ok fixed and mailed.
<lifeless> igc: the key thing I've done different to you is to figure out the root cause :)
<lifeless> meh, that sounds wrong.
<igc> harsh but true :-)
<lifeless> I mean I made the test that was putting bogus data in fail
<igc> my issue was I wasn't sure what the correct behaviour really ought to be
<lifeless> the names in inventory and dirstate bjects should always be NFC/NKFC normalised
<igc> good ...
<lifeless> thats what the normalized_filename methods docstring says
<lifeless> and add enforces
<lifeless> the problem was that rename_one was not doing the same check as add
<igc> so as I had suspected, my code (which was failing) was actually correct and the test was actually wrong. I'll look forward to reviewing your change then! :-)
<lifeless> review away
<lifeless> but bytes_to_gzip first please, thats blocking other changes for me
<lifeless> I'm thinking I can save a lot of hash update function calls
<lifeless> by doing sha1 sum of the byte block rather than sha_strings
<igc> interesting
<lifeless> 5% difference
<lifeless> (as a micro-benchmark)
<lifeless> looks like it could be a 1.2% overall win
<kgoetz> hi all. just wondering if bzr ignores or reads robots.txt files? i have a deny: * line in my websites root directory, but i still want people to be able to checkout my bzr over http
<lifeless> kgoetz: thats fine
<lifeless> bzr isn't a robot
<kgoetz> lifeless: sweet. thanks.
<lifeless> poolie: want a chat ?
<vila> lifeless: open_write_stream is dead code can I remove it ?
<lifeless> vila: dead? how so
<vila> lifeless: kidding, just wanted you to quickly page-in  related info :) Its introduction broke webdav support
<vila> looking at it I wonder why you didn't define it Transport
<vila> s/it/it in/
<vila> since it relies on other primitives
<lifeless> huh?
<lifeless> colour me confused
<lifeless> it is a_transport.open_write_stream
<vila> I saw the specific sftp implementation, but I don't understand why you didn't provide a *default* implementation in Transport
<vila> since sftp and memory use the same exact code
<vila> and remote too
<vila> grr s/sftp and memory/ftp and memory/
<lifeless> so the FTP implementations ucks
<lifeless> *sucks*
<lifeless> anything doing self.append_bytes() as a thunk will perform heinously
<vila> fine for a default implementation by my book
<lifeless> default implementations should make sense
<lifeless> if the default is bad, its not a good default
<lifeless> the only transport that self.append() makes sense for is Memory
<vila> ok, that's the reason then. Fine, but webdav will use the same :-/
<lifeless> webdav should definately do a chunked encoded streaming upload
<lifeless> or if the server is 1.1
<lifeless> sorry
<vila> lifeless: chunked encoding is on my TODO list, albeit very deep :-)
<lifeless> if the next hop is a 1.0 in its signature then it should buffer locally
<lifeless> we do *thousands* of little writes
<lifeless> and the api is designed to allow that.
<vila> hmmm, and sftp provides buffering via paramiko ?
<lifeless> sftp streams
<lifeless> non blocking writes
<lifeless> I looked at doing a proper stream for the FTP one but it was going to be tricksy
<lifeless> IIRC
<lifeless> RemoteTransport will want to buffer too
<lifeless> but it doesn't yet
<lifeless> though RemoteTransport will hopefully not use the api ever as the smart server should kick in
<vila> lifeless: ok thanks for "default implementations should not suck" rationale, that was what I was looking after
<vila> I mostly understood the rest and will fix webdav with a default sucking implementation and a FIXME for buffering
<vila> lifeless: last bit, did you think about some criteria to trigger the buffer flush ? Is there some coherence to ensure about concurrent read or writes by other users ?
<lifeless> vila: its documented in the docstring
<lifeless> vila: have a look at the LocalTransport implementation for example
<vila> lifeless: meh, can't find anything on that subject, more precise pointer ?
<vila> LocallTransport.open_write_stream says: See Transport.open_write_stream... which defines the polilcy but local doesn't seem to implement it, still in your private branch only maybe ?
<lifeless> pydoc bzrlib.transport.Transport.open_write_stream
<igc> lifeless: do you notice a speed difference if the compression level is set to 1 instead of -1?
<lifeless> vila: look at the get method on local.py
<lifeless> igc: dunno
<lifeless> igc: the default (-1) is what hg uses FWIW
<vila> lifeless: ok
<igc> ok
<ubotu> New bug: #140055 in bzr "socket leak in test suite" [Medium,Triaged]  https://launchpad.net/bugs/140055
<lifeless> ok, I'm out
<lifeless> night
<igc> lifeless: night - review just emailed btw
<lifeless> thanks
<igc> vila: got a moment?
<vila> igc: yup
<igc> Q re bzrdir.open_from_transport ...
<igc> can I comment out the qualified_target = ... line?
<igc> or ...
<igc> should it be return get_transport(qualified_target)?
<vila> the FIXME implies we should return get_transport(qualified_target) *but* it's hard to verify
<vila> redirect can be on other schemes (ftp, sftp, etc)
<igc> ok, so ...
<vila> the problem is really when we are working with the non-default http implementation and the redirect will use the default http implementation
<vila> i.e.: http+pycurl is the default, http+urllib: redirects to http
<igc> code quality wise, what do you suggest given qualified_target is calculated but never used?
<vila> we begin with a urllib transport and ends with a pycurl transport
<vila> the code can be safely commented out, one can even write a test that exhibit the problematic behavior and make it an expected failure
<igc> I'll comment it out then as part of some cleanups to that module I'll submit
<vila> now that ConnectedTransport have been refactored, this bug may be more easy to address, but it may also vanish if we drop pycurl support
<igc> I like your idea of an expected failure test btw
<vila> I think that's the whole story, so in short, comment it out :)
<vila> igc: :)
<igc> thanks
<vila> in spirit the FIXME comment is a lazy way to do that :)
<vila> igc: just of out curiosity, how did you arrive there ?
<vila> FIXME grepping ?
<igc> vila: I was reading the bzrdir code as part of me reviewing abentley's reconfigure patch
<igc> I figured I needed to grok it in order to review the pack stuff soon as well
<vila> igc: hmm, bzrdir is hard to grok...
<vila> lots of static methods, I had to read a bunch of plugins for foreign vcs to understand why.
<igc> 44 A4 pages says to me that it ought to be a few modules in a package, not one big one :-)
<igc> moving old formats into a plugin as lifeless has suggested will improve things though
<igc> anyhow, time for some food
* igc dinner
<vila> igc: enjoy your meal
<igc> thanks
<lifeless> lets drop pycurl :)
<rokahn> I'm looking for version control system which I can adapt to store and retrieve XML diffs (as opposed to line-based diffs).  Would someone on this channel know if Bazaar is a good choice (or what might be a better choice)?  We already have software to generate the XML diffs and apply the XML patches so we're looking for a version control system which can be easily modified to use external programs for diff & patch.
<alfborge> I'm trying to update my local branch against the upstream branch through sftp using bzr pull and bzr merge, but it's taking ages and showing no progress.
<alfborge> Both are running bazaar 0.90
<alfborge> Any idea what I can do to speed it up/find out why it's slow (or not working)?
<alfborge>   The repos is 193M
<alfborge> (At least that's what it says when I do "du -hs ~/repos"
<matkor> jelmer: Sorry for bothering but could you please merge tiny fix for push with overwrite from https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? It is pretty straightforward ... TIA
<lifeless> alfborge: networking is still slow; 0.92 will largely fix this
<lifeless> alfborge: be patient and it will be fine
<alfborge> Is there a way to make bzr completely forget files?
<alfborge> I.e. remove all history about the files.
<quicksilver> alfborge: only madmen and dictators try to change history :)
<Peng> Or people who accidentally added an ISO.
<jelmer> Peng: You can remove information about history (creating ghosts)
<Peng> Oh, reallly? Cool.
<Peng> Anyway, alfborge was the one who asked.
<Peng> I'd like to do it too, but I converted to hg a month ago for speed.
<jelmer> it's not really exposed at the UI level yet
<Peng> so it doesn't matter anymore.
<Peng> jelmer: It probably shouldn't be.
* Peng wanders off.
<alfborge> jelmer: Any docs on this?
<jelmer> alfborge: there's a plugin that allows removing revisions but it's not very efficient
<jelmer> alfborge: see remove-revisions on the plugin page
<quicksilver> if I'd accidentally added an ISO, I'd just re-check out the verision before that mistake
<quicksilver> but that's obviously not the solution if you want to weed out a file that's been in there for 20 revisions
<Peng> Is it possible to check out up to r10, then bundle 12-15 and apply them? Or would it error out because 11 is missing?
* Peng wanders off.
<quicksilver> Peng: it would error out. but there may be a way to say "do this anyway"
<jelmer> Peng: No, that won't work. You could apply those as patches and commit them manually but that would create new revisions.
<jelmer> matkor: the abs in your latest commit is not correct
<jelmer> matkor: Negatives are used to indicate that the length of mainline has decreased
<matkor> jelmer: OK. I think we need descriptive name for that ...
<matkor> "%d revisions removed"  "%d revisions added" ?
<jelmer> matkor: Eventually, we should display all the information in PullResult()
<jelmer> matkor: bzr pull in bzr itself used to print negatives as well, so I'd rather keep that behaviour until we start using PullResult
<jelmer> poolie: Hi
<matkor> jelmer: OK. I will prepare correct revision and let You know :)
<jelmer> matkor: Cool, thanks! And thanks for the patch :-)
<jelmer> matkor: phanatic and I have been discussing ways to improve the development process of bzr-gtk
<jelmer> we'd like to start using BundleBuggy
<jelmer> so it'll hopefully become easier to get things merged and so we can have at least some review
<NamNguyen> bundlebuggy doesn't merge
<jelmer> NamNguyen: No, but it means merge requests don't get dropped but are remembered
<matkor> jelmer: Whateve suits you best it's ok for me. Just let me know what and when I should do to fit new workflow
<matkor> jelmer: I think cut down version of fix is on: https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor
<jelmer> matkor: it's ok to just create a new commit that reverts the abs() change, no need to keep one revision per feature
<jelmer> matkor: Thanks, pulled
<matkor> jelmer: OK. thank you too :)
<ubotu> New bug: #140419 in bzr "selective commit sometimes fails with `parent_id not in inventory` error" [Undecided,New]  https://launchpad.net/bugs/140419
<lifeless> Peng: any chance you'll come back? Have you tried the C patience matcher - its 10 times faster at diff, which is what was hurting you IIRC.
<lifeless> good night all, I'll look in scrollback :)
<Peng> lifeless: Don't worry, I still like Bazaar. But I'm planning to stick with Mercurial for this because converting the branch back would be a pain, Bazaar probably isn't going to beat it in performance any time soon, and I like being able to copy files.
<Peng> lifeless: But I am curious to see how much faster Bazaar is, and I'm planning to try it out eventually.
<jelmer> imho, working tree performance is now acceptable for large trees but network performance is still not quite there yet
<Peng> In my case, network performance doesn't matter much.
<ubotu> New bug: #140432 in bzr "bzr fails with 'iteration over non-sequence'" [Undecided,New]  https://launchpad.net/bugs/140432
<Gacha> hi
<Gacha> How can I tell bazaar to ignore a directory?
<Gacha> when I type bzr ignore "./my/dir/"
<Gacha> it says: bzr: ERROR: [Errno 1]  Operation not permitted
<jdong> sounds like you have permissions problems in your branch
<Gacha> but the  "./my/dir/" is correct?
<dato> Gacha: yes, it is
<Gacha> the ./ shows that its from the begining of the tree, right?
<dato> yep
<Gacha> I checked permissions, everything seems to be ok
<Gacha> I'm using sshmount, maybe that the problem
<dato> Gacha: that sounds very very likely
<Gacha> ok, I will search for workaround
<vila> lifeless: to drop pycurl we need certificate verification. python-2.6 will have it, I'm still lurking for a way to back port it.
* beuno wonders what Launchpad does differently that it doesn't return that sftp doesn't update the working tree
<dato> beuno: that there is not a working tree at all
<jelmer> beuno: If there's no working tree remotely, no message will be displayed
<dato> beuno: but that's not launhpad specific
<beuno> hm, ok, that won't work for me, would a "cron job updating working trees" be too much of a hack?   I'm having all kinds of permission problems using push-and-update plugin
<jelmer> beuno: that may result in locking errors while pushing every now and then, but other than that, it should work (won't corrupt any data)
<beuno> jelmer, what would be a better approach then?
<beuno> (if there is one)
<jelmer> beuno: the push-and-update plugin is the only thing I can think of
<jelmer> also, locking collisions won't happen very often - only if the cron job is updating the working tree /and/ somebody is pushing changes
<beuno> right, thanks jelmer, dato  :D
<keir> hmm, the git pack + idx format is quite nice
<radix> is there a bug with moving symlinks in bzr 0.90?
<radix> I'm getting a "No WorkingTree exists" error
<LarstiQ> radix: moving how exactly? There have been some symlink related bugs in the past (and I have no idea what happened since the start of August)
<LarstiQ> hi, btw
<radix> yo :)
<radix> hmm, having trouble reproducing
<radix> maybe it has something to do with the fact that the target of this symlink is outside of the branch
<radix> and in fact it starts with a ../
* radix tries to repro with that
<radix> yeeeah, that seems to be the problem
<radix> or at least, I get a similarish error in my repro environment
<radix> http://rafb.net/p/TTFEQe32.html
<radix> (../foo/bar doesn't exist at all)
<LarstiQ> mkay
<james_w> hi LarstiQ.
<LarstiQ> heya james_w
<james_w> LarstiQ: how are you?
<LarstiQ> james_w: ok I think, how about you?
<james_w> I'm fine thanks. How was your summer?
<dato> LarstiQ: hey, long time no see, I think
<james_w> hi dato
<dato> hi james_w. I tried a build of bzr-builddeb to upload it yesterday, but it died with some error I can't remember.
<LarstiQ> dato: aye, dropped of the internet at the beginning of August
<LarstiQ> james_w: quite good, except for a horrible August
<james_w> LarstiQ: oh dear. Is September any better for you so far?
<james_w> dato: ah, thanks for the warning. I'll try and build now.
<LarstiQ> james_w: much improved it is, yes
<james_w> radix: yeah, I think that is reported already. The bug log kind of shows why it has not been fixed yet.
<radix> can you tell me which bug it is? I tried seraching but didn't find anything.
<james_w> bug 32669
<ubotu> Launchpad bug 32669 in bzr "Adding a symlink to another branch fails" [Medium,Confirmed]  https://launchpad.net/bugs/32669
<james_w> has many bugs with symlinks in it
<james_w> I think the last is your case.
<james_w> bug 48444 is another
<ubotu> Launchpad bug 48444 in bzr "Symlinks to repository branches don't work" [Medium,Confirmed]  https://launchpad.net/bugs/48444
<james_w> and bug 124859 another. They all deal with when to dereference a symlink and when not to.
<ubotu> Launchpad bug 124859 in bzr "incorrect repository detected with symlink to a branch" [Critical,Triaged]  https://launchpad.net/bugs/124859
<james_w> LarstiQ: glad to hear it.
<dato> james_w: btw if you could change the b-dep on python-all-dev to just python-all, that'd be cool (I'd personally stick to python only, but if you want to run the testsuite under all supported versions, that's of course fine as well)
<james_w> dato: thanks, I'll do that. I'm not sure why I had that to begin with.
<beuno> ok, I question for the brave, I have a the following situation:   /dir1, /dir1/subdir1 and dir1/subdir2.   I would like to have a repository in all of them, the top directory, and the subdirs too
<beuno> what would be the best approach?
<sri> howdy
<beuno> because if I push to the subdirs, the main dir's repo will need commiting too
<james_w> beuno: do you mean repository or branch?
<beuno> james_w, both I think, all of em will have working trees
<james_w> so you are not talking about shared repositories?
<beuno> I'm not sure  :D
<james_w> I don't see why a push to the subdirs would require a parent commit, unless you are talking about versioning the files in the sudirs twice, once in the subdir and once in the parent.
<beuno> james_w, well, I was sort of hoping I could pull either all of it, or individually, as needed
<james_w> beuno: that sounds like a use case for nested trees.
<beuno> and if that's not possible, I guess I can just add those dirs to .bzrignore, and have them branched individually
<beuno> james_w, yes! nested trees sounds like what I want, is that already working?
<james_w> the internal support is there if you upgrade the branches. However the UI is hidden commands, not polished, and missing functionality for some commands I believe.
<beuno> ok, so it doesn't sound like something I want to implement company-wide
<james_w> no, I would say that it is not ready for that.
<beuno> james_w, great, I'll go for ignoring them then, thanks
<james_w> phanatic: hi. In gdiff I would expect "Complete diff" to show the whole diff in the other window, is there a reason why it doesn't?
<phanatic> james_w: must be a bug, i've noticed that as well. could you report it, so we can keep track of its status?
<james_w> sure, lauchpad I assume?
<james_w> annotate says that it has been that way since it was added.
<phanatic> james_w: thanks for the report
<phanatic> it used to show the complete diff
<james_w> phanatic: no problem. Thanks for the project.
<james_w> phanatic: ah, looking again, it might be API change in show_diff_trees, if specific_files=[]  used to mean all files and now means none then that would probably cause it.
<phanatic> james_w: thanks for tracking it down
<james_w> phanatic: yeah, it looks like None might be more appropriate.
<phanatic> james_w: this may some rude, but if you have the time, could you create a patch, please?
<phanatic> s/some/sound
<james_w> phanatic: no problem, I was just about to offer.
<james_w> where do you want it?
<james_w> and do you have a testsuite?
<lifeless> moin
<james_w> hi lifeless
<phanatic> james_w: we don't have a testsuite for gui bits :( attaching a bundle or branch to the bug report would be awesome
<phanatic> morning lifeless
<james_w> phanatic: done.
<phanatic> james_w: thanks, merged :)
<james_w> thanks phanatic
<lifeless> hi phanatic
<lifeless> LarstiQ: how is subtrees coming ?
<james_w> jelmer: the dev branch now has your requested $UPSTREAM_VERSION.
<jelmer> james_w: wow, that was quick (-: Thanks, I'll try it out tomorrow
<james_w> jelmer: it's actually got a couple of tests, so it might even work.
<james_w> jelmer: it's not flexible, it just solves your exact case, so let me know if you think it should be expanded.
<keir> lifeless, still around?
<keir> lifeless, i have most of the code written short of the actual graphindex wrapper; however, it's grown somewhat complicated
<keir> lifeless, i've been studying git's pack format and index. i feel like we should move in that direction.
<asabil> abentley: I don't get you first argument concerning bzr description ?
<asabil> bzr nick doesn't support referring to a remote branch
<asabil> so why does bzr description needs that ?
<schierbeck> phanatic: i've pushed a fix for the bug you mentioned :)
<phanatic> schierbeck: great, i'll check it out :)
<phanatic> schierbeck: works like a charm, i'll merge it
<schierbeck> cool
<schierbeck> phanatic: when's the release due?
<phanatic> schierbeck: this week (probably the weekend)
<lifeless> keir: so what does git do differently (other than having fixed length keys) in its index ?
<keir> they have a fixed length 256 entry index at the top
<keir> which works because of the fixed length keys
<keir> then it's a sorted list of the entries. since they are also fixed length it works for direct bisection
<keir> what i'm thinking, is why not just move to a sha1 based system?
<keir> pack the current keys into the pack and index them by sha, as with everything else
<keir> it would be transparent to the upper layers
<keir> we can still make the packs toposorted (for storing graphs)
<lifeless> so te 256 way fan at the top is equivalent to your key index index
<keir> yes
<keir> but since it's storing keys, there is no bisection; it's a straight jump to the right place
<keir> in my index, you have to bisect it because the var length keys
<lifeless> uhm
<keir> sorry, not keys, sha hashes
<lifeless> you still have to bisect
<lifeless> fixed length means you can bisect on record number rather than bytes
<keir> no, you just take the first byte and hop. the table stores the cumulative sum of the keys
<lifeless> thats all
<lifeless> say there are 256000 keys
<lifeless> sha's are homogenous
<keir> exactly.
<lifeless> how will it be direct rather than bisection - the 256 fan out still leaves you 1000 entries to select amongst
<keir> lifeless, yes, you have to bisect amongst those 1000
<abentley> asabil: All commands that can refer to branches should be able to refer to remote ones.  It's arguably a bug that "nick" cannot.
<keir> but the first jump is direct
<keir> instead of bisecting the table
<lifeless> keir: its a partial radix tree is all
<asabil> abentley: I see, then how to fix the bug in nick ?
<keir> they also have some other nice things, such as crc's in the packs
<lifeless> keir: for each entry? or for the whole pack? we can trivially add that, but we have higher level sha's anyway
<abentley> You don't have to fix nick, just "description".  If you want to fix nick, you would add a "-d" or "-f" option to it that can take branch.
<lifeless> and crc's in each hunk at the moment
<lifeless> so we'd be duplicating the crc processing if we did it the 'obvious' way
<keir> lifeless, i guess they found corruption due to HW was real enough to add a 2nd table of crc32's for each object in the pack
<keir> lifeless, i was picking the brains of #git
<lifeless> ok, so my thoughts are...
<lifeless> we have crcs for everything in the packs today.
<lifeless> its layered differently to git but its there
<lifeless> (we also have shas)
<lifeless> so its a really a no-op to move crcs from place A to place B at this point in time.
<keir> ok
<lifeless> as for the index, their index doesn't sound better to me
<keir> what i don't like about my index, is that it's complicated because of the variable length
<keir> now that i support short 'tags' for backpointers to the full length key (rather than the offset to the key), the code isn't so simple
<lifeless> we're studying changing some parts of the core to have fixed length keys, but that is very deep work
<keir> what i was thinking, is to move the fixed-length-ness to be an implementation detail which is not known about above
<lifeless> I certainly don't understand how you would do a radix tree to find blocks of 1000 entries (or whatever) and keep topological sorting
<keir> git toposorts the contents in the packs
<keir> but the index is sorted by sha
<radix> :(
<lifeless> yes, I know
<lifeless> we have looked at git quite closely you know :)
<keir> true
<lifeless> and for git this works because they operate on local disk
<lifeless> as soon as you say 'index operations are remote' the ballgame changes
<keir> yes, i noticed that their network perf can't be that amazing compared to what i have planned
<keir> my concern with my current code is that building is going to be slow for really large trees
<lifeless> ok
<lifeless> so there are a range of possibilities
<lifeless> possibly the tradeoffs you chose for your design aren't quite right, and the design is driving code complexity
<keir> i'm confident i can make a fast C version though.
<keir> yeah
<keir> do you think you could review the current code? even though it has lots of debug prints.
<lifeless> your suggesting moving to something like the git index is a reflection of that
<lifeless> sure
<keir> i generally feel that simple data structures are important
<keir> unless there's a compelling reason to be otherwise
<lifeless> so the git index is describable as 'bisection in 1/256 of the file'
<keir> yes
<lifeless> so a 256M index is 'bisection in 1M' to find a single key
<keir> they have a 2ndary index in version 2 which is bigger
<lifeless> and to grab (say) 50 keys over the wire to reconstruct a single text - download 50M
<lifeless> with a secondary index - presumably extending the radix tree - you can reduce this
<keir> with our data, it's really not clear how to efficiently do a radix tree
<lifeless> I think simple data structures are very appealing; but they have to do the job :)
<keir> absolutely
<keir> ok, i'll go add some comments and push my code
<lifeless> so LPC trees will eat up our data trivially
<lifeless> erm, LPC Tries
<keir> what is lpc?
<lifeless> level path compressed
<lifeless> no nodes where there is no split in keys, variable size nodes so every node is always very close to fully populted
<lifeless> but they may not do the right thing network wise; I'm just noting their properties in terms of our keyspace
<keir> yes
<lifeless> theres a paper on citeseer if you are interested
<lifeless> also hash tries might be relevant, if you want to dig
<keir> i agree, that given our keyspace, it may be the right thing. but i feel like it's just a bandaid to cover that we have variable length keys
<lifeless> well
<lifeless> for now variable length keys are axiomatix for all indices
<lifeless> I doubt that we will *ever* change that for the revision and signature indices
<lifeless> we *may* change that for the text and inventory indices
<lifeless> I'd also like to note that postgresql, sqlite etc do a fantastic job indexing variable length strings
<keir> ok.
<keir> actually that may be worth looking into
<keir> but i suppose they have different constraints
<lifeless> mysql too
<lifeless> I was chatting with David Axmark about this sort of thing actually
<lifeless> mysql optimisation both in the server code and in how you design the db is all about latency
<lifeless> gonig to disk hurts performance hugely
<lifeless> (because their data sets are so big, disk latency is measurable, like network for us)
<abentley> jelmer: ping
<jelmer> abentley: pong
<abentley> I've looked at the BB source, and it all says it's under the GPL 2+.
<abentley> The only thing lacking I could see was a copy of the GPL 2.
<jelmer> abentley: I was looking for a LICENSE file of some sort
<keir> lifeless, pull my branch bzr+ssh://mierle@bazaar.launchpad.net/~mierle/bzr/compactgraph/
<jelmer> abentley: though I guess the changes you are referring to some other GPLv2 are slim ;-)
<lifeless> keir: anyhow, I will happily eyeball the code and give you some feedback.
<keir> lifeless, i'm adding comments now but this way you can take a look
<abentley> Well, if that's all you were looking for, it's an easy fix.
<keir> lifeless, also i added the entertaining ability to compress the index blocks with repr() :P
<lifeless> keir: dude, thats so wrong
<keir> :)
<lifeless> it will play merry hell with people debugging
<keir> i thought it was hilarious
<keir> mainly i wanted to make sure swapping out block compression methods worked
<lifeless> oh I have more sample data
<lifeless> http://people.ubuntu.com/~robertc/fbd6843a48261ccf6291451e0799d06f.tix
<lifeless> thats a current-formatted copy of the mozilla text index
<lifeless> as opposed to the old 0.tix that needed editing to be usable
<keir> cool
<keir> is there a wiki page which points to the pack instructions? i don't have the link i saved before, and it's just about useless to search for it on google. for whatever reason google is not good at searching gmane.org.
<keir> lifeless, see compact_graph.py and test_compact_graph.py
<lifeless> if you google for pack dogfooding bzr
<lifeless> the first hit was one of my mails
<lifeless> so follow that, then you can hope to the quarter index page
<lifeless> and search for [PACKS]  on that page
<jelmer> abentley: that'd be nice to have in
<abentley> jelmer: see revno 206
#bzr 2007-09-18
<lifeless> so I think I can save another 10 seconds
<lifeless> robertc@lifeless-64:~/source/baz/misc-fixen$ python -m timeit -n 1 -r 1 -s 'from bzrlib.osutils import sha_strings' -s 'one_mb = ["A"*80] *800' 'for f in xrange(50000): sha_strings(one_mb)'
<lifeless> 1 loops, best of 1: 35.9 sec per loop
<lifeless> robertc@lifeless-64:~/source/baz/misc-fixen$ python -m timeit -n 1 -r 1 -s 'from bzrlib.osutils import sha_string' -s 'one_mb = "A"*80*800' 'for f in xrange(50000): sha_string(one_mb)'
<lifeless> 1 loops, best of 1: 22.3 sec per loop
<keir> lifeless, should i write my own toposort or use the existing one?
<lifeless> the existing one is fast
<lifeless> its a good starting point, if it doesn't fit the sort you need - if a different layout will be better, then we'll need to add another version of it or something to tsort
<lifeless> keir: ok looking at your code, one thing bzr requires is copyright assignment for non-trivial changes
<lifeless> theres a wiki page with the agreement, its referenced from HACKING
<keir> lifeless, i know, i'll do that later
<lifeless> ok
<lifeless> theres a few things that are truely trivial that jump out at me
<lifeless> we follow PEP-8 with a few extra guidelines
<lifeless> your code doesn't currently do that
<keir> oh, let's not worry about code formatting
<keir> i'll cross that bridge when we're looking at integration
<lifeless> like I say, truely trivial ;)
<lifeless> a data point on performance for you
<lifeless> python -m timeit -s 'def foo(_, _2):pass' 'for f in xrange(50000): foo()'
<lifeless> python -m timeit -s 'def foo(_, _2):pass' 'for f in xrange(50000): pass'
<lifeless> erm
<lifeless> first one should be
<lifeless> python -m timeit -s 'def foo(_, _2):pass' 'for f in xrange(50000): foo(1, 2)'
<lifeless> anyhow, run those
<lifeless> this will tell you something about function call costs
<lifeless> for me its about 15ms per 50K calls
<keir> it's 12 for me
<keir> 2 for no function call
<lifeless> so you have a function that takes (int, size) and does an if
<lifeless> this is duplicate work - when you decide size you know the function that you need
<lifeless> so I'd be inclined to assign to a variable the serialiser for a given thing
<lifeless> e.g. when you determine key_length_size
<keir> ok
<lifeless> set  pack_key = a_callable_that_takes_one_int
<keir> ah, right
<lifeless> this is just as clean but faster
<keir> the speed of packing and unpacking, i think will be slow
<lifeless> this is confusing
<lifeless> +    # each row is (keysize key valsize val pads) such that is row_length bytes
<lifeless> +    rows = (''.join((pack_sized_int(len(items[0] ), key_length_size),
<lifeless> +                     items[0] ,
<lifeless> +                     pack_sized_int(len(items[1] ), value_length_size),
<keir> they are prime targets for c
<lifeless> +                     items[1] ))
<lifeless> +            for items in items)
<lifeless> 'for items in items'
<lifeless> it only works because iter(items) is called before items is rebound
<keir> wow, i can't believe i wrote that
<lifeless> I need to go run a chore, back in about 20
<poolie> hello
<keir> hi
<poolie> hi keir
<lifeless> hi poolie
<lifeless> jelmer: ping, waiting on reply from you
<keir> lifeless, any other thoughts?
<lifeless> Peng: btw I have found your glitch from yesterday
<lifeless> Peng: some historical data in bzr.dev has changed (just in an index), its triggering a type error
<lifeless> keir: on the code? yes, just tracking down a performance issue for a bit
<lifeless> wow, mem copies really hurt
<lifeless> 20 second difference in performance by introducing a single exra mem copy of the text of a file fo rinitial commit
<keir> this does not bode well for my index code
<lifeless> I was trying to use sha_string instead of sha_strings
<lifeless> which is 10 seconds faster or so overall
<lifeless> but the extra copy overrode
<lifeless> so I'm going to have to try a bit harder to avoid it
<igc> morning all
<lifeless> hiya
<lifeless> of course it could be something else, hard to be entirely sure ;)
<poolie> lifeless, there's a question about dapper packages
<lifeless> hmm?
<poolie> is it possible to build bzr debs for dapper?
<poolie> can we automate that?
<lifeless> yes
<lifeless> did we not chat about this on thursday?
<lifeless> or was it friday?
<poolie> i wanted to confirm that there was nothing special about dapper
<poolie> as i recall it's just a matter of you setting up the right chroots?
<lifeless> its not different to say gentoo or redhat
<lifeless> the packaging has to be done to match
<poolie> right, the python standards have changed
<lifeless> I have the chroots
<poolie> so it's a different system
<jelmer> lifeless, sorry, just got back. will reply now
<lifeless> poolie: have you reconciled bzr.dev with abentleys patch or something ?
<jelmer> lifeless, in the mean time, did you see my pqm merge request and ping ? >-)
<lifeless> yes
<poolie> no
<lifeless> thanks
<lifeless> something wierd going on
<lifeless> in my branch the revision robertc
<lifeless> meh
<lifeless> robertc@robertcollins.net-20070720032020-xiftpb5gqeebo861
<lifeless> has two parents
<lifeless>     parent: pqm@pqm.ubuntu.com-20070720015347-eaeqmggngaemmbde
<lifeless>     parent: pqm@pqm.ubuntu.com-20070705224207-7pslqt12ofh4vnzx
<lifeless> but one of the files it altered
<lifeless> has different per-file graph for me and bzr.dev
<lifeless>  ('robertc@robertcollins.net-20070720005841-xnu6um6vx0n41h0k',), ['robertc@robertcollins.net-20070720005841-xnu6um6vx0n41h0k', 'pqm@pqm.ubuntu.com-20070705224207-7pslqt12ofh4vnzx'] 
<lifeless> left is my index, right is bzr.dev's
<lifeless> whats strange is that this is a revision I created
<lifeless> so I'm not at *all* sure why my index could be different
<poolie> lifeless, do you want me to merge aaron's patch or something?
<lifeless> %254e%2545%2557%2553-20050323055033-4e00b5db738777ff is the file id
<lifeless> poolie: no
<lifeless> spiv and I have been reviewing it
<lifeless> oh, I know
<lifeless> abentley: ping
<igc> fyi, I'm looking into the commit bug reported by Alex now
<latexer> i can't find an open bug about it.
<latexer> but I just managed to "bzr push" a local branch into the a base repository path, instead of a subdiretory there.
<latexer> and it seems it blew away the repo info, as "bzr info my_repo" just reports the branch info.
<lifeless> thats a feature
<latexer> uhh...
<lifeless> bzr info -v my_repo will show the repo details
<latexer> lifeless: interesting...
<lifeless> you can get rid of the branch by deleting .bzr/branch (but be sure *not* to delete .bzr/repository, cause thats your repository right there)
<latexer> lifeless: the feature being a repo and a branch in the same directory?
<latexer> and now I'm seeing it.
<latexer> lifeless: indeed. that worked wonders.
<latexer> lifeless: thanks!
<lifeless> vila: ping
<lifeless> meh sorry vila
<ubotu> New bug: #140563 in bzr "unicode command line options cause unicodeencodeerror traceback" [Low,Triaged]  https://launchpad.net/bugs/140563
<igc> poolie: see my latest comment on bug 140419 please
<ubotu> Launchpad bug 140419 in bzr "selective commit sometimes fails with `parent_id not in inventory` error" [Undecided,New]  https://launchpad.net/bugs/140419
<igc> poolie: do you want the fix reapplied just to bzr.dev or 0.92 as well?
<igc> I'll put the merge up in the next few minutes
<poolie> igc, please do merge that for 0.92
<poolie> i mean, 0.91
<igc> sure. I meant 0.91 as well. :-)
<fullermd> Some of the code around the patch for bug 115947 seems to have changed, but I'm not sure whether the problem is solved, still there, worked around elsewhere, etc...
<ubotu> Launchpad bug 115947 in bzr "DirState.set_state_from_inventory() fails when we have common prefix paths "foo" and "foo-bar"" [High,Fix committed]  https://launchpad.net/bugs/115947
<igc> ok - the reapplication of that fix has been sent to pqm for both 0.91 and bzr.dev now
* igc food
<lifeless> cool
<lifeless> we should check that nothing else got reverted by that merge
* Starting logfile irclogs/bzr.log
<poolie> http://bundlebuggy.aaronbentley.com/request/%3C46EF2B5C.3010208%40internode.on.net%3E
<poolie> i think this looks reasonable but i'm not specifically sure why it's correct
<poolie> s/why/that
<poolie> actually i am pretty sure
<lifeless> which patc is it ?
<poolie> -        entries = work_inv.iter_entries()
<poolie> +        entries = work_inv.iter_entries_by_dir()
<poolie> that's the heart of it
<lifeless> yup
<lifeless> oh is this from ian ?
<poolie> yes
<lifeless> if so its just reinstating what jam reverted by mistake
<lifeless> bad merge
<poolie> spiv, how's it going? quick call?
<jml> is there a clever bzr trick to move uncommitted changes from one branch to another?
<fullermd> merge --uncommitted?
<jml> that's probably it :)
<jml> bzr rocks.
<lifeless> ok
<lifeless> bzr.dev has broken indices
<lifeless> abentley: ^ ping
<lifeless> abentley: I don't *know* that you ran reconcile, but its my best bet so far
<lifeless> spiv: ping
<lifeless> spiv: I'm going to ring you, hope thats ok
<spiv> lifeless: ok.
<abentley> lifeless: I have not deliberately run reconcile on my main bzr.dev
<lifeless> ok thats very interesting
<lifeless> *something* has added a parent though
<abentley> I will run check.
<abentley> It's possible I did it by accident, I suppose.
<lifeless> I would expect your parents-modified check to error on the new file graph for NEWS if something else introduced this
<lifeless> >>> from bzrlib.repository import Repository
<lifeless> >>> r = Repository.open('..')
<lifeless> >>> i = r.get_inventory('pqm@pqm.ubuntu.com-20070720015347-eaeqmggngaemmbde')
<lifeless> >>> i2 = r.get_inventory('pqm@pqm.ubuntu.com-20070705224207-7pslqt12ofh4vnzx')
<lifeless> >>> i.path2id('NEWS')
<lifeless> 'NEWS-20050323055033-4e00b5db738777ff'
<lifeless> >>> fid = i.path2id('NEWS')
<lifeless> >>> i[fid] .revision
<lifeless> 'robertc@robertcollins.net-20070720005841-xnu6um6vx0n41h0k'
<lifeless> >>> i2[fid] .revision
<lifeless> 'pqm@pqm.ubuntu.com-20070705224207-7pslqt12ofh4vnzx'
<lifeless> >>> i2[fid] .revision in r.get_ancestry(i[fid] .revision)
<lifeless> True
<lifeless> just veriified again
<lifeless> that is, the per file change in my commit should have one parent only, as my mail said - I hadn't actually checked via the inventory before.
<lifeless> abentley: your reconcile is the only thing I can think of that would change a file graph like that
<abentley> I'm not really understanding the scenario, and it's late here.
<abentley> But I'm paranoid enough to run "reconcile" only against temp branches until it hits mainline.
<lifeless> abentley: ok. Well andrew has been looking at your patch anyway as its part of the hpss work
<lifeless> so leave it with us; someone else may have run that reconcile
<lifeless> e.g. vila or one of theother branches merged last night
<abentley> I'll let you know about the "check" output, then off to bed.
<lifeless> thanks
<lifeless> sleep well
<abentley> My home repository definitely has not been reconciled.
<vila> lifeless: hi, still drinking first coffee, but never run reconcile
<abentley> lifeless: Both my home and work repositories have lots of unreferenced text ancestors, so it seems impossible that they've been accidentally reconciled.
<lifeless> this is bizarro
<lifeless> bzr.dev has a new entry for that revision in that file
<lifeless> as well as many others
<lifeless> (many other replacement index entries)
<abentley> Well, perhaps we can check for the bogus entries on all the branches that have been merged into bzr recently?
<lifeless> yeah
<lifeless> I was about to start doing that :)
<lifeless> there's martin
<abentley> Sorry I can't provide a shortcut by being at fault :-)
<lifeless> this happened sometime yesterday far as I can figure
<lifeless> vila
<abentley> G'night.
<vila> lifeless: pong
<lifeless> dm watkins
<vila> abentley: night
<lifeless> jelmer
<lifeless> keir
<vila> hmm, bzr viz on http://bazaar.launchpad.net/~v-ladeuil/bzr/bzr.integration/ says pqm@pqm.ubuntu.com-20070917142923-f06edfgw1d0cvj4w was the tip when I merged my fix for #140055
<vila> the commit message is 'Add reconfigure command'
<lifeless> igc: you haven't run the new reconcile have you ?
<igc> no - should I?
<lifeless> no
<lifeless> abentley: if you are still up, I've mailed the list a request for debug stuff; which you might like to do anyway - but no rush. I just won't merge bzr.dev for a bit.
<poolie> igc, about docstrings
<poolie> it seems hard to define ahead of time how much is enough
<lifeless> I think one per non test-case method and one-per-class and one-per-module is desirable always
<lifeless> because intent is rarely expressed in code
<poolie> intent can be expressed in method names
<lifeless> to some degree
<lifeless> but I see docstrings as different to comments
<poolie> lifeless, for example i've picked up, i think from you, the trend to have long test names
<lifeless> self documenting code can be comment ftree
<poolie> since you only have to write them once
<poolie> agree
<lifeless> yup :)
<poolie> otoh i like more comments in test code
<lifeless> yes, that too
<poolie> because it is often not obvious *why* something is there
<lifeless> I'm just saying that I support a policy of always having docstrings on code outside of .tests
<poolie> and it's not like regular code where you can just remove such lines
<lifeless> and inside .tests where the code is not a test itself :)
<poolie> i do to, but having a docstring that just repeats the method name doesn't count
<lifeless> right
<spiv> poolie: Thinking of tests... http://martinfowler.com/articles/mocksArentStubs.html is the link I was talking about the other day, that talks about behaviour verification vs. state verification.
<lifeless> spiv: you have seen my interface skew 'paper' right ?
<spiv> lifeless: yes
<lifeless> good :)
<spiv> lifeless: but thanks for the reminder, it may be relevant to a blog post I'm slowly composing.
<lifeless> ok, thats my 9 1/2 hours
<igc> poolie: re "having a docstring that repeats the method name doesn't count" ...
<igc> it *is* sometimes useful
<igc> not for what it says, ...
<igc> but for the fact that it doesn't add anything else :-)
<poolie> i guess it can represent two things:
<spiv> igc: then it should just directly say "I'm a slack developer." ;)
<poolie> "i thought about this and i'm sure there's no more to say" or "i didn't think very much"
<poolie> :)
<igc> spiv: :-)
<poolie> are we testing the developer's state or their behavior? :)
<spiv> igc: because docstrings should express intent rather than just stating the obvious about the implementation ;)
<igc> both :-)
<Stevage> hello
<Stevage> how do you find the history of all files in a directory?
<Stevage> or one file, for that matter?
<lifeless> bzr log PATH
<lifeless> gives one file at a tie
<lifeless> *time*
<Stevage> "bzr log dirname" seems to only give revisions for the directory itself
<lifeless> right
<lifeless> there isn't a --recursive option for it yet
<Stevage> well I just want files in that dir
<Stevage> not necessarily subdirs
<lifeless> the obvious way to express that to me is 'bzr log dir/*'
<lifeless> (that doesn't work, I'm speculating on UI right now)
<Stevage> ah
<Stevage> yeah, it didn't work :)
<Stevage> also, can anyone explain why bzr is case sensitive on windows?
<spiv> lifeless: that UI sounds good to me too.
<fullermd> You'd need a --no-recuse dir/*
<lifeless> Stevage: because windows is case sensitive
<Stevage> it's sort of bizarre
<fullermd> Since it's likely that * will encompass subdirs....
<Stevage> lifeless: since when?
<lifeless> bleh
<Stevage> "dir pfx" works for a dir called PFX, so why doesn't "bzr log pfx"?
<lifeless> did I mention I'm about 6 hours past lunchtime with no food
<fullermd> (unless you make recursion non-default, but I think that would be Wrong(tm))
<lifeless> Stevage: oh I see. Please file a bug, we can fix that.
<poolie> Stevage, i'd say it's because we're case sensitive everywhere
<Stevage> coolies
<Stevage> well perhaps the UI could be case insensitive
<poolie> it would be better if we were case-insensitive internally on platforms where the user would expect that
<poolie> right
<Stevage> where's the bug tracker?
<spiv> bugs.launchpad.net/bzr
<poolie> i think 'state verification' is a really poor name, implying that it's for testing things that mutate state
<poolie> something like 'result verification' would be better
<igc> lifeless: emailed you the results from my repo btw
<poolie> it's a good system of naming in other regards though
<poolie> spiv, what bothers me a bit about some of the remote tests is that they are very mock-based,
<poolie> and i guess i am not a mockist
<poolie> i would rather test against a fake object and observe the results
<poolie> hm
<poolie> also, even for a mock object they're one-sided in that they check only inputs, not results, or vice versa
<poolie> i'd like to use http://martinfowler.com/bliki/ObjectMother.html in more tests
<poolie> in particular it would be a neat way to make either everything or nothing use unicode filenames
<poolie> for examlpe
<Stevage> hey can anyone tell me why bzr.exe is so slow?
<poolie> what in particular is slow?
<Stevage> it takes on the order of 2 seconds just to return "bzr help"
<Stevage> it's a problem for me because I need to call it approximately 50,000 times
<poolie> !
<poolie> yeah
<poolie> this is for your importer?
<Stevage> yep
<poolie> for comparison on my linux machin it's about 0.1s
<Stevage> sucks
<Stevage> so it's a windowsy thing
<poolie> are you running it under cygwin?
<poolie> i'm not sure
<Stevage> no
<Stevage> native
<poolie> can you try it with bzr --profile-imports help
<Stevage> ok what to do with the output?
<Stevage> 281.0 it lists for 'cum' of bzrlib
<Stevage> hmm, seems when I run it a few times in a row it's quicker, but still close to a second maybe
<spiv> Stevage: paste the output at http://rafb.net/paste and we can take a quick look at it
<Stevage> http://rafb.net/p/XMjBKk33.txt
<spiv> Stevage: hmm, nothing jumps out at me except for that fact that all imports are pretty uniformly slow.
<spiv> Stevage: I wonder if it's something to do with the way bzrlib is packed bundled into a zip file by the win32 installer?
<poolie> Stevage, how long does it take to do
<poolie> python -c "import bzrlib"
<spiv> Stevage: I suppose you could compare running from the source distribution.  (download and unpack the source tarball, install the standalone python if you haven't already, and run "python path\to\unpacked\bzr --profiled-imports help")
<poolie> that would be good
<Stevage> python -c "import bzrlib" took about half a second. is there a way to time it?
<Stevage> poolie: the first two numbers are 219 and 172 (instead of 281 and 172). want me to paste it?
<spiv> Even "import sys" takes 15ms according to your --profile-imports output!  (Maybe that's just because the resolution of time.time() on win32 is so poor?  time.clock() is better on win32)
<Stevage> yeah I tihnk it's resolution
<Stevage> all the times are listed as 0, 15, 16, 31...
* spiv nods
<poolie> Stevage, i suspect it's something windows-specific as it's so much slower than here
<poolie> aside from anything else you should probably post to the list so alexander and co can look at it
<poolie> also running from source as spiv says would be good
<Stevage> running from source is faster than running from precompiled?
<Stevage> I'm semi-running from source (due to my change)
<Stevage> or can I compile it myself, will that go faster?
<poolie> there are two orthogonal things here - whether you have the extensions compiled
<poolie> and whether you're using bzr from inside a zip file, or from separate files on disk
<poolie> i think spiv was thinking that using a zip file might be much slower
<Stevage> ah
<Stevage> how do I check?
<Stevage> ok, bazaar\lib contains library.zip
<Stevage> if I unzip that will it be faster?
<Stevage> and if so, do I just dump the files in lib?
<poolie> probably the best thing would be to download the 0.91rc2 tarball
<poolie> extract that, then run from in there
<poolie> i realize that won't have your changes but let's at least see how it compares
<poolie> i assume this is a reasonably new machine?
<Stevage> not especially new, why?
<Stevage> it's a P4 2.4Ghz
<poolie> i mean if it's an 800Mhz pentium
<poolie> ok
<Stevage> heh yeah
<Stevage> ok, why do you do want me to download .91rc2? is it a lot faster than .90.0?
<Stevage> is that equivalent to bzr.dev?
<ubotu> New bug: #140614 in bzr "selftest noise re _http_start" [Undecided,New]  https://launchpad.net/bugs/140614
<poolie> bzr.dev would also be ok
<poolie> Stevage, it may be faster, but i think the speed problem may be something specific to your tree
<poolie> i'm not familiar with the library.zip thing and i wonder if that's causing a problem
<ubotu> New bug: #140615 in bzr "get_reverse_tag_dict" [High,New]  https://launchpad.net/bugs/140615
<Gacha> hi
<Gacha> I want to create  a repository, like /repository then project1, project2 ...
<Gacha> I need to call "bzr init" in the repository or there is some more to know?
<poolie> Gacha, init-repo for the repository, then init for each project
<Gacha> thanks
<Gacha> and how can I get a clean copy of a project, without the .bzr dirs?
<Gacha> with "bzr get"?
<mlh> Gacha: you need the .bzr
<mlh> unless you don't want to use bzr  -- you could export in that case
<Gacha> but when I want to use my software for production, not for editing
<mlh> that's usually done with your build tool
<mlh> but if there's nothign to build you can 'bzr export ... ' or rsync --ignore=.bzr
<Gacha> thanks
<mlh> er, that'd be rsync --exclude=.bzr   (I was going from memory)
<mlh> what scm/vcs did you use before bzr?
<Gacha> none
<Gacha> this is my first try to use versions :)
<mlh> how did you deploy to production then?
<mlh> just a copy?
<Gacha> with rsync
<mlh> ah
<Gacha> I had test, production and bacula for safety
<mlh> you could have a tiny Makefile or 'deploy' script which ensured that there were outstanding changes and no rubbish before you rsync'd
<mlh> '' that there were NO outstanding changes ..'   taht should read
<Gacha> I was coding alone so there was no problems, but now I feel the need for versions and branches
<Gacha> the hardest would be to lern this to my boss
<mlh> I know exactly what you mean
<Gacha> he likes to open files as root, edit and thats it
<Gacha> and I cant say anything :)
<mlh> :-)
<fullermd> Oh, don't say anything.  Just overwrite his changes.
<fullermd> When he starts bitching, you look him in the eye and say "They weren't in version control, so they never happened."
<mlh> hook up aide or tripwire with a script that copies changes to a bzr repo
* mlh thinks .. maybe that would the start of a good bzr plugin
<Gacha> now when I called "bzr init-repo repository" I need to create the projects. I should create them with mkdir and call "bzr init" in the project folder, and nothing in the repository folder?
<mlh> see the example in 'bzr help init-repo'
<Gacha> I did
<mlh> I theeenk you almost always want --no-trees  but I'm far from an experienced bzr'er
<mlh> oh, and you did everything up to the 'cd trunk-checkout' ?
<fullermd> You always want --no-trees, except when you don't.  Then you want --trees, which you always want, except when you don't.
<Gacha> right
* mlh is grateful for fullermd's lucid explanation
* fullermd overflows with topical advice.
<Gacha> and whats the difference between --no-trees and trees? What would be the "working trees by default" ?
<mlh> Gacha: for one project, the repo and the working tree are in the same place
<Gacha> I need repo for many projects
<fullermd> No you don't.
<mlh> in the init-repo/checkout --lightweight model, they're in different places
<Gacha> repository/project1/trunk/.....
<mlh> Gacha: it's not a problem to have a repo for each project
<Gacha> http://doc.bazaar-vcs.org/latest/en/user-guide/shared_repository_layouts.html#id4
<Gacha> I want the 1.1
<fullermd> There's no real gain in storing unrelated branches in a repository (there's not any real loss either, but there's no gain)
<igc> night all
<fullermd> You may be mislead by comparisons to other VCSen.
<mlh> Gacha: right, note the separate repo for each project; this contrasts with the SVN layout
<mlh> in 1.1 svn has 1 repo for 2 projects; bzr has a repo for each project
<Gacha> so, I need to create the repository with the --no-tree or without? The project dirs I can create with simple mkdir or there is some other way?
<mlh> again, I think (but stand to be corrected) that all branches/trunks in a bzr init-repo repo should be closely related, i..e branches of one another
<Gacha> so, I need to do "init-repo" in each project dir?
<fullermd> Well, the answer is yes and no.  It depends on how you want to work.
<mlh> Gacha: don't sweat over no-trees
<Gacha> but I dont understand the difference
<mlh> if you do the lightweight checkout, you're creating a working tree elsewhere and clearly don't need trees in the repo
<Gacha> from the one statement in docs
<fullermd> The difference is in where your working files are.
<fullermd> With --trees, your branches in the repository have working trees colocated in them.  With --no-trees, they don't, and you have to check them out elsewhere to work on.
<Gacha> 2nd option looks better
<mlh> the other thing is you don't have to decide now.
<fullermd> Quite.  You can always change your mind and shift stuff around later.
<mlh> just mkdir proj1; cd proj1; bzr init
<mlh> you can forget abotu init-repo for the moment
<mlh> bzr is easy to start with
<fullermd> The question of repositories and where working trees are are pretty ephemeral; you can change all that around any time.
<Gacha> I have a remote server where I want to make the repository, but the editing will be on my work computer and home computer.
<fullermd> Are you sure you want the repo remotely?  You end up having to go across the network every commit then.
<Gacha> how I understand, I need to use Heavyweight Checkout
<mlh> indeed
<Gacha> I'm a web developer and the changes should be visible every time I commit them
<fullermd> Well, that won't happen regardless.
<fullermd> Commiting a new revision into the branch won't update some other working tree.
<mlh> if you want to do a checkout/export/deploy for every commit, that might be possible with a hook (don't know) or you can have a cron job os seomthing poll the repo
<fullermd> I'm pretty sure the SS doesn't exec any hooks, so you're down to manually or cronally triggered.
<mlh> but having everything deployed the second it hits the repo is not the design use of a vcs
<Gacha> I will execute the pull every time is needed
<mlh> you want to use bzr as a replacement for bacula/rsync/whatever
<Gacha> :D
<Gacha> I want to edit files on my local machine
<Gacha> then with small script push them to remote server
<mlh> :-) which is a common but discouraged mode of use for any vcs. Certainly the svn and cvs mailing lsits get this kind of request all the time
<mlh> In anything more than a one person shop, you should deploy to a demo/test/qa server and run some tests
<mlh> and only deploy to production if they pass
<mlh> there's also code review of course
<mlh> anyway
<mlh> enough of software engineering 101 :-)
<fullermd> Man, don't tempt me to go on a rant over testing web apps...   I already did that this week.
<mlh> I'm in the the thick of it now
<mlh> what do you use?
<mlh> jmeter and opensta look useful
<fullermd> What, for testing?  Nothing, because I've never found a solution.
<mlh> heh
<fullermd> Hence, the rant.
<mlh> wel besides the above, selenium and watij/watir might be worth looking into as they drive a real brwoser
<mlh> there's something in pythin around to, which I can't recall
<fullermd> Driving a browser sounds like throbbing pain...
<mlh> ah the python thing is 'twill'
<Gacha> so what should I use, the init or the init-repo?
<mlh> fullermd: http://www.advogato.org/article/874.html
<fullermd> jmeter looks nothing like what I'd need...
<mlh> Gacha: just init for now, make life easy for yourself
<Gacha> ok
<fullermd> Neitehr does opensta...  these are just stress testers.
<mlh> yeah stress testing is what I'm doing .. functional tests by others
<mlh> but most stress testers don't udnerstand ajax which may or may not matter
<fullermd> Yeah, I need functional tests.
<fullermd> Manually stepping through multi-step processes trying various inputs to try and cover all the cases to test a change is a nightmare, and holey as hell.
<mlh> my mission is to force developers to write/add to the tests and test before they commit
<mlh> fat chance
<fullermd> That wsgi stuff in twill sounds like a load of crud I don't need.  I'd just test it against a web server.
<fullermd> My problem is I fear any solution is just going to be miserable to use, since I have to define multi-stepping, then going to the right place to check stuff   :|
<mlh> He surveyed the website, and all gladness left him and a deep melancholy settled down upon his spirit.   Life to him seemed hollow, and existence but a burden
<mlh> (misquoting tom sawyer)
* mlh -> home
<fullermd> Mmm.  Doesn't seem to do anything for the picking apart forms on the viewing side   :|
<poolie> ok that's it for me
<Kinnison> Is there a command to give me the log --short info about a revision, and also the list of affected filepaths?
<lifeless> log --short -v ?
<dato> log --short -v ?
<lifeless> ciao
<Kinnison> perfect, thanks
<Gacha> is there a way to specify the user as argument when commiting ?
<Peng> Gacha: Starting with the next vversion of Bazaar, there's a --author argument to bzr commit.
<Peng> an.
<Gacha> nice
<Gacha> when it will be?
* Peng points up at the 0.91rc2 link in the topic
<lifeless> Gacha: we release monthl
<Gacha> why the ubuntu package is so outdated?
<jdong> it's not THAT outdated
<jdong> it's like 1 version behind stable...
<Gacha> it would be safe to install from source the new version?
<jdong> Gacha: there is a deb repository at bazaar-vcs.org
<jdong> you can always get the latest bzr from there for your Ubuntu/Debian release
<Gacha> right, I forgot that already installed the newsest from your repository, sorry :)
<ignas> hi
<Odd_Bloke> ignas: Hi.
<alfborge> Can anyone explain pending merges in an easy way?
<alfborge> And why do I have to merge when there are no conflicts?
<dato> you have to merge (instead of pull) when you have commited a revision of your own
<alfborge> thanks
<gabe_> ppl
<gabe_> what is the best way to backup a no-trees bzr repo? Just tar and bz2 it?
<dato> for example
<gabe_> i remember with svn i made a dumpfile...?
<dato> right. there is no such thing in bzr.
<gabe_> k tar and zipping is most straightforward
<Zindar> I think the simplest thing is to push it to another machine
<Zindar> bzr push = instant backup :)
<Zindar> (I know, that might not be what you want for a number of reason... but it's good enought for me)
<Peng> Unless the bzr repo gets corrupted. :)
<gabe_> Zindar: that's a good idea
<Zindar> peng: yes :)
<gabe_> problem is I make copious use of sftp
<gabe_> Zindar: but bzr doesn't push over sftp properly
<Zindar> gabe_: bzr push sftp://path
<Zindar> what?
<Zindar> why not?
<Zindar> I use sftp all the time
<Zindar> never had any problems for at least a year
<gabe_> i use sftp all the time, it pulls
<gabe_>  and checks out
<gabe_> but not push
<radix> gabe_: you're probably just misunderstanding what "properly" means :-)
<radix> gabe_: it does push quite fine over sftp
<Zindar> gabe_: what happens?
<gabe_> at least in the man it says it won't push working trees
<Zindar> never had any problems with it
<Zindar> yes
<Zindar> but you don't need that
<radix> gabe_: yes, it doesn't update the working tree, but all the data is there in the .bzr
<gabe_> right
<gabe_> aha that's ok then
<Zindar> you can always login and do "bzr update" to recreat then
<gabe_> it's true i don't need working tress
<radix> or just branch it back, etc
<gabe_> for example
<Zindar> exactly
<gabe_> if i push to another machine I will have a treeless repo...
<gabe_> if i log in to that machine and cd to the repo
<gabe_> how can i make trees from the .bzr?
<radix> bzr update
<Zindar> the reason is simply that working trees is something that can change.. so if you would want to update that, you would have to run diff and stuff like that over sftp.. which is not fun
<Zindar> you just run "bzr update"
<gabe_> and it updates from the local copy?
<radix> actually, you may need to run "bzr checkout ." if it's the first time? or maybe that's not necessary any more
<gabe_> that's awesome
<radix> gabe_: yes
<gabe_> i'll try it :P
<gabe_> cheers
<radix> ok :)
<gabe_> makes more sense than tarring and zippin
<gabe_> just today i moved the last of my projects over from svn
<gabe_> now i'm figuring out the best way to back it all up
<Peng> I think it's a good idea to tar it up occasionally, just in case the repository gets corrupted or something.
<gabe_> Peng: good idea, perhaps about once a week will be cool
<Peng> Yeah.
<gabe_> ummm
<gabe_> not sure what to do...
<gabe_> I have a bzr repos, it is called 'bazaar' :)
<gabe_> i mounted a backup destination via NFS
<gabe_> bzr co /usr/var/bazaar/ /media/backup/
<gabe_> bzr: ERROR: Not a branch: /usr/var/bazaar/.bzr/branch/
<gabe_> it is a --no-trees repo with many branches beneath it
<gabe_> what is the easiest way to backup the entire thing?
<dato> gabe_: you can't 'co' a repo, only a branch. and since you presumably have several branches in the repo, you'd have to 'co' each of them.
<dato> so it's better to run tar+gz, or rsync
<gabe_> ah damn
<dato> rsync would work best if you have the old copy lying around (i.e. if you run it periodically over the same directory)
<dato> in any case, backuping .bzr is the same as backuping any other directory in the filesystem
<gabe_> ok so that makes it a bit easier
<gabe_> hmmm freebsd don't have rsync by default - cripple!
<gabe_> cheers, rsync worked a treat on all those thousands of knit files!
<sri> sup
<gabe_> sri: yo
<sri> yo
<james_w> could someone please get me the output of bzr info -v bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk I don't have my ssh key around.
<james_w> I just need the format lines really, in particular the branch.
<james_w> ah, no need, grep saves the day again.
<corporate_cookie> i'm trying to build a bzr-17 rpm with python2.4 setup.py bdist --fromats=rpm ...and it errors at /bzr-0.17.0/bzrlib/__init__.py", line 46 complaining of 'invalid syntax'
<corporate_cookie> any ideas ?
<corporate_cookie> line 46 is bzrlib.symbol_versioning import (deprecated_function,
<ignas> hi
<corporate_cookie> hi : )
<ignas> my checkout weights ~70 mb, is there a way to make working with it through the network a bit easier?
<ignas> i mean just pushing the branch to launchpad takes ages
<ignas> makes me think twice before creating a public feature branch :/
<cr3> when I bzr push, I get: No push location known or specified. So, where can I specify a push location?
<ignas> bzr push [LOCATION] 
<ignas> can i get bzr tell me more information about progress of such looong operations as "bzr push"?
<cr3> ignas: thanks, I wonder why that location wasn't preserved when branching
<ignas> well, *pushing* a branch into the place which you branched from
<ignas> is not what you want 90% of the time
<ignas> usually you *branch* and then *merge* the changes back
<ignas> hmm, bzr push sftp://some-place-in-launchpad -v is not giving me anything more than the same old progress bar :/
<james_w> corporate_cookie: you need python 2.4, it looks like you are running python 2.3.
<corporate_cookie> james_w: when I issue python2.4 -V ...it tells me i'm running Python 2.4
<james_w> corporate_cookie: ah, sorry, I missed you were explicitly running with 2.4
<james_w> corporate_cookie: does the line in question not start with "from"?
<corporate_cookie> james_w: it dose indeed start with from
<james_w> corporate_cookie: what is the previous line?
<corporate_cookie> james_w:      version_string = '%d.%d.%d%s%d' % version_info
<corporate_cookie> __version__ = version_string
<corporate_cookie> its an else clause
<james_w> I'm not sure then.
<corporate_cookie> alas ..that makes two of us
<corporate_cookie> thanks for the help though
<AnMaster> I have been searching the website for info about the command "sign-my-commits" and how it is used but have been unable to find anything useful in the way of documentation
<AnMaster> I would like some more info about how it works
<lifeless> AnMaster: it triggers the normal gpg signing for all revisions that match
<lifeless> and are not signed
<AnMaster> lifeless, hm? and how does the normal gpg signing work
<AnMaster> that is where I can't find any info
<lifeless> doc.bazaar-vcs.org/bzr.dev/en/user-guide/configuration.htm
<lifeless> sorry, http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/configuration.html
<AnMaster> lifeless, hm, one problem, how does it select gpg key
<AnMaster> I would have several that would match
<lifeless> it users your default, unless you override the signing command to supply it
<AnMaster> ok
<AnMaster> lifeless, I'm not sure what my default one is, as I use GUI frontends like kgpg
<lifeless> gpg --clearsign foo
<lifeless> wll probably tell you
<lifeless> if kgpg accepts gpg commands you can use kgpg from bzr
<lifeless> I use gnome-gpg for instance
<lifeless> which means I get a gui prompt
<AnMaster> hm
<lifeless> gpg_signing_command = gnome-gpg
<lifeless> in my bazaar.conf
<AnMaster> hm
<AnMaster> now this is odd, I just checked against key server and some one I got no idea who it is has signed my key. hm
<AnMaster> oh well doesn't belong in this channel
#bzr 2007-09-19
<AnMaster> lifeless, um, how would I tell gpg on command line what key to use?
<hstuart> AnMaster, gpg -u user@domain.ext
<AnMaster> ah
<hstuart> I've wrapped my signing in a separate command file as gpg -u identity --clearsign $*   seems to work fairly well
<hstuart> though I haven't really found a good way to see who has signed what commits
<AnMaster> bzr: ERROR: Failed to gpg sign data with command [u'/usr/bin/gpg -u anmaster (AT) users.sourceforge.net', '--clearsign']  (it really said @ but I don't know if this channel is logged public and I hate spam)
<AnMaster> why not some more detailed error message?
<hstuart> AnMaster, you have to wrap it in a separate script and give that as the gpg_signing_command
<AnMaster> oh? that seems odd
<hstuart> I battled around with that for a while as well
<hstuart> I think it has to do with the way that python executes separate processes, but I never bothered to investigate too closely
<AnMaster> by the way using "$@" is in 99.99% percent of the cases better than $*
<AnMaster> don't forget the quotes
<lifeless> hstuart: you should not have --clearsign in your script
<lifeless> hstuart: bzr supplies --clearsign
<AnMaster> lifeless, but why is a script needed at all?
<hstuart> lifeless, ah, well, then it gets really clearsigned ;)
<lifeless> AnMaster: I'd say 'its a bug', I think there is a bug open on it
<AnMaster> k
<hstuart> AnMaster, right
<AnMaster> ok, signing all current 135 commits, means I have to enter my key 135 times?
* AnMaster decides to look at gpg-agent
<hstuart> heh
<AnMaster> seems a lot harder to use than ssh-agent
<AnMaster> that I use currently
<lifeless> AnMaster: did you try kgpg ?
<AnMaster> lifeless, well, it didn't work as it should
<lifeless> ah well
<hstuart> lifeless, is there a good way to see who has signed what commits, btw? I've been looking for that
<lifeless> hstuart: hmm, don't think so
<hstuart> drat - anything planned?
<AnMaster> lifeless, is seems to support it's own set of options for command line processing
<lifeless> it would be great to have someone step up and put some love into that
<lifeless> AnMaster: :(
<hstuart> lifeless, ok, I'll take that as a no then :)
<AnMaster> or at least a very limited set of gpg options
<lifeless> hstuart: its planned in the abstract
<lifeless> hstuart: but I'm not aware of anyone actually wokring on it
<AnMaster> anyway, any hints on gpg-agent?
<lifeless> no idea, I haven't used gpg-agent
<hstuart> yeah, I've seen the launchpad plan, but the gpg things haven't received any updates in forever
<hstuart> ah well, anyway, off to bed, 'night
<lifeless> gnight
<lifeless> vila: re []  in argument lists, i think you are a little confused
<lifeless> vila: try this:
<lifeless> >>> def foo(l=[] ):
<lifeless> >>>  l.append('1')
<lifeless> >>>  print l
<lifeless> >>> foo()
<lifeless> >>> foo()
<AnMaster> got to sleep too
<AnMaster> hopefully gpg-agent will look less complex when I wake up
<AnMaster> :)
<lifeless> AnMaster: you could disable your passphrase
<lifeless> sign them all
<lifeless> reinstate it
<AnMaster> lifeless, ugh, sounds insecure
<lifeless> no more than having a process that will sign a document if asked over a local socket
<AnMaster> hm
<AnMaster> night
<lifeless> (assuming you are not surfing etc at the time, don't have sshd running ...)
<lifeless> night
<AnMaster> lifeless, well I don't have any server running on my desktop as the user I use in x, I do have some test ones as other users
<AnMaster> *locks x session, switches to a vt, runs vlock -a*
<lifeless> there you go then, sounds fine :)
<vila> lifeless: can't sleep, but no, not confused, I perfectly understand your example
<lifeless> vila: so why did you say that the commands.run method will display the same behaviour?
<vila> they will not, but they are always *called* with fixes=[] , so either we make it the default value (cmd_commit uses it as read-only) or we begin by if fixes is None: fixes =[] 
<vila> both will have the same result, ok, the later is less risky, but how in hell will cmd_commit decide that it knows how to fix something ?
<lifeless> I would use a tuple myself in this case
<lifeless> fixes=()
<lifeless> because its safe
<lifeless> but it would need to be changed if commit started mutating the list
<vila> Yeah, I see the point, was grumpy :)
<poolie> hello
<vila> hi poolie
<poolie> hi vila
<beuno> hello, poolie, I've got a question stored for you about the translation of the bzr docs, got a minute?
<poolie> sure
<vila> lifeless: in another context (still  related to []  as a default value)
<beuno> I'm translating it into spanish, and I was wondering how to structure a few things, for example, the index.txt
<vila> I introduced possible_transports in various methods as the way to share connections
<beuno> should it be under docs as index.es.txt?  in the /es/ dir?  if that's the case, shouldn't the english one be moved to /en/ too?
<vila> In one review John said that since I wanted to push people to use possible_tranports (p_t) I may as well declare it with a default value of [] 
<lifeless> beuno: index.txt in the es dir
<lifeless> vila: John was smoking his toenails that day then.
<beuno> lifeless, and the english one stays under /doc/?
<lifeless> beuno: I'd mail the list Ithink actually
<lifeless> I'm sure igc has a plan, but hes not here yet
<poolie> that would be cool to have it translated
<beuno> lifeless, alright then, seems like the best place to gather opinions, will do that
<poolie> beuno, do you think translating the ui is important too?
<beuno> I've got about 20% translated
<beuno> poolie, absolutely!
<vila> lifeless: :) not completely, it may provide local caches for the duration of a bzr command
<beuno> I'm currently translating the docs to reflect what bzr will actually say (in english), but the ideal situation would be to have everything localized
<poolie> vila, what may?
<vila> lifeless: still problematic for long running users as GUIs though
<lifeless> vila: no, it will not be weakref. It will hold sftp links etc open for the entire runtime of e.g. graphical tools using bzr.
<vila> lifeless: yup
<lifeless> vila: Its a terrible idea to abuse this language defect like tat.
<vila> lifeless: I didn't :)
<poolie> if you're talking about mutating the paramater default as a hidden global variable i agree
<lifeless> Good :)
<poolie> that sounds pretty bad
<lifeless> Apparently jam suggested that.
<lifeless> I claim he was smoking his toenails.
* beuno was asked to give a talk on bzr in October at an open source conference, so is trying to have everything in spanish before that
<beuno> and having it for me employees is a bonus
<vila> lifeless: my bad, John didn't propose that but instead to make it a mandatory parameter
<lifeless> vila: ah!
<lifeless> much saner
<vila> And I didn't implement it because I'm still unsure on where (in terms of code paths) the caching should be activated unconditionally
<synic> is there a FAQ on how to improve the performance of a larger repository?
<synic> is there a way we can mark old changes as 'obsolete' or something?
<lifeless> synic: we're working on changes in teh core, targeted for0.92, to massively improve that
* ignas is beginning to think that bzr might be a bit difficult to use with a big project :/
<synic> anything I can do until then?
<ignas> 3+ hours to push a branch to launchpad
<ignas> and it's still below 50% of the progress bar
<ignas> am i doing something wrong? maybe i shouldn't have used sftp as the protocol?
<J-diddy> swapping it out with bzr+ssh:// will definitely help
<lifeless> ignas: 0.92 will include bzr+ssh improvements that make it about 20% slower than rsync
<lifeless> ignas: don't stop it now though
<lifeless> ignas: when it hits 50% its actually about 80% or more done
<ignas> i know, it just got to Fetch 3/4
<lifeless> synic: not really sorry. Its a performance bug in bzr.
<ignas> but having a 70mb repository is a bit painful, because event with maximum upload speed it still would take quire a lot
<ignas> not 3 hours a lot though ;)
<ignas> lifeless: thanks for the heads up though
<synic> lifeless: are the changes in 0.92 something that launchpad will be able to integrate easily?
<igc> morning all
<lifeless> synic: yes
<lifeless> poolie: calling ok ?
<poolie> k
<poolie> vila, were your cpu problems due to trackerd?
<vila> no, first it was... evms, I uninstalled it
<abentley> vila: Do you want a reply to your post re: [] ?
<vila> then it was khubd, I went a bit bersek and deactivated services: bluetooth, powernowd, acpid, apmd, mdadm
<vila> abentley: I will add a comment explaing that I was confused as lifeless pointed out a bit earlier :)
<abentley> Okay.
<vila> point (and door) closed :)
<poolie> hello abentley
<abentley> Hi there.
<poolie> vila, thankyou for the patch for bug 140614
<ubotu> Launchpad bug 140614 in bzr "selftest noise re _http_start" [Low,Fix committed]  https://launchpad.net/bugs/140614
<poolie> can you explain to me briefly why this fixes it though?
<poolie> why would releasing the semaphore cause the socket fd to be invalid?
<vila> I didn't double-checked, but most probably the client was already using the socket while the server try to set the timeout
<vila> as Aaron as pointed out, my previous fix, by releasing hundreds of sockets should have make the code faster (ftp tests should be even more affected as medusa relies on asyncore which use select)
<vila> the fun thing is that when I saw the bug report and look at the code I wondered why the settimeout was before the lock release... so I tried that first... it worked
<vila> poolie: does that sound convincing ?
<poolie> enough for me
<vila> ok
<poolie> abentley, i got a reply to my request to install python-kid on the machine that serves bazaar-vcs.org
<poolie> apparently it's hard because that machine runs dapper and kid is not in dapper
<poolie> so our options are
<poolie> - just live without it
<poolie> - try to install kid from source
<poolie> (not sure if there would be other problems)
<poolie> - something else, like building the docs elsewhere and uploading them
<abentley> I did have Kid installed from source on dapper, and had no trouble with that.
<abentley> But if this is going to be a big problem, maybe we should look at another way of building pretty docs.
<abentley> I just don't want to invent a new template language.
<poolie> heh
<poolie> yeha
<poolie> i mean, yeah
<ubotu> New bug: #140834 in bzr "too many futex syscalls" [Undecided,New]  https://launchpad.net/bugs/140834
<abentley> Realistically, I guess we can look into what docutils provides by way of customization.
<poolie> maybe that would be cleaner
<poolie> if you think i should install kid and it will work i'm happy to do that
<abentley> I'd be surprised if it didn't work.  It depends on how comfortable you are with having software on that machine not managed by apt[itude] .
<poolie> personally i'm fine with it
<poolie> it's more that sometimes you get into a rabbithole of missing dependencies
<abentley> I installed kid with easy_install, as part of TurboGears.
<abentley> It appears to have no dependencies, but if the install becomes painful, we can try a different approach.
<fullermd> Hm.  There's a port of it.
<fullermd> It lists the dependancies as python, py-setuptools, and py-elementtree
<abentley> 0.9.6 no longer requires elementtree, AIUI.
<fullermd> This is 0.9.5, so that could be
<fullermd> Anyway, you got elementtree around for bzr anyway, so it doesn't matter.
<abentley> Yes, that was a change in 0.9.6
<ubotu> New bug: #140844 in bzr ""bzr log --line --verbose" does not work" [Undecided,New]  https://launchpad.net/bugs/140844
* igc food
<spiv> lifeless: abentley's reconcile doesn't introduce that corruption when run on a hand-fixed repo.
<lifeless> spiv: can you confirm that it does not fix it either ?
<spiv> lifeless: sure, give me ~20 min.
<Stevage> hey guys, what does this mean: bzr: ERROR: Permission denied: u'C:/bzr/Tlib62/.bzr/repository/lock/held': [Error 5]  Access is denied
<lifeless> well
<lifeless> it means that either th elock or unlock failed
<lifeless> your bzr trace file (run bzr --version to see where that is) will have a traceback
<lifeless> is that dir readonly for you?
<lifeless> do you have write access to it ?
<Stevage> yeah, this is during a massive sequence of commits
<Stevage> so like 300 commits in a row succeeded, then that one failed
<fullermd> Sorry, the trial version only allows 300 commits per day.  You can upgrade for $39.95...
<Stevage> ok I have the traceback
<Stevage> :)
<poolie> that reminds me of a bug alexander posted about recently
<spiv> lifeless: confirmed: abentley's reconcile doesn't fix the corruption.
<Stevage> http://rafb.net/p/PAed8E45.html
<poolie> i think i merged something for that
<spiv> Now to fix that.
<lifeless> spiv: I think you have a new test case for his check and reconcile work then :)
<lifeless> spiv: its good to know that it doesn't introduce it.
<lifeless> now, WTF does.
<spiv> lifeless: good question!
<poolie> Stevage: are you using 0.91rc?
<Stevage> no, .09
<Stevage> .90
<Stevage> I did download .91rc2 but I wasn't sure how to merge my changes into it?
<poolie> Stevage: did you make your changes in the downloaded-from-tarball tree?
<poolie> Stevage: i'm not 100
<poolie> Stevage: i'm not 100% sure but i think this is fixed in 0.91
<Stevage> no I haven't
<Stevage> is there a way to merge my changes in .90 to the .91 ver?
<Stevage> I mean, I know I can do it by hand, but I'm curious whether i can merge it?
<ubotu> New bug: #140857 in bzr ""bzr: interrupted" should say where it was interrupted" [Wishlist,New]  https://launchpad.net/bugs/140857
<ubotu> New bug: #140858 in bzr "when selftest is interrupted, it should show the results of all	tests so far" [Medium,New]  https://launchpad.net/bugs/140858
* spiv -> food
<lifeless> 
<lifeless> real    1m27.526s
<lifeless> user    1m20.481s
<lifeless> sys     0m4.476s
<Stevage> ok, done. is there a way to precompile my python source so it runs faster each time?
<poolie> Stevage: that should happen automatically by producing .pyc files
<poolie> as long as the directory is writable
<Vantage13> hi, i'm a little confused about bzr-cvsps-import.   I did an import using 0.18 or bzr and it created a bzr and a staging directory, but I thought it would also checkout the files from CVS.  From what I can see, none of the actually files are there.  There is however, the a directory structure based on the branches, etc...
<lifeless> Vantage13: right, you can bzr checkout any of teh branches the converter created
<Vantage13> lifeless: really?   Where will it get the files from?  CVS?
<fullermd> No, from the bzr branches it just converted.
<fullermd> They're there, they just don't have working trees.
<Vantage13> fullermd: wow, that's quite cool.  Thanks!
<Stevage> hmm, same problem: bzr: ERROR: Permission denied: "C:/bzr/Tlib63/.bzr/repository/lock/held": [Error 5]  Access is denied
<Stevage> that's running on .91rc2
<Stevage> wait, actually that's 0.92.0dev0
<lifeless> whats the backtrace look like ?
<Stevage> like the one I pasted earlier, if you have ti
<lifeless> no, I don't
<Stevage> http://rafb.net/p/FJ0j5K59.html
<Stevage> (that's fresh)
<lifeless> I wonder if there is a fileopen withint that path ?
<lifeless> could you please file a bug, including what you are doing to trigger this
<lifeless> we care about windows, and its almost certainly a windows specific glitch
<Stevage> ok
<Stevage> hard to say what I'm doing specially though
<lifeless> well
<Stevage> I'm doing hundreds of commits, then it just falls over
<lifeless> just note that you are doing X commits in y timeframe
<Stevage> sure
<lifeless> are you using bzrlib or the bzr executable
<Stevage> bzrlib
<Stevage> both .90 and .92
<lifeless> if you are using bzrlib, can you provide the script you are using
<Stevage> oh, I mean I'm calling bzr from python
<lifeless> it may be a articular sequence of calls neded to trigger this
<Stevage> so I guess I mean bzr
<lifeless> if you do system('bzr foo bar baz') you're not using bzrlib :)
<lifeless> or subprocess.foo('bzr' , ....)
<Stevage> heh
<Stevage> it's a bit more esoteric than that
<Stevage> I'm using a tool called finalbuilder
<lifeless> igc: got the mail?
<igc> lifeless: yes thanks
<igc> I'll try it now
<ubotu> New bug: #140869 in bzr "Access denied for lock file" [Undecided,New]  https://launchpad.net/bugs/140869
<igc> lifeless: results on my machine emailed back now fyi
<lifeless> thanks!
<lifeless> of home time
<lifeless> spiv: hows it going, do you need an input from me ?
<sri> yo
<lifeless> sri: yoyo
<lifeless> sri: I'm about to go, but if you wanted to chat with me I'll be online in an hourish.
<lifeless> spiv: ring if you want to chat about why its not finding the corruption
<lifeless> ciao
<vila> rats, miss lifeless
<vila> I just saw his request to martin about cherrypicking a change into a not-corrupted bzr.dev
<vila> does that mean we should do that for all pqm submissions until further notice ?
<Stevage> can I copy a file within bazaar?
<Stevage> as in, I have a file proj1/foo/blah.c  and want to copy it with history to proj1/boo/blah.c
<Stevage> anyone?
<fullermd> No, there isn't any such thing.
<Stevage> bugger
<Stevage> so you can do a rename like that, but not a copy
<fullermd> Yeah, you can move files, but there's no copy.
<fullermd> Aside from the lack of round tuits, it's a wide-open question what the proper semantics of copy should be in various situations (particularly merges), which is why there isn't one.
<Stevage> hmm
<Stevage> I can see it's going to take me a while to get used to directory-based version control
<lifeless> vila: not 'not corrupted', 'fresh - without packs in it'
<Stevage> the tool I'm migrating from is all file-based
<lifeless> Stevage: we're planning on copy semantics as an optional thing in the future.
<vila> lifeless: pfew, good, sry for the noise :)
<lifeless> Stevage: there is wide spread debate on what this means
<lifeless> Stevage: one way is to consider the whole project a big bag of lines and get rid of file id except for grouping lines into paths
<lifeless> another is to have a more flexible id system that can represent copies as we as moves
<fullermd> I've occasionally wished for copies as a way of simulating intra-branch branch/merge'ing.
<Stevage> intetresting :)
<Stevage> I'll have to subscribe to the list
<Stevage> cya everyone
<cory> I was a bit surprised that I can't seem to easily produce a diff or even list changed files between two branches, but it looks dead simple to do it with bzrlib.  Am I missing something?
<fullermd> -rbranch: or -rancestor:?
<cory> Can I do that with two remote branches and no working trees?
<fullermd> I don't think so, but that's a bug.
<fullermd> I vaguely recall that both diff and stat beg after WT's when they have no need of them.
<cory> Ah, ok.
<cory> Regardless, Branch.open("foo").basis_tree().changes_from(Branch.open("bar").basis_tree()) seems to give me precisely what I was hoping for. :)
<igc> night all
<lapthrick> howdy
<lapthrick> mathrick@hatsumi:~/Dev$ bzr get svn://svn.gna.org/svn/pokersource/trunk bzr-pokersource
<lapthrick> bzr: ERROR: libsvn._core.SubversionException: ('Malformed network data', 210004)
<lapthrick> bzr 0.90.0 on python 2.5.1.final.0 (linux2)
<lapthrick> http://pastebin.com/f1d0ed055 has the full backtrace
<lifeless> lapthrick: I'd file a bug or question on bzr-svn
<mtaylor> does anyone know of anything for making bzr work with quilt? Or a bzr project to do something similar?
<Kinnison> In what sense? Maintaining a quilt in a bzr branch? maintaining a branch for each patch of a quilt?
<mtaylor> Kinnison: I think more like maintaining a quilt in a bzr branch. one of my friends uses quilt on top of bk, but I was thinking it might be nicer if something like that was integrated with bzr or something
<lapthrick> mtaylor: I think parts of quilt functionality are already provided by shelve, no?
<mtaylor> lapthrick: yes. I think that some of them are, but I'm not sure if you can cherry pick from shelve, can you?
<lapthrick> I believe so, AFAIK it does provide you the named changesets function, which is what's needed for cherrypicking
<mtaylor> lapthrick: hmm. I'll go play with that then and see
<lapthrick> "You can put multiple items on the shelf. Normally each time you run unshelve the most recently shelved changes will be reinstated. However, you can also unshelve changes in a different order by explicitly specifiying which changes to unshelve. This works best when the changes don't depend on each other."
<lapthrick> mtaylor: from bzr shelve --help
<jelmer> lapthrick: please file a bug report against bzr-svn
<lapthrick> jelmer: will do as soon as I wrangle launchpad into resetting my password
<lapthrick> which it insists on not doing
<jelmer> Looks like I can reproduce it here
<jelmer> but the server isn't responding properly
<jelmer> even with stock svn
<jelmer> svn ls svn://svn.gna.org/svn/pokersource
<jelmer> gives the same error
<lapthrick> oho, finally
<lapthrick> jelmer: however, my svn did checkout without any problems
<lapthrick> maybe something changed since then
<lapthrick> it was last Friday I believe
<jelmer> lapthrick: Your SVN checkout doesn't access the root of the repository (svn://svn.gna.org/svn/pokersource)
<jelmer> which is the bit that is causing problems
<lapthrick> ahh
<lapthrick> jelmer: but I was checkouting trunk/
<jelmer> bzr-svn will try to look at the repository root because it tries to retrieve the history of the repository
<lapthrick> I see
<lapthrick> so it's NOTABUG?
<lapthrick> and/or NOTGNOME
<jelmer> NOTBZR you mean? :-)
<jelmer> I do think it's a bug - bzr-svn should be able to avoid connecting to the repository root
<jelmer> at least over some protocols
<lapthrick> jelmer: yes, but it's usually NOTGNOME where I come from, so it's a generic "not my problem" status :)
<lapthrick> jelmer: I see, but how can you retrieve history then without looking at the root?
<lapthrick> you mean it'll only look at the history of the dir specified?
<jelmer> lapthrick: there are workarounds - for example, it should be possible to connect to svn://svn.example.com/foo/trunk but then request the log for ".." or "/"
<jelmer> the behaviour of the get_log() call in svn differs per protocol (svn://, http://, svn+ssh://) though, which is why we try to avoid that at the moment
<jelmer> I think the extra code complexity is worth it, if it means we can support the pokersource repository
<lapthrick> jelmer: I see
<lapthrick> jelmer: hmm, svn ls worked for me right now
<lapthrick> can you retry?
<jelmer> hmm, now it works for me too
<lapthrick> mathrick@hatsumi:~$ svn --version
<lapthrick> svn, version 1.4.4 (r25188)
<lapthrick> but bzr still dies
<jelmer> is that server perhaps under heavy load or something?
<lapthrick> dunno
<lapthrick> http:// worked though
<lapthrick> I will retry with svn:// once it finishes
<lapthrick> mathrick@hatsumi:~$ svn ls svn://svn.gna.org/svn/pokersource
<lapthrick> svn: Can't read from connection: Connection reset by peer
<lapthrick> jelmer: I guess it might be the server at fault
<lapthrick> copying revision  320/2895
<lapthrick> oh man, that's not gonna be fast
<jelmer> lapthrick: at the moment we have to fetch all historical changes. work has started to make it possible to fetch only the last few revisions
<lapthrick> jelmer: isn't it kind of necessary to fetch the whole history to have a real bzr branch?
<jelmer> lapthrick: it is possible to do "lazy" fetching - in other words, not fetch anything until the user is trying to access it
<lapthrick> I see
<AfC> jelmer: [how do you do that?] 
<AfC> [oh, sorry, you're talking about bzr-svn. I thought you meant Bazaar itself] 
<jelmer> AfC: This is true for Bazaar itself as well
<jelmer> AfC: The idea is to make it possible to fetch just the last few revisions of a branch and store a pointer to another branch that contains more of that history
<AfC> jelmer: how do you do that, then? Is there a --lightweight option to `bzr branch` as well?
<Vantage13> Hi, I'm using bzr 0.18 w/ bzr-cvsps-import to try and import a large CVS repo, but I keep getting memory errors.  Any way around this?
<jelmer> AfC: It's not possible yet - these are the stackedrepository / shallow branches specs
<AfC> jelmer: ah. I have envisaged a modality whereby the commit messages etc were there (ie, you could run `bzr viz`) but the actual deltas between revisions wouldn't be present unless [able to be]  fetched [on demand, or silent error] 
<jelmer> AfC: something like that could be done easily once the shallow branch / stacked repository code is in
<jelmer> AfC: but it may involve doing things like caching diffstats for "bzr log -v'
<AfC> jelmer: I was more thinking "sorry, diff not available" ... where I was really going with this was trying to avoid the necessity to download / push massive amounts of revisions especially of large code drops that subsequently got deleted before merging
<AfC> [this happens a lot for us] 
<AfC> [but if I accept the revisions, they're full of all the crap I subsequently expunge, thus traffic] 
<fullermd> It strikes me that some sort of graft/rebase is probably the better solution to that problem...
<jelmer> AfC: Ah, I see. It should be possible to set a policy as to what bzr should do if a revision is not available in the branch itself - fetch it or consider it a ghost.
<TeTeT> how well does bazaar cope with binary files, e.h. PNGs?
<radix> TeTeT: well enough that I've never noticed any problems
<radix> I've heard rumors that its binary delta algorithm isn't efficient or whatever, but it doesn't concern me
<gabe__> i have tens of websites in a bzr repo, they have all manner of binary files, work a treat for me
<TeTeT> radix: thx, should be fine with small pngs then
<TeTeT> I once run into trouble with some very large files, 10+ MB
<TeTeT> but this was an older version, I think 0.13 or so
<corporate_cookie> I'm more curious than anything..how dose BZR handle binaries ?
<corporate_cookie> the way i understand it ..bzr stores ...sort of a recipe of changes between versions ...it dose not actually store files them selves but rather the instructions to build those files
<corporate_cookie> how would this work with a Binary file / a non text based file
<radix> corporate_cookie: so, there's an algorithm for efficiently representing differences between text files
<radix> corporate_cookie: there's also an algorithm for representing differences between "binary" files, which doesn't rely on newline markers
<fullermd> Is there?
<radix> google for "binary delta" and "binary diff" :-)
<corporate_cookie> radix:  ..how slow / useful is this algorithm ...practically
<corporate_cookie> ok : )
<fullermd> Oh, I'm aware that there _are_ such algorithms.  I was questioning the part where it had anything to do with bzr at the moment.
<radix> oh, I don't know
<radix> I was responding to the general question about "how would this work"
<lapthrick> corporate_cookie: ..why ...are ...you ...talking ...like ...this?
<fullermd> I'm pretty sure that in bzr it works just like text files.
<corporate_cookie> lapthrick:  dramatic pauses make life more spicy
* radix eats some basil
<corporate_cookie> Captain Kirk
<corporate_cookie> ...it worked ... for ...him
<mvo> lifeless: hello! I'm playing with bzr-git currently and it seems to not like me currently: http://paste.ubuntu.com/293/ . am I missing something here?
<AnMaster> is there anything like $Id$ of svn for bzr, would be helpful for my app to be able to output what revision it is from with --version
<AnMaster> or branch + revision perhaps
<jelmer> AnMaster: No, not yet - there are plans to add support for such keywords, but it hasn't been implemented yet
<AnMaster> ah, it would make support a lot simpler
<jelmer> AnMaster: the specification for that feature is at https://blueprints.launchpad.net/bzr/+spec/bzr-keyword-expansion
<jelmer> mvo: I think bzr-git has bitrotted recently, think it just needs to be updated to be compatible with more recent versions of bzr
<lapthrick> CVS keywords have always bugged me, I have instinctive dislike for anything that's not data-transparent
<AnMaster> hm
<AnMaster> I don't use CVS so I don't know, but I use svn and bzr
<jelmer> lapthrick: yeah, same here. at least svn requires you to explicitly enable them
<AnMaster> and it is quite useful to have for --version output on one file with svn
<lapthrick> AnMaster: yeah, but CVS quite excelled at having non-transparent features enabled by default
<AnMaster> lapthrick, ah that sounds bad
<lapthrick> and then you had to disable them for each and every file by hand
<lapthrick> woe was you if you forgot to disable linebreak conversion on a binary file or something
<AnMaster> what is the best software to do something like viewvc/viewsvn for bzr?
<lapthrick> AnMaster: there's bzr-web or what was its name
<AnMaster> easy to set up on server preferred
<AnMaster> server runs lighttpd on freebsd
<jelmer> loggerhead
<lapthrick> http://goffredo-baroncelli.homelinux.net/bazaar
<AnMaster> hm?
<AnMaster> jelmer, and link to loggerhead? and is it easy to set up?
<AnMaster> I do not have root access on the server, but I can run python, php and perl scripts on it
<lapthrick> http://www.lag.net/loggerhead/
<lapthrick> (was not overly easy to google)
<jelmer> http://www.lag.net/loggerhead/
<AnMaster> any online docs for it? can't find that on it's page
<jelmer> whoops, too late :-) I was having trouble with google as well
<mvo> jelmer: yeah, it looks like it. I played around with the code a bit, but it seems like there are too many changes for me
<jelmer> AnMaster: There's the README.txt in the source tarball
<AnMaster> ah *reads*
<AnMaster> looks like it need to run a bg process and needs proxy stuff in web server config? that I can't do
<AnMaster> I can run python, php and perl by fastcgi
<AnMaster> but I can not change web server config
<AnMaster> jelmer, so it looks like that doesn't work?
<jelmer> It's a standard turbogears app, maybe there's some way to use that inside apache?
<lapthrick> its own loggerhead install seems to be down
<AnMaster> jelmer, it is lighttpd, not apache
<AnMaster> but well I'm not good at python that this seems to be
<abadger1999> AnMaster: We've run TG stuff as mod_python in Fedora before.
<abadger1999> It wasn't a good experience but fastcgi might be better.
<AnMaster> abadger1999, hm ok, anything special needed?
<abadger1999> Looking for some documentation on the web right now...
<abadger1999> AnMaster: http://tools.cherrypy.org/wiki/FastCGIWSGI
<abadger1999> TurboGears uses CP2.2 under the hood so the 2.2 instructions there should be pretty good.
<AnMaster> abadger1999, hm, this looks apache centric. again
<abadger1999> There's lighttpd setup on that page.
<AnMaster> ah *scrolls down*
<james_w> mvo: I don't think bzr-git ever worked for branching. I think the best you could do was history exploration.
<mvo> james_w: aha, ok. I will just have to look into git then I guess. I was trying to avoid it :)
<james_w> jelmer: do you have a local override for export-upstream in your bzr-svn branch?
<jelmer> james_w: no, not all
<jelmer> james_w: why?
<james_w> just wondering. It would be more efficient. You wouldn't have to hit the network to export the tarball.
<jelmer> well, bzr-svn merges upstream every now and then so all the revisions are already available locally
<jelmer> the exporting step takes just a few seconds when I run `bzr builddeb`
<james_w> that's good.
<james_w> jelmer: did you see my reply to your bug?
<jelmer> no, not yet - when was it sent?
<jelmer> never mind, just got it
<james_w> jelmer: any thoughts? I was hoping you would say "what about..." and all would become clear.
<jelmer> james_w: will reply in a sec
<james_w> jelmer: thanks.
<lapthrick> bah
<lapthrick> bzr shell forgets "ls"
<lapthrick> as in, bzr ls, it only has the system ls
<lifeless> lapthrick: /usr/bin/ls
<lapthrick> lifeless: nono, I do have /usr/bin/ls available
<lapthrick> it's bzr ls that's missing
<lifeless> oh I see
<lapthrick> well, okay, I stand corrected. I don't have /usr/bin/ls, I have /bin/ls :)
<alxgsv> Hello
<alxgsv> i want to ask if there a way to solve my problem
<alxgsv> bzr via proxy
<alxgsv> http_proxy="login:password@ip:port" doesnt work
<lifeless> abentley: ping
<lifeless> mvo: yo
<ubotu> New bug: #141026 in bzr-pqm "pqm-submit does not check for uncommitted changes" [Undecided,New]  https://launchpad.net/bugs/141026
<Lo-lan-do> Good evening/morning/day/night all
<alxgsv> hi )
<Lo-lan-do> As I've been engaged in other activities lately, and didn't follow bzr-svn development closely, I was wondering if there had been any changes in there.
<Lo-lan-do> Hmm.  There's one log entry that seems promising: "Handle pushing merges of which LHS parent is older revision of branch path."
<jelmer> Lo-lan-do: yeah, I think that fixed one of the bugs you hit
<Lo-lan-do> I'll give it a try right away.
<lapthrick> jelmer: btw, bzr-svn is , finally I don't have to worry about stupid shit like not having write privileges for some kinda package I happen to be working with
<lapthrick> make it faster on checkouts and it will be unstoppable
<Lo-lan-do> I concur emphatically.
<Lo-lan-do> (On both points, alas ;-)
<lapthrick> a friend is playing with hgsvn right now
<lapthrick> so far, it seems to be very fast
<jelmer> thanks, great to hear
<lapthrick> but I dunno about usablility
<Lo-lan-do> Ah, yes, there was the problem about an svn property that had been corrupted.
<lapthrick> jelmer: also, it's quite remarkable that for a 15MB source tree with 2895 revs bzr-svn eats only 47MB, whereas a plain SVN checkout needs 38MB
<jelmer> Lo-lan-do: The bug that caused that has been fixed
<jelmer> so it won't corrupt your repository again
<jelmer> are you still getting the error about the property?
<Lo-lan-do> I just got the following:
<Lo-lan-do> Using saved location: svn+https://svn.gforge.org/svn/gforge/trunk
<Lo-lan-do> bzr: ERROR: exceptions.AssertionError: Revision id lolando@debian.org-20070831143537-22lpbh2js43vt97j was added incorrectly
<jelmer> lapthrick: svn always has two copies of each file - the working copy you can edit and an backup copy it uses do to local diffs
<Lo-lan-do> I suppose I needed to fix the SVN repo before pushing, so I'm now looking in my emails for the value that shouldn't have been removed from the property.
<Lo-lan-do> jelmer: Does the order of the lines in the bzr:revision-id:v3-trunk0 property matter?
<lapthrick> jelmer: yeah, but the point is that bzn stuffs 2895 times as much history into barely 40% more space
<jelmer> Lo-lan-do: bzr-svn looks at diffs and assumes there is only one line added per commit
<lifeless> lapthrick: hgsvn doesn't seem to have the ability for different people to interoperate as easily
<jelmer> lapthrick: nice, I missed the bit about the number of revs (-:
<lifeless> lapthrick: its more like a better svn client, than about actual full blown interoperation
<lifeless> lapthrick: with bzr-svn people can push into svn and back out again losslessly
<lapthrick> lifeless: I see, so hgsvn just pulls, but can't push?
<lifeless> it uses a single directory that has both .svn and .hg dirs
<lapthrick> jelmer: as an aside, it's a bit strange, the current rev in that repo is 3402, but bzr-svn reports pulling 2895
<lapthrick> lifeless: ahh, so it's up to you to keep them in sync
<lifeless> lapthrick: basically its a set of scripts to help you keep them synced
<jelmer> lapthrick: svn's revnoss are repository-based, bzr's revnos are branch-based
<Lo-lan-do> I suppose the 507 missing revs are in other branches.
<lapthrick> I see
<lifeless> whereas bzr-svn migrates the data, flagging it in bzr as coming from svn, and allowing smart merges with svn whether or not you were the original converter
<Lo-lan-do> bzr: ERROR: exceptions.AssertionError: Revision id lolando@debian.org-20070831143537-22lpbh2js43vt97j was added incorrectly
<Lo-lan-do> :-(
<jelmer> Lo-lan-do: what did you change specifically/
<jelmer> Lo-lan-do: (to try and get it fixed?)
<Lo-lan-do> http://lists.gforge.org/pipermail/gforge-commits/2007-September/000550.html
<jelmer> we may need a bzr-svn fix to get it to deal with these broken commits correctly
<lapthrick> can bzr-svn convert an existing checkout yet>
<lapthrick> ?
<jelmer> lapthrick: how do you mean?
<jelmer> lapthrick: like 'bzr upgrade' in a svn checkout?
<lapthrick> jelmer: I did svn co svn://some/package
<lapthrick> can I now cd package; bzr branch . or something?
<Lo-lan-do> jelmer: You told me the other day that a push I did replaced the property with a new value, instead of appending the new revid, so I tried to restore the old revid
<jelmer> Lo-lan-do: bzr-svn doesn't look just at the contents of the revid property but also at the diffs
<jelmer> Lo-lan-do: you could make a local copy of that repository and try to remove that property completely and then try the push again
<Lo-lan-do> Hm.  Is it possible to slurp a remote SVN repository and recreate it locally?  I don't have direct access to the repo...
<lifeless> lapthrick: you mean to do an inplace conversion from a svn checkout to a bzr checkout ?
<lapthrick> yeah
<lifeless> I don't know if it can.
<lapthrick> jelmer probably does :)
<jelmer> it can if it's running a recent version of subversion
<lapthrick> is 1.4 recent?
<lapthrick> jelmer: and how would I go about doing it? bzr branch . ?
<jelmer> lapthrick: sorry that was an answer to Lo-lan-do
<lapthrick> ahh
<jelmer> lapthrick: you can't upgrade a svn checkout in-place
<jelmer> but you can do something like 'bzr branch svn-wc-dir bzr-branch-dir'
<lapthrick> jelmer: aha, and it will pull all the history, or will it rather defer until it's actually needed?
<jelmer> lapthrick: it will pull all history - there's no way around that until bzr supports shallow branches
<lifeless> which jelmer is working on :)
<jelmer> Lo-lan-do: the gforge repo doesn't seem to support syncing
<lapthrick> mathrick@hatsumi:~/Dev/rails$ bzr branch pokerolymp/ bzr-pokerolymp
<lapthrick> bzr: ERROR: Not a branch: /home/mathrick/Dev/rails/pokerolymp/
<lapthrick> jelmer: doesn't seem to work, I guess I'll just pull another copy via net
<Lo-lan-do> Damn.
<Lo-lan-do> I'll try deleting the property then, shall I?
<jelmer> Lo-lan-do: yeah - that should work, if you remove the local bzr-svn cache
<jelmer> (~/.bazaar/svn-cache/6d150e1c-e21c-0410-8b89-9ee68aed362b)
<Lo-lan-do> Right.  propdel committed (through svn), now waiting for the bzr merge to complete (seems to be rather slowed down by the lack of cache :-)
<lapthrick> jelmer: apparently bzr-svn hates https :(
<lapthrick> which makes it pretty hard for me to use it for my job repo
<jelmer> lapthrick: why, what error are you getting?
<lapthrick> KeyError: 77
<lapthrick> jelmer: want a full backtrace?
<jelmer> lapthrick: what version of bzr-svn are you using?
<jelmer> lapthrick: if you're using 0.4.x, please file a bug report - that's a serious bug
<lapthrick> jelmer: dpkg reports 0.4.1-1
<jelmer> lapthrick: is this a public branch you're trying to copy?
<lapthrick> no
<lapthrick> it's authenticated
<lapthrick> jelmer: is that supported?
<jelmer> lapthrick: yes, it uses the svn auth cache
<jelmer> in other words, if you have authenticated against that repository using svn earlier, it should work
<lapthrick> jelmer: then svn has no problem at all with checking out
<lapthrick> it didn't ask me for the password
<jelmer> lapthrick: could you post the backtrace in a bug report on launchpad ?
<sri> lifeless: naw, no chat as of yet :)  Just hanging out for now
<lifeless> :)
<Lo-lan-do> Progress!
<Lo-lan-do> bzr: ERROR: libsvn._core.SubversionException: ("File '/svn/gforge/trunk/gforge/debian/po/de.po' already exists", 175005)
<Lo-lan-do> A different error :-)
<Lo-lan-do> Should I remove the bzr:file-ids property on that directory too?
<jelmer> Lo-lan-do: ah, yes
<Lo-lan-do> Lots of network activity happens, and the command seems to take longer than previously.
<Lo-lan-do> So even if it eventually fails, it'll have failed at a later stage :-)
* jelmer doesn't see any new commits on the branch yet
<Lo-lan-do> It's still computing.
<jelmer> if you run it with -Dcommit -Dtransport it will write information to ~/.bzr.log
<Lo-lan-do> Ah, damn.  Failed again, still with bzr: ERROR: libsvn._core.SubversionException: ("File '/svn/gforge/trunk/gforge/debian/po/de.po' already exists", 175005)
<Lo-lan-do> (After 18 minutes)
<jelmer> Lo-lan-do: can you run with -Dcommit -Dtransport and try to push again?
<Lo-lan-do> Yep.
<Lo-lan-do> http://paste.debian.net/37562
<jelmer> Lo-lan-do: thanks
<lapthrick> boo
<lapthrick> rspush is not working
<jelmer> Lo-lan-do: Looks like it's trying to push those changes again that caused the error earlier
<lapthrick> bzr bzr-pokersource:2900/> rspush mimi.imada.sdu.dk:/home/makat05/WWWpublicUnhandled error:
<lapthrick> Unknown status: 255
<lapthrick> are there any glaring errors you can see?
<jelmer> Sorry, I never use rspush
<jelmer> lapthrick: is rsync installed on the remote host and local machine?
<lapthrick> local yes
<lapthrick> hmm
<lapthrick> I think the problem was with SSH auth
<lapthrick> cause plain push to sftp:// displayed that BIG SCARY WARNING about fingerprint having changed
<jelmer> Lo-lan-do: What version are you running 0.4.3 or 0.4 from bzr?
<Lo-lan-do> 0.4.3 so far
* Lo-lan-do tries again with bzr
<Lo-lan-do> jelmer: Same error, full log in http://paste.debian.net/37564
<abentley> lifeless: pong
<jelmer> Lo-lan-do: I'll do some more analysis later this week and see if I can get it fixed
<jelmer> Lo-lan-do, is the branch you're trying to push available somewhere
<jelmer> ?
<lifeless> abentley: could I ask you to review my 'dont propogate index changes' patch, not so much from 'is the code ok' as its mainly deletes, but from 'is this the right approach'
<Lo-lan-do> jelmer: Would it be likely to help (as a temporary workaround) if removed the problematic files from SVN, then pushed, then re-added them if needed?
<lifeless> abentley: also spiv has confirmed your reconcile neither creates the problem, nor fixes.
<lifeless> abentley: so hes modifying it to detect and correct.
<jelmer> Lo-lan-do, it's not the files that are problematic, it's bzr-svn's view of history
<abentley> lifeless: cool.
<jelmer> Lo-lan-do, it's trying to push that broken revision again
<lifeless> jelmer: how to repair it ?
<lifeless> oh, need to analyse, sorry.
<abentley> lifeless: one thought I had was that perhaps these discrepancies should trigger something like the reconcile code.
<Lo-lan-do> What I'm trying to push is basically a merge of http://alioth.debian.org/~lolando/bzr/gforge/debian/sid into the bzr-svn branch
<abentley> So that you don't pull bogus parent updates, but do pull valid parent updtes.
<lifeless> abentley: the current propogation was a cheap 'fix on the fly' approach.
<lifeless> but on consideration its actually bogus - it scales with history
<lapthrick> ShortReadvError: readv() read 591 bytes rather than 4306 bytes at 0 for 2e/1101%40c4f34931-41c7-4605-b615-9bb9f479c57e%253atrunk%253apoker-network%25252%2546pokerweb%25252%2546pages%25252%2546currency.php.knit
<lifeless> because it requires cross checking all parents ever
<abentley> Okay, that might be the gripping hand.
<jelmer> lapthrick, looks like a webserver that's trying to execute all files containing .php
<lifeless> abentley: been reading classic scifi recently ?
<lapthrick> jelmer: ooh
<lapthrick> now that's dumb
<lifeless> lapthrick: yeah, we didn't appreciate how many broken web server rules there were. We've fixed that now
<lapthrick> do you know what .htaccess spell would kill it?
<lifeless> lapthrick: in the next repository disk format.
<lapthrick> lifeless: okay, what format is that?
<lapthrick> is it in 0.90?
<lifeless> lapthrick: no, 0.92 we hope
<lapthrick> bueh
<abentley> No, Murakami lately.  I just like the "gripping hand" extension.
<lapthrick> abentley: Murakami is nice
#bzr 2007-09-20
<lifeless> abentley: IIRC it was pournelle and ??? in 'The mote in gods eye'
<Lo-lan-do> lapthrick:     AddHandler None .knit .kndx
<lifeless> the gripping hand was the big overdeveloped arm, not the fine-tuned hand
<lifeless> oh yes, they did a book called that too
<lapthrick> Lo-lan-do: .htaccess by default is valid for all subdirs unless overrided, right?
<abentley> Yeah, Pournelle/Niven, but I think the "on one hand, on the other hand, on the gripping hand" phrase came from the sequel, "The Gripping Hand"
<Lo-lan-do> Right
<abentley> Anyhow, I'll look the patch over now.
<lifeless> abentley: could be, I don't think I've read the sequel
* lifeless notes to do so
<Lo-lan-do> jelmer: I pushed my gateway branch to http://alioth.debian.org/~lolando/bzr/gforge/upstram-svn/trunk -- it contains the stuff that I'm trying to push to SVN
<Lo-lan-do> I'm off to bed for now, but I'll be available in the next few days to provide info if needed.
<Lo-lan-do> Thanks already for the time you spend on my bugs :-)
<radix> abentley: Do you mean Haruki, Ryu, or Takashi? :)
<abentley> Heh, Haruki.
<radix> (the first three Murakamis that have written books that I can think of)
<radix> ok yeah, figured ;-)
<radix> funnily enough, they're all flaming postmodernists
<abentley> I also read this blog about SCO by Jones.
<radix> that's probably not postmodern :)
<abentley> radix: No, but SCO is a significant author of speculative fiction.
<radix> haha
<lapthrick> is there some more documentation on bugs metadata in bzr?
<lapthrick> help bugs isn't very verbose
<lifeless> there is a document in the docs
<lifeless> doc.bazaar-vcs.org/bzr.dev/en/
<lapthrick> thanks
<lapthrick> is the immutability inherent in the design, or just something to be implemented?
<lifeless> what do you mean
<lapthrick> lifeless: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/bug_trackers.html , section Limitations
<lapthrick> is that limitation supposed to be removed?
<lifeless> not in the short term
<lifeless> the reason its immutable is that its part of the commit
<lifeless> so changing it would involve changing the commit, which is part of history
<lifeless> one can imagine a more complicated system where later commits can 'revert' things, but that hasn't been really designed or discussed at this point
<lapthrick> lifeless: I see, I was reading http://bazaar-vcs.org/Specs/RevisionBugMetadata
<lapthrick> which indeed does discuss that :)
<lifeless> well
<lifeless> in terms of concrete goals
<lifeless> there are no patchs, nor folk hacking on, the more complicated sorts of things
<lifeless> so far no one has needed them
<lapthrick> aha
<lifeless> igc: call ?
<igc> yep - 10 mins
<igc> lifeless: you at home?
<abentley> lifeless: I don't think _apply_delta is unused.  I think the reason nothing else needed to be changed is that static methods can be invoked on instances as well as on classes.
<lifeless> abentley: true enough, still leaves it as a no-op change though
<lifeless> robertc@lifeless-64:~/source/baz/test-repos/mozilla$ time ~/source/baz/repository/bzr commit -m 'commit' --unchanged -q
<lifeless> 
<lifeless> real    0m58.889s
<lifeless> user    0m50.591s
<lifeless> sys     0m3.640s
<lifeless> robertc@lifeless-64:~/source/baz/test-repos/mozilla$ time ~/source/baz/repository/bzr commit -m 'commit' --unchanged -q a
<lifeless> 
<lifeless> real    0m27.626s
<lifeless> user    0m25.538s
<lifeless> sys     0m1.504s
<lifeless> 25 seconds to *just* do the overhead of a commit for a single file.
<lifeless> I'm going to target this for a bit
<abentley> It does remove the artificial requirement for a knit instance.
<igc> lifeless: adding staticmethod is a good change iff semantically it has nothing to do with the current object
<igc> that's certainly the case in terms of the implementation fwiw
<lifeless> abentley: this is true, but it also makes it unvariable when you have a knit. I think moving it closer to the users would make sense.
<lifeless> rather than just bit-twiddling
<lifeless> I mean, applying a delta would seem to be be related to the delta representation
<lifeless> and/or the content representation
<abentley> How do you mean unvariable?
<lifeless> well object methods are mainly to allow code to vary based on the content of the object
<lifeless> if this method has no dependencies *in principle* on the content of the object, then its probably on the wrong object
<abentley> I'm with you there.
<igc> so the params are lines and delta ...
<igc> it operates on lines and returns lines
<lifeless> igc: if delta is returned by another method on the VersionedFile, then delta is linked to the VersionedFile
<lifeless> igc: so its not clear from this level of discussion that there is no connection
<lifeless> anyhow, I've said my bit
<abentley> lifeless: But it's trivial to imagine an implementation of iter_file_versions directly on top of packs, using knit deltas.  And that would clearly have no need for a versionedfile of any kind.
<lifeless> abentley: I agree. However it could sensibly use a KnitData instance
<lifeless> there is delta assembly too
<lifeless> so being able to use a single KnitSomeThing instance to manage that implementation would be good
<lifeless> something that takes (fileid, revisionid) keys and uses the index directly without the mapping thunk layer
<abentley> Yep, we're agreed there.
<thumper> lifeless: know where poolie is?
<lifeless> thumper: yes
<abentley> I think the reason we don't have something like that already is that knit deltas are not objects.
<lifeless> abentley: well there is KnitData/KnitContent.
<lifeless> abentley: I'm not sure that individual delta objects are the problem
<lifeless> its more that the delta application stuff was conflated with storage.
<lifeless> KnitData vs KnitAccess has fixed that
<thumper> lifeless: sometimes you remind me of a friend in the UK (never answered the implied question)
<lifeless> thumper: I'm proud to remind you of a friend :)
<lifeless> thumper: oh, and merf says hello
<thumper> merf who?
<lifeless> michael murphy
<lifeless> from uni
<abentley> KnitData looks more akin to ContainerReader.  KnitContent looks plausible.
<thumper> lifeless: ah, where is he now?
<lifeless> Sydney
<thumper> doing?
<lifeless> we had Jason's bucks night last weekend
<thumper> cool
<thumper> it go well?
<lifeless> oh, hes running something in the money market space for commbank
<lifeless> yah
<igc> abentley: so is moving _apply_delta into knit.py (and out of versionedfile.py) agreed as an improvement?
<spiv> lifeless: I think that qeebo revision of yours is definitely strange.
<lifeless> don't have a sound-bite label for it unfortunately, but he's happy and it sounds fun and interesting
<spiv> lifeless: In that the second parent does seem to be in the ancestry of the first parent.
<lifeless> spiv: yah. Want to be a cherrypick merge will do that
<abentley> igc: If we are talking about the optimal place, that looks like it.  I'm also happy with a staticmethod, or the status quo.
<lifeless> *bet*
<lifeless> spiv: try this on for size:
<lifeless> bzr branch -r 2634 bzr.dev foo; bzr merge -r 2591..2592 ; bzr st
<lifeless> spiv: its merging in a revision that was already merged previously, but had had its text discarded
<lifeless> spiv: but even so, the heads() calculation for me gives the right single parent case
<spiv> lifeless: right, but we don't record cherrypicks yet?
<lifeless> its not a cherrypick :)
<lifeless> because the base revision is in the ancesty
<fullermd> Sounds more like a cherryununpick.
<poolie> good morning
<lifeless> hi
<spiv> lifeless: ah, that does indeed create it.  Weird.
<igc> morning poolie
<lifeless> spiv: normal IMO
<lifeless> spiv: its unusual but still a valid DAG
<spiv> (incidentally bzr viz just ignores the second parent for the purposes of drawing lines)
<lifeless> spiv: yes, I wrote that code :)
<lifeless> its the same logic as bzr log uses for indenting
<spiv> lifeless: well, "weird" in the sense that I had thought that "bzr merge -r X..Y" wouldn't record a pending merge, but it turns out the world is more complicated.
<spiv> lifeless: thanks for satisfying my curiosity about that.
<lifeless> :)
<lifeless> np
<abentley> Could this be related to igc's restoration of my patch that jam reverted?
<lifeless> yes
<lifeless> jams patch apparently reverted many things
<lifeless> mine was restored months ago
<lifeless> but I don't think igc could have caused the parent confusion
<igc> revno 2614 was the merge
<igc> fwiw, I used patch -p0 to apply abentley's changes to bzr.dev
<spiv> lifeless: so, what information in the corrupt bzr.dev repo can be used to deduce that file revision has the wrong parents?
<lifeless> spiv: left_parent = r.get_inventory(p1)[fileid] .revision
<spiv> lifeless: did you say InventoryEntry.find_previous_heads figures it out?
<abentley> spiv: My reconcile algorithm ought to determine the correct parents already.
<lifeless> right_parent = r.get_inventory(p2)[fileid] .revision
<spiv> abentley: *nod*.  I want to figure out why it isn't.
<lifeless> correct_parents = r.get_graph().heads([left_parent, right_parent] )
<abentley> spiv: the algorithm is applied only when there are unreferenced parents.
<lifeless> for me, that returns just one
<abentley> This parent is clearly referenced.
<spiv> abentley: ah, I see.
<lifeless> so disabling the condition to only check when its not referenced should be enough
<lifeless> d
<lifeless> hmm
<lifeless> perhaps we should catch UnicodeDecodeErrors and log them, then show a nice user error IFF their locale is C
<lifeless> otherwise raise them as normal
<lifeless> (in run_bzr_)
<abentley> spiv: I have paged the algorithm back into memory.  Ping me if you want a description, but I gather you've already been looking at that code.
<spiv> abentley: thanks, I think I'll be ok, but I'll let you know.
<igc> lifeless: that patch submitted to pqm now
<spiv> Ok, I have a version of Aaron's reconcile that does correct that problem.
<spiv> Now to polish it and test it properly...
<spiv> lifeless, abentley: it's safe to say I understand this stuff much better than I did a week ago...
<abentley> cool
<lifeless> igc: thanks
<lifeless> spiv: cool
<spiv> Boy I wish reconcile gave some progress indication.
<fullermd> Maybe it figures it would just be too depressing.
<spiv> fullermd: I want to know how depressed to be! :)
<spiv> It's the depression with no visible end that gets me down... ;)
<spiv> Good grief reconcile is slow though.
<spiv> I guess NEWS has a particularly large history, but even so...
<lifeless> it spins
<lifeless> just give it some progress figures
<spiv> 20 minutes just to check the NEWS knit.
<spiv> lifeless: FWIW, the reconcile branch http://people.ubuntu.com/~andrew/bzr/reconcile-check-heads
<lifeless> its cooked ?
<spiv> lifeless: it just has the manually tested fix, it's not fully cooked at all.
<lifeless> k
<spiv> lifeless: how urgent is it for you that I cook it now?
<lifeless> if you don't, I'll have to
<lifeless> I can't work with bzr.dev till we apply it there, and uncooked code == buggy
* spiv nods
<spiv> Ok, I'll keep at it.
<ubotu> New bug: #130574 in bzr "Interrupting bzr log causes "bzr crashed with IOError in <module>()"" [Low,Confirmed]  https://launchpad.net/bugs/130574
<fullermd> So, what's the upshot of all of this fribbery with that ancestry lately?
<fullermd> Should I be avoiding updating my bzr.dev, or switching back to the release for my daily work?  Or is it ignorable for us non-devs?
<lifeless> ignore it
<lifeless> we'll fix it and issue a bzr that will correct it all
<fullermd> Sweet.  My favorite problems are those I can ignore   :)
* igc food
<lifeless> poolie_: my fix to not propogate changes has hit bzr.dev.
<lifeless> poolie_: I propose to move pqm to that version asap
<lifeless> not propogate randomish index changes I mean
* spiv -> food
<lifeless> OMG
<lifeless> regular bzr is /so slow/ now :(
<jdong> are you teasing us? :)
<lifeless> not at all
<lifeless> I'm testing a specific optimisation for bzr.dev
<lifeless> and its making me cry
<jdong> ah, I see
<jdong> I read it as "haha, look at me with my faster bzr!" :D
<lifeless> initial commit of a moz tree with my hacked up bzr that I'm peeling off patches is 1m32
<lifeless> with bzr.dev and the patch I'm currently testing it is ... 8m
<jdong> wow, that's a substantial difference
<lifeless> yes
<lifeless> We've been working on performance
<jdong> glad to hear
<fullermd> Is 0.91 due this week, or is it blocked on resolving that ancestry burp?
<lifeless> its due
<fullermd> Cool.
<lifeless> anyhow, thats a clean 4% in that patch
<lifeless> igc: ^
<igc> cool
<lifeless> add_inventory is 20%
<lifeless> update_builder is 37%
<poolie_> fullermd: i'll probably do 0.91 when i get home
<poolie_> just spending some quality time w spiv now
<fullermd> Oh, I was just making sure I was up-to-date with plans.  Not trying to rush you.
<lifeless> ok, of that 25 seconds, I've just nuked 7
<igc> neat
<lifeless> it won't apply to non-selected-file commits unfortunately, but it will make it easier to see hot spots in the code that does apply
<lifeless> care to review that other patch ?
<igc> sure
<lifeless> garh benching on bzr.dev is breaking my balls
<lifeless> ..so.. ..slow..
<lifeless> while this runs I'm going for a wlak to think
<lifeless> woot
<lifeless> 50% saving
<lifeless> real    0m29.516s
<lifeless> user    0m27.594s
<lifeless> sys     0m1.236s
<lifeless> to
<lifeless> real    0m19.251s
<lifeless> user    0m17.897s
<lifeless> sys     0m0.768s
<lifeless> in bzr.dev
<AfC> You're a rock star
<lifeless> well, not *quite* 50%
<lifeless> now to see if it passes tests, and if so send it in
<lifeless> AfC: I know :)
<lifeless> AfC: I have initial commit with packs faster than hg, on my laptop
<lifeless> darn this fails tests, I'll have to tweak it for corner cases.
<AfC> lifeless: Initial commit... I know that's what you've been working on; that's for importing projects into Bazaar, right? [ie, unrelated to initial checkout?] 
<lifeless> AfC: yes, the first experience for folk considering migrating an existing project to bzr
<AfC> Sure
<lifeless> AfC: much of initial commit is present in incremental commit too
<lifeless> so wins there show up in incremental
<AfC> Understood
<lifeless> bbiab
<AfC> lifeless: you _really_ need to take half an afternoon and put something a bit more flattering up as a home page.
<fullermd> Eh, people have been telling me that for years.
<AfC> lifeless: right now it doesn't even _mention_ Bazaar
<AfC> fullermd: yeah, but if I link to Rob in a blog post, it's like embarrassing for him.
<fullermd> They usually phrase it as "Aiee, my eyes are bleeding!", but it means about the same thing...
<Peng> What's lifeless's homepage.
<Peng> ?
<lifeless> to say its bare bones would be to talk it up
<lifeless> AfC: I loath web design; someone who's eyes bleed enough will eventually offer me a new site
<Peng> Mine is completely empty.
<Peng> I just realized what I need to do: 1997!
<Peng> But with valid HTML and CSS.
<Peng> So it's ironic?
<Peng> Anyone got a freely-licensed animated GIF of the U.S. flag?
<igc> lifeless: review sent to the list now
<lifeless> igc: + or - ?
<igc> few changes would be good I think
<lifeless> ok, I'll llook tomorrow
<lifeless> for now I want to get this 40% win polished
<nocturn> Hi all
<nocturn> I'm relatively new to Bazaar and I think I made a mistake
<nocturn> I wanted to branch an existing project to which I only had a source tarball
<nocturn> So I unpacked it in project.vanilla and made that a Bazaar repo
<nocturn> I then created project.mybranch and imported the tarball again
<nocturn> I made my changes on mybranch.  Now I would like to use diff and later merge as the vanilla version gets updates
<nocturn> but mybranch  and vanilla have no common ancestor....
<nocturn> Is there any way to fix this?
<poolie_> nocturn: if you've just done the one change, it may be easiest to do diff -r 1 on mybranch, then apply that through patch to a branch coming from the real import
<poolie_> uh
<poolie_> actually, why not just throw away project.vanilla, and replace it with
<poolie_> bzr branch -r 1 mybranch vanilla
<poolie_> ?
<nocturn> I did multiple changes (3 actual releases of my branch)
<nocturn> poolie_: What would that do exactly?
<poolie_> that would give you a new 'vanilla' branch, containing the import you committed as the first on mybranch
<poolie_> but it would be known to have history in common
<nocturn> OK, and would that still be OK when I use diff and merge since Vanilla is actually the real mainline
<poolie_> right
<nocturn> Ok, trying...
<poolie_> have you done anything else with your original vanilla branch?
<nocturn> no, I didn't touch it.  It belongs to someone else (I'm branching their projec)
<lifeless> then the best thing to do is to use the branch command :)
<nocturn> lifeless: Yeah :-)
<nocturn> Ok, did the branch
<poolie_> lifeless: hi, just reading this 4% branch
<poolie_> trying to understand
<poolie_>          # If length == 1, then we only have the root entry. Which means
<poolie_>          # that there is no real difference (only the root could be different)
<poolie_> -        if (len(self.builder.new_inventory) != 1 and self._any_real_changes()):
<poolie_> +        if len(self.builder.new_inventory) != 1 and (self.entries_changed or
<poolie_> +            self.entries_deleted):
<nocturn> poolie_: Do I need to do anything special to remove the branch again?
<poolie_> nocturn: you can just either delete it, or i usually prefer to move it into a directory called 'Abandoned'
<poolie_> just in case i want it back
<poolie_> like a trash can
<nocturn> Is it wise to follow something like trunk,tags,branches in bzr too
<poolie_> no, better to just have the trunk and branches in one directory
<poolie_> as separate branches obviously
<poolie_> lifeless: the len(...inv) tests in there look a bit strange strange
<nocturn> poolie_: silly question, but how to I do that 'have the trunk and branches in one directory'?
<poolie_> the usual setup is
<poolie_> bzr init-repo myproject
<poolie_> bzr init myproject/trunk
<AfC> lifeless: don't need anything fancy. Just a one paragraph bio, some bullet points about what you're _currently_ working on, and a photo. Don't need any of the rest of the bling.
<poolie_> (do stuff)
<poolie_> bzr branch myproject/trunk myproject/somefeature
<AfC> lifeless: bring a photo jpg along this weekend and we'll hack someething up quickly.
<lifeless> AfC: photo. Eek.
<AfC> lifeless: hackergotch at least :)
<lifeless> quick, look for a cookie monster jpg
<poolie_> i have some good photos of lifeless
<poolie_> i think
<poolie_> he can be the judge
<AfC> poolie_: did I hear you say Bazaar 0.91 would be "today"?
<lifeless> poolie_: I think you're probably better placed to asses
<poolie_> AfC: yes i expect so
<lifeless> poolie_: they are strange but correct; its an artifact of 'the null tree has no root'
<lifeless> which I don't like but is entrenched now
<lifeless> bleh test output ordering failures.
<lifeless> ok fixed version I think, real    0m18.834s
<lifeless> user    0m17.645s
<lifeless> sys     0m0.580s
<ubotu> New bug: #141157 in launchpad-bazaar "Locks acquired via the smart protocol have poor lock info." [Undecided,New]  https://launchpad.net/bugs/141157
<lifeless> ok, all commit tests pass, next round
<lifeless> looking good
<lifeless> 2K ok so far
* AfC updates the time in the blog post he's writing
<lifeless> time?
<AfC> It was 19.2 seconds. You just said 18.8
<AfC> (or was that for something else?)
<AfC> down from 29.5s
<lifeless> oh right
<lifeless> so if you want the test scenario
<lifeless> this is a mozilla tree
<lifeless> doing 'bzr commit -m message FILENAME'
<lifeless> I'm aiming for that to be about 2seconds eventually, or less
<lifeless> long way to go to get there
<lifeless> this is just the low hanging fruity biscuits
<AfC> lifeless: forgive me for being stupid, but isn't that incremental commit, not initial commit?
<lifeless> I'm talking about incremental today
<lifeless> *initial commit* figures:
<lifeless> bzr.dev
<lifeless> real    6m21.980s
<lifeless> user    3m16.668s
<lifeless> sys     0m18.469s
<lifeless> my experimental pack work, not all of which is stable enough to publish in any form (but I can supply patches for the *really* brave)
<lifeless> real    1m34.322s
<lifeless> user    1m20.829s
<lifeless> sys     0m4.668s
<AfC> (Your comment was just the seed for me writing a blog post, but it's part of my contribution to the ongoing war in GNOME land about DVCS)
<nocturn> Ok, I'm reading TrackingUpstream here:
<nocturn> http://dev.marva.antwerpencentraal.be/
<nocturn> Sorry, wrong url
<nocturn> http://bazaar-vcs.org/TrackingUpstream
<nocturn> How can I use SVN from upstream instead of CVS
<lifeless> bzr-svn
<lifeless> nocturn: bzr-svn is wicked cool
<lifeless> at this point, calling status, then a selected commit with the ids from status is still faster, have to hammer some more.
<nocturn> OK, thanks lifeless
<lifeless> igc: review requested
<igc> lifeless: sure
<lifeless> it should be obvious which one :)
<igc> lifeless: yes, and you're right re the nested tree stuff I think
<nocturn> Ok, got the structure set up
<nocturn> I created a repo with bzr init-repo project
<nocturn> and upstream and mybranch in that
<nocturn> Now, how can I check out the repo?
<lifeless> bzr checkout project/mybranch
<lifeless> or have I misunderstood what you mean?
<nocturn> lifeless: That checks out only my branch, can I checkout the entire repo?
<nocturn> Like an SVN checkout without specifying trunk
<lifeless> no
<lifeless> in bzr branches are *semantic*, they define structure
<lifeless> in svn there are no branches, which is a huge problem for programmatic use of svn
<nocturn> Ok, when I try to get the upstream branch, it says: bzr: ERROR: Not a branch
<nocturn> For mybranch too.
<lifeless> how did you make the branches ?
<nocturn> I created myproject with repo-init
<nocturn> then upstream with bzr init
<nocturn> then mybranch with branch upstream mybranch
<nocturn> I'm now trying a checkout over sftp
<nocturn> As I usually do
<lifeless> what sftp url are you using ?
<nocturn> sftp://hostname:/path-to-repo/upstream
<lifeless> (don't paste a password or anything, but the rest would be useful. feel free to mangle hostnames etc, but keep the path basically intact if possible)
<lifeless>         ^
<lifeless> erm
<lifeless>              ^
<lifeless> thats better
<nocturn> bzr co sftp:/bzrhost.domain:/home/bzr/marva/upstream
<lifeless> the second : is incorrect in SFTP urls, you would need a port number there
<lifeless> and you are missing a /
<lifeless> bzr co sftp://bzrhost.domain/home/bzr/marva/upstream
<lifeless> that will work better
<nocturn> Sorry, I need more coffee ;-)
<nocturn> It worked now.  Sorry for the mistake, I'm missing some sleep...
<lifeless> no worries
<lifeless> perhaps you should sleep though :)
<lifeless> igc: there is a bug, I don't know if I introduced it though (with nested pointless)
<lifeless> I've added a test
<igc> ok - let me think about your mail re nested trees some more
<lifeless> hmm, I've fixed the bug and am doing the other comments right now
<lifeless> that mail is orthogonal
<lifeless> well, I *am fixing* dammit.
<lifeless> its still there
<lifeless> hah!
<lifeless> self._unchanged is fuxored for nested treees
<igc> fuxored?
<lifeless> say it out loud
<poolie_> he has children :)
<lifeless> :)
<lifeless> they will learn
<igc> they're absent right now so it's ok :-)
<thekorn> hi, one short question: i pushed a branch to launchpad with bzr 0.15 (feisty), is it possible to get this branch with bzr 0.8 (available in dapper)?
<lifeless> igc: ok, I think I've squashed that bug - insufficient coverage
<lifeless> thekorn: yes
<lifeless> thekorn: we will be issuing a new format in the near future which will break compatibility with dapper, but we also have debs of newer bzr's for dapper
<thekorn> lifeless: ah ok, thanks
<nocturn> Another question... There where changes to upstream trunk (which I do not want yet)
<nocturn> How can I get them in mybranch?
<nocturn> merge probably, but I would like to be able to give my changes back too...
<lifeless> to get someone elses work use merge
<lifeless> to send your work, if they use bzr either publish a branch or use bzr send
<lifeless> if they don't use bzr, use 'bzr send --no-bundle'
<nocturn> I don't have bzr send...
<lifeless> oh, must be an old bzr
<nocturn> Bazaar (bzr) 0.17.0
<nocturn> On Ubuntu Dapper (server)
<lifeless> if they don't use bzr you can get a good diff for emailing them with 'bzr diff -r ancestor:PATHTOUPSTREAM'
<lifeless> this will do the right thing even if you haven't merged everything from upstream yet
<nocturn> Ok, thanks
<lifeless> if they use bzr either publish a branch, or use 'bzr bundle'
<poolie_> :!sort % |uniq -c|sort -nr > dupes.tmp
<poolie_> easy guide to refactoring :)
<poolie_> well, slightly interesting
<lifeless> poolie_: the big commercial code analysis engines are basically that, but more generic
<nocturn> The's no newer version of bazaar for dapper, I'm using the bazaar repository
<lifeless> igc: ok, both patches are back in your court
<Lo-lan-do> G'day
<lifeless> nocturn: yes, thats right, there will be soon
<igc> thanks
<lifeless> theres a 44% win, and you're sitting on it!
<lifeless> (kidding)
<igc> great news! Makes me happy! (not kidding)
<nocturn> Ok, good that it's still getting updates :-)
<nocturn> I'm waiting for the next LTS to upgrade the server
<ubotu> New bug: #141172 in bzr "Interrupting bzr Ctrl-C does not kill openssh subprocess" [Undecided,New]  https://launchpad.net/bugs/141172
<LeoNerd> Isn't that a rather old duplicate?
<spiv> LeoNerd: perhaps, but I didn't find the dup when filing.
<igc> lifeless: should the parameter to find_ids_across_trees in commit.py be self.specific_files or specific_files or doesn't it matter?
<lifeless> it does not matter
<lifeless> the results are the same if its deduped or not
<lifeless> but the later checks win by processing minimal entries
<igc> ok
<lifeless> night all
<lifeless> igc: if you are happy or want trivial changes, please feel free to do them and submit it
<lifeless> as I still can't resolve conflicts bzr.dev
<lifeless> and I'm sure there are some on these
<igc> lifeless: one more Q ...
<lifeless> so I'd be asking you to submit it anyhow :)
<igc> line 687 - you've dropped ie.revision = None ...
<lifeless> right
<igc> was that deliberate?
<lifeless> yes
<lifeless> its bogus
<lifeless> we're carrying over an unaltered inventory entrie
<lifeless> *entry*
<lifeless> why would we mark it as possibly-changed ?
<igc> fair enough
<igc> night and thanks
<lifeless> gnight
<Kinnison> hey lifeless, how's pack coming along?
* igc food
<nocturn> Anyone here using the Bugs Everywhere system?
<nocturn> I found it on the bazaar homepage, link http://panoramicfeedback.com/opensource/
<lifeless> Kinnison: faster than hg on my laptop for the first commit
<lifeless> Kinnison: thats the highlight, reality is more complex, of course
<Kinnison> lifeless: :-)
<Kinnison> lifeless: I'm more interested in whether or not it'll improve push/pull at all
<Kinnison> Since my first commit is usually of no more than five or six files :-)
<lifeless> push/pull with it is about 120% of rsync
<lifeless> later
<Kinnison> And is that with a pure protocol like sftp, or with something smart?
<ubotu> New bug: #141105 in bzr "Crash with authenticated https checkout" [Undecided,New]  https://launchpad.net/bugs/141105
<matkor> python apps do not crash ... they only raise exceptions ...
<nocturn> Ok, I have made an experimental branch using the branch command
<nocturn> But the source branch had minor changes
<nocturn> How Can I pull them in?
<Kinnison> matkor: right up until the C extensions crash :-)
<matkor> Kinnison: Then it is C crash ;)
<Kinnison> even if it's the python interpreter which is crashing?
<fullermd> C crash run!
<matkor> Kinnison: yeahh...  blame C and Canada ;)
<spiv> Kinnison: that's with sftp
<matkor> nocturn: commit on source branch and pull merge on experimental ?
<Kinnison> What if it's a pypy interpreter and the code running in that causes the pypy interpreter to raise an exception, rather than to raise an exception within itself?
<spiv> Kinnison: AIUI
<Kinnison> spiv: that's pretty cool
<spiv> Kinnison: a big win is that there's very few roundtrips with packs, because there's relatively few files.
<gabe__> hello ppl
<gabe__> hoping someone might be able to give me some pointers with using bzr_launchpad
<gabe__> bzr+launchpad
<lifeless> gabe__: I'm just passing through, but perhaps #launchpad may have some folk able to help too; also you should really ask your question, vague things like 'need help' don't give helpers enough info to know what to say to you
<gabe__> hehe yeah cheers
<gabe__> well I have a central repo (no-trees) with many branches in it, do you know if it's possible to link the whole thing up with launchpad, rather than individual projects?
<fullermd> I'm pretty sure not.  You can only push/pull branches, so you'd have to iterate over them one way or another.
<fullermd> And I don't think launchpad gives you any repo control, so they'd each be independant on the other end too.
<gabe__> oh
<gabe__> well then can i use launchpad as a ticketing system, without linking it with my branches?
<thumper> What's the chance of dapper backports for bzr > 0.17?
<fullermd> I imagine so.  I mean, it doesn't force you to upload any branches at all, so...
<spiv> gabe__: sure, you can use any part of launchpad independently of the others.
<Lo-lan-do> thumper: It was mentioned earlier that there will be some soon.
<spiv> gabe__: obviously the intent is that the various parts will integrate nicely and work well together, but you don't have to upload branches to use the bug tracker, or vice versa.
* spiv -> food
<gabe__> aha sounds cool, basically in my company we have lots of websites that we maintain. We want a ticketing system to track required changes etc. Each website is its own branch. But we don't want to have a seperate ticketing system for each website. What would be the bet way to go about this?
<thumper> poolie: re the testing that I was going to do tomorrow,
<poolie> (phone)
<thumper> poolie: there is not currently a bzr > 0.17 for dapper
<lifeless> thumper: run from source?
<lifeless> there will be soon
<thumper> lifeless: ok, could do
<zomba> hi
<zomba> i have a problem
<zomba> bzr: ERROR: File exists: '/bzrrep/myrep/.bzr/repository/lock/1v8fqh0fv9.tmp': Failure: unable to mkdir
<zomba> any ideas?
<fullermd> Permissions?
<zomba> no...I can't do a bzr commit
<zomba> i've the solution
<zomba> disk space on the server repository
<zomba> thanks anyway
<AfC> Did you decide to cut 0.91 today, or is it still in progress?
<resiak> as far as i can tell, it's not possible to persuade `bzr log` to include diffs.  is there a straightforward way to fake this, short of parsing `bzr log` and feeding each rev to `bzr diff -r $rev-1..$rev` ?
<fullermd> No, there's not.  Though you probably want -rparent:$rev..$rev.
<resiak> aha, thanks
<fullermd> Or even '-c$rev' (new on 0.91, I think)
<fullermd> If you were more ambitious, you could probably write a custom log formatter that did the job...
<fullermd> (would certainly be faster than spawning a kadnillion python processes...)
<grantgm> Is there any way to merge (add) a bzr branch into an existing svn repo? I've started work on some code for a prof, and now that I'm about 100 revisions into tracking it with bzr, he's told me he'd like me to start using the department's centralized svn server. The svn server has a ton of different directories in TRUNK (one for each researcher/project - about 8 gigs total). He would like me to create another directory there for my project.
<grantgm> Ideally, what I'd like to do is import my bzr branch into the svn repo (while maintaining my revision history), and maintain the ability to work with bzr on my end, using that single svn directory as a remote (possibly bound) branch. If possible, I'd like to avoid having to keep the rest of the svn trunk on my local system, since 99% of it is completely irrelevant to me.
<grantgm> It seems that using the svn repo through bzr can be done with the svn/bzr foreign branches plugin (is that correct?) but I can't seem to find any way of actually getting the data that I already have into svn.
<grantgm> Any help would be greatly appreciated!
<dato> jelmer would know if pushing just to a subdirectory is possible.
<jelmer> grantgm: you should be able to use svn-push from the latest bzr-svn
<jelmer> to push to /trunk or something (to the root of the repository won't work)
<grantgm> so i should create the dir in svn trunk, then just using svn-push svn://host/trunk/mydir will get my revision history into svn?
<Peng> grantgm: Try convincing them to use Bazaar instead of svn. :D
<grantgm> i already did :) ... but he didn't seem impressed :(
<jelmer> grantgm: Yep, that should work, as long as mydir isn't the top-level directory of the repository
<grantgm> of the svn repository?
<jelmer> yep
<grantgm> nope, it isn't, so I'll give it a go. Here's hoping I don't wipe out the whole Comp Sci & Engineering repo in the process :)
<grantgm> when it says on http://bazaar-vcs.org/BzrForeignBranches/Subversion that renames aren't supported (under Future Enhancements) does that just mean that if I want to move a file I should do it with svn rather than bzr, and then everything will be fine, or will doing any renaming break it?
<jelmer> grantgm: bzr can push renames just fine
<jelmer> and will still see them as renames
<jelmer> but if somebody does a "svn mv" bzr won't consider that a rename
<jelmer> I'll clarify the statement on the wiki
<LeoNerd> The core problem is that svn doesn't really have a file move operation
<LeoNerd> It sees a new file whose history continues from some other file, then a deletion
<jelmer> right, you have to use heuristics to determine that when somebody does a delete+copy they actually meant a move
<jelmer> bzr-svn stores rename information in a bzr-specific property in svn
<grantgm> let me make sure i have this correctly: if i do a bzr rename, will it won't be pushed to svn as such - bzr will understand it, but in svn it will appear as a delete-then-create. is that right?
<jelmer> grantgm: yes
<LeoNerd> Er...
<LeoNerd> It's more that svn doesn't _have_ a move operation, so that's the best thing that it can do, a delete-then-create
<LeoNerd> It's almost the same as CVS, only SVN can reference other files for history further back than the first revision, so the newly-created file takes the history of the one that's deleted
<grantgm> so that is what 'svn move' actually does?
<LeoNerd> Since it doesn't have one, a bzr->svn push can emulate a rename using a delete-then-create
<LeoNerd> Yes.
<LeoNerd> svn has lots of "magic" that isn't really magic at all, that's simply hacked on using the cheap-reference-copy thing
<LeoNerd> There's no such thing as a branch, or a tag, in svn
<LeoNerd> The only things that exist are cheap copies
<LeoNerd> A branch is a cheap copy of its parent, that then has new divergent history
<LeoNerd> A tag is a cheap copy of its referrant, that you promise not to change
<fullermd> But that's the best way to do it.  Obviously.  I mean, it took them 6 years of hard work to perfect it.
<LeoNerd> A rename is a cheap copy of the old name of the file, the old file is then deleted
<LeoNerd> All these operations do exist natively within bzr
<LeoNerd> This difference in world view, is what makes bidirectional bzr<->svn gatewaying very difficult in the general case
<grantgm> yea...that seems a lot more sane
<LeoNerd> You can only guarantee proper gateway in restricted cases where both sides can agree a proper representation for the operations. Namely, a single branch of commits that just add, change, or remove files.
<jelmer> LeoNerd: bzr-svn can handle all sorts of funky revisions
<LeoNerd> But surely just by heuristic analysis?
<grantgm> right, but it seems that svn can't. so long as bzr tracks what is _really_ happening, i'm happy
<jelmer> LeoNerd: No, 1-to-1 mapping
<jelmer> LeoNerd: or do you mean what directories to consider branches and the like?
<LeoNerd> Er.. Not sure I quite get the question any more...
<jelmer> LeoNerd: can you give an example of the sort of heuristic analysis you mean?
<LeoNerd> Detecting a merge
<jelmer> it can't detect svn merges and won't try to, but it stores information about bzr merges
<jelmer> and can read that
<LeoNerd> Yes, that's the sort of thing I meant
<jelmer> it will also be able to use the merge info svn 1.5 writes out (when it's finally released)
<jelmer> sorry, I misunderstood you then
<grantgm> hey, jelmer, are you here?
<jelmer> grantgm, yep
<grantgm> I've just tried what we were talking about earlier, but it doesn't seem to like it: I created the directory in the svn repo, (svn mkdir mydir), and I'm now trying to push my local branch to it, but its telling me that the branches have diverged
<jelmer> grantgm: It will create the directory for you, otherwise you'll indeed get that error
<DShepherd> how can I update to a specific revision?
<grantgm> ok. so at this point, should i --overwrite it?
<jelmer> grantgm: easiest would be to just remove it and then do the push
<grantgm> ok. I tried merging, as well, but that seemed to hang. I killed it after ~20 minutes of no activity
<jelmer> grantgm: what exactly did you try to merge?
<grantgm> from within my local branch i did 'bzr merge svn://remoteserver/repo/trunk/mydir'
<grantgm> the same thing I'd do if my local branch had diverged from a remote one using just bzr
<jelmer> grantgm: These branches don't have any history in common
<jelmer> although I agree it shouldn't hang
<grantgm> yea...I figured I'd give it a try. Grasping at straws, I guess.
<grantgm> ok, so I've removed the directory from the svn repo, and ran the push again. Its throwing an list index out of range exception. Check http://paste.ubuntu-nl.org/38028/
<lifeless> moin
<grantgm> ... throwing *a* list index ...
<jelmer> hey lifeless
<lifeless> power failures
<lifeless> hate em
<jelmer> grantgm: what version of bzr-svn are you running?
<grantgm> 0.90.0, package from Ubuntu Gutsy
<jelmer> grantgm: that command should be 'svn-push' rather than 'push'
<grantgm> oh, sorry, that's the bzr package...one second
<jelmer> the two will be integrated eventually but that hasn't been done yet
<jelmer> lifeless: you haven't missed much here
<grantgm> Ok, it seems to be going now. 'bzr help svn-push' makes it sound like they are already pretty much integrated: "this command is the same as that of 'bzr push', except that it also creates new branches." Gimme
<grantgm> ... a sec and I'll let you know if it goes through
<lifeless> I need a favour from someone familiar with bzr
<jelmer> lifeless: what sort of favor ? :-)
<lifeless> jelmer: I need someone to generate a bundle of bzr.dev against my repository branch
<lifeless> because I can't push-pull :)
<lifeless> then I can apply that bundle to my local copy of bzr.dev, which will make my [merge]  mails be slightly less out of date
<jelmer> lifeless: what's the location of your branch?
<lifeless> people.u.c/~me/baz2.0/repository
<jelmer> lifeless, not quite sure I follow - what command do you need me to run?
<lifeless> oh
<jelmer> 'bzr.packs bundle http://people.ubuntu.com/~robertc/baz2.0/repository/' from my local bzr.dev copy?
<lifeless> yes I think
<lifeless> or s/bundle/send/ and ad --mail-to robert...
<jelmer> on its way
<lifeless> danke
<thumper> lifeless: which branch should I grab to do my load testing on dapper?
<thumper> lifeless: I guess bzr.0.90
<lifeless> load testing on dapper?
<lifeless> ok, I'm confuzzled
<lifeless> 0.90 is fine though yes
<thumper> lifeless: it'll all become clear soonish :)
<thumper> I hope
<ike> Hello.
<ike> Anyone know something about crypto repository format?
<ike> Will it work? afaik it was GSoC project but i couldn't find anything on mailing lists.
<lifeless> ike: it didn't get finished
<ike> pitty. but was it completly dropped or just the progress is slow?
<ike> lifeless: do you know maybe?
<ubotu> New bug: #141368 in bzr "merge command should have --change option" [Undecided,New]  https://launchpad.net/bugs/141368
<lifeless> ike: I was the mentor
<lifeless> ike: and I don't know :(
<ike> lifeless: oh. pitty. was it your idea? 'cause i'm looking for crypto repository oslt.
<ike> i need repository for sensitive data (passwords etc)
<lifeless> it was bogdano's idea
<lifeless> and a really nice one.
<lifeless> but he disappeared basically in the second half
<lifeless> there is code on launchpad but it doesn't encrypt, only obscures the data - proof of concept progress only
<ike> mhm. not much useful in my case.
<ike> so another question maybe.
<ike> i thought about some repository inside crypto partition/file.
<ike> secured by a password... and question: is it possible to tell bzr or i don't know what to interactve pass password to ... mount oslt?i
<lifeless> what is "oslt?i" ?
<ike> i want to simply `bzr pull` and if the repository isn't available (the partition isn't mounted) to mount particular partition first.
<ike> oslt - or something like that. the last "i" was a typo.
<lifeless> ok
<ike> i know that the whole partition whould be clearly readable while sending the data but... it's better than nothing i think.
<lifeless> uhm no, bzr doesn't have that, but you could use luks separately
<igc> morning
<lifeless> and just have a loopback crypto partition
<lifeless> cryptsetup is your friend for that
<lifeless> hi igc
<igc> hi lifeless
<lifeless> jelmer: I haven't seen it
<lifeless> jelmer: oh I found it sorry :)
<ike> Ok. I get that. But is scenario like that possible: clients executes `bzr up`, bzr connects to the repository, asks client for a password, mounts partition with provided password, receives data from a repo, unmounts the partition?
<lifeless> ike: yes, you could do that in a plugin as a transport I think
<ike> o! hooray. thanks. i'll look at this.
<lifeless> just replace the normal local transport with one that knows about your path; however I'd just do it as a shell script wrapper IMO
<lifeless> proably simpler, and easier to be sure its unmounted afterwards
<ike> Hm. So you suggest a script which mounts needed partition, executes `bzr something` and unmounts it.
<ike> crap. how i didn't figure this out by myself?
<lifeless> :)
#bzr 2007-09-21
<lifeless> igc:  can you merge my bytes_to_gzip patch?, I'm definite its the right thing now even with memory copies - 3 seconds win with it
<lifeless> igc: even with my faster-sha patch
<igc> sure. I'll do that RSN
<ubotu> New bug: #141382 in bzr "Test failures when TMPDIR points at a symlink" [Low,New]  https://launchpad.net/bugs/141382
<lifeless> igc: thanks!
<lifeless> igc: I've decided path_content_summary is the go
<igc> Yes, I think it is
<lifeless> igc: it may be wrong eventually but for now its an improvement, IFF I add the sha lookup
<lifeless> so I'm going to add that today
<igc> 4% review just sent to the list btw
<igc> so lifeless, you have a lot of merges needed to pqm :-)
<igc> I can do most of them today if you wish
<igc> what order do you want them submitted if any?
<lifeless> make bytes would be a good start
<lifeless> jelmer: what bug is your bundle on ?
<jelmer> lifeless, which bundle?
<lifeless> the pqm one
<lifeless> I'm looking at bug 117197
<ubotu> Launchpad bug 117197 in pqm "Doesn't install required Python package" [High,Triaged]  https://launchpad.net/bugs/117197
<lifeless> but theres no linked branch or bundle
<jelmer> lifeless: oh, I send the bundle to you. I'll attach it to the bug report, didn't know that was actually open
<jelmer> s/send/sent/
<lifeless> you filed it :)
<jelmer> whoops, that's the second time that happens
<jelmer> ok, bundle is now attached
<lifeless> igc just had a power failure
<kkubasik> hey, I just found bug# 133989
<kkubasik> its where bzr cant branch from svn on windows
<kkubasik> with a FleExitst error
<kkubasik> has anyone heard anything as far as possible solutions etc?
<jelmer> kkubasik, that's a bug in bzr's windows support
<lifeless> jelmer: are you sure?
<lifeless> jelmer: I thought so too, but only bzr-svn users seem to hit it
<jelmer> lifeless, yes, it was also reported independently against bzr
<lifeless> oh ok
<kkubasik> ahhh
<lifeless> do we know the cause yet? is it a change in python ?
<lifeless> kkubasik: this is recent FWIW
<jelmer> https://bugs.edge.launchpad.net/bzr/+bug/139253
<ubotu> Launchpad bug 139253 in bzr "bzr branch fails with "File exists" error." [Undecided,New] 
<lifeless> bump that to critical please
<lifeless> and triaged
<jelmer> done
<lifeless> user    1m20.565s
<lifeless> commit is sneaking down still :)
<jelmer> lifeless: which tree?
<lifeless> moz
<lifeless> initial
<jelmer> nice
<lifeless> (I'm working on incremental, but have to run the initial each time as well to stop regressions)
* jelmer has just started on shallow branches again
<jelmer> as everything else seems to be fast enough nowadays :-)
<elmo> I remember when status took that long for one file in the moz tree :-P
<elmo> \o/
<lifeless> elmo: initial commit in bzr.dev is 3m20 user
<lifeless> elmo: and 6+minutes wallclock
<elmo> what's the wall for you commit?
<lifeless> I get
<lifeless> real    1m26.859s
<lifeless> user    1m20.565s
<lifeless> sys     0m4.420s
<elmo> nice
<lifeless> packs: )
<lifeless> whenever linux is slow, write your own filesystem FTW
<elmo> (and I was just being bitter - I have too many machines running bzr 0.8)
<poolie> elmo, that's the dapper version?
<lifeless> poolie: yes
<lifeless> we have not done an SRU yet
<poolie> good morning lifeless
<lifeless> hi poolie
<lifeless> igc has had a power failure
<poolie> :)
<poolie> Brisbane was famous for power failures when i was a kid
<lifeless> poolie: bzrlib/tests/inventory_implementations/basics.py
<lifeless> is named strangely, why isn't it test_basics.py ?
<poolie> no good reason
<igc> I'm back
<lifeless> thanks jelmer that was very helpful
<lifeless> igc: my patch for rename correctness isn't merged
<lifeless> igc: if it was approved, could you merge that too ?
<igc> sure
<igc> just doing the 4% one now
<lifeless> vila: please keep news alphabetically sorted now
<lifeless> vila: as per the thread on the list
<lifeless> F comes after H
<lifeless> in NEWS, but shouldn't
<jdong> wait, F doesn't come before H
<jdong> oh nvm
* jdong hangs head in shame
<jdong> just... please... hit /clear and pretend that never happened :)
<lifeless> poolie: pushing 2768 of repository branch
<lifeless> poolie: its up to date with bzr.dev some more with that
<poolie> everyone's beeping at me
<igc> lifeless: rename_one fix submitted to pqm now fyi
<lifeless> danke
<lifeless> elmo: btw why don't you upgrade bzr across all the systems
<lifeless> elmo: there are many bug fixes you should really have
<Vantage13> hi I'm using bzr 0.18 with bzr-cvsps-import and it keeps throwing memory errors on cvs v files that are larger than 20MB.  Is there any way at all around this? (aside from adding more ram...)
<lifeless> Vantage13: theres no existing knob that I'm aware of. Can you please file a bug on this; and if you know some python I'd be happy to help you work up a patch to fix this
<Vantage13> lifeless: is this a bzr-cvsps-import bug or bzr itself?
<lifeless> Vantage13: I would say bzr-vcsps-import
<lifeless> lol
<lifeless> knits$ bzr vommit
<lifeless> bzr: ERROR: unknown command "vommit"
<jdong> now we need to implement it :)
<jdong> Spec: Bulimic Repacker: bzr vomit / bzr gag....
<lifeless> spiv: ping
<fullermd> Hm.  'vomit' should be an alias for 'uncommit'...
<spiv> lifeless: pong
<lifeless> spiv: hows teh fix? Can we chat about it?
<spiv> Sure.
<spiv> (you mean on phone or here?)
<lifeless> either
<igc> lifeless: review of 40% one done now
<lifeless> phone focuses the mind
<spiv> Basically it's working, but the tests are a PITA.  It's awkward to construct broken versionedfiles to run the tests on.  I have an automated test for it, but the scaffolding is a bit ugly.
<spiv> I think it's probably time I fired it off to the list for review despite that.
<ubotu> New bug: #141411 in bzr-cvsps-import "Import fails with memory error on files larger than 25MB" [Undecided,New]  https://launchpad.net/bugs/141411
<lifeless> spiv: how about a phone chat then, see if we can find a way to express the problem with test approach
<spiv> lifeless: sounds good.
<Vantage13> anyone know what alterations I'd have to make to remove a file or have bzr-cvsps-import skip a file?  I tried removing the cvs v file, and removing it from the CVSROOT commitlog but it still seems to know the file is missing and error out...
* igc food
<lifeless>         head_set = self._repo_graph.heads(parent_candiate_entries.keys())
<lifeless>         heads = [] 
<lifeless>         for inv in parent_invs:
<lifeless>             if ie.file_id in inv:
<lifeless>                 old_rev = inv[ie.file_id] .revision
<lifeless>                 if old_rev in head_set:
<lifeless>                     heads.append(inv[ie.file_id] .revision)
<lifeless>                     head_set.remove(inv[ie.file_id] .revision)
<lifeless> correct_parent_versions = [parent_version for parent_version in all_parent_versions in parent_version in g.heads(all_parent_versions)] 
<cory> I haven't seen much in the way of bzr <-> p4.  Is there any hope of something saving me from this predicament? :P
<lifeless> I've heard rumours, but not seen any code
<lifeless> Vantage13: hi
<lifeless> Vantage13: looking at the backtrace, I wonder if its a bug in our patiencediff.
<lifeless> Vantage13: you could breakpoint in line 608 of knit.py to get the texts that are being diffed
<lifeless> (_get_matching_blocks() does a diff)
<cory> Hmm, rumors are better than nothing, I suppose.  tailor explodes in numerous different ways, and only deals with part of what I need.
<cory> breakpoint... .py...how do you guys debug?
<lifeless> breakpoints, logs, traceing, debug output
<lifeless> pdb is a very good tool
<cory> Hmm, wow.  I've never used pdb.
<lifeless> put
<lifeless> import pdb;pdb.set_trace()
<lifeless> in a .py file somewhere, you'll get the hang of it easily
<Vantage13> lifeless: I know the file that's causing the problem.  It's a large data import text file.  The diff between the two versions is pretty huge
<lifeless> Vantage13: right, I'm wondering if the memory problem is not (its a 25Mb file), but (these two texts cannot diff properly with bzrlib)
<Vantage13> lifeless: how do you insert a breakpoint there?
<lifeless> import pdb;pdb.set_trace()
<lifeless> ok, I can pull bzr.dev now, with the fix to not propogate parent corruption
<igc> good news. I'm just merging your 40% one now btw
<lifeless> thanks!
<igc> but there are plenty others of yours in BB still to merge :-)
<Vantage13> lifeless: around?
<lifeless> Vantage13: yes
<Vantage13> lifeless: so I've set_trace right before the loop and it's stopped, however, i'm not sure what I should be doing at this point or what I should be looking for
<lifeless> well
<lifeless> it probably will pass some number of times
<lifeless> so 'c'
<lifeless> many times until it crashes, then you can add a condition to only break into the debugger on that case
<Vantage13> lifeless: i've actually got it on the one that crashes (since the previous calls were correctly processed the first time)
<lifeless> ok cool
<lifeless> you should have two texts there
<Vantage13> I have
<Vantage13>  /usr/lib/python2.4/site-packages/bzrlib/knit.py(609)_merge_annotations()-> for i, j, n in seq.get_matching_blocks():
<Vantage13> and the prompt
<lifeless> ok, one sec
<Vantage13> k
<lifeless> print annotated
<lifeless> print parents
<lifeless> print len(merge_content.text())
<Vantage13> both are True
<lifeless> print len (content.text())
<Vantage13> 768676
<lifeless> hmm, parents should be a list, not a boolean
<Vantage13> 770413
<lifeless> wow, thats quite long :)
<lifeless> have a look via top - how much memory is the process using at the moment
<Vantage13> lifeless: yeah, as I said :)
<Vantage13> 17.8%
<lifeless> however we do diff entire iso's using this code
<lifeless> 17% of what ?
<Vantage13> 370m Virt
<Vantage13> sorry, I just grabbed the %MEM column
<Vantage13> 360m RES
<lifeless> ok, large but not insane
<lifeless> (given the size of thing you are dealing with)
<lifeless> lets save these two texts
<Vantage13> lifeless: save how?
<lifeless> bzrlib.transport.get_transport('file:///tmp/').put_bytes('a', ''.join(merge_content.text()))
<lifeless> bzrlib.transport.get_transport('file:///tmp/').put_bytes('b', ''.join(content.text()))
<lifeless> that should create two files on disk - check they exist and look ok to you
<Vantage13> yup
<lifeless> from a shell
<lifeless> do python -m bzrlib.patiencediff /tmp/a /tmp/b
<lifeless> theory is that this will blow up
<Vantage13> odd.  It's saying module bzrlib.patiencediff not found, even though it is...
<lifeless> ok
<lifeless> just do /path/to/bzrlib/patiencediff.py /tmp/a /tmp/b
<Vantage13> running...
<lifeless> have a look in top, is it growing ?
<Vantage13> at the moment, no.  It seems fixed at 170m
<lifeless> how big is each file ?
<Vantage13> 18M each
<lifeless> so 36M from 170 134
<lifeless> 370M + 134 = 504M
<Vantage13> lifeless: this was the last message I got from you "370M + 134 = 504M".  was that the last one you sent?
<lifeless> 14:30 < lifeless> which is big, how much ram do you have ?
<Vantage13> lifeless: the machine has 2GB
<lifeless> ok
<lifeless> did it finish the diff ok ?
<Vantage13> yup
<lifeless> strange
<lifeless> so if you step through the loop
<lifeless> where does it crash
<Vantage13> len(self.a), len(self.b), matches, 10)
<Vantage13> MemoryError: <exceptions.MemoryError instance at 0xb7e2cd0c>> /usr/lib/python2.4/site-packages/bzrlib/patiencediff.py(244)get_matching_blocks()
<lifeless> hmm
<lifeless> and its on that pass through
<lifeless> ?
<Vantage13> then continuing through I also get
<Vantage13> len(self.a), len(self.b), matches, 10)
<lifeless> have you run out of memory now ?
<Vantage13> MemoryError: <exceptions.MemoryError instance at 0xb7e2cd0c>> /usr/lib/python2.4/site-packages/bzrlib/knit.py(609)_merge_annotations()
<lifeless> yea the exception is being raised frame by frame
<lifeless> what does top show now ?
<Vantage13> 397m
<lifeless> still not enough to get OOM
<lifeless> I have to pop away for a bit;
<lifeless> basically we need to figure out what is causing the error
<lifeless> I'd try stepping (s) into the function that fails now
<lifeless> try to get to the point that the next 's' will cause a failure
<lifeless> then investigate the variable etc that are involved and see if any are obscenely large or anything like that
<Vantage13> lifeless: this seems to be the loop
<Vantage13> 48  ->     for i in xrange(len(a)): 49             line = a[i]  50             if line in index: 51                 index[line]  = None 52             else: 53                 index[line] = i
<Vantage13> in patiencediff.py
<ssokolow> Does anyone know of a Bazaar cheat sheet similar to the Mercurial one and the edit of the Mercurial one to describe Git made by Zack Rusin?
<poolie_> ssokolow, http://doc.bazaar-vcs.org/bzr.dev/en/quick-reference/quick-start-summary.svg
<ssokolow> poolie_: Thanks.
<poolie_> you're welcome
<lifeless> Vantage13: so this should shrink memory use
<lifeless> I think
<Vantage13> lifeless: ?
<lifeless> Vantage13: can you identify the exact point it fails ?
<Vantage13> lifeless: without stepping through every single entry in file?  Probably not...
<lifeless> yah
<lifeless> uhm
<lifeless> add a print i
<lifeless> in there
<lifeless> run to failure,
<lifeless> then you can add a if i == failure_value: import pdb;pdb.set_trace()
<igc> lifeless: that 40% one now merged into bzr.dev. Can you please check you're happy with how I merged & tweaked it?
<lifeless> am doing
<igc> thanks
<Vantage13> lifeless: ok, i'm there
<lifeless> so in theory, 's' will cause a crash
<lifeless> does it ?
<Vantage13> index[line] = i
<Vantage13> throws the memory error
<Vantage13> i=699050
<Vantage13> line = V3S 6V2,BC,Surrey,1
<Vantage13> is there a limit to the size of the data structure index?
<lifeless> ok
<lifeless> lets get back there
<lifeless> and we won't run that line :)
<lifeless> if your memory use is reasonable at this point I'm going to consider it a CPython bug probably
<lifeless> >>> print type(index)
<Vantage13> 'dict'
<Vantage13> how do you print the total number of entries in the dictionary?
<jml> len(index)
<lifeless> print repr(line)
<lifeless> lets be sure there's no funky business
<Vantage13> 'V3S 6V2,BC,Surrey,1\r\n'
<lifeless> so I think you have found a bug in python.
<lifeless> whats the process size ?
<Vantage13> 397m VIRT, 386m RES
<lifeless> yah
<lifeless> jml: what do you think? 'index[line]  = i' throws a MemoryError
<jml> lifeless: "weird".
<lifeless> I recall spiv tracking down a bug in dict
<jml> Vantage13: print len(index)
<lifeless> this may be it
<spiv> lifeless: did I?
<jml> lifeless: yeah, that rings bells.
<Vantage13> 699051
<spiv> I don't remember it :)
<lifeless> spiv: in launchpad, some time back
<lifeless> or perhaps it was jamesh, but I thought it was you
<jml> hmm
<spiv> Hmm, I do remember spending a lot of time digging through the dictobject.c code at some point.
<spiv> I forget why though.
<lifeless> rotfl
<spiv> Something involving the difference between how it handled string keys (which it special cases) and other things.
<lifeless> lifeless, spivs exomemory
<lifeless> spiv: oh, perhaps it was security proxies as keys
<lifeless> or something like tha
<lifeless> so its bizarre to get an Out of memory error at this point
<spiv> lifeless: oh, I do remember that bug sort of now.
<lifeless> there is 400Mb in the process
<spiv> lifeless: it wasn't a bug in dict, it just looked like it.
<lifeless> this line is putting line into into
<spiv> There was a __del__ somewhere deleting things from a dict when I didn't realise it.
<spiv> Anyway, this is a large dict.
<lifeless> Vantage13: can you do 'print line in index'
<spiv> And inserting in a dict occasionally will trigger a resize.
<lifeless> spiv: power of two expansion ?
<Vantage13> lifeless: True
<spiv> Which I believe happens by allocating a whole new table, moving stuff into the new table, then removing the old table.
<lifeless> spiv: ^ line is already in there
<spiv> Yeah, I think it's power of two.
<lifeless> spiv: worst case it would allocate 800M (twice current memory), for 1.2Gb, still well within comfort - this machine has 2GB
<lifeless> Vantage13: do you have ulimits in place ?
<spiv> It has a loop doing "newsize <<= 1".
<Vantage13> lifeless: nope.  unlimited
<Vantage13> wait
<Vantage13> virtual memory seems to have one...
<Vantage13> suspiciously set to 409600
<lifeless> ahha!
<lifeless> there we go, memo to self, check ulimits earlier
<spiv> lifeless: I don't see why you say the line is already in there; Vantage13 says "index[line] = i" is triggering the memory error after all.
<lifeless> 15:37 < lifeless> Vantage13: can you do 'print line in index'
<lifeless> 15:38 < Vantage13> lifeless: True
<spiv> Ah, ulimits.
<lifeless> I've quoted the two lines that make me say the line is already in there
<spiv> lifeless: ah, I missed that, thanks.
<lifeless> Vantage13: so, remove the debug statements and try again. I wager it will work
<Vantage13> any idea off hand what would be setting that ulimit?  I assume it's a boot or login script...
<lifeless> uhm /etc/defaults/ may have something
<lifeless> theres also bash .d stuff in /etc/somethingorother
<igc> lifeless: are you good to merge now or shall I keep helping? If so, I'll merge "micro-tweaks to sha routines" next assuming you still want it in
<Vantage13> lifeless: we seem to have moved past that file, so i'm thinking that was it
<lifeless> Vantage13: :)
<Vantage13> lifeless: Thanks for all the help!
<lifeless> igc: please merge it, I'm good but help is help.
<igc> no problem
<poolie_> lifeless, is that a 'tweak' vote for the traceback change?
<poolie_> ie can i merge it with that change?
<lifeless> poolie_: sure
<lifeless> if my arguments are cogent
<lifeless> and you are convinced
<poolie_> sure, i just was being lazy
<lifeless> :)
<poolie_> succesfully
<james_w> ulimits are set in /etc/security/limits.conf as well
<lifeless> igc: a review of my knit random id patch would be cool too
<igc> I'm doing it now
<lifeless> :)
<lifeless> I'm just benching all my combined changes finally
<lifeless> I had *too many* branches to deal for a bit there
<igc> :-)
<igc> Hence my keenness today to get bzr.dev up to date
<lifeless> its still not quite *all* branches
<lifeless> but much closer
<lifeless> initial commit figures
<lifeless> real    1m28.816s
<igc> so lifeless, I'm confused re that patch ...
<lifeless> user    1m20.373s
<lifeless> sys     0m4.572s
<lifeless> which is good
<lifeless> no regression
<lifeless> mmmhmm ?
<igc> the changes to _add() don't make any sense
<lifeless> *blink*
<igc> add_version gaining random_id I get
<lifeless> really?
<igc> but nothing in that patch calls _add
<igc> is it already called by existing code?
<lifeless> incremental with 5 new files,
<lifeless> real    0m56.226s
<lifeless> user    0m49.507s
<lifeless> sys     0m3.744s
<lifeless> and incremental with specified file
<lifeless> real    0m23.494s
<lifeless> user    0m22.117s
<lifeless> sys     0m0.872s
<igc> big difference there
<lifeless> @@ -828,7 +828,7 @@
<lifeless>          self._check_add(version_id, lines, random_id, check_content)
<lifeless>          self._check_versions_present(parents)
<lifeless>          return self._add(version_id, lines[:] , parents, self.delta,
<lifeless> -            parent_texts, left_matching_blocks, nostore_sha)
<lifeless> +            parent_texts, left_matching_blocks, nostore_sha, random_id)
<lifeless> that hunk calls add
<lifeless> but I missed a hunk in my edits
<lifeless> I'll resubmit in a second
<igc> I was about to say "sure - but what calls it?"
<igc> :-)
<lifeless> _add is called there
<lifeless> or do you mean add_versions ?
<igc> cool
<igc> now, add_versions makes sense
<igc> s/now/no/
<lifeless> just supersede that path
<lifeless> patch
<lifeless> sent
<igc> thanks
<lifeless> bbiab
<igc> that's all good now lifeless
<poolie_> lifeless, would suggest renaming random_id to something that doesn't look like it's a random id
<poolie_> like id_is_random
<lifeless> poolie_: good suggestion; there is a idiom in play so we should do it for more than this one patch
<lifeless> igc: is that +1 ?
<igc> yep - voted on BB. I like poolie's suggestin btw but ...
<igc> we've used random_id elsewhere so ..
<igc> at least it's consistent
<poolie_> can you search and replace for the others?
<lifeless> monday perhaps
<lifeless> going on 11 hours work today
<poolie_> sure
<igc> poolie_: time for some Qs?
<igc> re bzrdir.py changes?
<lifeless> so I'm inclined to merge this as is as igc was happy
<igc> I'm not sure I understood your feedback in the review (poolie)
<poolie_> i don't believe i did review it other than here
<igc> as far as the new exception goes, better to report it than fail silently yes?
<igc> yes you did
<poolie_> which review?
<igc> http://bundlebuggy.aaronbentley.com/request/%3C46EF7C4F.8020404%40internode.on.net%3E
<lifeless> mmm too tired; going to leave this for monday
<poolie_> have a good weekend
<poolie_> are you going camping?
<igc> ditto
<lifeless> I've cancel codecon
<lifeless> going to sleep
<lifeless> I'm not good company right now
<igc> sleep always helps I find :-)
<lifeless> I may be fighting something off, feel *so* lethargic its not funny
<poolie_> igc, are you talking about the last comment in that review?
<igc> yep
<igc> but all 3 need some discudssion :-)
<poolie_> give me a minute
<igc> so, I'm not convinced (yet) that initialize_on_transport should take possible_transports as a parameter ...
<igc> what exactly does that buy us?
<igc> By then, the transport has been selected, yes?
<poolie_> igc, hi
<igc> hi
<poolie_> i looked at it again too, i don't think there's any point in passing it down
<poolie_> so nevermind that
<lifeless> poolie_: I've pushed up a bunch of merges today; you might like to see if that merges cleanly to your branch. I will look at your bundle monday.
<poolie_> i'll send an update with more
<igc> ok - so the exception feedback ...
<igc> I've added a new exception that will get reported ..
<igc> previously it failed but did nothing
<igc> so I don't understand ...
<igc> what you meant by 're-raise the orginal'
<poolie_> something like this:
<poolie_> i = 0
<poolie_> while True:
<poolie_>    rename
<poolie_> feh
<poolie_> hard to get it right in irc
<poolie_> i meant that for the first n iterations, when an exception is raised, you should ignore it and try again
<poolie_> after that, you should execute a bare 'raise' statement, causing it to rethrow the exception
<igc> ah - ok
<poolie_> so the caller, or the user, will see 'rename ............ failed: reason'
<poolie_> which i think is just as clear
<poolie_> unless i missed osmethigt
<poolie_> something
<igc> that's much clearer - thanks
<igc> ok - last bit ...
<igc> vila's code that isn't being used ...
<igc> I'm just commenting out dead code
<poolie_> ok, i think i understand it now
<igc> well ...
<igc> dead as in "pending" ...
<poolie_> it's about, say, if it was http+pycurl then we should preserve the 'pycurl' bit
<igc> when vila get's to it
<poolie_> hm
<poolie_> i think the main thing is that it ought to be a call to something like
<poolie_> target = urlutils.copy_url_qualifiers(original, target)
<poolie_> and then that can be tested separately
<poolie_> rather than doing string slicing inline here
<igc> yes, that's looks better
<lifeless> I'm gone
<lifeless> ciao
<igc> I'd like to put in that line but not write it
<igc> seeya lifeless
<poolie_> put it in as a comment?
<igc> yes ...
<poolie_> ok with me
<igc> thanks
<igc> (just trying to keep semi-focussed)
<igc> I'll put an updated patch up
<vila> poolie_, igc: I agree with poolie about passing possible_transports down, at that paticular point (initialize) it's harmless to not passing it down
<poolie_> but in general we should, right?
<igc> yes
<vila> poolie_: yes
<poolie_> hello vila
<vila> hi poolie_ , hi all ;-)
<igc> good to chat with you vila!
<vila> same here :)
<igc> how's sunny France?
<vila> been averbooked since I came back from vacations, thins have settled down a bit :)
<vila> s/aver/over/
<vila> s/thins/things/
<igc> sounds pretty normal! :-)
* vila needs another coffee...
<vila> yeah, I didn't get 3 and 1/2 weeks in a row for years, that was very good but the come back was harder than expected :D
<igc> yes, 2 weeks is the limit for most of us ...
<igc> beyond that, it becomes "what am I doing with my life!!!" :- ):-)
<vila> about the commented out code, I agree with lifeless, I hate it when people use a VCS and insist on commenting code out, plus there is already a bug for that
<igc> vila: know the bug #
<igc> ?
<igc> if so, I'll update it with poolie's code suggestion
<poolie_> vila, 3.5 weeks sounds nice, did you go away or just relax?
<vila> #122258 is realted, not exactly the bug in question but strongly related
<vila> poolie_: I went in spain and in several locations in France, we nearly saw all our best friends (some we didn't for years :)
<vila> poolie_: but we relax a lot too :)
<igc> sounds great
<vila> we were so lucky, the summer was exceptionally bad this year, but we manage to get sun every day :) Every time we arrived somewhere people said: "Wow, you're lucky, the weather have been sooo bad until today/yesterday/a few minutes ago"...
<igc> you must be good luck!
<vila> ubugtu ? bug #122258 is related, not exactly the bug in question but strongly related
<ubotu> Launchpad bug 122258 in bzr "http decorators incorrectly handled when authentication is used" [Low,Confirmed]  https://launchpad.net/bugs/122258
<vila> ubotu: thanks
<ubotu> You're welcome! But keep in mind I'm just a bot ;-)
<poolie_> haha
* poolie_ pets ubotu
<poolie_> i'm going to put my head down into this for another hour or so, anything else to talk about?
<igc> vila - get my reply?
<poolie_> if not, have a good weekend
<vila> igc: no
<vila> poolie_: have a good weekend too
<igc> no - that's all poolie - thanks
<poolie_> thanks
<igc> vila - yes, it means you bring good luck
<vila> igc: kthks
<igc> (when I reply in Gaim, people don't see my replies)
<igc> (promises himself to get to the bottom of that one day soon)
<vila> igc: :)
<ubotu> New bug: #141438 in bzr "BundleTester.test_unicode_bundle fails for WorkingTree3 on OSX" [Low,Triaged]  https://launchpad.net/bugs/141438
<igc> have a good weekend all
<poolie_> night
<matkor> Is it possible to update remote checkout ?  bzr update sftp://host/bzr-dir ? I get (bzr: ERROR: sftp://www-cz.ant.vpn/usr/lib/python2.4/site-packages/abbon2/.bzr/ is not a local path) ?
<spiv> matkor: Not builtin.  There's "ssh host bzr bzr-dir".
<ubotu> New bug: #141456 in bzr "merging of branches with nested trees fails when commiting" [Undecided,New]  https://launchpad.net/bugs/141456
<spiv> Er, "ssh host bzr update bzr-dir"
<spiv> There's a plugin that automates that: https://launchpad.net/bzr-push-and-update/
<matkor> spiv: Yeah but when checkout on host is from remote repo-host I would have to give access to repo-host to host which is not always good idea ...
<matkor> give access = give key / password to ssh executed on host
<matkor> I would be nice to have keys on trusted-host give them to host and repo-host and than on trusted-host be able to bzr update host ...
<sabdfl> howdy revisionistas
<AnMaster> I have to pull from a lot of branches with long names, is there anyway to store a shorthand so I can use bzr pull someword for http://foo.bar.com/~user/long/url
<AnMaster> using --remember doesn't work well when you pull from several
<hdh> I create a bzr repo in my firefox profile dir, and it crashed with this http://pastebin.ca/705679
<spiv> hdh: hmm, that's because there's a backslash in the filename
<spiv> It shouldn't traceback about that though.
<GaryvdM> AnMaster: You could use enviroment vars.
<AnMaster> GaryvdM, hm :(
<spiv> hdh: it's this bug https://bugs.launchpad.net/bzr/+bug/81844
<ubotu> Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid] 
<AnMaster> GaryvdM, any better idea?
<hdh> spiv: thanks, I should have thought of lp before
<GaryvdM> Sorry - no
<uws> AnMaster, GaryvdM: what I do is this. I create a local repository and mirror all upstream branches I pull from locally (doesn't take much space because of the shared repository) into local directories with a convenient name, e.g. repodir/some-project.person-name. Then I just pull/merge into my own branch using  "bzr pull ../some-project.some-other-person"
<AnMaster> uws, interesting
<uws> AnMaster, GaryvdM: (note that each mirror remembers the upstream url, so it fixes the problem)
<AnMaster> but well not perfect
<AnMaster> best would be aliased such
<AnMaster> I don't know how to make a feature request, but I'm requesting this feature
<AnMaster> so if someone want to make a feature request: thanks
<GaryvdM> AnMaster: you can make a feature request as a bug here: https://bugs.launchpad.net/bzr/+filebug
<AnMaster> need some login?
<AnMaster> :/
<AnMaster> oh well
<AnMaster> will to that after I get some food
<GaryvdM> I need to test if some code I have written works with branchs that have ghosts. How do you create a branch that has ghosts?
<GaryvdM> Ok - bzr.dev has ghosts - so I'll just use that...
<ubotu> New bug: #141478 in bzr "`bzr status -rN..M` in branch w/o tree produce NoWorkingTree error" [Undecided,New]  https://launchpad.net/bugs/141478
<vila> mrevell: ping
<mrevell> hi vila
<vila> hi mathew, I can't push to launchpad anymore, seems something broke in the last minutes or so, you're aware of it ?
<elmo> bazaar.launchpad.net and codebrowse.launchpad.net are down for emergency maintenance, ETD is 10 minutes
<elmo> [sorry, forgot to announce that in this channel] 
<mrevell> thanks elmo
<vila> elmo: thanks
<vila> elmo: I mean, thanks for telling us and doing the maintenance too :)
<mrevell> vila: I've just added a comment in response to your comment on the documentation audit bu
<mrevell> s/bu/bug
<vila> to tell the whole story I tried to push from a wrong machine, get a ssh request about a new IP address, get bounced because the machine was not authorized, went to the right machine, get an unreachable host and wondered if I had broken something :-)
<elmo> should be back now
<vila> elmo: wow, slow down, I still have to answer mrevell :)
<vila> mrevell: Great news !!!!
<vila> mrevell: from the outside, canonical looks a bit like Santa Klaus or the Tooth Fairy: surprises pop up unexpected  :)
<vila> elmo: I pushed without problems (just to confirm it's back and ok from my side)
<fbond> Hey, anyone know of any recent RPMs (or SRPMs) that I can use on my company's RHEL4 (ugh) system?
<vila> fbond: look at http://bazaar-vcs.org/Download
<vila> if you can't use an rpm package, installing from source is not *that* hard, you need python2.4 though (python -V)
<fbond> vila: thanks, I did look there.  I will see what I can do.  I don't like installing things from source due to maintenance headaches.
<fbond> I'm more likely to build my own rpms.
* fbond wishes he didn't have to use RHEL ...
<vila> fbond: that's why you should pester your admins to update to a newer RHEL :)
<fbond> Well ... I am the admin, but we are on a managed server that I don't have physical access to, and my plates already full because we're a bit understaffed for that sort of thing.
<vila> fbond: if you build a usable RPM we will gladly add it to the wiki (come back here for how)
<fbond> vila: okay, I'll keep you up to date
<vila> I'm not the one to contact for that, but Those Who Can read the logs :)
<vila> fbond: and thanks in advance
<vila> :-( Got a corrupt repo (first time ever though), any advice about what I should backup for diagnosis: .bzr.tgz, .bzrlog, anything else ?
<vila> backtrace ends with: KnitCorrupt: Knit <bzrlib.knit._KnitAccess object at 0xb776e4cc> corrupt: While reading {v.ladeuil+lp@free.fr-20070921114314-1tro2mobuor8e8zh} got IOError(Not a gzipped file)
<vila> and revisions.knit contains zeroes (0x00) on the whole range described in revisions.kndx...
<lapthrick> hey
<lapthrick> jelmer: why is bzr-svn still marked alpha on the plugins page?
<ubotu> New bug: #141538 in bzr-eclipse "cannot bzr init" [Undecided,New]  https://launchpad.net/bugs/141538
<lapthrick> jelmer: also, copy + delete => rename is listed as TODO, yet you have a screenshot demonstrating that it works :)
<GaryvdM> lapthrick: if you rename in bzr, then push to svn, and then pull to bzr - it knows it was a rename
<GaryvdM> if you rename in svn, then pull to bzr - it shows as a copy + delete
<lapthrick> GaryvdM: I mean http://samba.org/~jelmer/bzr/bzrsvn-renames.png
<GaryvdM> Hmm - he was saying last night that it does not do that.
<lapthrick> hmm, plugins page link to http://people.samba.org/bzr/jelmer/bzr-svn/0.3/
<phanatic> GaryvdM: your vizchanges branch looks good. it feels much faster, and i like the new curly graphs ;)
<GaryvdM> Best to wait for him
<lapthrick> shouldn't it be 0.4/ ?
<GaryvdM> Thanks phanatic
<lapthrick> phanatic: screenshot!
<lapthrick> and what are the rules bzr follows if a plugin is installed both system-wide and in ~ ?
<phanatic> lapthrick: the branch is still hot ;)
<lapthrick> phanatic: that doesn't impair your screenshotting ability, does it? :)
<GaryvdM> I'll upload one now
<GaryvdM> Branch is here: https://code.launchpad.net/~garyvdm/bzr-gtk/vizchanges
<phanatic> lapthrick: it's not about screenshooting ability, but laziness :P
<lapthrick> bzr needs checkout --light aliased to `cl'
<Odd_Bloke> lapthrick: You can add aliases yourself...
<GaryvdM> lapthrick: http://garyvdm.googlepages.com/bzr-gtk-vizchanges.png
<lapthrick> how can I quote a particular comment in launchpad?
<lapthrick> Odd_Bloke: oh?
<Odd_Bloke> lapthrick: http://doc.bazaar-vcs.org/bzr-0.15/using_aliases.htm
<Odd_Bloke> That's reasonably old but the method should stand.
<lapthrick> nifty, thanks
<hsn_> is there plugin for netbeans ide?
<james_w> Can anybody think of a fix for the following issue. I have a plugin that I am trying to run the testsuite of during the package build.
<james_w> it does this by running python __init__.py which sets up a test runner with the test suite.
<james_w> one of the tests then does from bzrlib.plugins import builddeb, as it needs to test something defined in the __init__.py.
<james_w> This fails as the plugin is not registered, and so it can't be imported that way.
<james_w> I can't set BZR_PLUGIN_PATH I don't think, as the code builds in a directory with a '-' in it, which bzr rejects.
<james_w> I see a few options:
<james_w> 1. copy all the code in to a new directory for the test, and then set BZR_PLUGIN_PATH.
<james_w> 2. move the thing that needs to be tested in to another module, and then simply import it in to __init__.py.
<james_w> 3. register the plugin before the tests are run.
<james_w> does anyone have an opinion about which is the least ugly?
<carlesoriol> hi. I'm carles Oriol from the catalan LoCo and I was thinking about create a bazaar for all the documentation and designs (logos, formats) of our LoCo. Is it possible? or it's too much  for the bazaar?
<carlesoriol> (bazaar project)
<james_w> how much are you talking about?
<carlesoriol> 300 Mb at the moment
<james_w> what's the largest file?
<carlesoriol> around 10 Mb
<james_w> that should be ok.
<carlesoriol> james_w: ok. Thanks for all
<james_w> however branching over the network will be slow at the moment.
<james_w> that should hopefully be a lot better next release (about a month).
<carlesoriol> james_w: well... If it's not a problem i'll organize the structure and then i can wait
<james_w> Lo-lan-do: thanks for bzr+ssh:// on alioth (I assume you had something to do with it).
<dato> it was buxy, actually, ages ago
<james_w> hi dato.
<dato> hey james_w
<james_w> I've just fixed builddeb for that problem you were having trying to build it.
<dato> I saw
<Lo-lan-do> james_w: Maybe, maybe not.  Forgot :-)
<james_w> Lo-lan-do: have you considered setting up shared repositories for each project?
<Lo-lan-do> I think we basically only provide a directory, and everyone is free to use it as they wish.
<Lo-lan-do> That includes creating repositories.
<james_w> providing repositories should transparently improve performance (including less server bandwidth).
<dato> not less server outgoing bandwidth
<Lo-lan-do> Yeah, but I guess some projects may have unrelated branches
<dato> or most, one per package
<Lo-lan-do> I'll add the recommendation to the wiki page
<james_w> dato: all done I think. Could you try again on your next upload round please?
<dato> james_w: ok
<james_w> thanks.
<james_w> jam's back.
<Lo-lan-do> Can one initialize a repository distantly?
<james_w> In theory yes.
<dato> yes
<dato> just try it :)
<james_w> and in practice.
<Lo-lan-do> http://wiki.debian.org/AliothBzr updated
<james_w> thanks Lo-lan-do
<vila> let's say I have identified a corrupted revision in ./bzr/repository/revisions.knit
<vila> Am I right in supposing that if I delete the corresponding line in revision.kndx, I will be safe ?
<vila> Or should I also delete it in all .kndx in the knits hierarchy ?
<vila> s#knits#repository/knits#
<vila> Of course it's a shared repository
<vila> abentley: ^ ?
<vila> lifeless: ^ ?
<vila> Did I mentioned that bzr check gives a traceback ?
<vila> ubotu: ^ ?
#bzr 2007-09-22
<mthaddon> Launchpad is going down in 15 mins for a code update. Estimated downtime is approx 1 hour
<lifeless> vila: hi
<lifeless> vila: two things, firstly you can only delete the line if its the last line
<lifeless> vila: if its not the last line you break dictionary references
<lifeless> vila: secondly, please keep NEWS in alphabetical order as per the list thread a few weeks back.
<Peng> Yay!
<Peng> 10 points to Launchpad for using a "503 Service Temporarily Unavailable" for the maintenance page.
<ubotu> New bug: #141629 in bzr ""bzr reconfigure" with no arguments throws an exception" [Undecided,Fix committed]  https://launchpad.net/bugs/141629
<mthaddon> LP going down for maintenance in 15 minutes for 1 hour
<Peng> Am I experiencing deja vu?
<Peng> :P
<Peng> What's up with LP?
<elmo> Peng: we ran into some problems during the previous maintenance  window, so it had to be rolled back.  we've resovled them and trying again to rollout the new code
<elmo> Peng: sorry for any inconvenience
<Peng> Ah.
<Peng> No problem or anything. I was just curious.
<vila> lifeless: soooo, I broke my repo dictionary reference because I didn't respect alphabetical order in NEWS... Naah, I can't believe that... Will drink another coffee first
<vila> lifeless: ok, so, the corrupted revision is the fourth from the end, you're saying I should delete the four to recover my repo. Should I track those revisions in the repository/knits hierarchy too ?
<vila> lifeless: About NEWS, I saw your first notice, I had read the thread but haven't realized the decision have been taken, I will comply. As soon as I can :)
<ubotu> New bug: #141555 in bzr-svn "Breakage with invalid SSL certificates (dup-of: 82086)" [Undecided,New]  https://launchpad.net/bugs/141555
<vila> bbib
* Starting logfile irclogs/bzr.log
<kgoetz> win 20
<vila> lifeless: no, was waiting for a confirmation, trying to reproduce it in clean env, etc
<vila> can't reproduce it so far :-/
<vila> lifeless: http://paste.ubuntu-nl.org/38243/   describes the corrupted revision
<vila> all zeroes, scary
<vila> Could your last tuned_gzip.bytes_to_gzip be related ?
<vila> My suspects so far: hardware problem (but find nothing else to confirm this),
<vila> NFS, the repo is on HFS+ on OSX, mounted as NFS, but the commit itself was from OSX
<vila> your last modification to tuned_gzip.bytes_to_gzip, but only because it modifies a code that may be related, I found nothing especially suspect in your modification, I just try to enumerate possible causes
<vila> this is mainly an annoyance because the repo holds everythin bzr related (including plugins) and it seems many commands try to read that revision even from branches that have nothing to do with it
<vila> for safety, I think I will reorganize this whole hierachy in several repos, just because I wanted to do that for quite some time
<vila> I lack time to hack as much as I want on this bug, but I may need to at least fix the .kndx (or several ? That's the point I want confirmation on) just to extract the right info (I still have several long lived branches in this repo)
<vila> I've made a backup of the whole hierarchy (888MB) and of the repo itself (93MO) and also from the .bzr.log of the two machines that may be involved
<vila> All are available for diagnosis
<vila> I lose some time doing that because tar suddenly told me 'file change while we read it' that scared me and made me think a little bit longer that I had an hardware problem (doing two consecutive tar and comparing them with cmp yielded ~3000 differences)
<fullermd> See what happens when you step away from the computer for a couple weeks??
<vila> After searching for the tar format and looking at the tar sources, it appears that some long file names triggers additional blocks containing the *current* date and time (sic), so false alert, I just learned that you can't compare two tar files :-/
<vila> fullermd: hehe, did you know about tar wart above ?
<fullermd> Not specifically what it was, but I did know that two tars of the same source aren't necessarily equal, even if they are equivalent.
<vila> fullermd: what a shame... apparently this is triggered by block checksums being different (so far so good), the blocks in question are special blocks preceding file header blocks for long file names
<vila> these blocks contain a mtime field, which is useless for them so they put 0
<vila> ... and somwhow this 0 is converted to current date... boom
<vila> fullermd: and the 'file change while we read it' rings a bell ?
<vila> I triggered it by asking OSX the size of the folder I was tar'ing, silly me, lost a couple more minutes for that :-/
<vila> the hard part was confirming that, indeed, OLDGNU_FORMAT (described in tar.h as 'obsolete RSN') was still the current format on OSX (and surely elsewhere) and that, yes, it includes an 'atime' field
<vila> Never figured tar knew about that....
<vila> lifeless: http://paste.ubuntu-nl.org/38244/ contains the .kndx files identified, thanks for confirming that deleting the lines (last of each file) will fix my repo (to the best of your knowledge :)
<vila> lifeless: I'm ready to loose the two branches involved, osx.pass.test.suite and bzr.integration
<tuXXX> When I bzr push on a sftp, files and directory aren't created, only .bzr, it this the correct behaviour?
<Peng> tuXXX: Yes.
<Peng> tuXXX: .bzr is all that's necessary to run bzr branch on it.
<tuXXX> Then I need a web front-end to display those files on my web server
<Peng> tuXXX: You can run "bzr checkout", then run "bzr update" in a cronjob or something.
<Peng> tuXXX: Or using bzr+ssh might do it, I dunno.
<Peng> tuXXX: Loggerhead is an advanced web front-end. I dunno about anything simple. There's bzr-webserve, but I'm not sure if it's maintained.
* Peng wanders off.
<tuXXX> sftp is useful because it doesn't need bzr to be installed on the server
<Peng> Yeah.
<GaryvdM> tuXXX - There is a plugin that does that. I'm just going to find it...
<GaryvdM> There is https://launchpad.net/bzr-push-and-update/
<tuXXX> ok
<tuXXX> bzr still needs to be installed server-side
<GaryvdM> Yhea :-(
<tuXXX> ok so I have to do a "bzr checkout ." on the server
<tuXXX> and it's work
<tuXXX> *and it works
<lapthrick> hrmm
<lapthrick> so Gutsy's bzr can't cope with https://
<vila> lapthrick: what do you mean ?
<lapthrick> vila: https://bugs.launchpad.net/bzr/+bug/141105
<ubotu> Launchpad bug 141105 in bzr "Crash with authenticated https checkout" [Undecided,New] 
<lapthrick> first I thought it was bzr-svn that was failing, but it turns out to die for plain bzr https:// uris as well
<vila> how so ? Can you try with https+urllib:// too ?
<lapthrick> sure
<AnMaster> gutsy? what is that
<lapthrick> newest ubuntu, not released yet
<AnMaster> ah
<AnMaster> <-- Gentoo user
<AnMaster> and FreeBSD
<lapthrick> vila: works with urllib, yeah
<lapthrick> I actually suspected it might be libcurl-gnutls's fault
<vila> I should definitely look at that new version, that error code 77 may indicate some API break somewhere
<lapthrick> ah, of course, you commented on that bug :)
<vila> lapthrick: you're using a stock gutsy is it ?
<lapthrick> aye
<vila> lapthrick: yeah, didn't recognize you as mathrick either :)
<lapthrick> :)
<lapthrick> I need to setup an irc proxy
<vila> lapthrick: if urllib is fine with you, keep using it, be aware that it makes *no* certificate verification though, track bug #82086 if you want to be kept informed on progress
<ubotu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed]  https://launchpad.net/bugs/82086
<lapthrick> vila: I see. That's strange though, as the original svn repo from that bug I have authenticated permanently with plain svn client
* lapthrick guesses "multiparent" plugin is not intended for end-user consumption yet
<vila> nothing strange in that :) svn should do proper certificate verification :)
<lapthrick> given the exceedingly brief help it has
<james_w> lapthrick: I think if you use svn+https:// for bzr-svn on that repo you will havee more success.
<lapthrick> vila: but isn't it supposed to re-use svn cache?
<lapthrick> james_w: yes, I needed a newer bzr-svn though
<lapthrick> I just got it, lesse if it works now
<vila> lapthrick: 1) I don't know what bzr-svn does, 2) we are not talking about credentials, we are talking about certificates
<vila> the server send a client saying: That's who I am (my certificate), this certificate have been validated by vendor$$$
<lapthrick> vila: yes, using svn client I accepted that certificate permanently
<vila> Ok, so it means bzr-svn doesn't use that
<james_w> I think jelmer says that bzr-svn works fine, it is just that bzr is probing for a bzr branch first, and so fails, adding svn+ bypasses this and goes straight to using the svn client, and so uses the stored information.
<lapthrick> ah
<lapthrick> james_w: that makes sense
<vila> ah
<lapthrick> mathrick@hatsumi:/tmp$ bzr cl svn+https://beta.aimido.de/svn/src2/trunk
<lapthrick> Segmentation fault (core dumped)
<lapthrick> :(
<lapthrick> it fetches the revisions info properly
<lapthrick> then dies
<lapthrick> cl == checkout --lightweight
<james_w> lapthrick: you should report that against bzr-svn, jelmer will want to know.
<james_w> a backtrace might be appreciated.
<lapthrick> mhm, if I can get a sensible trace
<james_w> I believe there are python debug packages, and maybe libsvn ones as well.
<lapthrick> yeah, I'll just check if it happens with branch as well
<lapthrick> seems to work just fine with branch
<lapthrick> hmm, isn't bzr status in an svn checkout supposed to work?
<lapthrick> it doesn't for me
<james_w> yeah it should I think.
<lapthrick> oh wait, wrong dir
<lapthrick> I forgot trunk/
<abentley> If you're getting a segfault, you should try running it under gdb.  That's a bug on the C side.
<lapthrick> abentley: I know :)
<lapthrick> h, what was the command to see the difference between branches?
<dato> in terms of revisions, `bzr missing`
<dato> (for diff, obviously `bzr diff`)
<lapthrick> yeah, I just saw missing
<lapthrick> thanks though
<lapthrick> hey jelmer_
<jelmer_> hi lapthrick
<lapthrick> jelmer_: seen my latest bugreport?
<lapthrick> I don't seem to be able to get a sensible trace, btw
<jelmer_> yep
<lapthrick> is python-dbg `which bzr` ... the correct way to get a backtrace from bzr?
<jelmer_> `bzr co --lightweight`is just an alias for 'svn co ...' btw
<lapthrick> jelmer_: oh
<lapthrick> mathrick@hatsumi:/tmp$ svn co svn+https://beta.aimido.de/svn/src2/trunk
<lapthrick> svn: Undefined tunnel scheme 'https'
<jelmer_> without the svn+ :-)
<jelmer_> ah, that's the problem
<lapthrick> jelmer_: hmm? So the svn client underneath dies and it crashes because of that?
<GaryvdM> bzr gdiff
<GaryvdM> err wrong window
<jelmer_> lapthrick: Yes, that's what I suspect
<jelmer_> GaryvdM: :-)
* lapthrick runs bzr shell
<lapthrick> it's noticeably faster
<GaryvdM> lapthrick: I gave up trying to set it up on windows
<jelmer_> lapthrick, can you try running that checkout command in gdb?
<lapthrick> jelmer_: and bzr-svn is , especially now I got it to check out my work repo
<lapthrick> jelmer_: I guess so
<lapthrick> jelmer_: ah, yes, that's much more sensible
<lapthrick> 0x080a215c in PyString_FromFormatV (
<lapthrick>     format=0x816de98 "'%.50s' object has no attribute '%.400s'",
<lapthrick>     vargs=0xbfb19f38 "\001") at ../Objects/stringobject.c:202
<lapthrick> 202     ../Objects/stringobject.c: No such file or directory.
<lapthrick>         in ../Objects/stringobject.c
<lapthrick> jelmer_: http://pastebin.com/m33018646
<jelmer_> thanks
<jelmer_> looks like another python-subversion bug
<lapthrick> I see
<lapthrick> jelmer_: why is there a difference between what schemes svn and bzr-svn handle anyway?
<jelmer_> lapthrick: bzr-svn supports everything that svn supports
<jelmer_> lapthrick: and it also supports 'svn+https' to work around that problem with SSL certificates
<lapthrick> jelmer_: yeah, but it was bailing out with the same error earlier, before I upgraded to 0.4.3
<Qhestion> hi. can i put my bzr installation (from the windows installer) on my usb stick?
<lapthrick> and isn't svn supposed to understand svn+https://? It's not uncommon to see urls like that on the net
<jelmer_> lapthrick: it supports svn+ssh://, svn://, http:// and https://
<jelmer_> lapthrick: which error did it bail out with earlier as well?
<jelmer_> Qhestion: you mean the files that it installed or the setup file?
<lapthrick> "Undefined tunnel scheme 'https'"
<Qhestion> the files it installed
<Qhestion> i just dont want to run the installer on the target machine
<Qhestion> (read: can't)
<jelmer_> Qhestion: should work ok as long as all the dependencies are installed
<Qhestion> dependencies?
<GaryvdM> Qhestion: I've never tried it, but I can't see why not.
<jelmer_> Qhestion: python, paramiko if you would like to use sftp, etc
<Qhestion> this is the "standalone installer"
<Qhestion> there shouldnt be dependencies
<Qhestion> and no sftp needed, only local (usb stick) repos
<jelmer_> Qhestion, not sure in that case, I don't know where that installs its python binary
<GaryvdM> Most of the dependencies are built into the installer, except the ssh stuff
<Qhestion> well, in C:\Programs\Bazaar there is a Python25.dll
<Qhestion> guess that is python ;)
<jelmer_> lapthrick: bzr-svn has to strip the svn+ bit for svn+http and svn+https before it passes urls to the svn libraries
<jelmer_> there was a bug where that wasn't happening in bzr-svn 0.4.1 I believe
<lapthrick> ah
<lapthrick> jelmer_: I thought svn+whatever was a general syntax
<GaryvdM> Qhestion: I'm sure it will work - give it a go
<Qhestion> i only have one try
<Qhestion> ;)
<lapthrick> Qhestion: can't you ask a random friend if you can test if it works?
<lapthrick> most probably they won't have bzr installed, so it's a good way to find out
<Qhestion> lapthrick: all my friends already got python ;)
<Qhestion> and bzr
<Qhestion> ya know, i need some people to test my software ;)
<Qhestion> i stopped programming in python, but i use Bazaar as version control system, and also to publish my sources
<Qhestion> hmm, i remember i should go back to the bazaar bugtracker
<Qhestion> filed a feature request there
<GaryvdM> Qhestion: I can do a test on my sisters machine when she gets home - probably in about 15 min.
<Qhestion> k
<Qhestion> thank you
<Qhestion> shall i send you a zip ?
<GaryvdM> ok
<GaryvdM> garyvdm@gmail.com
<Qhestion> woo 11 MB
<Qhestion> this will ake a bit
<jelmer_> lapthrick: you can add custom tunnel mechanisms to svn for the native svn protocol
<jelmer_> the http protocol is different though
<jelmer_> lapthrick, Thanks for the backtrace, I have to head out now, will have a look at it later today.
<GaryvdM> don't worry - I'll download the installer
<Qhestion> ok
<GaryvdM> Qhestion: It works
<GaryvdM> And my sister dose not have admin rights on her machine
<GaryvdM> s/dose/does
<Qhestion> Garyvd: thank you
<Qhestion> Garyvd: she does not have admin on her own machine? lol. good job ;)
<GaryvdM> It's a work machine from a big corporate...
<Qhestion> oh
<schierbeck> phanatic: hey
<phanatic> schierbeck: hi :)
<schierbeck> phanatic: i was thinking
<schierbeck> do you really need a date column in the viz treeview?
<schierbeck> it happens quite often with big projects that the window becomes too wide
<phanatic> good question, it's nice to see the date right away, not just in the details. but it often runs off the screen because of the graph being too wide
<schierbeck> phanatic: but i'd rather have a nice, easy-to-comprehend graph than a timestamp...
<schierbeck> i mean, it's not often you actually *need* to know the exact time of a commit, or do you?
<schierbeck> it may just be me...
<phanatic> yeah, you're probably right
<schierbeck> i think i'll create a branch and toy around with it
<GaryvdM> schierbeck, phanatic: I've hacked up a possible solution to reduce the with of the graph. I was just emailing phanatic about it.
<GaryvdM> s/with/width
<phanatic> actually i was thinking about redesigning the full thing. e.g. display only the graphs, and the details only when you move your mouse on a node. what do you think?
<GaryvdM> https://code.launchpad.net/~garyvdm/bzr-gtk/brokenlines
<schierbeck> GaryvdM: cool, as long as the graph is still easy to read
<schierbeck> phanatic: i like the commit message being there, and sometimes the author
<schierbeck> but there's no need for both the author name and email
<GaryvdM> Thats a good point...
<phanatic> indeed
<schierbeck> GaryvdM: i'm not sure about the new graphs, i took a look, and it's a bit curvy (?)
<schierbeck> of course, i'm no authority on the subject
<phanatic> GaryvdM: this brokenlines stuff is pretty interesing
<phanatic> schierbeck: imho they look better this way
<schierbeck> phanatic: okay, it seems i'm outnumbered in my favor of straightness :P
<phanatic> :D
<schierbeck> i really like the way broken lines are handled
<schierbeck> in the new branch, that is
<phanatic> yep, me too
<phanatic> does it load faster as well, or it's just me who feels it? :)
<GaryvdM> I hope so :-)
<GaryvdM> I should only be loading the revision data after the first screen is shown
<GaryvdM> I'm hoping I can get it to only load the revision data for a rivision when it is scrolled into view.
<GaryvdM> s/I/It
<phanatic> 2.625s on bzr.dev, that's quite impressive
<schierbeck> GaryvdM: do you think you could get the merge and branch-off lines to join at a different angle?
<GaryvdM> Yes - play with the curve controll points
<schierbeck> phanatic: i've made a version of viz without the date column, have a look: https://code.launchpad.net/~dasch/bzr-gtk/viz-remove-timestamp-column
<schierbeck> GaryvdM: ok, i'll look into it
<phanatic> huh, with current bzr-gtk trunk it takes 25.085s
<GaryvdM> viv/graphcell.py line 181-187
<phanatic> oops, 15.085s that is :)
<phanatic> but still 7 times more than with brokenlines
<ubotu> New bug: #144071 in bzr "dirstate-tags format is expensive for network operations?" [Undecided,New]  https://launchpad.net/bugs/144071
<phanatic> schierbeck: thanks, i will :)
<schierbeck> phanatic: i'm also looking into cutting off the email portion of the committer id
<phanatic> great
<phanatic> GaryvdM: what do you think: is brokenlines stable enough to get in into 0.91?
<GaryvdM> I don't know - I would love to have testing done on it.
<GaryvdM> Lots of new code.
<GaryvdM> s/more testing
<phanatic> fine, i won't merge it then before the release :)
<GaryvdM> Yhea - lets merge it just after the release.
<schierbeck> phanatic: the new version should have been pushed to lp now, got a little ahead of myself before
<schierbeck> i also tried making the graph column non-resizable
<schierbeck> i think it is actually better -- when do you *not* want to see the branch graph?
<phanatic> schierbeck: if it gets too wide, maybe?
<schierbeck> phanatic: perhaps, but i think the graph is the main feature of the viz -- without it, it's really hard to navigate
<phanatic> yes, you're right
<schierbeck> i think it's better to make sure the graph will almost never be too wide
<schierbeck> :)
<phanatic> that's where brokenlines comes into the scene ;)
<schierbeck> phanatic: i've pushed the changes to lp; the email part is now hidden in the treeview
<schierbeck> my implementation is not perfect; i guess the separation of name and email should go in bzrlib, not in bzr-gtk
<phanatic> i get a traceback here
<phanatic> Traceback (most recent call last):
<phanatic>   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/gtk/viz/branchwin.py", line 190, in populate_model
<phanatic>     committer = revision.committer.split('<')[0] .strip()
<phanatic> AttributeError: 'NoneType' object has no attribute 'split'
<phanatic> (i ran bzr viz on bzr.dev tree)
<schierbeck> phanatic: ok, committer can apparently be None...
<phanatic> yeah, it seems :/
<schierbeck> heh, there was a check for revision.committer is None one line above... doh!
<lapthrick> so, I have one branch A (which is mine), and now I want to incorporate another branch B (upstream, not mine) as a part of A, but in a way that would still let me merge further changes in A
<lapthrick> is that possible?
<lapthrick> both branches are created by bzr-svn btw
<lapthrick> *further changes in B
<schierbeck> phanatic: pushed a fix
<phanatic> wow, lp syncs pretty fast finally
<schierbeck> yup
<phanatic> schierbeck: looks fine to me :)
<schierbeck> phanatic: can it get merged into trunk, or is it too big a change of the ui?
<phanatic> i think it's sane change. and we don't have things like ui freeze :)
<schierbeck> lovely :)
<phanatic> schierbeck: you know the drill: add a NEWS entry, and i'll be all happy :P
<schierbeck> great
<Odd_Bloke> lapthrick: Are you asking if you can incorporate branch B into branch A but later be able to merge further changes from B into A?
<Odd_Bloke> lapthrick: If so, is branch A related to branch B at all?
<schierbeck> phanatic: added NEWS entry and pushed to lp
<lapthrick> Odd_Bloke: no, not at all related. I want to incorporate it as in I want all the files from B in A (in a subdirectory, too)
<GaryvdM> Do you want the rivision history from B in A?
<GaryvdM> If not, you can just use a nested directory
<GaryvdM> If yes - I think you need to use graft?
<lapthrick> GaryvdM: no, I don't really need the history of B past the point it got imported into A
<GaryvdM> http://spacepants.org/src/bzrgraft/
<lapthrick> GaryvdM: so I just copy it and that's all? What happens if at one point I decide to move a file outside B? Also, will A see B as a part of it (as in, I will commit and it will notice all those files that appeared)?
<GaryvdM> Are you talking about a nested branch?
<lapthrick> I think graft is not compatible with recent bzr's
<lapthrick> GaryvdM: I guess I am
<lapthrick> if I use a nested branch, will the branches understand their mutual relationship?
<GaryvdM> For a nested branch - you have two seperate branches with seperate rivision histories, but one is inside the other on the file system
<GaryvdM> Once you have imported B into A, will you need to merge changes from B's trunk into B
<lapthrick> GaryvdM: but I need them integrated. Basically I have a big repo A, and I have some outside vendor's source B I want to import. So I want A to contain all the files from B, but I want them also to retain their identity, so that when the vendor commits changes to their repo, I can just pull them and it'd do the right thing
<lapthrick> yet I also need to be able to manipulate the imported files myself, as the B sources are not usable for me pristine
<GaryvdM> I think a nested branches would be the best solution, but not perfect. Lets say you make a change to A and a change to B that go together, you would have commit seperatly to A and B.
<GaryvdM> But it would be easy to merge you changes to B with the vendors changes.
<lapthrick> GaryvdM: okay, so when someone branches off A, will they also get a copy of B?
<GaryvdM> no
<lapthrick> so that's not really a solution for me, I need A to actually have all of B in it
<lapthrick> so basically I need 'bzr steal' functionality
<lapthrick> GaryvdM_: how hard would it be to add such 'bzr steal' function?
<lapthrick> hmm, I wonder if multiparent does anything of what I want
<GaryvdM> lapthrick: I don't know - I have only been hacking on bzr-gtk for about a month.
<lapthrick> I see
<schierbeck> GaryvdM: do you think revision id deserves its own column in the viz window? i tend to prefer a tooltip instead
* lapthrick pokes people he suspects have a clue, like lifeless, abentley and james_w
<GaryvdM> No - it's very long
<lapthrick> https://launchpad.net/bzr-merge-into/
<lapthrick> oho!
<GaryvdM> I supect that you are talking about the revision number column though
<schierbeck> GaryvdM: sorry, i meant revision number
<GaryvdM> Well  - Someone loged it as a feature request: https://bugs.launchpad.net/bzr-gtk/+bug/64167
<ubotu> Launchpad bug 64167 in bzr-gtk "bzr viz don't show revno for main revisions" [Wishlist,Fix committed] 
<schierbeck> hmm, it says "fix committed" -- where's the fix?
<schierbeck> (using trunk)
<GaryvdM> Viz is being used for 2 things - a GUI for Log - and a graph renderer
<GaryvdM> I't commited to https://code.launchpad.net/~garyvdm/bzr-gtk/vizchanges, but not to trunk yet
<schierbeck> GaryvdM: ok
<schierbeck> as a column or a tooltip?
<GaryvdM> May be we need a interface to select what columns the user wants
<phanatic> GaryvdM: btw we assume that "Fix committed" means it was committed to trunk (just a sidenote)
<GaryvdM> Oh
<GaryvdM> Changed
<abadger1999> abentley: around?
<lapthrick> does John Arbash Meinel IRC? And if so, what nick does he use?
<phanatic> lapthrick: jam
<lapthrick> doesn't really seem to be here
<phanatic> lapthrick: 1. it's weekend 2. he's on us time
<lapthrick> true
<james_w> 3. he's got a new son.
<james_w> lapthrick: I can't spot your question, would you mind repeating it?
<lapthrick> james_w: yes, I basically want to do what merge-into provides: merge in outside code into my own branch, whilst still retaining the ability to pull in later changes in upstream
<lapthrick> at least if I understand merge-into's scope correctly it's supposed to do that
<james_w> and merge-into isn't what you want?
<lapthrick> james_w: it is, but doesn't work
<lapthrick> https://bugs.launchpad.net/bzr-merge-into/+bug/144108
<lapthrick> just finished writing
<ubotu> Launchpad bug 144108 in bzr-merge-into "Doesn't work with 0.90 --  no attribute 'base_is_other_ancestor'" [Undecided,New] 
<lapthrick> if I can get this fixed, I no longer will have to put up with stupid subversion crap
<james_w> lapthrick: thanks, caught up now.
<james_w> so, I believe merge into is now superceded by by-value nested trees, so I think that should solve your problem.
<james_w> however I don't really know how they work, and they are still experimental.
<james_w> and by-reference nested trees are currently completely broken, so maybe by-value are too.
<lapthrick> ouch, I don't really understand what you just said
<james_w> do you understand nested trees?
<james_w> as in you have one tree (branch) tracked as part of another.
<lapthrick> james_w: yes, the concept is pretty clear and incidentally exactly what I want (as long as I am still able to move parts of the inner tree to the outside one)
<james_w> yeah, it sounds like you want a by-value nested tree.
<lapthrick> what's the difference?
<james_w> by-value means that the contents are tracked, by-reference means that just a pointer is tracked.
<lapthrick> I see
<lapthrick> so yeah, by-value
<james_w> by-value is just breaking up a branch so that you can branch from a sub-directory of it.
<ubotu> New bug: #144108 in bzr-merge-into "Doesn't work with 0.90 --  no attribute 'base_is_other_ancestor'" [Undecided,New]  https://launchpad.net/bugs/144108
<james_w> but also allows you to merge as you want I hope.
<james_w> merge-into was jam's plugin to do by-value before nested trees were started.
<lapthrick> james_w: excellent, bzr + bzr-svn == all bzr , no stupid svn 
<lapthrick> as long as it works, that is :)
<james_w> yeah, you shouldn't have to touch svn
<james_w> lapthrick: I have an idea for fixing merge-into, wnat to try it?
<james_w> edit merge_into.py, and on the line (near the end) before conflicts = merger.do_merge() insert merger.find_base()
<lapthrick> james_w: sure
<james_w> that should set the missing attribute, but whether it will work is another question.
<lapthrick> okay, lemme try
<lapthrick> "Branches have no common ancestor, and no merge base revision was specified."
<lapthrick> james_w: success was not full it seems
<james_w> indeed.
<james_w> perhaps try in __init__ just set self.base_is_other_ancestor = False and remove the other change.
<james_w> I'm not sure what the effect will be, but it sounds like that will never be true in this case.
<lapthrick> yeah
<james_w> or I have another suggestion.
<james_w> where you put find_base before put set_base_revision
<james_w> merger.set_base_revision(revision.NULL_REVISION, branch_to_merge)
<james_w> you will need to do from bzrlib import revision before
<james_w> after that I'm a bit stuck for ideas.
<lapthrick> james_w: okay, lemme try that
<lapthrick> james_w: are those two separate ideas, or a single change?
<james_w> two separate, I would try the second one first, it seems like less of a hacky change.
<james_w> even if it is unlikely to work/
<lapthrick> <james_w> merger.set_base_revision(revision.NULL_REVISION, branch_to_merge)
<lapthrick> this one, set in place where I previously did find_base?
<james_w> yes.
<james_w> adding the import statment just above.
<lapthrick> should I also add find_base call?
<james_w> or add revision to the list of imports at the top.
<james_w> no, the find base is the wrong one, it should be deleted, as I see it will never work here.
<lapthrick> okay
<lapthrick> james_w: awesome, that worked
<lapthrick> I will post a patch for that bug then
<james_w> wow.
<james_w> did you try it on your branches as well?
<lapthrick> james_w: yes, bzr missing --other ../other shows nothing
<lapthrick> which is exactly what I expected :)
<james_w> horsesome.
<lapthrick> I'm gonna try pulling some changes from upstream now
<lapthrick> hmm
<lapthrick> james_w: http://pastebin.com/m1a097d9d
<james_w> lapthrick: so is that file named foo.html or pokersource/foo.html in ../../pokersource?
<lapthrick> james_w: foo.html, if I wanted to access it, I'd say ../../pokersource/foo.html
<james_w> and when you did the merge-into you made it put the contents of the ../../pokersource branch in pokersource/ ?
<lapthrick> james_w: yes
<james_w> that's a good sign I think then.
<lapthrick> how so?
<james_w> it knows how to resolve that file in to the subdir.
<lapthrick> do you mean it can be fixed, or that it's not broken?
<james_w> so I think a path conflict comes when you add a file of the same name in two branches independently
<james_w> which would suggest that the merge-into messed up the file-ids.
<james_w> but the fact that it knows that ../.../foo.html corresponds to pokersource/foo.html means that it got something right.
<lapthrick> ah
<james_w> lapthrick: it's definately broken, I was just commenting that it seemed to be at least partially right.
<lapthrick> james_w: can I get it to tell me file-ids?
<james_w> It may be fixable.
<james_w> lapthrick: I'm not sure about command line. I can do it with bzrlib easily if you want to.
<james_w> python
<james_w> >>> import bzrlib
<james_w> >>> from bzrlib.workingtree import WorkingTree
<james_w> >>> t = WorkingTree.open_containing('.')
<james_w> >>> t.path2id(path)
<james_w> however I'm not sure which id you will get it the conflicting case.
<james_w> if you revert, and then check pokersource/foo.html in this branch, and then foo.html in the other they should be the same.
<lapthrick> >>> t.path2id("pokersource/foo.html")
<lapthrick> Traceback (most recent call last):
<lapthrick>   File "<stdin>", line 1, in <module>
<lapthrick> AttributeError: 'tuple' object has no attribute 'path2id'
<james_w> t = t[0] 
<james_w> I always forget that one.
<lapthrick> james_w: and how do I retrieve the id now? It didn't return any value
<james_w> I'm also not sure whether it's the fact that you are doing a delete that is causing the issue.
<james_w> >>> t.path2id should work now.
<lapthrick> yes, but it doesn't return anything
<lapthrick> well, returns None
<james_w> that means the file is not versioned.
<james_w> did you revert first?
<lapthrick> no
<james_w> try the reverted case first, and also uncommit + revert in the other branch to test that one.
<james_w> let's check that it thinks the two files are the same first, then work out what causes the conflict.
<lapthrick> >>> t.path2id("pokersource/foo.html")
<lapthrick> 'foo.html-20070922173216-lw0yu2ouatfdvc2r-1'
<lapthrick> >>> t.path2id("foo.html")
<lapthrick> 'foo.html-20070922173216-lw0yu2ouatfdvc2r-1'
<lapthrick> so they got the same ID
<james_w> that's good. bzr will equate the two.
<lapthrick> james_w: indeed, non-rm change works just fine
<james_w> you may get the conflict as you are doing a delete. Can you instead try an edit in the upstream branch and then merge that.
<james_w> ah, that's good then.
<lapthrick> yeah, I just did :)
<james_w> I wonder where that conflict comes from then.
<james_w> you could look at the conflicts documentation.
<lapthrick> what do you mean?
<james_w> http://pastebin.com/d4818a9e7
<james_w> there is a conflicts section of the user guide.
<james_w> I guess this is the parent directory case.
<james_w> so bzr sees 'rm foo' in one branch and 'mv foo ...' in the other and doesn't know who to listen to.
<james_w> lapthrick: it appears to be working, so you could resolve the conflicts as a workaround, and then ask on Monday for any ideas for a fix.
<lapthrick> james_w: hmm, but why does it see mv?
<lapthrick> james_w: yep, it's already much much awesomely better than trying to do the same with subversion :)
<lapthrick> I love how bzr is the best available svn client
<james_w> well, one tree has / as the parent, the other has /pokersource/ and so it considers it a move I guess.
<lapthrick> james_w: oh, I see. So we need to muck the path in there to make it see pokersource/ as the parent where needed
<lapthrick> as / I mean
<james_w> bzr doesn't actually record moves, it just preserves file ids, and then sees name and parent directory changes as moves later I believe.
<lapthrick> james_w: in any case, huge thanks for the help
<james_w> lapthrick: no problem. This fix is probably a bit in depth for me.
<lapthrick> maybe jam will come around on monday
<lapthrick> right now I have it working, I don't need to pull in any actual change yet, so it's really not a big issue
<james_w> that would be one fix, but I'm not sure that you could enforce that without massive changes (aka nested trees I guess).
<lapthrick> yeah
<james_w> and the conflicts should be easy to solve, and perhaps rare.
<lapthrick> otherwise it'd try to move to /.., and that just doesn't make sense
<james_w> I guess the nested tree support there is may provide a way to fix this.
<lapthrick> yeah, I'm more than happy to move to that once it's not broken
<james_w> I guess jam maybe knew this was a limitation, but it was 'good enough'.
<james_w> it needs someone to pick it up, and most of the core devs are on performance at the moment.
<james_w> lapthrick: could you mail a bundle to the bug report with your fix please?
<james_w> I'm off out now, so I can't commit it tonight, but if it's in my inbox it will remind me to do it tomorrow.
<lapthrick> james_w: sure
<james_w> thanks.
#bzr 2007-09-23
<et_> Running 0.18.0. Have checkout. Tried to commit. Got "ERROR: parent_id ... not in inventory". Have no clue what caused this happen, or how to correct it.
<et_> Looks like if you bzr moved a file, and try to commit another file without first commiting the move, you get this error message. The work around is to commit the move first.
<vila> 4. he's got a *first* baby :)
<lapthrick> can you uncommit a revision from the middle of the history?
<lapthrick> like, if the current revision is, say, 3000, can I uncommit rev 2900 only?
<lifeless> lapthrick: no, uncommit just pops the top off the branch, recursively
<cory> I'm confused that adding identical files is a conflict.
<dato> cory: when you `bzr add` the same file in two different branches, each of them gets assigned a different file-id, which is the id bzr uses to know if they're the same file or not
<cory> I understand.  I guess my gut expectation though is that it clobber files with the same name so that I can do a bzr status to see if they've actually changed, myself.
<cory> Also, if, say, I accidentally reverted that part of a merge and kept the files different, I have no idea how to cause them to merge again.
<cory> It's unfortunately guaranteed to happen the way I'm trying to round-trip changes with p4. :P
<lapthrick> jelmer: poke?
<lifeless> moin
<lifeless> cory: ping
<cory> lifeless: Hiya.
<lifeless> hi
<lifeless> you're working on a p4 round-tripper ?
<cory> pong?
<cory> I just have some sketchy scripts I threw together.  One to automate bringing changes from p4 to bzr, and one that just opens files for edit / add / whatever by comparing the current working tree and p4 branch in bzr.
<lifeless> ok
<cory> The first should really just be tailor, but fixing that was more daunting than making something that would work for now.
<lifeless> so a couple of notes about the guts that may help you
<lifeless> tailor is, IMO, broken by design
<lifeless> because its a lowest common denominator approach
<cory> Sure.
<lifeless> I prefer high fidelity myself
<lifeless> anyhow, bzr has an inode concept
<lifeless> files are accessible by path, but identified by 'inode', which we call 'file-id'
<cory> How would I take advantage of that?
<lifeless> we have some sketches for recording copying and merging of file-ids. When we have that it will be possible, and occasionally sensible, for merges that end up with a file with mostly the same content, at the same place, to be merged rather than placed alongside each other
<cory> Ah, neat.
<lifeless> but until those sketches are turned into reality you have a bit of a problem :)
<lifeless> there are a few ways around the issue
<lifeless> bzr-svn, which has the same issue, tackles it by assigning deterministically unique file-ids
<lifeless> which gives e.g. README in all branches of the same project on the same svn server the same fileid
<lapthrick> http://pastebin.com/m63022805 <-- more bzr-svn fun
<lifeless> but unique across all other svn servers
<cory> Hrrrrm.
<lapthrick> apparently you can't merge-into from an SVN repo, it goes wrong at some point
<lifeless> lapthrick: merge-into is a plugin command, it possibly uses the bzrlib api in ways that the bzr-svn author hasn't accomodatd.
<cory> How do files get added to a branch from the bzr side when you're working with bzr-svn?
<lifeless> lapthrick: I would file a question on bzr-svn about that
<lifeless> cory: bzr add :)
<lapthrick> lifeless: you mean a question and not a bug now?
<cory> Does bzr-svn get involved and make sure the file has a proper file-id?
<lifeless> lapthrick: I suggest you work with 'bzr checkout svn:// && bzr merge && bzr commit' because that will preserve the history the same as merge-into, with the advantage of working.
<lifeless> lapthrick: yes, its not clear where the bug is.
<lifeless> lapthrick: so ask for help :)
<lifeless> cory: perhaps I misunderstood your question. I thought you meant 'bzr branch svn:///  foo && cd foo && touch BAR && bzr add BAR && bzr commit && bzr svn-push svn:////'
<cory> Oh, or is the original file-id stored in an svn property?
<lifeless> cory: yes, bzr svn-push (it will be integrated with bzr push sometime) annotates the svn repository
<lapthrick> lifeless: but plain merge won't result in having a branch in a subdir, I do have it working with a branch made out of SVN, I just wanted to reduce the number of intermediate steps between upstream SVN and my branch-in-subdir
<lifeless> lapthrick: I don't understand what you mean
<lapthrick> lifeless: well, I don't understand what I'm supposed to merge
<lifeless> lapthrick: what are you trying to do then?
<lifeless> cory: so if you don't want to annotate p4, you can just do a one-way solution, as long as the ids in different branches for the same file are the same bzr will be happy
<lifeless> cory: when you add a file on the bzr side, you will have a history disconnect after you get it coming back at you from p4, just take the p4 version always
<lapthrick> lifeless: the same as I was doing yesterday (have a branch of an upstream SVN repo inside a subdir of my own repo), but pulled directly from SVN, instead from my-branch-of-upstream-SVN that serves no other purpose than to mediate between upstream SVN and my branch-in-a-subdir
<cory> lifeless: Yeah, that sounds sensible.
<lifeless> cory: and do a manual merge (patch foo < diff foo.ORIG foo.THIS)
<lifeless> lapthrick: do you mean 'repo' or 'tree' ?
<lapthrick> lifeless: tree
<lifeless> lapthrick: the terms are not interchangable for bzr.
<lapthrick> yeah, I guess
<lifeless> lapthrick: so, you have tree-root/upstream
<lifeless> where tree-root is a bzr tree
<lifeless> and upstream is a svn checkout ?, or a bzr-svn branch from svn ?
<lapthrick> lifeless: http://pastebin.com/m1a7e323
<lapthrick> is it more clear?
<cory> Random thought...or there could be something like patch queue manager performing the actual p4 submits. :)
<lapthrick> what's p4?
<lifeless> lapthrick: I don't have a browser here
<cory> lapthrick: perforce
<lifeless> lapthrick: perforce, a vcs
<lapthrick> lifeless: sec, I'll paste it in private
<lifeless> k'
<lapthrick> cory: so you're writing p4 integration?
<lifeless> adhoc version I think
<lifeless> rather than e.g. bzr-p4
<cory> Just hacking enough together to get by. :P
<lapthrick> ah, so just a single project that's somehow dependent on p4?
<lifeless> lapthrick: I'm still confused; what is the relationship between mytree and myupstream; did you bzr join? or are you using the alpha-quality nested trees support?
<lifeless> lapthrick: its hard for me to understand what you mean, as your commands used paths that did not exist (you branch to myupstream, then cd to mytree; I can't tell what mytree is meant to be there)
<lapthrick> lifeless: mytree is a pre-existing tree I want to have upstream as a part of. I want to get the same effect as bzr join would have, but I'm using merge-into for that
<lapthrick> not nested trees
<lifeless> I don't understand why you use merge-into, rather than cd + bzr pull
<lifeless> merge-into is for doing *merges*, and if you are not changing the upstream, and its just a separate tree that happens to be positioned one dir down, then pull should work fine
<lapthrick> lifeless: because I want to have upstream/ be seen as a part of mytree. Mytree is actually backed by an SVN repo, so when I push into it, I want upstream/ be uploaded as well
<lapthrick> I'm essentially using bzr to manage SVN for me
<lifeless> ok
<lifeless> so if you want the content to be added and managed, you need to combine the trees.
<lifeless> that means 'bzr join myupstream'
<lapthrick> but that's really experimental, right?
<lapthrick> merge-into does the same, except without real nested trees support
<lapthrick> (and with slight caveats because of that)
<lapthrick> lifeless: will I get burnt badly if I use bzr join?
<lifeless> merge-into does an implicit join
<lifeless> you've already joined
<lifeless> after that you should just use regular merge
<lapthrick> yes, I know
<lapthrick> lifeless: it works, as long as I don't try to merge-into directly from svn://
<lapthrick> if I have that intermediate bzr-svn branch, it works like a charm
<lifeless> lapthrick: but why are you running merge-into more than once
<lifeless> lapthrick: I don't see why the intermediate branch is a problem as you only need it once
<lapthrick> lifeless: I'm not, those were two different cases. First is what I did (and what worked), second was what I'd like to do
<lifeless> so, I'd definately record this somewhere
<lapthrick> lifeless: oh, so I can merge with svn:// later on?
<lapthrick> if so, it's even better
<lifeless> so that jelmer/john can look at the error
<lifeless> but merge-into is used to perform the join
<lapthrick> yah, will do
<lifeless> you should not keep using merge-into
<lapthrick> I'm not, I used it only once
<lifeless> righto. So now you use bzr merge svn:// and that should work
<lapthrick> apparently it does, missing --other reports nothing
<lapthrick> lifeless: thanks, I didn't realise I could do that
<lifeless> thats something John should add to the plugin docs
<lapthrick> now I just need to figure out how to prod bzr-svn into making an actual SVN branch (ie. one that will result in a branch being created in the SVN repo)
<lifeless> bzr svn-push ?
<lapthrick> hmm, or I can do it by hand and then rebind
<lapthrick> lifeless: will it have the same effect as doing cd svncheckout && svn cp trunk branches/mybranch && svn commit ?
<lifeless> I don't know
<lapthrick> ah, right, that's what it should do I guess
<Lo-lan-do> Anyone knows whether jelmer works freelance?
<lapthrick> let's test it on something that's not my job repo though :)
<lifeless> Lo-lan-do: he's at uni still AFAIK
<lifeless> hi keir
<Lo-lan-do> Hmm.
<keir> lifeless, hey
<keir> lifeless, RL has been giving me the smackdown lately
<lifeless> I know the feeling
<keir> lifeless, so i haven't touched the indexing backend in awhile
<lifeless> I only made incremental partial commit 40% faster last week  :()
<keir> that's sweeeet!
<lifeless> index reading is 14% of the remaining overhead !
<keir> lifeless, cool
<keir> lifeless, is that because it has to read the entire index?
<lifeless> yes
<lapthrick> awesome, it works
<keir> lifeless, when do you expect to merge packs?
<lifeless> keir: I'm hoping this week to have the code in bzr.dev
<lapthrick> is there a way to retroactively change the committer on revisions? I have some revisions committed with the wrong name and would like to avoid mucking around with shelve if possible
<keir> lifeless, neat!
<lifeless> format freeze will be once the index read issue is fixed
<keir> lifeless, have you looked at all at my code?
<lifeless> keir: at some yes
<lifeless> not at all
<keir> lifeless, i won't be able to touch it until tuesday
<lifeless> thats fine
<keir> lifeless, i feel like the code has become too complicated, and i'd like a second opinion
<lapthrick> so what about changing the committer? Is that possible?
<keir> lapthrick, uncommit and re-commit?
<lifeless> lapthrick: bzr does not support altering or annotating existing revisions
<lapthrick> keir: I wanted to avoid doing that
<lapthrick> hmm, okay
<lifeless> lapthrick: we currently feel that this is too much complexity for too little return
<keir> lifeless, what about the 'nuclear launch codes' problem?
<lifeless> keir: uncommit and garbage collect
<keir> lifeless, i've personally run into that and had to hex edit a svn repo
<lifeless> there are plugins that can create new revisions from existing, preserving the deltas etc
<keir> lifeless, aah, ok. in my case it was several revs behind
<lifeless> but the *meaning* of the revision changes when you remove a file from it
<lifeless> or change its content
<lifeless> its hash changes
<lapthrick> okay, so what will be the easiest change to pop a series of commits, then recommit them, just with a different name? If I could avoid typing in commits messages anew, it'd be helpful
<lapthrick> s/easiest change/easiest way/
<lifeless> lapthrick: check the rebase plugin out; AIUI it will do what you want
<lifeless> of course, it may not ;)
<lapthrick> ah, right
<lapthrick> I wonder how experimental it is
<lapthrick> bzr bzr-pokerolymp:2085/> log -r ancestor:svn+https://beta.aimido.de/svn/src2/trunk
<lapthrick> Unhandled error:
<lapthrick> 'NoneType' object has no attribute 'base'
<lapthrick> interesting
<lifeless> bug filin' time  :)
<lapthrick> bzr bzr-pokerolymp:2085/> log -r branch:svn+https://beta.aimido.de/svn/src2/trunk
<lapthrick> A write attempt was made in a read only transaction on LockableFiles(lock, file:///home/mathrick/Dev/rails/bzr-pokerolymp/.bzr/repository/)
<lapthrick> man, I'm good :)
<lifeless> intereseteing
<lifeless> log should be read only
<lifeless> I'm better bzr-svn is the culprit
<igc> morning all
<lifeless> hola
<lifeless> you're up early :)
#bzr 2008-09-15
<jml> poolie: may I join the call?
<poolie> yes
<poolie> just fiddling with linux audio :/
<jml> ahh :)
<spiv> That's an endless source of joy.
 * jml finds a bzr bug
<jml> http://paste.ubuntu.com/47016/
<spiv> jml: is it normal that it takes almost a minute to authenticate to bazaar.staging.launchpad.net?
<mwhudson> sadly, yes :/
<jml> spiv: there's a graph of auth times available internally
<jml> so what's the deal with KeyError?
<justizin> so hey guys, someone said a while back, and i know i ask once in a while about this because i don't have latest bzr and haven't started using, but there is a semi-equivalent to svn:externals in bzr being worked on, or maybe in 1.6, but i can't find it in docs or anywhere..
<spiv> jml: https://bugs.edge.launchpad.net/bzr/+bug/208869
<ubottu> Launchpad bug 208869 in bzr "info -v fails over bzr+ssh" [High,Confirmed]
<jml> oh. fun.
<justizin> i have access to an ubuntu intrepid box with 1.6 now so want to plan to use that feature if possible..
<poolie> jml, i wish it was faster to put tags on bugs
<lifeless> justizin: its not baked yet unfortunately; the feature is called nested trees, and LarstiQ has a bzr branch on launchpad with it
<jml> poolie: me too.
<jml> poolie: we might actually make it so over the next couple of months.
<justizin> i'd love to help test, i make heavy use of svn externals and have replaced it for now with a bash script in my bzr repo that just fetches the contents of EXTERNALS.txt, but i'm looking to mirror all our svn dependencies in bzr so that i can hand-merge upstream changes, be aware, etc.. and get off svn.
<jml> poolie: is there a "this shows users a stack trace zomg fix it now" tag?
<poolie> for bzr?
<justizin> it's a handy feature but bzr's list tips the scales pretty heavily away from it either way
<poolie> not really
<poolie> just set importance=zomg
<justizin> it is a one-liner to fetch the externals, and i'm soon going to just use bzr to fetch either bzr or svn externals, and make our file contain svn+http urls
<justizin> lifeless: I'll try to find the branch in lp :)
<lifeless> jml: lots of things show stack traces; its not a great metric for how many users it affects
<justizin> lifeless: do you know anything about the feature's current design?
<lifeless> jml: we try to set importance by normalising frequency and impact
<justizin> is it like a shared repo?
<lifeless> justizin: not really, shared repos just optimise storage
<lifeless> brb
<justizin> well, i mean, i guess a better formed question would be, does it use a shared repo, or similar func, to optimize storage..
<jml> lifeless: sure. It's something dear to me because I've had reports from friends who show off bzr to *their* friends and then get all embarrassed because of stack traces.
<lifeless> jml: is it the branch-history one? wtf is branch-history anyhow :P
<jml> lifeless: it's https://bugs.edge.launchpad.net/bzr/+bug/208869 â  info -v fails over bzr+ssh
<ubottu> Launchpad bug 208869 in bzr "info -v fails over bzr+ssh" [High,Confirmed]
<jml> oh look, ubottu doesn't suck :)
<jml> poolie: I get this with your branch: http://paste.ubuntu.com/47029/
 * jml tries a couple of things to ensure not pebkac
<jml> yeah, looks like a bug.
<poolie> jml, interesting
<poolie> thanks
<jml> poolie: np
<lifeless> spiv: ping
<lifeless> poolie: ping
<spiv> lifeless: pong
<poolie> lifeless, hi
<lifeless> spiv: is the hash for a char-converted-to-int the same as a 1-length string containing the same char (for dict lookups from C python)
<spiv> lifeless: I don't know, I'd guess not.  It's certainly not guaranteed.
<lifeless> pyrex FTL then :P
<spiv> Yep, definitely different.
<lifeless> it translated _minikind_to_kind[minikind] to _minikind_to_kind[PyLongInt_FromInt(minikind)]
<lifeless> when I made minikind into a cdef char, rather than a python string
<poolie> lifeless, was that all you wanted?
<lifeless> poolie: yeah, echannel :P
<poolie> intrepid wants to reboot now, biab
<spiv> lifeless: Hmm, maybe pyrex things _minikind_to_kind is a C array rather than a dict, or something?
<spiv> Oh, except obviously not if it's doing PyLongInt_FromInt.
<spiv> Anyway, that does seem badly broken :)
<spiv> lifeless: python -c "for i in range(256): print i, hash(i), hash(chr(i))", btw :)
<lifeless> spiv: yeah, I wasn't going to list all the C Python API calls to do the dict lookup
<lifeless> I was just showing the key 'oops' moment
<lifeless> 2.4 seconds now
<lifeless> oh, thats by cheating. doh.
<spiv> :)
<lifeless> ok, thats annoying
<lifeless> we put every dir into a dict during st
<lifeless> if there are no renames, epic fail.
<lifeless> spiv: is there a constant value for True and False in CPYthon ?
<mwhudson> Py_True
<jml> I would like to make a branch using make_branch that has a stackable branch format and a non-stackable repo format.
<jml> what's the easiest way of doing this?
<spiv> jml: heh
<spiv> jml: take a look at the mail I *just* sent to the bazaar@ list
<jml> I saw :)
<jml> slightly different though.
<spiv> jml: TestCaseWithMemoryTransport.make_branch unfortunately ignores shared repos.
<jml> spiv: I don't need shared repos, just a non-standard branch/repo format pair
<spiv> And doesn't give you any way to specify non-standard format groupings.
<jml> :)
<spiv> I suppose you could register a new format in the bzrlib.bzrdir.format_registry
<jml> I'll just steal code I have elsewhere that does what I want (but doesn't use make_branch)
<spiv> But simplest is probably to instantiate a custom BzrMetaFormat1 and set the *_format attributes appropriately
<jml> *nod*
<poolie> lifeless, ping?
<poolie> i want to run something past you re bug 261315
<ubottu> Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315
<poolie> either before or after lunch
<poolie> that is basically, is it reasonable for the RemoteBranch to get the branch.conf file and interpret it itself to extract the fallback url, rather than relying on the server to do this?
<poolie> i think it is
<lifeless> poolie: you mean via VFS calls?
<lifeless> poolie: or delegated to _real_branch?
<lifeless> poolie: accessing branch.conf from RemoteBranch, directly, would be unreasonable - abstraction violation IMO
<poolie> re branch.conf
<poolie> it kind of is
<poolie> otoh i'm not sure why it's exposed by an rpc if the client is not supposed to read it directly
<poolie> maybe this is a spurious historical reason
<lifeless> err
<lifeless> you've lost me
<lifeless> simple thought experiment, imagine the branch at the other end is a bzr svn branch
<lifeless> or a BzrBranch5
<lifeless> neither of which have branch.conf
<poolie> sure, that's just the case i'm thinking of
<lifeless> an rpc can abstract that
<lifeless> without the client having the format's code locally
<poolie> my point is it's odd that RemoteBranch supplies a get_config() method
<poolie> well
<lifeless> why is that odd?
<poolie> arguably that can represent the configuration file as any object
<lifeless> SvnBranch supplies such a method, and so does Branch5
<poolie> i meant to say Branch.get_config_file,
<poolie> and it's no longer called, i removed it a while ago iirc
<poolie> so that's ok
<poolie> spiv, ping?
<poolie> my current plan for this is then
<poolie> first off, read it through the real branch at RemoteBranch construction time
<poolie> this is unfortunately going to cause all branches to do vfs operations
<poolie> but we need to do this to work with older servers
<spiv> poolie: pong
<poolie> then, add an rpc that gets all the information we need when opening a branch: repository location, last revision, stacking, etc
<poolie> probably called Branch.open_v3 or something
<poolie> then change the client to call this, and only if the server fails go back to using the vfs
<spiv> That sounds good to me.
<poolie> so the fact that we have to be able to do it over vfs suggests i should get that going first
<poolie> if we do that second stage we will save some roundtrips when opening a branch
<poolie> but we need to think a bit about where to cache it
<poolie> the straightforward thing would be to just naively cache it in the RemoteBranch object indefinitely
<poolie> however, the general approach aaiu is that caching should be scoped by locks
<spiv> How do non-remote branches handle caching of stacking info/
<spiv> ?
<poolie> so then there seem to be a few options
<poolie> apparently they don't cache it
<poolie> heh, nice question :)
<poolie> so, the stacking info does not particularly need to be cache because it's normally only used from the constructor to open the repository
<poolie> caching it would not be particularly important for performance
<poolie> and if we can arrange to make this open_v3 call from the constructor or nearby we would not need to call it either
<poolie> i guess i was thinking more about putting other things like the last_revision into the same call
<poolie> where it both would be important to call it and also it's quite likely to change
<spiv> Hmm, last revision info is currently cached, and that cache's lifetime is managed by locks.
<spiv> Possibly what's missing is an open-and-immediately-read-lock operation?
<poolie> um, also, if the only higher-level rpc that reads the stacking location is the open_v3 one, then presumably it needs to be cached for commands like info that might ask for it later
<poolie> this does seem related to creating objects locked
<poolie> both on disk when we start writing to them and also in the api
<spiv> Right.
<poolie> spiv, how is the lifetime managed by a lock?
<poolie> afaics it isn't
<spiv> See BzrBranch.unlock
<spiv> It calls _clear_cached_state
<spiv> RemoteBranch also calls _clear_cached_state on unlock.
<poolie> ah
<poolie> right
<poolie> i was mislead a bit by the lack of a call to the super constructor, but there is a comment saying why
<poolie> though it's still a bit tasteless
<poolie> so it would be a bit dodgy but we could cache it there from the constructor and it would last until the object is first unlocked
<lifeless> uhm
<lifeless> thats lots dodgy
<lifeless> if you want an idiom for open-locked, do that as a separate branch IMO, possibly lots of things that can break
<poolie> sure
<poolie> so if we don't do that, it seems necessary to add a specific fine-grained api to get the stacked location
<poolie> this could be done in addition to putting it in the constructor
<poolie> i guess we need one to set it so it's not unreasonably increasing the number of available apis.
<lifeless> didn't jml put up a branch to allow getting stacked location from the branch format object?
<jml> lifeless: it was rejected.
<lifeless> we do have api's for settings and getting the location already
<jml> the problem for me was that I needed a Branch object to use BranchConfig
 * poolie reads
<poolie> ok, i read that thread
<jml> in the end, I used something close to the original patch.
<poolie> used meaning it was merged to bzr.dev?
<poolie> or used in an external patch?
<poolie> lifeless, sure, i'm just wondering how those apis should be implemented on RemoteBranch
<poolie> or rather, how to most cleanly get my implementation of it to pass the existing test_remote tests
<poolie> spiv, re those tests we were looking at on friday
<jml> poolie: used as in "wrote a standalone function that did the same thing"
<jml> poolie: https://pastebin.canonical.com/9155/ if you are interested.
<spiv> I think it's useful for tests if merely constructing a RemoteBranch doesn't trigger an RPC.
<poolie> spiv, that's the heart of the problem here
<spiv> A possibility would be to add an optional fallback_urls= param to RemoteBranch.__init__.
<poolie> and do it from the RemoteBranchFormat
<poolie> that's true
<poolie> but, if we find we need to do it through the real_branch, then what...
<spiv> The existing test_remote tests would just pass fallback_urls=[], and for now the real code can not pass it.
<spiv> And when not passed RemoteBranch could then fallback to using real_branch.
<poolie> hm
<poolie> so i can see how that's handy if you just want to test some other aspect
<poolie> of the class
<poolie> on the other hand it seems a bit like cheating
<spiv> poolie: it's a bit weird to me that opening a branch mutates the repository object, which potentially belongs to other branches too.
<spiv> poolie: (i.e. by adding the fallbacks)
<poolie> that's true
<poolie> but, that's the api
<spiv> Yeah.
<poolie> it's kind of related to being able to get the repository either from the bzrdir or the branch
<poolie> and now you get different behaviour
<poolie> um
<poolie> there are some other possible paths as far as asking the Repository class method or format object too
<poolie> it should be more clear which one is primary
<lifeless> could someone with linux try this - valgrind --tool=callgrind python2.5 bzr st bzr.dev
<lifeless> spiv: it was a tradeoff
<lifeless> spiv: having a arbitrarily large list of fallbacks is intrinsic to a shared repo with stacking
<lifeless> spiv: having the branch maintain the state allows restricting that scope to just the repository instances that need to know about it
<spiv> lifeless: you say "the branch maintain the state", but they state is kept on the repo afaict?
<spiv> lifeless: I guess my naive expectation would be that stacked_branch.repository would be a FallbackRepository(real_repo, *fallback_urls) rather than having the branch mutate the repo.
<spiv> I haven't spent much time thinking about this, though :)
<lifeless> spiv: the disk state is in the branch
<lifeless> spiv: reconcile needs to be able to work with all branch's fallback repos at once
<jml> lifeless: I've run that valgrind command, what output do you want?
<lifeless> jml: did it fail with 'cannot allocate memory' ?
<jml> lifeless: nope.
<lifeless> ok
<jml> that's using bzr.dev built for py2.5
<poolie> spiv, the thing is that the repo implementation might want to know about how they're stacked
<poolie> rather than it just being a composite object
<poolie> um
<lifeless> jml: thanks
<poolie> it might be cleaner though to unambiguously give the branch responsibility for opening the repo
<poolie> if it has the knowledge how to do so
<lifeless> by comparison, git has a single repo instance with a list of 'alternates', and hg just writes nulls for parents at the edge of the stacking boundary
<poolie> could it be a security problem for the server to give arbitrary urls back to the client?
<lifeless> yes, if they are trusted
<lifeless> but that applies to normal content and hooks too
<lifeless> so I don't think they are any more special than reading a file from a http server
<poolie> mm
<poolie> it seems like it'd be good for test_smart to start its test with the tuple-like request it wants to test
<poolie> so it can also check the right thing gets called
<poolie> rather than starting with the Request class that's going to ultimately run...
<poolie> hm
<poolie> it's not really easily accessible though
<vila> Good morning Bazaar
<gour> morning
<lifeless> hi vila
<poolie> hello vila
<chandlerc> i got an odd error when upgrading a shared repository with a bzr-svn branch in it:
<chandlerc> bzr: ERROR: No such file: ('3@fc50161f-d74b-0410-97f1-43881e8fa688:parser%2Ftrunk:templates', 'svn-v3-trunk1:fc50161f-d74b-0410-97f1-43881e8fa688:parser%2Ftrunk:18')
<spiv> jelmer: ^ see chandlerc's upgrade problem
<spiv> poolie: have you seen David Ingamells' stacking problem on the mailing list?
<poolie> no
<spiv> poolie: https://lists.ubuntu.com/archives/bazaar/2008q3/047516.html is the most recent post in the thread
<poolie> ok, yes
<poolie> spiv, what about it?
<spiv> Just that you are somewhat likely to know if it's a already known issue or not.
<poolie> it's not totally surprising to me, but i don't specifically know what it is
<spiv> i.e. you're probably best placed to reply and say "yes, that's bug #NNN" or "that's a problem, please file a new bug report".
<poolie> not off hand
<poolie> i'd have to try to reproduce it
<poolie> so, (B)
<poolie> it would be nice if we could just say "expose this as an rpc" rather than declaring each one as a custom class
<poolie> i guess there's no strong reason why we can't?
<poolie> like it would probably fit into the registry format
<spiv> poolie: for RPCs with simple arguments and return values?
<poolie> yeah
<poolie> at least to start with
<poolie> i'm going to put the fallback repositories into the real_repository fallback, as well as the remote one
<spiv> Or rather than changing the registry, you could perhaps have a helper to construct a SmartServerRequest* subclass for you, and then register that.
<poolie> exactly
<poolie> or even just an instance
<poolie> well, archetype or something
<poolie> spiv, i wouldn't be totally surprised if this current branch fixes it but i'm not sure it will
<spiv> I needs to be a class, or object factory of some sort, I think.
<spiv> poolie: yeah.  That's what I thought about my last fix, though ;)
<poolie> ^^ which "that"?
<spiv> "i wouldn't be totally surprised if this current branch fixes it but i'm not sure it will"
<poolie> heh
<vila> spiv: regarding but #269535, could you make a quick review of lp:~vila/bzr/py26bzr revno 2940 ? It fixes a lot of python-2.6 failures and errors but makes  bzrlib.tests.test_fetch.TestHttpFetch.test_weaves_are_retrieved_once fails.
<vila> Which is a bit puzzling...
<vila> spiv: I'm not asking for a true review, just a look and feedback, it may need more polish (I'm just trying to make it work for now)
<spiv> vila: ok
<vila> spiv: thanks
 * AfC would just like to say that he is finding bzr fast today.
<AfC> Take THAT all you whingers.
<spiv> AfC: :)
<gour> AfC: 1.7x?
<AfC> gour: don't be ridiculous; 1.6.1.
<AfC> Running released software == sanity.
<gour> ok, ok...nice to hear
<AfC> [Unless of course it's a project you're hacking on. Then of course you run upstream from source.
<AfC> Which reminds me of something I was chatting about with Rusty one day... I was observing that I had just done a release of my project, and didn't feel terribly enlightened or uplifted as a result.
<AfC> After all, *I* don't need to do a release to use my code. We just need everyone _else_ in the software universe to release _their_ code so we can use it  :) :)]
<gour> lol
<AfC> (I first thought of this when I'd get "congratulations on your release" type emails from colleagues, when all doing a release was good for was a lot of time consumed away from time spent on hacking ... and bug reports for OSes I don't use and for situations that were all WORKSFORME)
<spiv> vila: wow that's a lot of changes!
<gour> "everybody is thinking about himself/herself, only I think..."
<vila> don't look at the whole ! Just diff -c 2940 !
<AfC> (made me realize just how big a burden doing releases really is. Its not only work. It's also psychological pain and distraction ... just so other people can use your work and not pay your anything. Reminds you just how much we owe people who offer their work as Open Source and promote Software Freedom).
<spiv> vila: sure :)
<vila> I'm not sure all changes in that branch are still needed, but since that was an early attempt to be compatible with python-2.6 I didn't re-start from scratch
<vila> but if your remark was about: "what is needed to be compatible with 2.6" then, yes, it's not as trivial as one may hope ;-/
<gour> AfC: just consider eternal glory people are using your software
<gour> vila: bzr will soon jump to 2.6 bandwagon?
<spiv> vila: yeah, that's what my remark was
<spiv> gour: no, we'll still support 2.4 for quite a while I think
<vila> gour: no, I'm looking at what is needed, I don't think we want to rush
<gour> thanks
<spiv> gour: (and 2.5).  But we want to work with 2.6 as well.
 * gour wonders who will use 3.0 then
<spiv> vila: so at a glance the changes in 2940 look nice.  Interesting that it causes that test to fail.
<vila> vila == puzzled, spiv == interested :D
<vila> spiv: I don't really like passing transport at medium construction time, it may be enough to provide it at request time
<vila> but that's the make it right part ;)
<poolie> spiv, did we ever settle something about systematically marshalling all/most errors across hpss?
<spiv> vila: so for some reason it's reprobing for a smart server
<poolie> afc, that's good to hear
<spiv> poolie: somewhat
<spiv> poolie: bzrlib/remote.py now has a _translate_error helper.
<poolie> i saw
<poolie> i guess i meant, on the server side, it's be nice to let the do() method just pass the error up and have it automatically sent
 * vila thinks that the smart probes are itching more and more.... redirection bugs, now that :-/
<vila> spiv: That's why I asked for feedback, I'm wondering if my patch is in the right direction or is foobaring some "ok, I have already probed, no need for more"
<spiv> poolie: so there's a single place to handle the unmarshalling now, and it deals with the "this exception needs an other_branch param" problem.  On the server side I think it's enough to make _call_converting_errors smarter.
<spiv> vila: I think it's the right direction
<vila> ok
<spiv> vila: so the reason it fails is that SmartClientMedium is the thing that remembers if there's been a protocol error or not
<spiv> vila: and now we are making new SmartClientMedia rather than re-using them.
<lifeless> vila: 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
<spiv> vila: probably the thing to do is keep the medium in the _shared_connection object, so there's one instance per connection.
<vila> spiv: Haaaaa ! Thks
<spiv> vila: rather than making a new one for each get_smart_medium call
<lifeless> vila: please poke now at my fixed branch and script so you can see what I've done
<lifeless> vila: as the EU guys come online, I won't be around to answer questions shortly
<vila> spiv: so it should not keep a transport instance
<lifeless> vila: we still have code changes to make vis-a-vis the bug, but the casper branch should be done
<spiv> vila: (search for _protocol_version_error inside SmartClientMedium to see where/how this state is tracked)
<vila> lifeless: ok, switching to it right now so that *I* can ask questions :)
<vila> spiv: sure, now that you mention that, it should be easy
<vila> lifeless: http://paste.ubuntu.com/47101/
<vila> when trying your script on cp -R casper.backup casper
<vila> Your script is intended to produce a 'cleaned' branch from a 'casper' branch, the later being broken, right ?
<lifeless> vila: you shouldn't need to run it though, I uploaded a fixed branch
<vila> I downloaded it, your script runs ok on it :D
<vila> I thought your script was intended to be used by people having broken branches
<vila> lifeless: what should be done with your clean branch ? push --overwrite it to lp:~ubuntu-core-dev/casper/trunk ?
<vila> and from there everybody should re-clone ?
<vila> should we go private from here to avoid spamming this channel ?
<poolie> here is fine
<poolie> but i think he's signed off
<lifeless> vila: something like that
<lifeless> vila: that error is a local repo error in whatever branch you tried it on
<lifeless> my script assumes a 'working but cannot clone' branch
<vila> lifeless: ok, I may have played too much, I'll retry with a less broken one
<vila> so, starting again with the casper.backup from  http://people.ubuntu.com/~cjwatson/tmp/casper-wreckage.tar.gz, your script works
<vila> lifeless: I won't pretend I understand everything that is going on nor that I can go further, but I think I can help them get back a clean branch
<vila> lifeless: that's what you're expecting from me right ?
<lifeless> vila: well, ideally they grab my cleaned branch
<lifeless> vila: and you help them become users of that branch, and its all good
<vila> lifeless: ok
<VSpike> morning folks... just looking for advice on an easier way to do something
<VSpike> I keep coming across a similar problem.. I organised a directory of files under source control by creating subdirectories and moving the file in there
<VSpike> Previously I've resolved this with bzr after the fact by doing a series of bzr move --after file1 /newdir/file1
<VSpike> Trouble is, if the directory is new, it complains there about it not being controlled, so I have to do bzr add newdir, but this then adds all the files in that new directory.. so I have to then remove each one before issuing the move --after command
<VSpike> Is there an easier way to do this?
<VSpike> It's bad enough that on windows the files are listed in bzr st with "/" when windows won't accept that so you can't even copy and paste to speed things up :)
<spiv> VSpike: "bzr add --no-recurse newdir" would help you I think
<spiv> That will add newdir without adding the files underneath it
<VSpike> spiv: ah was hoping there was something like that :)
<lifeless> vila: may need LOSA help to zap the existing branches
<lifeless> jml: could you draft a _real quick_ mail to vila about what it would take to zap the existing corrupt branches of casper, for LOSA's to execute ?
<lifeless> jml: (you know the details I'd have to say 'look up' on)
<jml> casper's a project on Launchpad?
<vila> jml: yes
<lifeless> jml: its a package whose source is managed in bzr
<lifeless> jml: I'm not sure what product the branches are attached to
 * vila would really like to know the expansion of LOSA...
<lifeless> some are not on LP but are mirrored - the 'remirror now' button discussed previously would suite those branches, others are hosted on LP
<mwhudson> vila: Launchpad/Landscape Operation System Administrator
<vila> ok, I was close with my Launchpad Overlord System Admins, but no cigar :)
<gnomefreak> my bzr login id would be just gnomefreak?
<gnomefreak> nope guess not
<cjwatson> vila: hey, so I'm looking through lifeless' work on bug 246880, and I understand he briefed you on what it'll take to deal with existing LP branches
<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
<Kinnison> gnomefreak: It's unclear to me what you mean
<Kinnison> gnomefreak: If your username is gnomefreak then bzr will default to using that to record commits
<gnomefreak> Kinnison: trying to push to my bzr branch it asks for "bzr launchpad-login YOUR_ID"
<Kinnison> gnomefreak: aah, you need to tell it your launchpad login id
<spiv> gnomefreak: that's not a "bzr login", that's your Launchpad login :)
<Kinnison> gnomefreak: e.g. mine is 'dsilvers'
<vila> cjwatson: yes, basically the bug has a clean branch associated with it
<gnomefreak> i used gnomefreak as ID and it still failed permissions on ssh key
<cjwatson> vila: right, I actually had to reconvert it using lifeless' script as he was missing some new revisions
<Kinnison> gnomefreak: You are John Vivirito?
<cjwatson> vila: I'm doing a diff-at-every-revision test now
<gnomefreak> Kinnison: yes
<vila> cjwatson: great
<cjwatson> vila: I'm going to want to push to lp:casper, and I have a funny feeling that I'll need to move the old branch out of the way first
<Kinnison> gnomefreak: and you're using one of gnomefreak@Development or gnomefreak@Hardy in terms of ssh keys?
<cjwatson> vila: do you know whether simply changing the branch name with "edit details" in LP will do the trick there?
<gnomefreak> Deveklopemt
<gnomefreak> Development Kinnison
<Kinnison> gnomefreak: so, having done bzr launchpad-login gnomefreak, did it give you errors?
<gnomefreak> it seems the permissions are due to shh key :(
<vila> cjwatson: ah, I don't remember if lp supports branch renames, it wasn't a long time ago, but that may have changed
<poolie> vila, i think it does
<cjwatson> I suppose I can just try it
<vila> poolie: thks :)
<spiv> cjwatson: To change the branch that "lp:casper" resolves to you'd need to use https://code.edge.launchpad.net/casper/trunk/+edit
<gnomefreak> and i know it worksoh yuck looks like no key in my ~/.ssh dir :( is there a way to add the exsisting key to it?
<spiv> cjwatson: (and simply renaming the underlying branch wouldn't affect lp:casper AIUI)
<Kinnison> gnomefreak: either copy your .id_{dsa,rsa}{,.pub} files in, or make a new key for that machine and register it on launchpad
<cjwatson> spiv: right, the bazaar.launchpad.net mirror won't care about what lp:casper is though. I just want to make sure the physical branch data is out of the way so that a fresh push will copy it all from scratch
<cjwatson> see what I mean?
<Kinnison> gnomefreak: s/\.id/.ssh/id/
<spiv> cjwatson: so probably for clarity for everyone you'd want to rename the existing branch, make a new one, and then point lp:casper at the new one
<cjwatson> I've renamed the existing one to trunk.old
<gnomefreak> Kinnison: that is gonna be hard since the dir is empty but i think i saved it to USB stick
<cjwatson> $ lftp sftp://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk
<cjwatson> cd: Access failed: stat/lstat failed (~ubuntu-core-dev/casper/trunk)
<cjwatson> that looks promising
<spiv> cjwatson: (or get an admin to empty branch directory behind the scenes for casper in both the hosted and mirror areas then re-use that)
<cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/ says "no changes!" rather than missing
<spiv> cjwatson: bazaar.launchpad.net mapping of name->branch has a slight lag
<spiv> cjwatson: so check again in say 2 minutes
<gnomefreak> Kinnison: thanks i got it working
<spiv> cjwatson: if https://code.launchpad.net/~ubuntu-core-dev/casper/trunk is 404 (and it is), bazaar.launchpad.net should follow suit shortly
<cjwatson> ok, even if bzr barfed on that branch?
<cjwatson> I wasn't sure of the level at which that stuff worked
<cjwatson> aha, yes, it's 404 now
<cjwatson> spiv: so that will definitely have moved aside all traces of the broken branch?
<spiv> bazaar.launchpad.net stores branches internally by a fixed ID, and maps alls requests as they come in to the underlying ID.
<cjwatson> oh, right, so no moving directories around required
<spiv> Right.
 * spiv -> food
<vila> cjwatson: now you can push the cleaned one on lp:~ubuntu-core-dev/casper/trunk
<cjwatson> yep, in progress
<vila> cjwatson: ok
<Kinnison> gnomefreak: you're welcome
<vila> cjwatson: looks like the new trunk has been uploaded, now you should be able to update lp:casper
<cjwatson> vila: yep, I asked Mithrandir to do that a few minutes ago
<cjwatson> (can't do it myself, I don't own the casper product)
<vila> ha, ok
<cjwatson> thanks for all the help, this is looking good now
<vila> cjwatson: lp:casper is not updated yet though
<cjwatson> yes, that will have to wait for Mithrandir to be present
<cjwatson> I'm not in much of a rush there
<vila> ok, as long as people needing the cleaned branch use the one you just uploaded, they should be fine
<VSpike> To use bzr in windows, which works best overall - cygwin + windows port of bzr, or cygwin + cygwin port of bzr?
<VSpike> I've used both - I'm currently using windows port without cygwin, but using the normal cmd prompt is driving me insane
<poolie> VSpike, i'm not totally sure but i think the cygwin one works better within cygwin
<poolie> and the windows one is better outside
<poolie> the windows one comes with some Explorer integration, if that's useful
<VSpike> poolie: thanks - I agree, the all-cygwin one worked OK for me mostly, once you get used to the quirks of cygwin and also hack it to make ssh work with bzr
<VSpike> poolie: the explorer integration is not enough to make up for the horror of the windows command line :)
<nDuff> aren't there alternatives available to cmd.exe?
 * nDuff remembers... 4dos, was it?... from back in the day.
<VSpike> nDuff: yes, there's the windows power shell
<nDuff> and I've heard Microsoft talking about how they were going to make a decent shell for a *long* while
<VSpike> I thought about trying learn that, but decided i just didn't have enough time when i could better put my efforts into improving my bash skills
<VSpike> their enhanced shell does look interesting but .. well, deadlines loom etc
<poolie> VSpike, learn zsh :-)
<poolie> like bash but a bit better
<poolie> back to work...
<VSpike> poolie: Ah yeah saw an article about it somewhere recenly
<VSpike> will push it up the project queue :) thx
 * nDuff has been using zsh for some time, and is constantly annoyed / trying to decide whether to go back to bash.
<nDuff> ...granted, though, the things that annoy me are probably configurable.
 * vila trying export ANNOYING=False
<msq_> Hi guys, after upgrading bzr on both ends I'm getting http://pastie.org/272628
<spiv> msq_: huh, weird.  What versions on both ends?
<msq_> spiv: 1.6.1
<spiv> msq_: does "ssh <host> bzr --version" report the version you expect?
<msq_> spiv: that's it :)
<msq_> spiv: though, how do I change it
<msq_> spiv: I use bzr in my own PATH on the server
<spiv> msq_: You can set BZR_REMOTE_PATH locally, or set bzr_remote_path in your locations.conf
<msq_> spiv: the latter on my server?
<spiv> No, both on the client.
<spiv> They are ways to configure the client to run a different path than just 'bzr'
<msq_> spiv: I assume that there is no server-side
<msq_> solution
<msq_> ?
<spiv> Well, if you replace OpenSSH with something more configurable there is ;)
<msq_> spiv:  heh ;)
<spiv> But I don't know of a way to make OpenSSH run your .bashrc or whatever before running any command.  And bzr doesn't have any feature on the server to workaround this, the client side is generally enough.
<msq_> spiv: thanks anyway!
<spiv> It wouldn't surprise me if there's some magic setting for OpenSSH on the server to change this behaviour, but I haven't been able to find it.
<msq_> spiv: ok, everything works perfect, locations.conf updated
<hsn_> i really need python based installers for windows, anybody knows who is building them?
<poolie> hsn_, as opposed to the exe installer?
<matejcik> vila: are you there?
<hsn_> yes i need something like this http://launchpad.net/bzr/1.6/1.6beta3/+download/bzr-1.6b3.win32-py2.5.exe
<poolie> hsn_, i think bialix was building them, but i might be behind the times
<poolie> you could ask on the list
<poolie> woo
<poolie> test_remote is clearing up nicely
<vila> matejci1: back, sorry, I was in the basement for a central heating problem :-/
<matejci1> vila: cool, now i'm back too
<matejci1> reporter of https://bugs.launchpad.net/bzr/+bug/269535 pointed me to you, said that you were working on it today
<vila> and the heating is back too, we are all here, good
<ubottu> Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress]
<matejci1> i'm the guy who maintains python in opensuse, so this issue is kind of my responsibility
<matejci1> so is there anything i can help with?
<vila> matejci1: phone, hold on
 * matejci1 holds
<vila> back, pfew, some days..
<vila> ok, so, bzr supports python-2.4 and 2.5
<matejci1> yes, and there's some subtle change that breaks it for python 2.6
<vila> I'm working on 2.6 and the last problem seems to related to our test framework
<vila> so, out of our ~1300 tests there remains only 8 failing and I don't think there are really problematic
<vila> yet, it will take time for python-2.6 to be truly supported, so if you want to include bzr in opensuse, it will be better to also include python-2.5
<vila> matejci1: is this possible ?
<matejci1> well... the thing is, that we only recently started working on the possibility of having two different pythons installed
<vila> bah, s/1300/13000/
<matejci1> so at least for 11.1 that probably won't happen
<poolie> wow
<poolie> are they really shipping only 2.6 even before 2.6 is released?
<poolie> or am i just out of date
<matejci1> poolie: we're not -shipping- it, mind you
<vila> and none of your packages that depends on python break ? Amazing...
<matejci1> poolie: python 2.6 release date is way before 11.1 release
<poolie> heh
<vila> when is 11.1 due ?
<poolie> certainly if you're using ubuntu numbering and that's January 2011 :-)
<vila> lol
<poolie> i realize you're probably not :)
<matejci1> hah :e)
<matejci1> nope, its ... i'm not sure how the numbering works actually
<matejci1> 11.1 should be out in december or something
<matejci1> and yes, packages do break ... mostly the "wild" complex ones like bzr, scons...
<poolie> vila, yay, my 261315 is all passing
<poolie> i think it still needs packwards compatibility
<matejci1> strangely enough, twisted framework seems to work perfectly
<vila> poolie: like hewlett packwards ?
<vila> poolie: woot, was the last remaining one to use stacked branches on lp ?
<poolie> realistically i think we will find some more
<poolie> but, basically yes
<vila> poolie: great
<poolie> also i think the remote tests are now easier to read and debug
<poolie> or at least the ones i've updated
<vila> poolie: I'll look at that asap then :)
<poolie> i was kind of fishing for reviews
<poolie> so it may not be perfect but i want to sleep
<poolie> if you can read it that would be good
<poolie> it will be kind of large so don't rubber stamp it
<vila> matejci1, poolie : I don't know how to proceed from there, but we need someone to pass the test suite with python-2.6 to ensure we don't regress
<poolie> but hopefully it will be ok enough to do 1.7 roughly on schedule
<poolie> multiple inheritance is annoying...
<matejci1> okay. where can i get the thing that needs testing?
<vila> bug #261315
<ubottu> Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315
<vila> errr
<vila> bug #269535
<ubottu> Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress] https://launchpad.net/bugs/269535
<vila> matejci1: do you have a working bzr ?
<matejci1> sure
<vila> matejci1: use it to 'bzr branch lp:~vila/bzr/py26bzr'
<vila> and file new bugs if you encounter problems
<matejci1> okay
<vila> I intend to use that one for the first round and close it once the test suite fully pass
<poolie> vila, we can probably get 2.6 running inside pqm though it might be annoying
<poolie> hm
<poolie> no 2.6 at all in intrepid yet
<vila> poolie: at least we should do that as we intend to do for windows and maybe osx ?
<poolie> right
<poolie> ok
<poolie> patch sent, off to bed
<matejci1> alright, what's the official way to run the testsuite?
<poolie> 'make check' or './bzr selftest'
<poolie> first is more thorough
<matejci1> hmm ... i wonder what would happen if we made that run at build time...
<vila> matejci1: as poolie said :) But if you have some plugins installed (and they fail to pass the test suite) you may try bzr selftest --no-plugins
<poolie> matejci1, actually i think that would be a great idea
<vila> matejci1: running it at build time will be perfect until we officially support it
<poolie> it takes 10 minutes or so
<poolie> depending on your hardware etc
<matejci1> that should be ok
<matejci1> but make check requires docutils, which we don't have...
<matejci1> selftest appears to work fine though
<poolie> it would be good to get docutils so that you'll get html documentation for bazaar
<poolie> ok
<matejci1> i'll leave that to bzr maintainer
<poolie> note that you should probably run 'make' or some sub-targets
<poolie> otherwise the binary extensions won't be built and it will be slow
<matejci1> setup.py build is sufficient?
<poolie> that also works
<matejci1> ....heh, cool, turns out most of the extensions did not build because of missing pyrex. i'll end up rewriting the package beyond recognition
<matejci1> hahahaha
<matejci1>   warnings.warn("this is your last warning")
<james_w> :-)
<matejci1> vila: http://pastebin.ca/1203397 is test output
<matejci1> i don't like how it skips tests due to "missing feature" ... even though the modules do get compiled
<matejci1> but that is probably due to bad module paths...
<vila> Are you running as root ?
<matejci1> yep
<vila> try a regular user :D
<matejci1> that won't fly :ep this is a chrooted env
<vila> Missing feature 'bzrlib._walkdirs_win32', obviously concerns windows only
<vila> Missing feature 'FTPServer' skipped 94 tests => You need to install nedusa (python ftp server)
<vila> Missing feature 'bzrlib._dirstate_helpers_c' and all that ends up with _c, you need pyrex and to run 'make'
<matejci1> i have that
<matejci1> but this is before installation, in the source dir
<vila> you did run make ?
<matejci1> so those .so aren't on pythonpath
<matejci1> that's what i'm trying to work around now
<vila> ./bzr selftest isn't enough ?
<matejci1> doesn't seem to be ... should it?
<vila> AFAIK, if you're running from sources, yes
<matejci1> okay let me find out what exactly happens
<matejci1> well ... correct me if i'm wrong but that can't work
<matejci1> the .so are in build/lib.linux.blabla/bzrlib
<matejci1> but when bzr says import bzrlib, it takes the bzrlib directory from source tree root
<matejci1> completely avoiding the .so libraries
<matejci1> and there doesn't seem to be anything to override this in sys.path..
<vila> forget the build directory
<vila> make build the .so in the bzrlib directory
<vila> build is a selftest produced directory, arguably a leak :)
<matejci1> hmm, indeed
<matejci1> is it possible to run only tests for the .so modules?
<vila> there are ways, but we risk spending more time establishing the list of tests than just re-running the whole ;)
<matejci1> whatever, just give me one ;e) i don't want to spend 10 minutes just to see "sorry your libraries didn't load"
<matejci1> ah, i get it now
<matejci1> "make" places the .so's in bzrlib/
<matejci1> "python setup.py build" doesn't
<rockstar> Can I use a wildcard in my locations.conf ?
<vila> matejci1: haaa, one is another story :)
<vila> matejci1: try ./bzr selftest -s bzrlib.tests.test__dirstate_helpers -v
<vila> it should run in less than one second and show you which tests are skipped (if any) for which feature
<vila> well, for the bzrlib._dirstate_helpers_c feature
<vila> matejci1: did the Exception class hierarchy changed in 2.6 ?
<matejci1> i'm not sure
<matejci1> i've lost the list of changes ;e)
<matejci1> let me find it
<matejci1> well, nothing about Exceptions is in PEP361, so i assume that if something changed, it did in a slight, almost unnoticeable way. just like the __init__ thing
<vila> :)
<vila> export PY_CRY_OUT_LOUD_ON_SLIGHT_ALMOST_UNNOTICEABLE_CHANGES=42
<matejci1> - Issue #1537: Changed GeneratorExit's base class from Exception to   BaseException.
<matejci1> this is what i found, only mention of exception hierarchy in NEWS. that should be much more trustworthy
<matejci1> why does "internaly performed glob", "utf8filesystem" and "unicodefilename" skip?
<vila> that's NEWS in Misc/ directory from sources right ?
<matejci1> yes
<matejci1> ....and why do i now skip 1138 tests, even though i have more features?
<vila> how many were you skipping before ?
<matejci1> 800something, iirc
<matejci1> yes, 841
<vila> hmmm, I don't really know from here :-/
<matejci1> http://pastebin.ca/1203434 there's a new selftest output
<vila> the first one is caused by running as root I think (per_lock.test_lock.TestLock.test_readonly_file(fcntl) )
<matejci1> i see
<matejci1> then there's a bunch about missing thread.get_name
<matejci1> oh, but those aren't failures
<matejci1> but appear to break stuff anyway
<vila> I can't reproduce that one ( thread.get_name) but it's highly suspicious of either a 2.6 bug or an change not backward compatible
<vila> all the PROXY ones seems due to a surprising change in SokectServer.py (currently trying to fix or work around that one)
<matejci1> let's see what NEWS say about get_name
<matejci1> .....nothing
<matejci1> wait a minute
<matejci1> the method name is supposed to be getName, not get_name
<vila> right and this is in python2.6/threading.py...
<matejci1> hmm, indeed
<matejci1> that makes sense - they were renaming the methods to python naming convention (underscores), apparently didn't do a good enough job
<matejci1> lemme fix it and retry
<vila> you seem to running python2.6b3, I'm running python2.6rc1 do you know who got the older one ?
<vila> s/to/to be/
<matejci1> you have the newer one
<matejci1> i'm going to package rc1 now
<matejci1> should be straightforward, too
<matejci1> get_name was python's fault, it works fine on 2.6rc1
<vila> matejci1: ok, I will stop shortly, at least for one run, all the proxy related tests succeeded, so I strongly suspect a python bug, especially since now, when I try to catch the exceptions related to  error: (9, 'Bad file descriptor'), I get either socket.error or select.error exceptions
<vila> none of which occurred with 2.5 and the modified code in SocketServer.py having some XXX, now use select with a timeout (I rely on a blocking behavior)
<vila> all in all, a can of worms that needs a fresh mind :)
<LarstiQ> vila: you take your rest now :)
<vila> LarstiQ: indeed :)
<matejci1> okay, i'll follow suit and go home get some sleep ;e)
<matejci1> (down to 841 skips, making much more sense)
<nandersson> Verterok, hurray!!! I can branch directly from Launchpad :-) Thanks tons for fixing this :-) Great job!
<nandersson> Using BzrEclipse that is :-)
<LarstiQ> nandersson: what are you branching? (I see you're in some blender channels as well)
<nandersson> LarstiQ, I tested with some stuff from my personal archives in Launchpad
<nandersson> Regarding Blender I'm investigating how to get the 3D-controllers from 3DConnexion to work :)
<LarstiQ> aaah
<LarstiQ> nandersson: good luck with that :)
<nandersson> Have you seen those?
<LarstiQ> not in real life, but yes
<nandersson> I'm also covering F/OSS for Swedish netmag Techworld Open Source and bzr+bzreclipse is an important implementation
<nandersson> That together with Launchpad will hopefully speed up development
<Verterok> nandersson: glad you like it! (you can branch directly from a project into a new one too ;) )
<nandersson> Verterok, yes I saw that :-) Very impressive stuff!!
<Verterok> nandersson: thanks, more comming soon :-)
<nandersson> Verterok, hehe, with this I'm more than happy :-) Launchpad+Eclipse is now a one-stop-shop
<Verterok> nandersson: and with mylyn integration should be awesone ;)
<nandersson> Verterok, Yes, the possibilities are mind blowing :-)
<nandersson> ...and now with all Ubuntu-packages under distributed version control :-) Very exiting times indeed
<justizin> nandersson: i've also wondered about 3dconnexion and blender.  have you met #blender?
<justizin> my understanding is that it requires linking to their libs somehow.
<nandersson> justizin, I don't know but there has been experimental support for 3dconnexion in blender for quite some time, but it seems that the support is still not in main.
<nandersson> justizin, I asked in #blendercoders
<justizin> ah right on, so maybe it's in the experimental tree.. ipthopthotet or whatever it's called ;d
<justizin> blender, iirc, isn't too much trouble to build.  what platform are you on?
<justizin> anyway whatev.  have fun. :)
 * justizin back to bzr-ing
<LarstiQ> justizin: I'm going shopping for food, after that maybe we can talk about nested trees? (svn:externals)
<justizin> that would rawk!
<justizin> i'll be around
<mthaddon> have upgraded the version of bzr that's being used by PQM to 1.6.1 - if anyone experiences any issues, please let me know
<justizin> actually, i should also go shopping for food, but ... meh. ;d
<vila> mthaddon: thanks, I'll keep you informed about my next submissions :)
<justizin> um, i just commited some renames from one directory to another, pushed via ssh, 'bzr update' on the server says the tree is up to date, but the changes are not proliferated.  am i missing something?
<beuno> vila, hi! Have you seen bug #270219 ?
<ubottu> Launchpad bug 270219 in bzr-upload "File contents are not updated when a revision also renames the file" [Undecided,New] https://launchpad.net/bugs/270219
<vila> beuno: yes, surprising, I didn't find the time to write the test to confirm it, that's shouldn't be hard
<vila> beuno: and you catch me just passing in front of my computer, I'm not there :)
<vila> beuno: but we shoud chat some day ;)
<beuno> vila, heh, ok ok. Just wanted to see if you'd seen it
<beuno> yes we do!
<beuno> I'm usually around from 13UTC on
<justizin> LarstiQ: reading some of the nested tree details, would love to give some input, some good ideas but also some things need to be optional, like fetching subtrees (sometimes you just want to check out the master, to change the subtree locations, or just to make minor edits without trying to run or compile)
<epsy> hi, i'm getting trouble using my launchpad account
<epsy> i recently changed my "name" on launchpad, i changed bzr launchpad-login, but bzr up fails telling me that there is no "epsy46" account on launchpad
<LarstiQ> justizin: something like --ignore-externals?
<epsy> bzr launchpad-login tells me my account is "epsy"
<LarstiQ> justizin: you can play with https://code.edge.launchpad.net/~larstiq/bzr/nested-trees to see what the status is at
<LarstiQ> epsy: hmm
<nandersson> epsy, Do you have the correct name in ~/.bazaar/bazaar.conf?
<justizin> LarstiQ: yeah, i thought you might be aware, just didn't see it in the notes / status..
<justizin> i'll check out the tree and give it a spin.
<LarstiQ> epsy: is your branch bound to epsy46@... ?
<LarstiQ> justizin: to be truthful, development has been very stagnant
<mbt> Anyone run into an issue with bzr on Win32 (XP) accessing a https:// repo?  Am getting an error in bzr 1.7rc1 thrown from pycurl, saying 'error: (65, "necessary data rewind wasn't possible")'
<epsy> LarstiQ, indeed
<mbt> I am able to check out the same repository on a Linux box with bzr just fine.
<LarstiQ> mbt: that one is new to me
<mbt> I did find one mention of it here on 8/29, but no fix was mentioned: http://irclogs.ubuntu.com/2008/08/29/%23bzr.txt
<LarstiQ> mbt: does it do that with https+urllib:// as well?
<mbt> can try that
<epsy> LarstiQ, thanks, got it solved
<LarstiQ> mbt: bug 207734 and bug 241698 might be relevant
<ubottu> Launchpad bug 207734 in bzr "push on bzr+http, pycurl fails with: necessary data rewind wasn't possible" [Undecided,Incomplete] https://launchpad.net/bugs/207734
<LarstiQ> epsy: cheers
<ubottu> Launchpad bug 241698 in bzr "POST to authenticating proxy causes "necessary data rewind wasn't possible" error" [Undecided,New] https://launchpad.net/bugs/241698
<justizin> LarstiQ: yah i see it is based on bzr 0.15 O.o
<LarstiQ> justizin: last I really touched it was the sprint in may this year or so?
<mbt> LarstiQ: Yeah, https+urllib:// worked, but plain https:// did not
<LarstiQ> mbt: right, without the urllib decorator you're using pycurl
<LarstiQ> mbt: did you see the bugs I mentioned?
<mbt> Yes, though this one is without a proxy, so I am going to guess that the problem has to be with pycurl and is more fundamental, though what it is I've not a clue
<LarstiQ> mbt: if you could comment that on 241698, then we can prod spiv again that there's more information
<mbt> LarstiQ: Will do, thanks
<LarstiQ> mbt: other than that, I've stopped using pycurl a while ago. Did it get installed with the windows installer, or did you install it seperately?
<mbt> Windows installer, from the launchpad page
<mbt> First Python app on the machine, so I assume its bundled
<LarstiQ> thanks
<LarstiQ> markh, vila: are there reasons to not drop pycurl from the bundled win32 installer?
<nandersson> I filed an idea at Brainstorm "Integrate bzr-builddeb in Eclipse" http://brainstorm.ubuntu.com/idea/13260/
<beuno> Verterok, cool!  Verterok will be very please
 * Verterok looks
<Verterok> nandersson: cool :)
<nandersson> As long as bzr-builddeb is installed it's a matter of executing bzr bd in the root directory - the file ends up in ../buildarea
<james_w> nandersson: "bzr bd lp:update-manager"
<vila> LarstiQ: pycurl validates ssl certificates, urllib doesn't, I wonder why I've never thought about making urllib the default for http, yet leaving pycurl the default for https...The least I could now is to send a one-lie patch on the list to get it discussed
 * vila off to bed
<james_w> or rather a URI that works
 * nandersson looks into lp:update-manager :-)
 * vila coughs one li*n*e-patch, where do I find my typos....
<LarstiQ> vila: it brought a smile to my face though :)
<nandersson> james_w, That's cool! Didn't knew you could do that :-)
<james_w> nandersson: thanks jelmer
<nandersson> james_w, Then perhaps the next thing would be to specify where to store the files? As in the Personal Package Archive for example?
<james_w> nandersson: yeah, I don't know about automatically uploading
<nandersson> james_w, Then my idea would basically already be implemented - just build a wrapper around it in Eclipse
<nandersson> That runs the command
<nandersson> bzr bd lp:my-package my-personal-package-archive
<Verterok> nandersson: you could setup a external tool in eclipse to run the command, in the meantime
<nandersson> Verterok, Yes, you're right, I can create my own script :-)
<awilkins> I keep having problems with Pycurl too
#bzr 2008-09-16
<poolie> hello
<poolie> spiv, jam, igc, lifeless, call in a minute
<markh> jelmer: ?
<jelmer> markh, hi
<markh> hi jelmer - I see you made a change for that crash on osx - is there anything I should do for windows binaries?
<markh> I saw another bug report recently and marked it as a dupe
<markh> but its a dupe of the osx one (which the other windows crash bug is too), and that is marked as fixed
<spiv> abentley: bundlebuggy seems to be giving 502 atm
<jelmer> markh, there were other fixes for Windows by Snaury as well
<markh> jelmer: so if I just rebuild all should be good?
<jelmer> markh: Yeah, I think so
<markh> that was the perfect answer :)
<markh> do I need to move to 1.5 or anything?
<jelmer> I would recommend building against 1.5 but for other reasons (several bugfixes that may be relevant, more protocol calls available to svn)
<markh> ok - iirc that will require some tweaks to setup.py as the list of libs has changed.  I'll see how I get on...
<markh> (that was the only reason I dropped back to 1.4 in the first place - the existing list of libs was already correct!)
<jelmer> markh, Snaury tweaked some of that as well afaik
<abentley> Soliton: restarted
<abentley> spiv: restarted
<spiv> abentley: thanks!
<jml> wuu patches.
<lifeless> abentley: you nearly got spivs origin correct
<abentley> lifeless: Hee.
<jml> poolie: does your updated patch address the problem I noticed here: http://paste.ubuntu.com/47029/ ?
<justizin> so, ah, again, i renamed some files from bin/ of my repo to scripts/, because bin/ is really a virtualenv and it ends up with all these generated scripts which show up in 'bzr status', i want to just add bin/ to ignores, but i can't get my parent branch to show the change.
<jml> justizin: you need to commit changes to your ignore file.
<justizin> jml: i haven't changed the ignore yet, i only moved the files which i want source-controlled, and my 'master' branch doesn't show the rename..
<justizin> even after a bzr update
<justizin> also, now i am trying to merge with an svn branch and i get: bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1558390>".
<justizin> woo fun :)
<justizin> this is a relatively old bzr 1.5 and older bzr-svn, of course.. looking forward to intrepid.
<justizin> but it's been working fine for months, just think this is odd..
<justizin> for instance, i bzr mv bin/disable-stuff scripts/disable-stuff
<justizin> in the repo on my laptop where i'm working, the change is there, i committed, i pushed, and on the server, i ran bzr update..
<justizin> and i checked everything i could think of.
<justizin> both report the same rev #
<justizin> but the contents diverge
<justizin> Oo
<jml> justizin: so maybe you need to merge one into the other.
<justizin> tried merge, says nothing to do..
<justizin> only changes in one branch, atm..
<jml> so, what are you trying to do?
<jml> poolie: ping
<justizin> jml: i'm trying to see my changes in the parent branch.
<justizin> bzr says everything is fine, that the tree is up to date, but i'm saying, dude, it's not.
<jml> justizin: ok. so you have two branches, you've made changes in one and not in the parent branch?
<jml> how did you tell bzr about those changes? (maybe you could paste a log to http://paste.ubuntu.com?)
<justizin> that is correct.  i commit.  i push.  i merge.  i pull.  i checkout.  i update.  no dice.
<justizin> i don't have a log handy, but i did as i normally do.  i understand the concepts of push, pull, merge, working trees and when i push over ssh, the working tree isn't updated..
<jml> oh ok.
<justizin> so they report the same rev #, attempts to push or merge say that there is nothing to do, bzr status / diff on my laptop shows no changes uncommitted, and bzr update on the server says also, nothing to do, tree is updated..
<justizin> i guess the next thing to check to be 100% is that a branch off the server has the new changes, though it's tree doesn't..
<jml> yeah, that's worth checking
<justizin> yah a fresh checkout shows the changes..
<justizin> bewildering
<spiv> justizin: what does "bzr revision-info" report?
<justizin> i'd nuke the server copy, but it's a branch of svn and i'm afraid i'll lose heritage
<justizin>  135 justizin@justin-ryans-macbook-pro-15.local-20080915190426-w8st6jjdasmd24ox
<justizin> for both
<justizin> and that'd be the commit from my laptop.
<spiv> So, they are exactly the same branch then.
<justizin> yah, but the working tree on the server is broken, which is my public http browsification
<spiv> justizin: so you want to update the working tree on the server?
<justizin> yah and again i understand when i push over ssh that doesn't happen, so i'm on the server and bzr update says the tree is up-to-date, though it's inconsistent with other branches, even the fresh one i just created *from* the branch with the broken wt
<spiv> justizin: perhaps you want to be using one of these plugins? <https://launchpad.net/bzr-push-and-update> or <https://launchpad.net/bzr-automirror>
<justizin> spiv: possibly, but again, i'm fine with manually updating the tree for now, it just refuses to update..
<spiv> justizin: does 'bzr info' in the tree on the server report the branch URL you expect?
<justizin> well it's a branch from an svn repo
<spiv> And what does "bzr status" say?
<justizin> one sec..
<justizin> (info does report as expected btw)
<justizin> well as of now it has pending merges from svn, which is a new problem, but the issue i'm talking about with the working tree was pre-existing..
<spiv> So the working tree has uncommitted changes?
<justizin> and, fwiw, i am now getting: bzr: ERROR: Revision {('',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x1558390>".
<justizin> well, it does as of about 20 min ago
<justizin> the working tree problem is maybe 8-12 hours ol
<justizin> old
<spiv> Uncommitted changes would explain why the working tree's contents don't match the last revision in the branch.
<justizin> it doesn't even have uncommitted changes, it's odd.. i reverted the files from the merge earlier and it just says pending merges with no other change info..
<justizin> no, they can't, because time only moves forwards - check wikipedia. ;)
<justizin> the working tree problem is pre-existing
<justizin> now of course it's all flubbed up and i take responsibility for that
<spiv> The revision not present error sounds like a bzr-svn bug.
<justizin> possibly, i don't have the latest bzr-svn b/c i'm using ubuntu hardy heron packages..
<justizin> i think i'll just end up creating a new bzr repo and futzing the svn merges on this..
<spiv> So I don't understand your problem.  If "bzr update" says the branch is up to date, and "bzr status" says no files are changed in the tree, then there are no changes.
<justizin> yeah, but i am a human and my brain says the files are laid out differently in a fresh branch from here..
<spiv> Is "bzr status" in the fresh branch clean?
<justizin> i moved files from bin/ to scripts/ in my repo, and they are moved on my laptop where i moved them, and they are moved in a fresh branch from the server to a temp location..
<justizin> the fresh branch was created during this conversation..
<justizin> as a means of verifying that the bzr repo had the changes, but the working tree on the server, itself, was broken..
<spiv> Sure, we're at the point where there's a wrong assumption somewhere, I think, so you'll have to pardon the dumb questions :)
<justizin> no it's ok
<justizin> i'm just frustrated and of course i explained some of this to other people over the course of the day
<spiv> (Hopefully I don't need to question http://en.wikipedia.org/wiki/Arrow_of_time ;)
<justizin> and now i hosed the repo for bzr *and* svn so it's all gone to hell and confusing ;d
<justizin> i realized while i was explaining the problem from earlier today that i came back in here for the new missing revision problem, in the same bzr branch / repo.
<justizin> it's ok, i'm learning.  noone's life support fails if this branch dies, and none of my customers will fire me. :)
<justizin> and if i wasn't using outdated code, i'd be helping to test bzr and bzr-svn :-P
<justizin> i noticed that bzr can be installed via setuptools now, btw - super rad.
<justizin> thinking of taking advantage of that for our plone deployment.
<justizin> so i can distribute a tarball of a buildout that installs bzr and pulls dev code.
<justizin> maybe..
<spiv> So I don't have any idea where your problem is.  If you have two up-to-date working trees at the same revision, and no uncommitted changes (i.e. a clean 'bzr st'), then I don't see any way for them to have different contents in their versioned files.
<poolie> jml, pong
<jml> poolie: so, with your patch applied to bzr.dev, I can branch stacked branches into shared repos, but not standalone.
<jml> poolie: I get the same error that I pasted yesterday.
<jml> http://paste.ubuntu.com/47029/
<poolie> ok
<poolie> that's good to know
<poolie> in a way
<poolie> you also said you had conflicts?
<jml> poolie: yeah, in remote.py and test_remote.py
<spiv> jml: how recent is your bzr.dev?  (It's probably unlikely, but I'm wondering if revno 3709 might help?)
<jml> spiv: 3709
<jml> the clash is with the changes in r3695
<jml> poolie: so, should I file a separate, critical bug for the AttributeError problem?
<poolie> that'd be good, and assign it to me
<beuno> http://dev.mysql.com/tech-resources/articles/advanced-bazaar.html
<beuno> w00t
<poolie> hello beuno
<beuno> hey poolie
<beuno> how are you?
<jml> poolie: https://bugs.edge.launchpad.net/bzr/+bug/270738
<ubottu> Launchpad bug 270738 in bzr "AttributeError when branching stacked branches" [Critical,New]
<mlh> there are a shorter form of 'mkdir bzr; cd bzr; bzr init-repo .' ?
<spiv> mlh: "bzr init-repo bzr ; cd bzr"
<mlh> I see that sequence mentioned in more than one place and wonder whether just 'bzr init-repo bzr ; cd bzr' might be better
<mlh> yer
<mlh> I just read Bueno's link above, and also the bzr hacking guide and they both have that triple in preference
<mlh> whereas the double I think is more intuitiev and reliable
<spiv> I prefer the double too.
<mlh> A bzr newbie might look askance at the amount of typing required just to start a repo
<mlh> perhaps bzr init-repo somedir used not to work in some older version of bzr?
<lifeless> jml: poolie will be a minute
<lifeless> mt,ignore me
 * jml ignores.
<abentley> poolie: Want to talk about Launchpad bzr teams?
<markh> jam: ?
<poolie> abentley, hi, just saw your mail about them
<poolie> and also about process - i was hoping someone else might reply
<abentley> poolie: Oh well.
<poolie> ?
<poolie> so that was a yes, i'm happy to talk about them
<abentley> Okay, what do you think about the plan I outlined?
<poolie> i thought there might be other teams that need to be cleared up
<poolie> um
<poolie> presumably after the last step you're wanting to leave ~bazaar-overall yourself and rejoin ~bzr?
<abentley> Right.
<abentley> bazaar-overall is already a member of Loom-developers and the RSS thing.
<poolie> reassigning people is probably a pita but perhaps a rubber duck will do it
<abentley> rubber duck?
<poolie> a launchpad admin
<lifeless> no duckie will do this
<lifeless> personally, I'd leave ~bzr where it is and just change owners on the projects that shouldn't be owned by ~bzr
<poolie> there is also a ~bzr-developers, do you know how that's supposed to fit in?
<abentley> poolie: My original idea was to create a *new* team to be the just-the-bazaar-codebase team.  But then you wanted to make bzr mean that.
<poolie> so that would not require people to move around, which might be less traumatic
<poolie> lifeless points out we don't necessarily need to move people
<poolie> they can join ~bazaar-overall if they want to
<abentley> bzr-developers was my original "just-bzr" team.
<abentley> poolie: I think it would be surprising for members of ~bzr to suddenly stop getting updates about all the various plugins and stuff.
<abentley> poolie: i.e. I don't think that moving people to bzr-overall is optional or opt-in.  It would be disruptive not to move them, if we follow that plan.
<lifeless> abentley: I think its more disruptive to have to move and rename all the branches etc
<lifeless> well, let me put my 2c in. I want you to get what you want here
<abentley> lifeless: Why would we have to move and rename branches?
<lifeless> personally, I will want to end up getting the notifications I get; and I don't want to have to update push urls en-masse (though I'm happy to do so in an adhoc basis subsequent to teams and owners being sorted)
<lifeless> abentley: there are a bunch of ~bzr owned branches for various plugins
<lifeless> abentley: if 'bzr' is renamed, their urls will change
<abentley> lifeless: I didn't think any of our plans involved renaming 'bzr'.
<lifeless> beyond that, I'm happy with anything
<lifeless> abentley: the bzr team I mean
<lifeless> '~bzr' in lp namespace terms
<abentley> lifeless: Still, I don't think any of our plans involved renaming ~bzr.
<lifeless> ok
<abentley> But we might well end up changing ownership of a bunch of plugin branches.
<abentley> So they would go from ~bzr to ~bazaar-overall or something.
<jml> hey guys
<abentley> jml: moo
<abentley> poolie: So do you have an idea how you want to proceed?
<jml> is this a new bug or an old one: 'bzr info -v http://mumak.net/code/stacked' raises an error and 'bzr info -v nosmart+http://mumak.net/code/stacked' does not
<poolie> abentley, it does seem like making ~bzr-developers own bzr is a smaller change
<poolie> and then ~bzr will be a member of that
<poolie> then you can change your membership but other people won't be affected
<jml> the server is using 1.6.1 from the ppa and I'm using bzr.dev with poolie's patch applied.
<poolie> possibly we should rename ~bzr-developers to ~bzr-core-dev or something
<abentley> poolie: Sure, whatever you like.
<abentley> jml: I don't know whether it's a regression.
<poolie> can you see any problems with that?
<abentley> poolie: I think the original reason you didn't want to do that was because the PPA locations would change, or something likethat.
<poolie> so we can't really rename ~bzr or stop using it for the ppa without causing that disruption
<poolie> in retrospect teams for ppas should be dedicated only to that purpose
<poolie> but i think if we do just this it should be ok
<poolie> so should i do this now?
<abentley> poolie: That would be great.
<abentley> jml: My bzr.dev is prolly out of date, but info -v does not raise an error on that URL.
<markh> jelmer: still here?
<abentley> jml: I am on revno 3698.
<jml> abentley: 3709 personally
<mwhudson> abentley: interesting, my bzr.dev is 3702 and does traceback
<mwhudson> tracebacks after bzr revert -r 3698 too, though
<lifeless> pycurl?
<mwhudson> i don't have pycurl installed
<abentley> jml: False data.  I had mistyped the URL slightly.
<jml> lifeless: how can I force urllib?
<mwhudson> jml: http+urllib
<lifeless> http+urliib ?
 * jml gets the same with urllib
 * abentley reminds the crowd that his original statement was wrong; it does traceback for him now.
<jml> abentley: I hear you :)
<abentley> My best guess is that the repository isn't getting stacked.
<abentley> jml: Do other operations on that URL work?
 * abentley is off to bed.
 * jml tries some
<jml> branch works
<jml> info doesn't.
<jml> BzrDir.clone probably doesn't
<lifeless> spiv: have reviewed for you, wasn't happy enough to approve, wasn't unhappy enough to resubmit
<lifeless> spiv: so I just commented
<jml> mwhudson_: welcome back
 * mwhudson_ grrs
<mwhudson_> networkmanager appears to have gone on holiday on my macbook
<poolie> abentley, ok, bazaar-overall should no longer be necessary
<poolie> biab
<spiv> lifeless: that's great, thanks!  I've replied; any thoughts on a better name/location than test_effort?
<vila> Goood.. hello guys
<markh> which platforms or distribution methods get the full html versions of the docs?
<lifeless> spiv: well, I'd have put it in test_remote I think
<lifeless> spiv: as I expect there will be a number of similar tests and they are all remote-centric AIUI
<lifeless> markh: dunno ? :P
<lifeless> markh: docs.bazaar-vcs.org :P
<markh> they are a nice source of pre-generated xhtml versions of each of the help topics I'm trying to work out if I can leverage :)
<markh> generating html at runtime from the 'rst-like' help text in bzrlib doesn't sound like fun
<spiv> lifeless: I expect there will be too, which is why I don't want them in test_remote.
<lifeless> spiv: I don't understand
<lifeless> I think I'm hearing 'because these things are related to remote tests and will be similar to each other I don't want them with other remote tests'
<spiv> I don't mind them being "with" other remote tests, I just don't want them in the existing test_remote module.
<spiv> so I'd rather have the new tests in test_remote_SOMETHING, or make a bzrlib/tests/remote/ directory with test_marshalling and test_effort in it, or a solution like that.
<spiv> Because test_remote is already quite large, and I don't like test modules with a vague purpose like "test everything related to bzrlib/remote.py".
<spiv> Does that make sense?
<lifeless> I'd prefer you made remote tests into a package than a concept-related test module, because all our other tests are module/class/method related, not concept.
<spiv> Basically, I see these tests as being in a related but definitely distinct category to the tests in test_remote
<lifeless> wow my arms are still itchy as hell from the allergy test
<spiv> A package is fine with me, and it sounds like it's ok with you?  If so, I'll do that.
<lifeless> hang a sec
<lifeless> mailing
<spiv> Ok.
<lifeless> ok, mailed
<lifeless> writing a paragraph helps me think sometimes
<lifeless> anyhow, bzrlib.tests.per_branch.test_push is where I think it belongs
<spiv> Really?  Interesting.
<lifeless> the mail should be there now, read it and lets chat more if it doesn't make sense
<spiv> I was thinking that a per_branch test would be low bang-for-buck, and also significantly more complex, because the RPC count for push could legitimately be different for different formats.
<lifeless> fork()
<spiv> (especially while we still fallback to VFS for various things)
<lifeless> on the one hand, I think this is too low level anyhow, it really demands to be cmd_push that is tested
<spiv> (Currently that patch has a test for both cmd_push and for branch_object.push)
<lifeless> on the other branch, I would set an upper ratchet on a per-branch types, if they are different
<lifeless> uhm anyhow
<lifeless> My key concern is SUT<->TestCode connections
<spiv> Yes, that's very important.
<lifeless> I don't think grouping tests by the fact they test overall effort is useful
<lifeless> (We don't test all the e.g. constructor method tests together)
<spiv> No, me either.
<lifeless> so cmd_push's test should definitely be in blackbox/tests/test_push.py IMO
<spiv> (Even though it was the way I was leaning initially)
<lifeless> the branch.push test I would be happy with either a per_branch, or a specific format test
<lifeless> doing per_branch would mean that new formats get <some> coverage by default
<spiv> See, that's strange to me.  It seems to me that the cmd_push test is as appropriate as a per_branch test as the other one.
<spiv> Well, nearly.
<lifeless> it is nearly
<lifeless> the problem is the tension between the cmd_push code, and the code it calls
<spiv> Having coverage for new formats is a very good point.  That probably does make a per_branch test worthwhile.
<imyojimbo> hi, i've just installed bzr. and every command i enter in the console outputs a warning "bzr-svn is not up to date with installed bzr version 1.7rc1. There should be a newer version of bzr-svn available."   what do i do
<lifeless> imyojimbo: have you installed a daily snapshot or something ?
<imyojimbo> no
<imyojimbo> the latest build for Windows
<lifeless> ah
<lifeless> markh: ^
<spiv> lifeless: btw, I see no difference in behaviour in pushing unreconstructable tags with bzr.dev vs. faster-empty-push
<lifeless> spiv: I know, I was saying that the tags support <-> repository layering etc needs an overhaul
<lifeless> and it will change the shape of the tuning you are doing
<spiv> I'm not sure what you're telling me.  Are you saying that my change is incorrect, or just that it's likely that someone else will touch this code at sometime soon?
<lifeless> uhm
<lifeless> I think the current code is faulty
<lifeless> and that your change may make it more faulty
<spiv> Ah.  As far as I can tell it's bug-for-bug compatible :)
<lifeless> further, that we may need to probe for revisions routinely when we fix the tag behaviour, to correct previous misbehaviour.
<lifeless> the tag stuff doesn't need to block us. Oh, but I have a small metacomment
<imyojimbo> ??
<lifeless> imyojimbo: I don't know anything about the windows builds; markh is the dev making them, he can answer your question
<lifeless> spiv: the metacomment is that 'no-op push' is not the common case. The common case is arguably 'changed tip with tags in branch', so changes that only help special cases but are less clear/useful for plugins etc are not auto-approve from me
<imyojimbo> ok, thanks
<lifeless> spiv: w.r.t. tags, I'd like to this change not assume that no-tags implies no-change-to-remote-tags
<lifeless> spiv: so either delegate to a helper method subclasses can replace, or something along those lines
<spiv> Pushing 0 revisions is not *the* common case, but it's not an uncommon one either.  A push of a branch with no tags is also fairly common I think (certainly all my bzr work falls in that category atm).
<spiv> I definitely wouldn't assume that anything is an auto-approve from you unless it's crystal clear that's improvement in every respect :)
<lifeless> spiv: sure, I'm not saying 'do not optimise' I'm saying 'for the common case I give clarity/extensibility a lower weighting'
<spiv> Ah, I see.  Sure.
<spiv> In short: I'm glad you reviewed this :)
<imyojimbo> ops. i did install the release candidate 1. and not the stable version 1.6.1  should i just unistall and reinstall the stable version?
<imyojimbo> *1.7
<lifeless> imyojimbo: yes, installing 1.6.1 again would probably fix the error
<imyojimbo> should i uninstall the current version, or just overide it with the new install
<mdke> hi. I need to revert the last commit done on a branch, what's the proper way to do that? with "revert" or "merge"?
<spiv> lifeless: http://rafb.net/p/1Edrnu30.html <-- change to allow subclasses to vary when tags are pushed by _basic_push
<spiv> mdke: 'bzr uncommit' usually
<mdke> spiv: that worked. Wow that's simple :)
<spiv> mdke: if you don't want to permanently remove that commit from the branch's history, then 'bzr revert -r 2 && bzr commit'
<spiv> :)
<spiv> (Oops, "bzr revert -r -2" is what I meant in that example, not that you care...)
<mdke> spiv: if I'm working on a bound branch, does "bzr uncommit" fix the serverside branch too?
<spiv> Yes.
<mdke> supercool
<mdke> thanks very much
<spiv> You can check for yourself with 'bzr log -r -1 URL' :)
<mdke> ok
<lifeless> spiv: that looks ok to me
<mdke> and the last question.
<spiv> lifeless: thanks
<mdke> users doing "bzr update" from the server branch will automatically get the uncommit too?
<spiv> mdke: yep
<AfC> (it'll "update" to whatever the current revision is)
<mdke> great
<mdke> thanks again
<lifeless> ok, I'm out :)
<akuehntopf> hello...if i do a bzr merge ../bundle.patch the original author is not preserved.. pull did not work, it told me to merge...merge applies cleanly (using cherry-pick). How can i preserve the original author? i'm using bzr 1.6.1
<akuehntopf> is it possible at all?
<bob2> akuehntopf: it should be preserved
<bob2> akuehntopf: (as commits underneath your merge commit)
<akuehntopf> unfortunately not, does it have something to do with "merge" doing cherry-pick?
<akuehntopf> because i couldn't use pull
<bob2> you commited, and 'bzr log' didn't show the commits indented below the merge?
<akuehntopf> it showed them, but using my id as the commited
<akuehntopf> committer
<akuehntopf> i'm sure i did something wrong, i'm not that familliar with bzr yet
<akuehntopf> so my steps were as follows:
<akuehntopf> bzr branch main feature
<akuehntopf> cd feature
<akuehntopf> bzr merge ../bundle.patch
<akuehntopf> bzr commit
<akuehntopf> cd ../main
<akuehntopf> bzr merge ../feature
<bob2> that's how merge works
<bob2> it creates a new commit, with your user id
<akuehntopf> ok
<akuehntopf> and pull?
<akuehntopf> would pull have preserved it?
<AfC> akuehntopf: install bzr-gtk and then try the visualize command with `bzr viz`. You'll get a much better idea of what's going on.
<akuehntopf> oh hi AfC , long time no see ;-)
<akuehntopf> i guess i'll try it using a simple demo repository
<bob2> pull would have just prepended them to the current revisions, yes
<akuehntopf> alright
<poolie> spiv, are you still around perchance?
<Snaury[work]> jelmer: do you have ideas why bzr-svn does not save passwords it's asking for?
<jrb_> are location now implemented for anything other launchpad. the only thing i could find was a brain dump from 2005. otherwise what is the current status?
<jrb_> sorry for the missing words in these sentences :(
<poolie> jrb_, what kind of location?
 * gour is wondering how people auto-generate changelog with bzr
<james_w> gour: there's a gnulog plugin to output a GNU-style changelog
<gour> james_w: ohh, thanks
<Pilky> has anyone else had trouble with the 1.6.1 installer?
<Pilky> for Mac OS X
<jelmer> Snaury[away]: It doesn't do any password caching because that's up to bzr and svn
<Snaury[work]> Hmm. But somehow it doesn't. :-/
<Snaury[work]> jelmer^^
<grutte_pier> Just a quick check: if I want to use a smart server over http, I'd have to something like this... right?
<grutte_pier> bzr revno bzr+http://jakob@www.astro.rug.nl/~jakobb/bzr_repos/repos1
<mwhudson> grutte_pier: new-ish bzr probes for the smart server by default
<grutte_pier> mwhudson: allright.... but that doesn't make any difference for the traceback I get :P Just to make sure that I'm not filing a bug whilst using the wrong syntax :P
<mwhudson> heh
<jrb_> poolie: the common prefix (or at least the server) of the branches on my own server
<jrb_> poolie: bzr checkout mine://foo
<uws> jelmer: is the performance issue we recently discussed fixed in bzr-svn 0.4.12? at least bzr-svn 0.4.11 had the problem
<jelmer> uws, yes, that's fixed in 0.4.12
<uws> jelmer: Ok, thanks. upgrading
<jelmer> 0.5 will be even more significantly faster
<VSpike> latest in a series of daft questions... .bzrignore, should it be added to source control?
<uws> jelmer: how?
<LarstiQ> VSpike: if you use 'bzr ignore' instead of touching .bzrignore itself it will add it to version control it self
<uws> VSpike: Yes.
<LarstiQ> VSpike: if you made it yourself, then yes
<jelmer> uws, fewer roundtrips and cache database queries
<LarstiQ> jelmer: and what is the ETA for 0.5? :)
<VSpike> thx
<jelmer> LarstiQ, "when I find the time" :-P
<LarstiQ> jelmer: ok, so what are the blockers? :P
<jelmer> basically, more tests - in particular tests for upgrading between different versions of the mappings
<LarstiQ> jelmer, uws: btw, 4 oktober there is a Python community day at the NLLGG national gettogether in Utrecht
<jelmer> LarstiQ, ah, thanks
<LarstiQ> (and 27 november a PUN meeting in Rotterdam)
<LarstiQ> which, coincidentally, I still need speakers for ;)
<jelmer> hmm
<jelmer> what sort of timeslots do the PUNs have, ~30 min?
<LarstiQ> jelmer: 30 minutes and 5 minutes lightning talks
<uws> PUN?
<LarstiQ> uws: Python Usersgroup Nederland
<LarstiQ> uws: http://wiki.python.org/moin/PUN/
<grutte_pier> I'd never heard of these... what kind of topics are usually covered during PUNs?
<LarstiQ> grutte_pier: anything goes
<LarstiQ> grutte_pier: http://wiki.python.org/moin/BvB28Aug has some of last time
<LarstiQ> grutte_pier: also, http://vanrees.org/weblog/archive/2008/09/12/python-calculated-coin
<jelmer> LarstiQ, I'd be interested in giving a talk if the meeting doesn't conflict with anything else in my agenda
<LarstiQ> jelmer: cool
<LarstiQ> grutte_pier: personally I'd like to get non-web topics, since that's a bit overrepresented imo
<LarstiQ> gah!
<LarstiQ> jelmer: ever run into svn repos that require authentication for reading parts of the repository?
<jelmer> LarstiQ, yep
<LarstiQ> jelmer: but you need access to the entire path to determine ancestry, right?
<jelmer> LarstiQ, yep, at least in 0.4
<LarstiQ> jelmer: anything I can do right now? Other than bug the admin.
<jelmer> LarstiQ, not really
<LarstiQ> ok
<ajaksu> any hints about merging to google code? (to allow svn-pushing there)
<ajaksu> I get "URL is permanently redirected to None"
<ajaksu> then "bzr: ERROR: exceptions.TypeError: expected string or buffer" :(
<LarstiQ> ajaksu: could you pastebin the command you're trying with all the output?
<ajaksu> LarstiQ: http://paste.pocoo.org/show/85422/ :)
<awilkins> Anyone using OpenKomodo
<awilkins> (cause I think I may try it)
<LarstiQ> ajaksu: ok
<jelmer> ajaksu, any chance you can try the latest revision from bzr-svn's 0.4 branch?
<jelmer> that should give a clearer error
<visik7> I got this error with bzr-svn ImportError: cannot import name client
<visik7> any clue ?
<LarstiQ> visik7: is this 0.4.11 or newer? In that case, did you build it?
<ajaksu> jelmer: sure, let me get it :)
<ajaksu> jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/0.4, right?
<visik7> LarstiQ: newer and yes
<jelmer> ajaksu, yep
<rockstar> jelmer, before you wrote your own svn bindings, what python library were you using?
<visik7> LarstiQ: I've opened a bug https://bugs.launchpad.net/bzr-svn/+bug/270950
<ubottu> Launchpad bug 270950 in bzr-svn "ImportError: cannot import name client " [Undecided,New]
<jelmer> rockstar, python-subversion (provided with subversion itself)
<jelmer> visik7: Please try running "import client" in a python interpreter
 * awilkins testifies that the hand-crafted ones are much better than the standard issue
<jelmer> visik7, while in ~/.bazaar/plugins/svn
<visik7> it works
<visik7> no import exceptions
<LarstiQ> jelmer: have you looked at the new python-subversion bindings?
<LarstiQ> jelmer: ie the ones that didn't get included in svn 1.5
<jelmer> visik7, what about "from bzrlib.plugins.svn import client" ?
<jelmer> LarstiQ, I helped write those :-)
<jelmer> LarstiQ, Or do you mean others than the SWIG-based ones?
<visik7> jelmer: ImportError: No module named bzrlib.plugins.svn
<jelmer> visik7, and after "from bzrlib.plugin import load_plugins; load_plugins()" ?
<visik7> jelmer: anywhere or in a specific path ?
<jelmer> visik7, anywhere
<visik7> no module, but wait I've no bzrlib system wide installed, (but some versions ago it worked smoothly)
<LarstiQ> jelmer: other than the SWIG-based ones, afaik
<LarstiQ> jelmer: a Dutch hg dev told me their current svn effort is going smoothly based on those newer bindings
<visik7> jelmer:  python -c "from bzrlib.plugin import load_plugins; load_plugins()"
<visik7> No handlers could be found for logger "bzr"
<jelmer> LarstiQ, there's nothing upstream yet
<jelmer> LarstiQ, perhaps in a separate branch
<LarstiQ> jelmer: hmmm
<visik7> any clue jelmer  ?
<jelmer> visik7, what version of bzr-svn?
<visik7> jelmer: trunk
<jelmer> visik7, no, sorry
<visik7> nevermind I'll wait
<ajaksu> jelmer: http://paste.pocoo.org/show/85427/
<jelmer> ajaksu, please file a bug about that
<jelmer> ajaksu, you should be able to use svn+https://ajaksu:sa6fQ8MY2cP8@ccoverage.googlecode.com/svn/trunk/ for now as workaround
<LarstiQ> ajaksu: could you try without pycurl?
<ajaksu> damn it, i didn't erase  my temp pass :D
<LarstiQ> jelmer: would https+urllib:// get to svn as well?
<jelmer> LarstiQ, nope, that will try just urllib, nothing else
<jelmer> I think
<LarstiQ> ok
<LarstiQ> jelmer: the rewind thing is something some people ran into yesterday too, without svn too
<LarstiQ> though
<LarstiQ> bug 241689 or so?
<ubottu> Launchpad bug 241689 in awn "awm blocks mouseaccess to windows/trays beside and directly above it" [Undecided,New] https://launchpad.net/bugs/241689
<LarstiQ> hmm no :)
 * LarstiQ goes home
<ajaksu> how do I explicit a base in a merge command?
<jelmer> ajaksu, bzr merge -rBASE..OTHER
<ajaksu> jelmer: wrong question, then... I'm trying to push my bzr branch to svn and it says 'branches have no common ancestor and no merge base  revision was specified', but with your suggestions it tries to merge 2 svn revisions instead :/
<jelmer> ajaksu, the location you're pushing to can't exist in svn yet if the two branches have no common ancestry
<ajaksu> should I 'svn commit' a copy of bzr rev 1 there?
<jelmer> ajaksu, no, you need to remove the branch you'd like to push to before running "bzr svn-push"
<ajaksu> added a subdir to /trunk and it seems to be thinking... IT WORKS! Thank you, thank you very much jelmer! :)
<ajaksu> sweet, great, thanks! :)
<imyojimbo> hi... i am reading bzr manual, and i just have to say im really enjoying it. bzr is a great tool.
<imyojimbo> great jon guys
<imyojimbo> *job
<jelmer> imyojimbo, thanks!
<jfroy|work> Hello! Is this the right place to ask about bzr-svn?
<LarstiQ> jfroy|work: sure
<jfroy|work> I was just wondering if there was a way to improve or cache http authentication credentials to avoid having to type a password a large number of times. I'm on Mac OS X, and so I would have expected the system keychain to be used.
<LarstiQ> jfroy|work: there are other places you could try depending on what you're looking for (say, bugreports), but bzr-svn is on topic here :)
<LarstiQ> jfroy|work: I believe that is more of a core bzr issue
<jfroy|work> I had a look around, and it seems to be a svn python binding issue, since bzr-svn seems to be importing a binary module of svn authentication methods.
<LarstiQ> ah, what version of bzr-svn are you using?
<jfroy|work> 0.4.12 on bzr 1.6.1
<jfroy|work> Using the system's interpreter
<LarstiQ> jfroy|work: hmm, I was under the impression that version didn't use the python-subversion bindings
<LarstiQ> jfroy|work: to be clear we're speaking about the same thing, does it ask you for credentials a great number of times _per operation_?
<LarstiQ> Say, doing a bzr branch and having to enter it once per revision.
<jfroy|work> a checkout or commit asks me for my credentials 3 times
<LarstiQ> jfroy|work: or do you mean you'd like to cache it across invocations of bzr?
<LarstiQ> jelmer: still around?
<jfroy|work> Correct, across invocations. That is, I'd like it to never ask me for credentials.
<LarstiQ> jfroy|work: ok, that's not a bzr-svn specific issue then.
<LarstiQ> jfroy|work: I believe vila has done some work on that, but I don't think it was with the OS X keychain, although he does use OS X.
<jfroy|work> Subversion has stored them in my account's keychain, and uses that information when invoked directly.
<LarstiQ> jfroy|work: right, I see.
<LarstiQ> jfroy|work: so if bzr had support for Keychain, you'd be happy?
<jfroy|work> The weird thing is line 156 of the auth module in the bzr-svn plugin:
<jfroy|work>     if getattr(ra, 'get_keychain_simple_provider', None):
<jfroy|work>         providers.append(ra.get_keychain_simple_provider())
<jfroy|work> Seems to be it should be working, but isn't
<jfroy|work> It would definitely be useful for deploying bzr around some more :)
<LarstiQ> jfroy|work: agreed :)
<jfroy|work> Sharing repositories with bzr is usually done through SSH, so SSH keypairs work fine, but svn is quite often shared over http[s]
 * LarstiQ nods
<LarstiQ> jfroy|work: I don't know the bzr-svn code in that detail, and jelmer doesn't seem to be around
<jfroy|work> I'm just not clear on who provides credentials to bzr-svn: bzr or the svn libraries (invoked by bzr-svn).
<jfroy|work> I'll troll around until he shows up :p
<LarstiQ> jfroy|work: afaik, unless maybe you're interacting with an svn checkout, it would be bzr.
<LarstiQ> heh :)
<LarstiQ> jfroy|work: you could also aks a question on https://answers.edge.launchpad.net/bzr-svn, or file a bug, depending on the level of certainty you have about things supposed to be working and not doing so.
<jfroy|work> I'll probably take the time to dig into this next weekend. It itches :p
<LarstiQ> jfroy|work: for bzr and Keychain, I'm not sure what the right approach is there nowadays
<LarstiQ> jfroy|work: cool :)
<jfroy|work> Ah, well for that, a plugin might do the trick, if plugins can pipe into the authentication mechanism. I honestly don't think there's a need for it.
<jfroy|work> ssh-agent on OS X stores key credentials in the keychain already :p
<LarstiQ> jfroy|work: plugins can do almost anything
<LarstiQ> jfroy|work: fair enough :)
<jfroy|work> and http is only ever used for read-only public branches, as far as I know
<jfroy|work> At least in my experience
<LarstiQ> well, I wouldn't mind having more of that infrastructure for dealing with svn branches as well
<LarstiQ> jfroy|work: heh, https://bugs.edge.launchpad.net/bzr/+bug/260919
<ubottu> Launchpad bug 260919 in bzr "Ability to register new auth providers" [Wishlist,Confirmed]
<jfroy|work> Such a cute bot :)
<LarstiQ> vila: could others help you with .netrc?
<LarstiQ> jfroy|work: I'm going off to have some dinner
<vila> LarstiQ: sure, patches welcome :D
<vila> I always saw .netrc as a first simple step before addressing gnome-keyring or OS X key chain
<bpierre> hi
<bpierre> what is the state of subtrees support in bazaar?
<beuno> bpierre, LarstiQ is the last person to work on it
<beuno> we may trick him into working on it again
<beuno> but he's getting smarter
<bpierre> :P
<abadger1999> Quick shared repository question:
<bpierre> beuno: subtrees need a specific repository format, right?
<abadger1999> Is there any drawback to putting a shared repository at the toplevel of multiple (possibly many) unrelated branches?
<beuno> bpierre, I don't recall the implementation details. I'm not sure they do
<beuno> abadger1999, maybe performance, but I think it's not too bad
<bpierre> help formats lists development-subtree and 1.6.1-rich-root
<beuno> huh, look at that
<beuno> you could wait for LarstiQ to finish his dinner
<abadger1999> beuno: Thanks!  I'm writing a plugin for a project that checks out source for many different projects to submit translations.
<beuno> or send a mail to the list
<bpierre> the docs on the site are not really up to date, but I got the impression that rich-root was a prerequisite for subtrees...
<abadger1999> Just trying to decide if shared repo @ toplevel or shared repo @ project level makes more sense.
<beuno> ah, I see
<beuno> I'd go for a per-project
<beuno> where they're more likely to share revisions
<abadger1999> <nod>
<abadger1999> Thanks again!
<beuno> welcome'
<LarstiQ> bpierre: yes
<LarstiQ> vila: anything in specific?
<bpierre> LarstiQ: ok, so is it somewhat working? can I switch to 1.6.1-rich-root to do some tests?
<LarstiQ> bpierre: if you want you can try out https://code.launchpad.net/~larstiq/bzr/nested-trees
<LarstiQ> bpierre: I haven't touched it in a while, but the basics should work
<LarstiQ> bpierre: how interested are you in this?
<LarstiQ> bpierre: I wouldn't mind some people reporting results :)
<bpierre> well, I'm evaluating bazaar and subversion for work
<bpierre> as our new VCS
<LarstiQ> ok
<bpierre> we use clearcase now
<bpierre> with UCM
 * LarstiQ has no clearcase experience
<bpierre> and there are 2 uses cases
<bpierre> well, clearcase has support for components
<LarstiQ> bpierre: go on :)
<bpierre> ok, so you can have different part of the tree, like a component for the driver
<bpierre> one for the applications/ui
<bpierre> one for the engine
<bpierre> and then, what you can do when you create a new project, is seed it with components from different projects
<bpierre> so you take the drivers for one platform, the apps for another product
<LarstiQ> ok. Do further commits then get fed back to the originating project?
<bpierre> yes, or just keep doing your own thing, with the ability to rebase to get changes from upstream
<bpierre> that's one use case
<bpierre> the other I'm concerned, is vendor branches
<bpierre> LarstiQ: still here?
<timeless> hello
<timeless> i'm a clueless and very frustrated something
<timeless> imagine i have a directory x/ with x/.bzr/branch/branch.conf with bound_location = something and bound = True
<timeless> but there are no files or directories in x/ other than .bzr/
<LarstiQ> bpierre: yes, real life intervened for a moment
<timeless> how do i get bzr to put all the files back that are managed by bzr?
<timeless> something like a cvs up or hg up or svn up
<jam> timeless: bzr co
<LarstiQ> timeless: there is a bzr up, but your situation sounds like bzr co
<timeless> [timeless@konigsberg bugzilla]$ bzr checkout
<timeless> bzr: ERROR: File exists: u'/data/mxr-data/bugzillamozilla-bzr/bugzilla/.bzr': [Errno 17] File exists: '/data/mxr-data/bugzillamozilla-bzr/bugzilla/.bzr'
<timeless> next?
<jam> timeless: what does "bzr status" give?
<timeless> (yes, i already tried both bzr co and bzr checkout, and a couple of others)
<jam> and what --version?
<timeless> Bazaar (bzr) 1.6.1
<timeless> status gives me lots of stuff
<LarstiQ> bpierre: how do you use components with vendor branches?
<timeless> it says that all the files are removed
<timeless> and that there are Text and Contents conflicts for most of the files
<timeless> and there are "pending merges"
<timeless> and i have a headache
<LarstiQ> bpierre: the classic cvs vendor branches you'd just do with branches in bzr.
<bpierre> ?
<LarstiQ> timeless: bzr revert perhaps?
<jam> timeless: bzr revert
<timeless> thanks
<LarstiQ> bpierre: ah hmm, you meant a usecase for bzr nested trees?
<bpierre> maybe I'm not using the right terminology: you have a thirparty provided driver, libraries and/or sources and header
<LarstiQ> bpierre: right
<bpierre> you want to be able to integrate it in the tree
<timeless> so... my goal is to have a box which makes 0 changes to the contents which it gets from an 'upstream'
<LarstiQ> aah, ok
<bpierre> fix, change some things
<bpierre> and still track the original vendor versions
<timeless> all i want to do is update periodically and have exactly what would be tip on the upstream bzr
<LarstiQ> bpierre: yeah, the fixing or changing some things aren't special, your wanting to integrate it in the tree is where subtrees could come in.
<bpierre> to do a tree way merge when you get a new version
<bpierre> yeah
<timeless> i'm using bzr update to do that
<timeless> should that work?
<bpierre> I guess once you can do that, you can mimic clearcase components
<LarstiQ> timeless: yes
<timeless> larstiq: ok. so it clearly didn't :)
<LarstiQ> timeless: although in that case a checkout doesn't give you any benefits over a normal branch
<timeless> larstiq: i want something simple
<timeless> "set it and forget it"
<LarstiQ> timeless: 'bzr get upstream; bzr pull; bzr pull; etc'
<bpierre> except, once thing clearcase does, is when you make a baseline, which is like a tag, you both get a global tag, for the whole project, and one for each component
<LarstiQ> timeless: as long as you make no changes to the tree, that will do it just fine. If you do make changes, you might need to throw in a `bzr revert` from time to time.
<bpierre> which then can be used by another project to update/merge only some components to/with your version
<gar1t> I have a workflow related question, which comes out of my use of git (am giving bzr a try)
<gar1t> I tend to use git for (among other things) creating local branches to organize my work in chunks that can be applied as single commits to the trunk/mainline. This is a common enough pattern.
<LarstiQ> bpierre: that's basically tagging each component with the same tag in one go?
<LarstiQ> gar1t: right
<gar1t> I'm scratching my head though with bzr. It looks like bzr wants to create new directories for every branch. I need/want to keep everything in a single working directory.
<gar1t> So, the workflow would look like this...
<nDuff> gar1t, why don't you keep your working directory and repo directory separate?
<nDuff> gar1t, that way your repo gets new subdirectories as you start new branches, but the working tree just switches between them.
<LarstiQ> gar1t: branches live in their own directories, but you can switch your working tree between them with `bzr switch`
<gar1t> the repo is a shared repo on a server
<bpierre> LarstiQ: yeah
<LarstiQ> gar1t: and if you use a shared repository without trees `bzr init-repo --no-trees`, the branches won't have working trees themselves.
<gar1t> I want to create "throw away" branches locally and use them for merges.
<gar1t> I created the shared repo (on the server) with the --no-trees option.
<LarstiQ> gar1t: but you don't have a shared repo locally, yet?
<gar1t> hmmm...not sure
<gar1t> I create a repo locally using bzr branch URL
<gar1t> did I miss a local init-repo along the way?
<LarstiQ> gar1t: `bzr branch/get` primarily creates a branch, not a repository
<nDuff> gar1t, if you want more than one local branch at a time, it's probably not a bad idea to have a local repo to keep them in.
<timeless> ok, thanks. i've switched to pull... i'll be back when that breaks :)
<gar1t> so init-repo first and then branch into that?
<nDuff> gar1t, ...presuming that just having multiple separately-checked-out working trees doesn't work for you.
<LarstiQ> gar1t: yup
<nDuff> gar1t, *nod*; that way you get the storage efficiency of shared repos.
<gar1t> yeah -- I'm trying to make branches as incredibly cheap as possible -- creating new directories doesn't really work for this workflow
<strk> use case: regression found, need to figure when introduced
<strk> $ bzr revno; bzr revert -r -10; bzr revno # revno always returns same revision... is there a better practice ?
<LarstiQ> gar1t: see 5.5.3 at http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#reusing-a-checkout
<LarstiQ> gar1t: ok, you really want a --no-trees for that init-repo then :)
<LarstiQ> strk: bzr bisect, see http://bazaar-vcs.org/BzrPlugins
<gar1t> LarstiQ: yeah, looked at that for some time today :)
<strk> LarstiQ: sound interesting, but that page points to no code
<strk> http://bzr.licquia.org/bzr-bisect/ <--- empty dir
<LarstiQ> gar1t: so a fundamental difference between git and bzr is that in bzr branches are directly addressable (by url)
<LarstiQ> strk: bzr branch http://bzr.licquia.org/bzr-bisect/ :)
<strk> ah
<LarstiQ> strk: I don't know if that is the most recent version, I haven't followed it, but I've used it in the past
<strk> bzr branch http://bzr.licquia.org/bzr-bisect/trunk
<gar1t> LarstiQ: use the --no-trees on the local repo as well?
<LarstiQ> gar1t: yup
<LarstiQ> gar1t: that does mean that you'll have seperate directories for each branch, but you don't have to have a working tree for each
<strk> no readme..
<strk> how to install ?
<LarstiQ> strk: it should be installed as a plugin
<strk> there's meta.py, setup.py and tests.py
<LarstiQ> strk: so, have it end up as ~/.bazaar/plugins/bisect/
<strk> and __init__.py
<LarstiQ> strk: then, you have `bzr help bisect`
<strk> ah, the whole dir ?
<LarstiQ> strk: yes
<strk> thanks
<LarstiQ> gar1t: the documentation mentions 'bzr switch path/to/branch', but iirc 'bzr switch <foo>' where foo is a sibling of the current branch you're bound to also works
<LarstiQ> gar1t: so that would become 'bzr switch X-1.0' instead of 'bzr switch ../X-1.0'
<bpierre> mmm, on the subject on bisect, you can't really change the revision of you working tree right? like go back? I used bisect and I was under the impression it was doing the equivalent of `revert -r rev`
<bpierre> so if you do a status, you seed the diff between rev and the head of the branch, right?
<fullermd> bpierre: Yes.  And revert's a straight blat, it won't do any change merging like an update -r should.
<strk> is there a way to know what revno you end up with after a revert ? (or bisect, which I guess uses revert underneat)
<bpierre> ok
<bpierre> that's something I kinda liked with monotone
<LarstiQ> strk: revert changes the filecontents to the revision you specified.
<LarstiQ> strk: bisect has a bit more of documentation
<LarstiQ> strk: you set a begin and start revision, and then it does a binary bisect between those
<LarstiQ> strk: and depending on your answers, it chooses which branch to continue in
<awilkins> bisect rocks, even when it discovers that I caused the bug ;-)
<LarstiQ> Odd_Bloke: what happened to your bisect changes?
<Odd_Bloke> LarstiQ: I expect they're on LP.
<fullermd> bpierre: Well, as bug 45719 says, it's something to kinda like about...   well, everything but bzr   :p
<ubottu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,In progress] https://launchpad.net/bugs/45719
<Odd_Bloke> I think it got awkward enough to polish them off that I kind of tailed off.
<bpierre> ok
<LarstiQ> Odd_Bloke: aaah :)
 * LarstiQ badges Odd_Bloke to pick it up again
 * fullermd pets ubottu.
<LarstiQ> bpierre: config-manager is an older solution to the nested-trees problem
<bpierre> what does it do?
<strk> I'm not sure I understand how bisect works. I know head has the bug (revno 9760) and I manually tested revno 9600 doesn't have the bug
<strk> how do I proceed ?
<bpierre> again, not a lot of documentation!
<strk> (9760) bzr bisect start
<strk> bzr bisect no -r 9600 ?
<LarstiQ> bpierre: maintain configs for checking out multiple trees
<bpierre> ok
<LarstiQ> bpierre: for the nested-trees branch on launchpad, it's basically: 'bzr branch other/branch subtree; bzr add subtree; bzr ci'
<bpierre> ok, so you can commit transparently across trees?
<LarstiQ> bpierre: that's the idea, yes
<bpierre> what happen if another project include a derived tree? can you cherry pick?
<LarstiQ> bpierre: there are still some buggy corner cases if you `bzr mv` across subtree boundaries
<bpierre> can you push only a subtree?
<LarstiQ> bpierre: yes
<bpierre> ok
<LarstiQ> bpierre: if you do a commit in the containing tree, it will recurse into subtrees, do it's stuff there, and then record the subtree state in the containing tree
<LarstiQ> bpierre: so the contained ones can still be worked upon by themselves
<LarstiQ> unless my brain is very rusty
<bpierre> so, I can have a repository r1 with a branch, say my main vendor branch, include it in my tree (and repository) push only the subtree to another branch in r1 for other project to cherry pick/merge?
<LarstiQ> bpierre: so, this code is rather old, I _think_ the basics work, but you might run into some rough patches. Would you be willing to try it out and work with me getting it fixed up?
<bpierre> sure, I was in the process of setting up a small test project
<LarstiQ> bpierre: I think we might have different terminology on cherry picking
<bpierre> :P
<bpierre> merge only a particular revision?
<LarstiQ> bpierre: if you mean, can I get just the changes in the subtree in my other project, then yes
<bpierre> not a full blown merge
<LarstiQ> bpierre: subtrees are their own seperate branches
<bpierre> ok
<bpierre> and tags are dupplicated too?
<LarstiQ> bpierre: so there are no non-subtree revisions in the subtree you'd want to not-merge
<LarstiQ> bpierre: now tags is a good question
<LarstiQ> bpierre: I'd assume so, but I'd have to check
<bpierre> ok
<bpierre> I'm in France, going to go to bed, but if you want me to do some tests tomorrow evening, I'm available
<LarstiQ> bpierre: cool, I'm in The Netherlands
<LarstiQ> bpierre: I'll be busy training most of the evening probably, but we'll see
<LarstiQ> bpierre: my client is always here, and I respond to backlog
<bpierre> same goes if someone want to check a possible fix for https://bugs.launchpad.net/bugs/269456 :D
<ubottu> Launchpad bug 269456 in bzr "checkout operation consume too much resources" [High,Triaged]
<bpierre> hehe
<bpierre> ok, won't be at home this week-end, but other than that, happy to do some testing on the week-end
<LarstiQ> bpierre: sweet
<gar1t> LarstiQ: after some navel staring, I think I understand
<LarstiQ> bpierre: that also gives me a bit more time to get back into the code ;)
<bpierre> ok
<bpierre> bye
 * LarstiQ looks up what navel staring means
<gar1t> LarstiQ: when pushing back to the central server -- is it better (for whatever reason) to push from the local repo, or can I push from the local working branch?
<LarstiQ> gar1t: ah :)
<gar1t> LarstiQ: lol, not sure if wikipedia covers that one ;)
 * LarstiQ found an article under 'wisegeek.com' fwiw
<LarstiQ> gar1t: I don't use that workflow myself, but afaik if you have your push location set in your branch, doing a push from your working tree will use that location and do the right thing
<gar1t> that's a very good explanation
<LarstiQ> it certainly would be the behaviour I expect.
<gar1t> LarstiQ: seems to work fine either way
<gar1t> thanks for the explanation -- that cleared up some things for me
<LarstiQ> gar1t: glad to be of help
<Odd_Bloke> https://code.launchpad.net/~daniel-thewatkins/bzr-bisect/automated is my bisect work.
<Odd_Bloke> Testing and bug reports would be appreciated.
<LarstiQ> ok
 * LarstiQ adds it to his todo list for tomorrow
<johan> is it possible to run a shell script as a post_commit hook for a bzr branch?
<gar1t> dir
<gar1t> sry - wrong window :(
<lifeless> johan: yes, via jelmers shell-script-hooks plugin, or via a python plugin that looks for a shell script and runs it
<johan> lifeless: okay, so no upstream support atm. Is that planned for the future?
<lifeless> johan: for some value of planned
<johan> lifeless: it would make sense, since not all users of bzr knows how to program python
<lifeless> we had a long debate; I'm happy with us supporting them as long as their presence does not reduce the clarity of interface of the python hooks
<lifeless> or try to make things equal, when obviously shell scripts are going to be slower and more limited because they can't access already present objects
<lifeless> johan: well, not all users of bzr know how to program shell either
<lifeless> johan: for instance, on windows, vbscript is probably a better common language
<lifeless> anyhow, as I say: there is [at least] one plugin that enables this, I don't think it needs to be in core to be considered available
<lifeless> johan: is there a particular reason you want this?
<imyojimbo> hi, say,  what kind off diff tool do you use?
<cody-somerville> imyojimbo, I use diff myself
<lifeless> imyojimbo: I don't use an external tool
<lifeless> imyojimbo: some folk like meld
<lifeless> imyojimbo: some folk on windows use commercial tools, I don't remember the name, but bzr can be configured to call out to them
<lifeless> garh I hate wiki advertising
<lifeless> http://nouveau.freedesktop.org/wiki/OProfile
<lifeless> note the reason it turns up on google under 'oprofile python'
<Kittens> lifeless, adblock plus :)
 * Verterok wonders if he found a bug or a feature
<lifeless> Kittens: how would that help ?
<Kittens> lifeless, get rid of the wiki ads
<Kittens> :p
<lifeless> Kittens: I'm going to guess you are assuming a bunch of things by what I meant and haven't looked at the wiki page in question at all.
<Verterok> while committing a merge, if all touched files are specified to commit it's rejected
<Kittens> fine fine if i must click
<lifeless> Kittens: if you *are* assuming, please don't :>
<Verterok> it's that behaviour ok?
<Kittens> lifeless, i assume a lot :p
<Kittens> sorry
<lifeless> Verterok: committed a merge, no parameters should be passed
<Kittens> it's one of my "features"
<lifeless> Verterok: sorry, I mean, 'committing' and 'no sub paths'
<lifeless> Kittens: np
<beuno> lifeless, but does it make sense to reject a commit if all changed files in the merge are being specified?
<Verterok> lifeless: thanks, but if I pass all the "changed/touched" files as prameters?
<beuno> hiya poolie
<poolie> hello beuno
<poolie> hello jam
<lifeless> Verterok: beuno: its a performance question. Can we tell there are no other altered or merged files without making commit slower by doing so.
<lifeless> currently, the answer is 'no'. I'm not sure that in theory it can be made 'yes'.
<beuno> so it's a performance tradeoff?
<Verterok> lifeless: thanks for the explanation
<lifeless> anyhow, I think the real bug is that we haven't implemented the necessary graph sophistication to support cherrypicks in all their beauty - partial graph references including references to partial merges
 * Verterok starts fixing bzr-eclipse commit when a merge is pending :(
<lifeless> in a philosophical sense, 'all modified from the merge' could be a set larger than that shown by 'diff' or 'status' due to per file graph joining
 * beuno blinks
 * Verterok too
<beuno> aha
<lifeless> so while I can agree in principle 'if all the changed files are specified', I don't think eclipse would actually be listing 'all the changed files', and once we do proper cherrypick merge support, I'm quite positive it wouldn't do what you want it too
<Verterok> lifeless: the particular problem I'm having in bzr-eclipse, is that when the commit dialog is opened, it shows all the modified files (in a table with checkbox)
<Verterok> by default, bzr-eclipse use the selected files in the commit command
<Verterok> so, I need to check if there is a pending merge, and don't allow the user to select/unselect the files, and also avoid using the file list in the commit
<lifeless> Verterok: yes, I think that makes sense
<Verterok> it's just that I missed this restriction while committing a merge
<lifeless> Verterok: and/also I suggest that if everything is selected, you don't pass in a file list anyhow, its simpler
<Verterok> lifeless: sure, that makes sense :)
<lifeless> looking further
<lifeless> I think it would be nice to allow commits to be edited after-creation before completion. [handwaving] build the full commit and inventory and have an object listing all the items changed, with a method to exclude an item. So call that, it removes it from the commit and puts it back to the parent (not doable in merge commits for now)
<lifeless> you could receive this object over the xmlrpc service
<lifeless> and edit it in the window live
<lifeless> then when you supply the commit message, the final inventory is written, the revision added and its done
<lifeless> Verterok: ^
 * Verterok blinks
<Verterok> lifeless: I need think about this a bit :)
<Verterok> (actually understand it :p )
<lifeless> Verterok: sure :P
<Verterok> lifeless: that's a nice idea.
<Verterok> lifeless: currently the xmlrpc service don't allow this kind of interaction between client-server
<Verterok> but it's a nice feature to add :)
<beuno> mwhudson, amanica has a few questions with your name written all over them
<beuno> "integrating loggerhead into gforge"
<beuno> "...and why paths suck"
<mwhudson> beuno: oh?
<mwhudson> amanica: i'm here now
<amanica> hi
<amanica> I'm writing a plugin to gforge which uses loggerhead to browse the branches
<amanica> but  at one place I can obtain the path to a file which includes the branch, repo or other dirs
<amanica> so I have two ideas:
<amanica> 1) in stead of  http://127.0.0.1:8080/bzr.repo/bzr.dev/annotate/head:/tools/biobench.py  ->  http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py
<amanica> 2)  in stead of  http://127.0.0.1:8080/bzr.repo/bzr.dev/annotate/head:/tools/biobench.py  ->  http://127.0.0.1:8080?annotate=/bzr.repo/bzr.dev/tools/biobench.py
<amanica> i.e. in gforge I dont know how to split the path into a branch part and a reletive to branch part
<mwhudson> amanica: you don't want to have the head: in there?
<amanica> I dont mind the head part so long as it is not in the middle of the url
<mwhudson> right
<mwhudson> i don't know a good answer to this, really
<amanica> I dont mind hacking on this, but I dont want to go into my own little fork
<mwhudson> in some ways, i'd be fine with  http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py being the annotate view
<mwhudson> but then how do you get to the changes view?
<mwhudson> you could do
<mwhudson> in some ways, i'd be fine with  http://127.0.0.1:8080/bzr.repo/bzr.dev/+changes
<amanica> or  http://127.0.0.1:8080/bzr.repo/bzr.dev?changes
<mwhudson> and then hope noone calls a file '+changes' ....
<mwhudson> i think using query args for this is kinda gross
<mwhudson> but it would work, i guess
<amanica> gross, why?
<mwhudson> well, i guess because it's a fundamentally different resource
 * Odd_Bloke thinks /+changes is nicer that ?changes.
<amanica> or maybe just a different view to the same resource
<amanica> I think using query args will be a lot cleaner
<mwhudson> the thing is, in bazaar the branches are the most important thing
<mwhudson> then the revisions
<mwhudson> then the content of the revisions
<mwhudson> (at least imho)
<amanica> and we dont have to worry about accedental conflicts
<amanica> as I said, 2) may be an acceptable workaround with the least impact (I think)
<mwhudson> it still offends my sense of style, i'm afraid
<amanica> I still think it will be cool to go staight to http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py  and the file contents pop up
#bzr 2008-09-17
<lifeless> I'd say
<amanica> I've never heard of a style to not use query args
<lifeless> ?action=annotate
<lifeless> would be a reasonable use of query args
<amanica> nice
<lifeless> so http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py?action=annotate
<lifeless> without that get the raw bytes of the file
<lifeless> or alternatively
<lifeless> so http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py?action=raw
<lifeless> and without that get the pretty view
<amanica> what pretty view?
<lifeless> annotated text is the pretty view :)
<amanica> :)
<poolie> lifeless, spiv, jam, call in 2m
<lifeless> I think allowing space in the URL's for revision and stuff is good
<amanica> as mentioned previously the only problem is: there are special files eg:
<lifeless> so http://127.0.0.1:8080/bzr.repo/bzr.dev/head:/tools/biobench.py?action=raw
<lifeless> is better IMO
<amanica> http://127.0.0.1:8080/bzr.repo/bzr.dev/files
<lifeless> an alternative is
<lifeless> http://127.0.0.1:8080/bzr.repo/bzr.dev;rev=head:/tools/biobench.py?action=raw
<amanica> so we might need to change http://127.0.0.1:8080/bzr.repo/bzr.dev/files -> http://127.0.0.1:8080/bzr.repo/bzr.dev?files
<thumper> when is the new bzrtools going to be packaged in the bzr ppa?
<lifeless> bbs
<thumper> right now I'm holding off installing the 1.7rc as it wants to remove bzrtools
<thumper> and I use bzrtools all the time, and don't want it removed
<thumper> nor do I want to use a non-packaged bzrtools
<amanica> in my use case http://127.0.0.1:8080/bzr.repo/bzr.dev;rev=head:/tools/biobench.py?action=raw is not really an option (I dont know where to split the path)
<mwhudson> amanica: well, default would be to show the head revision presumably
<amanica> yup
<mwhudson> amanica: so far i've been restraining myself a little from suggesting you fix gforge instead/as well :)
<amanica> and I'd have to add another param for rev=123
<amanica> I am busy fixing it :)
<amanica> I can do a bzr revno on every folder in my path to determine if it is the branch
 * beuno -> home + dinner
<amanica> but that didnt work for me
<amanica> I have been using `bzr branches` to get a list of branches
<lifeless> bzr root
<lifeless> will tell you where the root is
<amanica> whcih I can compare to the full path to see if I can determine which one is in use
<amanica> ah
<amanica> But I thouth if loggerhead is cleaver enough in any case I dont need to mess with that
<johan> lifeless: no, just that shell scripting makes a bit more sense than a python plugin, for hooks.
<mwhudson> amanica: in any case it's by now pretty easily to write wsgi stuff to do url traversal however you like
<mwhudson> amanica: unfortunately the links that get generated will be all wrong :/
<mwhudson> if you care to tackle _that_ problem you will definitely be my friend
<amanica> which _that_ problem?
<mwhudson> amanica: the link-generation problem
<amanica> is this wsgi stuff in loggerhead
<amanica> or do you mean write a site wrapper?
<mwhudson> loggerhead is all wsgi these days
<amanica> ok, Ive not seen this link generation problem
<amanica> so now that I can determine the branch root, I would be able to split up the url.
<mwhudson> amanica: well it's the standard thing of making sure that the way you generate urls and the way you interpret them line up
<manunderground> hey does bzr support something similar to git's submodules?
<manunderground> or bitkeepers ability to reference other repos?
<mwhudson> amanica: loggerhead is flexible enough to allow the way you interpret urls to be changed easily
<mwhudson> amanica: but the way they are generated is very hard coded and horrible
<amanica> oh ok
<manunderground> ???
<amanica> I didn't really intend to change the url generation, but mainly just to support alternate urls
<amanica> mwhudson: I would still need a way to do this for a specific revno
<Peng_> manunderground: Like svn:external? Something like that has been In Progress for ages.
<manunderground> peng_ dunno if it's the same but I imagine it is, not familiar with svn:external
<manunderground> it is simply the abillity to have one repo reference another as another working item
<mwhudson> manunderground: people here may not be familiar with git submodules :)
<manunderground> here's the use case, you have a suite of apps, you want each app to have its own repository
<manunderground> you want the suite to have a repository, too, maybe it has an installer or something
<manunderground> so the suite references the app's repos
<manunderground> (which in turn reference feature repos? AHHH)
<amanica> mwhudson: BTW I'm not really a gforge guy, but my company is going to use it, and I HAVE TO USE BZR OR I'LL DIE. so I'm writng a plugin....
<amanica> mwhudson: so I still like/need something like http://127.0.0.1:8080/bzr.repo/bzr.dev/tools/biobench.py?revno=123
<manunderground> so, it doesn't exist but it's planned and not exactly forthcoming?
<mwhudson> amanica: right, it can probably be added easily enough
<amanica> I'm ok with that, but I'd prefer to work on something that will have a chance to get merged in the future, than going off into my own little fork
<Kilroo> manunderground: I was just reading something today about different directory structures you can use for repositories with Bazaar.
<amanica> thats why I'm trying to get an idea of what others want. and surprisingly its not what I thought
<Kilroo> A couple of them were essentially ways where you have a shared repository for a collection of projects and then separate projects within that repository.
<Kilroo> But I can't find the page again, so I'm not sure how closely it resembles the organization pattern you describe.
<manunderground> Kilroo: hm, hard to say, but it'd be cool if you found that again
<manunderground> I think this is actually a very important feature
<mwhudson> manunderground: there are kind of two answer to this, there is "nested trees" which i woudn't hold your breath for, and there is "config-manager" which collects branches into one tree on disk
<manunderground> mwhudson: so can you explain "collects branches into one tree" means
<fullermd> manunderground: And in bzr terms, you mean 'branches', not 'repos'.
<manunderground> oh ok
<manunderground> haha
<manunderground> thanks
<manunderground> but then I assume that the branch is the entire tree?
<manunderground> (meaning, you can trace out the entire tree from the branch)
<fullermd> Well, branches are what you work with.  You never work with 'repos'.
<manunderground> alright, let me try to clarify thigns here. when I say repo I mean a tree
<manunderground> with the root
<manunderground> and a branch is not the full tree, right?
<manunderground> the tree is a collection of branches
<manunderground> and I'd like to have, say, 3 independent trees
<manunderground> then a fourth one which references the other three
<manunderground> (and ideally doesn't have to put import all their files or history)
<manunderground> so it's a reference that I'm looking for, I think :-)
<fullermd> As I understand you, you'd have 3 branches, and then a fourth branch with not much in it, but references to those other 3.
<fullermd> (assuming that nested trees were up and running)
<manunderground> alright, that sounds like what I want, so that is supported?
<fullermd> No.
<fullermd> Now, there's nothing stopping you from arranging the 3 branches however you want on your system.  But the bits that allow automating treating them as a single entity from the outside aren't there.
<manunderground> oh ok, so you would have then if I understand you there's no way to track the history of references in your project? You could put some placeholder dirs or readmes, etc, but not actually reference the other projects repo's
<manunderground> haha, minus the "so you would have then" bit...
<jml> poolie: woot.
<poolie> jml, ?
<jml> poolie: saw the call minutes :)
<jml>  * looking at failure jml is seeing on stacked
<poolie> was there any other news on it from your side?
<jml> poolie: I've filed bugs with easy steps to reproduce the symptoms, that's about it.
<LaserJock> can lightweight checkouts be pushed to LP?
<jml> LaserJock: only branches.
<LaserJock> hmm, interesting
<LaserJock> so the only good way of sharing changes to a lightweight checkout is to send patches?
<jml> I'm a little confused.
<LaserJock> sorry
<jml> by 'changes to a lightweight checkout', do you mean 'local edits without commits'?
<jml> it's ok, I'm just having a slow day :)
<LaserJock> no
<LaserJock> I mean, I want to get a branch from LP, make some commits, and then get it back to the author
<LaserJock> I was wondering if a lightweight checkout would work for that or not
<LaserJock> can I make local commits on a lightweight checkout even?
<jml> I don't think so.
<jml> well, you can if it's a lightweight checkout of a branch you have write access to
<jml> oh
<jml> but they aren't local
 * jml should really try today again.
<LaserJock> I don't think I have write access either
<jml> LaserJock: I think you'll need to make a real, honest-to-goodness branch.
<mwhudson> soon, you'll be able to branch --stacked
<LaserJock> mwhudson: that'll give me partial history?
<mwhudson> basically yes
<jml> although I imagine that for heavy hacking you'll still probably want a shared repo model â not sure.
<lifeless> LaserJock: if youwant to commits you need write access; a stacked branch will work, or a normal branch
<LaserJock> lifeless: right, I was wondering if I could do a lightweight checkout and then push it to my bzr space
<LaserJock> makes sense though that that wouldn't exactly work
<LaserJock> ok, another question. when I'm branching I get a notice that the branch format is old
<lifeless> complain to the branch owner
<LaserJock> ok
<lifeless> (they should upgrade it)
<LaserJock> I wondered if I should upgrade it or if they should
<lifeless> unless you have write access, you can't
<LaserJock> but I'm not sure if it's just because I'm using newer bzr or not
<lifeless> if you do, then you can [with some tricks if its on launchpad]
<LaserJock> is there a table of formats vs bzr version?
<lifeless> core formats have versions in them, that indicate the introducing version
<lifeless> formats that don't have a version in them are either very old (0.8 or so)
<LaserJock> so this ones says: RepositoryFormatKnit1
<lifeless> or plugin formats that you need a specific plugin for
<lifeless> there should be a line at the top
<lifeless> someting like 'knits' - anyhow, thats a very old format
<lifeless> bzr 0.8 and above read and write it, but its slow.
<LaserJock> yeah, this branch is taking *forever*
<LaserJock> I'll perhaps mention it to mvo tomorrow
<LaserJock> if you upgrade a branch how does it know what to upgrade to? does it just go to the latest default?
<lifeless> with the exception of bzr-svn branches, it goes to the current default, which we are conservative about changing
<lifeless> the current default works with bzr 0.92 and above
<LaserJock> ah, ok good
<lifeless> with bzr-svn branches it will error, as you need to manually specify what to upgrade to
<LaserJock> I was wondering if it's easy to get a situation where a person upgrading via bzr.dev ends up doing bad things for other users
<lifeless> LaserJock: if we were silly, it would be :P
<LaserJock> well ... :-)
<LaserJock> jeeze, this thing is using like 2 KB/s
<lifeless> "slow" :P
<LaserJock> I guess I could start like 10 branches at the same time :-)
<fullermd> Well, using bzr.dev caused bug 261339, frex   :p
<ubottu> Launchpad bug 261339 in bzr "Upgrade from knit to pack fails on revision not present" [Critical,Fix released] https://launchpad.net/bugs/261339
<fullermd> (well, maybe not precisely caused, but caused to exhibit anyway)
<LaserJock> hmm, has the idea of combining init-repo with branch come up?
<jml> LaserJock: kind of.
<jml> LaserJock: rockstar and I have talked about a plugin that does the init-repo when fetching a branch for the first time.
<LaserJock> yeah, something like that
<LaserJock> I always forget
<jml> LaserJock: it's slightly complicated by the fact that some people like to keep their local branches separate from their working trees.
<LaserJock> so like you would have ~/branches/* and then  ~/working ?
<jml> LaserJock: something like that.
<jml> LaserJock: to do that manually, you'd go 'bzr init-repo --no-trees ~/branches; cd ~/branches; bzr branch <whatever>; cd ~/trees; bzr co --lightweight ~/branches/<whatever>'
<jml> maybe there's an easier way.
 * jml shrugs
<jml> I mix trees and branches with merry abandon.
<LaserJock> oh woah, that's interesting
<jml> thumper, abentley and others use that layout
<jml> and can help you more if you're interested
<LaserJock> jml: why do init-repo in ~/branches ?
<LaserJock> instead of just doing individual branches
<jml> LaserJock: it creates a repository (that is, a bucket for revisions) that can be shared between branches.
<jml> LaserJock: this saves space and also makes certain operations faster
<LaserJock> so I guess if you had branches with similar history it'd help
<jml> in particular, making new branches and fetching branches from remote hosts
<jml> LaserJock: right.
<RAOF> And, by "certain operations" jml means "branching".  And by "faster", he means "like a hojilion times faster".
<jml> LaserJock: so actually, you _wouldn't_ do "init-repo ~/branches"
<jml> you'd probably do "init-repo ~/repos/<my-project>"
<jml> and then "init-repo ~/repos/<another-project>"
<LaserJock> I was reading about a science professor who was using bzr repos for papers
<rockstar> jml, LaserJock it just so happens that I'm polishing that plugin right now.
<LaserJock> so if he had a new paper or presentation he'd bzr branch
<LaserJock> seemed like a really cool idea
<jml> I know at least one PhD student who uses Bazaar for their thesis.
<jml> maybe two.
<LaserJock> that's what I'm doing right now ...
<LaserJock> it's nice to know what revision I gave my advisor to read
<LaserJock> the idea of a presentations bzr repo is interesting, since often they are a fairly linear progression
<rockstar> Hom do I get a branch's format in bzrlib Branch?
<rockstar> s/Hom/How
<mwhudson> rockstar: from a branch object?
<mwhudson> b._format.get_branch_format() i think
<jml> well
<spiv> LaserJock: I habitually make branches for any slides I'm working on
<jml> assuming a certain modernity.
<jml> there isn't actually a consistent way across all formats, I don't think.
<rockstar> *gasp* An API where I have to access the a property starting with _
<spiv> LaserJock: I don't think I've ever looked at the old revisions, but just knowing that I *can* lets me relax and delete unused ideas and whatever from my slides rather than leaving them floating around until the last moment in case I decide I might want to use them after all.
<LaserJock> spiv: yeah, exactly
<rockstar> jml, the use case is this:  I have my plugin, and I'm getting repository/branch format conflicts
<jml> rockstar: that's not a use case :)
<jml> rockstar: what are you doing to get these conflicts?
<LaserJock> I wish I could go back in time 6 years and input everything into bzr :-)
<rockstar> jml, let me finish!
 * jml does so
<jml> LaserJock: putting Bazaar back in time six years would solve a lot of my problems.
<rockstar> So, I get conflicts when I create a repository with the default format, and then try to put a branch in the repo that doesn't have a compatible format.
<rockstar> So I needed to open the branch to check the format BEFORE I create the repo.
<jml> rockstar: so, you need to open the url as a BzrDir and then check the repo format
<jml> I guess.
<rockstar> jml, yes.  However, mwhudson's response seems to be incorrect.
<mwhudson> rockstar: i think you can look at the cloning metadir for that
<rockstar> mwhudson, Would this help? http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.branch.BranchFormat.html#find_format
<poolie> ok, really focussing on 270738 now
<jam> poolie: the patch you posted conflicts with spiv's remote error fixes (bug #2613515)
<ubottu> Error: Launchpad bug 2613515 could not be found
<jam> 261315
<jam> bug #261315
<ubottu> Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315
<jam> bug #270738
<ubottu> Launchpad bug 270738 in bzr "AttributeError when branching stacked branches" [Critical,New] https://launchpad.net/bugs/270738
<jam> jml mentioned it, I just confirmed it
<poolie> jam, i intentionally did mine off an old branch to ease integration into 1.7
<jam> sure
<poolie> i guess i should merge it into 1.7? or just into trunk?
<jam> just that the 1.7 branch *has* spiv's changes
<poolie> or rather, merge them into me
<jam> poolie: right, just 1.7
<jam> poolie: the change to "get_stacked_on_url" seems like it should be a per_branch test
<poolie> jam, do you mean that you can still get it even if the repo can't accommodate it?
<rockstar> Okay, so it looks like the branch is a RemoteBranch object.  Is there a way to get the format of the RemoteBranch?
<poolie> hm, maybe
<jam> poolie: right, just that it changes the API of the function
<jam> to always return the config value
<poolie> rockstar: remotebranch._real_branch.format unfortunately
<poolie> if you want the on-disk format
<jam> Personally, I prefer it to return None rather than raise an exception, but that is a long-ago discussion that got missed
<rockstar> poolie, _real_branch is apparently None
<poolie> call ._ensure_real then
<poolie> jam, i know
<poolie> i wonder if it would be better to just change it anyhow though
<poolie> like, will there really be that many external callers of it?
<jam> poolie: why do you have the "self._remote_path()" instead of "self.bzrdir._path_for_remote_call()" ?
<jam> I think it is *better* I just don't see why it was important for this patch
<poolie> i just didn't want to copy & paste it again
<poolie> um
<poolie> i feel a tension between doing focussed patches and cleaning things as i go
<jam> sure
<jam> I was mostly just trying to understand the patch and where I needed to focus
<jam> I'm fine with the cleanup
<jam> though generally for a rc hotfix I would avoid them
<poolie> true
<LaserJock> is there a possibility of a branching from LP just stalling?
<LaserJock> I'm going on 1.5 hrs now and I'm not sure if there's any progress
<lifeless> LaserJock: strace the process
<lifeless> LaserJock: is it a big project?
<LaserJock> I didn't think so
<LaserJock> gnome-app-install
<LaserJock> 600 or so revisions
<LaserJock> but the actual size shouldn't be bad
<lifeless> its more file-count that breaks knits
<LaserJock> ok, strace says it's still doing stuff
<abadger1999> When using relative directories for workingtree.add() and workingtree.smart_add(), what is it supposed to be relative to?
<lifeless> abadger1999: add is relative to tree root
<abadger1999> My test is showing it's relative to the cwd, but the documentation says it should be relative to the wt root.
<lifeless> smart_add is a little broken, its relative to pwd
<abadger1999> Ah... maybe add is giving me a different error then.
<abadger1999> lifeless: To make smart_add work as expected, do I need to os.chdir() to the tree root and then back after the call?
<LaserJock> lifeless: 227 files for 2.7MB is the source tree
<abadger1999> relpath() broken too?
<lifeless> abadger1999: no, just give the relpath from cwd
<abadger1999> Ah. rigt.
<abadger1999> lifeless: Thanks
<jam> poolie: BB:tweak sent to the list
<lifeless> LaserJock: so it will be ~ 227 * 2 * RTT + BW*(history size)
<poolie> i'm just working on the test merge, thanks john
<LaserJock> lifeless: well, as long as I know it's still working I'll stick with it. I just didn't see the progress bar or "pinwheel" moving so I wondered if somehow it got hung up
<lifeless> bbs, lunching
<poolie> LaserJock: over ssh or http?
 * rockstar is having a hell of a time creating a repository with a format compatible with this branch
<spiv> rockstar: source_branch.repository._format.initialize(target_bzrdir) ?
<rockstar> spiv, well, the way it works on branches that use a something besides knitpack is:
<rockstar> format = bzrdir.format_registry.make_bzrdir('default')
<rockstar> newdir = format.initialize_on_transport(to_transport)
<rockstar> repo = newdir.create_repository(shared=True)
<spiv> The default repository format isn't compatible with all branches, though.
<LaserJock> poolie: ssh
<rockstar> spiv, yea, experiencing this now.
<lifeless> rockstar: what are you trying to do?
<spiv> rockstar: so what problem are you trying to solve?  If it's "make a branch into a new shared repository", then you probably want to preserve the original format.
<rockstar> spiv, yes, that's why I'm fixing the bug.  :)
<spiv> rockstar: if so, I'd make a new *empty* bzrdir, then use my suggestion above (passing shared=True), then just branch.sprout into a directory under that.
<rockstar> lifeless, I've been sitting on this plugin for a while that creates a shared repository and puts a branch inside.
<lifeless> rockstar: create the repo by using the source repo's bzrdir to sprout
<lifeless> source_branch.repository.bzrdir.sprout()
<rockstar> lifeless, wow, I think you just took out most of my code with that (provided it works)
<poolie> LaserJock: i'm hoping to work soon on better progress messages for ssh
<poolie> spiv, jml, lifeless, Functional Programming Sydney is on tomorrow at 6:30 at google
<LaserJock> poolie: are they different than for http?
<poolie> LaserJock: without going into detail yes the codepath is a bit different
<spiv> poolie: d'oh.  It's a birthday dinner for my mother tomorrow night.
<jml> poolie: ooh.
<LaserJock> what's the 0/4 step in branching? copying over revisions?
<rockstar> lifeless, remote_branch.repository.bzrdir.sprout() seems to be sprouting the branch, not a repository.
<lifeless> ah yes, I was a bit quick there :P
<lifeless> LaserJock: file texts
<wgrant> It is ridiculously slow. I can't see how it could be so slow even if it is plain knits.
<poolie> spiv, i know it's probably in a message somewhere but
<lifeless> rockstar: so the source.repository.bzr._format object should be parameterised correctly
<poolie> what is the point of the error translation change in your landing to 1.7?
<poolie> just asking to know, not cause i disapprove
<jml> wgrant: what is?
<wgrant> jml: Checking out the branch that LaserJock is attempting to check out.
<jml> wgrant: from Launchpad?
<wgrant> Yes.
<LaserJock> wgrant: oh, it finished!
<LaserJock> Branched 616 revision(s).
<LaserJock> real    147m15.237s
<wgrant> LaserJock: How big is it all up?
<LaserJock> .bzr is 33MB
<rockstar> lifeless, parameterized correctly how?
<lifeless> LaserJock: run 'bzr upgrade' in your copy
<lifeless> LaserJock: it will at least make your push, when you publish to LP, nice and fast :)
<wgrant> What is the status of stacked branches (with LP)?
<LaserJock> lifeless: do I run upgrade in the branch or in the root of the share repo?
<jml> wgrant: the next rollout will support them and have a default stacking policy set up for certain projects.
<LaserJock> *shared
<lifeless> LaserJock: oh, if you have a shared repo already, its probably already packs
<wgrant> jml: The rollout in a few hours?
<LaserJock> lifeless: oh, so was it taking so long because it was converting as it was branching?
<wgrant> Do we get docs on how to use them, or do we have to work to actually discover that they are supported, and work harder to work out how to use them?
<AfC> oh, snap
<jml> wgrant: that rollout, yes.
<lifeless> LaserJock: it shouldn't have no, the conversion from knits to packs is trivial - we just strip off some metadata
<LaserJock> hmm, this doesn't look good. bzr info in the branch gives: Repository tree (format: unnamed)
<wgrant> jml: Aha.
<jml> wgrant: using them is a Bazaar issue :)
<wgrant> jml: How does LP define a stacking policy?
<wgrant> Or is that a branch property?
<wgrant> Your statement about doing it for certain projects above has me confused.
<jml> wgrant: a branch can be stacked on another branch. Bazaar has a feature where new branches can be automatically stacked on a preconfigured branch.
<lifeless> LaserJock: there is a bug on that
<lifeless> LaserJock: just run 'bzr upgrade' in the new branch
<lifeless> LaserJock: that will upgrade it to a tags-supporting branch
<wgrant> jml: Right, that makes sense, but I wondered how LP came into the configuration equation.
<jml> wgrant: roughly speaking, Launchpad will stack branches on the development focus branch by default.
<wgrant> I fail to see how Launchpad can decide that, but I guess I've no choice but to trust you!
<lifeless> lp tells bzr what to stack on
<jml> wgrant: I'm not sure I follow.
<wgrant> jml: Normally when I push a branch to LP, LP doesn't interfere. I just upload the branch over sftp or bzr+ssh, and LP eventually scans it. LP has no say in the upload.
<LaserJock> lifeless: yeah, bzr upgrade was trivial and got me a recognizable format
<jml> wgrant: so, Launchpad tells the client 'you should stack your branches on URL', and the client says 'OK'
<wgrant> jml: Aha, that makes sense.
<jml> wgrant: except actually because bzr is request / response, Launchpad only answers questions
<wgrant> I presume that this doesn't work unless I use bzr+ssh.
<jml> actually, sftp works fine too.
<spiv> poolie: It was for https://bugs.launchpad.net/bzr/+bug/263527
<ubottu> Launchpad bug 263527 in bzr "ErrorFromSmartServer should not cause a traceback" [Medium,Fix released]
<spiv> poolie: basically it doesn't scare users with a client-side traceback when it's (probably) the server that's having the problem.
<jml> wgrant: it won't work for old formats. they'll just upload normally.
<wgrant> jml: So it speaks bzr over sftp somehow?
<wgrant> I thought pushing over sftp was just copying things with sftp.
<jml> not really.
<wgrant> Well, at least it didn't use anything bzr-specific.
<jml> Bazaar delegates to format objects, which do file operations more intelligently than dumb copying.
<jml> here, the new format checks the remote configuration file.
<lifeless> wgrant: lp synthesises a file at the project/ path in the sftp tree
<lifeless> wgrant: bzr reads that file
 * jml has a mental picture of himself standing at a keyboard wearing a devo hat.
<wgrant> lifeless: Ahh.
<wgrant> lifeless: That explains it - I wondered how bzr could get information from LP from an empty directory.
<LaserJock> wgrant: LP is full of "magic" :-)
<jml> we try to keep it to a minimum.
<jml> (alternatively, "You think that's files you're reading?")
<abentley> poolie: Thanks for setting up bzr-core.  I have gotten herb to zap bazaar-overall
<poolie> i saw, thanks
<poolie> spiv, so I was wondering about TestBranchSetLastRevisionInfo.test_unexpected_error
<poolie> but maybe i understand more now
<poolie> spiv, could it be that the comment at the top of that test is wrong?
<poolie>         # A response of 'NoSuchRevision' is translated into an exception.
<poolie> actually it's testing when we get a random unexpected error
<LaserJock> ok, so pushing the same branch (now upgraded) took 16 min
<LaserJock> so a total turn-around for branch-push of 163 minutes
<jml> :(
<poolie> !!
<mwh> well, the time to upload is ok i guess...
<LaserJock> and so now I dont' have any time to hack on it
<mwh> er
<mwh> well
<mwh> better
<LaserJock> wgrant: are you gonna time a branch from mine?
<jml> also, if you could do -Dhpss, that would be great.
<LaserJock> mwh: I might have been limited by my upload bandwidth
<LaserJock> holy cow, wgrant got my branch in 2.5 min
<wgrant> And I'm in .au. Not too bad.
<LaserJock> hmm, 147 vs 2.5
<wgrant> Just a tad faster.
<wgrant> I think knits need to die.
<poolie> wgrant: well, you should get a warning about them with the current code
<poolie> either 1.6 or 1.7?
<spiv> poolie: yeah, the comment does seem to be a copy & paste mistake.
<mwh> i think the version of bar running on the server is _particularly_ bad with knits
<wgrant> (oh, and this is with Hardy's bzr over HTTP, so it's probably rather slower than it should be)
<mwh> wgrant: oh
<wgrant> I was using Intrepid's bzr of bzr+ssh to get the knit branch, IIRC. But that machine doesn't have direct Internet access now, so I'm doing it on another box.
<wgrant> s/of/and/
<mwh> well, for the initial branch, bzr+ssh probably doesn't beat http by much
<wgrant> Ah.
<jml> if at all.
<wgrant> How much faster should bzr 1.6 be than 1.3.1?
<mwh> (there's limited opportunity for cleverness after all, it's a "get all this data from here to there" operation)
<wgrant> Probably not much, I guess.
<jml> also, encryption :)
<mwh> wgrant: for bzr+ssh, "a bit"
<mwh> wgrant: for http, not much at all i expect
<poolie> initial push is pretty close to the underlying bandwidth for packs
<poolie> about 90%
<LaserJock> yeah, I was at my bandwidth max when pushing 40KB/s
 * jml goes to get coffee
<LaserJock> but when branching I was only using ~ 2KB/s
<poolie> spiv, i'm not so sure the distinction between ErrorFromSmartServer and Unexpected& is really worthwhile...
<poolie> i mean if you get the former and it's not matched, surely it's unexpected?
<poolie> anyhow i've resolved the merge for 1.7
<spiv> poolie: if an ErrorFromSmartServer escapes from a Remote* object, that's a bug in the client -- it means the error translation isn't being invoked.
<spiv> Whereas Unexpected& is "the client tried to translate and couldn't, so it appears the server is talking nonsense".
<poolie> mm
<poolie> ok
<poolie> jml, spiv, jam, the integrated fix for 261315 is now submitted to pqm for 1.7
<spiv> Hooray!
<poolie> i'm going to take a break then look at
<poolie> um, that keyerror thing
<poolie> spiv, i want to use the updated wiki roadmap page in my meeting tomorrow night
<poolie> i'll work with you on it later or tomorrow if you want
<poolie> oh foo, i guess it clashes with fpsyd
<abadger1999> Thanks a bunch guys!  transifex will have a working bzr submission backend courtesy of your help.
<vila> hi all
<poolie> hello vila
<poolie> how's things
<vila> fine, many mails to write today :)
<poolie> oh, what kind of thing?
<vila> oh, summaries for python-2.6 compatibility, the ones I mentioned the last time, november meeting, etc
<vila> I will try to clear my mailbox a bit more today :D
<lifeless> mwh: are there docs on the generator protocol for C extensions?
<spiv> lifeless: 'generator protocol'?  AIUI, it's just the iterator protocol.  Are you asking about creating generators or something?
<lifeless> spiv: pyrex doesn't support yield
<lifeless> spiv: I'm looking at how to make a pyrex module behave like its yielding with the least possible overhead
<spiv> The yield keyword is just a convenient (and efficient) way to build an iterator.
<lifeless> I just had to restrain myself from sarcasm
<poolie> wonders never cease :)
<spiv> So if I'm understanding you correctly, the answer to your problem is "write an object that conforms to the iterator protocol".  I feel like I'm missing something?
<lifeless> spiv: we need tp_iternext in the C object set to the next in the C level code, for instance
<spiv> Right.  It sounds like you understand the C end of things just fine, so I'm not sure what you're asking about.  :)
<spiv> Or maybe it's how to do it in Pyrex that's the issue?
<lifeless> spiv: indeed
<spiv> Ah, ok.
<lifeless> spiv: and with lowest overhead I can achieve :P
<spiv> I think Pyrex lets you define __next__ on your class.
<spiv> (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/special_methods.html mentions it)
<lifeless> yes, just been reading that :P
<lifeless> thanks
<spiv> Oh well, that exhausts my expertise on the topic, so I'll shut up now :)
<lifeless> john did an iterator for win32
<lifeless> so there is stuff to cargo cult
<lifeless> but I was hoping to know more about e.g. marshalling and reentry overhead etc
<spiv> Take a peek at the C translation I guess.
<spiv> I can make some guesses, but that's probably not very helpful :)
<thumper> please can we have bzrtools in the bzr ppa?
<speakman> hi folks! :)
<speakman> how is --fixes supposed to work?
<speakman> I'm using Trac, and even if it doesn't work with Trac for the moment, I'd like to use it anyway in case it will be supported later on.
<speakman> but "bzr commit -m "message" --fixes 30" results in a "bzr: ERROR: Invalid bug 30. Must be in the form of 'tag:id'. Commit refused."
<RAOF> speakman: --fixes=$BUGID.  So, for launchpad, I pass --fixes=lp:12345
<ubottu> Launchpad bug 30 in malone "comments on bugs require subjects" [Medium,Fix released] https://launchpad.net/bugs/30
 * spiv knocks another 10s off pushing 1 new rev to a bzr.dev branch.  (Now down to 51s over 500ms latency link, down from 73s with 1.4)
<speakman> RAOF: I see. How can I use it in my local repo? Or even with trac if it's supported nowadays?
<spiv> speakman: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#bug-tracker-settings
<spiv> speakman: note that all --fixes does is set a property in that revision.  It's then up to your Trac/Bugzilla/whatever instance to interpret that property.
<speakman> spiv: ok, I'd just like it to be set in the changeset, no matter if it's interpreted or used. :)
<spiv> Cool.
<speakman> regarding the docs; am I supposed to edit the .bzr/branch/branch.conf by hand?
<spiv> I think so, although it's not something you'd need to do very often.
<spiv> I can't remember the last time I edited one, if ever.
 * jml can
<jml> but I was trying to break stuff :)
<lifeless> spiv: great news
<lifeless> spiv: I know I'd love to hear about such things on-list too :>
<spiv> lifeless: and it's only a bit of a hack, too ;)
<speakman> reading the doc twice I found setting trac-url into ~/.bazaar/bazaar.conf works great too :)
<poolie> actually
<poolie> jml, re bug 270738
<ubottu> Launchpad bug 270738 in bzr "AttributeError when branching stacked branches" [Critical,New] https://launchpad.net/bugs/270738
<speakman> Now my latest changeset is commited with --fixes project:bugno, but I can't even see it with "bzr log -r -1 -v". Isn't it supposed to show up?
<jml> poolie: yes.
<poolie> the attribute error is obviously just hiding something else
<poolie> assuming that it's not already fixed in the branch
<bob2> speakman: afaik it is only shown by 'bzr viz'
<poolie> could you make a trivial change like say changing the last parameter to repr(self) or ""
<poolie> and tell me what happens then
<poolie> because i cannot reproduce it at present
<jml> poolie: sure. gimme a second to finish off this thought.
<jml> poolie: actually, do you have an updated non-conflicting version of your bundle?
<LarstiQ> moin
 * jml becomes curious as to how zope orders its layers
<jml> LarstiQ: hello.
<LarstiQ> jml: hello :)
<spiv> speakman: https://bugs.edge.launchpad.net/bzr/+bug/251729
<ubottu> Launchpad bug 251729 in bzr "It would be nice to have bugs informations in logs" [Wishlist,Confirmed]
<poolie> jml, i sent it in to pqm
<poolie> if you pull bzr.1.7 you'll get it
<jml> poolie: ahh ok.
<poolie> or http://sourcefrog.net/bzr/261315-into-1.7
<jml> pqm is empty, so I'll try pulling now.
<jml> while my machine thrashes for these tests
<jml> poolie: did you try to reproduce with the same branch?
<jml> poolie: I get that same error with bzr.dev
<jml> I'll update to use repr
<jml> poolie: I wonder why you can't reproduce the bug.
<jml> poolie:
<jml> $ bzr branch bzr+ssh://localhost/tmp/e g
<jml> bzr: ERROR: Revision {set([('Arch-1:walters@verbum.org--2003%tla-pqm--mainline--0.1--patch-10',), ('Arch-1:walters@verbum.org--2003%arch-pqm--main--0--base-0',), ('Arch-1:walters@verbum.org--2003%tla-pqm--mainline--0.1--patch-1',), ('Arch-1:walters@verbum.org--2003%tla-pqm--mainline--0.2--base-0',), ('Arch-1:robert.collins@canonical.com--general%arch-pqm--main--0--base-0',), ('Arch-1:robert.collins@canonical.com--general%arch-pqm--main--0--patch-1',), ('A
<jml> rch-1:walters@verbum.org--2003%tla-pqm--mainline--0.3--base-0',)])} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()), <bzrlib.knit._DirectPackAccess object at 0x882194c>)".
<jml> poolie: feel free to call me on my mobile if you want to talk more, I'm off.
<poolie> thanks very much
<matkor> Hi !
<matkor> How can I resolve such strange to me confilcts: Conflict adding file semantics_cserver.py.BASE.  Moved existing file to semantics_cserver.py.BASE.moved.
<matkor> I do not remember adding semantics_cserver.py.BASE
<matkor> I have valid content in semantics_cserver.py
<matkor> which I would like to commit
<LarstiQ> matkor: that sounds like a second round of conflicts on top of the existing one
<LarstiQ> matkor: when do you get this conflict?
<matkor> LarstiQ: I worked over checkout ..
<matkor> did unbind , commited some changes and bind later
<matkor> result was pretty surprising to me
<matkor> anyway how can I force resolve it ?
<matkor> bzr resolved semantics_cserver.py does not help with that ...
<LarstiQ> matkor: use status and diff to find out where you are, and resolve to resolve conflicts
<LarstiQ> matkor: no, the message says your conflict is on semantics_cserver.py.BASE, not semantics_cserver.py
<matkor> LarstiQ: Yes , I am not interested in semantics_cserver.py.* - I have valid (merged) content in semantics_cserver.py
<matkor> I just want to commit it
<matkor> LarstiQ: If confilict is
<matkor> bzr revert semantics_cserver.py.BASE
<matkor> bzr: ERROR: Path(s) are not versioned: semantics_cserver.py.BASE
<LarstiQ> matkor: could you pastebin `bzr status` output please?
<matkor> LarstiQ: sure , but pastebin.org seems to be dead for me, here it is http://wklej.org/id/4724/
<matkor> bzr 1.5
 * LarstiQ doesn't care _which_ pastebin it is :)
<LarstiQ> matkor: so, `bzr resolve semantics_cserver.py` doesn't remove those .BASE conflicts, what does `bzr resolve semantics_cserver.py.BASE` do?
<matkor> LarstiQ: Oh, it removes from conflicting files ! Thank you very much !
<LarstiQ> matkor: no problem :) If you can give a recipe for how to reproduce this situation, that might be nice.
<matkor> LarstiQ: I doubt it. I did several post unbind/bind merges and it worked great as for now ...
<LarstiQ> matkor: any reason you're not using commit --local; update instead of unbinding/rebinding?
<matkor> LarstiQ: Propably only my ignorance about commit --local ...  Reading now how it works.
<imyojimbo> can some1 please explain to me the idea of --no-trees repository, i didnt get it
<AfC> imyojimbo: Branches created in it won't have Working Trees present. Gives you a way of storing lots of branches without taking up lots of space. It's just a variation.
<matkor> LarstiQ: Yeah bzr commit --local is doing exactly what I wanted by doing bzr unbind commit bind cycle. Thank  you very much again !
<LarstiQ> matkor: np :)
<jml> jamesh: actually using testresources?
<vxnick> Hi all - got a bit of a strange one here, hoping you can help
<vxnick> Do you know how I can embed the revision number within a PHP file? Presumably, this would need to be done as part of a post-commit hook?
<AfC> vxnick: have a look through the mailing list archive. There was recently some discussion of ids or version strings or something like that. Not sure if they were talking about a plugin or a hook or what.
<vxnick> AfC: thanks - I'll take a look
<LarstiQ> vxnick: how about `bzr version-info`?
<vxnick> LarstiQ: that's what I thought it'd be - I found the thread in the mailing lists :-)
<vxnick> I wasn't sure how I would hook this in though, as I'm not a Python dev
<LarstiQ> vxnick: a good place is in your build or deployment process
<vxnick> LarstiQ: I assume a hook would do this well then? I'm using PHP, so there's no build process as such
<LarstiQ> vxnick: imo, doing it every commit is often not what you need, but yes, you could do that if you really wanted
<LarstiQ> vxnick: no deployment proces either?
<vxnick> LarstiQ: What I'm basically trying to do is add the revno into something like "version.php", so I can call it within the application
<LarstiQ> vxnick: let me try to phrase the question differently. What do you plan to use that version for?
<LarstiQ> vxnick: right
<LarstiQ> vxnick: so, when you're developing locally, it isn't important to have that information?
<vxnick> LarstiQ: I'm comfortable with the process of doing it, but I'm just not familiar enough with Python to actually do it
<LarstiQ> vxnick: there isn't much python to `bzr version-info`
<vxnick> LarstiQ: True, but I don't know any Python whatsoever :)
<LarstiQ> vxnick: ok, there isn't _any_ python to it ;P
<LarstiQ> vxnick: if the default output isn't usably, you can supply a template
<awilkins> markh: Is building the .exe version hard?
<LarstiQ> vxnick: see `bzr help version-info`
<awilkins> markh: I'm building the python-installer version but I'd quite like to try my users on TBZR
<vxnick> LarstiQ: that's fine, but what I want to do is put that (or `bzr revno`) within a Python hook which is then called upon every commit, etc
<awilkins> markh: Does it preclude you using any plugins, etc?
<vxnick> LarstiQ: would it be wise to use `bzr ignore` on the version file, so it doesn't artificially bump up the revno every time bzr notices it's been changed?
<LarstiQ> vxnick: is this a webapp?
<vxnick> LarstiQ: it could be any sort of app
<LarstiQ> vxnick: ok
<vxnick> LarstiQ:  although, for completeness, yes
<LarstiQ> vxnick: for any sort of app, I would only run version-info when you make a tarball to ship to your users
<LarstiQ> vxnick: for a webapp, I would call it only when you deploy it at your server
<vxnick> LarstiQ: makes sense, thanks. What about for something that's ongoing?
<vxnick> LarstiQ: in the sense that it doesn't get tarred up, but rather commited to a production branch, etc
<LarstiQ> vxnick: ok, so your deployment process is just committing?
<vxnick> LarstiQ: basically yes
<LarstiQ> vxnick: maybe you'd be better off with keyword expansion
 * LarstiQ sighs
<LarstiQ> vxnick: Basically, I think it's a bad idea.
<LarstiQ> vxnick: but let me see if I can cook it up
<spiv> vxnick: How does committing to the branch cause the new version of your webapp to be deployed?
<vxnick> LarstiQ: keyword expansion would be good enough if that's do-able
<vxnick> spiv: sorry, I'm pretty new to all this so I might be wrong
<vxnick> LarstiQ: I think I looked into keyword expansion a while ago but discounted it for one reason or another
<LarstiQ> vxnick: my advice would be to have a discrete deployment step
<vxnick> LarstiQ: what would you suggest?
<vxnick> spiv: sorry, I think I was using something like `bzr rsync` or similar to push commits to a web area
<spiv> vxnick: so that's the point where you could be running bzr version-info (or whatever) to put the revision info in a php file.
<vxnick> spiv: surely that'd be a hook then?
<LarstiQ> vxnick: something like `bzr export path/to/production; bzr version-info --custom --template "version = {revno}" > path/to/production/version.php`
<vxnick> LarstiQ: thanks
<LarstiQ> and probably something more appropriate than export
<LarstiQ> but that really depends on the rest of your infrastructure
<vxnick> yep
<vxnick> LarstiQ: do you think it's still feasible to update this version file as and when commits happen, as I've (kinda) been discussing with spiv?
<LarstiQ> vxnick: doing the same as cm_version_info is a little bit more involved than trivial
<spiv> vxnick: Just having a script that does "bzr version-info ... ; rsync" seems simplest to me.
<LarstiQ> (in a hook)
<LarstiQ> vxnick: it is possible, I just think it's useless
<vxnick> LarstiQ: many thanks
<spiv> vxnick: I don't know of a plugin that provides a 'bzr rsync' command, but there is a 'bzr rspush' in bzrtools I think.  You could write a plugin that hooks that.
<vxnick> spiv:  many thanks also
<LarstiQ> vxnick: but more work than a 5 minute hack for me I'm afraid
<vxnick> guys - I think I'll just script it then and use that as my staging step
<LarstiQ> vxnick: however, it sounds like it might be worthwhile addition to the bzr-upload plugin
<spiv> vxnick: you're welcome
<spiv> LarstiQ: that's true
<vxnick> LarstiQ: that's what I'm using - sorry, forgot what it was called!
<LarstiQ> doh :)
<vxnick> LarstiQ: when I was referring to `bzr rsync`
<LarstiQ> vxnick: that's excellent then :)
<vxnick> thanks a lot for your help guys, much appreciated!
<LarstiQ> vxnick: thank me when it actually works for you
<vxnick> LarstiQ: fair enough ;)
 * LarstiQ files a request on bzr-upload
<vxnick> :)
<vxnick> LarstiQ: could you link me to the request once done, so I can stay in the loop
<LarstiQ> vxnick: sure
<LarstiQ> vxnick: nothing complex, but bug 271316
<ubottu> Launchpad bug 271316 in bzr-upload "feature-request: optionally produce a versin-info like file" [Undecided,New] https://launchpad.net/bugs/271316
<vxnick> LarstiQ: sorry, one more thing - would it be worth ignoring the version.php file, or keeping it revisioned?
<vxnick> LarstiQ: cheers :)
<LarstiQ> vxnick: with the bzr-upload approach, you would never have the version.php in your working tree, only in the production area, so you wouldn't have to ignore it.
<vxnick> LarstiQ: gotcha
<LarstiQ> vxnick: if you were to produce a version file on every commit, I'd ignore it
<vxnick> LarstiQ: understood, thanks!
<Leonidas> when I have a path and it is a directory, and a revision tree, how can I get the contents? Do I have to filter the inventory?
<LarstiQ> Leonidas: something like bzr.dev export does?
<Leonidas> LarstiQ: I am currently doing inventory.iter_entries() and filtering out InventoryDirectories + checking thether the path.startswith the director that I want to check.
<Leonidas> s/director/directory/
<LarstiQ> Leonidas: bzrlib.export._export_iter_entries does: 'subdir_id = inv.path2id(subdir); entries = inv.iter_entries(subdir_id)'
<Leonidas> I'm looking for something like inventory.get_path_subitems('mydirectory/myotherdirectory/') or something like this.
<Leonidas> LarstiQ: looks good, I'll try it after lunch, thanks!
<awilkins> Verterok: Ignore that patch until I can make it pass tests  ;)
<speakman> will bzr-trac support --fixes soon?
<LarstiQ> does bzr-trac still exist?
<speakman> hopefully it does :)
<speakman> latest commit 2008-08-31
<LarstiQ> okay :)
<LarstiQ> speakman: I'd take it up with whomever is working on it then.
<speakman> I think they're inhere. Afaik the project doesn't have it's own irc chan.
<LarstiQ> speakman: there seem to be multiple projects doing bzr-trac integration, which one did you mean?
<speakman> https://launchpad.net/trac-bzr - where do you find more?
<LarstiQ> https://launchpad.net/bzr-trac is one
<LarstiQ> speakman: I'd probably ask a question on that project then
<LarstiQ> but it is surprising to me it doesn't already work
<LarstiQ> speakman: https://bugs.edge.launchpad.net/trac-bzr/+bug/120470
<ubottu> Launchpad bug 120470 in trac-bzr "Support for bug-fixed metadata" [Wishlist,Triaged]
<speakman> thanks. can I push for a certain wish on launchpad?
<LarstiQ> speakman: add a comment to that bug asking for that status :)
<LarstiQ> speakman: and well, if you add a patch that implements the feature, that should bump it up ;)
<speakman> if I was skilled enough I would ;)
<VSpike> Got a situation where even after a commit bzr st shows a change.  But when I try to commit again, it says there are no changes to commit
<VSpike> Change is a directory being removed
<VSpike> What can I do?  Or should I just ignore it and hope it goes away?
<grutte_pier> depends on the change that bzr st shows
<VSpike> grutte_pier: it shows "removed: images/Devices/"
<VSpike> grutte_pier: that has persisted through the last couple of commits
<VSpike> right now it's the only change in the list
<bob2> have you only been doing selective commits?
<VSpike> no
<grutte_pier> vspike: I'm trying to reproduce your situation, but maybe you have been deleting stuff using system rm instead of bzr rm?
<fullermd> I always delete stuff with system rm, and I've never seen that happen.
<grutte_pier> actually... I notice now as well that bzr seems smart enough to delete files that are not present anymore from the branch as well
<grutte_pier> that's nice! I don't think other VCS can do that
<uws> VSpike: What happens if you try "bzr commit images/Devices" ?
<VSpike> It's windows, which may be an issue.  I renamed the directory from "Devices" to "devices". I then did "bzr move --after images/Devices images/devices"
<fullermd> That sounds like a source of trouble...
<fullermd> I'd move it back, then bzr mv it.
<grutte_pier> and if that works, file a bug, because it _should_ work according to the help I guess :P
<LarstiQ> it should
<LarstiQ> VSpike: which version of bzr?
<grutte_pier> but how is windows with case?
<bob2> useless
<bob2> preserving but not distinguishing
<VSpike> yeah, i can imagine case could be a windows specific issue.  Sometimes it matters, sometimes it doesnt
<grutte_pier> right.... so maybe Devices and devices look like the very same dir to begin with?? causing bzr commit to state that no changes have to be committed?
<grutte_pier> and maybe bzr st Does see this, because it is slightly different implemented?
<VSpike> how can i query the detailed history of a file?
 * grutte_pier is just guessing
<grutte_pier> vspike: i guess bzr branch-history should work (from the bzrtools plugin)
<LarstiQ> VSpike: bzr log <file>
<gour> hi, i've to work on some web sites all based on same codebase (cms made simple). does it make sense to use one shared repo with branches representing different sites and/or different states like production/test etc. ?
<VSpike> Sorry, just trying to figure out how to install bzrtools on cygwin :)
<awilkins> Verterok: ping?
<grutte_pier> gour: i guess that's precisely what vcs is supposed to do......
<LarstiQ> gour: yes
<grutte_pier> vspike: bzr log probably does what you actually want (I forgot the most obvious :P )
<gour> thanks.
<VSpike> grutte_pier: any idea where that hides in windows? :)
<VSpike> (Not cygwin - I've just switched from windows version to cygwin, but those commits were made under windows)
<VSpike> Just doing "bzr diff images/ -r 54..55" which is the relevant commit shows this http://pastebin.com/m7d771fe3
<VSpike> so it added the directory with the new name (images/devices) and renamed each file in the old directory (/images/Devices/) to the new location, but did nothing with the old directory itself
<VSpike> So I can see why it's reporting it as removed
<VSpike> What is strange is why commit won't commit it, and I guess that is probably to do with case
<Verterok> awilkins: pong
<pysquared> Hi, I'm evaluating bazaar for use in our company, and like it a lot.  However I cannot figure out how to combine 2 branches that have no common ancestor.  Anyone help please?
<awilkins> Verterok: Hi there, I'm trying to get the tip of bzr-eclipse working on Callisto by merging my previous "remove the non-callisto bits" patch
<awilkins> Verterok: What's the dependency on org.eclipse.core.expressions 3.2.100 ?
<Verterok> awilkins: hi!
<Verterok> let me check
<Verterok> I think, that nothing depends on expresions :)
<awilkins> Verterok: I've fixed a bunch of windows-specific issues in the client library (I made all the status methods return forward-slashes regardless of platform because that's what the CLI client does)
<awilkins> Verterok: I can't get it to start and the preferences page is unavailable
<pysquared> The only thing that "works" so far is to create an empty branch to be used as the basis for all new branches I ever create, which then allows for possible future merging.
<Verterok> awilkins: great, patches are more than welcome. :)
<pysquared> I come from CVS, so I guess the confusion is natural
<awilkins> Verterok: I think it still has issues when the default implementation of "bzr" is not "bzr" on the PATH
<Verterok> awilkins: I 've been working on the client also, adding support for pending merges in the status and some enhancements in the xmlrpc client interface
<Verterok> awilkins: what do you mean with 'bzr is not bzr'? :)
<awilkins> Verterok: On windows, my default implementation is "c:\python25\scripts\bzr.bat"
<jelmer> pysquared, hi
<jelmer> pysquared: You can merge one into the other by using something like "bzr merge -r1..-1 <other>"
<jelmer> pysquared, or if one should be a subdir of the other, you can use "bzr join"
<LarstiQ> -r0..-1 that is
<awilkins> Verterok: I think at some point bzr-eclipse became unable to configure itself unless it can find bzr... which it can't
<Verterok> awilkins: ah, I get it. I fixed some issues with bzr.bat a few weeks ago. (when the path to bzr.bat contains spaces)
<jelmer> ah, right - thanks, LarstiQ
<LarstiQ> pysquared: but merging branches that have no common ancestor is a very unusual thing to do
<LarstiQ> pysquared: so if you find yourself doing that a lot, I'd take a step back and look at your workflow
<awilkins> Verterok: I think I've got that ; I'm running off tip of trunk with a small anti-europa patch
<Verterok> awilkins: at the preference page, bzr-eclipse needs bzr to test if the xmlrpc service can be run, and if xmloutput is installed, etc
<pysquared> Thanks, will check out "join" now.
<Verterok> awilkins: do you have a stacktrace?
<awilkins> Verterok: Those things pass when running the library
<awilkins> Verterok: Alas, no, it just fails
<pysquared> I have a CVS repo with a tree of various sized projects in, some dependent on others.  I was wondering if I could start small, and bazaarify a subtree at a time, and then combine them later.
<awilkins> Verterok: I saw the pretty new menu once, then it spewed the "requiremnts update" dialog once, as well as the "this operation is not enabled" and the menu is greyed now
<Verterok> awilkins: the dependecy update popup use the IWorkbenchBrowserSupport
<Verterok> awilkins: maybe in callisto is different to show a browser?
<awilkins> Verterok: Aha, it is trying "bzr" and not working, I just got a stack dump in another plugin
<awilkins> http://pastebin.ubuntu.com/47792/
<Verterok> awilkins: the  "revision-info" patch is the one I should ignore?
<LarstiQ> pysquared: random subtrees don't work very well as branch units, but distinct projects are a very good choice for that
<awilkins> Verterok: You may as well, It's included in the second one
<awilkins> I think
<VSpike> damn.. even bzr commit --unchanged doesn't fix it :/
<Verterok> awilkins: ok, I'm looking the second one ATM
<LarstiQ> VSpike: can you move the directory back to what it was?
<awilkins> Verterok: No prefs page in the Team prefs for Bazaar
<Verterok> awilkins: hmm, it seems that it can't find the bzr file in Scripts/bzr
<VSpike> LarstiQ: what about the files in it?
<LarstiQ> VSpike: just move the entire dir
<VSpike> LarstiQ: with bzr mv or just mv?
<LarstiQ> VSpike: just mv
<LarstiQ> VSpike: this is exploratory in nature, not a fix yet
<awilkins> Verterok: I thought this was to do with the difference between the length of the list of args
<pysquared> Well, I got this to work: banana$ bzr merge -r0..-1 ../apple  (thanks jelmer)
<VSpike> LarstiQ: http://pastebin.com/mcb8e143
 * LarstiQ blinks
<grutte_pier> vspike: I'm getting confused a bit
<LarstiQ> VSpike: and what does bzr st show if you move Devices to devices again?
<LarstiQ> VSpike: this is not the output I'd expect with what you just told us
<grutte_pier> vspike: I don't manage to reproduce your situation
<Verterok> awilkins: it would be great to have the value of cmdLine
<jelmer> pysquared: you're welcome
<VSpike> http://pastebin.com/d4fb79800
<grutte_pier> well, that pastebin makes sense
<grutte_pier> because you didn't yet do the bzr mv --after in that one
<awilkins> Verterok: I'm just trapping it ; it's probably to do with cmdLine having 1 more element on windows using the batch file
<awilkins> Verterok: cmdLine is "bzr","xmlversion", "--short"
<Verterok> awilkins: mmm, that's bad
<Verterok> awilkins: that's the default value
<awilkins> Verterok: This is the default config ; problem is, if it doesn't survive this first check, it doesn't work
<LarstiQ> VSpike: this is rather weird
<grutte_pier> vspike: but if i try to do something similar on some test-stuff, I also get a: unknown: image/device
<awilkins> Verterok: Let me hop through and see if it's called again
<Verterok> awilkins: I'll try to replicate the config and debug it
<awilkins> Verterok: That's interesting, it's getting called from an SVN provider
<grutte_pier> vspike: did you by any change add the image/devices dir with bzr add, before you did the sysm mv command?
<VSpike> grutte_pier: yes, I would think so - it won't let you do the move otherwise
<VSpike> Oh.. system move
<VSpike> Nope
<VSpike> Looking back at logs, I think the sequence was: create new dir, system mv files from old dir to new, bzr add --no-recurse <new dir>, bzr mv --after each file <oldpath> <newpath>
<LarstiQ> VSpike: ah
<LarstiQ> VSpike: I'm not sure how well it would deal with that
<VSpike> So i did bzr mv --after for each file in the directory, and I bzr add'ed the new dir, but didnt remove the old one
<Verterok> awilkins: hmm, that's weird
<VSpike> LarstiQ: I don't think I've had problems with that when the names differ by more than case
<LarstiQ> grutte_pier: mind trying to reproduce it that way? Ie, version files in old, commit, mkdir new, mv old/* new/*; bring files under version control in new, and then bzr mv --after old new
<Verterok> awilkins: about the ..core.expresion dependency, it's used in the refresh command hook: RefreshExecutionListener
<VSpike> LarstiQ: it's something I do quite often - move files around, then try and tell bzr about it after the fact
<LarstiQ> VSpike: could be, I don't know what the code does atm, but I can see it having two sets of fileids it needs to resolve
<LarstiQ> VSpike: right, just system mv and bzr mv --after, or also bzr add before the after?
<VSpike> LarstiQ: have to bzr add, otherwise it bitches at you that the target is not versioned
<awilkins> Verterok: Is there a reason why the version is at 3.2.100 ; I can't find a package that has that version in the Callisto updates but the version number looks callisto-ish
<LarstiQ> VSpike: ok
<VSpike> LarstiQ: hence the --no-recurse (which I recently discovered) otherwise it adds all the files too in the new location, and you have to then bzr remove each one before you can do the bzr mv
<grutte_pier> vspike: it's on win right? On linux mv old/* new/* is not allowed :P
<grutte_pier> vspike: mv old new is allowed, but that places the old as a subdir in new
<Verterok> awilkins: there is no reason, it's just the version available in 3.4
<VSpike> grutte_pier: I did it with a gui tool :)
<BasicOSX> Would be nice if there was a section on the bzr web page with template for tailor configuration for converting other RCS repos to bzr repos
<LarstiQ> VSpike: doh, I overlooked the --no-recurse. Yeah, that is exactly what I had in mind.
<grutte_pier> vspike: i think i need to cp instead of mv :P
<LarstiQ> BasicOSX: well, tailor isn't exactly the most recommended solution
<BasicOSX> LarstiQ:  oh? What is recommend for darcs to bzr?
<LarstiQ> BasicOSX: ok, specifically for darcs tailor is :)
<BasicOSX> heh :-)
<LarstiQ> unless there is darcs-fastexport now?
<Verterok> awilkins: starting in a fresh workspace seems to work in *nix (actually OS X)
<Verterok> awilkins: I'll start a VM in my Linux box try this on windows
<awilkins> Verterok: not here ; I shall apply my (evil) patch and see if this fixes it
<awilkins> Verterok: In a dead HEAD I have a patch that patches the preference initializer to use a valid path on Windows
<BasicOSX> LarstiQ:  looks to be a fastimport
<awilkins> Verterok: Ok, if you cheat and use a valid path it works fine
<Verterok> awilkins: mm, ok. bzr is not a valid path in windows? :)
<awilkins> Verterok: Try patching org.vcs.bazaar.eclipse.PreferenceInitializer to use a bad name like "bzr_chicken" and see it it works on *nix
<awilkins> Verterok: Windows doesn't read #! and work out what to pass a file to
<grutte_pier> vspike,larstiq: I can't reproduce it that way; the olddir is placed as subdir in newdir
 * Verterok try that 
<awilkins> Verterok: I'm not even sure that you can use ProcessBuilder.start() without an absolute path
<jam> vila: poke with a soft stick
<awilkins> Verterok: You should at least be able to access the prefs page to set it up properly, but I think it's a chicken and egg scenario ; can't set up a valid config without a valid config
<vila> jam: ponk ?
<jam> good afternoon :)
<vila> hi ! :D
<LarstiQ> grutte_pier: mv old/* new/ ?
<Verterok> awilkins: ok. so we need to check if the config invalid, and show the pref page anyway
<jam> I just wanted to verify
<VSpike> I can reproduce it
<jam> bug #233817 is bzr-1.8 not 1.7, right?
<VSpike> It is dependant on case
<ubottu> Launchpad bug 233817 in bzr "missing doesn't show merged revisions" [High,Fix released] https://launchpad.net/bugs/233817
<vila> jam: checking
<grutte_pier> vspike,larstiq: I do remember that windows way of moving is quite different than *nix... since I'm on the latter
 * LarstiQ nods
<LarstiQ> grutte_pier: I'm on *nix myself
<grutte_pier> vspike: but how many commits did you do after rev 54? What if you revert to the latter? and then use proper bzr commands do move the files around??
<awilkins> Verterok: I have to catch a train now, but I'll touch bases with you later.
<grutte_pier> larstiq,vspike: so i set up a Device-dir with two files, which was commited to the branch, then created a device dir, --no-recurse added the thing and moved Device/* to device
<VSpike> grutte_pier, LarstiQ : http://pastebin.com/m1d98a78e
<grutte_pier> larstiq,vspike: at this time bzr st says: removed: Device/file1 Device/file2 unknown: device/file1 device/file2
<grutte_pier> aah, let's check that pastebin first :P
<VSpike> it works under linux: http://pastebin.com/m12a59bda
<VSpike> Just seems like a Windows issue with case of file names
<VSpike> (possibly insert "yet another" in there somewhere)
<VSpike> It may make a difference, but the windows version is 1.5
<VSpike> Using a newer version after the fact doesn't seem to change anything
<VSpike> Let me try in Cygwin with 1.61
<grutte_pier> vspike: I have indeed just repeated all your steps, but the last bzr st gives just nothing
<grutte_pier> vspike: what's weird though, is that I also get an explicit warning 'missing old' on the second commit
<VSpike> grutte_pier: on linux or windows?
<grutte_pier> linux
<VSpike> grutte_pier: on linux with the latest version, the last bzr st gives me nothing too
<grutte_pier> vspike: there is another difference: i get: 'deleted old' in the output of the second ci
<grutte_pier> vspike: you don't have that, so the ci doesn't remove the old/ dir
<LarstiQ> VSpike: I'll boot up my windows laptop after I get back from training
<VSpike> grutte_pier: did you see my second pastebin?  http://pastebin.com/m12a59bda
 * LarstiQ is afk for a while
<VSpike> grutte_pier: I get the same as you.. it shows "deleted old"
<VSpike> on linux that is
<grutte_pier> i get more and more convinced that this indeed some strange case-problem
<VSpike> Agreed
<grutte_pier> vspike: to me it seems a very academic situation though.... why not move the whole dir at once instead of moving first the dir and then seperately moving the files?
<grutte_pier> wait.... without the 'not' :P
<fullermd> Eh?  How can you move the dir then separately move the files?  Where are the files in the middle?   :p
<grutte_pier> aah, that's wrong choice of words......
<grutte_pier> why would you set up a new dir, which you add seperately to the branch, and then mv the files explicitly to that new dir
<grutte_pier> if you can also just bzr mv the whole thing at once......
<fullermd> Well, they're semantically different operations; it depends on which you want to do.  But usually, you'd want to move the dir...
<grutte_pier> well, I guess the thing in http://pastebin.com/m12a59bda is in the end just a move I would say??
<VSpike> grutte_pier: true, "bzr mv --after old Old" is permissible, does the right thing, and works as expected on windows
<VSpike> so yeah, I'd say it was a better way to do it
<VSpike> Still probably counts as a bug though :)
<grutte_pier> but still... during the commit, apparently bzr does not delete a dir(maybe file) on Win if there is another file that has the same name except case
<grutte_pier> that's still a bug I would say, yes
<fullermd> No, that's a move of a file into a different (new) directory, and removal of an old directory.  That's a different thing that keeping a file in the same directory, and moving the directory.
<fullermd> But anyway, I always think of move --after like a barbed-wire necklace   :p
<grutte_pier> same here.... outsjj
<VSpike> if you are working in a command line enviroment it would be more natural to use bzr mv, but my dev environment gives me a file-manager like tree of the project files, so the natural way to move things around is with that
<VSpike> Then you have to reconcile it with the source control afterwards
<VSpike> No-one would voluntarily use the windows command line if an alternative were available :)
<grutte_pier> yep..... time for TortoiseBzr?? :P
<grutte_pier> vspike: but have by now managed to repair the branch?
<grutte_pier> +you
 * grutte_pier is off to get some food
<VSpike> grutte_pier: yeah fixed it
<VSpike> thanks
<VSpike> had to go bzr mv it to tmp/ and commit, then bzr mv it to devices/ and commit
<grutte_pier> 'it' being the Devices/ dir?
<VSpike> If I want to check the latest windows version before filing a bug, should i try 1.7rc1 or 1.6.1?
<VSpike> grutte_pier: yep
<grutte_pier> vspike: 1.6.1 is the latest 'stable' version, but 1.7rc1 has even more bugs fixed.... but my suspicion is that this bug is not fixed in any, so I'd probably try the 1.7rc1
<VSpike> grutte_pier: thanks.. glad you said that, cos I just d/l and installed it:)
<imyojimbo> guys, i need your advice. im about to push my project to launchpad. Im developing using Visual Studio and im not sure what to do about the ide files vs put in my project files (some settings files). should i ignore them, or u think i should version them too?
<VSpike> imyojimbo: which files?  As a rule, you want it so that everything required to build your code is included.  Someone should be able to check out and build your project and end up with the same result that you did.
<VSpike> imyojimbo: i don't version .suo files, because they seem to be automatically regenerated if missing
<VSpike> imyojimbo: .csproj and .sln file I include
<imyojimbo> VSpike are u there?
<NfNitLoop> I'm doing `bzr branch http://host/svn/repo/trunk` and getting the error SubversionException "REPORT request failed on [the latest version]."
<NfNitLoop> Has anyone seen this before?
<NfNitLoop> trunk/ checks out fine via svn.
<NfNitLoop> and the changes in that rev are pretty minor.  (just a few lines in a file.)
<bpierre> hi
<NfNitLoop> h'lo.
<bpierre> LarstiQ: I've branched https://code.launchpad.net/~larstiq/bzr/nested-trees, how do I use it? I've created a shared repository with the development0-subtree format, and 2 branches inside, how do I nest one of the branch in the other?
<poolie> hello
<beuno> gooooooooooood morning poolie
<Spaz> afternoon
<lifeless> what where when, did I sleep through to the avo?!
<beuno> evening lifeless
<beuno> :)
<poolie> jam, hi
<lifeless> 43 tests to go
<poolie> to where?
<LeoNerd> Aren't these things traditionally on a wall, to be taken down and passed around one at a time?
<jam1> test
<Peng_> jam1: Hiya
<Peng_> Whatcha testing?
<jam> My nick :)
#bzr 2008-09-18
<poolie> spiv, call in a sec
<Necoro> hi there
<Necoro> anyone an idea: http://rafb.net/p/v6LWKW51.html
<Necoro> ?
<beuno> Necoro, Permission denied (publickey).
<beuno> it shouldn't be tracebacking
<beuno> spiv, ^
<beuno> Necoro, but, it's likely due to Launchpad being down
<Necoro> beuno: hmm - the web service is up and running ;)
<Necoro> but the traceback is strange though
<Necoro> AttributeError: 'ProtocolThreeDecoder' object has no attribute '_in_buffer'
<jml> Necoro: the codehosting service is not yet fully up.
<beuno> Necoro, the web service, but not the code hosting
<Necoro> ok
<Necoro> then I'll try again tomorrow morning ;)
<Necoro> or in a few hours - depending on how long I stay awake
<spiv> Necoro: that's a bug in -Dhpss
<spiv> Necoro: it's fixed in bzr.dev (and 1.7rc I think)
<Necoro> spiv: *g* - bugs in debug code pathes are always great :D
<lifeless> spiv: did you see my comment on that merge request?
<lifeless> down to 15 failures btw
<spiv> lifeless: yeah, I did
<spiv> lifeless: it's still flagged in my inbox as something to address
<lifeless> cool
<lifeless> 2.45 seconds now btw
<lifeless> I've seen hg as low as 2.37
<lifeless> so, without plugins, my bzr branch is faster :P
<spiv> When I land faster-startup (tomorrow hopefully) that'll get you another 30ms :)
<lifeless> btw, did you try my status branch out ?
<poolie> nice
<lifeless> ok, all tests pass
<lifeless> (all the intertree unit tests I mean)
<lifeless> still 2.45 seconds with everything passing, which is good
<lifeless> lots of fat in there still I think
<lifeless> breakfast now, test-parameterisation for this new extension after that, then people can pplay
<jml> when's next bzr rc cut due?
<jml> jam: ^^
<jdobrien> i f
<jdobrien> i know this isn't a bzr question but, i know there's a way of getting a line count from bzr diff by piping it through something else. but i can't remember how
<jml> jdobrien: bzr di | wc -l will get you a line count
<jdobrien> that's it! thanks!
<jml> jdobrien: but piping through 'diffstat' is also sometimes useful
<jdobrien> jml: thank you
<jdobrien> jml: diffstat, very nice
<lifeless> 2.42 seconds :P
<lifeless> btw
<lifeless> there is a faster status branch pushed to ...readdir
<lifeless> I'm tuning now, but its currently 1.4/3.84 seconds faster
<mwh> lifeless: does it mean a faster diff against wt too?
<lifeless> mwh: yes
<lifeless> mwh: diff is built on iter_changes
<mwh> right
 * mwh tries to think what else is
<mwh> merge, i guess?
<mwh> but that's between revision trees i suppose
<lifeless> merge does a local diff
<lifeless> so yes, merge on large trees should feel faster
<lifeless> mwh: how long does 'bzr st' take you today on lp?
<jml> ~540ms for me.
<AfC> Is bzr 1.7-rc1 something you want me testing? (alternative answers to "duh, yes" are "ooops, no, it's horridly broken don't touch" and "wait until 1.7rc2" and "no stick with 1.6.1 for day to day use" and "please test the $X which we want feedback on")
<lifeless> yah, you would see only a small improvement
<lifeless> AfC: rc testing feedback is always welcome; I don't know if there are specific improvements there that are relevant to you
<AfC> {shrug}
<AfC> Then I'll pull it in.
<lifeless> if 1.7c1 was horribly broken the IRC topic would likely say so
<AfC> Uh huh
<AfC> (I'm more getting at the tension between "it was just a snapshot on a given day" and "our dev tip is where it's at, but don't use that")
<lifeless> oh
<lifeless> well, I live ahead of tip myself; I think anyone that is interested can safely run tip - just need to track the rss feed for it to know what changes are occuring
<jml> AfC: use the tip of the bzr 1.7 branch if you want to test. It's got a couple of fixes that aren't in the rc.
<fullermd> I track tip, 'cuz it makes me feel special.
<AfC> fullermd: you *are* special. Don't let anyone tell you different.
<fullermd> That's what the counselors always told me, while they were smiling and backing away.
<fullermd> Anyway, whaddaya get if you run released versions, anyway?  All you do is trip over bugs that other people have already found.  Where's the joy in that?
 * spiv sometimes thinks that "Following the tip" sounds like "walking the plank"
<fullermd> I mean, that's all like "You: I found this bug    lifeless: Yeah, it's bug 12345".
<ubottu> Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<spiv> Especially when lifeless says he lives ahead of the tip :)
<fullermd> With tip, you can be all "You: I found this bug     lifeless: o_O"
<spiv> fullermd: the joy is that if the bugs are already known, then maybe the workarounds are too ;)
<jml> spiv: 'patches accepted' is not a workaround.
<fullermd> Piffle.  What kinda wimp wants to live like THAT?
<fullermd> That's like getting pre-digested food.
<fullermd> Gotta have something you can sink your teeth into.
<fullermd> Even if it responds by sinking teeth into you...
<lifeless> mwh: so, did you try the branch? or just curious about whether it will help you ?
<spiv> poolie: there's a mostly complete http://bazaar-vcs.org/SmartPushAnalysis1.8 now.  I'm off to lunch.
<poolie> hey, great
<poolie> i was literally talking about it to thumper right now
 * spiv does a couple last touches
<spiv> Ok, really lunch now :)
<spiv> poolie: buried in the "analysis" section is a description of the 10s win I mentioned this morning.
<poolie> spiv, can you tell me more (or add more) to that page about the streaming-push work
<poolie> like sending a put_revisions_stream rather than working on packs
<mwh> lifeless: no, i didn't get around to it
<poolie> spiv, are you back?
<spiv> poolie: I am
<poolie> quick call? skype or pots?
<spiv> Either's fine with me.
<jml> will 'bzr upgrade' in a shared repo upgrade the branches in that repo?
<lifeless> jml: it didn't do so in the past, but I don't know if it does now
<jml> lifeless: thanks.
<lifeless> jml: easy enuff to find out
<jml> lifeless: yeah, I know.
<jml> the answer is "no"
<vila> hi all
<lifeless> jml: ping
<jml> lifeless: pong.
<lifeless> jml: AIUI bzr never stacks unless --stacked is passed
<lifeless> I refer to your lp documentation
<lifeless> if it is stacking without --stacked being passed, or a local default being set, I consider it a pretty big bug we should fix
<jml> lifeless: ok.
<lifeless> (because stacking generates a truncated database, it can lead to unrecoverable data loss if people think they actually have a full branch)
<jml> lifeless: not 100% sure what to say to that.
<lifeless> (and then delete something)
<jml> lifeless: the work I've been doing on Launchpad has been predicated on the default stacking policy stuff in Bazaar 1.7.
<lifeless> jml: I understood that policy to control *where* not *if*
<jml> lifeless: ok, then that's definitely something to raise on the Bazaar mailing list.
<mwh> <lifeless> jml: AIUI bzr never stacks unless --stacked is passed
<mwh> not true, a*i*ui
<lifeless> poolie: please read the above, then comment
<lifeless> from 16:11 < lifeless> jml: ping
<jml> lifeless: in any case, whether or not Bazaar needs to grow a local configuration option is incidental to Launchpad.
<jml> lifeless: if the 1.7 release gets one I'll update my instructions.
<jml> lifeless: this rollout only defines a stacking policy for projects on a pre-configured shortlist, so the impact is manageable.
<poolie> hi
<poolie> hm
<poolie> my understanding was that it should not normally stack unless --stacked was given
<poolie> but when pushing to eg launchpad the server could tell it to do so
<jml> this matches how bzr behaves at the moment.
<poolie> yay
<poolie> i'm so haappy to hear thaht
<poolie> that*
<jml> :)
<jml> ok. well I'm going to take a few deep breaths to recover from that little shock.
<poolie> lifeless: is this ok with you?
<lifeless> poolie: I don't really feel comfortable with that, but if you are, well, I have bigger fish to fry.
<poolie> jml, can we change this later so the server just sends a suggested url but doesn't turn it on?
<jml> poolie: I'm not sure I follow. At the moment, all the server does is specify a URL in a control.conf file.
<jml> (and a billion things to deal with the fallout of that & Launchpad's own infrastructure)
<jml> poolie: presumably Bazaar can change at a later stage to respond differently to this URL.
<poolie> ok
<poolie> lifeless: thanks for the status update that was super useful
<poolie> aside from being a nice set of numbers
<lifeless> I'd like to set usertest run across it
<poolie> thanks for noting that it may be bottoming out too
<poolie> ok
<poolie> you can, or i can on escudero
<lifeless> is there a HOWTO?
<poolie> yes, just google it
<lifeless> http://rabbit.eng.miami.edu/dics/amerlen/length08.txt ?
<lifeless> thats the only hit
<lifeless> for "'usertest' 'escudero'"
<poolie> hee hee
<poolie> http://people.ubuntu.com/~ianc/plugins/usertest/doc/usertest-tutorial.html
<lifeless> uhm
<lifeless> I meant on escudero
<poolie> https://wiki.canonical.com/Orcadas
<poolie> i mistyped
<poolie> i'll be here for a few more hours so i'm going to take a break now
<lifeless> ok
<lifeless> well, I might poke tomorrow
<lifeless> reading those two docs suggests to me the answer is 'no there is no howto for running a specific branch'
<lifeless> so I'll look at it tomorrow
<poolie> i can set it up
<lifeless> gnight, enjoy your call :P
<poolie> it's in the doc on that machine
<lifeless> branch is http://people.ubuntu.com/~robertc/baz2.0/readdir
<lifeless> thanks!
<imyojimbo> hi, im trying to push a branch to lp , and i get "The server's host key is not cached in the registry"
<Odd_Bloke> poolie: Did you see my email regarding payment for the summer?
<poolie> Odd_Bloke: hi there
<poolie> yes let's see about that
<Odd_Bloke> poolie: I'm at work ATM, so email is better than IRC. :)
<poolie> ok
<poolie> sent
<Odd_Bloke> poolie: Thanks.
<Odd_Bloke> I'll deal with it when I get home.
<Odd_Bloke> Or possibly tomorrow, I'm probably busy this evening.
<poolie> maybe we can talk tomorrow my time/uk evening
<poolie> lifeless: should be running now in http://benchmark.bazaar-vcs.org/usertest/log/usertest.log.inprogress
<awilkins> ls
<awilkins> Oops
<robsta> hi
<robsta> is there anything new in the BzrGit department?
<Odd_Bloke> robsta: jelmer wrote (most of) it, so he'll probably know.
<robsta> is it usable already?
<lifeless> robsta: it can clone locally I believe
<robsta> ok, guess i'll stick to svn server-side for the time being, then
<antoranz> Hi guys!
<antoranz> is it possible to list all the revisions in a branch but ordered by date instead of "revision/branch"?
<antoranz> I mean.... instead of having the revision tree, I want toget all the revisions ordered by date
<antoranz> is that even possible at all?
<vila> jam: ping
<Tak> in a bound checkout, does `bzr cat` hit the server?
<bob2> I'd assume yes for lightweight,no for regular
<Tak> good
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.6.1 now available! please test bzr-1.7rc2 |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<Leonidas> how comes that bzr mv -q still shows what it moves?
<james_w> Leonidas: it's a bug I expect
<Leonidas> Yeah, I think so too. I just encountered again when I wrote it in a script
<james_w> Leonidas: I would guess it's an easy fix
<Leonidas> james_w: probably. It's not a problem currently, I just wanted to tell that to the developers, so they can fix it when someone has a bit of spare time.
<james_w> Leonidas: a bug report would be a better way of doing that of course
<Leonidas> james_w: sure, I'll write one in a moment. Just wanted to make sure I'm not the only one with this problem.
<james_w> thanks, I'll check now
<james_w> yup, I see it too
<Leonidas> CLOSED: worksforme with the comment: "Do you think we'd miss something like this?" would leave me standing like an idiot ;)
<james_w> true :-)
<Leonidas> james_w: there it is: https://bugs.launchpad.net/bzr/+bug/271790
<ubottu> Ubuntu bug 271790 in bzr "bzr move ignores quiet option" [Undecided,New]
<james_w> Leonidas: thanks, I triaged it
<Leonidas> cool, let's see how it'll continue :)
<Kittens> meow
<Kittens> oh my
<Kittens> 1.7 already? O_o
<Kittens> (well, an rc, but still)
<Kittens> did you hire a team of slaves or such?
<awilkins> Kittens: 1.7 was hot on the heels of 1.6
<awilkins> 1.6 had a over-long release cycyle
<Kittens> ah :p
 * rocky is comforted by the fact that there are so few changes between 1.7rc1 and 1.7rc2
 * awilkins just wants them to merge his switch-to-sibling patch so he can stop maintaining his own builds
<awilkins> markh: Is it hard to build the "exe" version?
<Verterok> awilkins: ping
<awilkins> Verterok: pong
<Verterok> awilkins: hey there!
<Verterok> awilkins: patch merged, and also a few other fixes/enhancements in bzr-java-lib (also in bzr-eclipse)
<awilkins> Verterok: Excellent :-)
<awilkins> Verterok: I love it when my patches get merged, I don't have to maintain the branch anymore :-)
<Verterok> awilkins: hehe, indeed.
<awilkins> Going to have to keep that callisto branch going though, methinks
<awilkins> At least until my PM badgers Borland into coughing up upgrade licenses
<Verterok> awilkins: (don't remember if already told this) about the dependency on core.expressions it's only used in the refresh hook
<awilkins> So we can use the Ganymede version insdtead of Callisto
<awilkins> Verterok: Yes... the refresh seems to work OK, so I'm not sure if it breaks anything to be on Callisto
<awilkins> Is there any specific behaviour that it enables?
<Verterok> awilkins: that's is only for a specific layout
<Verterok> awilkins: when the project root is below the branch root
<awilkins> Verterok: Flat or hierarchical or something else?
<awilkins> Ah
<awilkins> So it would come into play on bzr-eclipse, for example
<Verterok> awilkins: i.e: bzr-eclipse project layout: mutliple projects in one branch
<Verterok> yes
<awilkins> It doesn't affect most of my stuff
<Verterok> awilkins: that was my point :) I assume you can remove the refresh hook and so the core.expressions deps
<awilkins> Verterok: What exactly is the bit that needs that version? Because if you just take the version number out of the manifest, it compiles and appears to run ok.
<awilkins> And a version of "3.2.100" suggests a callisto component to my mind
<Verterok> awilkins: I think the 3.2.100 was added in Europa (but just guessing)
<Verterok> awilkins: I never specified a version :p
<awilkins> Verterok: It's true that I can't find a 3.2.100 version in the Callisto updates, but a europa-specific component should be 3.3, no? I suspect it's a patched version of a europa-compatible library
<awilkins> Sorry, callisto-compatible
<awilkins> That would fit the version number scheme
<Verterok> awilkins: here (3.4) seems to compile without the version number
<awilkins> Also does so for 3.2
<Verterok> awilkins: the version scheme is not exactly like that :)
<awilkins> Well, it should be :-)
<Verterok> awilkins: mayor.minor.bug-fix, mayor change *only* if there are api breaks, minor when there are new api or visible changes
<awilkins> Verterok: It just makes a sort of internal sense to me that a component of version 3.2 has had the same API since Eclipse 3.2
<awilkins> Since there are also 3.4s in Ganymede but not in Callisto
<awilkins> esp. for actual eclipse bits
<Verterok> awilkins: in ganymede, core.expressions is in version 3.3 :p
<Verterok> awilkins: http://wiki.eclipse.org/index.php/Version_Numbering <- from there I taked my lame explanation of versions numbers :)
<awilkins> Yes, but you have to admit that the large amount of "3.2" components in Callisto, and 3.3 in Europa, and 3.4 in ganymede... well, I reckon there's a convention operating within the rules there :-)
<awilkins> What would fail if it wasn't working properly on this version
<Verterok> awilkins: sure, it makes sense that most of the componentes get bumped to 3.3, 3.4, etc :)
<awilkins> BUt if the API does not break... then not
<awilkins> Hence 3.3. on Ganymede, etc
<Verterok> awilkins: right :)
 * Verterok just realized that bzr-eclipse should be 1.0.99 :p
 * awilkins has had to revise client code several times, you naughty dog
<awilkins> :-P
<Verterok> :)
<awilkins> Since you didn't choose a version number, I suggest it is removed
<awilkins> Since it compiles just fine here
<Verterok> awilkins: ah, all tests passing on *nix :-D
<awilkins> And you don't support 3.2 anyway because you use 3.3 components
<Verterok> awilkins: sure, I'll remove it in my next commit
<awilkins> I have a little patch for your /tmp dir stuff
<awilkins> Hmm.
<Verterok> awilkins: patches are more than welcome :)
<awilkins> Verterok: They fail to start a client here
<awilkins> Verterok: My laptop is passing.
<Verterok> awilkins: the client don't start?
<Verterok> awilkins: also I added a few goodies related to preferences, let me know if the chicken-egg issue is solved for your case :)
<awilkins> Verterok: It doesn't seem to be registering the client factories before it asks to create one
<awilkins> It calls into createClient and factories is an empty mapo
<Verterok> awilkins: hmm, let me check
<Tak> argh, why does `bzr diff` return a nonzero value on a non-error condition?
<awilkins> I'll trap my working one and see where regstierAdapterFactory is getting called during the tests
<Verterok> Tak: it indicates the result of the diff
<Verterok> Tak: take a look at the end of: 'bzr help diff'
<Verterok> awilkins: it should be in TestsConfig/TestConfig (If I remember ok)
<Tak> I see what they mean
<Tak> but the shell treats !0 as an error condition and acts accordingly
<fullermd> diff(1) returns non-zero on differences too.
<awilkins> Verterok: Badgers, my fault
<awilkins> I'm running with xmloutput 0.5
<Tak> meh, it does?  I guess that answers my question then
<awilkins> My thoughts on that are ; since bzr-java-client can manipulate the PLUGIN PATH, it could have it's own internal xmloutput plugin
<awilkins> But it probably needs a test to check the plugin version
<Verterok> awilkins: oh, ok. I was thinking that maybe the new "lightweight" checks for the executable broken something on win32
<awilkins> Verterok: All the bits of code I suspected haven't changed between our branches, I think
 * awilkins pulls xmloutput
<Verterok> awilkins: that would be nice, I've been playing with eclipse regarding this "bundled-xmloutput", and it seems quite simple to achieve
<Verterok> awilkins: do you know if the PLUGIN PATH override the default plugins location?
<awilkins> Verterok: I don't know
<awilkins> Verterok: It all passes here apart from index because I don't have the plugin
<Verterok> awilkins: great, I must add a conditional in the execution of the test related to bzr-search
<awilkins> Now I'll try a startup in a clean workspace
 * Verterok cross fingers and wait
<Verterok> awilkins: the preferences page should be opened on startup
<awilkins> Verterok: Ok, zero prefs
<awilkins> So far.
<awilkins> Imported a project (because I'd usually do that and forget about VCS for a while)
<awilkins> Ok, menus are available.... go to prefs now
<awilkins> Set the .bat file... it's happy
<awilkins> Took a moment to show overlays because this is a large tree
<awilkins> So the "can't set prefs" issue is clear
<Verterok> awilkins: gooooood :D
<awilkins> This is a slightly patched branch because I've removed callisto things to make it compile
<awilkins> *europa
<awilkins> But only those changes required (no SaveableEditor)
<awilkins> My wife is waving cake
 * awilkins departs, drooling
 * beuno points everyone at: http://www.smashingmagazine.com/2008/09/18/the-top-7-open-source-version-control-systems/
<Verterok> hi beuno
<beuno> hey Verterok
<beuno> lifeless, igc, jam, abentley ^
<LarstiQ> anam I missing some navigation, or isn't there much to the review?
<beuno> well, it's not very profound
<beuno> but it showcases bzr quite weel
<beuno> well even
<LarstiQ> ok :)
<beuno> TBH, it's a site that normally features design stuff
<beuno> so it was surprising to me to see that entry
<beuno> so I had to share it   :)
<Tak> "Monotone places higher value on integrity than performance."
<Tak> I thought that was bzr's claim :-P
<LarstiQ> Tak: you obviously haven't tried monotone lately ;)
<Tak> haha, no
<Tak> one experience was enough for me
 * awilkins has a monotone server that's run untouched on his DVR for ages
<awilkins> I think I'll transfer the source to bzr branches and leave it at that
<ronny> yo
<Spaz> ew monotone
<Spaz> hello ronny
<ronny> monotone is certainly nice and powerfull, just dog-slow cause poor data-store
<awilkins> SQLite is not poor ... but RDBMS are a poor idea of version control
<awilkins> Another reason to shy away from TFS
<LarstiQ> it's a bit sad, they did some nice stuff
<ronny> awilkins: well, given the context sqlite is poor
<awilkins> VSS! With SQL Server as a backend! Yay
<ronny> well
<rocky> is there anything compareable to svn authz access via http/apache for bzr? where you can control access to various repos and/or folders-within-repos via a config file?
<Tak> eh, tfs is a bit more like svn with sql server as a backend ;-)
<awilkins> rocky: You can only do authorization on a whole-tree level
<beuno> there is a script in contrib/
<rocky> awilkins: well, is there anything making that (on whole-tree level) simple for a http based bzr serving?
<beuno> for SSH keys
<ronny> hmm, well, will bzr branches stay to limited to one head and having the workdir point to that
<rocky> beuno: what i'm asking for would need to be read/write via http
<beuno> rocky, ah, webdav. vila is the man to ask about that
<rocky> vila: ^^ :)
<beuno> it's late-ish for him, so he may not be around
<beuno> if you don't get an answer, sending an email to the list is the next best thing
<awilkins> Hmm, I like the domo-kun eating trees on their picture of git, why isn't the real git like that....
<rocky> since the main bzr http serving thing is just a python wsgi app (well at least it looks that way) it seems fairly straightforward to write my own access middleware for that
<rocky> but i'd love to see if someone's already one that
<rocky> *done
<beuno> rocky, well, contributions to loggerhead are *very* welcome  :)
<awilkins> I've only gone as far as configuring access via IIS auth
<AmanicA> I've managed to do read & write through apache  (bzr+http://)
<beuno> anyway, I'm off to the dentist
<awilkins> You just use IIS user impersonation and normal NTFS ACLs
<beuno> IIS, eeeeew!
<Spaz> ew
<beuno> ok, that's it for unproductive comments from me
<awilkins> I know, but the production site is ASP classic
<rocky> ew is right ;)
 * Spaz threw up a little
<awilkins> I could change it to PHP in short order though
<awilkins> THe ASP is only being used for a very few things
<awilkins> Mostly inserting "1" and "0" into links in strategic places
<awilkins> Might be nicer... but without it, Bazaar would not have working IIS support yet, so ner.
<AmanicA> rocky: using AuthType Basic and AuthUserFile like with svn
<LarstiQ> awilkins: I for one think you're a hero :)
<Spaz> i think IIS discussion is off-topic in here
<Spaz> and quite frankly i think it's flamebait :P
<rocky> well as long as everyone here acknowledges that MS tech beats all i don't need to argue....
 * rocky couldn't resist throwing out some bait
<Spaz> hurhurhur
<Spaz> :P
<awilkins> Yes, MS tech is a violent assault, we agree
<Spaz> i think m$'s technology is their attempt at conquering the world...and it seems to be working
<Spaz> :p
 * Spaz forks himself into the background
<LarstiQ> Spaz: nah, not as it concers
<LarstiQ> meh
 * LarstiQ kicks freezing laptop
<Spaz> don't kick it too hard
<awilkins> markh: Ping?
<ferrouswheel> hi all, is there any way to pull individual file changes from a revision?
<ferrouswheel> ahh, dumb question, just found out merge supports that
<Spaz> bzr help diff
<Spaz> or that
<bpierre> hi
<LarstiQ> bpierre: hey, did you try `bzr add subtree`?
<LarstiQ> s/hey/hi/
<ferrouswheel> looks like i spoke to soon... online some refers to using individual files with merge... but i can't find anything in the help about it
<ferrouswheel> oh actually it does work... it just doesn't accept wild cards.
<bpierre_> does it work if the directory containing the subtree is added but not yet commited?
<bpierre_> LarstiQ: here is what I did: http://www.pastie.org/275241
<LarstiQ> bpierre_: I think that should work. The root fileid won't be set yet of ruby, so _possbily_ that could go wrong
<bpierre_> I tried to commit, then add, no luck
<LarstiQ> no luck in what way?
<bpierre_> I'm using the right format, right?
<LarstiQ> bpierre_: yes, old, but alas
<bpierre_> add src, commit src, branch ../c src/c, add src/c
<LarstiQ> bpierre_: what does that give?
<bpierre_> nothing, if I do a status, src/c is still unknown
<LarstiQ> hmm
<bpierre_> 0.373  opening working tree '/home/bpierre/projs/test/ptree/ruby/trunk/src/c'
<bpierre_> 0.390  skip control directory '.bzr'
<bpierre_> in ~/.bzr.log
 * LarstiQ tries to find a workable machine
<LarstiQ> bpierre_: oh wait, which bzr is that you're using?
<LarstiQ> bpierre_: path/to/nested-trees/bzr ?
<bpierre_> installed http://bazaar.launchpad.net/%7Elarstiq/bzr/nested-trees/ with --prefix=~/progs
<bpierre_> bzr --version: Bazaar (bzr) 1.3.0.dev.0
<LarstiQ> bpierre_: ok, so bzr in your path is that one?
<bpierre_> yep
<LarstiQ> bpierre_: bah, you're right
<fm> how do i publish my local bzr repo to an ftp server?
<bpierre_> ?
<LarstiQ> bpierre_: that means I'll have to refamiliarize myself with the code
<bpierre_> ok
<jcomeau> hi all, i can't seem to find the right lines on your webpage to add to /etc/apt/sources.list... any clues?
<jcomeau> this is on Debian, of course
<LarstiQ> bpierre_: I'm sorry I don't know currently why that is so :/
<LarstiQ> jcomeau: testing or sid should not need anything extra
<bpierre_> LarstiQ: how can I execute the test suite?
<LarstiQ> bpierre_: bzr selftest <pattern>
<LarstiQ> bpierre_: without the latter it will run the entirety
<bpierre_> ok
<LarstiQ> bpierre_: there are on the order of 10 failures/errors atm
<bpierre_> ok, and I don't need to be in a specific directory?
<LarstiQ> bpierre_: (if you're bored, you can look at `bzr help join`, and see how well that models your components usecase)
<bpierre_> ah, ok
<LarstiQ> bpierre_: join is also in regular bzr fwiw
<LarstiQ> bpierre_: I believe at least Debian/Ubuntu run the suite after building packages, and not from the source tree, so I expect that to work
<bpierre_> really? I noticed split was
<bpierre_> (part of the regular bzr)
<LarstiQ> bpierre_: in development, most people will run it from a bzr source tree
<bpierre_> ok
<LarstiQ> bpierre_: yeah, bzr-svn uses (or used) the same functionality under the hood
<bpierre_> the rich root format?
<LarstiQ> bpierre_: splitting and joining
<bpierre_> what are the differences between all those format? rich-root, development-subtree, dirstate-with-subtree?
<jcomeau> LarstiQ: that's what i gathered, but apt-get -t unstable install bazaar tells me it's already the latest version... and it's 1.4.2
<LarstiQ> jcomeau: s/bazaar/bzr/
<pl0sh> i have installed the new release and i got this message always i use the bzr command.
<LarstiQ> jcomeau: the 'bazaar' package is unfortunately named, it is not the bzr Bazaar
<LarstiQ> bpierre_: different ages basically
<jcomeau> LarstiQ: thanks! looks like that'll do it...
<LarstiQ> bpierre_: rich-root is a part of what the nested-trees needed, but that got integrated a while ago
<LarstiQ> bpierre_: dirstate-with-subtree is the old dirstate format, plus subtrees
<LarstiQ> bpierre_: and development-subtree I don't know but assume to be current development format plus subtree
<bpierre_> ok, and rich-root?
<LarstiQ> pl0sh: what error?
<bpierre_> in the blueprint, rich-root is required, so is rich-root part of subtree format
<bpierre_> ?
<LarstiQ> bpierre_: no, the rich-root feature is necessary but not enough
<pl0sh> bzr-svn is not up to date with installed bzr version 1.7rc1.
<pl0sh> There should be a newer version of bzr-svn available.
<pl0sh> Standalone tree (format: pack-0.92)
<LarstiQ> bpierre_: rich-root _is_ enough for bzr-svn though, part of the reason why rich-root formats exist in released versions
<bpierre_> ok, it's what I understood then
<bpierre_> thanks
<LarstiQ> pl0sh: either update bzr-svn to a version that works with bzr 1.7rc1, downgrade bzr to a version that works with your bzr-svn, or disable the bzr-svn plugin
<LarstiQ> bpierre_: np
 * LarstiQ really needs to start going home
<pl0sh> ok, so, what version of bzr-svn works with bzr 1.7rc1?
<LarstiQ> pl0sh: no released versions according to http://bazaar-vcs.org/BzrForeignBranches/Subversion
<LarstiQ> pl0sh: two other options, run with --no-plugins, or ignore the message.
<LarstiQ> pl0sh: you do realise bzr 1.7rc1 is a release candidate, and not a released version? :)
<awilkins> pl0sh: silly question ; do you use it?
<pl0sh> sure i know it
<awilkins> (bzr-svn, that is)
<LarstiQ> pl0sh: if you don't use bzr-svn, disabling it is probably the easiest solution
<pl0sh> i don't use it i think i'll disable it or anyway just ignore the message
<awilkins> You can just find it and move it to the parent folder
<bpierre_> LarstiQ: mmm, did a join, without --reference, commit, but then noticed --reference, and how it matched more by usecase, so uncommit, revert, add (after renaming src/c/.bzr.retired.0/), and now commit
<LarstiQ> pl0sh: if you do want to use bzr-svn and 1.7rc1, you could use a non-released bzr-svn version as well
<bpierre_> but it fails
<bpierre_> :P
 * LarstiQ slaps self
<LarstiQ> bpierre_: reference, that's it! :)
<bpierre_> bit I'm not really going gentle with it, what with the uncommit and all
<pl0sh> alright, thank you
<bpierre_> LarstiQ: the error is: bzr: ERROR: already in a write group
<LarstiQ> pl0sh: which would be lp:bzr-svn/0.4 I think
<LarstiQ> bpierre_: huuuu
<bpierre_> :D
<bpierre_> I'm going to try all over again, start from a clean state
<pl0sh> btw, i'm not very expert using bzr, and i'd want to use it better, where can i start?
<LarstiQ> bpierre_: I like your abilities as a tester ;)
<LarstiQ> pl0sh: that depends. Reading the documentation is a start, but imo interacting with other people works best.
 * LarstiQ really heads home now
<LarstiQ> bpierre_: thanks for trying this stuff out btw, I can use the kick under my rear :)
<pl0sh> i just use the basics of bzr
<LarstiQ> pl0sh: well, what more do you want to do?
<LarstiQ> pl0sh: plugins can be fun to write, if you have the time and the inclination
<LarstiQ> pl0sh: as can reading the mailing list
<pl0sh> that would be great
<pl0sh> actually i use bzr to keep tracking my development and as a helper when a make a mistake (i.e. delete a file or something like that..)..
<pl0sh> but actually i don't know how to use bzr in a team, like merging branches (i think)
<shawn_1> I have been using svn for a long time, and I am trying to migrate to bazaar. I have the repository set up on a remote box and I am having trouble checking out from it.
<bpierre_> LarstiQ: same error: http://www.pastie.org/275273
<shawn_1> bazaar is not liking my proxy settings
<VanL> Is there a way to list the available repositories at a URL? For example, I have access to bzr+ssh://username@hostname.com/some/path.
<VanL> I can push something there
<VanL> but I want to see what others are doing in the same tree
<mwh> hmm, seems having a gannotate window open makes bzr pull fail with
<mwh> bzr: ERROR: Could not acquire lock "[Errno 11] Resource temporarily unavailable"
<awilkins> Wah, wah, wah
<VanL> but I don't know the exact path to their repository.
<awilkins> I built bzr.exe for windows, and it doesn't work
<awilkins> mwh: Yes, many things I think should be read only use too many locks
<fullermd> VanL: Not exactly.  There's a 'branches' command in bzrtools that will walk around a given location and try to list all the branches there.
<VanL> fullermd: Does it come with the basic bzr install?
<fullermd> No, but it's a common plugin.
<fullermd> There's a package for it on most OSen that I know of [that bzr is packaged for, at least]
<bpierre_> part of the windows setup exe too
<kiko-phone> hey lifeless, are you around?
<VanL> In bzrlib/plugins?
<GaryvdM> VanL: qlog from qbzr will find the branches and show the tips form the branches. See http://garyvdm.googlepages.com/qlog-repo.png
<bpierre_> any direction on how to rebuild the setup exe for windows?
<VanL> GaryvdM: thanks
<VanL> fullermd: thanks, now installed.
<mwh> is it new that remotebranches support set_stacked_on_url?
<mwh> i think they do something really weird with relative paths
<mwh> ah no
<mwh> it's that RemoteBzrDir.find_branch_format opens the branch
<lifeless> jam: ping
<lifeless> jam: do you know, offhand, where Py_ssizet is defined, getting buildfailures of all our extensions on a python2.4 box
<jam> lifeless: You need a new-ish version of pyrex
<jam> which will do a proper "if python_version < 2.5: #define Py_ssize_t int"
<jam> lifeless: looking at the file I have right now:
<ronny> re
<jam> http://rafb.net/p/47rI8Y78.html
<lifeless> this is still running dapper :P
<jam> Py_ssize_t only exists on python >2.5
<jam> sorry, >= 2.5
<jam> lifeless: I'm trying to debug why PQM is running into autopack failures
<jam> And I seem to have run into a *very* strange situation
<jam> Where I'm seeing a revision text 6 times in the same pack file
<jam> each time with different content
<lifeless> just whacking that into _)dirstate_helpers_c.h has helped
<lifeless> jam: if you're analyzing the pack content, remember that knit hunks only have a revision field
<lifeless> jam: so you'll see file texts and inventories etc willynilly
<lifeless> jam: there is a bug open on the autopack issue, its not just pqm (FWIW)
<jam> lifeless: sure, but how would you get 6 items?
<jam> ah, just multiple file texts?
<LarstiQ> bpierre_: same thing here, I'll look at it tomorrow, after some sleep
<bpierre_> ok, thanks
<ronny> lifeless: about that only having a single tip per branch + always having the workdir point to that tip, is there any chance to ever change that?
<lifeless> jam: rev, inv, sig, 3 file changes
<lifeless> ronny: well, everything can be changed, if the community agree its an improvement
<lifeless> ronny: I'm not quite sure what you mean though, because branch, in every VCS I know of, refers to one of two things: a line of development, or a bifurcation in the revision graph
<fullermd> Well, the workdir can already point elsewhere than the tip.  You just can't do or find out much of anything about it when it is.
<jam> lifeless: do you know how LP guys are requesting PQM do a cherrypick? I didn't think that was possible
<mwh> jam: cherrypicks are done by the osas i think
<lifeless> ronny: in the former, a revision is the definition of an entry point into the graph; I guess you could define multiple revs as all being 'part of branch X'
<lifeless> jam: manual merges by LOSAs
<fullermd> Well, mtn can have multiple heads because "on a branch" means "has a given certificate attached"...
<lifeless> ronny: and in the latter case, its structural rather than user facing
<jam> I don't know what an OSA or a LOSA is, but it is getting the PQM user-id
<lifeless> fullermd: indeed; mtn is the exception :)
<ronny> lifeless: well, git, hg and monotone allow me to go to previous/alternative versions in a branch, i build my workflows around that, bzr really differs there
<bpierre_> monotone allows multiple heads for a branch
<lifeless> jam: 'sudo' :>
<jam> anyway, I have the feeling that the manual editing is where the problem is happening
<jam> *why* I'm not sure
<jam> but that seems to be causing the later problems.
<lifeless> jam: I don't, because the same thing has happened to beuno on a normal push
<jam> I'll check another example (I have 2)
<ronny> bpierre_: not just monotone
<lifeless> jam: there is a bug open, with tarballs of the branch as it happened live
<beuno> are we talking about the packs collisions?
<bpierre_> can be interrested to go back (maybe using something like bisect), and fix the bug where it was added
<lifeless> jam: don't get confused by pqm hitting it :P
<bpierre_> then merge the multiple heads
<beuno> if we are, it's happened multiple times already, with different branches
<lifeless> ronny: AFAIK bzr allows precisely the same workflow, spelt a little differently, but the same overall picture and work
<bpierre_> also, you can pull/push with monotone, without having to merge, which can be great (you can always do the merging on one machine)
<lifeless> ronny: if there is a something you want to do and bzr doesn't help you do it, thats definitely a bug.
<ronny> lifeless: as far as i got that i have to make a multi-branch repo and create multiple branches on different paths, and thats just not what i want to do
<LarstiQ> lifeless: I want to find bugs in bzr? :)
<fullermd> ronny: Well, I think it IS just monotone.  The others have multiple branches.
<LarstiQ> ronny: bzr switch <sibling> ?
<toytoy> guys how would i resolve the pending merges? or can i also abort that pending merges? this exist when i issue 'bzr status'
<bpierre_> wouldn't the -r fix to update fix that?
<bpierre_> being able to go back
<LarstiQ> toytoy: normally, you'd commit them
<fullermd> Not exactly.
<ronny> LarstiQ: not really
<fullermd> update -r fits different uses.
<ronny> LarstiQ: not nearly as flexible
<LarstiQ> ronny: then it isn't clear to me what you want to do.
<bpierre_> fullermd: ?
<toytoy> LarstiQ: oh yeah thanks i did and it's lost i thought it will still show :)
<lifeless> toytoy: after you do a merge, you need to do a commit to action the merge
<lifeless> toytoy: bzr stops after ocmbining the content, so you can review it
<ronny> fullermd: well, in monotone multiple heads with the same name are pretty much 2 "branches", too they just happen to have the same name
<fullermd> bpierre_: update -r lets you flind your WT around easily (and with better semantics for various things than using revert), but it's not the same as jumping among branches at all.
<lifeless> bpierre_, ronny: perhaps a little detail will help. We have 3 objects:
<lifeless> WT - your source code unpacked on disk, and some metadata such as the revision bzr set the tree to be
<toytoy> lifeless: oh i see, thanks for that :)
<fullermd> ronny: Not really; as far as mtn is concerned, it IS one branch.  Leads to some impressively large small differences.
<lifeless> Branch - a tip in the revision graph, with attached user editable metadata like push-location, tags etc
<bpierre_> well, my first concern is being able to switch revision, not branch, and being able commit on the same branch
<fullermd> Anyway.  I do agree that branches being tied to directories makes a number of things more cumbersome.
<lifeless> Repository - history store
<bpierre_> but being able to switch a workspace to another branch could be handy too
<fullermd> With a lot more support code, a fair bit of that could be papered over, but...
<ronny> fullermd: well, from a technical point its just 2 heads in the dag with the same name tag, it works exactly the same in hg
<lifeless> bpierre_: you can switch workspaces easily - the switch command does this.
<lifeless> a shared history store gives you disk space optimisation, for large projects this is useful
<lifeless> bpierre_: when you say commit on the same branch, do you mean 'manage branches roughly like mtn' ?
<lifeless> wife calling, I'll be back in a bit. ronny - look into tags; they may do what you want [though using a single workspace N branches should do it too - I'd like to know the downsides]
<bpierre_> well, what happen if I go back, and try to commit?
<bpierre_> all on the same branch?
<ronny> lifeless: i mostly want to deal with stuff like i do with git/hg, im not using mtn these days
<bpierre_> isn't switch only part of the loom plugin?
<GaryvdM> no
<ronny> bpierre_: well, the dirstate has to be linked to the revision you are at, so you would create a new line of history thats to be merged at a later point
<bpierre_> I really liked monotone, but conflicts were a pain, and bzr is so much faster
<bpierre_> ronny: ok, that's what I want
<bpierre_> how would I merge?
<bpierre_> merge .
<bpierre_> ?
<ronny> if you got 2 heads, you would just merge, else yo'd have to refer to the revisions
<bpierre_> how would revision number be constructed?
<lifeless> ronny: well, git gives you a new ref in the same repository, which is equivalent to a separate branch in a shared repo in bzr
<ronny> well, there are bzr's uuid's and bzr could also infer a local linear numbering (hg does that, works like a charm)
<bpierre_> I have revnos 1 2 3 4 5, go back to 3 with update -r 3, commit
<lifeless> ronny: have you tried this, and of so what didn't it do for you?
<ronny> lifeless: i disliked the workflows of shared repos
<lifeless> ronny: local linear numbering conflicts rather badly with concurrency
<bpierre_> yeah
<lifeless> so I think there are ~ 3 discussions going on here at once
<lifeless> a) how to do what bpierre_ wants
<lifeless> b) how to do what ronny wants, in a way that works for ronny
<lifeless> c) some technical stuff about design/scaling etc
<ronny> lifeless: you mean concurrent multiple writers to the repo?
<lifeless> bpierre_: in the current design, if you want another line of development, you need a new branch object; branches in bzr are like branches in git in this way - they are not inferred, they are explicit references
<lifeless> ronny: by concurrency - yes
<ronny> hmk, nice
<bpierre_> mmm
<lifeless> bpierre_: branches are cheap though; I have a repo with ~12K branches, and it performs fine
<bpierre_> the problem is more how a branch is tied to a directory
<ronny> lifeless: any locks involved for stuff like tags? or completely lockfree?
<lifeless> bpierre_: what about that gives you problems (damn, I sound like eliza)
<bpierre_> I mean in monotone, there is a clear difference between the database, and a workspace
<lifeless> ronny: tags are per-branch, and as such the branch-lock surrounds mutation to tags
<ronny> ah, ok
<bpierre_> each revision can have multiple branch certs, and monotone just try to follow the DAG for update operation
<lifeless> ronny: so two branches can be pushed concurrently to the same repo, they don't conflict or collide
<bpierre_> an complain if it find a fork
<bpierre_> then you can reconcile multiple heads on the branch
<fullermd> I've hit some ugly corners in mtn on that sort of thing, to be sure.
<bpierre_> with bzr, a branch is tied to a directory, no?
<fullermd> The flexibility is nice to have, though.
<bpierre_> fullermd: what corners?
<lifeless> bpierre_: yes, branches are tied to a directory, but you can consider that a user-accessible database if you like
<lifeless> bpierre_: try this, just quickly, if you would:
<fullermd> Well, to take one example, I propogated a change where there was no divergeance.  Only the head got the new certificate, so one side of the 'branch' wasn't connected.  mtn-viz had a total fit for somebody else.
<lifeless> bzr init-repo --no-trees /tmp/bzr-db
<bpierre_> my only real problem, was how you resolve conflict, with a use case where you have a simplifed project, and you propagate with new/modified files in a directory that don't exists anymory in the target branch
<bpierre_> yeah, I could consider a no tree repo has my db
<bpierre_> and then I can create has many branches
<fullermd> (a lot of things about mtn bugged the snot out of me.  I don't particularly enjoy working with it.  But the multi-head capability makes doing daggy fixes REAL easy, and I miss that)
<lifeless> bpierre_: right
<bpierre_> which might be different revision of the same branch
<bpierre_> logical branch
<lifeless> bpierre_: trunk is one branch, and feature branches a,b,c
<bpierre_> but, it's more work
<bpierre_> than with monotone
<lifeless> bpierre_: ok. I take it you've tried working with this?
<bpierre_> btw, can you easily add custom certs/properties to a revision?
<lifeless> there is a revision_properties facility
<bpierre_> lifeless: multiple branches for each feature?
<lifeless> we use it for recording branch nicknames and plugins use it for recording arbitrary things
<bpierre_> ok
<lifeless> bpierre_: multiple branches, switch between them, etc.
<lifeless> bpierre_: I'm going out on a limb here, but are you trying to do 'daggyfixes' ?
<bpierre_> no, but it is one use case
<bpierre_> last time, I wanted to use the bisect plugin
<bpierre_> to find a bug
<bpierre_> which was a waste of time since it was a hardware bug on my project, but I disgrees, anyway, right know, what the plugin does is revert to a revision
<bpierre_> so stat, show the differences with the tip of the branch
<bpierre_> which is not practical
<bpierre_> and might be tempted to fix it in the revision that introduced it, so yes, a daggyfix, no?
<ronny> well, basically 2 things about branches suck, 1. dirstate is allways bound to the latest rev, 2. there is no way to have more than one head
<ronny> i want to jump back to rev x, commit a fix, merge with head
<bpierre_> also my tree is big, so all those operation take time/space
<bpierre_> ronny: exactly
<lifeless> bpierre_: switch is mostly O(difference), so total tree size and history are not really factors
<awilkins> I found the dirstate bound to tip thing confusing
<fullermd> 1. isn't true; there's just no real capability to manage it not being.
<lifeless> yah, 1. is false, though bzr tries to keep it always the same to allow commit() to work
<ronny> commit cant commit to revs that already have children?
<lifeless> ronny: commit commits to the tip of a branch
<bpierre_> ;(
<fullermd> (which is to say, the dirstate can easily point at any rev in the branch history, but there's no way, sans deep hacking, to MOVE it to anywhere but the current tip)
<lifeless> ronny: branch is defined as 'a tip'
<ronny> uh, thats well bad
<awilkins> Commit therefore makes a new tip
<lifeless> ronny: so its a tautology
<awilkins> So it should be able to make a new tip from any revision ; it already has done, for every revision before this one...
<lifeless> oh
<lifeless> terminology overlap
<awilkins> You can certainly have multiple tips in a repo
<lifeless> 'tip' here -> 'tip of the line of development', *NOT* 'a leaf node in the DAG'
<awilkins> Or heads
<lifeless> the DAG is unknowable, because its simultaneously distributed and disconnected
<lifeless> its also O(history) to do anything with it that involves inferring 'unmerged' from the entire dataset. this simply doesn't scale well without complex caches or long critical-lock sections around insertions to the db
 * mwh waves https://bugs.edge.launchpad.net/bzr/+bug/271924
<ubottu> Ubuntu bug 271924 in bzr "RemoteBzrDir.find_branch_format opens the branch" [Undecided,New]
<lifeless> ronny: so if you change the branch tip and dirstate rev you can commit against *any* rev in your local database
<mwh> around
<bpierre_> ok
<lifeless> this just mutates your existing branch - its what commit does, it mutates a branch to add a commit object to it, which is likewise inserted in to the repository
<lifeless> (actually the ordering is 'new commit object in repo; update branch tip; update dirstate'
<ronny> hmm, it generaly sounds a __lot__ more complicated to do in bzr, than it is in git/hg/monotone
<lifeless> ronny: git is the same - create a new commit object (done by linking to the index), update the branch reflog and basis reflog
<lifeless> ronny: hg is the same - insert content into all the modified revlogs, then the manifest revlog and revision revlog, then update the dirstate
<lifeless> I haven't read the code for commit in monotone but I bet it is ~=
<lifeless> we're having a deep technical discussion rather than one about getting you working well, because you seem to want to do that:)
<ronny> well, bzr doesnt seem to allow me to work like i want
<ronny> well, in hg i just do hg up -r rev; commit; merge
<bpierre_> +1
<ronny> in mtn i do the same
<lifeless> ronny: so, question.
<lifeless> ronny: if you do the first two commands, and someone clones you, what do they get ?
<ronny> 2 heads
<lifeless> ronny: and how do they know which one really represents the branch ?
<lifeless> (vs being an experiment that failed)
<ronny> both do
<bpierre_> they don't
<lifeless> bingo, that confusion is exactly my point
<bpierre_> know which one is best, an experiment
<lifeless> in bzr we don't have that, because the branch tip is well defined at all times
<ronny> well
<bpierre_> yeah, but with a process, a common location with a gatekeeper
<bpierre_> where is the problem?
<abadger1999> There very often isn't a good process or a gatekeeper.
<ronny> people cant pull my local repos, no problem, i wont push before the merge
<lifeless> bpierre_: what if the gatekeeper does that ? :P Or more pragmatically, consider shared branches, where there are many gatekeepers
<bpierre_> also, a good use case with multiple heads, is being able to commit on one machine, push to another, and do the merge on the second one
<lifeless> bpierre_: you can do that with bzr just fine
<ronny> also pushing is pretty much prohibited without explicit force if there are more than 1 heads as a result
<bpierre_> you have to create another branch, no?
<ronny> so remote branches are well-defined
<bpierre_> you can't push if you have diverged
<lifeless> bpierre_: no, though its the simplest way IMO
<ronny> i just want to do what the heck i want locally
 * abadger1999 often works on git repos where there's multiple branches with no well defined method of finding which a given piece of work should be done on.
<bpierre_> lifeless: how do you it without a new branch?
<abadger1999> I note that it's a social problem though... launchpad makes the same thing happen to collections of bzr branches.
<lifeless> bpierre_: bzr push, ignore the error about divergence, bzr heads on the other machine, bzr merge . -r <head you want>
<bpierre_> wait, push will have pushed the revisions?
<lifeless> bpierre_: though I prefer to just make a new branch when I have that situation, it remembers it for me then
<lifeless> bpierre_: yes, the repository will have them, they just aren't reference from the branch
<bpierre_> mmm, but you have to remember the revid
<lifeless> bpierre_: thats what heads will tell you, and heads --dead only lists unmerged heads
<bpierre_> ok
<lifeless> what I like about separate branches is that they are cheap, they are easily managed (I can have arbitrary number of pending-review, pending-merge, in-progress, etc)
<lifeless> by cheap I mean no workspace
<lifeless> and no separate history store
<awilkins> Does uncommit mark revisions?
<lifeless> as for the use case of 'make a new branch from an arbitrary rev', well - I think bisect can definitely be improved; there already is 'bzr branch -r XXX' to make a branch @ a rev
<awilkins> Because one thing I found is that "heads" is really fouled by uncommits
<lifeless> awilkins: If I understand you correctly, no
<fullermd> Branches being directories does necessarily make them heavier weight than ref-based branches, though.
<bpierre_> yeah, but you don't want a new workspace for each revision you try
<lifeless> awilkins: that would be nice wouldn't it. needs some thought
<awilkins> It would be nice if uncommit marked a rev as having been uncommitted
<lifeless> fullermd: yes, but thats the same weight as git and svn and cvs and a few others besides
<bpierre_> although, you could cheat with a new branch, cloning the tip, and then pull --overwrite -r ?
<fullermd> No (well, maybe svn/cvs, but I don't count them)
<fullermd> I don't mean heavier technically; I mean heavier psychologically.
<fullermd> You have to switch a lot more gears.
<fullermd> There needs to be a whole lot more UI magic happening to make dir-based branches seamless in a way that ref-based are naturally.
<lifeless> fullermd: mmmm, I don't see why; single tree, switch between, branches to list, push-repo, modulo bugs
<lifeless> fullermd: please define 'ref-based'
<fullermd> Well, ref-based can be dir-based, but meaning managed entirely by the tool behind your back.
<lifeless> bpierre_: yes, new branch, pull --overwrite -r X, should be fast
<awilkins> branch-and-switch would cover a lot of it
<fullermd> Consider the case: I have my branch of $PROJ.  You suggest a branch I should merge in.
<lifeless> fullermd: ok
<fullermd> If bzr were ref-based, I could "bzr branch $NEW beblatz ; bzr switch beblatz ; <check stuff> ; bzr switch mine ; bzr merge beblatz ; bzr ci"
<fullermd> But with dir based, I can't do that directly; I have to switch to knowing about the filesystem, and "bzr branch $NEW /wherever/my/repo/is/beblatz", etc.
<lifeless> fullermd: but you can do that today, with one change:
<fullermd> Ditto when I'm done, and can "bzr rm-branch beblatz" instead of "rm -rf /some/where... crap, where is that..."
<lifeless> "bzr branch $NEW ../beblatz ; bzr switch beblatz ; <check stuff> ; bzr switch mine ; bzr merge ../beblatz ; bzr ci"
<lifeless> fullermd: have you tried the switch branch-finding heuristic?
<fullermd> No, because I don't generally work that way.  But until it's a branch branch-finding heuristic and a merge branch-finding heuristic and a diff branch-finding heuristic...   it means you're switching a lot of gears.
<LarstiQ> so right now, switch is the only command that has the ref-behind-your-back heuristic, afaik
<bpierre_> switch is provided in 1.7?
<lifeless> fullermd: note that for hg, you have to rollback to decide you didn't like it, which is fugly, for git you need a branch-name, (so its system-managed, and thats nice)
<fullermd> I don't claim that dir-based branches are _inherently_ psychologically heavier, but there needs to be a lot of UI magic to make them FEEL the same weight.
<lifeless> fullermd: oh, I agree, the heuristic needs to be pervasive
<lifeless> fullermd: I was asking if you had tried it
<lifeless> bpierre_: switch is single, um, 0.92 or something; been in for ages
<bpierre_> ah
<lifeless> bpierre_: what we're talking about here, is a heuristic where switch will look for branches in oldbranch/../, which means less typing for you
<fullermd> Unfortunately, it's a lot like the performance question, in a way.
<lifeless> bpierre_: but other commands don't yet do that
<fullermd> It's not "bzr can't", but "bzr presently doesn't".
<fullermd> And each side of the question is going to put a very different emphasis on that phrase   :|
<fullermd> Being branch-based we have an inherent [not insoluble, but] problem, in that we HAVE to have that heuristic.
<lifeless> how many paths does mysql have in it ?
<fullermd> And it's a lot of places to sprinkle it.  Even if we get all the commands, then we have branch: and ancestor: and such revspecs to handle too.  And then there are plugins...
<bpierre_> I can live with the typing, it's just that the use of checkout can sometime be confusing (at least to me) so I didn't think about using it with a regular (disconnected) branch
<bpierre_> (after reading the help for switch)
<fullermd> Heck, look how long it's taken us (still taking?) just to get all the commands to understand the metadir format, and stop demanding WT's when they don't need them, etc.
<fullermd> (not that that's in any real way related to the issue, just the same on some level in the amount of distributed assumptions)
<awilkins> I agree, I keep finding myself wishing that merge had the same sibling-heuristic as switch (and that someone would merge my sibling finding patch for switch)
<bpierre_> wait, switch only work for a checkout ...
<awilkins> bpierre_: Yes, but the sibling heuristic only works on lightweights
<awilkins> bpierre_: My patch fixes it so it works on eavies too
<bpierre_> sibling?
<awilkins> brother, sister
<ronny> well, basically the workflow enfocements and the speed issues basically make me avoid bzr for all of my own projects
<jam> lifeless: so I have an idea of what is causing the auto-pack problem. And it *is* related to the cherrypicking, but only tangentially
<awilkins>  bzr switch sibling   ==   bzr switch <my bound branch>/../sibling
<LarstiQ> bpierre_: repo/{foo,bar}, cd foo, switch bar == switch ../bar
<bpierre_> I guess lightweigts is ok, I think I'm starting to understand how you use it lifeless
<bpierre_> LarstiQ: yeah, just syntaxic sugar
<bpierre_> :P
<LarstiQ> bpierre_: exactly
<jam> lifeless: consider if we have packs of 10*9, and one of 1, and then we fetch another pack of 19. This will trigger an autopack, and try to create a pack of 100, 10. It can fill the 100 one from all the large packs
<jam> and the size 1 pack gets "promoted" to size 10, but there is nothing else to put in with it
<jam> Anyway, I'll poke at it more, but I think it is something worth trying out.
<awilkins> I think BB needs some work. 'tis down again. Does it do many hardworking things?
<bpierre_> so you create a repo, with x no tree branches, and then you work with one checkout of those branches, which you can then switch depending on your activity, right?
<awilkins> bpierre_: That's it
<bpierre_> thanks
<bpierre_> :D
<awilkins> bpierre_: Rather the same as git, only the branches are out there in the filesystem for you to look at
<bpierre_> yeah
<awilkins> (can git do hierarchical branch organization by the wa?)
<fullermd> I don't think as such, but you can mostly fake it via naming.
<lifeless> jam: ok.
<lifeless> jam: it may help to simplify things there, I realised a while ago that autopack should be a little simpler.
<fullermd> We fake naming via hierarchy; they fake hierarchy via naming   ;)
<awilkins> fullermd: You can just move those folders around, right?
<bpierre_> and if I want do to a daggyfix, I can just push -r to clone at a revision, and switch to it, than back to where I was, and merge?
<awilkins> fullermd: As long as they stay in the repo?
<lifeless> jam: specifically, rather than going for N packs of specific sizes, when we were past a pack boundary, it should (still using the 1, 10, 100 etc logic - thats fine), just calculate the ones it wants to combine, and output one single big pack
<fullermd> In bzr, you mean?  Sure.
<lifeless> jam: e.g. rather than making a 100, and a 10, it would just make one of 110
<jam> lifeless: sure
<awilkins> Only thing it screws with is the bindings
<Odd_Bloke> D'oh, poolie's not around.
<jam> lifeless: triggered it
 * fullermd scampers off to a meeting.
<jam> now I need a simpler test case :)
<lifeless> bbiab, food
<poolie> hello
<Odd_Bloke> poolie: Hey.
<poolie> hello
<Verterok> poolie: hi
<jam> lifeless: instructions on how to get it to fail easily are on bug #242510
<ubottu> Launchpad bug 242510 in bzr "Pack already exists when pushing/autopacking" [High,Confirmed] https://launchpad.net/bugs/242510
<Odd_Bloke> poolie: I'm afraid I can't really chat now. :(
#bzr 2008-09-19
<poolie> Odd_Bloke: i'll look for your mail and reply then
<Odd_Bloke> poolie: Sure, just grabbing your key to encrypt it now.
<Odd_Bloke> GPG - fun for all the family.
<GaryvdM> Hi - How can I revert changes made by a revision in my wt?
<GaryvdM> Not revert to a revision
<poolie> undo just some of the changes?
<GaryvdM> Undo the changes by a revisions, but the the changes by subsequent revisions
<GaryvdM> *Undo the changes by a revision
<poolie> try something like 'bzr merge -r 10..9'
<GaryvdM> ok
<GaryvdM> Thanks poolie - That worked.
<Odd_Bloke> poolie: Sent.
<bpierre_> well, that little conversation about switch was a real eye opener, I can't beleive I skipped this section in the manual... thanks for your answers
<bpierre_> bye
<markh> jam: any hope still of getting the plugin localizations included with 1.7?
<poolie> abentley, bb seems to be down...
<abentley> poolie: restarted
<poolie> thanks very much
<GaryvdM> ping lifeless
<jam> markh: I suppose I could force it. Though it would be nice if we could get poolie or spiv to review it and also approve.
<jam> It is small enough that I would be okay with bringing it in post rc2
<GaryvdM> jam: could you give me any pointers to try figure out why get_parent_map is slower when passing all revisions in one go?
<lifeless> GaryvdM: hmm?
<lifeless> call to all devs: please give my readdir branch a spin
<GaryvdM> lifeless: same question as jam :-)
<lifeless> GaryvdM: lsprof
<GaryvdM> ok
<lifeless> also try a btree based repo and see if that handles it more gracefully
<poolie> jam, i'll try to look
<GaryvdM> ok
<GaryvdM> lifeless: Sorry - how do I create a btree based repo?  None of the formats in "bzr help init" mention btree?
<markh> lifeless: recall how you suggested I set sys.platform to "win32" so linux can run the same tests?  The problem is that osutils, and probably others, do win32 specific things at *import* time - eg, osutils.abspath is set to a linux or windows specific version as osutils is imported.  Thus, as Ian noticed, the tests fail on Linux.  What do you suggest?
<lifeless> markh: oh
<lifeless> markh: bummer :P, I guess, disable it then
<markh> ok cool
<lifeless> GaryvdM: the index2 plugin has the code, though its a little bitrotted;
<jelmer> markh: hi!
<markh> jelmer: hi!
<markh> jelmer: you get a build related patch from me?  I *think* I remembered to send one...
<jelmer> markh: No, what was it about?
<jelmer> markh: bzr-svn on Windows? (-:
<markh> bummer.  libsasl.dll needs to be included for 1.5
<markh> svn 1.5
 * markh looks
<jelmer> markh: what address did you send it to?
<markh> jelmer at samba.org, sent tuesday
<markh> try again to that addy?
<igc> hi all
<markh> g'day ian!
<igc> markh: hi
<igc> markh: re your win32utils patch, it needs a tweak too
<markh> igc: thanks for the review of that patch - but that lifeless character led me astray ;)
<beuno> hi igc!
<igc> hi beuno
<markh> igc: you referring to the transport abspath patch?
<lifeless> markh: well the altered code path should be testable; its a nuisance that its not
<markh> lifeless: yeah, I understand and agree with your motivations
<igc> so markh, TestlocationCtypes needs some more protection as it runs (and fails) on Linux
<igc> the os.environ["APPDATA"] bit causes a KeyError
<jelmer> markh: let me just check whether I didn't accidently skip over it
<jelmer> markh: nope - please resend
<igc> markh: get_local_appdata_location() patch
<jelmer> 'morning Ian!
<igc> hi jelmer. How are you?
<markh> igc: right, bummer.  I must remember that my test ubuntu installation is only a couple of clicks away...
<igc> :-)
<markh> I'll quickly fix the transport abspath to simply disable the tests on windows first
<markh> jelmer: sent
<jelmer> markh: also, I was wondering if you could run the testsuite against my IPv6 patch on windows.
<markh> jelmer: why not :)  where is it?
<jelmer> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080830185330.GA22976%40vernstok.nl%3E
<jelmer> igc: Good, thanks!
<jelmer> igc: How are you? It's good to see you around here again.
<markh> jelmer: is there a nice subset of tests I can run to reduce the noise caused by the full suite?
<jelmer> markh: Just the smart server tests should be sufficient
<igc> jelmer: I'm better thanks.
<markh> jelmer: socket module has no attribute AI_ADDRCONFIG on windows :(
<jelmer> markh: does it work ok if you exclude AI_ADDRCONFIG?
<markh> jelmer: "smart.*server" runs 27 tests and they all pass now.  How to remove that flag from server.py and medium.py
<markh> s/How/Had/
<jelmer> markh: Cool, thanks.
<markh> just "selftest server" runs 42 and they all pass too :)
<markh> igc: I resubmitted the transport_abspath patch which skips the test on non-windows.
<igc> markh: thanks
<GaryvdM> Hi lifeless. I unfortunately get the following error: http://pastebin.com/d78fe14ad
<GaryvdM> I attached a debugger, and format_registry.register_metadir is being called twice
<lifeless> interesting
<lifeless> is the plugin loading correctly?
<GaryvdM> no
<lifeless> well, thats probably the cause of the double-registration
<GaryvdM> It seems that that error is being thrown when the plugin is loading
<lifeless> I'll see if I can peek later today, but trying with bzr 1.6 might let it load properly
<GaryvdM> ok
<lifeless> no, that error is during arg processing
<lifeless> oh cool - http://www.datadictionary.nhs.uk/  uses bzr
<lifeless> awilkins: do you know more about them ?
<mwhudson> blink
<GaryvdM> lifeless: It's because I don't have pybloom installed :-)
<lifeless> if you hack the plugin up a bit
<lifeless> you can use the btree implementation in bzr.dev
<lifeless> (rather than the one in the plugins btree_index module
<jelmer> lifeless: from what I understand, awilkins works for NHS :-)
<lifeless> jelmer: ah
<markh> igc: thanks for the review, and I should try to proof-read better :(  I'm still confused by the 'tweak' thing though - who will/should fix that typo in the comments?
<igc> markh: I will when I merge it to pqm
<lifeless> markh: tweak technically means 'ok to merge with no more review but the changes done'
<markh> lifeless: yeah - but sometimes I'm not sure if I'm being asked to make the tweak and resubmit, or someone else will...
<lifeless> markh: if you don't have merge access, then I'd say you still should make the changes yourself, but you could just ping someone on IRC to land it (or send it in again with a note saying 'all reviewed this is the tweaks')
<markh> especially as the person saying 'tweak' might not be the person submitting it to PQM IIUC
<lifeless> right
<igc> markh: we do overload tweak to mean two things ...
<markh> lifeless: yeah, I don't have merge access, so I think I'll assume I should resubmit with the tweaks unless I can convince a sucker to tweak and land for me :)
<igc> 1) another review not required
<igc> 2) small changes needed before merging
<lifeless> igc: I don't see that as overloading :). We have could represent it as multiple bits in a bitfield, but symbolic names are easier :P
<igc> markh: if I ever vote tweak but ask you to do the tweaks, it's my polite way of saying you can probably tweak it better than I can
<igc> markh: in the case of fixing a comment, I'm sure I have the intellect to manage that myself :-)
<igc> lifeless: if you're ok with markh's resubmitted patch, I'll tweak and land it
<mwhudson> jam: yay for figuring out https://bugs.edge.launchpad.net/bzr/+bug/242510
<ubottu> Ubuntu bug 242510 in bzr "Pack already exists when pushing/autopacking" [High,Confirmed]
<markh> so now all we need is a story for the LockContention failure noise on Windows and the test suite there will be looking good!
<lifeless> igc: poolie has acked I think
<lifeless> markh: if I vote tweak, I expect the author to tweak
<markh> igc: good to see you back again :)  How are things?
<lifeless> markh: which FWIW is the safe default for you to assume :P
<markh> lifeless: so I hope you understand my slight confusion ;)
<lifeless> markh: I think its due to igc being helpful
<igc> markh: I'm better today. Still some pain but nothing like before
<markh> damn helpful people!
<markh> igc: good.  the treatment getting easier?
<igc> markh: treatment stopped for now; surgery in early Oct is next; recovery before then
<poolie> hello igc
<igc> hi poolie!
<markh> jelmer: that mail arrive?
<jelmer> yep, thanks
<jelmer> markh: I've merged it
<markh> jam: that patch for the plugin l10n files has actually got 2 approve votes already.
<markh> 1.7rc2 binaries for windows are now up on launchpad
<markh> Also FYI, http://bazaar-vcs.org/TortoiseBzr has some recent Tortoise screen-shots from Vista and is looking quite pretty :)
<thumper> markh: OMG, the UI refers to creating a stacked branch
<thumper> markh: I do question the (possible) default of making a checkout
<markh> thumper: is the stacked branch thing good or bad? :)
<thumper> markh: is the revno really 0.0.1dev?
<thumper> markh: surely we could have a bigger number :)
<markh> yep :)  Probably should be 0.0.2.dev now ;)
<thumper> markh: kinda good
<thumper> markh: but more to explain to the users :)
<thumper> markh: looks very pretty though
<thumper> markh: good work
<markh> thanks!
<thumper> blog now please :)
<markh> lots of the prettiness is qbzr
 * markh needs to get one of those new-fangled blog thingies...
<GaryvdM> Nice markh!
<markh> I just recently landed a nice change so we can easily have those 'links' on the form display a popup help window with any bzr topic formatted as reasonable html, which is nice.  All 'revision number' boxes can have a link that explain the revision number formats, for example.
<markh> ack - but I just noticed the binaries don't have docutils so things aren't as pretty as they could be :(
<GaryvdM> markh - just want to nudge you to Bug #271983
<ubottu> Launchpad bug 271983 in qbzr "Error writen to concole when clicking on "branches" link in qinit" [Undecided,New] https://launchpad.net/bugs/271983
<markh> GaryvdM: ack - I must have missed that.  Do you have any idea what it does mean?  I'm guessing localizations?
<markh> WFM obviously
<GaryvdM> I was hoping it was something you missed. I'll debug.
 * markh just twigges GaryvdM is qbzr's Gary - hi!
<markh> twigged
<GaryvdM> Hi!
<markh> GaryvdM: what do you think in principle of those large changed I recently mailed about?
<GaryvdM> I haven't got my head around them yet :-(
<GaryvdM> I did pull the branch and gave it a test run - And I could not see any problems :-)
<markh> fair enough :)  I think being able to use the signal/slot editor is a nice feature, as is the abaility to have the form at runtime look much more likje it does in qtdesigner.  I'm happy to negotiate the actual impl obviously though :)
<markh> its very nice to have a checkbox connected to a radio button, so magically the checkbox is only enabled when the radio is - all with zero code :)
<GaryvdM> Oh - Thats cool
<markh> similarly with links - you could add a new help link to any of our forms with zero code.
<markh> just connect the signal with the slot in the editor
<markh> I'm quite impressed with qt
<GaryvdM> That bug is weird. I get it when I run from the command line, but not when I run from Komodo
<markh> the code I copied from blindly indexed via 'foo[0][1]' - ie, had no regard for the fact there might be more than 1.  So that's probably a good option :)  I'll have a look after I eat...
<GaryvdM> It's get 2 help topics because I have the bzrtools plugin installed, which has a command called branches.
<markh> hrm - I have bzrtools 1.7.0 installed too
<GaryvdM> I think we can safely just display the first topic.
<markh> sounds fine to me
<GaryvdM> Ok I'm pushing a fix now.
<markh> thanks
 * igc unch
<stefanlsd> I am playing around with bzr and the merging, and when i merge it gives me a file.moved. How do i get the launchpad / ubuntu functionality where it generated the conflict markers in the same file?
<RAOF> stefanlsd: It's my understanding that what you're seeing happens when you've independently added the same file in different branches, and so bzr doesn't know that they're the same file.
<stefanlsd> RAOF: yeah, i did that.  let me try and modify the contents of the same file after i've merged then...
<spiv> stefanlsd: RAOF is right.  You get foo.moved files when it's a conflict of two different files at the same path.  You get conflict markers within a file when there's a conflict of the contents of one file.
<stefanlsd> RAOF, spiv:  thanks, yeah. i see that now.
<vila> hi all
 * vila off to renew passport
<ngnp> ï»¿hi ... is there document about combining cvs and bazaar ... my project is in cvs ... doing a cvs 'switch-branch' my .bzr was deleted
<ngnp> do I need a shared repo to prevent this or are there other ways.
 * vila 's back
<matkor> Hi ! I upgraded bzr 1.5 -> 1.6.1, during bzr update bzr suggested doing upgrade I did , now I during bzr update I get: bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. ?
<matkor> ah
<matkor> sorry
<matkor> upgrade vs update confusion :)
<bignose> if I don't see a command in the 'bzrlib' package, but I know it's provided by core Bazaar (not a plug-in), how do I find out how to run it programmatically?
<bignose> e.g. 'version-info'
<LarstiQ> bignose: I always start by `vim bzrlib/builtins.py`
<LarstiQ> bignose: version-info specifically is in bzrlib/cmd_version_info.py
<bignose> hmm. so I should 'import bzrlib.cmd_version_info' to get it?
<LarstiQ> bignose: well, it is possible to rund the cmd objects, but often that is not exactly what you want
<bignose> indeed.
<LarstiQ> bignose: depends on what you're doing ofcourse
<bignose> I'm hoping there's a better API to get the output of the command, and specify its inputs
<bignose> (so now I guess my question is specifically about the 'version-info' command)
<bignose> that module exports only the Command class
<bignose> s/class/subclass/
<LarstiQ> bignose: I'd forego the cmd object and directly do builder=format...
<LarstiQ> bignose: are you thinking of specifying a tempate in a file instead of as an argument?
<LarstiQ> template, even
<bignose> yes, potentially
<LarstiQ> bignose: then I request you submit a patch, because I want that too ;)
<LarstiQ> bignose: are these enough pointers for now? If so, I'm going afk for the day
<bignose> LarstiQ: thanks very much, yes
<LarstiQ> cool
<LarstiQ> *runs*
<lifeless> bignose: you _can_ do cmd_class().run_argv(argv), but thats a pretty crude way to reuse code
<bignose> bzrlib.export.export(workingtree.branch, export_dir_path, format="dir")
<bignose> File "/usr/lib/python2.5/site-packages/bzrlib/export/dir_exporter.py", line 38, in dir_exporter inv = tree.inventory
<bignose> AttributeError: 'BzrBranch6' object has no attribute 'inventory'
<bignose> what API should I be using for export? the above doesn't seem to work on a branch as referenced by 'bzrlib.workingtree.WorkingTree.branch'
<james_w> branch.repository.revision_tree(branch.last_revision())
<james_w> that will get you the last committed revision on the branch as a revision tree, and export works on trees
<bignose> hmm. so I know how to get from "arbitrary path somewhere in the working tree" to a WorkingTree instance
<bignose> how do I get a repository?
<jelmer> bignose: WorkingTree.open_containing(path)
<bignose> jelmer: yes, that's the part I know.
<jelmer> that'll return a workingtree instance and path relative to the path in the working tree
<jelmer> bignose: workingtree.branch.repository
<bignose> so I need to do 'branch = workingtree.branch', then 'tree = branch.repository.revision_tree(branch.last_revision())', then 'bzrlib.export.export(tree)'
<bignose> yes?
<jelmer> bignose: yep
<jelmer> bignose: branch.basis_tree() is a shortcut for branch.repository.revision_tree(branch.last_revision()) btw
<bignose> jelmer: excellent, thanks
<bignose> from a branch instance, how can I get the branch root?
<jelmer> bignose: the URL of the branch you mean? branch.base IIRC
<bignose> no, the filesystem path as output by 'bzr root'
<spiv> That's the .basedir of the workingtree.
<bignose> spiv: thanks
<spiv> (Which may be the same as the osutils.local_path_from_url(branch.base) a lot of the time)
<lifeless> or
<lifeless> tree.basis_tree()
<lifeless> if you want the wt's parent rather than the branch tip, which could be different
<awilkins> markh: Ping?
<matkor> Hmmm I upgraded to bzr 1.6.1, done bzr upgrade now, when starting olive (bzr-gtk) bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///home/users/matkor/.bzr/repository/') has no revision ('matkor@laptop-hp-20080918151249-q38r0dgg95jsnhqi',) .. any suggestions ?
<matkor> Hm I had to get back to old (Knit) version of repo ... should I fill bug somehow ?
<matkor> by repo has 119 MB and contains data I do not want make public ...
<gnomefreak> ok something is really wrong with bzr bd :( on first build using -S -sa everything goes into build-area (that is good) now without doing anything to build-area i build without -S -sa and everything gets pulled from build-area and goes into work/ except for source.changes file
<james_w> gnomefreak: -sa isn't a valid option to bd, could you be more specific in what you are doing please?
<gnomefreak> james_w: first build (source or binaries) everything goes into build-area   2nd build (source or bins) everything gets removed from build-area except sources.changes and put into work
<gnomefreak> dir
<gnomefreak> james_w: that is what is causing the cheksum mismatch i showed you earlier
<james_w> gnomefreak: yes, I understand
<james_w> I'm trying to find out where the bug is, are you now saying that it doesn't matter whether the second is without "-S -sa", everything still gets moved?
<gnomefreak> james_w: right that is why ~jjv worked and other one failed
<gnomefreak> failed -- errored on lintian
<james_w> can you give me the transcripts of this happening then please?
<gnomefreak> james_w: i got rid of the build clutter http://pastebin.mozilla.org/539840
<james_w> thanks
<gnomefreak> james_w: np
<james_w> ->mozillateam
<gnomefreak> ok
<gnomefreak> you mean try that command?
<jelmer> join #samba-technical
<jelmer> argh
<beuno> tsk tsk, look at jelmer trying to get people to join his channel...
<james_w> hey jelmer
<james_w> hey beuno
<jelmer> :-)
<beuno> hey james_w!
<james_w> how you guys doing?
<jelmer> Hey beuno, james_w
<beuno> howdy jelmer
 * Jc2k resists jelmers demands
 * beuno is getting ready to go to NZ for a week
<jelmer> beuno, lucky bastard.
<beuno> well, it's 24h flight plus 16h timezone shift
<beuno> I'm not sure how that's going to pan out
<jelmer> a week is not a very long time though  - where are you going there?
<beuno> Dunedin, to visit thumper
<jelmer> ah, Dunedin is nice
<beuno> you've been there?
<jelmer> yeah, a couple of years ago
<jelmer> a friend of mine lives near Dunedin at the coast
 * beuno is impressed
<beuno> brb
<Leonidas> is there a way to create ghost revisions on purpose via the command line?
<jelmer> Leonidas, nope, API only afaik
<Leonidas> jelmer: ok, thanks, so I'll write myself a small helper which does that.
<bialix> jam: hi
<jam> hi bialix
<abentley> bialix: I'm closing down the server you have a unix account on.  If you need anything off it, it's at old.aaronbentley.com.
<bialix> abentley: thank you, but I don;t have there anything. If there still my files, you can delete it
<abentley> bialix: Cool.
<bialix> thanks for the fish
<abentley> bialix: I tried to let you know by email, but your server dropped the message: http://pastebin.ubuntu.com/48368/
<bialix> ukr.net is a free mail server
<abentley> bialix: Okay.  Just letting you know.
<bialix> thx
<abeaumont> hi, i've a svn repo mirror as explained in user guide's 8.2.3 section, which are the commands to have the bazaar mirror synchronized with subversion repo?
<tvainika> Do you know about gnome's bzr mirror (bzr-playground.gnome.org), does it sync changes bi directionally? Can I commit with bzr to bzr-playground, or should I commit my changes with bzr-svn to normal svn.gnome.org?
<beuno> jelmer, do you know?  ^
<jdobrien> i need some assistance resolving a simple conflict with bzr merge
<jdobrien> it's a one line conflict and i know what i want in my new branch
<beuno> jdobrien, so what's the problem?
<jdobrien> the new branch as the proper line it it
<jdobrien> but when ever i remove the <<< >>> and try to commit, it says Conflicts detected ...
<beuno> jdobrien, so, you removed all the >>>, <<<<, and  ====
<beuno> run "bzr resolve"
<jdobrien> ahh!
<jdobrien> bueno: thanks
<beuno> welcome'
<beuno> my turn!
<beuno> anyone know how I can push a branch to a remote server, and create the working tree automatically?
<jdobrien> beuno: can't you just scp the whole folder?
<LarstiQ> jdobrien: bad idea
<jelmer> tvainika, afaik it's one way - pushing to svn.gnome.org should work
<LarstiQ> beuno: push-and-update is not sufficient I presume?
<beuno> LarstiQ, it would, but I'm not sure it creates the working tree the first time?
<LarstiQ> beuno: good question
<beuno> my feeling is no, since the plugin just does the push and updates
<beuno> which will error
<jdobrien> LarstiQ: thanks, i didn't realize all the capabilities of bzr push
<beuno> ok, so next question
<beuno> which I've seen answered a billion times, but can never remember
<beuno> how do I create a working tree from the pushed branch?
<Peng_> beuno: "bzr co"?
<LarstiQ> beuno: what Peng_ said
<beuno> marianom, what Peng_ and LarstiQ said  :)
<beuno> thanks guys
<beuno> that's why I never remember
<beuno> it doesn't make sense to me
<tvainika> beuno: co = checkout just like in svn, cvs or any other "old fashion" vcs, why it doesn't make sense?
<beuno> because I'm within a branch, and I'm checking it out into itself
<beuno> blows my mind for some reason
<fullermd> Sure; you're making a working tree for a branch.  That's what checkout does   :)
<LarstiQ> beuno: this is the other sense
<Peng_> hg uses "hg update" both to change the working tree to an arbitrary revision and to delete the working tree ("hg up null", since it treats no tree and a tree set to the null revision identically). More intuitive, IMO.
<Peng_> Also one command vs. three.
<fullermd> Wow, that sounds utterly insanely bizarre.
<Peng_> Haha.
<Peng_> Both are slightly odd, with "hg up null" and "bzr co", so whatever.
 * Peng_ shrugs.
<LarstiQ> bzr co corresponds to .bzr/checkout/, which is the metadata for the working tree
<fullermd> bzr co never seems odd in the slightest to me.  In CVS, you use 'cvs co' to create a working tree.  In SVN, you use 'svn co' to create a working tree.  In bzr, you use 'bzr co' to create a working tree.
<fullermd> Heck, in RCS you use 'co' to create a working file...
<fullermd> In SCCS, you just kill yourself.
<LarstiQ> :)
<beuno> ah, that makes more sense
<jdobrien> In VSS you kill everyone else...and then yourself
<beuno> "bzr co corresponds to .bzr/checkout/, which is the metadata for the working tree" is what I was looking for
<beuno> thanks LarstiQ
<fullermd> But you fail at killing yourself, because your weapon corrupted itself from being used too many times.
<Peng_> That does make sense, but it still bothers me.
 * fullermd still thinks it bothers you because you had the misfortune to hear the phrase 'bound branch'.
<Peng_> fullermd: Right.
<fullermd> Knowing too much about the underpinings of lightweight and heavyweight and whatnot muddles the issue severely.
 * LarstiQ nods
<fullermd> If you just stick with 'checkout creates a working tree for a branch', and ignore the lower level stuff as trivial implementation issues that don't affect anything else, it's much easier to work with.
<fullermd> I'm a firm believer that overcommunication of that causes a LOT of unnecessary trouble in the user-base.
<fullermd> Doubled and tripled the moment somebody mentions 'commit --local'.
<jdobrien> fullermd: probably better than complete ignorance, such as mine
<fullermd> I'm not sure of that, really.  You don't _need_ to know any of the difference, until you reach below the covers with something like ci --local and unmask it.
<jdobrien> you must have missed my suggestion :-)
<GaryvdM> Hi - We sometimes see a problem in qlog, where the following error is written to the console:
<GaryvdM> UserWarning: LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C:/Documents%20and%20Settings/Gary/My%20Documents/bzr/.bzr/repository/>) was gc'd while locked
<GaryvdM>   warnings.warn("%r was gc'd while locked" % self)
<GaryvdM> What can I do to debug this
<GaryvdM> I've checked that all our lock_read()'s have try: finally: unlock()
<LarstiQ> hmm, no bpierre
<LarstiQ> GaryvdM: all I know is to direct you to spiv ;)
<GaryvdM> Ok
<beuno> and, it's saturday for spiv, so he probably won't be here for a couple of days  :)
<LarstiQ> GaryvdM: only qlog has that?
<GaryvdM> yes
<LarstiQ> GaryvdM: it also happens in bzr selftest runs btw
<LarstiQ> GaryvdM: based on that summier knowledge, I'd say it's either something tests and qlog do the same, or it is a bzrlib problem.
<LarstiQ> GaryvdM: can you reproduce it reliably?
<GaryvdM> Currently
<GaryvdM> In fact I've just realised that it happens when you click Refresh\
<GaryvdM> Which reopens the branch.
<GaryvdM> Now that I realized that - it should be easy to fix :-)
<LarstiQ> GaryvdM: aah :)
<LarstiQ> does anyknow how I can reach bpierre_ other than waiting till he shows up here again?
<jelmer> join #ctrlproxy
<jelmer> argh
<jelmer> not my best day
<beuno> twice, you're borderline spamming!  :p
<emmajane> beuno: You're around. :) I have a question for you...
<emmajane> How did you tag your web site files in terms of release information.
<emmajane> for example: I have just uploaded a series of files for a client to look at. I should probably take a snapshot now so that I can roll back to this point. I don't think I want a branch... but I'm not sure what I want.
<Odd_Bloke> kick jelmer Spamming.
<LarstiQ> Odd_Bloke: I haven't had time to look at testing bisect yet
<jelmer> Odd_Bloke, :-)
 * jelmer waves at beuno, emmajane, Odd_Bloke and LarstiQ 
 * emmajane waves
 * LarstiQ waves at jelmer 
<emmajane> (and that was an open question if anyone else has suggestions :) )
 * fullermd waggles.
<beuno> emmajane, you want to tag the uploaded set of files?
<beuno> the revid is uploaded to a hidden file
<fullermd> I dunno.  Tags are easy and cheap.
<beuno> if you add a tag to the branch
<beuno> you can easily map those two later on if needed
<LarstiQ> emmajane: a tag sounds reasonable
<fullermd> And after all, you can always create a branch from that rev later if you turn out to need a branch.
<beuno> and/or push that specific revision
<emmajane> beuno: I'm just "manually" uploading files at this point because I'm lazy (at least I remembered to bzr init though *grin*). I think it makes sense to have some kind of history that I can roll back to. Normally I rely on my memory and my commit messages. But there must be something more efficient...
 * emmajane nods.
<emmajane> tags are like flags, right?
<emmajane> just sort of a "hello!! over here!" note?
<beuno> emmajane, you mean you didn't use bzr-upload?
<LarstiQ> emmajane: "manual" sounds like more work than I'm willing to do ;)
<emmajane> beuno: I know, I know. :/
<beuno> heh
<beuno> well
<beuno> if you *do* use bzr-upload, the plugin uploads a file with the revid
<emmajane> beuno: I'm already a day late on delivering the specs so I'm amazed I remembered to even think about revision control. It's a start. :)
<beuno> so you know what revision was uploaded
<Odd_Bloke> beuno: Presumably that's overwritten next time the upload happens?
 * Odd_Bloke hasn't even looked at bzr-upload.
<LarstiQ> GaryvdM: you're not going to be in .nl somewhere this year perchance?
<beuno> Odd_Bloke, yeap
 * fullermd has lost count of how many days late he'd be for things if he WEREN'T thinking about revision control   :p
<beuno> there's no history of uploads
<beuno> we'd need to develop a revision control system on top of a plugin for revision control
<emmajane> fullermd: heh
<beuno> (or, just keep on adding the uploaded revs to the current file, which is very cheap and easy, but no fun at all)
<beuno> emmajane, anyway, if you've just uploaded manually
<LarstiQ> beuno: ah, but think about the scalability!
<emmajane> at this point I've uploaded it to /client_name/v1-layout/files.html so that they know they're looking only at the "general layout" .. once they've approved that I'll give them sub-nav.
<beuno> just do:  bzr tag something_to_rmemeber_it_by
<Odd_Bloke> We should write it in C, and really obfuscate the UI.
<Odd_Bloke> Then it'll be _fast_.
 * emmajane nods.
<beuno> and you can come back to that later on
<beuno> bzr tags
<emmajane> Yeah. I think that's what I want.
<beuno> will show you all the tags
<emmajane> for example: bzr tag v1_upload
<fullermd> Odd_Bloke: Obfuscated UI is nice and all, but C is a pain, and fast is overrated.  If you just wrote it in Haskell...
 * LarstiQ cringes at the nested-trees/bzr.dev diff
<emmajane> PS I hate IE...
 * jelmer cheers on LarstiQ 
<beuno> emmajane, we all do  :)
<emmajane> Just thought I'd throw that in there.
 * emmajane grins.
<Odd_Bloke> fullermd: :D
<emmajane> thanks for the suggestions, everyone. :)
<beuno> welcome'
<beuno> and, hurray for LarstiQ finishing nested tree support!
<LarstiQ> hah, that's a bit premature :)
<beuno> :)
<NfNitLoop> ooh, nested tree support.
<emmajane> a tag applies to all files, not just the files in that sub-directory, right?
<NfNitLoop> What sort of support is that?  :)
<LarstiQ> NfNitLoop: lp:~larstiq/bzr/nested-trees
<jelmer> emmajane, yep
<LarstiQ> emmajane: it applies to a revision, so the versions of all files in the tree at that point
 * emmajane nods
<emmajane> and I assume I have to commit after adding a tag?
<beuno> nope
<emmajane> interesting.
<beuno> that's one way of putting it, yes  :)
<emmajane> what happens if there are changed files ... does the tag apply itself to the last commit?
<LarstiQ> beuno: it's a 97k diff, so this will take a while. And then there is fixing the outstanding problems off course. But if you want to help stress test whay I do, please!
<fullermd> The tag points at whatever revision you tell it to point at (which is the last commit if you don't say something else)
 * emmajane nods
<emmajane> again.. "interesting"
<emmajane> tags == flags == bookmarks.
<beuno> LarstiQ, ah, 97k sounds like fun. Another reason to finish the implementation ASAP  :)
<beuno> I'll branch and start poking at it
<beuno> what repo format do I need to use it?
<LarstiQ> beuno: --development-subtree
<beuno> LarstiQ, Format <RepositoryFormatKnit1> for lp-140342092:///~larstiq/bzr/nested-trees/.bzr is deprecated - please use 'bzr upgrade' to get better performance
<LarstiQ> beuno: bpierre was trying it out yesterday, and didn't get it to work. I got the same thing. But today I tried afresh, and it works. Difference: using a repository or entirely standalone (the latter works)
<LarstiQ> beuno: so be warned of that
<LarstiQ> beuno: yeah, I know :)
<LarstiQ> beuno: and nested-trees is probably one of the trees with funky revisions, so I'll need to reconcile it.
<GaryvdM> LarstiQ: No - I live in South Africa
 * LarstiQ nods at GaryvdM 
<LarstiQ> GaryvdM: but that in itself doesn't prevent you from visiting :)
<GaryvdM> Yes
<GaryvdM> I don't think so.
<GaryvdM> I'm not working in IT atm.
<LarstiQ> GaryvdM: ah, ok.
<GaryvdM> Do you know me?
<beuno> LarstiQ, note, need a standalone
<LarstiQ> GaryvdM: nope!
<LarstiQ> GaryvdM: other than from qbzr
<GaryvdM> Ok - was just wondering - cause I worked in Maastricht for a while.
<LarstiQ> GaryvdM: most people from South Africa I know live/work in the Delft area. And the StoneThree people.
<GaryvdM> That is interesting.
<danielfolsom> whenever i try to do bzr launchpad-login Danielfolsom, an error comes up: " https://launchpad.net/%7EDanielfolsom/%2Bsshkeys is permanently redirected to https://launchpad.net/~danielfolsom/+sshkeys "
<danielfolsom> any ideas?
<LarstiQ> danielfolsom: try with daniefolsom instead of Danielfolsom?
<LarstiQ> modulo the l
<LarstiQ> danielfolsom: the point being upper -> lower case
<danielfolsom> omg that did it
<danielfolsom> i'm so sorry
<LarstiQ> danielfolsom: that's ok :)
<danielfolsom> thanks very much!
<LaserJock> I've got a perhaps stupid bzr repo question
<LaserJock> if I've got a repo, and then two branches that are similar, but different depths, will they still share history?
<danielfolsom> does anyone who uses bzr on a mac know if there's a way to update it? And also, would anyone know why bzr would keep freezing up (very consistently)?
<LaserJock> my use case is using bzr svn to get different depths of a SVN repo
<LarstiQ> LaserJock: yes
<LarstiQ> LaserJock: what do you mean with 'different depths' of an SVN repo?
<LarstiQ> danielfolsom: get a newer version of bzr? I'm not a mac user, but doesn't bazaar-vcs.org carry .dmgs?
<LaserJock> what I mean is, the svn repo has a trunk/<project>/ structure
<LarstiQ> danielfolsom: and could you describe the freezing in more detail?
<LaserJock> if I branch both trunk/ and trunk/project/ will the repo know that they share history?
<LarstiQ> LaserJock: bzr init-repo repo; cd repo; bzr branch foo; mkdir deeper; cd deeper; bzr branch bar;
<danielfolsom> LarstiQ: oh ok - and then just another random question - is there any way to uninstall? (just so i know for future reference)
<LarstiQ> LaserJock: foo and bar share history
<danielfolsom> LarstiQ: it just stops about 1/4 of the way through
<LarstiQ> LaserJock: specifically in the case of svn though, they might not have any revisions in common, possibly
<LarstiQ> danielfolsom: on mac? No clue. For me it would be apt-get remove bzr.
<LarstiQ> danielfolsom: I think it's not freezing, but rather taking a long time.
<danielfolsom> LarstiQ: possibly - i'll get back to you after i update - it does say it has to redirect
<danielfolsom> BasicOSX: i assume you use bzr with a mac
<BasicOSX> danielfolsom:  hourly
<danielfolsom> do you know how to uninstall (I'd like to know for the future)
<BasicOSX> I pull from bzr.dev repo
<BasicOSX> I don't use a package or anything like that
<danielfolsom> ahh ok - thanks
<danielfolsom> so just bzr pull bzr.dev repo - and that's it?
<BasicOSX> Look at appzapper, it will do what you want
<BasicOSX> in ~/projects/bzr.dev
<LarstiQ> going out on a limb here, but don't .dmgs have their own uninstall facilities?
<BasicOSX> then I symlink ~/bin/bzr to ~/projects/bzr.dev/bzr
<BasicOSX> and make sure ~/bin/ is first in my path
<BasicOSX> just drag the app into trash that does what you want
<BasicOSX> appzapper will kill all conf files and whatnot
<danielfolsom> haha - that's all a bit over my head
<BasicOSX> osx != windows
<danielfolsom> and i can't actually find the bzr app, so i don't think appzapper will work
<BasicOSX> if installed via dmg should be in /Applications
<danielfolsom> yeah - i can't seem to find it
<danielfolsom> so i guess that means i didn't install via dmg
<LarstiQ> danielfolsom: darwin ports or similar?
<danielfolsom> side question: the way you know that bzr is frozen is if the line stops spinning, right?
<danielfolsom> LarstiQ: idk, sorry - i've never used darwin before i don't think though
<danielfolsom> possibly via svn ... for some reason i just can't find anything
<LarstiQ> danielfolsom: no, the line can spin so slowly that you don't see it moving
<danielfolsom> o ok
<BasicOSX> there is a darwin port, but I haven't used it
<danielfolsom> when i put bzr in the search box i get README.txt, bzr.rb, bzlib.h, and bzlib.h - i don't know why there are two
<LarstiQ> bzlib.h is bz2 compression, nor bzr
<danielfolsom> that's weird - it's still saying i need to update the server to bazaar 1.2, but usng bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev - i thought i just upgraded to 1.5
<Peng_> danielfolsom: Known issue. An RPC was removed in 1.6, so older clients assume the server is older than 1.2.
 * Peng_ just walked in on this conversation.
<danielfolsom> haha no worries
<danielfolsom> actually my real problem is  bzr isn't downloading successfully - it did what i said correctly, but when i do bzr branch lp:getting-down-with - it stops 1/4 of the way through
<danielfolsom> and i don't think that it's that huge of a file
<LarstiQ> /home/larstiq/bin/bzr get lp:getting-down-with  2.39s user 0.40s system 10% cpu 26.783 total
<LarstiQ> it isn't that huge
<LarstiQ> danielfolsom: do you have strace or somesuch?
<danielfolsom> strace? no
<danielfolsom> oh wait! Wow, well it took 10 minutes (13 minutes to be exact), but it finally got it
<danielfolsom> thanks for all your help!
<LarstiQ> danielfolsom: np.
<LaserJock> huh, fascinating
<LaserJock> bzr is really smart
<LaserJock> or maybe I'm just a tad slow ;-)
<LaserJock> but it amazes me that I could create a shared repo, bzr branch trunk/ from an LP code import, and then bzr branch trunk/<project/ from the SVN repo directly
<danielfolsom> ok i have one more question (sorry to keep coming back): is there a way to see what someone did in a specific diff?
<LaserJock> and I lose nothing, each branch only costs me 40KB
<danielfolsom> anyone know?
<fullermd> danielfolsom: What, you mean just from bzr diff?
<danielfolsom> can you use diff to see what someone did in a certain revision? Say revision 177?
<fullermd> bzr diff -c177
<danielfolsom> o sweet - i never knew about that
<danielfolsom> thank you!
<LaserJock> bzr help diff has lots of neat things you can do :-)
<LarstiQ> danielfolsom: you're welcome to stay around, no need to quit :)
<danielfolsom> sweet :)
<LaserJock> LarstiQ: do you know if either possible or done already to have bzr remove unneeded revisions from a shared repo
<LarstiQ> LaserJock: one way is branching to a new repository
<LarstiQ> LaserJock: sorry, I'm falling asleep right now
<LarstiQ> LaserJock: also look at the plugins page
<jfroy|work> w00t
<jfroy|work> I completed Brian de Alwis's work and did the small bit of work left in bzr-svn's ra.c file to enable keychain authentication on Mac OS X
<LarstiQ> jfroy|work: cool!
 * LarstiQ detaches, be back tomorrow
#bzr 2008-09-20
<toojays> Hi bzr people! Can somebody please tell me how to do a partial commit in bzr?
<toojays> If I were using git, I would do "git add -p".
<jelmer> toojays, just specify the path
<toojays> Can bzr do something like this?
<jelmer> toojays, bzr commit <path>
<toojays> jelmer: The changes I want to commit separately are in the same file.
<toojays> One set of changes I will want to merge to another branch, one set I will not.
<toojays> But they are in the same file.
<jelmer> ah, you'd like bzr to prompt you about each chunk of changes?
<toojays> Yeah, I guess that's the only UI I know of to do what I want.
<fullermd> I think somebody wrote a plugin...   bzr record or something.
<fullermd> You could also use shelve to set aside the bits you don't want, commit, then bring them back.
<toojays> Shelve . . . yeah, that sounds like a workaround I could use.
<toojays> This makes me think . . . is there a page for people coming to bzr from other dvcs systems, which compares how to do similar operations?
<toojays> I have been using git a lot at work, but am using bzr at home . . . so I'm pretty fluent with git, but have only been doing "easy" stuff with bzr so far.
<fullermd> Well...  the people wanting that particular thing are usually the darcs people   ;)
<fullermd> Hence 'record'.
<fullermd> Ah, 'interactive'.  Renamed post-loom, I guess.
<fullermd> https://launchpad.net/bzr-interactive
<toojays> fullermd: thanks, that sounds like it will do what I want.
<markh> jelmer: bzr-svn is still reporting as '0.4.13dev0' - is that likely to change for a 1.7 release?
<planetcalls> hi. I am pretty new to bazar. Mini tuts on website show command line way of doing things. Do we have any UI or shell hooks like SVN for bazar ?
<mlh> for windows or linux?
<mlh> there's a few in progress
<mlh> check the website
<mlh> there's TortoiseBZR in progress, specifically for windows
<markh> planetcalls: if you are on windows, try the 1.7rc2 build rather than 1.6 - the GUI stuff is much more polished there.
<mlh> there you go -- straight from the source :-)
<markh> :)
<planetcalls> markh, thanks. From the examples and documents it seems as if bazar is having only the command based binaries.
<markh> planetcalls: its very much a current work in progress, so the examples and docs lag a little still
<markh> planetcalls: but that also means it is so new that there are issues and things not implemented. It is no where near as mature as TortoiseSVN yet.
<markh> its functional though
<planetcalls> yea that is obvious. I am not going to give up Tortoise anytime soon but wanted to give distributed vcs a try
<planetcalls> just found TortoiseBzr....sounds it would be easier to adopt bazar in near future
<markh> planetcalls: yeah, the most recent TortoiseBzr is in the bzr 1.7rc2 binary on launchpad
<markh> planetcalls: but it also includes a plugin which allows you to use a GUI from the command line - eg, "bzr qci" will show a graphical version of "bzr ci" - ie, to do a checkin
<planetcalls> ok thanks......now downloading
<_zou> after command "bzr update", I got following messages:
<_zou> Unable to obtain lock file:///cygdrive/d/work/OpenSrc/gnash_bazaar/trunk/.bzr/branch/lock
<_zou> locked 37 hours, 51 minutes ago
<_zou> Will continue to try until 13:00:39
<_zou> anyone knows how to solve this?
<markh> _zou: 'bzr break-lock'
<markh> _zou: but you should probably also upgrade your bzr to a non-cygwin one - one of the 1.6 or 1.7 binaries would be good.
<_zou> thanks, trying now.
<_zou> does it work on windows?
<_zou> 'bzr break-lock' works, update again now.
<markh> _zou: yeah, 1.6 and 1.7 builds for windows are looking good.
<markh> if that is what you were asking :)
<_zou> thanks, I'll try it later.
<_zou> 'bzr update'
<_zou> now it prints '/ 0/0', and no progress.
<_zou> is there anyway that I can check if the connection is successful?
<_zou> connection to bzr server.
<_zou> no timeout message, no error message, 'bzr update' just stalled.
<markh> _zou: it can sometimes appear to do that.  Check .bzr.log and you might see activity
<markh> in your "my documents" folder
<markh> but let it go - the problem is in the progress reporting rather than anything more serious
<markh> I actually opened a bug on that - it mentions the 'branch' command but I think its the same - bug 264615
<ubottu> Launchpad bug 264615 in bzr "progress bar for pull does nothing until near completion" [Medium,Triaged] https://launchpad.net/bugs/264615
<markh> (oops - mentions 'pull' :)
<_zou> markh: yes, I found the file under "my documents", but no message for today.
<_zou> There are some old messages.
<markh> hrmph
<markh> 'up -v' might help - but I'd let it go in the hope it actually working
<markh> obviously not forever, but many minutes isn't unusual if there are many revisions to pull.
<_zou> I wait a whole morning last time, still no progress or unfinished. Then I used "ctrl + C" to break the command. That's why I need the 'bzr break-lock' command today.
<_zou> yes, there are many revisions.
<_zou> I haven't update for a long time.
<markh> hrm - 'up -v' might give some insight, but it might not :(  if its connecting via ssh it might be strangeness related to that somehow
<_zou> markh: "bzr up -v" also printed "- 0/0" and stalled here.  Thanks anyway, might be a network problem here.
<Leonidas> hi
<Spaz> hello
<Leonidas> chich change is needed so that I get a file called 'TREE_ROOT' in iter_changes?
<Leonidas> s/chich/which/
<Leonidas> I see that the empty path has the id TREE_ROOT, but how to make a change to the empty path that is tracked using bzr?
<mwhudson> you don't, i think
<Leonidas> mwhudson: so why bzr.dev has such changes?
<mwhudson> maybe i think wrong then :)
<mwhudson> but bzr.dev has a long and rather more ... eccentric ... history than most branches
<mwhudson> (like having a revision with revid "A")
<mwhudson> Leonidas: i guess you can look at the revisions in bzr.dev that appear to modify TREE_ROOT, right?
<Leonidas> mwhudson: I currently don't know how to do it, but hmm, that is probably the way to go.
<mwhudson> there is a way to find "all revisions touching a file"
<mwhudson> i forget what it is though, i guess read the log code
<Leonidas> mwhudson: the point is, if I can process bzr.dev properly, I shouldn't have any problem with bzr repos in general :)
<mwhudson> Leonidas: ah :)
 * Leonidas checks the cmd_log
<mwhudson> grunk, i always forget how horrible the log code is
<Leonidas> show_log(bzrdev, lf, specific_fileid='TREE_ROOT') doesn't show anything. *sigh*
<mwhudson> yeah, there seem to be inconsistencies around
<Leonidas> that wouldn't be a big problem, if my stack would be correct, but somehow I only get one frame in pdb.
<mwhudson> yay generators!
<LarstiQ> Leonidas: there is tree.set_root_id()
<LarstiQ> Leonidas: I'm not entirely sure what you're asking about
<LarstiQ> Leonidas: and things like bzrlib.transform.adjust_root_path
<LarstiQ> Leonidas: take care with the transform code though
<clemente> The preferred way to convert from git to bzr is still fastimport, isn't it?
<Odd_Bloke> clemente: I believe so, yes.
<Odd_Bloke> bzr-git might work, but I don't know.
<Pieter> or git-bzr, but that just uses fastimport
<clemente> ok. Apparently development for bzr-fastimport is stuck since 2 months :-(
<Odd_Bloke> clemente: Why's that a problem?  It works.
<clemente> Not for me; I have bug 238365
<ubottu> Launchpad bug 238365 in bzr-fastimport "Symbolic links to files with names in UTF-8 (Unicode)" [Undecided,New] https://launchpad.net/bugs/238365
<clemente> I'd like to fix it but I don't know where to start
<Pieter>     ie.symlink_target = data.encode('utf8')
<Pieter> just change that to ie.symlink_target = data
<Pieter> or so
<clemente> Then all data will be stored in binary, even if it contains Â¬utf-8 or even invalid utf-8 sequences
<clemente> I don't know if that is allowed in bzr; but I think that git allows git
<clemente> *it :-)
<Pieter> a symlink is a symlink, it doesn't have any encoding specified.. I don't know why you'd try to convert it to utf-8 anyway
<clemente> Why does data.encode('utf8') fail if data is aleardy utf8? Is it trying to a double conversion?
<LarstiQ> without looking at the code, I'd say that is because it's data supplied from the user environment
 * LarstiQ looks at the code
<clemente> Mmm... if fastimport leaves the data as it is, then bazaar complains later:
<clemente>   File "/w/bzr/bzr.dev-oficial/bzrlib/dirstate.py", line 1862, in _inv_entry_to_details
<clemente> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 1: ordinal not in range(128)
<clemente> And the problem is really in Bazaar: bzrlib/dirstate.py, 1860:
<clemente>         elif kind == 'symlink':
<clemente>             # We don't support non-ascii targets for symlinks yet.
<clemente>             fingerprint = str(inv_entry.symlink_target or '')
<clemente> I will report a new bug on that and link the old similar ones to it
<clemente> bug 272444
<ubottu> Launchpad bug 272444 in bzr "Support symlinks to non-ascii file names" [Undecided,New] https://launchpad.net/bugs/272444
<clemente> Pieter: bzr refuses to store just any string in the original character encoding, and tries to convert everything to Unicode instead
<clemente> From bug 59968: â This root cause of this problem is that we store this data in XML, and XML1.0 doesn't permit most ASCII control codes. â
<ubottu> Launchpad bug 59968 in bzr "add should refuse bad filenames" [Medium,Confirmed] https://launchpad.net/bugs/59968
<clemente> So ie.symlink_target = data would be wrong and   ie.symlink_target = data.encode('utf8') better
<Pieter> messing up filenames just because your backend doesn't support the real data sounds wrong
<clemente> There are lots of Unicode bugs in Bazaar...
<clemente> LarstiQ: you said that it did data.encode('utf8') because it comes from the user. Would it be better to âconvert it to utf8 only if it is not already utf8â?
<LarstiQ> clemente: eh no, you can only encode unicode, encoding an already encoded string doesn't make sense
<clemente> Or âtry to convert it to utf8, but if it fails with an exception, leave the data intactâ
<Pieter> clemente: that last part already happens somewhere else in fast-import
<LarstiQ> clemente: so if it's utf8, and then you try to encode utf8, something is wrong
<LarstiQ> Pieter: it's not messing up filenames, it's being able to reproduce them
<LarstiQ> which, without extra provisions, clashes with being able to store arbitrary binary streams
<Pieter> can't you just base64 them?
<clemente> LarstiQ: so a try+catch around that conversion would be needed to prevent the wrong conversion
<clemente> try+expect actually
<clemente> except !
<LarstiQ> Pieter: that's not the point, Linux treats its filesystem paths as binary data, others don't
<LarstiQ> Pieter: so you need to know what encoding a filename is in, or you are not able to check it out everywhere
<LarstiQ> clemente: no
<LarstiQ> clemente: in general, the entire pipeline should be: data from environment -> decode into unicode, live in unicode in the entire system -> encode on the way out
<LarstiQ> clemente: there should be no mixing of encoded and unencoded data within
<LarstiQ> Pieter: now, some people don't care that you can't check it out, they just want to store a binary stream and tough luck if it fais somewhere else
<LarstiQ> Pieter: that should be possible
<Pieter> yeah.. that seems the right way to go
<LarstiQ> well
<LarstiQ> it gives rise to working trees that only work in certain corner cases, which is a bad thing
<LarstiQ> Pieter: the root cause here being that the common denominator doesn't allow that
<clemente> But both modes are incompatible
<LarstiQ> clemente: bug 59968 shouldn't be relevant anymore
<ubottu> Launchpad bug 59968 in bzr "add should refuse bad filenames" [Medium,Confirmed] https://launchpad.net/bugs/59968
<LarstiQ> clemente: at least the xml part
<LarstiQ> hi Guest25912
<LarstiQ> clemente: so just fix 272444
<clemente> LarstiQ: How? I think two modes are needed, configurable by the user. Some people would like âdon't change my encoding, leave the data as it is even if it later fails somewhere elseâ and others âplease make that my data is available everywhere without encoding problemsâ
<LarstiQ> clemente: your use case of tres should work perfectly fine with the latter, we _know_ the encoding
<LarstiQ> clemente: if we know the encoding, there is no problem
<LarstiQ> clemente: the problem arises when we do not know the encoding of binary data
<clemente> So the problem is not knowing the encoding used to store the target of a symlink
<LarstiQ> clemente: that's a problem, not your problem. If you look at the git-fastexport output you'll see it declares the data to be utf8 encoded
<Pieter> LarstiQ: only the commit messages afaik
<LarstiQ> link to a file with a name in utf-8
<LarstiQ> Pieter: ^^ that's in 'expo'
<Pieter>               It is recommended that <path> always be encoded using UTF-8.
<Pieter> that's in the manpage
<LarstiQ> Pieter: right, I just looked at the output of clemente's series of git commands
<LarstiQ> clemente: if you try without the symlink, it works fine, right?
<clemente> LarstiQ: I think so
 * LarstiQ commented out the git add prova, and that works
<LarstiQ> clemente: so the concrete problem bzr problem we're dealing with is an (now) arbitrary limitation on symlink targets
<LarstiQ> hmm, maybe not
<LarstiQ> clemente: if I add the symlink and commit it in bzr, it works. Branching that branch however does not.
<Pieter> LarstiQ: that path is only utf-8 in the git output because it was stored as utf-8
<LarstiQ> clemente: so some parts allow it, others don't.
<LarstiQ> Pieter: right, and I'd like to solve clemente's specific problem without tackling the larger issue
<LarstiQ> that is a wee bit more work
<Pieter> LarstiQ: by assuming it's utf-8?
<LarstiQ> Pieter: by being told it is utf-8
<LarstiQ> Pieter: which is true in clemente's case
<clemente> So the problem is in branch, not in add,rm,log,... A simpler testcase is: mkdir br1; cd br1; bzr init .; touch mÃ©s; ln -s mÃ©s prova; bzr add prova; bzr commit -m "link to utf-8 file name"; cd ..; bzr branch br1 br2
<LarstiQ> clemente: right
<LarstiQ> clemente: can you write a testcase for that?
<LarstiQ> a bzrlib/tests/ testcase that is
<clemente> LarstiQ: I'll try that in a while, yes (first I'll need to make them run)
<LarstiQ> clemente: ./bzr selftest <pattern>
<clemente> ok, that was easy :-)  (Although there was no documentation on bzrlib/tests/ explaining how to run them)
<clemente> or how to run all
<clemente> ./bzr selftest
<clemente> well, that was also easy... only it wasn't documented there
<LarstiQ> clemente: bzr help selftest?
<LarstiQ> that, or the developer documentation
<clemente> Yes, but I saw lots of tests in the bzrlib/tests/ and didn't know how to run them :-)
<clemente> Maybe a README or INFO helps there
<clemente> bzrlib/tests/INFO, I mean
<clemente> I'll work more on this later, and write or extend some tests for utf8
<LarstiQ> luks: qannotate is nice!
<LarstiQ> luks: and qbrowse!
<LarstiQ> Odd_Bloke: hmmm, something funny is going on when I bisect run, it seems to keep repeating going back to the tip
<LarstiQ> ho hum, why was ie.get_tar_item deprecated
<Guest55688> LarstiQ, it sucks
<LarstiQ> jelmer: the removal sucks, or the function sucks?
<LarstiQ> jelmer: or your nick change sucks?
<jelmer> LarstiQ, get_tar_item can't provide a last modification time
<jelmer> LarstiQ, which caused issues exporting the same .tar.gz file for the same revision
<jelmer> LarstiQ, not sure if that's the reason it was deprecated though
<LarstiQ> jelmer: I don't think that's fixed now though
<LarstiQ> item.mtime = now
<LarstiQ> jelmer: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/44475/focus=44476
<LarstiQ> jelmer: but now it seems the exporter code suffers from duplication
<jelmer> LarstiQ, that was there before too, but it means you have to pass in "now"
<LarstiQ> jelmer: mkay
<LarstiQ> at least I only have to fix _export_iter_entries() once
<LarstiQ> right, back to the bzrlib/merge.py conflict
<fdv> does anybody know whether (and possibly how) "shallow" checkouts / branches are supported in 1.6? I believe I heard they would be
<uws> fdv: I think the name is "stacked"
<LarstiQ> yup
<LarstiQ> fdv: see --stacked on branch and push for instance
<fdv> right
<fdv> but it depends on the availability of it's parent branch for all operations, according to the docs
<fdv> do you know if bzr-svn supports it?
<fdv> heh. seems to :)
<LarstiQ> fdv: should only be the case for operations which it doesn't have the revisions itself for
<fdv> ah, ok
<LarstiQ> fdv: iirc for bzr-svn the layering wasn't entirely right
<fdv> oh
<LarstiQ> but it's been a while since I asked jelmer about it
<fdv> the bzr-svn faq recommends it
<LarstiQ> really? Then I guess he fixed it :)
<fdv> (http://samba.org/~jelmer/bzr-svn/FAQ.html#cloning-a-large-subversion-branch-is-very-slow)
<fdv> now I've just got to hassle the svn guys to upgrade to 1.5, then the world will be a better place :)
<LarstiQ> fdv: any idea how large of a difference upgrading to 1.5 makes?
<fdv> LarstiQ: nope, just read what that faq said :)
<fdv> it took a week to clone the 1.4 repo to bzr, can't be worse than that ;)
<fdv> LarstiQ: if and when I figure it out I can try to remember to let you know
<LarstiQ> fdv: yes please, I could go badger some of my svn admins then ;)
<fdv> :)
<fdv> LarstiQ: svn 1.4 is so broken that there should be ample reason in itself, afaik
<fdv> merging support is paramount, imo
<fdv> (*working* merge support, that is)
<LarstiQ> I haven't had cause to use it on svn, I heard there is this one python script you need to accomplish it with 1.5?
<fdv> with 1.4 you can use svnmerge
<fdv> it's supposedly fixed in 1.5
<fdv> LarstiQ: have you tried cloning the repo from 1.4?
<LarstiQ> ok
<LarstiQ> fdv: with bzr? Yes, although not the entire repository, but projects within it.
<fdv> right
<fdv> hm. it might seem to be issues with stacked branches from svn
<fdv> no matter what type of repo I init, (I tried --1.6.1-rich-root, --rich-root-pack, and --subversion), the result is the same
<fdv> bzr reports that it uses RepositoryFormatKnitPack5RichRoot for stacking
<fdv> (after a branch command)
<fdv> then it says that SvnRepository('<svnurl>') is not compatible with KnitPackRepository('local-repo-path'), different serializers
<fdv> does this sound familiar to anybody?
<dlee> When I push to a bzr+ssh branch or commit when bound to it, is there yet a way to have it email people about my push or commit?  The bzr+ssh branch is on a Unix (FreeBSD) system I control.
<fdv> uhm. I had a slightly old version of bzr-svn, sorry about the hassle
<alefteris> trying to push over sftp and i get "bzr: ERROR: Permission denied: "/blog": [Errno 13] Permission denied"
<alefteris> what can i do to see what is wrong?
<alefteris> does the directory need any special permissions?
<alefteris> nevermind, solved it
#bzr 2008-09-21
<jml> $ bzr push sftp://<hostname>/<path>
<jml> No revisions to pull.
<jml> wtf?
<Spaz_> did you specify trunk/ perhaps?
<Spaz_> :)
<jml> It's the "pull" bit that weirds me out.
<lifeless> jml: using  loom?
<jml> yeah.
<lifeless> bug xxxxx
<lifeless> (its open)
<jml> it took me a while to figure out it was a loomified branch
<jml> export-loom ftw
<libwilliam> I'm working on parsing the bzr error messages in my program. I can't seem to find if there is a standard way of doing error messages in bzr. Do all error messages start with "bzr: ERROR: "?
<jml> lifeless: can you merge my testresources branch please?
<spiv> libwilliam: pretty much.  See bzrlib.trace.report_exception
<libwilliam> spiv: thanks
 * emmajane waves.
<emmajane> I wanted to give the bzr_upload plugin a try, but it doesn't seem to want to load.
<emmajane> I've downloaded it from launchpad and run the setup.py script, but I'm still getting:
<emmajane> Unable to load plugin 'bzr_upload' from '/home/emmajane/.bazaar/plugins'
<alecwh> Hello, can bazaar commit to a repository through the FTP protocol?
<alecwh> push*
<alecwh> And is it possible to grab the latest working version of a repository - not the entire history?
<emmajane> alecwh: yes you can use FTP.
<alecwh> emmajane: how would the command look, with a username and password, and can I get bzr to save the location, so I don't need to type it each time I want to push?
<emmajane> I believe it's just: bzr push ftp://username@ftpserver
<alecwh> emmajane: yes, but I have a password too.
<emmajane> does it not prompt you for a password?
<alecwh> emmajane: I haven't tried yet, I just assumed there was another variable to set.
<alecwh> thanks!
<emmajane> I think it should just work.
<emmajane> alecwh: try also: bzr help
<emmajane> and bzr help <command name>
<emmajane> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
<alecwh> emmajane: thanks
<emmajane> did it work?
<alecwh> emmajane: really sorry, haven't tried yet (not at my computer), I'll get back to you later though
<emmajane> np
<Kamping_Kaiser> can someone suggest a tool to keep track of bzr branches? (other then LP...)
<mwhudson> Kamping_Kaiser: keeping track in what sense?
<Kamping_Kaiser> mwhudson, via a web interface, as i recall (sorry, i wasnt clear)
<mwhudson> Kamping_Kaiser: there's loggerhead
<nosklo> I am having trouble using bzr-svn plugin. Tried both ubuntu hardy package and trunk version. Ubuntu hardy package segfaults on bzr selftest svn.
<mwhudson> it can browse directories now, so you can just point it at the directory containing all your repos, for example
<Kamping_Kaiser> mwhudson, thanks, i'll go and check it out
<fdv> nosklo: have you tried installing the most recent bzr-svn locally (in ~/.bazaar/plugins)?
<fdv> that bit me yesterday
<nosklo> fdv, using ubuntu package bzr + recent bzr-svn?
<fdv> nosklo: what was the question?
<nosklo> fdv, getting bzr-svn to work somehow
<fdv> nosklo: yes, but what did you just ask me?
<fdv> whether I use "ubuntu's" bzr and not ubuntu bzr-svn?
<nosklo> fdv, I can't make it work. I have tried: installing bzr and bzr-svn packages, and installing bzr.dev and bzr-svn trunks
<fdv> ok..
<nosklo> fdv, I am asking if maybe combining the package with the trunk
<fdv> which bzr version?
<fdv> nosklo: if you get your packages from http://ppa.launchpad.net/bzr/ubuntu it seems to me you _should_ be fine
<nosklo> fdv, I will try.
<fdv> nosklo: otherwise, check which bzr version you have and compare to http://bazaar-vcs.org/BzrForeignBranches/Subversion#releases
<fdv> I have bzr 1.6.1 and bzr-svn 0.4.12, which at least to me seems to be a combination that works
<fdv> uhm.. pqm depends on config-manager, which in turn depends on pybaz. the latter is no longer in use, is it?
<Leonidas> hi
<Leonidas> could someone take a look at the changes between aaron.bentley@utoronto.ca-20070517163555-3i7jamitmffdg85l and aaron.bentley@utoronto.ca-20070611021058-7mqy4fsayv27zper
<Odd_Bloke> Leonidas: Umm, in what context?
<Leonidas> Odd_Bloke: there is a change with the fileid TREE_ROOT and I'd like to ask someone what that means.
<Odd_Bloke> Leonidas: In what branch?
<Leonidas> Odd_Bloke: bzr.dev
<Odd_Bloke> Right, that's all I was looking for. :)
<Leonidas> iter_changes gives me ('TREE_ROOT', (None, u''), True, (False, True), (None, None), (None, u''), (None, 'directory'), (None, False))
<Odd_Bloke> Leonidas: It'd be more normal to use revnos for a branch like bzr.dev.
<Leonidas> Odd_Bloke: right, but I don't have the revno.
<Leonidas> when working with bzrlib, one almost never gets any revnos
<Leonidas> abentley: do you have a moment and can take a look on that changeset?
<abentley> Leonidas: That looks like it's creating the root directory.
<Leonidas> abentley: how is this possible? The root directory must have existed earlier.
<abentley> There may have been a different root directory
<abentley> Yes, the root directory for aaron.bentley@utoronto.ca-20070517163555-3i7jamitmffdg85l was "tree_root-20070410133226-3795pjcs6oz73ncz-1"
<Leonidas> abentley: how can something like this be reproduced? TREE_ROOT looks like it is something special, whereas tree_root-2007... is not.
<abentley> Leonidas: Using bzrlib, you should be able to set whatever tree root you want.
<Leonidas> abentley: how? By modifiying a revision tree's inventory?
<abentley> Leonidas: By calling set_root_id on a WorkingTree.
<Leonidas> ah!
<abentley> I should point out that released versions of bzr will always select TREE_ROOT if the repo format isn't a rich root format.
<Leonidas> but, erm, what use does it have to be able to change the TREE_ROOT? I'm trying to understand this, but somehow a the root directory cannot track any changes like setting it +x or something.
<abentley> The root directory can do anything any other directory can do.  Especially, it can be moved and renamed.
<abentley> Or deleted, even.  This tends to happen when splitting one tree into two.
<Leonidas> I see, didn't know that. I always thought about the root directory to be just a container for the content.
<Leonidas> abentley: ok, thanks a lot. Now that I can reproduce this in simple repositories, I can figure out that to do.
<abentley> you're welcome.
<Leonidas> abentley: I suppose there needs to be a file/directory with that fileid already created to set_root_id, right? But the ``bzr`` program seems not to have any problems with nonexistent root_ids
<Zelgadis> Hi! Does bzr supports nested trees?
<Teddy> Zelgadis: Apparently, yes.
<Zelgadis> Teddy: how?
<Teddy> Zelgadis: http://bazaar-vcs.org/NestedTrees
<LarstiQ> I might need to update that soon
<LarstiQ> Zelgadis: I guess the answer is: it's not where we want it yet, but you can do a number of things already
<Zelgadis> wow, thank you
<LarstiQ> Zelgadis: if you can desribe your use case more clearly I can give more detailed directions.
<Zelgadis> ok. I have a directory with a lib, doc, layouts and episodes
<Zelgadis> every person, who works on particular episode will need lib folder
<Zelgadis> but some person don't need lib folder, he just wants the doc folder
<Zelgadis> that's the complex case. But I can simplify it.
<LarstiQ> Zelgadis: I see, nested trees would ease working like that
<Zelgadis> yep. The main purpose is to reduce bandwidth usage
<Zelgadis> every episode is extremely huge
<LarstiQ> Zelgadis: right, I would recommend keeping each episode in its own branch.
<LarstiQ> Zelgadis: but you can work with multiple branches like that without having nested-trees, it will be more manual work that way
<Zelgadis> LarstiQ: If I'll do it without ConfigManager then everytime user do a checkout a whole repository history will be retrieved, right?
<LarstiQ> Zelgadis: cm doesn't impact that aspect, it just takes away some of the manual aspect of checking out different trees into a hierarchy
<LarstiQ> Zelgadis: so, you have a couple of seperate problems to be solved
<LarstiQ> Zelgadis: one thing you mentioned is breaking up into multiple branches because each individual episode is very big
<LarstiQ> Zelgadis: another thing might be that you don't want all history for one specific episode when you're working on it
<LarstiQ> Zelgadis: options to help there are stacked branches or lightweight checkouts
<Zelgadis> LarstiQ: yes, lightweight checkouts - is a option because I've choosed the bazaar among others VCS
<LarstiQ> Zelgadis: what is the workflow like on an episode? Do people need to work against the history often?
<Zelgadis> LarstiQ: what is a stacked branches?
<Zelgadis> Yes we doing commits often
<LarstiQ> Zelgadis: stacked branches allow you to have only some of the historical data yourself, and for older revisions to talk to the branch they are stacked upon
<LarstiQ> Zelgadis: it's a feature introduced in 1.6, see --stacked in `bzr help branch` for instance
<LarstiQ> Zelgadis: for committing you don't need to access history, diff and log are cases where you need older revisions
<Zelgadis> LarstiQ: But if I want to commit locally?
<Zelgadis> (with a lightweight checkout that's seems impossible)
<Zelgadis> But that's not a big problem.
<LarstiQ> Zelgadis: correct, a lightweight checkout needs to contact it's master for everything
<LarstiQ> Zelgadis: a stacked branch doesn't need to, it can operate locally
<Zelgadis> nice
<LarstiQ> Zelgadis: http://doc.bazaar-vcs.org/bzr.1.6/en/user-guide/index.html#using-stacked-branches
<LarstiQ> Zelgadis: out of curiousity, what is an episode?
<Zelgadis> cartoon episode - source files (.blend, .sif, .xcf, .kra)
<LarstiQ> ooh, cool
<Zelgadis> LarstiQ: You may find more at http://morevnaproject.org/
<Zelgadis> althrough, not much there yet
<Zelgadis> LarstiQ: So, back to the NestedTrees problem - all I need, is just organize folders in branches
<LarstiQ> Zelgadis: yeah
<LarstiQ> Zelgadis: it sounds to me like most people will only have one or two branches (lib/episodeX or doc) at a time
<Zelgadis> yep
<LarstiQ> Zelgadis: in that case it isn't too much overhead to just get them by hand
<Zelgadis> the problem is what I need some files (like Makefile and README) at the root of branches
<Zelgadis> outside the branches
<LarstiQ> Zelgadis: you could do something like: cd morevna; bzr branch http://host/environment; cd environment; bzr branch http://host/episodeX
<Zelgadis> LarstiQ: ...and tell to .bzrignore in environment to ignore the subdirectories?
<LarstiQ> where environment has the Makefile, README and all other things you need for all of them
<LarstiQ> Zelgadis: bzr will do that automatically
<LarstiQ> or well, I should rephrase that
<LarstiQ> Zelgadis: if you have a bzr branch in another bzr branch, bzr status will not list all the files in that inner branch as unknown
<Zelgadis> cool!
<LarstiQ> Zelgadis: it will see that the directory is a bzr branch, and not recurse into it
<Zelgadis> didn't know that - that simplifies things!
<LarstiQ> Zelgadis: it will show up only once as an unknown dir
<Zelgadis> but we could still add that unknown dir?
<Zelgadis> LarstiQ: it will help people to figure out what branches they could need
<LarstiQ> Zelgadis: not `bzr add`
<LarstiQ> Zelgadis: what do you mean, figure out what branches they need?
<Zelgadis> LarstiQ: so, they appear as unknown, but 'bzr add' won't add them?
<LarstiQ> (and not recursing into unknown directories is something bzr does for all unknown dirs btw)
<LarstiQ> Zelgadis: correct
<LarstiQ> Zelgadis: try: cd /tmp; bzr init foo; cd foo; bzr init bar; bzr st; bzr add bar; bzr st;
<Zelgadis> LarstiQ: Ah, understand. That's ok.
<Zelgadis> LarstiQ: Thanks alot!
<LarstiQ> Zelgadis: np :)
<Zelgadis> back to work ^___^
<Leonidas> bzrlib.errors.InconsistentDelta: An inconsistent delta was supplied involving 'newdir/secondfile', 'secondfile-20080921155404-xxpouw03i8s29crx-3'
<Leonidas> reason: This was marked as a real delete, but the WT state claims that it still exists and is versioned.
<Leonidas> hmm, this is strange.
<Leonidas> I just tried to change the root_id to the id of the subdirectory newdir, but that does not seem to work.
<LarstiQ> Leonidas: that would give two paths with the same file_id, no?
<stewart> lifeless: ping?
<ronny> hi
<ronny> how can i convert a branch with rich root support into one without rich root support?
<stewart> ronny: bzr upgrade (has parameters)
<stewart> anybody know if you can combine two bzr trees for separate projects (i.e. no common history) into one?
<LarstiQ> stewart: bzr merge -r 0..-1 otherbranch
<ronny> stewart: it goes only in one direction
<LarstiQ> stewart: you may want to move the contents of one of them into a subdir to reduce conflicts
<ronny> stewart: i can convert from non-rich to rich, but not back
<stewart> ronny: okay - not 100% of that.
<stewart> LarstiQ: that's what we'd do. it's adding a storage engine into the mysql tree that's been maintained externally.
<LarstiQ> ronny: that would be because a non-rich root format can not represent all of the information in a rich root format
<LarstiQ> ronny: so by default that isn't possible. May I ask why you'd want to do so?
<LarstiQ> stewart: ah, I see.
<ronny> cause the remote is not a rich repo
<ronny> and i want to push
<ronny> however bzr doesnt let me to
<LarstiQ> right, for the reason I just mentioned.
<LarstiQ> ronny: upgrading remote isn't feasible?
<ronny> i could do that, but its just my branch of another project, i dont want to enforce anything and i dont want to redo the cahnges i did
<LarstiQ> ronny: right.
<ronny> what kind of metadata does the rich-root hold, cause im pretty sure i dont use any of it
<stewart> LarstiQ: just tested the merge command above, worked great. thanks!
<LarstiQ> ronny: the root path gets to have a real file_id, which enables you to move it and such.
<LarstiQ> ronny: I'm looking for ways to help you deal with this, without having to exercise bzrib directly.
<LarstiQ> next up, rebase
<ronny> hu?
<LarstiQ> ronny: I looked at creating a bundle and applying that, didn't work. Now I'm looking at rebase.
<ronny> hmm, the __dozenz__ of partially incompatible repo formats are a pain :/
<LarstiQ> __dozenz__?
<ronny> well, i count at least 6 of them
<ronny> well, more like 13
<LarstiQ> ah, dozens, not a python __attribute
<Leonidas> LarstiQ: no, not really, since the newdir has a different fileid than '' which has the fileid TREE_ROOT.
<LarstiQ> Leonidas: but you said you dit set_root_id(newdir_id)?
<LarstiQ> ronny: I can't really think straight right now
<LarstiQ> ronny: but I'd try the list next
<Leonidas> LarstiQ: yeah, I had a working tree with the root id set to TREE_ROOT and then I tried changing it to the file-id of my subdirectory
<fdv> anybody around who might have a hint or two on how to get pqm working?
<fdv> or are there alternatives?
<Odd_Bloke> fdv: What are you struggling with?
<fdv> Odd_Bloke: pqm requires config-manager, which requires pybaz
<Odd_Bloke> fdv: Yes.
<fdv> afaik, baz, and therefore pybaz, is discontinued
<Odd_Bloke> Yes.
<Odd_Bloke> It's a bug in CM, rather than PQM.
<fdv> yes, I presumed as much
<fdv> but I don't really know neither pybaz, nor bzrlib very well, so migrating is a rather tough option :)
<Odd_Bloke> fdv: PQM doesn't require you to use baz.
<Odd_Bloke> It just required libraries for using baz to be installed.
<Odd_Bloke> Which is why it's such an irritating bug.
<fdv> right, so pybaz is enough?
<Odd_Bloke> fdv: Enough for what?
<Odd_Bloke> If you want to use PQM for bzr, you only need what's in PQM.  Unfortunately, PQM currently requires config-manager which requires pybaz, but that's orthogonal to what you really need.
<Odd_Bloke> fdv: What platform are you on?
<fdv> Odd_Bloke: ubuntu
<fdv> sorry, was distracted a moment
<Odd_Bloke> fdv: 'apt-get install config-manager' should be enough for PQM to not complain about it. :)
<fdv> the config-manager package is broken, as it depends on pybaz, but that one doesn't exist
<fdv> ...anymore
<Odd_Bloke> *shakes fist at Ubuntu*
<fdv> still, when trying to use config-manager from source, there are lots of 'import pybaz' statements in there
<fdv> so I can't really see how it'd work
<fdv> oh, right
<Odd_Bloke> Try using https://code.launchpad.net/~daniel-thewatkins/pqm/config-manager
<fdv> maybe that code is only called when one uses baz
<Odd_Bloke> fdv: That code _should_ only be called when one uses baz.
<fdv> right, I see
<Odd_Bloke> Unfortunately, it is not.
<fdv> oh
<fdv> bummer
<Odd_Bloke> Hence the whole issue. :p
<fdv> sounds like it should be fairly easy to fix
<fdv> I see
<Odd_Bloke> fdv: Patches welcome. ;)
<fdv> hehe :)
<Odd_Bloke> I've spent a little while looking at it (I worked on PQM over the summer), but didn't get very far.
<fdv> so config-manager is only needed by pqm when used with baz, is it so?
<Odd_Bloke> fdv: Nope, CM isn't _needed_ even then.
<fdv> ok, but it _can_ be used
<Odd_Bloke> Yeah, but it also _can_ be used when you're using PQM with bzr.
<fdv> but it might also be nice to have with bzr?
<fdv> right
<Odd_Bloke> It should be completely independent of baz.
<Odd_Bloke> But it's not.
<fdv> I see
<Odd_Bloke> fdv: Actually, that's not the branch you should use.
<fdv> oh
<Odd_Bloke> fdv: It depends on a lot of other unmerged work.
<fdv> right
<Odd_Bloke> fdv: If you don't want to use config-manager, ISTR that just removing the imports works.
<Odd_Bloke> Which is nasty, but will let you get on with things.
<fdv> ok
<fdv> (another issue, btw, is that config-manager won't build without the dir ./libgetopt, which is not there, but I nicked it from the .deb)
<fdv> Odd_Bloke: what would I need config-manager for anoway?
<Odd_Bloke> fdv: If your build required you to pull in a few branches.
<Odd_Bloke> It's _kinda_ like svn:externals.
<fdv> aha
<fdv> makes sense
<fdv> kind of hard to put the pieces together without prior knowledge :)
<fdv> (this channel, of course, is _very_ helpful in that respect :))
<Odd_Bloke> fdv: Yeah, PQM is still fairly obtuse.
<fdv> config-manager seems to be a bit out of date, actually
<fdv> though maybe I just don't understand it
<Odd_Bloke> Well, it depends on pybaz, which is a reasonable indicator. :p
<fdv> under implementations, there is only arch_vcs.py and fake_vcs.py
<Odd_Bloke> Yeah, that's where the baz and bzr stuff should be.
<fdv> only baz, afaics
<Odd_Bloke> Whereas currently it's intermingled with the core code.
<fdv> aha
<fdv> I see
<fdv> doesn't sound like a very pleasing place to start :)
<fdv> Odd_Bloke: thanks a lot, at least I know part of the rationale now and I might be able to get it together
<Odd_Bloke> fdv: No worries. :)
<fdv> Odd_Bloke: wouldn't it make sense in pqm to import config_manager only inside the two methods using it?
<fdv> I'm not sure if I see why that is ugly
<Odd_Bloke> fdv: It would make sense, I think.
<lifeless> stewart: yo
<libwilliam> I was doing some messing around with the different commands to see what they did and now my tag revnos are listed as ?.. My guess is because I uncommitted the revisions that had tags. So if this is the case I was wondering if those tags should even exist?
<Odd_Bloke> libwilliam: Those tags will point at the old revisions.  The '?' just means that those revisions don't have a revision number in this branch (as they are not part of the history).
<libwilliam> Alright, well I am trying to do a bzr log -r tag:<tag with ?> and I am getting a crash
<libwilliam> Is this worthy of a bug report?
<jelmer> libwilliam, please
<libwilliam> jelmer, k
<rsc-> Is there a way for me to use "meld" to resolve conflicts when merging?
<beuno> jml, hi
<beuno> I've given your lp stacked branch experiment a spin
<beuno> and I get this: http://paste.ubuntu.com/49082/
<beuno> I have a shared repo
<jml> beuno: oh, the branch called 'experiment' is broken.
<jml> beuno: but even if it was ok, if you branch it locally, it should work, and won't be stacked unless you say --stacked
<rsc--> Is there a way for me to use "meld" to resolve conflicts when merging?
<beuno> jml, that explais it, thanks
#bzr 2009-09-14
<poolie> hello igc
<igc> hi poolie
<spiv> Good morning.
<lifeless> hai
<poolie> hi spiv
<timClicks> hi all, sorry for n00b q - how to I overwrite locally modified files with the trunk?
<Raim> timClicks: you can use bzr revert to go back to the unmodified version
<timClicks> thanks Raim
<Raim> or if you are talking about pulling new changes and forgetting any local changes, bzr pull --overwrite
<timClicks> I didn't quite trust revert
<lifeless> poolie: quick call ?
<poolie> hi, sure
<fullermd> vila: py25 on this system doesn't make any difference either.
<Stavros> hello
<Stavros> i pushed my repo somewhere, creating a branch, and now i want to create a workingtree there, how can i do it?
<Stavros> anyone? :/
<davidstrauss> Stavros: Where do you want the working tree?
<Stavros> in the branch i pushed
<davidstrauss> Stavros: Can you SSH and cd to the directory?
<Stavros> yes, i just need the command
<Stavros> bzr up stopped working for some reason
<davidstrauss> Stavros: bzr up won't create a working tree
<fullermd> up doesn't create a working tree, it just updates an existing one.
<davidstrauss> Stavros: Run bzr checkout
<Stavros> it used to work in earlier versions
<Stavros> ah, that's it, thanks
<Stavros> i kept trying revert and up, but nothing
<Stavros> thanks
<poolie> spiv, how's stuff?
<spiv> poolie: ok... I started bumping into unexpected obstacles with the homedir-relative hpss patch; I'd forgotten just how many layers there are between cmd_serve and SmartServerRequest to pass new options through.
<spiv> poolie: so I decided I should take a look at implementing it as a transport decorator after all, as that is already passed through just fine.  But that too is hitting some obstacles; I have written a generic path filtering transport decorator but it isn't quite passing tests yet.
<poolie> ok, that sounds good
<poolie> i wondered if that would be the case
<poolie> spiv, i'm just thinking that many transports do abspath(arg) or similar before using paths
<poolie> ie some common filtering
<poolie> this seems to have some connection to wanting to do common policy on paths, but i'm not sure precisely what
<spiv> Yeah, possibly.
<spiv> I hope to have more firmly formed ideas on the subject Real Soon Now...
<spiv> Hmm, if a patch to add "--pdb-on-failure" to selftest dropped out of the sky right about now, I wouldn't complain...
<SamB> spiv: heck yeah!
<SamB> though personally I would think it would make more sense to just make BZR_PDB=y work then too
<SamB> but either way would be really useful
<SamB> ... probably would have done it if I had been able to see how ...
<spiv> SamB: the problem is BZR_PDB really means something slightly different.
<spiv> So making it do this for selftest would be a bit hackish.
<poolie> spiv, i'd love that too
<poolie> high on my list of post-2.0 wishes
<poolie> maybe this week
<poolie> also --pdb-before
<lifeless> I think reusing BZR_PDB would be ok, really.
<lifeless> its not that conceptually different.
<lifeless> I will note that the 'stock' way to do it is to use debug() rather than run()
<lifeless> and then just run under pdb
<lifeless> I'm not convinced that this is the most elegant/appropriate way to tackle it
<poolie> saying "debug() rather than run()" is fine, but that's an api, not a ui
<lifeless> yes
<lifeless> the theory behind the debug() approach is that you would do 'python -m pdb bzr selftest --debug'
<poolie> do you mean, start pdb from the python repl, then construct a test, then
<lifeless> but, as I say, I have doubts.
<poolie> interesting
<poolie> i had no idea you could use pdb as a module
<poolie> its docstring doesn't mention it
<poolie> i think having a way by which other debuggers can run the right thing is highly worthwhile
<lifeless> so the problem with debug centres around finally & cleanup code
<poolie> oh i realized the reason all my work is unmerged, because lp was having a bad day on friday
<spiv> Ideally I think a pdb prompt for a failed test would be started before cleanups are run.
<lifeless> spiv: yes; this depends on the precise interaction of 'finally' and 'pdb.pm', for using 'debug()' as an API to do this.
<lifeless> spiv: which is one [but not all] of the reasons I don't like debug
<lifeless> http://paste.ubuntu.com/270620/
<lifeless> spiv: ^ enjoy.
<lifeless> hooking into self.fail() would work too, but that has the problem that not all errors invoke fail, some raise directly.
<naoki_> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#getting-help
<naoki_> s/bzr help/bzr help topics/ ?
<lifeless> spiv: also https://code.edge.launchpad.net/~lifeless/bzr/selftest-pdb/+merge/11673
<poolie> what's the pqm trunk branch?
<lifeless> lp:pqm ?
<poolie> naoki_, you're right, the 'list of topics' is different
<poolie> naoki_, file a bug/
<naoki_> OK
<poolie> actually nm
<poolie> i'll change it here
<poolie> lifeless: what i actually meant is, what should i put in locations.conf?
<lifeless> oh :)
<poolie> i think i have it now
<lifeless> its in my docs proposal
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/docs/+merge/11284
<lifeless> submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
<naoki_> https://bugs.launchpad.net/bzr/+bug/429151
<ubottu> Launchpad bug 429151 in bzr "'bzr help' in "getting help" section should be 'bzr help topics'" [Undecided,New]
<AfC> Now that we have a stable default format, is there any need for `bzr init` to list off 21 options all relating to different formats possibilities?
<AfC> [I thought we fixed that, but they're back]
<poolie> afc, in its' help?
<poolie> naoki_, https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/11674 thanks for pointing it out
<poolie> check that phrasing if you like
<spiv> Time for lunch.
 * igc lunch
<jam> fullermd: are you sure that you're going to "write something someday" http://www.over-yonder.net/
<jam> :)
<jam> anyway, night all. I'm headed to bed, and then off to Canada tomorrow
<spiv> jam: Canada, eh? :)
<jam> spiv: I think I'll be training some people, eh?
<jam> does anyone know how to tell 'setup.py' that one of your extension needs the library built in a previous step?
<jam>   libraries=['extension']
<jam> is easy enough
<jam> but I have to also give the path to the lib
<jam> and the temporary directory where everything is being built doesn't seem to be on the default lib path
<SamB_XP_> jam: I don't think you're supposed to need symbols from other modules directly; I think you're supposed to use some Python-side APIs to find the other modules?
<SamB_XP_> the part I can't remember is how they're supposed to provide C-level APIs to other extension modules ...
<jam> SamB_XP_: the point is that one C level api is using another C level api, and I need the .lib so that the compiler can resolve the imported symbol
<SamB_XP_> jam: oh, you mean they're already doing that in Linux but it doesn't work in Windows ?
<SamB_XP_> well, I think they're not supposed to do that ...
<jam> SamB_XP_: I have 2 python extensions. I want to write a Key_New() function
<jam> similar to PyTuple_New()
<SamB_XP_> ... isn't this covered in extending and embedding ?
<jam> and I want to make use of that function in the next lib
<jam> SamB_XP_: I can get it exported, and I can get it imported *if* I do:
<SamB_XP_> you probably want to do something like what the numeric library does now -- whatever it's name is these days ;-)
<jam> add_pyrex_extension('bzrlib._btree_serializer_pyx',
<jam>                     libraries=['_keys_type_c'])
<jam> ext_modules[-1].library_dirs.append('build/temp.win32-2.6/Release/bzrlib')
<jam> Obviously that "library_dirs" isn't going to be a stable path
<jam> I haven't yet found out how to find that path properly
<jam> hence the questions here
<jam> Scons, for instance, when you create a build node, you can pass that to the next build node
<SamB_XP_> jam: I really, really don't think you're supposed to directly link extension modules like that ...
<jam> to make it a dependency, and it has attributes like "this is where my lib is built"
<jam> SamB_XP_: Not much different from linking python26.lib to get the functions from python26.dll
<jam> it is just another dll
<jam> just named .pyd (or .so)
<spiv> SamB_XP_: but consider the case of a plain C lib that is shared between multiple Python C modules
<spiv> SamB_XP_: which is certainly valid, and I think would encounter the same issue?
<jam> spiv: though you have some potential issue if/when 'import' is triggered
<jam> anyway
<jam> as near as I can tell
<jam> distutils has no concept of 'dependencies'
<jam> well, I found this from 2004: http://osdir.com/ml/python.distutils.devel/2004-02/msg00116.html
<jam> where they were talking about adding it
<lifeless> jam: this is to build an extension that build-deps on another extension?
<jam> lifeless: yeah, and links to it
<SamB_XP_> jam: http://docs.python.org/extending/extending.html#providing-a-c-api-for-an-extension-module
<lifeless> spiv: does my selftest-pdb gelp you?
<SamB_XP_> jam: that's the officially sanctioned approach
<SamB_XP_> dumb as it may seem
<spiv> lifeless: not yet, as I dealt with my immediate issue the old-fashioned way (import pdb; pdb.set_trace()) and haven't needed that again today.
<bialix> igc: https://launchpad.net/bzr-explorer/trunk/0.8/
<jam> SamB_XP_: that is so... very... awful
<SamB_XP_> jam: so's the (\forall OS, dynamic linking) story
<jam> So couldn't you just store it in PyCFunction, and then get the raw pointer out of that?
<igc> bialix: awesome, thanks.
<bialix> :-)
<bialix> what about bzr installer?
<bialix> igc: ^
<igc> bialix: I've merged your stuff to trunk and patched in explorer 0.8
<igc> bialix: I'm trying to build it now on my vista VM
<bialix> igc: I hope you re-enabled TBZR
<lifeless> jam: this is what pyd files do, I thought
<lifeless> jam: the pyrex header stuff
<igc> bialix: I will but I haven't yet
<bialix> igc: ok
<bialix> igc: English messages is OK?
<jam> lifeless: pyd files are just a .dll named differently (for windows)
<igc> bialix: likewise I need to put back the other installers according to jam's email
<jam> ah, you mean pyrex pyd files
<lifeless> jam: yes :)
<jam> I haven't specifically played with them
<bialix> igc: do you mean build all installers from your project?
<jam> and there is also .pxi, IIRC
<jam> or something like that, pyxi? pyi?
<bialix> igc: it will be non-trivial
<bialix> igc: also I was forced to disable your settings to use mingw
<igc> bialix: we *might* be able to build the other installers from 2.0.0 trunk - dunno
<bialix> igc: I believe you can set such settings in distutils.cfg
<igc> bialix: I'm still learning how all this stuff hangs together
<bialix> igc: it hangs together very badly
<SamB_XP_> bialix: that's probably why he's still learning ;-p
<igc> bialix: it's challenging that's for sure
<bialix> SamB_XP_: no
<SamB_XP_> if it hung together well, it probably would be a breeze to learn ;-P
<igc> bialix: it will be good as we gradually reduce the dependences, etc.
<bialix> igc: it won't help much
<bialix> igc: removing cog is just a tiny change
<igc> bialix: right. But I'd like other clean-ups as well so build-installer.bat was python say.
<bialix> igc: be back online after 2-3 hours
<igc> bialix: then we can perhaps use it for os x, etc.
<bialix> igc: unlikely
 * bialix bbl
<igc> bye
<lifeless> jam: is this for meliae?
<lifeless> I'd look at pyrex's interface stuff
<fullermd> jam: :P   Someday encompasses a lot   :p
 * fullermd boggles.
<fullermd> Selftest is using 120 threads?  That CAN'T be right, can it?
<lifeless> fullermd: if they aren't getting gc'd
<fullermd> Well, it's on 9222/22518, and it's been running for almost 5 hours.
<fullermd> It's eating a hundred thousand context switches a second, so it's actually getting about 3% of the CPU.  I'm thinking something's not quite right.
<lifeless> that would be the GIL
<fullermd> And it's spit a giant pile of "Can't assign requrest address" from various per_transport tests.  Related?
<lifeless> yes
<lifeless> server threads not winding up properly.
<fullermd> So those errors are symptom, not cause?
<lifeless> reported as 'selftest hanging on windows' I think, but not debugged/pinned down
<lifeless> yes, i think they are a symptom
<fullermd> Is there something I can try now while it's running to get info about the cause, or should I just murderlize it?
<lifeless> gdb
<lifeless> get a pystack in some of the threads
<fullermd> 'cuz I ain't letting my server sit on its knees for another 7 hours to finish...
<fullermd> 'k...   I'll look into that after I finish lunch.
<jml> how big is the bzr 2a repo?
<lifeless> 30MB
<jml> thanks.
<fullermd> You have a handy ref on doing that?  I've never used gdb with python.
<lifeless> http://wiki.python.org/moin/DebuggingWithGdb
<fullermd> Mmm.  Would pdb be easier?  It would take a little doing to get a debug symbol'd python...
<fullermd> (that matches the running one)
<lifeless> you could try ctrl-\ and debug
<lifeless> no guarantees that it will do anything sensible with other threads.
<lifeless> pdb is rather more capable ;)
<lifeless> sorry
<lifeless> gdb is ...
<vila> fullermd: not fully awake yet, but first thing *I* would try is: '--parallel=fork' which is known to work around the thread issue (see gentoo)... (be back after coffee)
<fullermd> Well, _fixing_ it would work around the thread issue too   :p
<fullermd> 's I can help in that direction...
<fullermd> 'k, running just -s per_transport.TransportTests seems to be doing the same thing; every HttpServer_urllib test spits the error, and the thread count is climbing.
<fullermd> So I guess it's easy to reproduce in this instance.
<lifeless> vila: We should fix this
<fullermd> How odd.  It gets the error calling socket.shutdown()?!
<lifeless> fullermd: don't worry about working around; try to get to the bottom of it.
<fullermd> What a bizarre place to get a Can't assign error.
<vila> lifeless: the bottom of it is to call transport.close()  :-) Pending that, it's to properly shutdown (as you pointed in some bug)
<vila> fullermd: what error in shutdown() ?
<lifeless> vila: I don't agree vis-a-vis close()
<vila> lifeless: let's talk about it (but let me have a coffee and a shower first :)
<fullermd> vila: http://paste.ubuntu.com/270691/  is what the tracebacks look like on the failed tests when I ^C.
<vila> fullermd: 8-) That's when I realize I'm dreaming...
 * vila won't be back before 2 coffees now
<fullermd> Oh my god, the best thing I can dream of now is not just bzr selftest, but bzr selftest _FAILING_?!
 * fullermd . o O ( Down, then across... )
<lifeless> vila: if t.close() is needed, production servers will leak resources.
<vila> lifeless: I agree. t.close() and s.shutdown() are both valid ways to fix the issue. I'd like to try *both* separately once I'm able to reproduce the problem reliably (I'm there on gentoo). But s.shutdown() is to be prefered, yes. Nevertheless t.close() is needed in other contexts (or if not strictly needed is the most natural to use, pullers were involved in the two cases my memory brings back)
<poolie> lifeless: still here?
<poolie> can you explain to me what you mean by using debug() for debug support in selftest?
<poolie> hi vila
<vila> hello poolie
<vila> fullermd: so, just to be sure, I understand your context correctly: 1) You now have brz.dev in 2a format, 2) you're running python-2.5, 3) You're experiencing thread leaks,
<vila> fullermd: what about the revision not found errors then ?
<fullermd> This is separate from that.
<vila> fullermd: but 1 & 2 are correct, right ?
<fullermd> I get the RevNotFound with 2.5 and 2.6 on my workstation (8/amd64).  Trying to see what I get on my server (7/i386/py25) that I'm seeing the thread leak stuff.
<fullermd> (on both bzr.dev and installed 1.18)
<fullermd> It only got partway through the test suite on the server due to that problem, but I haven't seen any RNF's there _yet_.  And at 9k and change, I'm pretty sure I would have if they were coming up with near the same frequency.
 * fullermd is working on a debug build of python at the moment to see if anything pops out of that.
<vila> fullermd: hmm, well, the thread leaks generally make a lot of noise but most importantly make the tests fail early, so once you start getting one such error, most of the subsequent ones are 100% noise
<fullermd> Yah.  But my backscroll has none of the RNF's.  I'm pretty sure I saw then in the first thousand at least on my workstation.
<fullermd> Now, there's two variables there; 7.x vs 8.x, and i386 vs amd64.  But you're running 7.x/amd64 and not seeing them, right?
<fullermd> So that suggests 7/8 is the culprit.
<vila> 7/amd64 yes (in a VM but hopefully that's unrelated)
<fullermd> Hopefully.
<vila> fullermd: checking again, you built the C extensions right ?
<fullermd> It's a working theory anyway.
<fullermd> Yah.
<fullermd> OK, there's a debug build...
<vila> so we need at least some test names to start searching further
<fullermd> Easy peasy.
<fullermd> Actually, I don't think the list has much changed since previous runs...
<vila> just thinking aloud :)
<fullermd> But there's a copy just in case you're too far from your mail quota   :p
<fullermd> As a guess, I'd say that EVERY problem there is the same thign.
<vila> my mail quota is my local disk available space :)
<fullermd> The 82 ERROR's that got sorted together obviously are.
<fullermd> But the other 9 FAIL's seem like they could actually be the same thing, expressed differently.
<fullermd> (e.g., all the test_statistics, that got 0 revs instead of 3, the 2 unreferenced texts instead of 0...  all sound like they could be the result of the same 'revisions going off into lala land' problem)
<fullermd> Which sadly, suggests it may not be as simple as a broken test or two, but may be a real problem   :|
<fullermd> Though I should note that I've NEVER seen revisions disappear in _using_ bzr.
<fullermd> Now, let's see how this gdb stuff woiks...
<fullermd> lifeless: OK, what am I...     Urg.
<fullermd> pystack on a thread hanging around from an error throws gdb into a tight loop.  Loverly.
<fullermd> bialix: Hey there.  Quit pinging me and running off before I can reply 6 hours later   :p
<bialix> fullermd: ok
<bialix> fullermd: my hosting admins are unable to install bzr correctly
<vila> bialix: +1 on that, it would be nice if you could find a way to be more reliably pingable on IRC :-/
<bialix> after 3 mails from me about wrong chmod bits they finally fixed problem
<vila> bialix: hi by the way :)
<bialix> vila: bonjour
<bialix> vila: it was joke?
<bialix> fullermd: what is the right way to install bzr on BSD?
<fullermd> From the port?  Just like any other port.
<fullermd> What chmod issues were cropping up?
<vila> bialix: like fullermd I often wish I can ping you, but since you're not always online, it makes rather hard to reach you that way, and sometimes writing a mail is not appropriate ,nothing serious, just wanted to echo fullermd's feeling
<bialix> fullermd: they install bzr only for root. my account even can't read bzrlib modules. therefore I've got consistent ImportError
<bialix> vila: you can ping me and hope that I'll read irclogs
<bialix> vila: or use gtalk
<vila> bialix: haaaa, I see
<fullermd> Mmm.  You mean the .py{,c,o} files are 600 or something?  What about the 'bzr' script itself?
<bialix> fullermd: yeah, something like that
<bialix> first time (2 years ago everything was nice)
<fullermd> Ports assumes that root means what they say with their umask, so if they have it set to 077 or something, and bzr's build doesn't explicitly override it, you could end up with that result.
<bialix> fullermd: yes, admin told something about umask
<fullermd> (bzr would hardly be the only thing affected by that; lots of ports will do what they _say_ rather than what they may think they _mean_ in that situation)
<fullermd> It does give warnings when you build/install with restrictive umasks, but if you're not watching the build, it's fairly easy to miss.
<bialix> it seems so
<bialix> so next time I'll asking about upgrade of bzr I need to tell them: "remember about umask"
<bialix> fullermd: heh, ok. thanks
<fullermd> Yeah.  They really should remember about that all around; lots of things meant to be run by non-root will be screwy in that case.
 * bialix stopped ping fullermd for next 6 months or so
<fullermd> Of course, you'd never notice with something like apache or a MTA or such, since they DO get run by root, but...   heck, _python_ could be seriously impacted, unless it overrules umask.
<fullermd> (that would be 2 wrongs making a right, I guess   :p)
<bialix> :-)
 * igc out for a bit
<bialix> vila: I really have no idea how to solve this ping problem
<vila> bialix: stay connected ?
<bialix> ubottu: can you work as irc postmaster?
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<bialix> vila: no way for work computer
<vila> bialix: end of discussion :-D
<fullermd> freenode has a MemoServ.  But that's probably more trouble than email.
<bialix> vila: and even if I'll let my home laptop working 24/7 it won't help me while I'm at work
<fullermd> Sure it will, that's what screen is for   :p
 * bialix run away screaming
<vila> yeah or any other irc proxy (not that I used one myself, but I understand that's one of their duties)
<bialix> irclogs.ubuntu.com btw has dealy around 2-3 hours
<bialix> so it's not very reliable
<vila> yeah, that makes quite a high latency :-/
<bialix> *delay
<fullermd> Anyway, nothing jumps out at me from screwing with gdb here.  So I'll shelve that for now.
 * bialix hides
<vila> fullermd: so I can work on the leak issue from gentoo, but the RNF are out of reach until I setup an 8/amd64...
<fullermd> Yeah.  Wonder what triggers that leak.
<fullermd> Never happened on my workstation, but is reliable on server.  And the server isn't setup much different from your VM.  Wacky.
<fullermd> Well, i386/amd64 I guess, but that hardly seems a likely culprit.
<fullermd> Perhaps academic now, but re: your setting up 25 and 26; that would be...  well, possible, but you don't wanna try it.  Lots of manual frobbery needed there.
<fullermd> (though why you wouldn't just want to go 2.6...   :p)
<beuno> poolie, hi
<poolie> hi!
<poolie> and bye, unfortunately
<beuno> poolie, :)   I'll catch up on the website emails then
<poolie> welcome back btw
<poolie> were you on holidays?
<vila> fullermd: I suspect you have a different  *limit* for the threads, we're leaking reliably almost everywhere, we're just rarely caught doing that :-D
<fullermd> I'm not explicitly setting one.  And wouldn't I get those address assignment errors whether or not it was hitting a limit?
<vila> fullermd: What are the steps to upgrade from 7.2 to 8 ? I should be able to clone my VM to start a 8 one
<fullermd> (I mean, I only have 2 threads when first I get one...)
<fullermd> vila: Basically, checkout the source, build and install.
<fullermd> You could grab an ISO or such for ...  BETA4 I think is the latest?  if you wanted to go the binary way.
<vila> ok, let me prepare things first (if you expect to still be online for a bit that is)
<vila> hmm, I don't know which one will be the shortest...
<fullermd> Oh, yes.  I've got coffee, and I'm settling down for an afternoon of working.
<fullermd> The build will probably be shortest in time you have to pay attention to it, though it'll presumably take longer in a VM than on bare iron.
<vila> may be worth starting again though
<vila> http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051801.html sounds full of good advices for upgrading no ?
<spiv> Hmm, I think have a reasonable implementation of /~/ (and /~user/) expansion for bzr serve now.
<vila> spiv: good to hear !
<fullermd> vila: Could work.  I've never used freebsd-update(8), so I don't know what (if any) hitches or tricks there might be in it.
<fullermd> spiv: beer++!
<vila> fullermd: is that a "good for me"/"good for noobs" dichotomy which shouldn't discourage me to try ? :)
<fullermd> Well, freebsd-update is basically a tool for binary updates between releases.  It requires that you're using the distributed binary bits, since it uses bindiffs.
<fullermd> Being as I never run releases, and always have locally compiled stuff, it's just not applicable to me   :p
<fullermd> OTOH, I have faith in the authors and maintainers, and have no reason to disbelieve that, in those cases, it works as advertised.
<vila> right, but since I installed from a 7.2 ISO and didn't update (as far as I recall) I should be able to just follow that right ?
<fullermd> Just that I have faith that all software has gotchas somewhere, and I don't know where they might be in f-u.
<fullermd> Yah.
<vila> So I\ll try that first, if that fails, I'll went the checkout/build/install route :)
<fullermd> Sounds like a plan.  What's the worst that could happ*SLAP*
<vila> fullermd: :-D Nothing, one more broken VM is not a big deal :)
<vila> fullermd: Does this look reasonable (y/n)?
<vila> fullermd: gee, yes, I guess :-D
 * fullermd is always tempted to see what 'n' does to questions like that   :p
 * igc dinner
<Stavros> hello
<fullermd> No, you say _goodbye_.  _I_ say hello.
<SamB_XP_> fullermd: why's that ?
<fullermd> I dunno.  John Lennon made me do it.
<SamB_XP_> in soviet russia, hello says you
<awilkins> jelmer: "Unexpected keyword argument '_override_hook_source_branch'" ; does this ring a bell?
<awilkins> jelmer: A colleague is getting this trying to push a revision to an SVN repository
<SamB_XP_> awilkins: would there happen to be a file and line attached to the error ?
<awilkins> SamB: I've got a trace coming to me ; http://pastebin.ubuntu.com/270796/
 * SamB_XP_ curses bzr for not using cgitb...
<awilkins> It did it with both 1.16 and 1.18-1
<awilkins> I'm suspicious
<SamB_XP_> of what ?
<SamB_XP_> ... anyway, there sure doesn't seem to be a bug for that ...
<awilkins> Ok, it happens for lightweight checkouts but not heavies
<awilkins> Looks like a path in the code that the test suite must pass over
<SamB> awilkins: lightweight checkouts of SVN repositories themselves ?
<SamB> that sounds like a phenominally bad idea ;-)
<awilkins> Lightweight checkout of a branch mirrored from an SVN repo
<SamB> oh
<SamB> I do that all the time on Linux ...
<awilkins> I don't think it's necessarily linked to bzr-svn
<SamB> well, I think it's highly likely that bzr-svn is at least triggering it
<awilkins> The bug is line 2468 of remote.py (in 1.18 at least)
<SamB> because it looked like at least 90% of tracebacks with that keyword argument in them were in bugs filed against bzr-svn
<awilkins> If bzr-svn is exercising the API in a legitimate way there should be a unit test that's doing the same thing
<SamB> when I say "triggering", I just doing what it should, but triggering a bug in bzr itself ;-)
<SamB> yeah, true
<SamB> or a similar sort of thing
<SamB> is that method supposed to accept any keyword arguments whatsoever ?
<fm> i have a bzr-pipeline. now i want to create a patch for every pipe, how is it done.
<fm> ?
<SamB> fm: does bzr-pipeline have no docs???
<fm> i cannot find docs about how to generate a patch series ....
<fm> there are neither docs how to reorder the pipes in the pipeline ...
<jelmer> awilkins: please file a bug
<SamB> fm: you checked http://bazaar-vcs.org/BzrPipeline ?
<SamB> that's what launchpad has for the homepage of bzr-pipeline
<SamB> fm: anyway, if you can't see how to do something even after reading all the docs you can find for bzr-pipeline using `bzr help' *and* reading the wiki page, go ahead and file a bug
<fm> SamB: i have read http://bazaar-vcs.org/BzrPipeline#id3 but they do it manually. i am looking for a command bzr export-pipes which creates a patch for every part of the pipe. i thought that was the use case of bzr-pipeline?
<fm> should i file a feature request for that, or do i miss something?
<SamB> fm: feel free to file a bug about that too ;-)
<SamB> go ahead
<fm> bzr help pipeline does not help alot ...
<SamB> well, if it's thare and help pipeline doesn't help you find it, that's also a problem
<SamB> so yeah, go ahead and file a bug about how you expect such a command and can't find it
<jam> lifeless: actually it is for bzr, so that I can have a "Key" type, and have btree_serializer create them directly. It is 738ms => 720ms for 'bzr log -n0 -r-1' if you build a tuple to pass it to Keys.__init__ versus using Key_New() and then setting the values.
<SamB> jam: that doesn't sound like much of a difference
<fm> https://bugs.launchpad.net/bzr-pipeline/+bug/429301 SamB
<ubottu> Launchpad bug 429301 in bzr-pipeline "export pipeline as a series of patches" [Undecided,New]
<bialix> SamB: be careful when talking about soviet russia. somebody watching you
<jelmer> bialix: :-)
<fullermd> In Soviet Russia, you watching SOMEBOD...   wait, that doesn't quite work...
<bialix> jelmer: hi, sorry, have no chance to run git tests fro you yet
<bialix> for you
<jelmer> bialix: np
<jelmer> are you subscribed to the windows bugreport for bzr-git by any chance?
<jelmer> There were some folks commenting on it the other day
<bialix> jelmer: subscribed to windows bugreports? how it's possible?
<bialix> IIUC lp allows me subscribe to all project bugmails, but it's not intelligent enough to distinguish between OS bugs
<jelmer> bialix: one particular bug report I mean
<bialix> err, I think no, but I'd like to
<bialix> which one?
<jelmer> bug 382125
<ubottu> Launchpad bug 382125 in bzr-git "Can't branch from remote repository on Windows" [Undecided,New] https://launchpad.net/bugs/382125
<bialix> jelmer: if you think I will be interested in particular bug report you can subscribe me freely. I know how to unsubscribe if I found that bug unrelated to me
 * bialix looking
<bialix> I saw it other day but not yet was subcribed. Now subscribed
<bialix> jelmer: as comments say it's wrong approach to open memory-mapped file in w mode
<bialix> jelmer: actually you can't
<bialix> on Windows
<bialix> only r+
<bialix> you even can't memory map the file of 0 length
<jelmer> bialix: Thanks, I'll do that in the future
<jelmer> bialix: Sucks that memory mapping is readonly :-/
<jelmer> so I guess we'll just have to read manually
<bialix> jelmer: perhaps I'm not quite understand your intent
<bialix> jelmer: python documentation on mmap module has many special remarks re Windows behavior
<jelmer> bialix: yeah, I guess I should have a look at that
<jelmer> we mostly use it to read packs so I guess we should be able to solve this pretty easily
<bialix> clearly RTFM case
<sidnei> jelmer, bialix: nowhere in the python documentation it mentions that mmap is read-only on windows
<bialix> jelmer: well, in this case it seems so
<bialix> [16:18]	<jelmer>	bialix: Sucks that memory mapping is readonly :-/
<bialix> I'm not sure what jelmer means when he said "that"
<bialix> sidnei: hi, btw
<sidnei> bialix: hi! :_
<sidnei> :)
<jelmer> bialix: sorry, I think I must've misunderstood
<jelmer> bialix: you're saying that there can only be one person with a file opened for mmap write access at the time?
<bialix> sidnei: after some experience with buildout for main bzr installer I wonder how to build smaller one to package just bzr-svn into installer :-D
<bialix> jelmer: no, I don't say so
<sidnei> bialix: yeah, should be possible. i wish i had time to dedicate to this :(
<jelmer> bialix: hmm, not sure I follow then. I guess I'll read the docs first :-)
<bialix> jelmer: bug 382125 said about error while trying to open the mmaped file in "w" mode
<ubottu> Launchpad bug 382125 in bzr-git "Can't branch from remote repository on Windows" [Undecided,New] https://launchpad.net/bugs/382125
<bialix> jelmer: J really have to look at your sources first
<bialix> jelmer: but if your intent is read and write in the same file via mmap, then you can achieve this, but initially you should open the file in r+ mode
<bialix> sidnei: yep :-(
<sidnei> i suspect the problem is that you can't open the same file for writing on windows twice (through the standard python api, you can open it in shared mode through pywin32), period. nothing to do with mmap?
<bialix> sidnei: I suspect jelmer don't need to open the same file twice, because it's inprocess stuff, not IPC
<jelmer> I suspect we're accidently opening the same file twice
<bialix> jelmer: lp:dulwich branch has very strange fomat: unnamed
<bialix> jelmer: can you upgrade it to 2a
<bialix> ?
<fullermd> You sure it's not?  lp:anything is unnamed when you're logged in, since it's the smart server remote fake format.
<bialix> fullermd: I've just branching it
<bialix> and have 2a repo + branch 6
<bialix> locally
<fullermd> Oh.  What's branch7?  Stacking?
<fullermd> (except not, since you can stack on branch6, right?  Don't quite understand that...)
<bialix> fullermd: you can see full info -v output here: https://bugs.launchpad.net/bzr-git/+bug/429394
<ubottu> Launchpad bug 429394 in bzr-git "If git plugin installed without dulwich it blocks usual bzr operations with bzr trees" [Undecided,New]
<bialix> fullermd: do you remember which format supports views?
<fullermd> Do views actually really work?
<fullermd> I think it was side by side with content filtering anyway, so that would be wt5 or whatever it is in 1.14+.
<bialix> I dunno, but I'd like use it
<bialix> oh
<bialix> jelmer: what's the strange combination in lp:dulwich: repo 2a, branch 6, wt 7
<bialix> bzr.dev in 2a has: repo 2a, branch 7, wt 4
<fullermd> I've got wt6 in my 2a bzr.dev.
<bialix> err dulwich: repo 2a, branch 6, wt 6
<bialix> fullermd: really?
<fullermd> The 2a rollup is 2a-rep/br7/wt6
<bialix> so it's 1.18 issue
<bialix> filing a bug is useless, core devs stopped support 1.18 already
<fullermd> 1.18 creates the same thing...
<fullermd> That's what the 2a rollup has always meant, I'm pretty sure.
<bialix> fullermd: not for me
<fullermd> Oh, maybe it's different on Windows?
 * bialix branching lp:bzr again from scratch w/o shared repo
<bialix> fullermd: do you think it's a joke?
<fullermd> I dunno.  Wasn't Windows using a different WT format by default for a while?
<bialix> never heard this
<bialix> AFAIC it's contradict to default policy of bzr.devs
<fullermd> The format registry for 2a lists Rep2a/Branch7/WT6, ans has since the revision that created the 2a format (4428.2.1)
 * bialix still branching
<fullermd> Now, I can see how you might end up with WT4 using 1.18 to branch bzr.dev...
<fullermd> (since there's no WT format on remote sides to copy, it'll just use the default, which in 1.18 is still pack-0.92, which uses WT4)
<fullermd> But that should show as unnamed, not 2a for the rollup name.
<bialix> fullermd: it seems so
<bialix> I've just finished to branch lp:bzr and again have: repo 2a, branch 7, wt 4
<bialix> damned zoo of formats
<fullermd> If you upgrade --2a it you should get wt6 though.
<fullermd> (or if you'd used 2.x+ to do the branch)
<bialix> yes, after upgrade to --2a I've got wt 6
<bialix> really really weird
<bialix> I think I'll file a bug to see what core devs might say
<vila> bialix: making 2a the new default is a significant step *away* from the zoo... you have good reasons for not taking that into account, but accept the consequences too then :D
<bialix> vila: it's inconsistent
<vila> file the bug anyway, 'unnamed' is never good
<fullermd> The problem is that there're two behaviors here, and neither of them is (by current concensus) strictly a bug.
<bialix> do you really think the behavior I see is good?
<vila> bialix: ^
<vila> bseeing 'unnamed' is *never* good
<fullermd> The first is that branch'ing from remote creates the local WT in the default WT format for that release, since WT's that are remote don't exist to bzr, so it has no format to copy.
<bialix> getting inconsistent 2a branch is a bug for me
<fullermd> And the second is that the 3 (or 4, I guess) formats are independent.
<fullermd> So as far as 1.18 is concerned, wt4 _is_ the proper WT format when you haven't requested anything else.
<fullermd> (since that's what it's config'd to create)
<bialix> I think it's a bug https://bugs.launchpad.net/bzr/+bug/292553
<ubottu> Launchpad bug 292553 in bzr "Format "unnamed" when creating "default" branches in newer repository formats" [Medium,Triaged]
<bialix> vila: I understand that nobody will work on this bug because default policy is to use bzr 2.0+
<fullermd> Well, it's more that nobody will work on it because what should be done is awful unclear.
<bialix> vila: but from theoretical POV: is it possible to bzr doing the RIGHT thing? looking at formats registry, found matched combination of repo/branch formats and determine default wt format?
<fullermd> None of the 3 formats is dependent on the others, so you can't guess what the WT format 'should' be based on the repo and branch format you see.
<bialix> fullermd: there is registry of formats
<bialix> fullermd: if you see repo 2a and branch 7 it's natural to expect this is 2a branch?
<fullermd> Not necessarily.  If you see a knit repo and a branch5, what wt format do you create?
<bialix> wt is special for treeless central repos, so bzr can be more smart about detecting the right format, rather than using defqult one
<bialix> fullermd: I dunno?
<bialix> but maybe bzr devs care to provide special registry then?
<bialix> to lookup default wt format based on repo+branch combination?
<fullermd> The point is, nobody can know.  It could be wt3 OR wt4.  Both are defined with that branch/repo combination.
<bialix> you really talk about ancient things
<fullermd> And there's no reason to believe the 'right' answer isn't wt7 for that branch either, just because you don't have a defined rollup format for it.
<bialix> I'm talking about new things
<bialix> urgh
<fullermd> There's no rule that multiple WT formats for given repo/branch combinations are only historical.
<bialix> I don't care
<bialix> I wanna have consistent 2a branch after branching lp:bzr
<bialix> I can't
<fullermd> 1.9 and 1.14 both use pack6 and branc7, but they have different WT formats.
<bialix> bzr is broken then
<bialix> I hate it
<fullermd> Who cares?  The WT works just fine.
<bialix> 1.14 never was in favor
<bialix> it was experimental thing nobody really used
<vila> not at all, it wasn't providing the same benefits to all cases so it was promoted mostly where it was
<fullermd> Everybody's [will be] using it, since it's contained in the 2a WT format.
<vila> but 2.0 was already worked on anyway so there was little incentive is pushing everybody to upgrade to 1.14
<bialix> zoo of formats zoo of formats zoo of formats
<vila> s/2.0/2a/
<fullermd> The repo and branch formats, taken in combination, tell you nothing about what the WT "should be", if that's even a meaningful question in the first place.
<bialix> why not create all possible permutations then?
<fullermd> For me, I think the rollup format name is the problem in the first place.
 * bialix reallyhave to shut up
<vila> yeah sure, you can repeat that ad nauseam, we are working to get out of that anyway
<fullermd> I think it just causes way more trouble than it saves.
<vila> fullermd: I agree. It should be fixed nevertheless.
<vila> (including replacing it by several parts if needed)
<fullermd> Well, that just opens the question of "what's the fix"; if the problem is "'unnamed' is alarming", then just not showing a rollup line is a fix   :p
<vila> not sure we can get two votes on that one :-D
<bialix> is not this simply hides the problem deeper?
<fullermd> A matter of perspective.
<bialix> if wt7 is filter-aware format and you expect to have proper filtering and...
<bialix> naoki_: hi
<naoki_> hi
<bialix> naoki_: small proposal re tbzr
<naoki_> what's?
<bialix> will be nice if you will update version info after some changes you made
<bialix> so each bzr-X.Y.Z-setup build will be with more or less unique tbzr version
<bialix> having 0.2 still while you doing many improvements does not sound right
<bialix> at least it was my impression looking at recent bug reports
<naoki_> I see.
<naoki_> After releasing 2.0, version compatibility is more problem.
<bialix> it will be much simpler to check bug reports
<bialix> what do you mean?
<naoki_> TortoiseBZR have released with newest bzr.
<naoki_> There are no like 1.13.5 after 1.14 released.
<bialix> I don't quite understand
<naoki_> But after 2.0, 2.0.5 can released after 2.1 released.
<bialix> this is not problem per se
<bialix> having 2 branches: one for stable 2.0.x and other for trunk
<naoki_> So, TortoiseBZR should define compatible bzr version like other plugins.
<bialix> something like that will be nice, yes
<bialix> but TBZR is not plugin
<bialix> so you need to show the error message in different (GUI) way
<naoki_> Yes, but relying to bzr api.
<bialix> and unless TBZR can be build separately of bzr.exe, it's not a problem
<naoki_> hmm.
<bialix> igc has started separate windows-installer project, so you can stick specific tbzr version to specific bzr release
<naoki_> So, I can use simple version number for TBZR.
<bialix> anything that will work for you is good
<naoki_> OK.
<naoki_> I'll branch and tag 0.2
<bialix> this is just suggestion based on my qbzr release manager experience
<bialix> version numbers is just numbers
<bialix> they are needed solely to distinguish between them
<bialix> no more no less
<bialix> version numbers like 1.0 and 2.0 is more than numbers
<bialix> they are MESSAGE to the worls
<bialix> world
<naoki_> Yes, people feels "1.0" is stable.
<naoki_> I have not done some operation on Launchpad, like series, release, etc...
<naoki_> Now I tagging release-0.2.0 and push.
<naoki_> It will compatible with bzr-1.18, 2.0, and qbzr-1.14
<bialix> it's ok
<bialix> just mention these dependencies in README or somewhere
<bialix> have to go. bye all
<igc> night all
<naoki_> good night
<bialix> good evening
<bialix> I want to ask about mainline idea
<bialix> anybody knows where from it comes? originates?
<malibu> Hi there...
<malibu> use bzr break-lock chroot-19383696:///r/repo/bzr/work/.bzr/branch/lock
<malibu> "
<malibu> when I do this, I get invalid protocol for chroot-19383696
<malibu> When I go to the root of my repo and just do 'bzr break-lock', it hangs
<malibu> Is there a way for me to just go into the repo and manually clear the lock?  I have full access to it
<bialix> chroot-xxx is temp protocol for bzr+ssh
<bialix> use bzr break-lock url
<bialix> it should not hang
<fullermd> bialix: I would guess at least some of it comes from arch.
<bialix> but it asked you about confirmation: y/N
<bialix> fullermd: I'm not familiar with arch
<bialix> fullermd: do you have any docs/links?
<fullermd> (not that I have more than a passing knowledge of it myself, but AIUI it did have some level of similar dichotomy between 'happened here' and 'grabbed from elsewhere')
<fullermd> No, just a general sense from some reading way back when and mentions of it since.
<bialix> is it correct if I assume mainline is like trunk in svn when UQDS used?
<fullermd> Your best bet may be to corner poolie and see how much was planned or emergent.
<bialix> fullermd: mainline in your country is more like man railroad or high way?
<bialix> s/man/main/
<bialix> hmm
<fullermd> I don't really think of it as either; without context it just strikes me kinda abstractly...
<bialix> poolie maybe will be good person for this question, but he's in oz time :-/
<LarstiQ> I'm not sure where the thinking that mainline is imported came from
<bialix> fullermd: ok, can you provide me some expressions with this word, please?
<LarstiQ> important
<bialix> LarstiQ, fullermd: I'm writing article about mainline concept in bzr and its impact on daily work
<bialix> I want to provide some simple explanation
<fullermd> I'm not sure.  I don't think of it as a strong analogy to some other thing; just the hazy concept of a privileged path compared to others...
<bialix> in Russian I've translated mainline as main branch or main development line
<bialix> as line of revisions
<fullermd> Now, my understanding of how it applies in bzr in particular and version control in general, and why it's important and useful, didn't come from any docs I read or discussions I saw, AFAICT.  It just sort of built itself up from fiddling.
<malibu> bialix: Do I use the url to the actual file, or just to the root of my repo?
<bialix> malibu: root of branch or repo
<LarstiQ> malibu: to your branch
<malibu> ok..
<fullermd> Yeah, there's some ambiguity there; it's sometimes used as 'main branch' (e.g., 'trunk' or the like).  But in this context, it's more like....    mmm...   'primary path through history', maybe?
<fullermd> It's the antithesis of relativity; a privileged frame of reference   ;p
<bialix> fullermd: it's mentioned on b-v.o wiki in Workflows document
<bialix> primary path through history -- very poetic, I like it
<bialix> technically it's just left hand revisions chain
<bialix> but this is ugly technical detail
<fullermd> It's a cross-section of the history that, if you work in a certain way, allows you to get a good high-level view of what's happened, much more quickly than if you have to read every page.
<fullermd> Cliff Notes to a branch (I wonder how well that translates...)
<fullermd> I think that's mostly a US-ism.
<bialix> http://en.wikipedia.org/wiki/CliffsNotes -- this one?
<fullermd> Yah.
<bialix> yes, it's hard to translate
<bialix> I'm little worried about dark side of mainline though
<bialix> you should use only mainline otherwise you will be screwed
<bialix> or your history will be hard to read/undersatdn
<bialix> understand
<fullermd> Well, it's a mechanism to ignore information.  If you ignore the right stuff, it can be a big aid.  If you ignore the wrong stuff, you're in trouble.
<bialix> how people deal with it?
<fullermd> And (tautologically) if you work in a way that mainline doesn't end up holding the right information, you won't get the right information from it (FSVO 'right').
<bialix> fullermd: well, log -n1 now default, so it's possible to say by default bzr ignores both right and wrong dtuff
<bialix> stuff, sorry
<LarstiQ> bialix: does your audience have experience with hg or git log?
<bialix> LarstiQ: I'm writing articles so it's self-contained
<fullermd> It can be simpler if they don't, since that brings biases.
<bialix> I don't do explicit references to hg or git
<LarstiQ> ok
<bialix> I often compare with svn though
<bialix> because it makes some examples simpler
<bialix> LarstiQ: btw, do you heard about group extension for hg?
<fullermd> That can be more useful; it's easier to describe the capabilities it provides as "svn log"++, rather than a sort of "git log"--.
<LarstiQ> bialix: I haven't
<fullermd> Anyway, it's way past my bedtime; I'm too far gone to dream up good analogies tonite   :|
<bialix> although I'm writing for newbies mostly I'm trying to explain things not for dummies, so even experienced people can get some new info
<LarstiQ> fullermd: I was thinking of the non-discriminating nature
<bialix> fullermd: what? are you going to sleep?
<fullermd> I was planning more on staring muzzily at the ceiling for a few hours, but...   call it what you will.
<bialix> LarstiQ: this extension aims to combine several revisions into logical group, something similar to bzr mainline
<bialix> fullermd: lol :-D
<LarstiQ> bialix: cool :)
<bialix> fullermd: ok, you win, bye
<zsquareplusc> bialix: and you already have articles online?
 * fullermd quickly hides away so bialix doesn't ping him in his sleep...
<bialix> zsquareplusc: yes, http://bzr-day.blogspot.com
<bialix> fullermd: I've promised to not ping ou next 6 months
<zsquareplusc> ah, wrong encoding for me :-)
<bialix> *you, err
<bialix> zsquareplusc: ru_RU
<fullermd> Well, if I'm really lucky, I'll sleep longer than that   ;p
<bialix> :-D
<bialix> :-D :-D :-D
<zsquareplusc> bialix: yea i know, the characters look perfectly as they should. it's me that can't make any sense from them ;-)
<bialix> yeah :-D
<bialix> don't try to use google translate service
<bialix> result is rather unpredictable :_D
<bialix> :-D
<bialix> especially funny when it tranlsate "command" as "team"
<bialix> just because these words are sound the same in Russian
<bialix> "bzr add team"
<bialix> how you can say "dotted revno" in other words?
<LarstiQ> "revno with branchpoint information encoded"
<Tak> is checking WorkingTree.merge_modified against none or empty The Correct Way to determine if there are merges pending commit?
<bialix> look at cmd_push in builtins.py
<bialix> there is check that wt has no changes files or pending merges
<Tak> cool, thanks
<bialix> Tak: len(tree.get_parent_ids()) > 1)
<Tak> thanks more!
<Tak> (prosiba? :-P)
<bialix> Tak: spasibo
<Tak> damn
<bialix> nm
 * Tak blame mumblers
<bialix> Russian is close to English in one feature: what is written often spelled very differently
<bialix> Tak: so if you want to write use: spasibo, if you will spell it, then close to your original variant
 * Tak nod
<bialix> What is codename of Ubuntu 8.04 ?
<jderose> bialix: hardy
<bialix> oh
<bialix> it's from beginning of 2008?
<zsquareplusc> yes the number IS the date
<bialix> nice
<bialix> what is LTS period? 5 years?
<bialix> anybody knows how to install newer qt on hardy?
<bialix> bug 429549
<ubottu> Launchpad bug 429549 in bzr-explorer "Opening Preferences: bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'QFormLayout'" [Undecided,New] https://launchpad.net/bugs/429549
<zsquareplusc> you'll probably get better support in #ubuntu ;-)
<bialix> meh
<Tak> so what behavior would one expect from a review/commit dialog on a tree with pending merges?
<bialix> I'll leave this question for igc
<bialix> Tak: review?
<LarstiQ> bialix: "see if I want to commit it as is"
<Tak> examine changes
<bialix> Tak: look at qcommit?
 * zsquareplusc misses the checkboxes and easy diff as TortoiseSVN has it for commits
<bialix> zsquareplusc: IIUC qcommit has checkboxes
<bialix> Tak: there is one big difference vs plain commit: when there is pending merges you always should commit entire tree, you can't select files for commit
<Tak> precisely
 * bialix nods
<zsquareplusc> bialix: a yes it has. i run the gtk gui more often than qbzr
<Tak> the current dialog: http://img294.imageshack.us/img294/1847/mdbzrreviewcommit.png
<bialix> Tak: so what is your question about?
<Tak> I'm trying to figure out the most helpful way for the gui to behave when there are pending merges
<bialix> zsquareplusc: try qbzr then
<bialix> Tak: it's not easy, indeed
<bialix> Tak: nothing better than suggesting show some explanation message about pending merges
<bialix> can you commit several files from your GUI?
<Tak> yes
<bialix> so maybe forcing this mode when there is merge?
<Tak> right now, if there's a merge pending, it requires you to commit everything in order for the commit to succeed
<bialix> do you support per-file commit messages?
<Tak> no, not currently
<bialix> on your screenshot there is prompt: Commit message for file 'vgtk'
<bialix> this can be misleading for pending merge case
<Tak> yeah, it is a little misleading
<Tak> What that actually does is create a commit message like: * blah.c: Fixed x.\n * blah.h: Fixed y. ...
<bialix> something like per-file entries, I suppose
<Tak> yeah
<bialix> and where is main commit message will be edited?
<Tak> it was originally designed for svn
<bialix> hehe
<bialix> I've reused svn support in FTE editor for bzr actions
<Tak> when "Commit" is pressed, a verification dialog pops up with the list of selected files and the full commit message
<bialix> it was so easy and mostly work
<bialix> Tak: ok, so use this dialog
<bialix> or invoke gcommit if this is gtk-based stuff
<Tak> yeah, bzr's ui maps nicely
<bialix> I'm still not quite understand what is your question actually
<phinze> so i don't shoot myself in the foot: do shelves as stored `bzr shelve` survive a bzr switch in a lightweight checkout?
<phinze> or, alternatively, do they stick to their associated branches somehow (though i don't know how that world even work implementation-wise)
<phinze> use case: jam-style setup, realize i started working on something that should be tracked in a new task branch, want to shelve, switch to new task branch, unshelve, selectively commit, reshelve rest, switch back, commit rest
<bialix> jam-sttyle :-)
<bialix> phinze: basically shelved changes stored in your checkout
<bialix> so they keep intact on switch
<bialix> they can know about base revision though
<bialix> so
<bialix> if your new branch based on current --everything should be fine
<bialix> old shelve1 working via plain patches
<bialix> you still can use it
<Tak> bialix: just wondering about the nicest way to present the user with the fact that 1) There are pending merges and 2) Commits have suddenly become all-or-nothing
<bialix> Tak: in qcommit we show list (graph) of pending merge
<phinze> bialix: awesome thanks
<luks> bzr could really support file selection even on merge commits
<luks> you can easily work it around by reverting/shelving the files before commit
<bialix> luks: hi
<luks> hi bialix
<bialix> luks: why?
<luks> I think it just unnecessarily restricts the user
<bialix> I think this is downside of mainline paradigm we talked earlier
<bialix> maybe you're right, IIRC there is bug report opened long time ago
<Tak> I agree with luks
<bialix> about unshelve or about restrict?
<bialix> from my experience I need selective commit on merge very rarely
<luks> I would understand the behavior if revert/shelve refused to work on a merge
<Tak> bialix: about both, really
<bialix> ok
<luks> hm, but revert is actually useful for resolving merges
<luks> so that wouldn't work
<bialix> what difference between log -n0 and log --include-merges?
 * luks hasn't used bzr log for ages :)
 * bialix too
<bialix> qlog rules
<bialix> but for article I have to
<LarstiQ> bialix: less cryptic name
<bialix> ok
<rocky> jelmer: hey, is there a version of bzr-svn for bzr 2.0dev yet?
<lifeless> moinmoin
<poolie> hi lifeless
<thefirstdude> hi poolie
<poolie> hi
 * davidstrauss joins the hi-fest
<davidstrauss> Hi!
<jelmer> rocky: yeah, the 1.0 branch of bzr-svn should work with 2.0
<poolie> jelmer: could you make at least an rc of it in the next couple of days
<poolie> so that we will have something suitable to sync into jaunty?
<bialix> poolie: hi
<poolie> hello bialix
<bialix> several hours ago I've asked about mainline paradigm origin and fullermd suggested to asking you
<bialix> can you make some remarks about mainline and its roots?
<bialix> I need this for my new article
<bialix> poolie: ^
<poolie> sure
<poolie> about why people have a mainline at all?
<bialix> no, about why bzr has mainline concept
<bialix> and no one else dvcs seems to have it
<jam1> hi all
<jam1> ghost jam
<bialix> and what is mainline in other words
<jam1> sorry mt
<lifeless> jam1: hi. I suggest looking at pyrexes interface stuff
<poolie> hello jam1
<bialix> hello jam1
<poolie> bialix: oh, mainline in the sense of having revisions numbered along the left side?
<poolie> well
<jam> lifeless: sure, I'll probably poke into that next week
<lifeless> the amount of C we're writing..
<bialix> poolie: I eager to know everything, but even short vision from you as original author will help
<lifeless> I am getting my feeling back of 'just do it in C' :P
<poolie> it's a bit hard for people to visualize unrestricted dags, and a bit hard to represent them well in text mode
<poolie> if you just give them arbitrary revision ids, they're impossible to compare
<poolie> and dates are not reliable in a distributed system
<bialix> esp when you have rebase
<poolie> right
<bialix> why collapsing merges revisions?
<poolie> in the log?
<poolie> any ideas about bug 429553?
<ubottu> Launchpad bug 429553 in bzr "bzr diff errors with "no revision"" [Undecided,New] https://launchpad.net/bugs/429553
<bialix> um... yes
<jam> is igc around?
<lifeless> bialix: do you mean 'why -n1 by default' ?
<jam> I wanted to ask a bit about cvs2bzr
<lifeless> jam: haven't seen him yet this morning
<bialix> poolie: this question about bug for me?
<bialix> poolie: I dunno
<poolie> no, more jam or lifeless
<poolie> bialix: i think that merges are not perfectly symmetric from the human's point of view
<bialix> lifeless: no, not -n1, about entire ideas of distinct clearly between left hand revs and merged revs
<poolie> i don't think people see it as 'merge A and B' but more 'merge B into A'
<bialix> it depends
<poolie> well,
<poolie> let's say it's often the second
<jam> poolie: I don't have a specific idea, but this line looks odd
<jam>  Â Â File "bzrlib\repository.pyo", line 1826, in get_revision_reconcile
<bialix> poolie: I found mainline idea good for disciplined developers
<bialix> but bad for bad developers
<poolie> if people often push or push overwrite it probably makes things confusing
<poolie> is that the sort of thing you mean?
<jam> bialix: how is it worse for undisciplined developers than not having a mainline at all?
<jam> hence you get the win with "disciplined" developers, but status quo for the rset
<jam> rest
<bialix> poolie: I have one in my team, who prefer to use only one his branch instead of make features branches for every new feature
<poolie> and he just merges to and from his branch?
<bialix> well, your idea about merge is not symmetric does not work when bad developer merge several weeks of work at once
<bialix> i.e. merge several new features interlined
<bialix> poolie: he just merge trunk into his own branch and don't pay attention about mainline annotation
<poolie> and then he pushes his branch to trunk?
<bialix> without append_revisions_only things become nightmare
<bialix> poolie: in the past yes, pushed. now I've restricted him to use me as gatekeeper
<poolie> hm
<bialix> poolie: hg has version numbers but does not have mainline
<poolie> why does he do this?
<jam> poolie: one possibility for the 'diff' is that it is trying to get the old revision so that it can fake a timestamp
<jam> and perhaps that revision is a ghost?
<poolie> right, in hg i think the versions are numbered in arbitrary topo-sorted order
<bialix> and hg guys "invent" group extension which does similar thing
<jam> poolie: right, they are the 'order the revision appeared in my repo'
<jam> and your numbers and mine are not the same
<jam> for the same rev
<bialix> i.e. add group comment to the several revisions to make them logical group in log
<bialix> poolie: I mean hg reinvent our wheel here: some sort of history annotation (as fullermd said)
<bialix> we have this for free from hardcoded mainline support
<poolie> basically i think the view you get from a bzr trunk branch is very good
<poolie> first this happened, then this happened, then this happened...
<bialix> so basically what is bother me a lot is this hardcoded mainline paradigm.
<poolie> and you can look at the details of all of the individual commits leading up to any of them
<bialix> yes, bzr follow this paradigm very well
<bialix> but not all projects are so disciplined
<bialix> what is your suggestions then?
<lifeless> poolie: in hg changes are in repo-add order
<bialix> and yes, default log -n1 makes the things a bit harder for undisciplined devs
<poolie> lifeless: i know
<lifeless> bialix: why not set 'append_only' on your branch ?
<bialix> lifeless: I did
<lifeless> poolie: sorry :P you said 'I think' :P
<bialix> but it's not default
<bialix> I understand reasons behind log -n1 (dotted revnos), I', just trying to understand mainline as word and paradigm
<bialix> is not it too restrictive?
<poolie> the idea is that when you're looking at a particular branch, it focuses attention on revisions that were actually committed in that particular branch (or its parent), rather than merged into it
<poolie> i think this is useful
<poolie> but if it turns out to be restrictive, we should try to relax those restrictions
<malibu> When I do break-lock from command line, bzr hangs
<poolie> in other words bzr should never hold you back from seeing or working with the real graph
<malibu> bialix: I think you were helping me before.. it does in fact hang
<malibu> I've been leaving it sit for 2 hours now
<bialix> malibu: many core devs around, please show us some pastebin
<bialix> you can file a bug though
#bzr 2009-09-15
<bialix> poolie, jam: how mysql team working with mainline?
<malibu> show a pastebin of what?
<jam> bialix: they don't
<bialix> jam said their branches are bushy
<jam> they don't worry about a separate mainline
<jam> sorry, a "specific mainline"
<poolie> malibu: is this on windows or unix?
<jam> but it doesn't seem to be a problem
<malibu> client on windows, server on ubuntu
<bialix> jam, poolie: theoretical questions: if bzr will have command-line option to not generate dotted revnos but show merged revisions -- does it will help?
<malibu> bialix: Here is my output:  http://pastebin.com/m634fe87e
<bialix> if dotted revnos is source of slowdown, then show only revid for merged revs might help?
<jam> bialix: it depends if you continue to preserve the merge info
<jam> if you want the "show merges just before the revision which merged them and after the one that did not"
<jam> it doesn't help
<poolie> bialix, the main problem i know of with our approach is this, that numbering them is either slow or needs to be cached
<poolie> though, i do think we need to do more to help people work well with undisciplined developers
<jam> poolie: so there are other options, like 'date sorted'
<bialix> IIUC jam trying to say dotted revnos is part of problem?
<poolie> jam: just a flat list, sorted by date?
<poolie> it could be worthwhile
<jam> bialix: dotted revnos + merge  sorting requires loading the whole graph
<jam> poolie: right
<bialix> jam: and only merge sorting?
<jam> bialix: no merge sorting
<jam> sorry I should revise
<bialix> if only merge sorting
<poolie> bialix: as we're going through history, we want to see whether a revision should be shown as 'merged by r100'
<jam> merge sorting requires loading the whole graph
<igc> morning
<jam> while we do that, we compute dotted revnos
<poolie> doing this requires checking whether it was merged by any previous revision
<jam> hey igc
<poolie> hi igc
<igc> hi jam, bialix, poolie
<jam> good to see you
<bialix> ok, thx for explanation
<jam> I've got a couple questions for cvs2bzr + fast-import
<igc> jam: fire away
<bialix> igc: hi
<jam> igc: With just copying the cvs2bzr-example.options, I ended up getting a 'commit per branch' to "create the branch"
<jam> which is necessary in svn, but obviously not bzr
<bialix> jam: so hg have natural sort order based on the order revisions come into repo?
<jam> bialix: it is 'topological sorted'
<jam> but yeah
<jam> when merging it fetches some revisions
<jam> that is the order
<lifeless> bialix: and in hg the sort can be different between different repos
<bialix> jam: ok, understand
<bialix> lifeless: I see
<poolie> i wonder if it is strictly guaranteed to be topo sorted
<bialix> so mainline concept in bzr is also about achieving consistency between different similar barcnhes?
<poolie> if they ever get a ghost-like condition that may be broken
<lifeless> they have a single file - the 'revision revlog', which is indexed by integers - the 'insertion order' in the repo.
<jam> igc: is there a way to disable it?
<poolie> bialix: yes, i think if you have two mirrors of the same conceptual branch, they should have consistent numbering
<bialix> poolie: AFAIK hg does not support ghost
<poolie> i don't think that is guaranteed true in hg
<igc> jam: I don't know whether that behaviour is controlled by options or just core cvs2fastimport behaviour. I suspect the latter
<jam> igc: so the problem with what I'm converting
<lifeless> their log and other operations that show ordering just start at revno=len(revisions.revlog), then count down.
<jam> is that they seem to create a lot of branches from the same rev
<jam> so the repo has 200+ branches, and like 100 are off of one rev
<lifeless> poolie: its not guaranteed true in hg; two branches with the same tip can have different revnos
<lifeless> both for the tip, and for antecedents
<poolie> right
<bialix> poolie: word "mainline" in the real life is about railroads? highways?
<igc> jam: the guy to ask is Michael Haggerty
<jam> igc: so we might just do trunk only conversions, but we'll see
<bialix> all dictionaries I've looked so far is rather confusing about this term
<igc> jam: bzr-fastimport itself looks for unique heads and only creates branches for those
<igc> jam: well it's meant to at least
<jam> igc: well, cvs2bzr is creating fake commits for the branches...
<jam> though perhaps it only looks that way because I was just converting part of a module?
<jam> not sure
<igc> jam: ok, that that certainly sounds like something we want fixed in cvs2bzr
<bialix> poolie: may I ask last question? do you read UQDS document from divmod.org?
<poolie> bialix, yes, from railroads
<poolie> or heroin ;-)
<poolie> http://en.wiktionary.org/wiki/mainline
<bialix> poolie: does it true to say their workflow is roughly equivalent to mainline paradigm?
<poolie> bialix: i have a while ago, let me look
<lifeless> bialix: they are dealing with svn :P
<poolie> i think that's broadly the type of flow that bzr encourages though
<bialix> lifeless: yes, but they insist on having a lot of feature branches
 * bialix will omit heroin meaning in the article
<bialix> fullermd also said mainline comes to bzr from Arch, is it correct?
<bialix> igc: how your experiments with windows installer?
<igc> bialix: it's my top priority this morning - just scanning email first
 * bialix going to sleep, see ya later
<bialix> poolie, jam: thanks for help
<zsquareplusc> someone have experience with bzr on sf.net? is it possible to store several, unrelated branches there (sub-projects)?
<jelmer> poolie: yeah, sure
<poolie> lifeless: any comments on bug 424797?
<ubottu> Launchpad bug 424797 in soyuz "lp.buildmaster.tests.test_manager.TestBuilddManagerScan.testScanRescuesJobFromBrokenBuilder failing silently" [Medium,Fix committed] https://launchpad.net/bugs/424797
<poolie> sorry bug 429747
<ubottu> Launchpad bug 429747 in bzr "errors during cleanup mask underlying errors" [High,Confirmed] https://launchpad.net/bugs/429747
<spiv> Good morning.
<spiv> poolie: I have hpss userdir expansion working now
<spiv> poolie: It's working nicely in manual testing, I have two small things left to do before submitting it,
<spiv> poolie: a) change chroot.py to reuse the path filtering decorator, because it's very similiar; b) add some testing for the uglier bits of the ~ expansion logic (and for the way it is glued into serve_bzr)
<poolie> hello spivvo
<poolie> cool
<poolie> lifeless: do you think you fixed bug 403322 implicitly with the delta fixes?
<ubottu> Launchpad bug 403322 in bzr "IndexError on moving added file" [High,Confirmed] https://launchpad.net/bugs/403322
<lifeless> poolie: I doubt it
<SamB> jelmer: where is the new bzrtools package ?
<naoki_> I'm currently translating user guide to Japanese.
<naoki_> Some document assume default format is not rich-root.
<naoki_> filtered_views.txt: Bazaar's default format does not yet support filtered views.
<naoki_> svn_plugin.txt: Note that using the ``default-rich-root`` option to ``init-repo`` is important
<lifeless> jam: are you around ?
<lifeless> igc: The batching that fast import does
<lifeless> igc: does it hold more than 1 inventory in memory?
<igc> lifeless: yes
<igc> lifeless: up to 10 from memory
<lifeless> igc: are they Inventory or CHKInventory objects ?
<igc> it's a cache of configurable size
<lifeless> as in, are they what the repository creates, or a separate object?
<lifeless> igc: I'm [still] working on analysing the memory use from the fast import that hit the wall
<lifeless> igc: so far I've determing taht there are several hundred 90K long containers in the memory dump
<igc> lifeless: I'd need to check. What the repo creates I believe
<lifeless> igc: did you see the gzip stuff I cc'd you on?
<igc> lifeless: bzr_commit_handler builds deltas and gets the new inventory back from the layer below IIRC
<igc> lifeless: yes. looks interesting.
<lifeless> igc: ok
<igc> lifeless: I'm hoping to get back on to fastimport bug fixing next week
<lifeless> I'm fairly sure something is leaking, and 914662 is the ref list length, which is unlikely to be coincidental
<lifeless> (900K, not 90K :P)
<igc> lifeless: this week I'm still fighting windows installers
<lifeless> yup
<lifeless> mmm, I am again reminded of why I dislike ORM's. :(
<cody-somerville> whats the name of that branch option that makes it so that you can only append to a branch
<cody-somerville> ie. it prevents the scenario where you branch, commit, merge parent, and then push to parent overwriting it
<fullermd> cody-somerville: append_revisions_only
 * igc lunch
<SamB> jelmer: oh, and it looks like bzr 2.0 packages should conflict with bzr-doc ?
<igc> out for a medical appointment - bbl
<lifeless> poolie: did you get my draft yesterday?
<poolie> hi
<bialix> igc: ping
<bialix> igc: the problem with win32event has no simple solution. you have to build full installer with tbzr on kerguelen to see the real result
 * bialix bbl, I'll read irclogs
<vila> hi all
<poolie> vila: hi
<poolie> are you looking at all at the issue of conflicts caused by deleting directories containing ignored files?
<vila> all the issues I don't know, but all the conflicts including those of this type certainly
<vila> poolie: do you still plan to review shell-like tests ? I have some improvements already done on top of the pending patch...
<vila> poolie: including a better execution model, globbing, 'rm' command
<vila> poolie: and counting :)
<poolie> vila, maybe i'll do it now
<vila> ok
<WanderNauta> Hi.
<WanderNauta> I'm new to version control, and I have a question.
<poolie> vila, can you help me triage the New bugs?
<poolie> not all right now, just a few a day
<WanderNauta> After going through some basic tutorials, it looked like with Bazaar, you need to run a command for every file you add.
<WanderNauta> Is there some option that looks for changed/new/removed/moved files automatically?
<vila> poolie: sure
<poolie> WanderNauta: 'mv --auto' and then 'add' with no arguments will add the new files
<bialix> poolie: is it possible to have simple fix for setup.py merged to 2.0.0?
<bialix> poolie: this one: https://lists.launchpad.net/bzr-windows/msg00149.html
<bialix> it's required only for bzr.exe
<WanderNauta> @poolie Thanks.
<bialix> if you don't think it suitable before release, I don't bother to prepare merge request
<bialix> and bonjour vila
<poolie> hi bialix
<vila> hi Alexander
<bialix> hi poolie, again
<bialix> hi Vincent
<poolie> bialix: it looks reasonable to me
<bialix> so I'll do the merge request now
<bialix> igc: around?
<igc> bialix: hi - just got back
<bialix> hi
<bialix> hi igc
<bialix> have problem with your build recipe
<igc> bialix: feel free to change it
<bialix> igc: http://pastebin.com/m63eea6fe
<bialix> it blow up on bzr-explorer
<bialix> Error: Abort uninstalling, because of pending local changes.
<bialix> bzr st in explorer/trunk branch is clean
<bialix> igc: am I missing something?
<bialix> I've got this error while running make as of revno 15 over existing build-win32
<bialix> sidnei: are you here?
<bialix> something wrong
<bialix> I did not see this before
<igc> bialix: I suspect it's a problem but not one I know how to solve
<bialix> are you adding uninstall action?
<igc> bialix: I certainly don't understand how the uninstall actions hang together, why they exist, what they do, etc.
 * bialix trying to remove build-win32 and starting from scratch
<igc> bialix: I think that will work but ...
<igc> it may be quicker to go into build_win32 ...
<bialix> everything worked for me at weekend
<igc> and then into explorer/trunk
<igc> and then run pull manually
<igc> bialix: I've been doing something like that instead of digging into the uninstall stuff
<bialix> vila: do you remember yesterday we talked about wt format?
<vila> bialix: yes, you think you can fix it ?
<bialix> branching over http works fine
<bialix> do you know why?
<bialix> I've just found that my 2.0.0 branch was cloned from http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0.0/ and it was in correct wt format
<bialix> maybe that branch has actual wt?
<bialix> but bzr info -v http:// does not say so
<vila> bialix: no idea, except that http use VFS
<bialix> igc: I've removed build-win32 and still have the same problem
<bialix> igc: that said that now I'm unable to build installer at all
<bialix> igc: you'd better disable this uninstall stuff
<bialix> igc: err, wait
<igc> bialix: I'm not sure what to do - I never touched the unistall stuff
<igc> bialix: I really think we need sidnei to help us here
<bialix> no, EPEBKAC
<bialix> it seems working, I've ran wrong command
<bialix> working now after deleting entire build-win32
<bialix> poolie: https://code.launchpad.net/~bialix/bzr/2.0.0-setup.py-qbzr-deps/+merge/11767
<igc> bialix: I'm heading off for the day sorry
<bialix> igc: bye
<igc> bialix: please ping sidnei if the installer still has issues. Hopefully he can help us get them sorted
<bialix> he's from South America?
<bialix> igc: stuff seems to working now, from scratch
<poolie> heading home soon
<poolie> bialix: is it at all possible jam would object to it?
<poolie> i don't expect so
<poolie> bialix: yes, sidnei is in brazil i think
<poolie> Rio Grande del Sul?
<poolie> see https://edge.launchpad.net/~sidnei
<bialix> poolie: I think everything is possible
<poolie> :)
<bialix> poolie: eta fro 2.0 final?
<bialix> poolie: eta for 2.0 final?
<poolie> soon, maybe tomorrow
<poolie> i'd like to see if we can do the web site first but maybe we can freeze the code, get that up, then announce it?
<bialix> poolie: this fix is not strictly required, as I've mentioned in revision commit message
<bialix> poolie: it will be very nice to have it, but not critical
<spirov92> hey guys. If I have 2 branches of a website-one on my machine and one on the server- and want them to have different database config files, how do I do that? do I just not version them?
<Coke> Hi! I'm using sftp as proto on a server a long long time ago in a galaxy far far away, but it's rather slow. The process of commiting 30-50k worth of text takes about 1m, including connecting and uploading. Is there a faster/better protocol?
<Coke> spirov92: usually you don't have site or user specific configurations in the repos
<spirov92> ok, thanks
<spirov92> so how do I exclude a file from versioning without deleting it?
<Coke> spirov92: bzr ignore <filename>
<Coke> or pattern
<spirov92> I did bzr ignore application/config/database.php..
<spirov92> "These files will continue to be version controlled unless you 'bzr remove' them."
<spirov92> and when I modify the file and do bzr diff, it shows the changes
<vila> spirov92: bzr rm <file> --keep
<vila> grr, gone
<Coke> Odd.
<Coke> I think ignore should do whatever it takes to actually ignore the file
<Coke> OR they should rename it to "ignore-maybe"
<Coke> it's counter intuitive and unproductive with the extra step of removing the file
<jelmer> SamB_XP: there is a bzrtools package in experimental
<jelmer> SamB_XP: bzr-doc ?
<fullermd> vila: It's quite unfair of you to not be getting errors   :|
<vila> fullermd: yeah, so totally unfair :-/
<fullermd> MP maybe?  My 7.x box is 2-core, and 8.x is 4-core.  It doesn't seem overly likely that that would matter, would it?
<fullermd> The tests are sequential...
<vila> MP leading to revision not found, wow, you're truly desperate :)
<vila> my VM is 4 cores
<fullermd> I can't imagine how it would, since (a) any given test is sequential, and (b) it's so stupidly perfectly repeatable.
<fullermd> But yeah, desperate   :p
<LarstiQ> f00f bug?
<fullermd> That was lockups, not VCS horkage   :p
<fullermd> (and bzr _better_ not be doing floating point division, either...)
<vila> endianess ?
<fullermd> We're all little-endian.
<vila> sadly, yes
<vila> just checking
<fullermd> I wonder if anybody IS running bzr big-endian.  SPARC I guess.  AIX guys maybe?  Isn't RS/6000 big-endian.
 * LarstiQ has retired his ppc :(
<vila> RS/6000 is power-era old I believe, so probably
<vila> I have a BeBox...
<fullermd> First *nix system I adminned was an RS/6000.  The scars are still quite visible.
 * fullermd twitches.
<vila> Pff, SunOS was worse I'm sure
<fullermd> SunOS was a dream, relatively   :p
<vila> ouch :)
<vila> I did UUCP sendmail !
<jelmer> moin *
<fullermd> I certainly don't believe you have some magical data corruption causing tests to _pass_.  That would be nuts.
<fullermd> And I know I don't causing them to fail.  It wouldn't be near so deterministic, and anyway I have ECC memory and ZFS with SHA256 block checksums.
<fullermd> (if my data goes, I intend to KNOW about it)
<vila> zfs...
<fullermd> Timing issues?  Wouldn't be deterministic.  System libraries?  Ours should be near enough as no difference.
 * fullermd frowns.
<vila> racing issues with zfs sounds worth checking
<fullermd> What race?  All it does is read the .py_ files.
<vila> fullermd: if I knew I wouldn't want to try
<fullermd> Temp files are gone so fast they'll never hit disk, and even if they did, they'd be read back out of the buffer cache.
<fullermd> (and anyway, my /tmp is plain old md-backed UFS)
<vila> all the tests run in /tmp
<vila> md-backed ?
<fullermd> Memory filesystem, swap backed (but it never needs to hit the swap)
<fullermd> (well, memory block device actually)
<vila> hmm, I didn't set that for freebsd, but I use it for jaunty
<fullermd> Ordering?  No way, I can run any of them individually and get the same failure.
<vila> !!!
<fullermd> I guess I'll have to find time at some point to sit down with one of them and try single-stepping   :(
<vila> fullermd: I'm trying to see if one is simpler than the others
<fullermd> Well, the first one on the list is probably the obvious choice.
<fullermd> blackbox.test_info.TestInfo.test_info_standalone
<fullermd> I think the rest are per_whatever's, so there are lots of formats to loop through.
<vila> blackbox tests are hard to debug because of the redirections (not all though)
<vila> pfff, talk about LOCALIZATION DEFECT, seen the test in question ?
<vila> 433 lines...
<vila> <cough> sorry for yelling
<LarstiQ> yeah, the info tests...
<vila> ...besides, that defect localization, so there
<vila> fullermd: can you try with a newly created user (just to rule out some more possible leaks)
<vila> fullermd: running a single failing test should be enough
<SamB_XP> but what if it doesn't fail!
<SamB_XP> then he'll have to run *another* one!
<jelmer> SamB_XP: ^
<jelmer> SamB_XP: there is a bzrtools package in experimental
<jelmer> SamB_XP: there is no bzr-doc package
<SamB_XP> jelmer: there isn't ?
<SamB_XP> than what was that thing I had installed ?
<jelmer> SamB_XP: "rmadison bzr-doc" agrees
 * SamB fires aptitude up
 * SamB wonders why his computer rebooted almost 5 hours ago, anyway ...
 * SamB thought he'd fixed that by making it clock down when it got hot ... but could it have been a power outage of some kind ?
<SamB> jelmer: it's from bzr ppas
<SamB> the available versions are, uh,
<SamB> 1.18-1~bazaar1~jaunty1 and 1.18+4684+126~9.04
<SamB> jelmer: and I am not seeing this experimental package you speak of
 * SamB notices that the PPA packages of bzrtools are laxly versioned
 * SamB tries one of those
<SamB> (er, have laxly-versioned dependencies on bzr, that is)
<SamB> ... heck, it apparently even loads ...
<SamB> jelmer: so, you should really sync up with the PPAs somehow ?
<SamB> in terms of what packages are built for bzr itself ;-)
<jam> vila: did you land the setup.py change to the bzr/2.0.0 branch?
<jam> (morning)
<vila> morning jam !
<vila> pqm'ed it when I said "I'll merge"
<vila> something wrong with it ?
<vila> jam: I thought you had an already full plate this week...
<jam> I haven't seen it yet, and I'm hoping to have win32 installers for them to use
<jam> vila: looks like it is just in pqm now
<vila> jam: was about to tell you that :-) Just in front of yours
<jam> I guess you said "ill merge" 20 min ago
<jam> so about right
<jam> vila: I'm just waking up
<vila> jam: how are things going ?
<vila> Running [ 0% 1 test(s) ] Current test: /home/pqm/bzr-pqm-workdir/home/2.0.0/bzr
<jam> the training and such is going fine. It's pretty informal
<jam> vila: I'm pretty sure the status line is completely borked :)
<vila> :-D
<vila> too bad....
<jam> And now that we have no "[ascii]" tests, I don't usually have a good feel for when it will be done
<vila> jam: well, you feel it's faster at least :)
<jam> vila: sort of... it is still something you send out and then forget about by the time you get the success/failure message
<jam> vila: of course, while all of this is going on, igc and bialix are changing the installer, and how we build the installer, and ...
<jam> It is all good in the end
<jam> but painful for me
<jam> even stupid stuff like now we depend on "doc.bazaar-vcs.org" for the pre-compiled help files
<jam> which means I have to add the doc.bazaar-vcs.org to the hosts file so that it can be found
<vila> :-/
<jam> for some reason buildout is *really* slow (maybe just the machine?)
 * vila is still slowly setting up a windows dev env as automatically as possible...
<jam> vila: is bug 424913 a wishlist or a won't fix?
<ubottu> Launchpad bug 424913 in bzr ""bzr pull -r 10000" doesn't pull entirety of 9998-rev branch" [Wishlist,Confirmed] https://launchpad.net/bugs/424913
<vila> a wishlist
<vila> The wish is that the error message could say:
<vila> revno 10000 does not exist, the last revision is: YYYY
<vila> which might work as well.
<vila> comment added there
<jam> vila: And my point is I don't think we are going to ever do that...
<SamB> huh, so much for multi-pull -q :-(
<jam> the issue is where are you strict about input, because it indicates typos
<jam> the actual desire of the person in that bug is to have resumable fetch...
<vila> jam: you can be strict and displays an informative message
<jam> anyway, still trying to get 2.0.0rc2 built, but I have to go get some food
<SamB> jam: that person is me, btw
<vila> SamB should speak with bialix who wants to implement a multi-step push/pull
<vila> SamB: *I* know :)
<jam> vila: imo, we should change the internal to just fetch 1k revs at a time... but certainly it can be implemented otherwise
<vila> SamB: Let jam wake up peacefully please
<SamB> it was so wierd to slowly realize that he was talking about me ;-)
<vila> oops forgot a smiley there
<vila> jam: I missed the discussion but bialix seemed to think the consensus that this will not happen, or not soon
<jam> SamB: I don't see how any of this would block a "multi-pull -q"
<jam> If you have a command that ones to pull a bunch of branches
<SamB> jam: that was an unrelated statement
<jam> have it connect, find the last revision, and then split it up
<SamB> I said that before I noticed you had been talking about me ;-)
<SamB> I said it because it's not all that quiet ...
<SamB> ... even if I give it /dev/null for stdin and pass stdout and stderr through cat :-(
<fullermd> Ew.  I'm not cleaning THAT litterbox...
<SamB> well, I'm rather pleased that that didn't affect it
<SamB> but displeased that it was not quiet
<vila> SamB: file a bug
<vila> with at least the strings that escape your humt :)
<SamB> vila: well, I guess I'd better try the latest first to make sure
<vila> hunt, damn it
<SamB> my hunt ?
<vila> track ? redirecting stind because -q does not work sounds like "output hunting" to me :)
<SamB> oh, I thought maybe you were suggesting that I ought to look inside ...
<vila> feel free to hunt where you see fit...
<SamB> hmm, "push -q" with no explicit target isn't quiet either
<SamB> okay
<SamB> somebody seems to be trying to use my uncylclopedia account ?
<SamB> (maybe they thought it was theirs ?)
<jam> vila: http://pqm.bazaar-vcs.org/
<jam> I see [ascii] tests running...
<jam> maybe it wasn't "fixed" on the 2.0.0 branch?
<vila> 8-) Ouch, fixed in trunk after 2.0 splitted I guess
<vila> err, that was 8-(
<fullermd> Isn't that intentional?
<vila> fullermd: the typo or the [ascii] tests ?
<fullermd> The ASCII tests.
<vila> The constraint was relaxed because the botnet took charge.
<vila> They have been deactivated in trunk only (jam, I just checked, still active in 2.0 and 2.0.0)
<fullermd> Yah, but I thought I remembered it coming up in the discussion to explicitly choose conservative for 2.0.
<lifeless> jam: lp:~lifeless/meliae/db
<emmajane> igc, ping?
<emmajane> igc, I'm just reviewing your changes trying to understand why you've changed a lot of the work that I'd already put into the Wiki as links for the footer?
<beuno> emmajane, hi
<emmajane> beuno, hey
<beuno> emmajane, I have not caught up on all the emails
<beuno> but, how's the web going?
<beuno> do you need any more designer foo?
<emmajane> beuno, I still need the buttons done. There's no photoshop file though. It's all in the branch.
<beuno> emmajane, have you talked to Danno, is it on it's way, etc?
<emmajane> beuno, What I emailed on Friday is the last email I sent about the project. I was travelling this weekend.
<emmajane> beuno, and today is my first day back in the office.
<emmajane> (which is what I said in the email...)
<beuno> emmajane, ok, cool. Email me and CC Danno about what you need, and I'll chase it up
<emmajane> thanks.
<beuno> I'm off again wed-fri, but I can peak at email every now and then
<emmajane> seems to be a common time to take off. :)
<emmajane> are you in London now?
<beuno> emmajane, no, Madrid. Will land in London on Sat
<emmajane> nice!
<beuno> well, "nice" is a very flexible word...
<emmajane> heh. Oh dear. :/
<beuno> I mean, what kind of country has 2 sunny days a year?  :)
<emmajane> LOL
<emmajane> canada. ;)
<emmajane> England.
<emmajane> Ireland.
 * emmajane could go on....
<beuno> ok, I'll rephrase
<beuno> what kind of country that I have to go to 4 times a year...
<beuno> :)
<emmajane> hehe
<emmajane> What's in Madrid that you're going four times a year?
<beuno> London is the 4 times a year
<beuno> Madrid has great weather
<emmajane> ahhh, right.
<beuno> I haven't worn shoes since I got here
<emmajane> heh
<vila> beuno: from Madrid to London, feel free to stop at Strasbourg :-)
<beuno> vila, I was actually in Paris for 4 days!
<beuno> I thought of pinging you, but it didn't look very close on the map  :)
<vila> hehe, far closer now with TGV but still...
<fullermd> Ah well, ports freeze beat 2.0.0.
 * Tak <3 tgv 
<vila> Tak: where are you from ?
<vila> fullermd: you didn't inject 2.0rc1 ? :)
<Tak> vila: I'm from florida
<garyvdm> Hi bialix.
<bialix> Hi Gary
<bialix> how do you do?
<garyvdm> Good and you?
<garyvdm> bialix: If Bug 423201 is still a problem, I can talk you through debugging it.
<ubottu> Launchpad bug 423201 in qbzr/trunk "qlog branch1 branch2 shows incorrect labels when branch2 is merged into branch1" [Medium,Confirmed] https://launchpad.net/bugs/423201
<bialix> garyvdm: I've made screenshots for you
<bialix> I think you saw it
<bialix> but then I've deleted those branches
<bialix> garyvdm: if you think you fixed them again, it's fine
<bialix> but I think we'd like to write some tests in some future
<garyvdm> bialix: Yes - I fixed the one problem(that the branch is not expanded), but I was not able to reproduce the 2nd (label shows on wrong rev).
<garyvdm> Ok - cool
<bialix> maybe vila will be interested to help
<garyvdm> Hmm - a test for that wont me to hard.
<bialix> garyvdm: I have backup of that repo
<garyvdm> *be
<bialix> if you want I can provide you it privately
<garyvdm> I think it is fixed..
<bialix> garyvdm: I found that different parameters of qlog command line have different impact
<bialix> maybe that's why you were unable to reproduce
<bialix> garyvdm: thanks for fixing it, anyway!
<garyvdm> bialix: Do you mean the order that branches are specified?
<bialix> yes, something like that
<garyvdm> bialix: The order affects what it thinks is trunk, but it should not affect the labels.
<bialix> at least there is clearly difference between running qlog b a vs qlog over shared repo in the other bug report
<bialix> garyvdm: this is my impression too, but sometimes I'm just don't understand what's going on
<garyvdm> Yes - for qlog b a, trunk=b, but for qlog ., trunk=a
<garyvdm> err - no,  but for qlog ., trunk=none, hence dates are used.
<bialix> garyvdm: btw, one idea about missing labels
<bialix> if you collapse merged branch tip its blue label becomes hidden
<bialix> and it's almost impossible to know where it hidden
<garyvdm> ok
<bialix> garyvdm: maybe in this case we can show some hint?
<garyvdm> or not allow you to collapse it.
<bialix> maybe we need to show something to say: look here: something hidden inside
<bialix> not allow to collapse? I guess it will be hard to implement, no?
<garyvdm> No - easy
<bialix> or something like that
<garyvdm> bialix: I was thinking about how we add non-versioned files in qcommit.
<bialix> and?
<spirov92> I'm trying to do branch /htdocs/myproject/ ftp://myproject.com/ but how should I supply the username&password?
<garyvdm> If we were to add non-versioned files immediately when the are checked, and remove added files when they are unchecked, this would give us some wins...
<vila> spirov92: user:pass@myproject.com is the direct way, look at authentication.conf for something a bit more secure
<spirov92> vila: thanks
<vila> spirov92: authentication.conf is described in the doc
<garyvdm> It would fix diff for checked non-versioned files. Checked non-versioned would be remembered.
<vila> spirov92: bzr rm <file> --keep
<vila> spirov92: you quit before I could replied this morning
<garyvdm> bialix: What do you think about that?
<spirov92> oh, thanks
<bialix> garyvdm: hmmmmmmmmmmmmmmm
<bialix> garyvdm: how fast it will be?
<garyvdm> bialix: as fast a bzr add, which is instant.
<bialix> garyvdm: me personally thinks will be much simpler to fix or internal diff behavior and teach it about planned add
<garyvdm> bialix: I was thinking about the message template stuff too.
<vila> spirov92: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings
<vila> oh no, he's gone again :-(
<garyvdm> vila: :-(
<vila> bialix: since we talk about that yesterday, see what happens just now with spirov92 ?
<garyvdm> bialix: But I think I have a solution for that now. Bouncing ideas is good.
<bialix> garyvdm: if you think it will not slow down us (and I seriously doubt about it) then ok
<bialix> vila: sorry? I've not watched carefully
<vila> never mind
<bialix> vila: but anyway excuse moi s'il vous plait
<vila> :-)
<bialix> garyvdm: what is bouncing idea?
<vila> either: "Excusez-moi s'il vous plait" or "Excuse-moi s'il te plait" :-D
<garyvdm> bialix: What I was doing now. Telling you about ideas.
<vila> bialix: you just bounced ideas back and forth with garyvdm
<vila> he says: "What if...", you reply "Yes, but..." etc
<vila> the idea goes back and forth bouncing
<bialix> vila: ok, "Excusez-moi s'il vous plait"
<bialix> vila: my francais is definitely is not good
<bialix> bear with me
<vila> I do :)
<bialix> sorry guys, a bit busy now
 * bialix bbl
<vila> bialix-webinar: staying connected like that is waaaaay better even if you don't reply than *not* being connected at all :D
<bialix-webinar> vila: I guess I need 24/7 IRC proxy to be 100% accessible to you
<spirov92> I'm trying to create a branch by ftp, but I get this error:
<fullermd> bialix-webinar: He could hire you as a butler instead; that would work too  ;)
<spirov92> Transport error: FTP temporary error during APPEND /var/www/html/new/.bzr/repository/upload/5jmrc2341kekjwb6e0il.fetch.Aborting. 451 /var/www/html/new/.bzr/repository/upload/5jmrc2341kekjwb6e0il.fetch: Append/Restart not permitted, try again
<vila> not me in particular, but quite often you ask a question and leave before I or other can answer or you're not there when we want to ask you a question :-) so 24/7 is a bit high but 8-17 could be a good compromise :)
<vila> ha spirov92 is back...
<spirov92> yep
<spirov92> so, can anyone help me?
<vila> you quit before I can give you the url for the doc about authentication.conf
<vila> spirov92: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings
<spirov92> thanks :)
<LarstiQ> spirov92: the ftp server is configured in a nasty way
<spirov92> so, what can I do to fix it? :P
<vila> now, Append/Restart not permitted means the server doesn't support a feature needed by bzr, 'try again' is a bit silly since there is little chance that it will change unless you can contact the admins
<vila> spirov92: are you the ftp server admin ?
<spirov92> no
<vila> ask him to allow APPEND
<spirov92> ok
<vila> or better, ask him to install bzr and ssh so you can use bzr+ssh:// instead ftp:// you'll get far better performances
<fullermd> Or at the least support SFTP.  It makes me weep that FTP still exists outside of very special cases   :|
<vila> fullermd: not everybody knows how to *install* sftp you know, in some parts of the world it's not even part of the *base* system :-P
<fullermd> Well, in some parts of the world they don't have running water either.  FTP shouldn't be given a chance to get a foothold there   :p
<vila> hehe, I'm afraid they'll get Linux before BSD there :D
<fullermd> I'm pretty sure every major Linux dist ships with working SFTP support these days.  So that'll tide them over.
<vila> *support* doesn't mean installed by default, hence my initial remark...
<vila> I wasn't joking about third world but about cheap ISPs instead...
<LarstiQ> fixing https://bugs.edge.launchpad.net/bzr/+bug/409615 would help
<fullermd> Oh, I'm pretty sure it does.  If it's got OpenSSH, and hasn't taken moderately serious steps to avoid it, it's got SFTP.
<ubottu> Launchpad bug 409615 in bzr "bzr shouldn't use ftp append when writing a whole file in one go" [Low,Confirmed]
<LarstiQ> well, not help against ftp actually
<fullermd> And I don't think any of the dists ship ssh.com's ssh stuff.
<LarstiQ> fullermd: the subsystem is disabled on a number of dists
<fullermd> It...   what?  Why the spit?
<LarstiQ> fullermd: that, and really cheap hosts don't give you ssh
<vila> It's a cultural thing, people still thinks that ftp is easier to install/manage than sftp
<fullermd> Sure, but you can give sftp without letting them have a shell.  I didn't know about default-disable though.  That sounds positively antediluvean.
<fullermd> Plunk them lunkskulls in front of a firewall config that tries to be reasonably tight and allow FTP to work for a few days, that'll learn 'em.
<vila> fullermd: You're preaching the choir ! It's not a technical problem :D
<vila> Ha, I see, you're getting it and are in the concrete proposal phase now
<fullermd> Right, that's why we choose means carefully.  Technical problems call for technical solutions; social problems call for mass murder   :p
<vila> LOL
<fullermd> Darwin will win in the end.  Sure, it may be a pyrrhic victory, but the 17 people left alive in the world will have a peaceful time.
 * vila enjoy launghing again without his rib hurting, that;'s the best news of the week :-D
<vila> well, at least for me it is :D
<fullermd> "... so Adam said, 'What can I get for a rib?'"
<vila> ...a good laugh ?
<fullermd> Old joke.
 * fullermd pulls up Google.
<fullermd> http://www.azarajokes.com/pe-What+can+I+get+for+a+rib%3F-1400-140000-210.htm
<vila> I was close enough...
<garyvdm> lol
<vila> http://www.alexshalman.com/2007/10/02/what-kind-of-woman-can-i-get-for-a-rib/
<vila> that one is more explicit :)
<spirov92> hey, I branch'ed a local branched to an sftp server, but only the .bzr folder is created. How do I make the actual files appear?
<spirov92> &branch
<spirov92> *branch
<beuno> spirov92, bzr co .
<spirov92> but the server doesn't have bzr. so can I do bzr co ftp://admin@mysite.com/ or something?
<beuno> I... think not
<beuno> spirov92, if you just want the contents, you can use the bzr-upload plugin
<vila> spirov92: ',bzr' contains everything that is needed to create a branch
<spirov92> beuno: yeah, that's an option too
<vila> beuno, spirov92 " of course you can 'bzr co ftp://' but it will create a branch locally not the working tree remotely
<vila> look at 'bzr help co'
<naoki_> Hi.
<naoki_> Little question about doc.
<naoki_> 'Simple developer naming' in shared_repository_layout.txt,
<vila> hi noaki !
<naoki_> Does this mean only one branch per developer?
<naoki_> hi vila.
<vila> naoki_: where did you find that (for context) ?
<beuno> vila, I think that's in docs/
<vila> can't find a file named shared_repository_layout.txt there :-/
<naoki_> yes, docs/en/user-guide/shared_repository_layout.txt
<vila> missing 's' layouts, stupid emacs, can't fix obvious typos
<naoki_> oh, sorry
<vila> naoki_: not your fault :)
<fullermd> Unless you're Richard Stallman.  Then it's totally your fault.
<vila> naoki_: so, back to your question, no, in that layout there is no limit on the number of branches
<vila> there is no limit to the number of levels in the hiearchy either,
<naoki_> I get it.
<naoki_> Thank you.
<vila> you can, for example, add an intermediate level for groups above devs
<vila> or even depts above groups, etc
<naoki_> Japanese translation of user-guide is complete in near future.
<vila> naoki_: Hurrah ! Congrats :D
<vila> garyvdm: still around ?
<garyvdm> hi vila
<vila> https://code.edge.launchpad.net/~garyvdm/bzr/427773-2.0-unlock-when-limbo/+merge/11631
<vila> garyvdm: poolie approved it but in bug comments, and I can't review it...
<garyvdm> Ah - ok
<vila> (I came across it while filing another bug)
<vila> garyvdm: can you add another review request that I can use ?
<vila> garyvdm: in that same mp
<garyvdm> vila: Done. Here is superseded request: https://code.launchpad.net/~garyvdm/bzr/427773-2.0-unlock-when-limbo/+merge/11776
<garyvdm> vila: Superseded because I discovered a mistake that I have fixed.
<vila> ok, good enough, but you could have done it without... ok
<vila> :)
<vila> oh yes, the renamed test
<pwolanin> Can anyone point me fo instructions for taking an existing source package in launchpad, then making my own version, and then getting it into a PPA so it will build?
<vila> pwolanin: try #launchpad instead
<pwolanin> ok, thanks
<garyvdm> vila: I was not sure where to put the news entry.
<vila> yeah, yeah, don't worry, still a work in progress, these NEWS sections in this new release branchesss
<garyvdm> ok
<vila> :)
<garyvdm> vila: And Martin approved for 2.0.1, not for 2.0.0.
<vila> I see, that's why you targeted 2.0 and that's where I will pqm it
<garyvdm> vila: I'm not sure if 2.0.0 has been branched yet.
 * garyvdm checks
<vila> garyvdm: it has, I already landed a fix by bialix
<garyvdm> Ok
<bialix> vila: which fix?
<garyvdm> ah lp:~bzr-pqm/bzr/2.0.0
<vila> bzr log -l 12 lp:~bzr-pqm/bzr/2.0.0
<vila> bialix: ^
<vila> fix in setup for qbzr py2exe
<bialix> limbo fix is gary work
<bialix> ah, py2exe
<bialix> yes
<bialix> vila: do you saw my setup.py loader proof of concept?
<vila> bialix: hmmm, not sure,
<bialix> bzr-windows ML
<vila> I saw some related mails, but I'm not sure I saw a patch
<bialix> jam said that loading stuff from several plugins setup.py is bad idea
<vila> yeah, I think there is some misunderstanding there
<bialix> vila: lp:~bialix/+junk/plugins-setups
<vila> bialix: I won't have time to look at it  today :-/
<bialix> np
<bialix> I don't insist
<bialix> just a heads up
<garyvdm> Hmmm - I passed to Merge3 base = "A" , this = "A", other ="". I expect to get out "", but I got"<<<<A====>>>>
<vila> sure, remind me tomorrow if I don't give feedback
<bialix> bye, vila, garyvdm
<garyvdm> bye
<vila> bye all
<gioele> hi
<gioele> which version of bzr-svn should one use with bzr 1.18?
<weigon> gioele: see http://bazaar-vcs.org/BzrForeignBranches/Subversion#releases
<gioele> argh, bzr-svn 0.6.5 has not been packaged yet in the PPA
<zsquareplusc> is that the reason i can't make a system upgrade anymore? without removing bzr-svn anyways ;-)
<RenatoSilva> verterok: hi, long time no merge :)
<verterok> RenatoSilva: Hi
<verterok> RenatoSilva: merge? oohhh the merge proposal
<verterok> RenatoSilva: I found a weird issue, but I don't have logs in my laptop, I'll comment on the merge proposal or write  test case for it (hopefully tonight or tomorrow)
<verterok> RenatoSilva: apologize the delay :(
<james_w> hey verterok
<RenatoSilva> verterok: ok np :) so you found a weird issue with the patch?
<verterok> RenatoSilva: with the uri en/decoding
<verterok> james_w: hey!
<RenatoSilva> verterok: you found that manually written method weird at all or you had an specific issue?
<RenatoSilva> verterok: iirc I had to write that method as default URL encoding doesn't do the required job... let me take a look to recall...
<carljm> hi all - is there any way to get bzr to tell me which revision deleted a file? "bzr log thefile" just says "Path does not have any revision history." But it does, because I can "bzr revert" to an earlier revision where it exists. Do I have to bisect manually?
<verterok> RenatoSilva: I builded the plugin with the patch and installed it, and got and error while playing with push/pull
<RenatoSilva> verterok: hum... please let me know if you get any info/log about it
<verterok> RenatoSilva: I need to take a look too, but I'm in the middle of a sprint ATM
<verterok> RenatoSilva: sure :)
<verterok> RenatoSilva: I mostly tried to work on the dependency split and bundling of xmloutput, I'll take a look to this tonight
<RenatoSilva> verterok: http://bazaar.launchpad.net/~renatosilva/bzr-java-lib/encoding-fixes/revision/201
<RenatoSilva> verterok: at a glance I'd say urlEncode() needs a fix, I think it won't work for non-ascii-finished strings
<RenatoSilva> verterok: besides iirc URLEncoder.encode() also encodes ascii chars, then I had to write urlEncode() for encoding non-ascii only
<verterok> RenatoSilva: ok, those are good news :)
<RenatoSilva> verterok: Patch for non-ascii-ending URLs encoding: http://pastie.org/617917. Not compiled yet :)
<verterok> RenatoSilva: :)
<verterok> RenatoSilva: cool!. please push it to the same branch, and in the merge proposal change it status to resubmit (that way I get a mail with the updated marge proposal ;))
<RenatoSilva> verterok: at home :) no ssh at work and no http push at lp :(
<verterok> RenatoSilva: sure, no hurry :)
<thefirstdude> how do I make a branch
<jam> lifeless: I got your branch, but I haven't had any time to look at it yet
<lifeless> jam: it has a minor bugfix for the C layer
<jam> igc, bialix, garyvdm: I've encountered some fairly critical bugs in the qbzr/bzr-explorer on Windows that I'll be working on tonight
<lifeless> jam: and my db work so far
<lifeless> jam: are you still in canadia?
<jam> lifeless: yes, I leave Thurs night
<jam> it was extra fun to have segfault bugs in qbzr while demoing it to the client
<lifeless> :) I was just reading that bug
<jam> has anyone heard if/when qbzr might switch to --2a format?
<jam> lifeless: yeah, doing some live training using Bazaar Explorer with inexperienced users was rather enlightening
<jam> hence the... 10+ bugs I opened
<lifeless> 20495872 nodes of the graph imported
<jam> It also shows that we don't actively have people dogfooding Bazaar Explorer as a production thing
<jam> lifeless: into sqlite?
<lifeless> yah
<jam> though... it still leaves the question of how many nodes you actually have :)
<lifeless> 40million
<jam> ah, so not bad, 50% there
<lifeless> I wanted to talk to you about guis with area maps
<lifeless> you use runsnakerun I think ?
<igc> morning
<igc> hi jam, lifeless
<lifeless> hi igc
<igc> jam: thanks for the bug reports
<igc> jam: I'll take a look asap
<jam> igc: I've got a fix for the critical one (segfault)
<jam> though I have to redownload qbzr trunk because it is in a 2a repo
<jam> lifeless: https://code.edge.launchpad.net/~jameinel/runsnakerun/memory_dump_integration
<poolie> hello jam!
<jam> hi poolie
<jam> lifeless: I don't know the current state of that branch, as it was a bit hacking
<jam> hackish
<jam> but it worked last I checked
<poolie> how's the trip?
<jam> poolie: overall pretty good
<jam> had some critical bugs that were a bit embarassing
<lifeless> jam: I figure if I can make its queries abstract; I can generate a thunk to sqlite
<jam> lifeless: certainly could be interesting
<lifeless> jam: and then do a single long running analsysis/caching of aggregates in the db
<jam> I'm curious how much you would end up loading for any given operation
<lifeless> followed up by quick rendering and exploring
<lifeless> jam: I'm thinking no more than 20 references deep
<lifeless> or even 10
<lifeless> jam: oh also
<lifeless> jam: 'expensive references' - why do you fold them to zero rather than removing ?
<lifeless> hi poolie
<jam> lifeless: you mean pointing them at a null object?
<jam> It was a "not quite sure what to do, let's try this" sort of thing
<lifeless> poolie: I'm feeling middling; I'm going to see how it goes, if I stop thinking I'll go to bed & file a sick day thingy in the system
<poolie> k
<jam> It could be useful to know that this object has 100k outgoing references
<thumper> jelmer: for updating LP's bzr-git, should we grab tip?
<mwhudson> jelmer: same question for dulwich btw
<lifeless> jam: funny you should mention :P - I have at least one object with 900000 references
<lifeless> in this dump
<jam> lifeless: probably intern dict
<jam> that is usually the big one
<jelmer> thumper, mwhudson: yeah, tip is best
<lifeless> vila: are you around, by any chance?
<thumper> jelmer: ok
<igc> lifeless: hope you're feeling better soon
#bzr 2009-09-16
<mwhudson> jelmer: how much of a good idea is upgraded dulwich?
<lifeless> igc: thanks
<poolie> wow, vila went crazy on the bugs
<poolie> hello igc
<poolie> want to catch up some time?
<lifeless> spm: ping
<lifeless> spm: balleny's pqm is dying
<lifeless> Permission denied (publickey).
<jam> igc: think you could look at https://code.edge.launchpad.net/~jameinel/qbzr/bug_430232_early_qapp/+merge/11831 ?
<lifeless> I think the backtrace is a furfy
<jam> I'd like to get it into a bzr installer tonight if at all possible
<igc> jam: shall do
<jam> mmmmmm furfy
<igc> poolie: let me look into these bugs for jam. Call around lunch time ok?
<poolie> fine with me
<thumper> jelmer: why is the trunk dulwich branch on LP registered as remote?
<SamB> thumper: most of jelmer's branches are ;-)
<SamB> he likes to keep them on samba.org for some reason
<poolie> who does the os x installers now? guillermo?
<jam> SamB, thumper: I'm pretty sure jelmer wants people to get "the absolute latest" when they do "bzr branch lp:dulwich" and not a potentially 5-hours out-of-date mirror
<jam> That was the argument he gave earlier for bzr-svn, IIRC
<jam> since he doesn't want to directly host them on lp
<thumper> why ever not? :)
<thumper> we're open now :)
<SamB> most of *my* mirrored branches are supposed to update hourly
<SamB> thumper: probably he likes having direct access to the part of the filesystem on which he keeps them ?
<SamB> well, more direct, I mean
<lifeless> jml: Around?
<poolie> emmajane: btw if you're around i have checked the moderation queues and there's nothing interesting held there
<SamB> of course, 2/3 of my mirrored branches are mirrors of SVN branches
<SamB> and the other one of a branch that launchpad never manages to pull
<SamB> well, that's calculated by project and not by branch, actually
<jml> lifeless, yes
<SamB> ... though *one* of those SVN mirrors is not strictly read-only
<SamB> ... if anyone has any dosemu branches they'd like merged, don't hesitate to submit a merge request ;-)
<igc> jam: that patch looks good to me
<jam> igc: so do you know what the 0.14 branch is for?
<jam> Is qbzr going to be doing a stable branch as well?
<igc> jam: 0.14 is the branch for karmic
<igc> jam: and the Windows 2.0.0 release as well
<jam> igc: sure, I was just wondering if the plan was for 0.14.x to be part of the 2.0.1+ releases as well
<igc> jam: I suspect 2.0.1 with go out with qbzr 0.15 but that's up to bialix and garyvdm to make that call
<lifeless> jml: http://rbtcollins.wordpress.com/2009/09/16/back-from-hiatus/
<jam> igc: well technically it is probably up to me, since I'll likely be doing the packaging :)
<igc> jam: I'm certainly planning for explorer 0.9, not 0.8.x, to go out with 2.0.1
<igc> jam: :-) :-)
<lifeless> jml: I thought you might either a) know of something, or b) have thoughts on the proposition
<jam> but usually I just follow the recommendations
<poolie> rebooting for karmic
<igc> jam: do you want me to merge that change to 014? Or is your connectivity good enough?
<jam> igc: I'm landing it now
<jam> I'm not sure what it will take to do a 0.14.2, though
<jam> so I may just take it and do 0.14.1-win32-1
<jam> igc: is dancingmonkeys continually updated?
<igc> jam: what do you mean by that?
<igc> it's just a branch I push after making edits
<jam> igc: how often does http://people.canonical.com/~ianc/dancingmonkeys/ update
<igc> whenever I manually update it
<igc> emmajane has the master branch - my stuff is just suggestions/experiments
<jml> lifeless, looking...
<lifeless> jml: thanks
<spm> lifeless: should be happening again
<lifeless> spm: what is needed for subunit in the chroot ?
<spm> lifeless: aiui, a package built; but I'm not across all the details; so that's a pretty handwavy response.
<lifeless> spm: all we need is python-subunit
<lifeless> you have packages of that :)
<spm> not for dapper, aiui
<lifeless> shouldn't matter
<lifeless> spm: you should be able to just dpkg -i the python-subunit package
<lifeless> spm: can you do a manual push from balleny +trunk ?
<spm> lifeless: I believe it also had a requirement on python-central which also wasn't in dapper. tbh, these may be trivial workarounds. I know that lamont and tom have been working on this stuff, so I'm kinda coming in with a fraction of the picture here.
<spm> bzr trunk? sure. one sec.
<lifeless> spm: did it have any revisions to push ?
<spm> lifeless: Pushed up to revision 4690.
<lifeless> 5 commits old ><
<spm> it had had a push branch location of you@escudero if that helps?
<lifeless> no
<lifeless> thats the old location
<spm> k
<lifeless> you should save the new ones
<spm> did on this case; it seemed the right thing to do :-)
<lifeless> pqm uses the configured value in the pqm.conf though, so that shouldn't have mattered
<spm> hang a sec.... $ bzr push --remember bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev ;; yet still shows: push branch: sftp://robertc@escudero/srv/www.bazaar-ng.org/rsync/bzr/bzr.dev
<spm> is that an issue? or did I syntax it?
<lifeless> check ~/.bazaar/locations.conf
<spm> ahhh. right. I see - I guess THAT should also be updated.
<lifeless> or removed
<lifeless> [the stanza not the file]
<spm> :-)
<lifeless> statik: http://elliotmurphy.com/ is down?
<spm> lifeless: that stanza has post_commit_to bits; I assume that no longer matters now via LP
<lifeless> correct
<lifeless> uhm
<lifeless> actually
<lifeless> lp's pqm uses lp notifications
<lifeless> I think we still get the ones to bazaar-commits.
<lifeless> whats the stanza? [paste it somewhere]
<spm> [/home/pqm/archives/thelove/bzr/+trunk]
<spm> post_commit = bzrlib.plugins.email.post_commit
<spm> post_commit_to = bazaar-commits@lists.canonical.com
<spm> push_location = sftp://robertc@escudero/srv/www.bazaar-ng.org/rsync/bzr/bzr.dev
<spm> small enough to go here
<lifeless> delete the post_commit and push_location lines
<spm> kk
<lifeless> the former is deprecated the latter wrong :P
<spm> heh
<spm> info -v looks much happier. ta
<BasicOSX> bzr.dev/bzrlib/osutils.py:928: UserWarning: bzr: warning: Failed to load compiled extensions: <snip> how do I compile these extensions?
<lifeless> BasicOSX: 'make'
<BasicOSX> pages and pages of errors under os x :-(
<lifeless> hmm
<lifeless> there is an installer for os x
<lifeless> you might want to look at the docs on how that is built, and follow that process
<BasicOSX> defeats the purpose for running bzr.dev by using installer :-)
<lifeless> nono
<lifeless> I'm not saying use the installer
<lifeless> I'm saying follow the docs on how to build it
<lifeless> to get a built bzr
<BasicOSX> That doesn't seem very pythonic  ... whole reason I picked bzr was simple install and go. If I wanted to compile stuff I would have picked git :-( I hope there was magnitude performance increases by going with .pyx
<verterok> poolie: hi
<lifeless> BasicOSX: so, I think you can squelch that warning
<lifeless> I think poolie: ^ might know
<lifeless> BasicOSX: and yes, _huge_ performance differences
<lifeless> BasicOSX: we do run fine without the extensions.
<BasicOSX>   yes, done already, just venting on simple (slow) vs complicated and fast
<poolie> hi verterok
<lifeless> BasicOSX: my personal vent is on python being slow :)
<verterok> poolie: re: os x installers, what's up?  :)
<poolie> BasicOSX: 'echo ignore_missing_extensions=True >> ~/.bazaar/bazaar.conf' should do it
<igc> hi verterok
<poolie> BasicOSX: it is much faster so the point is to just make sure people are making an informed choice to do without them
<verterok> poolie, igc: btw, I'm trying to build a Bazaar.app bundle (without much success :()
<verterok> igc: hi
<poolie> if you can think of a better way to handle it i'm all ears
<poolie> verterok: it sounds like a great idea, i wish you luck!
<verterok> poolie: igc idea
<BasicOSX> raw point right now, getting a hard time from the git people on the GPGMail project about bzr is a moving target and "broken" many times
<verterok> I'm having some issues to make py2app include all the packages/modules
<verterok> s/to make/making/
<igc> verterok: the *really* big issue from my perspective on OS X is getting PyQt bundled in our installer
<poolie> BasicOSX: i'm hoping that will be much more stable with bugfixes only into 2.0
<BasicOSX> I'm sending you feedback :-)
<verterok> igc: would be really cool to include it (bzr-explorer, etc), but with the current installer it's a bit difficult, a.k.a: I don't know if it's going to work at all. The bundle approach is a lot more promising
<verterok> igc: the main issue is that we must include Qt too, and it's going to be a *really* big dmg
<jam> igc: if you are around I'd like to chat about something
<igc> jam: yep
<jam> igc: so I just sent an email updating bug #430311
<ubottu> Launchpad bug 430311 in bzr-explorer "We should look into keeping connections open while a branch is "open" in Explorer" [Undecided,New] https://launchpad.net/bugs/430311
<jam> igc: but basically, I think lightweight checkouts + bzr-explorer + qbzr are a pretty bad idea
<jam> bzr-explorer always spawns a subprocess to do anything
<jam> and *so does qbzr*
<igc> verterok: I wasn't suggesting it would be easy, but I feel
<jam> which means that to go from viewing your tree
<poolie> spiv, hi?
<verterok> igc: :)
<jam> through commit and back
<jam> connects 4+ times
<igc> verterok: that 90% of mac users will end up using the GUI before long
<igc> jam: :-(
<jam> and in my testing here with an Ubuntu server
<jam> the ssh handshake is *super* slow
<jam> like >1s on the local network
<jam> I assume this is something about security issues
<jam> (I've also noticed it when using openssh to connect from an Ubuntu desktop...)
<spiv> poolie: oh, hi!
<jam> hey spvi
<jam> spiv:
<verterok> igc: fully agreed
<jam> igc: so... I have to wonder if we want to make "Checkout" heavy by default in bzr-explorer
<lifeless> BasicOSX: broken in any particular way?
<jam> I know we have the whole discussion about what things should be
<lifeless> BasicOSX: or just that the OSX installers weren't always polished?
<jam> but the alternative is trying to find a way to share connections between subprocess
<BasicOSX> Maybe poolie  can forward your my email :-)
<jam> or teaching bzr-explorer + qbzr to be done using threads ??
<poolie> i don't have any mail from you (yet)
<BasicOSX> Sent to sourcefrog email, just resent to canonical
<poolie> jelmer, hi?
<poolie> it may just be delayed somewhere
<igc> jam: I personally think 'checkouts' are only sensible when pointed to a local branch, preferably disk path accessible
<spiv> poolie: I'm finishing that userdir patch atm.
<igc> jam: so a bound branch is the answer IMO
<poolie> yay
<igc> jam: I'm looking to change the branch dialog so ...
<igc> (1) it has a 'bind this branch to parent' checkbox
<jam> igc: so... in a corporate setting, we'd like to say that all commits are auto-mirrored to the central location where everything is backed up
<jam> having a lightweight checkout pointing at a local bound branch is....
<igc> (2) warns you if the destination isn't in a shared repo
<igc> (3) opens the created location implicitly on completion
<igc> jam: but it was too risky to do before 0.8
<BasicOSX> well, will run with ignore_missing_extensions=True since depends for getting things compiled for os x are long and many :-(
<igc> jam:is ... ?
<jam> igc: a bit odd at best
<igc> jam: why do you think it's odd?
<jam> I realize it probably works, but a checkout of a bound branch is hard to give as a recommendation
<igc> jam: hmm
<igc> jam: I think checkouts are the current answer to 'shared tree' ala git
<igc> jam: bound branches are quite independent IMO
<igc> jam: and mixing the two is fine as far as I'm concerned
<igc> jam: at least conceptually - I don't know how reliable it is
<jam> igc: so internally I'm pretty sure it all works
<jam> probably conceptually the largest problem is that both are currently called "checkouts"
<igc> jam: not in epxlorer :-)
<jam> igc: well, since it doesn't have "Bound branches"
<jam> nor heavyweight checkouts
<jam> (I think)
<igc> jam: it has bound branches
<igc> jam: it's just 2 steps to set up currently: branch then bind
<igc> jam: hence my wish for a checkbox in the branch dialog
<jam> igc: so I assume you are already aware of the "Branch" should automatically open the target bug
<igc> jam: yes, I wanted to fix it for 0.8 but ran out of time
<jam> also... what about "create a working tree"
<jam> at the moment the way to create a tree in a treeless branch is to run the checkout dialog
<jam> with a target of '.'
<igc> jam: 0.8.1 already refreshes the repo view btw
<jam> which oddly, then opens the checkout in a new tab... :)
<igc> jam: we'll need to trap the '.' case
<igc> jam: 0.8 got auto-opening working for Init and Checkout but not Branch
<jam> sure, but it seems like "Work" could have a "create a working tree here" case...
<jam> at least, maybe
<jam> igc: so if you want to have a "and bind to parent"
<jam> then I have a workflow suggestion for you
<igc> fire away
<jam> which is "create a remote branch on the server, create a local branch of that, bind it, and switch my lightweight checkout to point at the local branch"
<jam> Which should really be 1 action
<igc> jam: sounds good
<jam> I also find that I really wish something like "qlog" was as directly visible as the working tree...
<jam> Possibly with just a summary of the last few revs, etc.
<igc> jam: the repo view does exactly that
<jam> I personally find the Collaborate / Explore / Work distinction difficult to track
<igc> jam: but you don't have repos there
<igc> jam: the 'virtual repo' (r workspace or whatever we call it) will too
<jam> igc: well, if we're going to switch to repos + bound branch + checkouts then maybe we will
<jam> though I just got a traceback trying to open a repository
<igc> jam: btw, try the 'extended' toolbar - it has log directly on the toolbar
<igc> jam: I use it 90% of the time
<igc> jam: I'll explain Collaborate, etc. in the User Guide when I get to it
<igc> jam: basically, one is for working with others, one is for looking at information and one is for 'local' actions that do something
<jam> igc: I like the expanded form... though I wonder why you don't think it should be the default
<igc> jam: it was orginally
<jam> igc: I guess my point for '"qlog" was as directly visible ' is that when I open up a branch
<jam> well a working tree
<jam> I have ... 90% whitespace on my screen
<jam> and digging down to find 'log' is uncomfortable
<igc> jam: I found it too busy when explaining explorer to solo developers that don't use the collaborate actions
<igc> jam: so the UI challenge w.r.t. stuff like qlog embedded is performance
<igc> jam: it's easy enough to launch and then hit refresh
<igc> (within the qlog window)
<jam> igc: ... sort of
<jam> it isn't how I would use it as a user
<igc> jam: but opening qlog every time someone opens a branch scares me
<jam> igc: faster than an ssh handshake for me... :)
<jam> 5s for bzr.dev
<igc> jam: :-)
<jam> but my specific point is that you could do the trivial view first, with only the last 10 mainline commits, with swivels that didn't do anything yte
<jam> yet
<jam> since you very quickly know the last few revs and their revnos, and whether they are merges
<igc> jam: right
<jam> igc: if I decided to spend some time on it... where would you put it to make visual sense?
<igc> jam: hmm
<jam> (i also still find that I'd prefer the working tree view to show colored status rather than having that as textual info in the left pane...)
<igc> jam: explorer has an extension mechanism right now where plugins can register 'panels' to display for various types
<igc> jam: you could do a qlog panel
<igc> that displayed for things with a working tree
<igc> or any type for that matter
<igc> jam: working tree love is coming
<igc> jam: keep in mind that explorer *code development* has mainly been an out of hours project!
<jam> well, my stomach is telling me that I better go hit the dining room or I'll be starving in another hour when they close... :(
<igc> jam: I reply to bugs on work time of course
<jam> igc: yeah... the main issue I see is that if we are going to have a gui under support
<jam> we better be able to expense some developer time to work on it
<igc> jam: and we can post 2.0
<igc> I believe
<jam> I know the whole "not a gui dev shop" thing...
<igc> jam: pre 2.0, the team focus was different as you know
<igc> jam: but I really felt passionate about having a nice GUI as well - hence my many late night these last few months
<igc> jam: grab some food - we can chat more later
<jam> well, I know wavesat is a bit concerned about using the gui...
<jam> they seem to be willing to switch to recommending the command line
<jam> I think the segfault was the big scare
<igc> jam: it would have been
<jam> well, mostly I'm saying they were thinking that switching to the command line would be a reasonable trade, rather than thinking to abandon bzr
<jam> which I was happy about
<igc> jam: I'd see how tomorrow goes with your fix landed
<igc> jam: thanks for all the feedback btw
<jam> be back later
<igc> jam: is using a smart server without ssh an option?
<SamB> oh, what was that loom alternative ?
<spiv> jelmer: ping?  It looks very much to me like the --protocol option to bzr serve has never worked?
<spiv> jelmer: which seems improbable, given that bzr-svn has code to use it, but the code in trunk is clearly broken...
<spiv> jelmer: (specifically, if --protocol is given on the command line, the code tries to use that value directly without looking it up in the registry)
<spiv> jelmer: Oh, nevermind, I think I see.
<lifeless> SamB: pipes
<SamB> lifeless: isn't it called pipeline ?
<SamB> I must have been blind when was looking at the plugins page to try to spot the name earlier ...
<SamB> lifeless: now where's a good tutorial ?
<jam> igc:  maybe, but I think they want some level of access control, like having only 1 gatekeeper able to commit to the 'trunk' branch
<igc> jam: that access control is independent of ssh vs bzr isn't it?
<jam> igc: it is filesystem based, but if you are using 'bzr serve' then it runs as the server user
<lifeless> SamB: no idea sorry ;P
<jam> versus bzr+ssh running as the ssh users
<igc> jam: ah - didn't know that
<jam> igc: since bzr:// doesn't do auth itself
<SamB> hmm, how to set the submit branch ?
<jam> igc: what do you think about having "cmd_explorer" subclass "QBzrCommand" ?
<igc> jam: I'm ok with that
<jam> I think at one point you wanted to be toolkit agnostic
<jam> but you seem pretty tied to qt now
<igc> jam: I think it caused some exception in my early Qt hacking days so I went another path at the time
<igc> jam: it's toolkit agnostic w.r.t. launching dialogs
<igc> jam: the core code needs to be in some toolkit and Qt seemed a good choice
<jam> igc: yeah, but if you are already depending on qt... it seems a bit silly to the depend on gtk at the next level
<jam> that, and you don't actually support bzr-gtk in the drop down list anymore .. :)
<igc> jam: right, so bzr-gtk is optional; qbzr is required
<igc> jam: if bzt-gtk is installed, it will appear in the list
<jam> ah, k
<jam> I guess i mostly played with the installer
<igc> jam: some users prefer the bzr-gtk dialogs and that's fine by me
<AfC> Notably anyone running a GNOME Desktop
<AfC> and who doesn't have any Qt or KDE libraries on their system
<SamB> AfC: that's going to work real well with bzr explorer!
<igc> jam: rev 275 of explorer has a few of your bugs fixed
<igc> jam: I'll release a 0.8.1 later today if they are useful enough to include in your new installer
<jam> igc: checking
<jam> igc:  I think the "create if missing" fix is worthy
<jam> since it will make a difference for a lot of use cases
<jam> igc: any chance you could do 0.8.1 now so I can build -2 before I sleep?
<jam> igc: also http://paste.ubuntu.com/271819/
<jam> fixes some of the "prompted for password on console rather than via dialog" that I've run into
<jam> I haven't 100% validated it yet, which is why it isn't a submitted patch
<jam> igc: well, actually I did just test it, and everything seems to work, so I'll push it up as a branch for you to merge
<jam> is bzr-explorer in 2a or 1.9 format?
<igc> jam: 1.9
<AfC> SamB: bzr-explorer ... that's for Microsoft Windows, right?
<AfC> (ie's a Windows Explorer plugin like Tortise, isn't it?)
<SamB_XP> AfC: anything with Qt, AIUI
<lifeless> AfC: nope; its a gui for doing bzr stuff, AIUI
<AfC> uh
<igc> AfC: explorer runs on Windows, GNOME, KDE and OS X
<AfC> igc: it has a GTK back end?
<SamB_XP> AfC: hahahaha
<igc> AfC: it can call out to either QBzr or bzr-gtk
 * AfC is confused
<SamB_XP> you think you can't run a Qt app in GNOME ?
<igc> AfC: the app itself is Qt
<AfC> SamB_XP: you can't run KDE apps on a box that doesn't have Qt installed, no
<SamB_XP> it's not a "KDE App"
<SamB_XP> though sadly qt4 is rather huge :-(
<AfC> igc: then it would be inaccurate to say it's a GNOME app [yes, you said something a bit different, but the point remains]
<jam> igc: lp:///~jameinel/bzr-explorer/dialog_for_password
 * SamB_XP finds himself looking for the archive button on a google code issue
<jam> igc: if you like that, then I'd like to build a 2.0.0-rc2 with your fixes and mine tonight
<jam> I could possibly do it early tomorrow am if that works better for you
<igc> jam: my today is better - I'm on leave tomorrow :-)
<igc> jam: rev 276 has your fix
<igc> I'll package 0.8.1 in the next 30 minutes
<igc> jam: how late is it there for you?
<jam> igc: 11:30pm
<igc> jam: ok, I'll package now. Won't take long
<jam> igc: well, all *I* need is a tag on your trunk :)
<igc> jam: done. The tag is release-0.8.1. The rev is 277.
<igc> jam: just double-check buildout pulls down the latest stuff - that's been playing up for me on Windows at least
<jam> sure
<sidnei> jam, igc: i believe you just need to pass '-n' to the buildout invocation
<sidnei> in case it's defaulting to 'newest=false'
<igc> thanks sidnei
<sidnei> igc: of course setting 'newest=true' in buildout.cfg might be even better
<igc> jam: if the installer needs that, can you push the fix?
<jam> igc: I can't commit on Kerguelen...
<jam> well, I could but I can't push
<jam> anyway, for now I can manually update subdirs
<jam> but I'll poke at it over the next whil
<igc> jam: thanks. I can push the fix if I know it works
<lifeless> poolie: I think you may be going off on a tangent, or thinking I am proposing something ugly, or something.
<lifeless> poolie: if my reply doesn't sit right, lets talk.
 * igc lunch
<poolie> lifeless: do you mean about the test base classes?
<lifeless> yes
<poolie> it may be a tangent if you're not proposing to use this any more than is there at present
<lifeless> I'm just proposing to clean up a little of what we have
<poolie> ok
<lifeless> we have 4 official base classes
<poolie> incremental cleanups++
<lifeless> I'd like to split things out some more, to 5, or may be 6
<lifeless> so they are smaller and more managable
<poolie> ok
<lifeless> its *easier* to migrate a collection of tests by changing their base class than by other means.
<poolie> do you have an example of a particular set of tests where you'd like to make this change?
<poolie> biab
<lifeless> poolie: no, this comes from looking at the various test support code
<poolie> lifeless: back now
<lifeless> poolie: I do want to transition to a testresources style thing. If I can convince you to allow the extra dependency, some nice things can be done :)
<lifeless> brb
<SamB_XP> heh
<SamB_XP> what is this, tag-team IRC ?
<poolie> lifeless: can you point me to a conflict checker i could run against our ppa?
<poolie> and/or run it yourself
<lifeless> poolie: https://edge.launchpad.net/conflictchecker
<lifeless> poolie: it is probably not what you are looking for though
<lifeless> poolie: what sort of issues do you want detected?
<poolie> i want to say "could i simultaneously install everything from this ppa?"
<poolie> things like bzrtools have a deb-level conflict with bzr
<lifeless> ok, its not what you want :)
<poolie> is there some other tool?
<lifeless> conflictchecker answers 'are things that claim to be concurrently installable concurrently installable' - e.g. 'are the packages lying'
<lifeless> I'd write a little one using python-apt
<poolie> ok
<poolie> or i could just test them in a chroot i guess
<lifeless> sure
<lifeless> a python apt script would be sufficient I think
<lifeless> its that sort of thing it can do very well
<AfC> Could write a package that depends on all those things and then get launchpad to attempt to build it?
<AfC> [or use that chroot-build-environment I've heard people talking about?]
<poolie> afc, that's a nice idea
<poolie> the first one
<poolie> but if someone then later uploads something that breaks it, i don't think we'll find out
<poolie> and ..
<poolie> i don't think we'd want it to reject the upload, just to tell us to get back in sync later
<AfC> What's a simple (and mean stupid simple, like as in doesn't even exist in Java space) Python web server thingy? I want to do up something as tiny as  `bzr cat | web page` then add a little syntax highlighting and line numbering.
<AfC> Any suggestions?
<AfC> I could just call `bzr cat` from PHP, but...
<lifeless> spiv: where did we put that experiment :P
<lifeless> AfC: twisted has a _very_ simple static web server, I don't recall the mojo for it though
<AfC> Hm. Now that I think of it, I could use `source-highlight` and just rsync the resultant HTML pages.
<AfC> [instead of maintaining a working tree in the target branch on the server]
<AfC> lifeless: ok, I'll look there, then [assuming the brute force approach doesn't work]
<lifeless> if you want to show bzr stuff though, with source highlighting etc, why not just use loggerhead?
<lifeless> bzr serve --http
<AfC> um
<AfC> that's integrated in bzr's core now?
<AfC> bzr: ERROR: no such option: --http
<AfC> apparently no
<lifeless> you have to install loggerhead
<lifeless> but thats how its exposed now, yes.
<AfC> lifeless: admittedly I've only used it on Launchpad, but loggerhead has struck me as bloated, slow, and cumbersome.
<AfC> s/used/seen/
<lifeless> AfC: the lp instance is serving 60K branches or so, many huge or in inefficient formats.
<AfC> lifeless: "admittedly ... Launchpad"
<AfC> lifeless: so yeah
<poolie> igc: around? want to catch up?
<AfC> lifeless: though, I must admit the part that it fails on for me is how much work it is to show the work of the people who actually contributed, rather than all the merges by the gatekeeper person / bot
* poolie changed the topic of #bzr to: Bazaar version control system | 2.0rc2 code frozen for 2.0.0 | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<igc> poolie: yep. now is good for me
<poolie> k
<fullermd> poolie: Does that imply the tarball is being cut?
<poolie> it's been cut for a week now
<lifeless> 'I'll cut you *****'
<fullermd> Eh?  No it hasn't...
<fullermd> Oh, you mean rc2.  I mean bzr-2.0.0.tar.gz.
<vila> hi all
<lifeless> hi vila
<vila> poolie, spiv : Does http://paste.ubuntu.com/271887/  rings a bell
<vila> hi lifeless
<spiv> vila: that does ring a bell
<spiv> vila: I dimly recall that was happening to me for a while
<vila> just occured on gentoo, can that be related to a timing issue ??
<spiv> vila: I guess that it's something like:
<lifeless> spiv: oh interesting that pathfilter permitations are testable
<lifeless> spiv: +1 on the thing then
<spiv> vila: while iterating the transport_list_registry a module import is triggered that registers a new transport, which then causes that error.
<vila> spiv: excellent, sounds very likely, now to isolate that...(I will wait for more occurrences anyway)
<poolie> fullermd: maybe it's unclear, i meant that 2.0rc2 shouldn't change before final
<spiv> lifeless: interesting?  I seem to recall you made the chroot test permutation work in the first place, so it's essentially your work there :)
<lifeless> spiv: :)
<lifeless> pathfilter != chroot
<lifeless> anyhoo go land it ;)
<spiv> vila: another possibility, unlikely I hope, is that some errant thread does a transport registration during that iteration...
<poolie> vila, i've seen it, not recently
<poolie> oh...
<spiv> lifeless: thanks :)
<vila> poolie: but you couldn't reproduce it right ?
<poolie> i don't think it's thread related
<poolie> i have fixed one of these, but i can't remember why, sorry
<lifeless> probably want to not use iteritems
<spiv> A __del__ that triggers a registration somehow (again via an import?) would be another theoretical cause for this to happen intermittently?
<poolie> bug 277048?
<ubottu> Launchpad bug 277048 in bzr "test failure: test_http.SmartHTTPTunnellingTest.test_http_send_smart_request (dictionary changed size during iteration)" [Low,Fix released] https://launchpad.net/bugs/277048
<spiv> It's weird to me that it's intermittent, unless there's something causing dict order to change from run-to-run.
<poolie> igc, what was the bug you mentioned on the phone please?
<vila> reported by pva ! Our gentoo usual suspect, interesting...
<vila> poolie: and threads can be involved as soon as an http 1.1 server is involved
<vila> or even any http server
<vila> why they should import a transport lately though is another question
<lifeless> anyone seen these before:
<lifeless> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
<vila> lifeless: quite often yes
<poolie> yes
<poolie> i don't recall why
<lifeless> chroot and memory servers register transports
<lifeless> they could be the cause of the size change
<vila> last I tracked it I seem to recall that it was expected by the test (but I may be wrong)
<vila> lifeless: their late registration shouldn't forbid using items() instead of iteritems() though right ? Well, better try than discuss in the wild...
<lifeless> vila: items() would be fine
<spiv> lifeless: yes, I've seen that, I have no insight into it though.
<lifeless> vila: can you arrange for a buildbot slave to run selftest --subunit, once a day?
<vila> lifeless: already replied to your mail :)
<lifeless> oh cool
<vila> yes I can, I also think hudson will give us that for free, but I can still add it temporarily
<vila> lifeless: you're ok for a snigle slave to run it right ?
<lifeless> yup
<lifeless> ideally one without too much noise
<lifeless> I want to be able to wget a compressed copy of the log, process it for timing data
<lifeless> and e.g. report top 10 culprits, total time etc
<vila> well, I tend to consider having a 8-way host as good enough to avoid noise, and it seems to be quite a vliad assumption so far
<lifeless> sounds fine to me
<vila> at least if it run all days at the same time, the noise should be quite the same
<lifeless> EODing, SMS/ping me if needed
<igc> poolie: bug 418469
<ubottu> Launchpad bug 418469 in bzr-explorer "[wishlist] proper .desktop file for Gnome/KDE desktops" [High,Confirmed] https://launchpad.net/bugs/418469
<spiv> vila: oh, on that dict size change
<spiv> vila: it's a bzr+http test, so there will be a chroot-..:// transport registered by the server thread.
<vila> as lifeless hinted just before yes
<spiv> Hmm.
<spiv> I suppose this means it could happen in production if one thread is creating a chroot (for handling a new connection) while another is doing BzrDir.open.
<spiv> Which wouldn't be an issue for bzr serve TCP or bzr serve --inet, but some forms of HTTP deployment could theoretically do that.
<vila> spiv: hmm, looks like you're on the right track to write a reproducing test :D
<spiv> vila: it's getting late in the day here, why don't you do it?  ;)
<vila> spiv: I just receive another more problematic test failure :-)
<spiv> Lucky you! :)
<spiv> I'll file a bug, at least.
<vila> poolie: http://paste.ubuntu.com/271900/
<poolie> vila :/
<poolie> can we get it to compile the extensions?
<vila> spiv: kidding, that sounds a bit complicated to set up, but I was about to send a submission s/iteritems/items/ based on the discussions here
<poolie> it's a bit gross it fails like this without them
<vila> poolie: jam asked for tests without extensions, it's not even occurring then...
<poolie> oh ok
<vila> we say we support running without extensions
<poolie> sure, so we should pass tests without them
<poolie> file a bug, assigned to me?
<poolie> i thought we'd have some fallout there
<vila> it's triggered by leopard again because the laptop sleeps at night (lazy guy) and run the build in the morning with a more recent bzr.dev
<vila> which certainly means that I will get a fully red botnet tomorrow if not fixed...
<vila> poolie: tell you what, I fix that one and you review the shell-like tests  ? :D
<poolie> :)
<poolie> deal
<vila> YES
<poolie> i'm sending things of mine already approved
<poolie> hopefully after that
<poolie> oh i need to file one more bug too
<igc> poolie: can I email bzr-windows asking for testers on the new installer?
<poolie> of course, why not?
<lifeless> hmm, ~ 500 tests that read from the local filesystem - aren't properly isolated.
<igc> poolie: and maybe put up a wiki page collecting test status across various windows versions?
<igc> poolie: well, we're yet to announce 2.0.0rc2
<poolie> well, probably we should ask for testing before the announcement
<igc> polie: ok, sounds good
<igc> poolie: I'll email now
<poolie> lifeless: we should try to get apport and subunit and maybe other things into the pqm chroot
<poolie> or is there already an rt?
<lifeless> theres an rt on subunit aready
<poolie> still waiting?
<vila> mwhahahah: * Don't call iteritems on transport_list_registry, because it may
<vila>   change during iteration.  (Martin Pool, #277048)
<vila> Except that the underlying implementation still use iteritems(), oh the irony....
<spiv> vila: yeah
<vila> I'm not throwing stones, I was just choked to follow the track and... wtf ???
<spiv> vila: fundamentally I think Registry should cope better here (by not using self._dict.iteritems()); https://bugs.edge.launchpad.net/bzr/+bug/430509
<ubottu> Launchpad bug 430509 in bzr "RuntimeError from get_transport when another thread concurrently registers a new transport" [Low,Confirmed]
<vila> I was about to do exactly the same...
<mtaylor> lifeless: are you waiting on me for anything these days?
<vila> #430510 sorry spiv I didn't realize you were filing it :-/
<spiv> Heh.
<vila> I was about to use list(registry.items()) for transport though, I think deprecating iteritems() is excessive...
<vila> In principle we should favour iteritems(), we found an exception, I'd prefer handling the exception that changing a good rule, objections ?
<poolie> vila:heh
<poolie> i think it's a bit bogus that we're registering and deregistering things this way
<lifeless> mtaylor: autoconf archive pandora cleanups;
<lifeless> mtaylor: not panicly
<mtaylor> lifeless: k. cool
<poolie> like why can't memory be memory://1234/aothuetue
<lifeless> poolie: huh? thats what the registration does
<spiv> lifeless: not quite
<lifeless> poolie: the alternative is memory etc to all manage their own registration of live servers
<poolie> i think some of them register new schemes not new hosts
<poolie> imbw
<spiv> lifeless: it registers memory-1234:///....
<lifeless> spiv: sure, 6-of-1 though, they are all prefixes ;P
<spiv> lifeless: we could perhaps just have memory:/  registered, and then have a separate MemoryServer registry with the netlocs as the keys.
<lifeless> I think what we do is elegant and reuses the code
<lifeless> rather than duplicating effort
<spiv> But that does shift the same problem to that secondary registry.
<lifeless> poolie: yes there is an rt for subunit, not for apport, and its in progress (something about needing a dapper package..)
<vila> spiv, lifeless, poolie : quite likely the bug will not trigger in that case, but anyway, I don't think a single exception is enough to require separating very similar intents
<vila> pfffff
<vila> Conflict: can't delete doc/en/developer-guide because it is not empty.  Not deleting.
<vila> poolie: now I understand your question from yesterday...
<poolie> that's it :)
<poolie> i think that's a sore point for jml, and some other users
<vila> but we still haven't decide how to address IIRC, we can't just delete HACKING.html there
<poolie> vila: i think most ignored files are safe to delete
<poolie> i think most of the time that's what people want
<vila> "think" and "most" ... twice.... :D
<poolie> possibly the other cases could be handled by moving them to either a backup file in a parent directory
<poolie> or say .bzr/trash
<vila> yeah, right ! Far better
<bialix> hi guys
<bialix> bonjour vila
<poolie> hi bialix
<vila> hello bialix
<poolie> or should i say privet?
<garyvdm> Hi all
<poolie> hi garyvdm
<igc> hi vila, bialix, garyvdm
<bialix> vila: I'll leave my chatzilla working as you teach me
<vila> bialix: hurrah !
<vila> :D
<bialix> but may be will not answer instantly
<vila> welcome to our 24/7 online world :)
<bialix> poolie: privet-privet
<vila> bialix: sure
<spiv> poolie: moving to a lost+found-ish directory sounds good to me; as you say often you just want to delete them so a single dir you can rm -r would be good.
<bialix> poolie: hi is fine too
<bialix> hi garyvdm, igc
<bialix> vila: I don't promise 24/7
<vila> bialix: I was joking :D
<bialix> ah
<bialix> nice
<spiv> poolie: I actually think a dir in the working tree root, rather than in .bzr, would be good
<bialix> jam is flloding qbzr with bug reports!
<poolie> .bzr-trash?
<spiv> poolie: because we don't want to train poeople to dig in .bzr to find their files
<bialix> garyvdm: did you see this?
<poolie> +1
<poolie> bialix: jam is doing some commercial training this week
<poolie> and i guess getting a lot of feedback
<garyvdm> bialix: Yip
<bialix> poolie: that's nice
<garyvdm> poolie: Thats cool
<bialix> poolie: getting feedback is cool
<bialix> poolie: unfortunately we can't fix all this bugs as quickly as jam reported them
<vila> spiv, poolie : remember the bug number where we can add these useful remarks ?
<spiv> I'm not sure that hidden-by-default is even necessary, why hide the junk?  I don't, though...
<garyvdm> poolie: Knowing software that you have written is being used is coll!
<spiv> vila: one with a low number, IIRC ;)
<poolie> it is good
<poolie> about directory conflicts?
<spiv> vila: I'm off; happy bug-squashing!
<poolie> nup
<vila> #102001 ?
<poolie> i was thinking about a crusade against four-digit bugs
<poolie> it'd be a bit arbitrary
<poolie> some are still marked inprogress though
<poolie> vila, ok, really reading it now
 * vila enters bersek mode
<vila> bug #102001
<vila> Hello ubottu ?
<ubottu> Launchpad bug 102001 in bzr "merges that delete non-empty directories confuse bzr" [Undecided,Invalid] https://launchpad.net/bugs/102001
<vila> bug #344013 too and may be more directly related
<ubottu> Launchpad bug 344013 in bzr "bzr resolve should automatically resolve conflicted directory deletion" [Medium,Confirmed] https://launchpad.net/bugs/344013
<bialix> how it's possible that jam filed bug report which is not bug report?
<vila> bialix: you'll have to explain a bit more here :)
<bialix> jam said that quncommit works wrong while it works as plain uncommit
<bialix> vila: it was rhetorical question actually. I simply can't believe
<vila> ha, that kind of  'not' :-) ok
<bialix> kind of 'nbot'?
<bialix> kind of 'not'?
<vila> bialix: that's why there is a "Won't fix" option :)
 * bialix perhpas looks stupid
<bialix> actually I've used Invalid
<vila> you said "is not bug report" I imagined you received a mail but couldn't find it back on lp...
<vila> so "not" a real bug report
<bialix> wow, what a wonderful bug Bug 430382
<ubottu> Launchpad bug 430382 in qbzr "qcommit crashes during Cancel" [Undecided,New] https://launchpad.net/bugs/430382
<bialix> and why there is no tree.conf???
<poolie> vila, review sent
<vila> thanks
<poolie> it's looking good but i have some questions
<vila> expect another one shortly then :)
<vila> poolie: right, so some answers are based on usage in my conflict-handling branch, where I have ~20 tests using ~20 scripts,
<vila> poolie: overall that's a needs fixing as in resubmit right ?
<poolie> pretty much
<poolie> obviously you're welcome to answer the questions other than by changing the code
<poolie> like if experience in using it has shown you that it works best as it is
<vila> sure, I intend to for some parts giving explanations why
<vila> exactly, separating output and errors, not checking output by default are two such examples
<garyvdm> poolie: As you are the author of Merge3, I think you are the best person to ask this. :-)
<garyvdm> poolie: http://paste.ubuntu.com/271945/ - Why does that result in a conflict?
<poolie> i forget what the argument order is
<poolie> is it base, a, b?
<garyvdm> yes
<garyvdm> I would expect the result to be ["c"]
<poolie> hm
<poolie> maybe it should be
<poolie> the basic idea is, this is a region that has changed, they disagree, therefore it conflicts
<poolie> this might be a place where reprocessing will trim it down
<poolie> perhaps it's more reasonable to say there are actually conceptually two regions here
<garyvdm> poolie: but it should be 2 regions?
<garyvdm> yes
<poolie> [a, b] => [a, b] | []
<poolie> and [] => [c] | []
<garyvdm> yes
<poolie> it would be interesting to try it at least
<poolie> i think i'd like to find a case where this occurred in real code
<poolie> does it only happen when one side is empty entirely?
<poolie> and how far do you take it?
<poolie> [a b c] => [a x b y c z] | []
<poolie> it would be a bit of a stretch to say that should be [x y z]
<garyvdm> yes
<poolie> are you looking at a real case?
<garyvdm> This is where I encounter it: I'm hacking qcommit to requery generate_commit_message_template when the file selection changes.
<garyvdm> "a", "b" = the base message
<garyvdm> The user (me) added "c"
<garyvdm> Then unchecked debian/changelog
<garyvdm> so the new message from generate_commit_message_template = []
<poolie> right, interesting
<poolie> this is a bit like some conflicts i see where one side has deleted a test (or other method), and another has added a new test just after it
 * garyvdm tries with reprocess=True
<poolie> clearly you want to keep the addition and keep the deletion
<garyvdm> reprocess=True dose not help
<igc> night all
<igc> I'll be offline a few days so see you all next week
<garyvdm> igc: Have a good rest!
<igc> thanks garyvdm!
<bialix> garyvdm: can we use our own templates for qcommit?
<bialix> igc: bye
<philn> hi
<garyvdm> bialix: ?
<philn> quicky one: on win32, how can i import bzrlib?
<philn> i have bzr installed system-wide
<garyvdm> philn: how did you install bzr?
<bialix> garyvdm: some people like vila often use list of changed files in commit message with some specific commetns
<bialix> philn: are you using bzr.exe installer?
<bialix> aka standalone installer?
<philn> bialix: err, don't remember
<philn> how can i check?
<bialix> show me output of `bzr version`
<bialix> pastebin it
<poolie> garyvdm: it's definitely worth filing a bug on it
<bialix> philn: but more importantly: why you want import bzrlib?
<poolie> tagged conflicts
<garyvdm> poolie: ok - Thanks
<philn> http://pastebin.com/m606b7b23
<garyvdm> bialix: He could write a plugin that implements a commit_message_template hook. When I have finished my hack, it will also work with qcommit.
<philn> bialix: i need it to call bzr commands from a python script
<bialix> philn: you have bzr.exe install, and very old (1.12)
<philn> i don't use that box daily, hopefully ;)
<bialix> philn: you either should install python-based version, see corresponding installers for your python version
<bialix> philn: what is your python version?
<philn> 2.5.2 ;)
<bialix> philn: are you one of that win32-haters?
<garyvdm> bialix: can't you add "C:\Program Files\Bazaar\lib\library.zip\bzrlib" to sys.path
<philn> hater no, but i'm not a lover either
<bialix> philn: install bzr from corresponding specific to 2.5 installer
<bialix> garyvdm: you can
<bialix> I mean *you* can
<garyvdm> bialix: Why won't that help philn?
<bialix> philn: use this installer http://launchpad.net/bzr/1.18/1.18.1/+download/bzr-1.18.1-1.win32-py2.5.exe
<bialix> garyvdm: it might help
<philn> my python is not installed system-wide, it is part of the big deps environment we use
<garyvdm> philn: try this then http://paste.ubuntu.com/271959/
<philn> garyvdm: yep, works
<philn> ok, so i can work with a try/except
<philn> thx
<garyvdm> :-)
<bialix> I don't recommend to hardcode C:\Program Files\Bazaar\lib\library.zip path there
<bialix> you can read actual path from registry
<bialix> on installation we wrote under HKLM\SOFTWARE\Bazaar\2.0 its InstallPath
<philn> err, okay
<philn> i don't have that "2.0" .. my bzr is really very, too oold ;)
<bialix> philn: and what you have?
<bialix> maybe 2.0 is unneccasary, I may forget some details
<philn> HKLM\SOFTWARE\Bazaar
<bialix> OK
<bialix> so use it
<bialix> is there InstallPath available?
<philn> yes
<philn> i'll ask people in the office to test...
<bialix> InstallPath should be C:\Program Files\Bazaar
<bialix> you just need os.path.join(InstallPath, 'lib\\library.zip')
<jszakmeister> jelmer: just a quick question for you... bzr-svn doesn't need the bzr: revprops for anything right?
<philn> it is on my machine yes
<jszakmeister> I mean it doesn't break anything not to have them, and doesn't interefere with the operation of bzr-svn at all?
<jszakmeister> Or does it limit you in some way if they're missing?
<bialix> garyvdm: finished to triage bugs, oh
<garyvdm> bialix: cool.
<bialix> jam is just like a bomb
<bialix> exploding
<garyvdm> bialix: lp:~garyvdm/qbzr/read_commit_message_hook/
<garyvdm> bialix: I need to work on how it merges things...
<bialix> merges things?
<bialix> sorry, I'm in dumb mode today
<bialix> garyvdm: sorry, I probably won't have a time to seriously looking at your branch till evening
<garyvdm> When you change the file selection, it updates the template
<garyvdm> bialix: cool. just for your information.
<bialix> ok, thanks
<bialix> ETTOMUCHSTUUF here
<garyvdm> vila may be interested :-)
<bialix> rats
<bialix> hate when typos ruined the joke (c) vila
<garyvdm> bialix: err - I know how feel.
<vila> bialix: :-)
<vila> garyvdm: I'm already bit overcommitted today :-/ Is that a merge proposal ?
<garyvdm> vila: no - something that will scratches and itch you have...
<vila> which one ?? :)
<garyvdm> vila: It makes qcommit get commit message templates
<garyvdm> And it updates it when you change the file selection.
<garyvdm> So we can me a commit message template that contains the list of files to be commited.
<garyvdm> Vila: which Alex said you often use...
<vila> ooh, not an itch of mine then :-) I use a different workflow: I prepare my commit message in a file in advance, sometimes I even revert/merge/shelve/do crazy stuff, while still retaining my file with the commit message
<vila> diff /diff -rsubmit:/commit are actions I do from emacs and the integration here fully fill my needs, so I'm a really hard sell for qcommit :) (or gcommit or whatever for that matter)
 * fullermd . o O ( ecommit )
<jszakmeister> I love qcommit.
<jszakmeister> I haven't tried the commit message templates though... I really should.
<vila> fullermd: I use DVC for that matter and my "file" is ChangeLog :)
<fullermd> Yeah, DVC means something very different to me probably   :p
<philn> thx for the help
<vila> fullermd: it's an emacs package in my case the acronym being... Distributed Version Control indeed :)
<fullermd> Yeah, I read it and think Diligentia, Vis, Celeritas   :p
<vila> fullermd: oh, in that sense, yeah, that's so me :-D
<lifeless> slowest tests today:
<lifeless> bzrlib.tests.test_bundle.V4WeaveBundleTester.test_last_modified 25.085
<lifeless> bzrlib.tests.test_bundle.V09BundleKnit2Tester.test_bundle 30.755
<lifeless> bzrlib.tests.test_bundle.V4WeaveBundleTester.test_bundle 39.020
<lifeless> bzrlib.tests.test_source.TestSource.test_no_asserts 54.165
<lifeless> bzrlib.tests.test_hashcache.TestHashCache.test_hammer_hashcache 69.739
<fullermd> I guess that counts as hammering it...
<vila> lifeless: and the later is timing dependant (I got a failure yesterday or the day before)
<SamB_XP> vila: have you had any issues with DVC ?
<vila> lifeless: http://paste.ubuntu.com/271990/
<vila> SamB_XP: apart from making it available to all my VMs without installing and recompiling ?
<vila> SamB_XP: no :)
<SamB_XP> 'kay.
<vila> SamB_XP: well, I lied.
<SamB_XP> 'cause if you were, I was going to ask you to file bugs ;-)
<vila> I had some problems, but I'm so used to work around them that I forget what they were
<SamB_XP> lol
<SamB_XP> typical
<vila> SamB_XP: But you're right, I should file them when I recall
<SamB_XP> maybe it wasn't taking bugs on launchpad last time you tried ;-)
<vila> SamB_XP: Certainly the biggest one is that the diff mode doesn't include the status mode, so I still ends up forgetting to add some files
<vila> SamB_XP: I started using DVC when I started using bzr, so neither of them used lp for bug tracking at that time I think :)
<vila> lifeless: http://paste.ubuntu.com/271990/
<SamB_XP> the former could be said of me, but the latter could not
<vila> lifeless: sorry, thought I didn't paste that :-/ Low glycemy (sp?) , lunch time :
<SamB_XP> though it would be more accurate to put it the other way 'round
<vila> SamB_XP: you lost me there :)
<SamB_XP> I started using bzr when I started using DVC ;-)
<vila> Oh, I see
<SamB_XP> and the dvc launchpad project wasn't accepting bugs, and there wasn't really anywhere else to send them but the DVC mailing list ...
<SamB_XP> which wasn't all that easy to find, either, iirc ;-)
<vila> SamB_XP: I remember your arrival :)
<lifeless> vila: it shouldn't fail though; what platform/fs was that on?
<vila> lifeless: karmic happened only once
<SamB_XP> did the test time out from being so slow ?
<lifeless> vila: what file system?
<vila> lifeless: ext4
<SamB_XP> !!!
<SamB_XP> why that ?
<vila> err, wait, no /tmp right ?
<vila> so tmpfs
<SamB_XP> only crazy people use that, I thought!
<SamB_XP> like ext[234] devs
<vila> lifeless: errr, maybe not, let me check the dates
<vila> I just recently switch to a real mptfs for the karmic VM
<vila> lifeless: right, it was still ext4
<NET||abuse> hey guys. i have a project i'm versioning with bzr on my laptop(ubuntu), bit i have some image work i'm doing on a windows machine (bloody flash and photoshop requirements) so i wanted to checkout the branch onto the windows machine and then commit and push images and swf's back up into the linux laptop
<NET||abuse> how do i branch from linux to windows?
<NET||abuse> ssh+bzr:// doesn't work in the bzr interface on windows :)
<NET||abuse> nevermind, gotit
<NET||abuse> ahh, ok, next question, how do i avoid having to enter my ssh password 7 times.
<garyvdm> authentication.conf
<vila> NET||abuse: use an ssh agent
<vila> garyvdm: authentication.conf doc states that the aim is *not* to replace ssh agents which are: 1) better suited, 2) more secure :-D
<NET||abuse> ok,, putty an ssh agent?
<vila> NET||abuse: I can never remember :-/
<NET||abuse> boy, my bzr usage is a little fuzzy,, i added an image from a tmp directory, the tmp directory is needed but the jpg's in it are not.. can i just add jpg's to the .bzr/.ignore file?
<NET||abuse> or where is the ignore file usually located?
<NET||abuse> or what is the right way to remove the already added random images from being tracked and then ignore them?
<jszakmeister> jelmer: Another quick question... what if my layout has multiple tag areas?  For instance, a number of our projects have both tags/ and releases/ where the latter has only tags that correspond to official releases.
<jszakmeister> And more specifically: what happens when I say to tag something from Bazaar?  How does it know which location to record the tag?
<NET||abuse> hmm, i branched / checkedout from a remote bzr location in windows, and bzr isn' showing it as a bzr tracked tree
<NET||abuse> hmm, i am confused, on command line i can manage the branch on the windows machine, i guess the explorer shell extension just isn't working.
<NET||abuse> well, i added the image i wanted to the branch, and commited, it asked me for ssh login to commit so i was thinking is it commiting directly back to the linux machine?
<NET||abuse> or how do i get the image into the linux bzr repo?
<NET||abuse> hmm, ok, even doing bzr st on the local windows branch directory required ssh login.
<NET||abuse> what have i done here?
<vila> NET||abuse: start with 'bzr info'
<NET||abuse> that also required ssh login.
<vila> whether you use a standalone branch or a checkout will lead to different behavior, you have to learn them both if you want to use them both
<NET||abuse> ah, ok
<NET||abuse> it says Standalone tree       push branch: master      parent branch : bzr+ssh://route_to_mylinuxbox     stacked on: bzr+ssh://route_to_mylinuxbox
<NET||abuse> on the linux box bzr info shows Satndalone tree,   location branch root: /home/me/devel/site.com/src
<NET||abuse> so what's happening,, the image doesn't seem to appear on my linux machine.
<NET||abuse> bzr st on windows says unkown: master/
<NET||abuse> i may have bzr push master by mistake to try getting it up to the linux box, but that was a mistake.
<gabriel_> hiya
<gabriel_> i've been trying to get bzr working over smbfs...
<gabriel_> Permission denied: "lock/uogwua8c74.tmp/info": [Errno 13] Permission denied: '/media/henry/dev.www.windsor-telecom.co.uk/.bzr/branch/lock/uogwua8c74.tmp/info'
<gabriel_> any help would be great!
<NET||abuse> hmm, i find that weird, that you should bzr init-repo dirname   before branching from somewhere else..??
<NET||abuse> would the act of branching from somewhere else not make the destination of the branching operation an active repo no?
<Daviey> Hi, is it possible to have many local commits, but then when pushed elsewhere fold them to a single changeset?
<NET||abuse> it should be..
<NET||abuse> i heard that you can do that when folding commits into an svn commit.
<Daviey> NET||abuse: i can't think how to, without a wrapper scrip
<NET||abuse> one sec,, have to read the docs on commiting to svn from local bzr branch.
<Daviey> Thanks.
<lifeless> vila: would be good to know if we can trigger that failure on ext4
<Daviey> The only way i could think, was to bzr diff to upstream branch revision, then bzr revert to that, then apply the diff and recommit
<NET||abuse> i'm still working on how to push my change back up to the linux box.
<lifeless> vila: Its possible either ext4 is breaking one of our assumptions, or has a bug.
<NET||abuse> i've redone the whole seutp, according to the sharing-with-peers workflow guide
<NET||abuse> i did init-repo, then branched from my linux repo over bzr+ssh://   did my local commit, even did a merge on the windows box.. but that doesn't push the changes back up to the linux machine.
<NET||abuse> how do i get the code back up to the linux machine?
<NET||abuse> Daviey, try reading though the http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#bzr-svn   section of docs on commit style up to svn, it may be parallel when working with centralized bzr repo ?
<jam> garyvdm: I think what you are asking about is what "--reprocess" gives
<jam> but I don't think Merge3 directly supports it?
<garyvdm> Hi jam. I was very intrested to read about your demo.
<garyvdm> jam: I don't think reprocess would do what I want. I think I'm going to have to write a custom version of Merge3.find_sync_regions
<vila> lifeless: 1) it occurs only once 2) I may add an additional build specifically for ext4 3) but given that using tmpfs didn't provide the expected benefits, I may as well revert that change so karmic always run on ext4
<jam> garyvdm: it works in text files...
<vila> garyvdm: be sure to respect alphabetical order in NEWS sections (I just fixed one in bzr.dev)
<vila> morning jam !
<garyvdm> vila: Did I make a mistake?
<garyvdm> vila: alphabetical order *with in* NEWS sections?
<jam> garyvdm: http://paste.ubuntu.com/272053/
<jam> hi vila
<vila> look at lp:~vila/bzr/integration
<vila> garyvdm: to reduce the potential conflicts there
<garyvdm> jam: In your example, base=[] this=[ab] other=[abc]. My example was base=[ab] this=[abc], other= []
<jam> garyvdm: .... then that should conflict for the hole region...
<jam> but ... ok
<garyvdm> jam: should be 2 regions...
<garyvdm> [ab], [ab], []
<jam> garyvdm: i disagree
<garyvdm> [], [c], []
<jam> but I can see how you would want that
<garyvdm> base, this, other
<jam> garyvdm: consider how that would look in a real file
<garyvdm> jam: Yes - I think for how I want to use it, it is a special use case.
<jam> garyvdm: http://paste.ubuntu.com/272059/
<garyvdm> jam: This is for automatically updating the message template in qcommit. (https://code.edge.launchpad.net/~garyvdm/qbzr/read_commit_message_hook)
<garyvdm> jam: I plan to have it automaticly use the text from THIS where there are conflicts.
<garyvdm> jam: hence my conclusion that I am going to have to write a custom version of Merge3.find_sync_regions...
<garyvdm> jam: Anyway, if it split it up into 2 regions, then the result would be [c], with no conflicts, not like http://paste.ubuntu.com/272059/
<jam> garyvdm: merging is a bit of an art, but there is an argument that deleting a and b should conflict with the insertion of c
<jam> if you consider the actions as their "edges" or the pairing of a line with the previous and next line
<garyvdm> jam: Yes
<jam> with extra 2 "lines" for the beginning of file and end of file
<jam> I realize that for your specific case, you may not want that
<NET||abuse> hmm, ok i've a checkbox on a list of db entries,, the html is <input class="pressactivecheckbox" type="checkbox" checked="checked" name="active" rel="7"/>    i want to do an ajax request to set the value 1 or 0 in the db, this is the jquery i'm trying to use.. http://paste.pocoo.org/show/140038
<NET||abuse> at the moment it is showing undefined for the checkboxes rel attribute
<NET||abuse> i tried it as just this.rel when building ajurl   and got the same.
<muffinresearch> Quick question does anything exist in terms of commit hooks on a bound central repo? I have a need to set something up to watch for changes on a centralised repo.
<NET||abuse> what am i doing wrong here?
<garyvdm> NET||abuse: I think you got the wrong channel. You are in #bzr atm...
<NET||abuse> garyvdm, hahahah oh god, i am and all,, cheers ;)
<NET||abuse> :P
<garyvdm> muffinresearch: Yes - but you need to think about weather you want it to fire server side, or client side.
<garyvdm> muffinresearch: post_change_branch_tip
<garyvdm> muffinresearch: you can see the list of hook by running bzr help hooks
<garyvdm> muffinresearch: post_change_branch_tip
<garyvdm> muffinresearch: you can see the list of hook by running bzr help hooks
<garyvdm> muffinresearch: If you are not running a bzr server, then it will have to be client side.
<muffinresearch> garyvdm: yep I'd be looking for this to run from the server
<muffinresearch> garyvdm: ok thanks for the pointers - cheers
<vila> fullermd: mwhaaaaaa, Fatal trap 12: page fault while in kernel mode
<fullermd> vila: That'll teach ya.
<vila> fullermd: I don't mind rebooting, just wanted to know if it was worth reporting and how ?
<vila> fullermd: given that I have no idea about how to reproduce....
<fullermd> Well, it Shouldn't(tm) happen.  Did it dump a core or anything?  Just the panic message usually doesn't tell too much by itself, though the IP could be poked at maybe.
<vila> fullermd: but noting that the VM is spinning on the 4 virtual cores like hell (like it does when halt'ing), which is really bad taste in a VM :)
<fullermd> (think dumps might be off by default)
<fullermd> (in b4 I mean)
<maco> i did "bzr init" and "bzr add" on some files in a directory and have worked on them and commited a few times. i just realized i should've done it one directory up. is there a way to move the root of it?
<muffinresearch> Having had more of a read of the docs it's not clear where I could put a plugin so that it can be "seen" by bzr smart server when using bzr+ssh://
<muffinresearch> Aha looks like I might be able to use bzrlib/plugins
<jam> well, I'm off to work, see you all in the evening (they block IRC)
<Pilky> is there a reason smart_add() will accept absolute paths but commit() doesn't seem to want to?
<Pilky> *sigh* now it seems I can't get smart_add() to accept relative paths
<Pilky> anyone around who can tell me why if I have a working tree called wt
<Pilky> wt.has_filename("somefile.txt") returns true
<Pilky> but wt.smart_add(["somefile.txt"]) gives a PathNotChild exception
<james_w> why not use wt.add() ?
<Pilky> I was under the impression wt.add() required more work
<Pilky> eg recursing yourself into directories
<james_w> it does
<james_w> my guess is that wt isn't rooted at your cwd
<james_w> and the path is taken relative to your cwd, and so isn't seen as being in the wt
<Pilky> ah
<Pilky> yeah
<Pilky> I hate dealing with command line stuff sometimes
<Pilky> james_w: thanks
<Pilky> james_w: can you then think why wt.commit() would work with relative but not absolute, no matter what the cwd?
<Pilky> I get a PathsNotVersionedError
<james_w> not too sure
<james_w> not *smart*_add
<james_w> so I wouldn't be surprised if it worked differently to everything else
<james_w> but I'm not sure what would make commit not like absolute paths at all
<Pilky> well bzr itself seems to handle it, guess I'll have to have a look at the source
<naoki_> Good evening.
<naoki_> I'm trying bzr-2.0rc2
<naoki_> I faced error "bzr: ERROR: Cannot commit from a lightweight checkout to a stacked branch."
<naoki_> I just use a stacked branch and didn't use lightweight checkout.
<naoki_> Is this intended behavior?
<naoki_> What I did:
<naoki_> bzr init foo
<naoki_> bzr branch --stacked foo bar
<naoki_> cd bar
<naoki_> echo foo > foo.txt
<naoki_> bzr add foo.txt
<naoki_> bzr commit
<fullermd> Does it work if you make a rev in foo before you branch bar from it?
<naoki_> doesn't
<fullermd> Shucks.  I woulda looked real smart if it had...
<naoki_> I'm trying bzr-2.0rc2-2-setup.exe on WinXP SP3.
<naoki_> http://paste.ubuntu.com/272229/
<naoki_> and -Derror
<naoki_> http://paste.ubuntu.com/272231/
<phinze> so maybe someone can help me figure out if i understand this correctly: if i make a commit that becomes r4 and then a commit that becomes r5 in a task branch, and i realize that though the task branch is off 'feature-foo' branch that r4 should really get merged back into 'trunk'
<phinze> since i have another commit sitting on top of r4 that does *not* belong in 'trunk' yet
<phinze> my only option is a dumb cherry pick (i.e. no knowledge of merge source)?
<LarstiQ> no, you can merge up to r4
<LarstiQ> phinze: the other way around you would be right, r5 needs to be in trunk but r4 not
<phinze> but since the task branch has many changes from 'feature-foo' branch won't those all come in with the merge?
<LarstiQ> ah, yes
 * LarstiQ missed that in the description
<phinze> so i am stuck with just diff/patch for grabbing those changes, eh
<phinze> since the cherry-picking use case in bzr doesn't do much more than that for me at this point
<phinze> is that accurate?
 * phinze reads bzr wiki CherryPick and DaggyFixes article linked from there
<LarstiQ> phinze: hmm, I really wouldn't use diff/patch
<phinze> LarstiQ: well, i suppose i meant 'bzr diff -c4'/patch
 * LarstiQ would really just use `bzr merge`
<phinze> fair, but in this particular use case, it wouldn't gain me anything functionally?
<LarstiQ> for one thing, it would gain you using the same interface
<fullermd> diff/patch do poorly at dealing with renames, and will fail unless the raw patch applies perfectly cleanly.
<LarstiQ> phinze: your understanding is correct that it under the hood the operations basically boil down to that
<LarstiQ> phinze: but with more risk
 * mneptok summons lifeless 
<phinze> fullermd: good point, LarstiQ: okay, thanks, i was really mostly concerned with understanding it properly anyways :) i'll stick with bzr merge
<phinze> what i really need to do is fix my bzr workflow to account for the fact that i often find myself in a task branch with some code that should land in trunk and some that should land in 'feature-foo
<phinze> '
<LarstiQ> phinze: shelve, merge uncommitted, more branching?
<Tak> phinze: you and me both
<phinze> LarstiQ: yeah that's what i've been working on smoothing over
<LarstiQ> k
<phinze> shelve, switch, interactive-commit... trying to figure out best way to combine
<phinze> and just making sure that "just commit and figure out later" should be closed off as an option
<LarstiQ> the _best_ way of course is by doing the work where you want to have it in the end ;)
<LarstiQ> phinze: don't forget rebase
<phinze> LarstiQ: i was under the impression that rebase was bad voodoo ...?
<LarstiQ> phinze: okay, maybe you _should_ forget ;)
<LarstiQ> phinze: well, since we're enumerating all the options
<phinze> so i am on a project team and i spend most of my time knocking down issues that fall under project namespace, but sometimes i need to edit code that is already in production and should be landing in trunk
<phinze> so it's the workflow of a bunch of tasks on project branches and, oop! a task that needs to be done and pushed to trunk
<phinze> s/project branches/my project's branch/
<LarstiQ> right
<phinze> and sometimes i'll figure out halfway through a given task for my project that, oh actually i'll need to change some library code to finish this
<tsmith> i canNOT get bzr-svn installed on gentoo
<tsmith> whenever i run "sudo layman -a bazaar" it says "* Overlay "bazaar" does not exist!
<tsmith> "
<phinze> tsmith: compile it from source? :)
<LarstiQ> tsmith: try 'bzr'?
 * LarstiQ has no clue about gentoo
<phinze> LarstiQ: /me neither
<verterok> bzrtools subversion bzr-svn
<verterok> oops
<verterok> tsmith: it's easy to build bzr-svn
<verterok> tsmith: also you can add the overlay manually
<shikibu> I want to move something like this: bzr mv --after src/classes/Cache.cls LiveRelease/5106-Utility/src/classes/Cache.cls, but bzr complains "bzr: ERROR: Could not move Cache.cls => Cache.cls: LiveRelease/5106-Utility/src/classes is not versioned."  However if I do "bzr add LiveRelease/5106-Utility/src/classes/" and then try to move Cache.cls, bzr will complain that LiveRelease/5106-Utility/src/classes/Cache.cls is already versioned. How do
<shikibu> bzr what I want here?
<LarstiQ> shikibu: bzr add --no-recurse
<shikibu> tnx let me try that
<LarstiQ> shikibu: and then do the mv --after as you tried it at first
<phinze> LarstiQ: hmm rebase *does* look like bad voodoo... but it might be just the right kind of bad voodoo for me! ;)
<shikibu> yes, I see
<shikibu> LarstiQ: works very nicely; thanks for your help
<LarstiQ> phinze: if you know what you are doing (and certainly what the impact of rebase can be on other people), it can be a handy tool
<LarstiQ> shikibu: gladly :)
<phinze> LarstiQ: yeah i generally find myself ending up in the role of Keeper of the Intergity of the Repository anyways... so this might be a good secert weapon to know how to use
 * LarstiQ nods at phinze 
<phinze> is the plugin on a trajectory towards landing in core?
<phinze> jelmer: ^^ perhaps you'd know best? :)
<tsmith> the documentation is flawed
<tsmith> https://launchpad.net/bzr-gentoo-overlay/
<tsmith> between step 1 and 2 it is *imperative* that the user run $ sudo layman -L
<Pilky> If there are any mac users around, I've just pushed the source for the "nearly 0.1" of BazaarX to launchpad: https://launchpad.net/bazaarx
<phinze> Pilky: will share with mac users in my office -- thanks
<Pilky> cool
<Pilky> only does status, commit, add and rm at the moment but it's a start :)
<jam> spm: are you around?
<jam> I seem to have something that successfully merged into the 2.0.0 pqm branch, but did not get pushed to launchpad
<jam> At least, when I try to submit it, I get "Nothing to do" but when I try to pull it, I don't get my change
<tsmith> how do you create a branch using tortoisebzr? ???? I don't see the command ANYWHERE
<jam> sidnei: I tried setting "newest = True" in the config file, and my first attempt seemed to get to "Installing Templates" and then hung for a very long time
<tsmith> how do you create a branch using tortoisebzr? ???? I don't see the command ANYWHERE
<jelmer> phinze: I'm not aware of any plans to get rebase into core
<sidnei> jam: well, its pulling every branch, that's why. if you give it '-vv' it should print some debugging info
<jam> sidnei: it isn't hanging on pulling a given branch
<jam> it is hanging at "Installing Templates"
<jam> as in... about 20-30 min at just that step before I cancelled it
<jam> maybe I'm wrong about what is going on
<jam> I'm used to seeing it say "connecting to X", "connecting to Y" etc
<jam> and hanging a long time on the initial
<sidnei> jam: that sounds odd. i can give it a try later, but im leaving for dinner right now
<jam> cd build-win32 && bin/buildout
<jam> sidnei: no prob
<jam> enjoy your dinner
<jam> for now, I'm just running again with newest = false
<sidnei> jam: you're running bzr-windows-installers or bzr?
<jam> and see if that gets something built
<jam> sidnei: bzr-windows-installers
<sidnei> jam: trunk?
<jam> sidnei: yes
<sidnei> ok, its running, bbl
<mwhudson> is making bzr's command line parsing stuff more resuable in other scripts seen as a worth goal?
<jam> mwhudson: I think jml has wanted to do that a few times
<jml> heh
<jam> I think we would be willing to merge patches to that effect
<mwhudson> basically, i've found something that makes it awkward and i'm wondering if i should file a bug
<jam> mwhudson: explicit bugs are more likely to be looked at... the 2.1 series is a good target for big code cleanups
<mwhudson> this thing is very tiny :)
<lifeless> 36million rows imported
<lifeless> mwhudson: it is reusable - commandant reuses it.
<lifeless> mwhudson: patches to make it more reusable++
<mwhudson> lifeless: well, yes, but there seem to be a few warts still
<lifeless> mwhudson: but if you tell me whats grating I may be able to help
<mwhudson> lifeless: Fail
<mwhudson> heh heh heh
<mwhudson> entertaining mispaste there
<mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/431054
<ubottu> Launchpad bug 431054 in bzr "Command._usage assumes the executable is called "bzr"" [Undecided,New]
<lifeless> jam: I'll get spm to push the branch; pqm had trouble when code hosting failed late last week
<jam> lifeless: thanks
<lifeless> spm: ^ just what you did for +trunk, on 2.0 and 2.0.0
<lifeless> mwhudson: anything else?
<mwhudson> lifeless: not yet, i was trying to ask if reports like this were of interest
<lifeless> mwhudson: they definitely are
<mwhudson> lifeless: now that i know that they are, i'll continue to produce them :)
<lifeless> mwhudson: I may be wrong to suggest a helper method; my reasoning is that command objects themselves are not intended to be reused willynlly
<mwhudson> my code is still a bit of a mess, i'll be in a better position to file sensible reports when i've cleaned it up a bit
<RenatoSilva> verterok: Hi Gullermo, I pushed a new revision yesterday. I also added a test for non-ascii-terminated urls
<lifeless> mwhudson: if this is ec2 stuff.. consider txaws :)
<verterok> RenatoSilva: cool, I'll take a look to the branch tonight
<jfroy|work> Is there a way for the command line to print the metadata recorded by the --fixes commit option?
#bzr 2009-09-17
<lifeless> jfroy|work: theres an option to log, I think
<jfroy|work> Or API to get to it. I'm basically trying to write a plug-in that adds a --fixes scheme for my company's bug tracker and also a post-commit hook that will add a message to the bug if the commit includes the --fixes metadata.
<jfroy|work> adding the --fixes scheme was trivial
<jfroy|work> (just another UniqueIntegerBugTracker)
<lifeless> the revision.properties
<jfroy|work> well --long doesn't do it
<lifeless> in your post commit hook
<jfroy|work> nice
<jfroy|work> I'm trying right now just to check if the metadata was recorded
<lifeless> print branch.repository.get_revision(revision_id).properties
<jfroy|work> There has to be a command to inspect a revision, even a debug command of some kind
<jfroy|work> time to break out a python shell huh
<jfroy|work> fair enough :)
<lifeless> cat-revision
<jfroy|work> ha, like the name :)
<jfroy|work> huh, log doesn't print the revision ID
<jfroy|work> --show-ids, nvm
<jfroy|work> And right now, it seems the property value will be hardcoded to "$BUG_URL fixed"
<jfroy|work> And stored with the key 'bugs'
<jfroy|work> Which seems to be a magic constant in the builtin commit command, which has me worried one day someone will change that and the plug-in will break
<KhaZ> Dumb question: currently when I want to add files to bzr, I basically run bzr st -S . | grep "^?" | awk '{print $2}' | xargs bzr add.  Is there a better way of doing this, besides maybe aliasing said command?
<lifeless> jfroy|work: its not part of commit; its part of the bug module
<lifeless> pydoc bzrlib.bugtracker
<lifeless> KhaZ: 'bzr add'
<KhaZ> ... D'oh.  It is quite possible I'm that much of an idiot.
<jfroy|work> lifeless: the 'fixed' part yes
<jfroy|work> but not the property name
<lifeless> the property name won't change
<lifeless> or if it did the query api in bugtracker would be adjusted to support reading from both
<lifeless> I'm saying, its no more or less at risk of changing than any metadata
<jfroy|work> I don't see any code in the bugtracker module that ever reads a revision property
<lifeless> there's stuff in qbzr
<lifeless> it will probably mgirate to the core at some point
<jfroy|work> I see
<spm> lifeless: 'kk (+trunk to 2.0 and 2.0.0)
<lifeless> spm: 2.0 to 2.0, and 2.0.0 to 2.0.0 :)
<lifeless> spm: pushing trunk to 2.0 would be bad ;P
<jfroy|work> So it should be relatively safe for the hook to look for the 'bug' property (as a constant key value, not as a constant imported from bzrlib)
<spm> heh. that's not what I meant :-)
<lifeless> jfroy|work: yes
<lifeless> jfroy|work: 'bugs'
<jfroy|work> * 'bugs'
<jfroy|work> damn, beat me to it :p
<spm> lifeless: so. 2.0: 4665 pushed, vs 4664; 2.0.0: 4667 vs 4665. no changes needed to locations.
<lifeless> spm: thanks
<lifeless> jam: ^
<spiv> Good morning.
<poolie> hi all
<poolie> hi spiv, lifeless
<poolie> maybe i should change the 'compiled extensions' warning to say "if you're running from a bzr source directory, run 'make'"
<spiv> poolie: good morning.  Thanks for starting the review of the hpss homedirs patch.  I forgot to mention that part of the diff (mainly pathfilter.py) is in a separate review (which has been approved now).
<poolie> np, i saw robert's verbal approval
<poolie> of that
<poolie> if you want me to read it too i can
<spiv> I wouldn't bother if I were you :)
<mkanat> Okay, assuming that I don't go to the 2a format right now, what's the best format for a repository that I will have to maintain well into the future, right now?
<mkanat> And that random people, including our users, might be checking out from.
<mkanat> (Which is why I don't want to go 2a right now--I need relatively good backwards-compatibility so that users can get at the repo.)
<mkanat> I'm asking because Bugzilla picked bzr over Hg, BTW.
<poolie> hi mkanat
<poolie> that's great news btw
<poolie> mkanat: i'd probably go for 1.9
<poolie> it's faster and smaller than earlier formats
<poolie> and it'll be supported by bzr releases going back, of course, to 1.9
<mkanat> poolie: That sounds pretty good. And that will be upgradable to 2a in the future?
<poolie> which is nearly a year ago now
<poolie> yes
 * mkanat nods.
<mkanat> Okay, cool.
<poolie> and 2.0 will support it
<poolie> so in your case i'd probably be suggesting people install 2.0.0 (or 2.0.x later)
<poolie> which will be a bugfix-only series
<poolie> but use 1.9, for interoperation with older releases
<mkanat> Okay.
<mkanat> Some people won't be able to install 2.0 very easily.
<mkanat> But everybody should be able to get 1.9.
<mkanat> At least. :-)
<mkanat> (For example, Bugzilla still works on RHEL4, but that only has python 2.3.)
<davidstrauss> mkanat: why would 2.0 be hard to install?
<lifeless> mkanat: 1.9-rich-root
<lifeless> mkanat: if you don't go 2a
<lifeless> mkanat: the rich root will make moving to 2a easier
<mkanat> poolie: Is there any way yet of reconciling two separate cvs imports and saying "these are actually the same, and these commits match to these commits and these files match to these files"?
<davidstrauss> mkanat: no
<lifeless> mkanat: bzr has only ever supported python 2.4 and up, FWIW
<mkanat> lifeless: Hmm, ever? Okay. :-)
<davidstrauss> mkanat: CVS -> bzr is non-deterministic
<mkanat> davidstrauss: Yes, but it would be nice if I could re-do my import, because some of it's messed up.
<mkanat> Due to the fact that we started it with an older bzr and an older cvsps_import.
<davidstrauss> mkanat: There's also no way in bzr for a single file to have multiple UUID ancestors
<mkanat> davidstrauss: But without breaking people who have already checked out from the existing bzr import (which is a lot of people including all my client work).
<davidstrauss> mkanat: so merging two branches with the same files and different bzr ancestry is a non-starter
<davidstrauss> mkanat: you could "merge" into the repo and resolve all conflicts in favor of the incoming files
<davidstrauss> mkanat: then you'd pick up the file UUIDs from the branch being merged in
<mkanat> davidstrauss: That would break merging back into the older checkouts, though, right?
<mkanat> I mean, I don't see any advantage.
<davidstrauss> mkanat: correct. you can't maintain ancestry in both directions
<mkanat> Ah well.
<davidstrauss> mkanat: it's an architectural limitation i've discussed with aaron bentley
<poolie> mkanat: if you can get all your users to help switch, it may be feasible
<poolie> you'd need to tell them to just cherrypick across from their existing branches into new ones based on the new import
<mkanat> poolie: The actual user base is fairly small, so it might be possible.
<mkanat> poolie: That is, my *main* concern is all the work I have in client branches.
<lifeless> poolie: re the extensions nag
<mkanat> And the work I did with NASA.
<poolie> per-client forks
<mkanat> poolie: Yeah.
<lifeless> poolie: I suggest: make bzr --version show the full list of missing extensions, and have the nag be a one-liner: 'One or more C extensions could not be loaded. See bzr help C-extensions'
<mkanat> poolie: So we'd do the import by basically just applying each patch of each revision individually, and copying the log message?
<poolie> lifeless: i agree about the nag
<SamB_XP> mkanat: you *might* be able to use rebase for some of it ?
<poolie> mkanat: right, and bzr-rebase may be able to help
<poolie> or, you can just fold them all up into one commit, depending how much resolution you want to keep
<lifeless> rebase still follows fileids
<mkanat> poolie: Okay. In that case, next question--is there a better existing CVS importer that can do branches and branch relations than cvsps_import now?
<SamB_XP> lifeless: oh, right, dang
<poolie> lifeless: the hard part is making --version show them: --version won't normally know all of the extensions we might want toload
<mkanat> poolie: I heard something about cscvs from kiko once.
<poolie> i know of the tool
<lifeless> mkanat: cvsps-import or cvs2bzr
<lifeless> mkanat: cscvs is not for conversions, its for ongoing mapping, and only really does trunk
<mkanat> lifeless: Ah, okay.
<mkanat> My problem with cvsps_import right now is that it wasn't correctly handling utf-8 in CVS log messages, and it wasn't deleting files under certain circumstances, it seemed.
<lifeless> mkanat: it can do other branches, with fiddling, but unless you plan to stay on cvs, go for cvsps-import or cvs2bzr (which is fastimport based)
<lifeless> poolie: so, seems to me that we don't really know that full list ever; so the current warning is also able to be incomplete.
<lifeless> poolie: I don't think it would be overly ugly to have a module scoped list of expected extensions, and plugins could add to that list if they have extensions too.
<poolie> right
<poolie> or otherwise
<poolie> just give the nag warning
<poolie> put the missing list into the log file
<poolie> it's probably actually rare that a non-developer will see just some things fail to load
<lifeless> I desire --version to show the list because its a very easy thing to ask a Windows or new user to look at.
<poolie> or see something that's not fixed by either running make, turning off the warning, or filing a bug
<poolie> i don't object to it, i just think it's a different (filed) bug
<lifeless> poolie: kk
<poolie> good idea on the message though
<mkanat> lifeless: Any particular preference between cvs2bzr and cvsps_import?
<lifeless> mkanat: I suspect they will have different bugs ;)
<mkanat> lifeless: Hahaha, okay. :-)
<mkanat> Maybe I'll just stick with cvsps, then.
<mkanat> So, if I want to make sure that people don't accidentally check in as somebody else, is the best way to require signatures?
<mkanat> Well, actually, I'm not even sure that would work.
<zsquareplusc> is someone here using bzr on sourceforge? do they support more than one branch per project?
<mkanat> jam: I'm running into a problem with cvsps 2.2, importing Bugzilla into bzr: https://bugs.launchpad.net/bzr-cvsps-import/+bug/431127
<ubottu> Launchpad bug 431127 in bzr-cvsps-import "cvsps_import fails with cvsps 2.2" [Undecided,New]
<aboSamoor1> Hi, I use bzr in my personal branch in launchpad. I save my different projects under different folders, my friends found it hard to pull all the folder to pull one of them. Is there any way to split the folders under different branches without losing the history of the commits ?
<zsquareplusc> aboSamoor1: last time i asked about that i was not given a direct solution. but the hint that you could use fast-import/export and filter. so it should be possible with 2 or 3 steps
<aboSamoor1> zsquareplusc: well, it is not only performance issue. I don't want to announce all my work once I send someone the address of branch.
<aboSamoor1> zsquareplusc: also I don't want make global commits history. so it will more clear to me the history of the commits of each project alone
<zsquareplusc> aboSamoor1: "bzr help fast-import-filter" should give some insight
<lifeless> aboSamoor1: just make separate branches now; e.g.
<lifeless> if you have in your current branch /proj1 /proj2 /proj3
<lifeless> then bzr push ../new-proj2-branch
<lifeless> cd ../new-proj2-branch
<lifeless> bzr rm --remove proj1 proj3
<lifeless> bzr mv proj2/* .
<lifeless> bzr rm proj2
<lifeless> bzr commit -m "Make this branch be for proj2 only."
<lifeless> and push that to launchpad under an appropriate project
<aboSamoor1> lifeless: how will the history of the new branch look like ? I mean if the initial branch has commit till 100 and proj2 was last updated with commit 90 what will be situation ?
<zsquareplusc> lifeless: --remove is not documented in my bzr's help rm, is that brand new?
<lifeless> zsquareplusc: actualy its old I think :)
<lifeless> aboSamoor1: try it and see ;)
<lifeless> aboSamoor1: as it in a separate branch it won't impact your existing work :)
<aboSamoor1> lifeless: good point
<aboSamoor1> :)
<lifeless> in short, it will have everything up to the point you do the rearrangement
<lifeless> which is what 'preserve history' means, generally ;)
<aboSamoor1> bzr push ../new-proj2-branch ----this must be ---> bzr branch ?
<lifeless> aboSamoor1: that makes a new branch at the path ../new-proj2-branch
<zsquareplusc> lifeless: hm, if its old, it's undocumented. i can't find a word about in in "help rm" or "man bzr"
<lifeless> zsquareplusc: as in removed
<lifeless> zsquareplusc: ignore it ;)
<zsquareplusc> aboSamoor1: its correct with push. you are in the directory of the current branch and push a copy to a fresh directory
<zsquareplusc> hm.. with bzr 1.17: bzr rm --remove CVSROOT  ... bzr: ERROR: no such option: --remove
<lifeless> zsquareplusc: don't use the option is what I mean
<zsquareplusc> ah, but with just rm you still have the history
<lifeless> zsquareplusc: Of course, the question was how to keep the history, wasn't it?...
<mkanat> In order to control commit access to a bzr repository, do I have to control the unix permissions of the repository .bzr directory, or just the unix permissions of the branch .bzr directory?
<zsquareplusc> lifeless: what i understood was, how to make 3 separate branches from 3 folders in one, each with only the history of the respective folder
<lifeless> zsquareplusc: to do that you need to break the history, rewrite it into a smaller form, which is what you'd use fast-export and fast-export-filter for
<aboSamoor1> lifeless: I did that for the first project it increased the commit number by one, now how can I view the history of the new branch without using launchpad ?
<zsquareplusc> aboSamoor1: bzr log or bzr qlog or bzr vis, depending on which plugins you have installed
<lifeless> aboSamoor1: bzr log
<aboSamoor1> lifeless: I am satisfied with the solution proposed, thanks very much :)
<mkanat> Hey hey. Anybody got some feedback on my permissions question, above?
<lifeless> aboSamoor1: cool
<lifeless> mkanat: both
<mkanat> lifeless: Okay.
<mkanat> lifeless: That's what I thought; it's what I've been doing.
<mkanat> lifeless: So basically if we have separate committer groups, we need separate repos?
<lifeless> yes
<mkanat> lifeless: Okay, that's what I thought.
<lifeless> there are ways to avoid that; theres some stuff in contrib I believe
<lifeless> but the most secure simple and robust way is one-capability per-repository
<aboSamoor1> lifeless: the only drawback of the solution, that if you split the old branch to 5 new branches you have 5 duplicate histories. 5*100 MB :(
<lifeless> aboSamoor1: they won't grow at the same rate though
<lifeless> aboSamoor1: and if you have a shared repository the deep history will be shared so you want have 500MB used on disk.
<aboSamoor1> lifeless: I will try bzr split later
<aboSamoor1> lifeless: I see
<mkanat> Is there a config for setting up "bzr serve" as a init.d daemon that logs to syslog?
<Drakeson> what is the bzr equivalent of git reset --hard origin/master ?
<spiv> mkanat: no, unfortunately.
<mkanat> Okay.
<spiv> mkanat: it would be good to improve our logging to make that possible.
<bob2> Drakeson: what does that do?
<mkanat> Yeah--I imagine running a constant "bzr serve" is faster than serving through inet.
<Drakeson> git-reset resets current head to the speficied state (origin/master here). --hard matches both the working tree and the index to the state one asked for.
<spiv> mkanat: yeah, most likely; it commonly takes a couple of hundred milliseconds to start a bzr serve process, assuming a warm system.  A cold system and some plugins can make that much worse.
 * mkanat nods.
<spiv> Drakeson: "bzr uncommit -r something && bzr revert", perhaps?
<spiv> Or maybe just "bzr pull --overwrite -r something", I guess.
<SamB_XP> spiv: how about an overheating system ?
<Drakeson> leave that aside for moment. assume I do rm -Rf * in a working directory (that leaves .bzr intact). How can I get get back all the files?
<spiv> I'm not sure exactly what the git jargon means.
<spiv> SamB_XP: I don't overclock, so I couldn't say ;)
<spiv> Drakeson: bzr revert
<SamB_XP> spiv: oh, mine does that without being overclocked
<Drakeson> spiv: thanks
<SamB_XP> I had to clock it down to get it to stop rebooting -- probably there is some kind of problem with the cooling ...
<Jemsquash> Does anyone know the timelines for 2.0? I see the release candidate has been pulled from the main page of bazaar-vcs.org.
<lifeless> rc1 was pulled, rc2 is out and fine
<lifeless> 2.0.0 is being assembled at the moment, no further changes
<Jemsquash> thanks lifeless
<mneptok> Jemsquash: just merging the animated .gif of poolie waving frantically that auto-displays during branch routines. stand by.
<mneptok> lifeless: was the decision final on this one for weave merges? - http://birdhouse.org/~mnep/avatars/scream.gif
<lifeless> heh
<thumper> is anyone going to fix the hardlinking issue with WorkingTree6?
<lifeless> thumper: eventually I guess? its fallout from content filtering, and theres a bunch of work needed in that area
<thumper> ok
<poolie> hey spiv, i may (if we're lucky) review your patch this afternoon
<poolie> i was wondering what you thought too about the idea of the client inhibiting itself from sending requests to servers when the implementation is known to be broken
<poolie> i think i asked before but didn't see (or remember :) your reply
<lifeless> spiv: the 'extra' in smart tcp server for testing is flummoxing me
<lifeless> spiv: got a minute for a chat
<lifeless> spiv: for example:
<lifeless> (Pdb) bzrlib.bzrdir.BzrDir.open(self.get_url() + '../')
<lifeless> *** UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', "Invalid URL join request: Cannot go above root: '/' + ('../',)")
<lifeless> bzrlib.bzrdir.BzrDir.open( "bzr://127.0.0.1:46829/")
<lifeless> *** BzrError: Attempt to escape test isolation: 'bzr
<lifeless> ...
<lifeless> self.get_transport(self.get_url())
<lifeless> <bzrlib.transport.remote.RemoteTCPTransport url=bzr://127.0.0.1:46829/extra/bzr%3A//127.0.0.1%3A46829/extra/>
<poolie> lifeless: could you look at bug 430738 some time?
<ubottu> Launchpad bug 430738 in bzr "Upgrade fails with NoSuchId in _iter_file_id_parents in add_inventory_by_delta" [Undecided,New] https://launchpad.net/bugs/430738
<lifeless> self.get_transport(self.get_url()).list_dir('.')
<lifeless> poolie: does 'check' pass on that repository?
<poolie> he doesn't say
<poolie> he says reconcile passed
 * thumper is helping some windows bound people with bzr
<spiv> lifeless: the last thing I would say is that if isinstance the for_testing server that you shouldn't hardcode /extra/; you can (and probably should) use server_obj.client_path_extra
<thumper> what is the absolute easiest way to install bzr on windows that allows bzr+ssh usage?
<spiv> thumper: windows on client, or server (or both)?
<thumper> how much hoop jumping needs to be done for people without ssh keys?
<thumper> spiv: windows client for sure
<thumper> spiv: I was going to set up my desktop as the main code host
<thumper> spiv: it is for a polytech project
<thumper> 3 people collaborating
<spiv> It should mostly just work, I think, now that we default to using paramiko on Windows.  (IIRC)
<thumper> spiv: as you may expect, my desktop is linux
<thumper> spiv: the bazaar wiki page for windows installing isn't very helpful
<mneptok> thumper: we know you still use an Amiga.
<thumper> it says "download these 8 things..."
<spiv> There's no requirement to have SSH keys, but they can help avoid the need to retype your password a lot :)
<spiv> thumper: Huh, I thought it was just a case of "download and run the .exe installer"
<thumper> spiv: I don't allow ssh with a password to my server :)
<spiv> thumper: but I could easily be wrong.
<thumper> which one?
<thumper> I tried the py 2.6 one as I thought that ment "uses python 2.6"
<thumper> but no
<thumper> the standalone installers say 2.2 and 2.3, and I'm not sure if they are meaning python or what
<spiv> Gosh, I'm out of date.  I thought there was just one!
<thumper> I'll ask again later tonight
<mneptok> thumper: IIRC, PuTTY allows creation and use of ssh keys.
<thumper> perhaps I'll get some windwos users
<spiv> thumper: http://bazaar-vcs.org/Download has, next to "Windows installer", a link called "default 1.18.1 installer".
<thumper> when is the 2.0 one going to be there?
<spiv> thumper: I guess you're looking at the Launchpad page of download files?
<thumper> yeah
<spiv> When it's released, I assume ;)
<thumper> :)
 * thumper goes to make dinner
<spiv> thumper: I'm pretty sure you almost always want to be using the "Standalone" installers on Windows.
<spiv> poolie: I'm ok with the idea of not sending requests we know the server will get wrong... the question is how can (and should) we determine the "known to be broken" fact?
<spiv> poolie: You're thinking of looking at version string in the response headers, I guess?
<spiv> poolie: the way we've dealt with this (or something similar, at least?) before is to create a new verb.
<lifeless> uhm
<lifeless> lp handles ~ fine
<lifeless> so I beg the question, how would one tell?
<bialix> hi all
<bialix> how's 2.0 moving?
<lifeless> spiv:
<lifeless> I don't know about you, but I'm pretty good at ignoring yet another email,
<lifeless> particularly email that comes from a cron job ;)
<lifeless> bah
<lifeless> copy paste fail
<lifeless> I don't know about you, but I'm pretty good at ignoring yet another email,
<lifeless> particularly email that comes from a cron job ;)
<lifeless> and gain.
 * lifeless stares at vim
<lifeless>         elif isinstance(transport_server, server.SmartTCPServer_for_testing):
<lifeless>             # The smart server adds a path similar to work, which is traversed
<lifeless>             # up from by the client. But the server is chrooted - the actual
<lifeless>             # backing transport is not escaped from, and VFS requests to the
<lifeless>             # root will error (because they try to escape the chroot).
<spiv> lifeless: sounds good
<spiv> lifeless: what are you referring to with "lp handles ~ fine"?
<lifeless> this should make you laugh:
<lifeless>     Attempt to escape test isolation: 'bzr://example.com/quack/' ['/tmp/testbzr-HhM4se.tmp/', 'file:///tmp/testbzr-HhM4se.tmp/', '/tmp/testbzr-HhM4se.tmp/', 'file:///tmp/testbzr-HhM4se.tmp/']
<spiv> :)
<lifeless> bzr+ssh://bazaar.launchpad.net/~lifeless/...
<spiv> I'm missing something.
<spiv> What was that comment in reply to?
<lifeless> 15:33 < spiv> poolie: I'm ok with the idea of not sending requests we know the server will get wrong... the question is how can (and should) we determine the "known to be broken" fact?
<spiv> Oh, that was unrelated to ~ in URLs.
<lifeless> ah ok
<poolie> it was unrelated
<poolie> it was about 1.17 sticking xml into chk streams
<poolie> purportedly chk streams
<poolie> spiv: we know now that 1.17 was broken
<poolie> poolie: it was unrelated
<poolie> poolie: it was about 1.17 sticking xml into chk streams
<poolie> poolie: purportedly chk streams
<poolie> poolie: spiv: we know now that 1.17 was broken
<spiv> poolie: right
<vila> hi all
<vila> poolie: you're speaking to yourself ? .... Often ?.... :P
<poolie> :) i think i fell off irc
<poolie> i wasn't sure if it got through
<poolie> what's the cleanest way to test things sent to trace.warning?
<vila> poolie: nearly done with bug #430749, I still have one failure
<ubottu> Launchpad bug 430749 in bzr ""Failed to load compiled extensions" warning breaks the test suite" [High,Confirmed] https://launchpad.net/bugs/430749
<poolie> ok
<vila> poolie: just in case you're on it
<poolie> i'm nearly done with giving a nicer message and am just trying to work out how to test it
<poolie> i'm also going out in about 40 mins
<poolie> oh btw, i forgot to say yesterday
<vila> ok, I think there is another for that
<poolie> i appreciated all your bug tidying
<vila> ok, I think there is another bug for that
<poolie> there is
<poolie> bug 430529
<ubottu> Launchpad bug 430529 in bzr "missing extensions warning is unclear" [High,In progress] https://launchpad.net/bugs/430529
<vila> ok, so no problem, we'll review each other :)
<vila> the way I address mine doesn't depend on the message only on the config variable
<poolie> this is kind of annoying
<vila> and last one fixed, running a full test suite to check
<poolie> it's a stupid thing to get stuck on
<poolie> the testing i mean
<vila> pfewwww
<vila> don't feel stupid, IME writing the first test of a new kind is always hard, far far harder than the code
<poolie> the thing is it's not the first
<poolie> it's just that trace really needs some cleaning up
<poolie> at least now we can do it with less fear of compatibility
<poolie> breakage
<vila> worth spendng some time on it isn't it ? :D
<vila> poolie: so what is it you're wanting to test exactly ? The text itself ? (Coincidentally I have test_config.py under my eyes, there is an assertWarning(warning)  there
<poolie> vila, the text, and it's no longer a python warning
<poolie> https://code.edge.launchpad.net/~mbp/bzr/430529-extension-warnings/+merge/11950
<poolie> i might pull at the cruft in a separate branch
<vila> ooh, it was a *python* warning, sorry I missed that
<poolie> i'll pull out some uncontroversial stuff from trace.py and send mail about the rest
<poolie> in short it's a question of whether we should still be using python logging
<poolie> it's a bit conflicted with our ui factory stuff
<poolie> it takes a little while to load
<poolie> and it makes things a bit more complex to test
<bialix> bonjour vila, good evening poolie
<vila> hello bialix
<vila> poolie: my vote is to unify under the ui banner
<vila> poolie: but I still have to read your mail :)
<naoki> commiting to stacked branch with bzr-2.0rc2 is OK on Ubuntu but failed on WinXP
<spiv> naoki: that sounds bad, please file a bug.
<naoki> https://bugs.launchpad.net/bzr/+bug/431223
<ubottu> Launchpad bug 431223 in bzr "bzr2.0rc2 fails commiting to stacked branch on WinXP" [Undecided,New]
<spiv> naoki: Hmm.  Sounds like bug 375013, but I don't know why you'd get different behaviour on Ubuntu vs. WinXP for that.
<ubottu> Launchpad bug 375013 in bzr "lightweight checkout commit to a stacked branch does not work" [High,Triaged] https://launchpad.net/bugs/375013
<spiv> naoki: perhaps on Ubuntu you aren't using a lightweight checkout of the branch?
<spiv> naoki: also, what version of bzr are you using on Ubuntu?
<rojanu> I am trying to connect to a server through proxy on Windows;  I have set http_proxy=http://my.proxy.server.com
<rojanu> even tried to configure authentication.conf to no avail, any ideas?
<vila> rojanu: try adding '-Dhttp' and look at your '.bzr.log' for clues
<rojanu> vila: where do I find the log?
<vila> 'bzr version' will tell you
<rojanu> Ok.  log has some traceback info and msg printed to stdout "bzr: ERROR: Connection error: failed to connect to bzr.bugzilla.org:4155: Operation timed out"
<vila> Did you specify '-Dhttp' in your command ?
<vila> Err, wait, you're connecting with a bzr+http:// url ?
<rojanu> here is my command "bzr -Dhttp co bzr://bzr.bugzilla.org/selenium/3.4"
<vila> rojanu: http is not involved here
<naoki_> spiv: I used bzr-2.0rc2 on Jaunty x86
<naoki_> spiv: And I didn't use lightweight checkout on both.
<naoki_> I did use only stacked branch that stacked on standalone branch.
<vila> rojanu: I meant, I don't know what proxy you're using but I'm not sure it will know how to transparently proxy the bzr protocol...
<rojanu> vila: I don't know what proxy it is apart from the server address.  In browsers, we have pac files specified!!!
<vila> rojanu: browsers speak http, bzr can speak http too with http servers, here you're trying to speak to a bzr server in the bzr protocol
<vila> rojanu: does bugzilla offers http access for that branch ? At a different address ?
<vila> rojanu: you may want to contact *them* to know that
<vila> s/know/answer/
<rojanu> vila:  I will contact bugzilla to get a http address, Thanks
<vila> rojanu: the alternative is to contact your admins to allow direct connection to  bzr.bugzilla.org:4155
<spiv> naoki_: thanks!  I'm still mystified, but I've updated the bug.
<lifeless> grr
<lifeless> "bzr: ERROR: Attempt to escape test isolation: 'file:///home/robertc/source/baz/pending/working/bzrlib/version.pyc/' ['/tmp/testbzr-laC87z.tmp/
<vila> lifeless: why grrr? Aren't you happy to catch one more ? :D
<lifeless> vila: this is 'bzr version looks for a bzr source tree'
<vila> haaa, GRRRRR instead
<vila> indeed I mean
<lifeless> vila: test root could be in ., and . is in the source tree, so permitting that means permitting all access within the source tree.
<lifeless> thus grr :P
<vila> lifeless: so that one test should be put in its own test class :)
<lifeless> vila: there are many such.
<lifeless> 400 tests to go
<vila> wow, 400 good reasons to escape ?
<vila> My remark was only for valid escape cases
<lifeless> I have a list of 500 failing tests
<lifeless> I've worked through finding causes the first 100 [and fixed]
<lifeless> so there might be only 2 left to go. I don't know :)
<vila> 8-/
<lifeless> 1;2c/win 20
<lifeless> vila: I know that you mean only valid cases, but when we open it up, that test can then misbehave, and we won't know
<vila> we don't know *today*, so better guard most of them, the 'bzr version' one, if I remember correctly, requires access to the source tree and can't even pass if run from an installed version
<lifeless> it should work when installed.
<vila> by skipping ?
<vila> or by conditional assertions ?
<vila> lifeless: if you could review https://code.edge.launchpad.net/~vila/bzr/430749-no-extensions-warning/+merge/11951 ,
<vila> I'll be able to put some green on the botnet which is currently full red :-/
<vila> kind of small-red-button but also related to your reflexions about config-in-home-dir accesses :)
<lifeless> vila: conditionals
<lifeless> do you see a double header on that page?
<vila> hoo, yes
<vila> one with branches, one with branch
<lifeless> thumper: ^
<lifeless> vila: reviewed
<vila> lifeless: bug #431133 ;-P Welcome to my world :D
<ubottu> Launchpad bug 431133 in bzr "blackbox.test_too_much.TestCommands.test_main_version in a checkout of bzr does network I/O" [High,Confirmed] https://launchpad.net/bugs/431133
<vila> lifeless: thanks ! Is that a tweak ?
<lifeless> vila: yes
<vila> lifeless: all impacted tests are based on TestCaseWithTransport and all use run_bzr_subprocess,  are you sure you want TestCase ?
<lifeless> vila: TCWT is fine
<vila> ok
<lifeless> the ExternalBase change is a no-op, you realise?
<vila> not sure what you mean by that, I delete all uses of ExternalBase because I find the class useless
<vila> and misleading
<pygi> hi folks
<lifeless> vila: ah
<lifeless> vila: see my proposal for new test dirs?
<vila> I don't think so
<lifeless> checl the list mail
<lifeless> _thumper_: hi
<_thumper_> lifeless: hi
<lifeless> _thumper_: https://code.edge.launchpad.net/~vila/bzr/430749-no-extensions-warning/+merge/11951
<_thumper_> lifeless: what's that?
<lifeless> do you see two headers there? Is that know/desired/a bug I should file?
<_thumper_> lifeless: I'm on windows :-|
<_thumper_> yes I know the two headers
<_thumper_> it is fixed in a branch I have in review
<lifeless> _thumper_: you poor thing.
<_thumper_> for 3.0
<lifeless> [windows]
<_thumper_> there were many heading issues with the new 3.0 work
<lifeless> whatever possessed you to do that?
<_thumper_> I'm trying to get bzr working on windows
<_thumper_> there are three different bzr standalone installers
<_thumper_> what is the difference between them?
<_thumper_> also, once I have them
<_thumper_> what do I need to talk to LP from a windows laptop?
<_thumper_> I need a local ssh key I guess
<_thumper_> are there docs on the bzr wiki on how to get this set up?
<lifeless> http://bazaar-vcs.org/Download
<lifeless> under windows
<lifeless> the first link
<_thumper_> I've got the 2.0rc2 from LP
<_thumper_> not the 1.18.1 one
<lifeless> theres a link to docs too
<lifeless> which explains the differences
 * _thumper_ looks again
<lifeless> yes, just need your ssh key; use pagent or putty or something like that
<_thumper_> lifeless: the download page isn't that helpful
<_thumper_> it doesn't mention the 2.0rc2 for windows
<_thumper_> nor the different stand alone installers
<lifeless> _thumper_: uhm
<vila> lifeless: amen for killing blackbox tests
<_thumper_> http://bazaar-vcs.org/WindowsDownloads has a wrong wildcard at the top
<lifeless> _thumper_: taking those point by point; the page is tuned for end users; end users shouldn't be using 2.0rc2.
<_thumper_> :)
<_thumper_>  bzr-2.0rc2-3-setup.exe,  bzr-2.0rc2-2-setup.exe,  bzr-2.0rc2-1-setup.exe - what's the difference?
<lifeless> secondly, for end users the first link, the one that says default, is the right one
<lifeless> where are you getting those links? Cause I have no idea.
<_thumper_> https://edge.launchpad.net/bzr/+download
<lifeless> I would guess at build number
<_thumper_> I'm downloading the 1.18.1 standalone installer now
<lifeless> jam: https://edge.launchpad.net/bzr/+download - are the -1- and -2- installers obsolete? if so lets delete em.
<lifeless> jam: I would, but I'm not sure I can undelete on lp if I'm wrong:)
<_thumper_> the windows downloads instructions doesn't say anything about "getting the default"
 * _thumper_ is being somewhat pedantic
<lifeless> _thumper_: s/pedantic/annoying/
<_thumper_> :)
<lifeless> _thumper_: where are you looking precisely please
<lifeless> because on here
<lifeless> http://bazaar-vcs.org/Download
<_thumper_> http://bazaar-vcs.org/WindowsDownloads
<lifeless> I see a link that folk will just follow and will just work.
<_thumper_> I followed the instructions link
<_thumper_> on the Download page
<_thumper_> people like instructions
<_thumper_> the instructions it takes you to contradict those on the earlier page
<lifeless> well the WindowsDownload page says 'most recent bzr-setup-*.exe'
<_thumper_> yes
<_thumper_> but that wildcard doesn't match
<lifeless> which modulo the aforementioned question about what the -N- bit is
<lifeless> right, so it should be fixed ;)
<_thumper_> bzr-*-setup.exe is right
<lifeless> I think so
 * _thumper_ ran the standalone installer
<_thumper_> where is the effective .bazaar directory on windows?
<_thumper_> for the locations.conf et al?
<lifeless> bzr --version
<_thumper_> 1.18.1
<lifeless> no
<lifeless> run it
<_thumper_> I did
<lifeless> it should have told you
<_thumper_> ha, didn't read that bit :)
<_thumper_> cool
<lifeless> naoki: your bug is a duplicate of the one that the error tells you about
<lifeless> naoki: you need a regular branch or checkout, pushing to or bound to respectively, to add data to a stacked branch.
<ngnp> I have the same (local) repo as Related branches: push, parent and submit ... what have I done wrong
<naoki> hmm, the error message tells me "Cannot commit from a lightweight checkout to a stacked branch.".
<naoki> I didn't use a lightweight checkout.
<lifeless> naoki: yes. there is more detail in the bug report it references
<lifeless> naoki: a stacked branch where there is an in-place tree is equivalent
<naoki> I see.
<lifeless> ngnp: I don't know that you've done anything wrong. what would you like bzr to do differently?
<naoki> OK. I mark my bug as duplicate.
<lifeless> naoki: I've done that;)
<lifeless> naoki: I was catching you here to explain
<lifeless> we'd like to make it work but its really not trivial
<ngnp> lifeless: I somehow did not expected these three ... just a push and parent? The weird this is that when committing the parent is sync immediately ... that's not what I wanted :(
<ngnp> synced
<lifeless> ngnp: do you mean repo or branch when you say they are the same?
<ngnp> lifeless: I'm working on ~htdocs/mdc and when committing there my ~/Documents/bzr/mdc is updated too. I want to control _when_ that happens :(
<lifeless> ngnp: which of those two did you create first?
<lifeless> ngnp: and how did you create the second one?
<ngnp> The ~Documents version
<lifeless> if you don't remember, just run 'bzr info' in ~htdocs/mdc and pastebin the result
<ngnp> first then dunno ... I guess a pull
<lifeless> I bet you did 'bzr checkout'
<lifeless> but the info will tell us
<ngnp> lifeless: http://pastebin.ca/1569478
<lifeless> see this line:   checkout of branch: ...
<lifeless> that says 'when you commit, it will auto push to the ...'
<lifeless> run 'bzr unbind'
<lifeless> and then you'll need to use 'bzr push' to do the push
<ngnp> lifeless: thanks :)
<lifeless> vila: do you recall what bzrlib/tests/commands/ is for
<lifeless> is that == the cli package I proposed?
<lifeless> vila: it doesn't really seem to be, to me?
<vila> not cli, quite the complement in fact
<vila> ..bad word :-/
<lifeless> its not clear to me how the tests there differ from other ones in blackbox, other than that they create the command object directly.
<lifeless> separately, InstrumentedTransport - that would be better as a decorator I think.
<lifeless> HookedTransportDecorator, decorate any transport you want?
<vila> wait a minute
<vila> paging context in
<lifeless> I ask, because the convolutions it goes through look to be precisely what chroot+ readonly+ etc all do already
<lifeless> and if it was setup like that it wouldn't be failing with isolation errors
<lifeless> BzrError: Attempt to escape test isolation: 'hooked://foo@localhost:37295/tmp/testbzr-VVo9LS.tmp/bzrlib.tests.commands.test_branch.TestBranch.test_branch_local_remote/work/' ['/tmp/testbzr-VVo9LS.tmp/', 'file:///tmp/testbzr-VVo9LS.tmp/', '/tmp/testbzr-VVo9LS.tmp/bzrlib.tests.commands.test_branch.TestBranch.test_branch_local_remote/', 'file:///tmp/testbzr-VVo9LS.tmp/bzrlib.tests.commands.test_branch.TestBranch.test_branch_local_remote/', '
<vila> So commands/__init__ says: Test the internal behaviour of the commands (the blackbox tests are intended to
<vila> test the usage of the commands).
<lifeless> well, blackbox tests internal behaviour for something like 90% of the tests in blackbox today ;)
<lifeless> I'm not objecting to the commands test package
<lifeless> just it was a bit of a spike you did,
<lifeless> and its been left fallow since
<vila> yeah, but nobody ever understood why it was named like that and even I am not sure :-/
<lifeless> The hooking stuff is spectacularly ugly though, and if I can get from you what you needed to achieve I'll do a separate branch to clean it up
<vila> pff, it's quite old and I seem to remember that I needed to do that to minimize changes at that time
<lifeless> vila: please think a bit about this
<lifeless> from what I can see you wanted to hook into some behaviour
<vila> may be it was to work around a bug fixed since like redirections bringing back pycurl transports instead or urllib ones
<lifeless> you created a TransportHooks
<vila> so I had to keep a tighter control than what decorators provided
<lifeless> which doesn't work for all transports
<lifeless> vila: I propose the following:
<vila> It's intended to be used for ConnectedTransport only
<lifeless>  - we make that transport hooks official and public for all transports.
<lifeless> non ConnectedTransports will simply never fire
<lifeless>  - we change the tests to just use SFTPTransport or FTPTransport directly
<vila> That *sounds* good (i.e. that seem to address the initial aims whatever they were, while being cleaner)
<lifeless> and finally, I'd be strongly inclined to consider these tests acceptance tests
<vila> Looking at the code also seem to imply I wasn't very good at parameterizing the tests at that time
<lifeless> if you wanted to do this overnight, I wouldn't complain :)
<vila> hehe
<vila> lifeless: don't count too much on it especially today, I need to finish early due to some light medical operation
<lifeless> vila: ok
<vila> lifeless: and that's really not today, tomorrow on the other hand... :-D SO maybe file a bug with the IRC discussion
<lifeless> vila: bug filed
<lifeless> vila: its kindof three bugs, I can file more specific ones when you run out of steam :)
<vila> lifeless: it's ok
 * vila fiddling with buildbot to add the timing run
<vila> lifeless: http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/1/steps/Non-regression tests/logs/stdio/text
<vila> that one is still in progress but the next should run on a "quiet" host (or I'll tune the scheduler) and with incremented numbers (after the /builds/ part)
<vila> lifeless: that way the archival is handled by buildbot and you can peek whatever suits your needs :)
<lifeless> thanks!
<vila> The format is correct ?
<lifeless> no idea
<vila> lifeless: on the other hand, we may want to integrate whatever processing you want in the botnet itself, that sounds quite its job after all
<vila> no urgency, just a thought
<lifeless> something is adding noise to it
<lifeless> wget -O- 'http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/1/steps/Non-regression%20tests/logs/stdio/text' | subunit2gtk
<vila> probably because you get both stout and stderr ?
<lifeless> ugh
<lifeless> can you squelch stderr then ?
<vila> sure
<vila> well, I'll try at least :)
<lifeless> 2>/dev/null
<lifeless> so the processing desired is 'analyse stuff'
<lifeless> which could be the subunit-ls --times I posted to the list
<lifeless> or 'how long are repo tests taking' etc
<vila> progress: 0
<vila> time: 2009-09-17 11:10:20.952940Z
<vila> program finished with exit code 0
<vila> elapsedTime=1.194652
<vila> that 2>/dev/null is quite a booster :D
<lifeless> Ran 465 tests in 206.470s
<lifeless> FAILED (errors=1, known_failure_count=18)
<lifeless> nearly there
<lifeless> more servers not supporting get_url :(
<vila> probably interpreted as a test name
<vila> there shouldn't be much left.. which ones ?
<lifeless> RecordingServer
<vila> haa
<zyga-work> hello
<zyga-work> I have a question about https://answers.launchpad.net/bzr/+question/71563
<zyga-work> how to use bzr join correctly
<zyga-work> does bzr, today, support nested trees in a way that allows one to have a branch that contains other branches
<zyga-work> and the inner branch can be still managed as a separate branch
<james_w> zyga-work: only at an experimental level
<zyga-work> great, do I need .dev tree or will 1.18 suffice?
<james_w> I don't think there have been any changes in that area
<lifeless> its not enabled for any supported repository format
<zyga-work> if you could walk me thru using it to, say consolidate a "workspace" branch that contains "libfoo", "libbar" and "program" I could update the wiki in return
<lifeless> zyga-work: ^
<zyga-work> :/
<lifeless> vila: bzr+ssh://bazaar.launchpad.net/~lifeless/bzr/test-speed - shiny shininess
<lifeless> oh bah
<vila> lifeless: was grabbing some food
<vila> lifeless: can't find a simple way to get a clean stdout :-/
<lifeless> ok, branch is actually pushed now
<vila> lifeless: hmm, indeed, totally different beast :)
<lifeless> so for --subunit
<lifeless> how about
<lifeless> selftest | tee subunit.log | subunit2pyunit
<vila> lifeless: the problem seems to be that the redirections can't be handled...
<vila> wow, the addition to start_server seems hackish, I'll have to test that against my local_test_server plugin asap
<lifeless> what builder are you using?
<vila> I created a new one (not committed yet if you're looking at the public branch0
<lifeless> vila: paste the relevant bit of the config here?
<lifeless> presumably only a couple of lines...
<lifeless> vila: start_server is hacky to the extent that tests depend on a directory *two levels up* from where they start to isolate them from the file system
<vila> lifeless: http://paste.ubuntu.com/272782/
<lifeless> if you imagine (and its not where I'm going - wt wants real disk, reasonably so), that everything was in a memory file system, we'd need to change our server start locations and so forth to provide those two extra directories.
<vila> lifeless: hmm, you mean xxx/work ?
<lifeless> safetynet/testname/work
<vila> yeah
<vila> hmm
<lifeless> so, you can argue that perhaps I should do that work first :)
<lifeless> but I think there is a chicken and egg effect
<vila> It will be clearer if that '../..' was obtained by a relpath calculation
<lifeless> can't do that
<lifeless> one url will be (say) sftp://, the other is file://
<lifeless> vila: try
<vila> but that's exactly where I have a problem (or rather not me but well), we have a relation between the server root and the test working dir
<lifeless> command = 'python ./bzr selftest --subunit 2>/dev/null'
<vila> OSError: [Errno 2] No such file or directory
<vila> Upon execvpe python ./bzr selftest --subunit 2>/dev/null ['python ./bzr selftest --subunit 2>/dev/null'] in environment id 48676992
<lifeless> urgh
<lifeless> ok
<lifeless> make a tiny little shell script
<lifeless> put it on the slave.
<lifeless> run that
<vila> exactly what I wanted to avoid :-/
<vila> but well, certainly the easiest in the mean time
<vila> lifeless: I'm tracking --usepty which is used at slave start and tie stdout and stderr, that may be a viable alternative
<lifeless> vila: whatever is easiest
<vila> done, try with 13 as number in the prvious url
<vila> rats, wait, I changed a part of the path
<vila> http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/13/steps/Timing%20tests/logs/stdio/text
<vila> lifeless: by the way, I went with the shell route, one more dependency but that's not a concern here
<vila> lifeless: and the schedule is 11PM my time i.e. 9 hours from now
<vila> approx your breakfast no ? :D
<lifeless> wget -O- 'http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/13/steps/Timing%20tests/logs/stdio/text' | subunit-ls --times | sort -n -k2 -r | head -n 20
<lifeless> :P
<lifeless> gnight
<lifeless> vila: just confirming - thats not using --parallel
<vila> lifeless: my god no ! :D
<lifeless> cool, thanks
<lifeless> bzrlib.tests.test_source.TestSource.test_no_asserts 24.874
<lifeless> bzrlib.tests.blackbox.test_breakin.TestBreakin.test_breakin 10.460
<lifeless> bzrlib.tests.test_hashcache.TestHashCache.test_hashcache_load 5.014
<lifeless> ...
<lifeless> its working - great
<lifeless> now, we just need a better QL for subunit
<vila> committed and publish on lp, patches welcome the script name time-selftest.sh
<lifeless> but I'm really really wiped, still sick & I meant to be in bed hours ago :(
 * lifeless goes
<vila> lifeless: and don't take the actual timings are accurate ! Lots of things happending here (catching up the no extensions failures)
<vila> s/are/as/
<vila> lifeless: sleep well !
<los> hi guys. Is there anything like: bzr diff --old XXX --new YYY --annotated ?
<los> I was looking for something that would show the diff annotated with info from YYY
<awilkins> bzr annotate YYY -r old-revision   ?
<awilkins> Oh wait
<awilkins> Probably want the new revision number
<awilkins> los: qannotate is pretty good :-)
<los> awilkins, checking...
<los> awilkins, sorry for delay.
<los> awilkins, I need it text based and basically what I want is: diff between the two trees + annotation on diff with data from more recent tree
<los> awilkins, any thoughts?
<awilkins> los: What's the metadata you want in the annotation?
<los> awilkins, committer would be enough, revno is optional
<awilkins> los: You may have to implement that if you want it ; it supports diff between arbitrary revisions but it doesn't have the --annotate option and I can't think of a simple way of doing it
<awilkins> But I'm not totally conversant with the innards
<los> awilkins, yes, that's what I was suspecting as well.
<los> awilkins, I was referring to the fact that I may need to implement it myself... :)
<awilkins> los: At least it won't be as hard as it would be for git (although I bet git already has it)
<awilkins> (and that's where your usage example is from)
<los> awilkins, I was not aware of that.
<awilkins> los: I don't know if git has it, TBH, I don't use git a lot
<awilkins> los: But if you review the implementation of annotate and diff I'm sure it's not hard to concoct it
<awilkins> Right, train time
<los> awilkins, thx
<sender> is there a way to ignore everything in /sites/default, except for /sites/default/files/showcase, without spelling out out all other directories?
<sender> RE:(?!sites/default/files/showcase/*).* works but ignores too much, e.g. a new file in root
<sender> RE:(?!sites/default/files/showcase/*).sites/default/**/* gives an python error ...
<kothog> I am curious: I am looking for a way to mirror a remote bzr repository locally--like a git clone, or a hg clone, or svnsync. Is there a way to do this with bzr? I don't need a working copy: just a copy of the remote bzr repository data.
<kothog> (I know I can pull a remote branch locally..  but does that get history and all other branches of the project, too?)
<beuno> kothog, not at the moment, no
<kothog> sad kothog.
<kothog> anything experimental developers want a test monkey for?
<beuno> kothog, I know there's a plugin called multi pull
<beuno> that may do something similar
<kothog> k..!   thanks beuno, appreciate your time and answers. :)
<maxb> Does anyone know why cvsps-import chooses to represent CVS tags as bzr branches?
<phinze> i'm continually getting Contents conflict in features/support/env.rb when i merge from trunk to project branch... i keep doing cp features/support/env.rb.OTHER features/support/env.rb; bzr resolve; but then next merge with a change for that file says it again
<phinze> what am i doing wrong here?
<phinze> maxb: i would imagine that's because CVS's concept of a tag is really closer to a bzr branch than what bzr calls a tag
<phinze> in bzr a tag is really more of a "revision nickname"
<phinze> http://bazaar-vcs.org/Tag
<phinze> whereas in cvs tag is really just a convention -- a branch you never write to that you call a "tag"
<maxb> That is not really true
<maxb> A CVS tag is a nickname for a tree-state
<phinze> (i was assuming svn maps back to cvs in that way... entirely possible i was wrong) :)
<maxb> In most cases one would hope and expect that the tree-state referred to a single point in time, i.e. a revision
<maxb> It is, however, true that a CVS tag can indicate a horrendous mishmash which corresponds to no true single revision
<phinze> ah, so it is like svn in that way, where each file can be at a different revision
<phinze> can't speak for its devs, but i imagine that the cvs import was just taking the safe route? :)
<phinze> so in CVS you cannot "commit" to a tag location?
<phinze> because you could do that in SVN
<phinze> okay getting somewhere: "(Bazaar currently relies
<phinze> of content analysis to detect binary files for commands like ``diff``.
<phinze> In the future, a ``binary = true`` rule may be added but it is not
<phinze> supported yet.)
<phinze> now to find the nature of that content analysis that is deciding my config file is binary
<phinze> so if a NUL byte occurs in the first 1024 bytes
<phinze> then bzr decided the file is binary
<phinze> *decides
<phinze> interesting
<awmcclain> We're getting this error when trying to buld 1.18 from source and 2.0 from easy_install: Cannot build extension "bzrlib._annotator_pyx".
<awmcclain> Use "build_ext --allow-python-fallback" to use slower python implementations instead.
<awmcclain> *build
<kfogel> Anyone know why I'm getting this, having just upgraded to latest trunk bzr?  http://paste.ubuntu.com/273029/
<pwolanin> anyone able to explain how bzr merging/tracking works in terms of different branches and history?  I'm trying to understand what the best workflow would be for a set of inter-related branches
<vila> kfogel: because you didn't run 'make' in your source directory
<kfogel> vila: ah, thanks.  'python setup.py build' used to do it; I guess not anymore?
<vila> build_ext you mean ?
<kfogel> vila: that fixed it
<kfogel> vila: I used to just do "python setup.py build" and get a trunk bzr that didn't give any warnings, and did use the C extensions.
<kfogel> vila: apparently, that's no longer sufficient, and I should run "make" instead.
<vila> kfogel: I never use build myself, always make, may be worth filing a bug
<kfogel> abentley: is it a bug that "python setup.py make" no longer seems to build bzr with C extensions, and "make" must be used instead, or was the old behavior just a coincidence and "make" is the Official Way?
<abentley> kfogel: No, it was "python setup.py build".
<sque> Hello I am trying to setup a multi-user server and I have really bad times with file permissions... I followed guides from here
<sque> especially i the part tha says "Setting permissions"
<sque> However.. the experiment failed. I created a folder named /bzr with 02770 permissions owned by root/bzr
<sque> but when I create a repository inside this folder it is created with those permissions: http://pastebin.com/d2a0c903d and commit from a non-root fails as it cannot write inside .bzr/branch/lock
<sque> can anyone advise me on what to do with file permissions?
<kenichi_> if you have a branch with no working-tree, how bad is it to create a branch of that branch, *under* the parent?
<zsquareplusc> sque: don't you need write permissions for the group on the folder? it can't create the lock file otherwise
<phinze> kenichi_: i have no idea, but that's a hilarious question ;)
<kenichi_> ha, thanks.  i can't think of anything *technically* wrong with it...
<doctormo> Advice please, how easy is it to tie into bzrlib to do a checkout while keeping gtk mainloops from freezing?
<sender> anyone the best way to resolve a "bzr: ERROR: KnitPackRepository('...')is not compatible withRemoteRepository('...')different rich-root support" error? I'm surprised as this comes up while pulling from the original repo...
<sque> zsquareplusc: Either I am an idiot or this bzr is NON user-friendly at all
<LarstiQ> sque: use posix acls
<Tak> don't you need to set the default umask as well?
<sque> LarstiQ: I am trying very hard!
<sque> What I have till now for the best practise is to create a group (I named it "bzr") and add all potential users of repository in it
<sque> Then i created a folder with 02770 permissions where it is my shared repository
<LarstiQ> sque: don't use plain old unix permissions
<sque> you mean ACL?
<LarstiQ> setfacl -m group:developer:rwx /bzr
<LarstiQ> setfacl -m default:group:developer:rwx /bzr
<LarstiQ> sque: the default: will cause newly created directories to inherit the right permissions
<sque> this is the best way?
<LarstiQ> sque: plain unix permissions can not express that wish
<LarstiQ> sque: yes
<kfogel> abentley: sorry, that's what I meant (typo in IRC, not on the commandline)
<spirov92> hi, I'm kinda confused. I made some changes in one branch, commited, then tried to push it on another branch over sftp, but the actual files are not modified. any ideas why?
<doctormo> Forget my last question, I'm stealing from bzr-gtk instead
<sque> LarstiQ: I know and that's why I am banging my head at the wall. Didn't thought to use ACLs. To tell you the truth I only know that it exists never used before, but I am asap to read more about it.
<LarstiQ> sque: https://bugs.edge.launchpad.net/bzr/+bug/50568/comments/9
<ubottu> Launchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed]
<LarstiQ> sque: they're very handy :)
<abentley> kfogel: In revno 4640, "setup.py build" does build extensions.  I haven't got a more recent bzr due to bug 430738
<ubottu> Launchpad bug 430738 in bzr "Upgrade fails with NoSuchId in _iter_file_id_parents in add_inventory_by_delta" [High,Confirmed] https://launchpad.net/bugs/430738
<spirov92> when I make changes in one branch and bzr push from that branch to another, the changes should be copied to the other one, right?
<spirov92> anyone willing to help a n00b?
<LarstiQ> spirov92: yes, the changes will then be in the other branch
<spirov92> but the actual files should be copied too? I don't see the actual files being modified
<Tak> spirov92: pushing over sftp?
<spirov92> yes
<LarstiQ> spirov92: if the other branch has a working tree, you will need to run `bzr update` for it to update the workingtree
<LarstiQ> spirov92: but are you sure you need a working tree on it?
<LarstiQ> spirov92: all bzr needs is in .bzr/
<spirov92> yep, I need a working tree, since the sftp branch is a website
<spirov92> um...the server doesn't have bzr installed. how do I update the tree over sftp?
<LarstiQ> spirov92: I recommend you use the bzr-upload plugin instead to do deployment
<spirov92> hmm...where do I actually get the upload plugin? can't find it in any openSUSE packages :(
<LarstiQ> spirov92: lp:bzr-upload
<LarstiQ> spirov92: so, `bzr branch lp:bzr-upload ~/.bazaar/plugins/upload`
<spirov92> thanks :)
 * LarstiQ heads to bed
<spirov92> yay, I now have the plugin :)
<LarstiQ> spirov92: see `bzr help upload` and or the README for instructions
<LarstiQ> night
<spirov92> night
<spirov92> hmmm....if I just copy the entire working tree and .bzr folder to another machine, it will still work, right?
<sque> LarstiQ: Ty very much it worked perfectly with ACL :)
<zsquareplusc> i'm using bzr cvsps-import and its creating thousands of notifications (bzr-notify). can i do something to clear the queue of notifications?
<lifeless> oh heh
<lifeless> kill the bzr-gtk process :)
<thumper> why does windows suck so much
<thumper> I got bzr working very easily
<thumper> getting it to push over bzr+ssh to another machine still doesn't work
<lifeless> is the other machine running a ssh daemon?
<thumper> I think there is some firewall thing somewhere that is blocking port 22
<lifeless> are you @ home?
<lifeless> there is a firewall in windows, configure it via control panel
<thumper> lifeless: I talk from my laptop to the desktop from home and away using linux
<thumper> lifeless: I was in windows on the same laptop failing last night
<lifeless> ok
<lifeless> see the control panel then :)
<lifeless> why the need for windows though?
<thumper> there is also norton internet security
<thumper> lifeless: to iron out the instructions for 3 other people I'm trying to teach bzr
<lifeless> brave man
<zsquareplusc> lifeless: i don't see a bzr-gtk process but there is a bzr-notify which i killed now, but notifications keep displaying. there is a queue somewhere :/
<lifeless> vila: urgle, you left in imports of config, after tweaking to not use it!
<lifeless> zsquareplusc: well, if you killed off the dbus reflector it will have spawned again
<zsquareplusc> lifeless: hm, i don't know what that is. killing bzr-notify worked and it did not restart
<lifeless> zsquareplusc: ok
<zsquareplusc> lifeless: it's not much of a problem. i'd just wish bzr cvsps-import would not create notifications for each changeset it's converting :p
<zsquareplusc> sorry to interrupt, poolie and/or lifeless, maybe one of you or someone with good bzr knowledge should probably check the instructions on sourceforge. i had problems understanding if they support multiple branches per project. maybe it's just me who did not understand but i think they should have a good description so that project admins feel confident to choose bzr over the other VCS they...
<zsquareplusc> ...also offer.
<zsquareplusc> that would be this page here: http://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar
<zsquareplusc> oh and they really do support multiple branches :-)
#bzr 2009-09-18
<poolie> hi zsquareplusc, sure
<spiv> Good morning.
<poolie> zsquareplusc: that looks ok to me on a brief read
<poolie> except it seems like you should be telling people to do init-repo in the project base directory
<poolie> then init under that to make the branches
<poolie> hi spiv
<zsquareplusc> poolie: so its fully clear to you that i can push several branches? i was expecting to read something about shared repository but it's probably me who does not yet fully understand that
<zsquareplusc> ok, with init-repo you would make a local shared repository for better efficiency (?), but that does have no impact on how the server stores them
<poolie> i'm suggesting you should init-repo on the server
<poolie> bzr init-repo bzr+ssh://.../project
<poolie> bzr init bzr+ssh://.../project/trunk
<zsquareplusc> hm ok. to late for me, i already pushed several branches :-)
<poolie> spiv, sorry, i didn't get back to your review
<poolie> i'll try again today
<lifeless> poolie: OMW
<poolie> me too, soon
<mwhudson> why can't a RegistryOption have a short_name?
<spiv> mwhudson: good question!
<lifeless> mwhudson: noone has made it work ? :)
<mwhudson> lifeless: yeah, fair enough
<RenatoSilva> It seems that I usually forget this, but how to overwrite a lp revision without deleting the original branch?
<lifeless> push --overwrite
<RenatoSilva> I thought I was thinking wrongly (that's probably why I did not thought of that flag :) )
<RenatoSilva> thank you again :) btw, is it my impression or bzr command interface needs some standardization?
<RenatoSilva> e.g. some commands you need a -d ,and other you don't for the same thing
<lifeless> spiv: bug 406687 - where is that up to? looks like a stale report to me ...
<ubottu> Launchpad bug 406687 in bzr "insert_stream doesn't check references are satisfied" [Critical,In progress] https://launchpad.net/bugs/406687
<lifeless> RenatoSilva: not really, -d isn't ever really needed, is it?
<RenatoSilva> lifeless: can't recall for what command...
<lifeless> please do file a bug in such a situation
<RenatoSilva> lifeless: pull from a bzr patch (that one generated by bzr send and that I always forget the name)
<lifeless> bzr pull filename ?
<RenatoSilva> isn't it -d filename?
<lifeless> no
<RenatoSilva> bzr pull [-d] thing ---> one you say it is a patch, other you say it is a master branch
<RenatoSilva> can't recall now
<lifeless> have a look at bzr help pull
<RenatoSilva> -d if for when . is not your branch right
<RenatoSilva> *-d is
<lifeless> thats correct
<RenatoSilva> ok thanks
<poolie> spiv, should we merge https://code.edge.launchpad.net/~spiv/bzr/lockcontention-bugs/+merge/9228
<spiv> lifeless: right, it should have been marked Fix Released in both targets; fixed now.
<spiv> poolie: it got stuck trying to decide if this was actually a good fix, IIRC.  I think long-term we will want to pass paths like this back through the pathfilter in smart server... I'm not sure if this is a good interim step or not if that's the goal.
 * spiv -> lunchb
<spiv> lunch, even!
<poolie> spiv, i haven't (re)read it, i just want it off my list
<poolie> this might indicate some kind of lp use case
<poolie> "i don't want to think about this more til something happens"
<spiv> poolie: well, how about I mark that proposal as rejected, for now
<spiv> poolie: it'll still be in my list of recent branches, to remind me, without cluttering the review list for everyone else.
<poolie> wfm, and just put it back to an inprogress bug
<spiv> Ok.
<poolie> going back to your patch now
<poolie> really :)
<poolie> spiv: homedir +1
<poolie> well, one question
<spiv> poolie: yeah, setUp/tearDown is consistent with transport Servers (even though that class isn't a Server)
<spiv> poolie: it never even occurred to me as I wrote that code to write "setUp" any other way :)
<spiv> poolie: I'll make them set_up and tear_down; we may as well start using the preferred naming style.
<spiv> poolie: thanks for the review!
<poolie> you're welcome
<lifeless> poolie: http://babune.ladeuil.net:26862/builders/timing-at-jaunty/builds/13/steps/Timing%20tests/logs/stdio/text is a subunit stream with timing data
<lifeless> spiv: my 2c are that I'd use setUp/tearDown because its the idiom we've used everywhere; its not a strong reason though
<lifeless> poolie: subunit-ls --times < text  | grep blackbox | awk '{ n += $2} END{print n}'
<vila> hi all
<vila> lifeless: regarding config imports, my delete-useless-imports day is friday, couldn't do it yesterday, sorry about that
<poolie> hi vila!
<vila> lifeless: the timings run#15 should be as accurate as possible, at least the noise was certainly very low
<vila> and the botnet is fully green, "Dormez bonne gens !" :D
<poolie> vila, is binding the jail to the test instance really needed?
<poolie> it seems a bit like unnecessary coupling to me
<vila> oh in theory yes, in practice that the easiest thing to do
<vila> Said otherwise: there are two test base classes proposed here, as you can see they are pretty trivial no you can redo your own binding even in a test method if you want
<vila> I don't consider the proposed implementation as final anyway, I just want it to be easily usable,
<poolie> fair enough
<vila> And I've been able to paste fully copy/pastable examples here and there in the bug reports (cough, a bit too much may be, but well, I viewed them as part of hte experiment)
<vila> err, I meant: "In theory no (you don't have to bind the ScriptRunner to a test instance, you just need to provide a ensure_jail())"
<poolie> yes, they look
<poolie> anyhow, i'm going back tothat patch
<lifeless> vila: no need to apologise.
<poolie> i meant to say, they look great
<vila> lifeless: joke :D
<vila> lifeless: thanks for the heads-up was the hidden message
<vila> lifeless: I wish we had better ways to identify useless imports... is it pyflakes that can be used for that ?
<vila> spiv: ^
<poolie> vila: it can, but lazy_imports seem to upset it
<vila> poolie: ha right, thanks
<poolie> i'd like to write that import effort test sometime
<poolie> probably not this afternoon though
<vila> argh, 'bzr pull' is not undoable :-(
<spiv> vila: it can, and mwhudson has a branch of it on lp that understands lazy_imports
 * vila . o 0 (Yet another botnet job... remaining hidden until successful)
<mwhudson> vila: and you can hook it up to flymake in emacs
<vila> mwhudson: err, .el somewhere ?
<vila> mwhudson: we really need a wiki for that kind of tricks
<poolie> ok i'm off
<bialix> hi *bzr
<spiv> mwhudson: and there's a similar thing for vim, now
<mwhudson> vila: https://dev.launchpad.net/EmacsTips
<mwhudson> spiv: yeah well, who cares about that? :)
<spiv> mwhudson: :P
<vila> mwhudson: OMG, Christmas time !
<vila> mwhudson: "unused imports and unrecognized games" is the later a typo or a joke I miss ?
<vila> hi bialix !
<bialix> bonjour mon cher vila
<jml> vila, it should be "names", not "games"
<vila> jml: ok
<vila> jml: wow, already fixed, you're quick :)
<AnAnt> Hello, is it possible to split a bzr repo into several repositories ?
<AnAnt> I asked this question few months ago, and I was told that there will be a new format that makes that easy
<mvo> hello! I stumbled accross this error message just now: http://paste.ubuntu.com/273312/plain/ - it first says ssh can not find the hostname (a problem with my nameserver) and then a very different bzr error message
<NET||abuse> hey guys.
<NET||abuse> i have a quick question on workflow....
<NET||abuse> there's 2 of us, well, my self on my linux machine, and my windows machine is branching from the linux machine.
<vila> spiv: ssh-homedir landed, Yes !
<NET||abuse> as i code on linux, i do bzr add; bzr commit;    and that keeps the local bzr branch updated...
<vila> NET||abuse: then you push from windows and suddenly your working tree is not up-to-date anymore ?
<vila> NET||abuse: Issue 'bzr update'
<NET||abuse> as i do design on the windows machine(flash and photoshop work mostly) i want to push up to the linux branch, so,, bzr init-repository; bzr branch ssh://me@linuxip/path/to/bzr/repo; hack hack.. bzr commit; bzr merge; bzr push???
<NET||abuse> is that the series of events?
<NET||abuse> ahh, and after i push from windows, onl linux i do what you say, bzr update;   will that overwrite any changes i make on linux if say the same file was edited on windows and checked in later than the commit occured onlinux?
<NET||abuse> do i not have to bzr merge on linux?
<NET||abuse> i ithink,, i'm confused as to the functionality of some of the commands.
<NET||abuse> bzr merge and bzr update,, what's the difference?
<vila> on windows: bzr branch bzr+ssh://you@linux/path/to/branch; cd branch; hack, hack; bzr commit -m 'blah'; bzr push
<fullermd> It's a plausible series of events.  Not the only, but workable.
<vila> on linux: 'bzr update if you did push from windows
<NET||abuse> ok,
<fullermd> Totally different commands; it's like asking the difference between a motorcycle and a tree stump.
<NET||abuse> what's the difference between a motorcycle and a tree stump?
<vila> NET||abuse: It may be clearer to use a master branch where both users push though
<fullermd> Tree stumps are hard to change the plugs in   :p
<vila> What's a stump ?
<NET||abuse> vila, yeh, i'm more used to an svn style workflow
<fullermd> 'update' is a command that works between a working tree and its branch.  In general, it means "catch me up with changes in the branch".
<lifeless> mvo: thanks
<lifeless> mvo: kindof a known cleanup issue
<NET||abuse> i guess it's only while i'm doing flash stuff and whatnot that i branch off the linux laptop to work on it... 90% of the time i'm just hacking away on my linux machine.
<fullermd> 'merge' is a command between branches.  In general, it means "bring over changes from that other branch"
<NET||abuse> so i just have a solo project style..
<fullermd> (technically, it's between your local WT and that other branch, since it doesn't _commit_ the merge, just _prepares_ them.)
<NET||abuse> fullermd, ahh,, ok,, so on the windows machine, why would i not just do bzr update also?
 * vila . o 0 (Of course the question *has* to be asked to fullermd ....)
<fullermd> Well, you could, but it wouldn't accomplish anything toward getting changes from the branch on your Linux machine.
<NET||abuse> vila, sorry, i don't mean to make you feel left out :)
<fullermd> All it would do is update the WT to the local branch (which is presumably a no-op, since the only way you get new revs into that branch is through that WT anyway)
<vila> NET||abuse: I don't :) fullermd speaks better than me :)
<NET||abuse> ;)
<NET||abuse> ahh, ok,, so a flow of how the data moves from the remote branch to the local WT is waht i was missing.
<fullermd> Pfft.  vila just knows that when *HE* asks a question of me, he ends up spending half a day tracking test failures.
<NET||abuse> when you pull down from the remote, i wasn't sure where the changes came into, i thought they were stored in the local branch in the background and then updated into the local WT
<fullermd> When you 'pull', that's what happens, yes.
<fullermd> When you 'merge', it prepares a new commit in the WT that contains those revisions (they sort of sit in limbo until you commit them, then they get hooked in)
<NET||abuse> so a pull would just pull the remote branch to the local branch in the background, and the local WT wouldn't see the pulled updates.
<fullermd> No, pull updates the working tree.
<NET||abuse> arrr...
<fullermd> But you can't pull unless you're an ancestor of the remote tip.  If you have local commits, for instance, you can't pull.
<fullermd> (well, you can pull --overwrite, but that throws away your local commits.  Probably not what you want.)
<NET||abuse> yeh, see i'm seeing it now as there are 2 copies of the code base on the machine, a branch that lives as parth of the the working history repository in the .bzr  directory and the working copy.. but i feel i'm not right in thinking that.
<NET||abuse> need to study the documentation more closely again and really try to understand the data flow behind the scenes,
<fullermd> spiv: That bzr+ssh ~ support does all the work on the server side, right?
 * vila . o 0 (Oooh, *1* half-day ? Really ?) :-P
<NET||abuse> these code management things have always taken a while to click in my head
<vila> fullermd: AIUI (bzr+ssh) yes
<vila> fullermd: that way old clients benefit too
<fullermd> NET||abuse: Try this.  The important unit is the Revision; a given state that you commit'd (there are other ways to create them, but that's 99.99% of them)
<fullermd> Yah.  But new clients with old servers don't  :p
<fullermd> (I mean, it's not much of a question...   it _can't_ be done anywhere but server side, so I don't know why I asked...)
<NET||abuse> ok, i think i just need to continue using it for now..
<fullermd> NET||abuse: So everything you do is in some way related to manipulating revisions (rather, moving them around, since they're immutable once created)
<NET||abuse> these concepts will slowly sink in as i see them happen.
<NET||abuse> yeh, your only creating new revisions by branching the previousrevision.  that makes sense,
<fullermd> NET||abuse: The three bits you work with are Repositories, Branches, and Working Trees.  And most of the time you don't actually work with Repositories, so you can pretend they're just a part of the Branch.
<fullermd> So you can think of the Repo/Branch as SVN's repo, and the Working Tree as a SVN checkout.
<fullermd> (except of course that on a SVN project, you need to move heaven and earth to have multiple repos talking together.  And even then it's iffy.)
<fullermd> So, you have two Branches (and their associated Repos); one on the Linux box, and one on the Windows.
<fullermd> And each branch has a Working Tree.
<fullermd> So the question you need to answer at any given point is "What am I doing with the Revisions?"
<fullermd> The answer can be "making a new one", which basically means editing files in the WT, fixing old bugs and creating new ones, and then 'commit'ing them to make a new Rev.
<fullermd> Once that's done, you have a new Rev in that Branch (and _not_ in the other Branch, so they're now out of sync, even if they were perfectly sync'd before)
<fullermd> The other main answer is "copying Revs from one of these Branches to the other"
<fullermd> That can happen via a variety of commands, the most pertinent being merge, push, and pull.  Each of those applies in a slightly different situation.
<fullermd> push and pull are (almost) symmetrical, it just being a question of whether you're in the source pointing at the destination, or in the destination pointed at the source.
<fullermd> Either of them works in the case that your source already includes everything the destination does (and presumably has new stuff on top)
<fullermd> e.g., you commit on the Windows Branch, then you 'push' that new rev to the Linux Branch.  Or you commit in the Linux Branch, and then you go into the Windows Branch and 'pull' that new one down.
<NET||abuse> aha, ok .... just one thing, i can't for the life of me imagine how from linux i could pull from windows..
<fullermd> Oh, it's possible in various ways.  But you may not want to bother figuring it out, since it may not matter (after all, you can just push from Win)
<NET||abuse> is that just a network protocol access problem more than anything :)
<fullermd> Probably.
<fullermd> Clear so far?
<NET||abuse> so from your own perspective, you can treat one working copy as a master repo like i am doing, pretty successfullyl.
<NET||abuse> yeh, so far it's making sense.
<fullermd> OK.  So that just leaves us with 'merge'.
<NET||abuse> yeh, this is the fuzzy one.
<fullermd> Merge is what you use when you can neither push nor pull (simplifying things).
<fullermd> Which is to say, that _neither_ branch is an "old version" (so to speak) of the other.
<fullermd> Say you commit on Windows, and then you go commit something else on Linux.
<fullermd> Now _each_ branch has stuff the other doesn't.  So you can't pull/push either way (without losing stuff).
<NET||abuse> when there are parallel changes in both branches, the local windows one and the linux one it pulled from.
<fullermd> Right.  So now we need a way of pulling these two heads together.  Or, should we say, merging them.
<NET||abuse> aha, ok that's making a little more sense.
<fullermd> Since accessin Win remotely has its issues, we'll just assume you're sitting at the Win box when you go to resolve this.
<NET||abuse> yeh, ok
<NET||abuse> and merging goes straight into the local windows WT
<fullermd> So you'd do a "bzr merge bzr+ssh://linux/foo" (or whatever the path; it will default to the same location as 'pull' if you don't explicitly give one, so you probably don't need to give one at all)
<NET||abuse> yeh, i don't have to. :)
<fullermd> What that would do, is bring over that Rev (or Revs, if there are more than one you don't have locally), merge the changes in the Working Tree, and stash the actual Revs in limbo.
<fullermd> That gives you a chance to review the changes made, fix any conflicts, and then when you're satisfied with the merge, commit it.
<fullermd> What that gives you now is a new Rev, which has _two_ parents, instead of the _one_ that you normally have.
<fullermd> To wit; your previous local head Rev, and that head Rev you got from the other branch.
<fullermd> So NOW, this local branch is a superset of the remote branch, and you can 'push' without losing anything.
<NET||abuse> ok, that's pretty well explained,
<fullermd> OK.
<fullermd> So since update was brought up, let's skim that real quick
<NET||abuse> ok
<fullermd> Update is most useful when your Working Tree is out of date with your Branch.
<fullermd> That will happen in this scenario when you've made changes on Windows (whether purely local or involving merge's, doesn't matter), then you 'push' them to the Linux box.
<fullermd> Over remote protocols, push doesn't update the working tree.
<fullermd> So now your WT on Linux considers itself "based on" an older revision, which is no longer the head of the branch.
<fullermd> And you can't commit from that state; you can only add on to the 'end'.
<fullermd> So you'd need to "bzr update" on Linux to 'catch up' the WT with the branch.
<fullermd> When you 'pull', you generally do it from within a branch, so 'pull' will update the WT as a matter of course after it does the Branch changes.
<NET||abuse> so if i did a bzr commit on the linux WT at that point, before doing update, it would complain?
<fullermd> Right.  Also, I think 'status' warns when the WT is pointing at an older rev.
<NET||abuse> ah, ok
<fullermd> Pretty much what happens with SVN if you try and change a file after somebody else commit'd to it, but without update'ing.
<NET||abuse> yeh, ok
<fullermd> It just happens less often in bzr, since Most Of The Time(tm), people aren't push'ing revs into your branch behind your back.
<NET||abuse> :P
<fullermd> The only way you get new revs is by commit'ing them, or pull/merge'ing them from elsewhere.
<NET||abuse> sneaky commit's
<fullermd> But in some cases, like this one, you have a branch that is both "a branch you're working in", and "a branch you're pushing into from elsewhere" [the Linux one], so new revs can show up without the WT knowing about it.
<fullermd> And there's nothing at all wrong with that.  It just means you sometimes have to nudge the WT.
<NET||abuse> huh, that goes along way to explaining how you can merge copies of code from various different members of a team.. it is a bit more of a learning curve than svn... but i can see some plausible use cases
<fullermd> ...   I think that's sufficient confusion   :)
<NET||abuse> so one last area that's confusing me, init-repository, branch and pull?
<fullermd> init-repo is used to create a shared repo, that can be shared across branches.
<NET||abuse> i've seen people say you should init-repository on , for example, my windows machine, before branching.
<fullermd> If you 'init' a branch without one (or create a branch another way, like with 'branch'), it builds an internal repository.
<fullermd> The downside there is that if you have 2 or 3 or 30 branches of the same project, every branch has a full copy of the history, and most of it will naturally be duplicated.
<fullermd> If the branches share a repository, though, all that duplicated history only gets stored once.
<fullermd> So if you expect multiple branches of one project, it's better to init-repo a shared repo for them before you start.
<NET||abuse> hmm, trying to think how you'd end up with multiple branches in a project..
<fullermd> But it's not a big deal.  You can create a repo later and change the branch[es] you already have to use it.
<fullermd> Heck, I've got dozens of branches of projects around   :p
<NET||abuse> oh, so you could branch for a specific feature,
<fullermd> It's not like SVN where that repository has some semantic meaning, or acts as a boundary.
<NET||abuse> and then have 2 or 3 branches of the same code base
<fullermd> The only real difference is makes is saving your disk space and I/O bandwidth.
<jszakmeister> fullermd: how do you do that?  Switch a branch to using a shared-repo, that is?
<fullermd> Which is well worth it, to be sure.  But running commands between branches works the same whether they share a repo or not.
<fullermd> jszakmeister: See the help for 'reconfigure'
<jszakmeister> Thanks!
<NET||abuse> ok,, so you can create a branch by bzr branch [remote branch]   or bzr pull [remote branch] ??
<fullermd> (this is actually a _slight_ lie, because there are some edge cases where the repo will change behavior.  But they don't really matter until you get deep into stuff)
<fullermd> pull won't create a branch; it only updates one you already made.
<fullermd> That's one of the asymmetries between 'push' and 'pull'; push will create the target if it doesn't exist, pull won't.
<NET||abuse> ahh, so you don't start a fresh branch with pull ,,
<fullermd> Right.  You basically create a branch one of two ways.
<NET||abuse> init-repo or branch?
<fullermd> With 'branch' (make a new copy of an existing branch to work with), and 'init' (create a new empty branch)
<NET||abuse> cool..
<fullermd> init, not init-repo.  init-repo just makes a shared repo for branches to use.
<NET||abuse> and from an init'd branch you could pull code from a remote branch somewhere
<NET||abuse> ahhh
<fullermd> With a bare Repository, you can't _do_ anything.  It just exists for Branches to use behind the scenes.
<NET||abuse> hmm
<NET||abuse> that's a new concept.
<fullermd> Sure.  You could "bzr init x ; cd x ; bzr pull http://some/where" instead of "bzr branch http://some/where x", and they'd do pretty much the same thing.
<fullermd> (it would be silly, but you could do it  ;)
<NET||abuse> cool, ok that much makes sence.
<NET||abuse> yeh, i wouldn't bother doing it, just to make sense of some of it that helps.
<fullermd> Yeah.  It can be a bit of a change from SVN, because in SVN the bzr concepts of Branch and Repository are sorta both crammed into the Repository.
<fullermd> (well, half of the Branch concept anyway.  The other half doesn't really exist, and just gets faked up with other primitives.  But that's details.)
<NET||abuse> you couldn't do bzr init ./blah; cd blah; bzr branch [remoterepo] ./v1; bzr branch [differentrepo] ./v2;     would that be wrong?
<fullermd> Well...    it would be weird.
<fullermd> (and you branch a Branch, not a Repo)
<NET||abuse> ok sorry, branches then.
<fullermd> What you'd end up with is three branches, one with nothing in it, and two others that happened to be below it in the filesystem.
<fullermd> Maybe you meant init-repo there?
<NET||abuse> hmm, ok so that'd be why you use init-repo for shared repo.
<NET||abuse> not really, just getting the difference between the 2
<fullermd> Basically, everything you directly interact with is a Branch.
<fullermd> You commit onto a Branch, look at the log for a Branch, etc.
<fullermd> Repositories are basically giant buckets that Revisions get dumped into.
<fullermd> Branches point at a Repository and say "look in there for [these revisions], those are the ones that are part of me"
<NET||abuse> if you worked in a group and had a central master branch you all checked out of, but wanted to be able to push specific changes over to a co-worker but not he central branch, you could set up pointers to eachothers local branches?
<fullermd> Mostly, the only time you directly look at or interact with a Repo is when you run init-repo.
<NET||abuse> ok
<fullermd> Usually, you'd go the other way; tell them to pull (or merge) from your branch.
<NET||abuse> checked out? there goes my svn centric concepts again.. a master branch you all branched out of...
<fullermd> No, you could all checkout the master branch too.
<NET||abuse> eh?
<NET||abuse> by checkout are you making a destinction from branching from the master branch?
<fullermd> 'checkout' creates a Working Tree for a given branch.  And usually it's used for making multiple WT's on the Branch.
<fullermd> Which is the same flow you have in SVN.
<NET||abuse> hmm
<fullermd> No, by checking it out.  "bzr checkout http://some/where"
<fullermd> (well, probably not http, since you presumable want to be able to _write_ there, so bzr+ssh:// or something)
<NET||abuse> well, web dav will allow you to write.
<NET||abuse> but anyway.
<fullermd> Then you basically have one shared branch that everybody has a WT on.  When you commit, everybody else needs to 'update', just like in SVN.
<fullermd> This is a workflow that DVCS's in general kinda shun, and nobody but bzr (TTBOMK) really first-class supports.
<fullermd> Me, *I* use it all the dang time, because it's really useful.
<NET||abuse> oh?
<NET||abuse> TTBOMK>
<NET||abuse> ?
<fullermd> To The Best Of My Knowledge
<NET||abuse> ahh, just urban dictionary'd it.
<fullermd> Ogod, I'm speaking urban now?
<NET||abuse> :P
<fullermd> By default, checkout creates what's called a "heavy" checkout, which means that it also copies down and stores the full history, just like 'branch' does.
<fullermd> That means that things like "bzr log" don't have to go across the network to the server.
<NET||abuse> hmm, why would it be useful? It just would prevent you from being able to ever use the WT to branch from again if you wanted to push work up from another machine, like in my case, I have 3 pc's, linux windows and a netbook, which i code on sometimes when traveling..
<fullermd> With a heavy checkout, you _can_ use that checkout as a source for 'branch'.
<NET||abuse> ohhh,,, yargg..
<NET||abuse> not sure i get the difference between that and a regular branch then.
<fullermd> The difference is that the Branch for that WT is the one off on the server you checked out from.
<fullermd> So when you 'commit', the rev goes there.  When somebody else has commit'd, you get told you're out of date and to 'update' before you can commit.
<fullermd> It's something you might commonly use for 'trunk' branches, for instance.
<NET||abuse> so it's more like a pure svn approach for that instance.
<fullermd> Right.
<OllieR> Hey I am having problems with bzr export. http://pastie.org/621552 - I run an export but the zip it produces is 0kb...
<fullermd> OllieR: Dunno, sorry; I don't know much about export   :(
<fullermd> NET||abuse: Let's invent a setup much like what I use.
<NET||abuse> haha, ok ..
<fullermd> NET||abuse: We have a project, project1.  There's a central server with a 'trunk' branch on it, that me and the other 6 guys all work on to move this thing forward.
<NET||abuse> yeh, sure.
<fullermd> I'll create a shared repo at /project1 (yeah, I base everything off the root dir for examples)
<fullermd> So "bzr init-repo /project1"
<NET||abuse> cool, we've init'd a shared repo. great.
<fullermd> Now, I make a checkout of the trunk: "cd /project1 ; bzr co bzr+ssh://server/project1/trunk"
<fullermd> Being a heavy checkout, it copies down all that history, and stores it in the shared repo instead of internally.
<NET||abuse> right, we've got our heavy checkout of the trunk branch..
<vila> OllieR: 'bzr version' ? What happens if you don't specify '--format zip' ?
<fullermd> So now I can work SVN-style by working and commit'ing and update'ing and all in /project1/trunk
<fullermd> And in fact, if the other 6 guys are all SVN-heads, I can basically move them to bzr with this setup, and the only difference they'll see is they run "bzr whatever" instead of "svn whatever".
<fullermd> They don't need to know anything about local branches or distributed whosafudge.
<fullermd> But I do, see.  'cuz I'm smart and stuff.
<NET||abuse> haha, cool, cause i have 5 guys in the office here all on svn, and i've broached the bzr scenario with them and they're... meh.. about it.
<fullermd> So I want to work on adding nobbles to it.  But that's gonna take a while and break stuff while I do it.  People get pissed when I break trunk, for some reason.
<fullermd> So, I make a new branch: "cd /project1 ; bzr branch trunk add-nobbles"
<NET||abuse> yeh, i get that too.. but my commits usually break buildbot.
<fullermd> Now I have trunk, still a checkout of the central trunk.  Anything I do there goes straight to the central server.
<fullermd> But I also have add-nobbles, as an independent branch, existing nowhere but on my drive.
<NET||abuse> cool, so we've branched from our heavy checkout to another local branch but both in a shred repo. one history.. gotcha.
<fullermd> (and that happened fast, because 'trunk' and 'nobbles' are both using the shared repo at /project1, so it didn't have to actually _copy_ any history)
<OllieR> vila: http://pastie.org/621552
<fullermd> So now I can go ahead and work on add-nobbles for the 9 weeks it takes me to finish it, without bothering turnk.
<fullermd> And without having 9 weeks of changes sitting uncommitted in a checkout, just begging for disaster.  I can keep on making a few commits an hour there.
<NET||abuse> yeh, this is a scenario i really like.
<fullermd> Of course, trunk keeps moving ahead while this is happening too.  I can still be working on fixes there and commiting them into trunk.
<OllieR> vila: added version output and export without --format zip. It seems it just exports an empty directory...
<fullermd> So every couple days, I "cd /project1/add-nobbles ; bzr merge ../trunk ; (check them over) ; bzr commit", to bring in the trunk changes.
<vila> OllieR: 'bzr ls -RV' ?
<fullermd> This way I don't diverge too far, and when I get conflicts, they're small and easy to fix, rather than trying to do one giant merge at the end.
<fullermd> Of course, this doesn't affect trunk at all.  Just add-nobbles.  But it means that I'm keeping up with those changes all the time.
<fullermd> Eventually, I finish up, and it's ready to go.  So I "cd /project1/trunk ; bzr update (just to be sure) ; bzr merge ../add-nobbles ; (check) ; bzr commit"
<OllieR> vila: null - so does bzr export only work within a working tree
<OllieR> I am using it from a treeless repo
<fullermd> My network churns for a while, uploading all those new revs to the server, and presto; the branch is landed into trunk.
<fullermd> Next time everyone else 'update's, they get all those changes.
<NET||abuse> fullermd, brb, one sec, have to move some application certificate for boss...
<vila> OllieR: Could be, may be worth filing a bug
<fullermd> Now, a few things here; first, that last merge is _EASY_, because I've already pretty much caught all the conflicts and fixed them with the periodic merges of trunk into add-nobbles.
<fullermd> NET||abuse: Second, it's not just the equivalent of doing a big "diff | patch"; every single one of those hundreds of revs I put into add-nobbles is now in trunk, so if we need to track back into them for something later, they're ready and accessible.
<fullermd> NET||abuse: In fact, I could "rm -rf /project1/add-nobbles" now if I wanted to; everything that was in it is in trunk now.
<fullermd> NET||abuse: And third, all of that work was local.  Nobody else even had to KNOW I was working on nobbles, and nobody needs to ever know or care that I did it in a separate branch.
<fullermd> NET||abuse: So 95% of your team can totally ignore branching, and just work lockstep in trunk like SVN.  And the 5% willing to shoulder the extra mental load of dealing with multiple branches can reap the benefits without getting in anyone else's way.
<fullermd> NET||abuse: And that 95% can slowly start using branches if they want too.  Maybe when you're working on something big in a branch, and want to share it with other people.
<fullermd> NET||abuse: The two (or 3, 4, etc) of you can share the branch among yourselves, merge'ing each other.  Or put it on a 'central' server, whether the same central server as trunk, or a different central server, and all create your own 'checkout's of it.
<fullermd> NET||abuse: (and then your own local branch's of THAT checkout, and...   *headsplode*)
<OllieR> vila: Yeah works from a checkout!
<OllieR> http://pastie.org/621552
<NET||abuse> fullermd, back, sorry, had to move a certificate for an applicaiton.
<OllieR> Nothing about that in the manual
<fullermd> NET||abuse: NP.  That's what backscroll is for  :)
<NET||abuse> fullermd, :)
<fullermd> So you can start working just like SVN, and scale up (individually or as a team), when you're ready to handle the extra complexity and have a situation where it's worth it.
<vila> OllieR: right, you can copy that paste into a bug report (slightly edited may be)
<fullermd> In my work, a lot of stuff still just happens on trunk.  Small bugfixes, tiny features...  roughly "anything that fits in one revision", I tend to just do straight on trunk.  Simpler.
<fullermd> The longer or more involved or more breakage-inducing it is, the bigger the advantages of making a branch for it.
<fullermd> I can choose on a case-by-case basis.
<fullermd> vila: Diff too large for email (1008 lines, the limit is 1000).
<fullermd> vila: You couldn't have made that 8 lines shorter?   :p
<NET||abuse> fullermd, hmm, that's fascinating,, i'm going to have to digest it before i use it more broadly, but i can imagine myself doing so in time..
<vila> fullermd: I'm trying to do that right now for a follow-up :D
<fullermd> NET||abuse: Sure.  Pick up new bits when they're helpful.
<NET||abuse> one of the reasons i'm looking into bzr is because of launchpad, we're very happy with trac here, but,, launchpad is pretty awsome... and we'll likely setup a copy and play with it :)
<NET||abuse> so i'll have to look into migrating our svn history into bzr somehow
<NET||abuse> then connect up launchpad as a web companion to the bzr projects we work on.
<fullermd> For a diversion, imagine I checkout'd /project1/trunk without making a shared repo at /project1, because I'm just gonna use the checkout, not branches anyway.
<fullermd> But later, I suddenly decide I want to use branches.  But I don't want to keep copying all the history.
<NET||abuse> yeh, that was a question that was on my mind throughout this discussion.
<fullermd> I can "bzr init-repo /project1" to create a repo there (empty; trunk still has its stuff internally)
<fullermd> Then I can "cd /project1/trunk ; bzr reconfigure --use-shared" to move the history into the shared repo, and switch trunk to using it (and throw away its internal copy)
<NET||abuse> hah, that's neat
<fullermd> (you can also go the other way around and "bzr reconfigure --standalone" to create an internal repo for the branch and copy the history out of the shared into it.  But you don't need to do that too often.)
<NET||abuse> i was thinking bzr co /projectco; then     bzr init-repo /project1; cd project1; bzr co /projectco ./trunk;
<fullermd> (it's also not QUITE exactly the mirror operation, for reasons we don't need to go into 'cuz you'll probably never use it)
<fullermd> That would probably not work so well.  Having a checkout of a checkout is icky.
<NET||abuse> hmm, yeh, maybe not.
<fullermd> It may not work at all.  It may sorta work, sometimes.  I don't actually know.
<fullermd> With straight branches it's easier, since they stand by themselves.
<NET||abuse> you'd have to redirect the parent / target repo of the second checkout back to the main repo.
<NET||abuse> or main trunk.
<fullermd> (before reconfigure grew those options, using 'branch' into and out of a repo to move things in/out was SOP)
<NET||abuse> aha, ok...
<NET||abuse> wow, brain melt..... in a good way though.
<fullermd> Now, if you already had the [heavy] checkout at /projectco, and didn't want to re-transfer all the data across the network, I'd do something like this:
<fullermd> bzr init-repo /project1 ; bzr branch /projectco /project1/tmp (just to 'prime' the repo) ; rm -rf /project1/tmp (cleanup) ; bzr co bzr+ssh://server/project1/trunk /project1/trunk"
<fullermd> Since that temporary 'branch' primed the repo with all the revisions, that last checkout didn't have to transfer much of anything; just check that we already had everything.
<NET||abuse> well you could do bzr init-repo project1; mv projectco ./project1/; cd project1; bzr reconfigure --use-shared;    no?
<NET||abuse> arrg, cd project/projectco;  sorry
<fullermd> That would also work, yep.
<NET||abuse> meh,, ,missed the 1 in project1 also...
<NET||abuse> cool though.
<fullermd> And if you decide "hey, that should be called 'trunk', not 'projectco'", you could also "cd /project1 ; mv projectco trunk"
<fullermd> (mv, not bzr mv, note)
<NET||abuse> ah, handy
<NET||abuse> yeh, of course.
<fullermd> As long as the branch stays _inside_ the repo, you can move it around to anything you want.
<NET||abuse> same as svn, using mv subcommand is only for moving items inside WT
<fullermd> If you mv it outside the repo, though, it'll start weeping the first time you do something that makes it look for a rev.
<NET||abuse> oh really.
<NET||abuse> that's interesting.
<fullermd> Yah.  'cuz it'll start looking for its repo, and...   umm....   where'd it go?
<fullermd> (that's one of the main cases you use reconfigure --standalone; to prepare for mv'ing it out of the repo)
<NET||abuse> so you can move it into the shared repo. reconfigure to --use-shared   and after that just mv ./projectco ./#trunk
<NET||abuse> etc etc.. as much as you like, and it's still tied the the shared repo.
<fullermd> Right.  A branch finds it shared repo implicitly, by looking at .., then ../../, then ../../../, etc.
<NET||abuse> ahh, that's very simplistic, but good i suppose.
<fullermd> So you could mv it to /project1/foo/bar/baz/quux/trunk if you wanted.
<NET||abuse> good tune. La Noy
<fullermd> So you can mv the branch around inside the repo, or even mv the repo around as a whole.  As long as the branches stay 'under' the repo, everything's cool.
<NET||abuse> arrg,, La NoyÃ©e
<NET||abuse> that's nice .. i like this shared repo idea..
<fullermd> A thing to note here, too, is that shared repos are entirely local.
<NET||abuse> really handy for tying branches of related work together.
<fullermd> Imagine you have the trunk and 2 feature branches in a shared repo on the central server.
<fullermd> /project1/trunk, /project1/feat1, /project1/feat2 (/project1 being a shared repo)
<fullermd> You could have co's of each of them in a shared repo at /myproject1 on your box.
<fullermd> Or you could have co's of them in /myproject1 _without_ a shared repo, each having its own copy of the history.
<NET||abuse> they are totally ignorant of eachothers shared repos'
<fullermd> Or have trunk at /myproject1, and feat1 and feat2 in a repo at /myproject1features.
<NET||abuse> gotcha,, yeh, that makes sense.
<fullermd> Right.  This is an aspect of "Repositories aren't semantic".  Everybody's setup can be different.
<NET||abuse> not bad, not bad.
<fullermd> The only thing you ever directly look at is a Branch.
<NET||abuse> yeh, i get that concept now..
<fullermd> (now, a downside of this is that we don't currently have something like "mirror-repo", or "pull-repo", to mirror/update the whole set of branches)
<OllieR> vila: many thanks for your time  - https://bugs.launchpad.net/bzr/+bug/432385
<ubottu> Launchpad bug 432385 in bzr "BZR export from a treeless repository outputs an empty file/dir" [Undecided,New]
<fullermd> Doesn't necessarily mean we _can't_, but it's more involved.  Some future work is looking in that direction.
<vila> OllieR: thanks for filing that bug !
<fullermd> But one reason we've gotten by this far without it is that you often don't need it, so...
<OllieR> vila: np
<NET||abuse>  fullermd: couldn't you just cp the shared repo,
 * fullermd of course uses 'we' to mean 'somebody competent, not me'   :p
<NET||abuse> you don't need a specific mirror command,
<fullermd> Sure.  You could tar it up and move it around, or rsync it, or whatever.
<NET||abuse> so that's a simple way to mirror the repo.
<fullermd> Gets more expensive than it has to be for updates though.
<fullermd> (and of course you can't mirror just a subset that way)
<NET||abuse> ok, but in situation where you only have http access to the repo, you may not have permissions to edit, so you may want to mirror the code base to fork the project or something.
<fullermd> Right.  You'd generally use 'branch' rather than 'checkout' for that.
<NET||abuse> especially if you still want to pull the downstream updates back from the master project.
<NET||abuse> yeh,
<NET||abuse> upstream, downstream... umm which ever way that indicates....
<fullermd> Then you could just "bzr branch http://where/ever upstream", and never do anything in that upstream branch except 'pull' updates, and use it as a source for 'merge'ing them into your codebase.
<NET||abuse> so still reaching for a real reason you'd need pull-repo
<fullermd> (never doing any merge's or push's into it, or committing, or etc)
<fullermd> It would be a lot more efficient for updating it than rsync and friends, for one.
<NET||abuse> well, you may want to pull-repo if say you have multiple branches for an app that's acorss say, different hardware architectures or something?
<fullermd> For another, you might want all the branches in that repo in a repo locally, but ALSO have your own local branches in that same repo (sharing the storage)
<fullermd> Yeah, there are a number of good reasons for it.  Just takes some planning in a VCS that's Branch-oriented like bzr.
<NET||abuse> ok, cool.
<NET||abuse> bleugh... my brain is full i think
<fullermd> My work here is done   :)
<NET||abuse> ;)
<NET||abuse> hehe.
<SamB_XP_> well, pull-repo would be pretty useful if you had, say, an svn-import that you wanted mirrored without actually using bzr-svn on the mirroring system ...
<NET||abuse> well thank you.. i owe you beer if ever we meet ;)
<fullermd> Yay, positive karma.  Now I can blow it on telling bad jokes to vila!
<NET||abuse> lol...
<NET||abuse> you coming to ireland and going to ossbarcamp tomorrow?
<SamB_XP_> it's kinda funny that bzr can pull every branch from a typical svn repository, but not from it's own native format ;-)
<fullermd> Oh, no.   I hate travelling.  I don't even like going across town.
<SamB_XP_> how big a town ?
<SamB_XP_> and is there any public transit ?
<fullermd> Bigger than my front lawn, so obviously way too big to bother crossing.
<SamB_XP_> wow you are hecka-lazy
<NET||abuse> haha, doh.
<fullermd> Pfft.  I'm a 'Merican.  We don't do public transit   :p
<NET||abuse> lol.....
<NET||abuse> i don't drive, i live on trams trains and buses
<fullermd> I go out every morning and crank my truck up, to let it idle for a few hours and make sure there's enough CO2 in the air.
<SamB_XP_> fullermd: that doesn't stop me!
<SamB_XP_> it depends on where you live, I guess
<NET||abuse> well, ireland, lotsa public transport here.
<SamB_XP_> so, like, what part of stupidville are you from ?
<fullermd> Yeah, if you live in a real City, it's much more of an option.
<NET||abuse> it's functional but badly managed..
<fullermd> You're happier not knowing   :p
<SamB_XP_> oh, the bible belt then ?
<fullermd> *I*'m happier not knowing...
<SamB_XP_> I'm a christian and I still think they're pretty crazy out there ...
<fullermd> Yeah, and I'm atheist, so imagine the fun I get.
<NET||abuse> do you live less than a 4 hours drive to a body of water
<fullermd> Luckily, I'm a grumpy misanthrope, so it doesn't get me down  :)
<fullermd> I live less than a 4 minute WALK from a reasonably sized body of water.
<NET||abuse> ahha, so you do leave your garden.
<fullermd> I didn't say I GO there.  Just that it's in spitting distance   :p
<SamB_XP_> fullermd: how do you know it's not in his garden?
<NET||abuse> is it an indoor swimming pool?
<fullermd> 33k acre reservoir.
<NET||abuse> ah hwell.
<SamB_XP_> hehehe
<SamB_XP_> piss in it ;-P
<NET||abuse> i like ireland, ther's no where that's more than an hour drive from a beach.
<fullermd> It's probably about 3 hours to the ocean.
<fullermd> (but, yuck.  Sand, and hot, and crappy bandwidth.  Who'd want that?)
<NET||abuse> and i'm only 20 minutes from the ocean here.. which is nice, and that's only cause i gotta drive along the coast to get away from the city ocean front.
<NET||abuse> yeh, not a fan of sand,, never said it was hot...
<NET||abuse> but i can get 3g on the beach.
<fullermd> Plenty of hot here.  I can ship some too you if you'd like...
<NET||abuse> hehe,
<fullermd> Round here, we have two seasons; summer, and January 15th.
<NET||abuse> will you take some of our rain?
<fullermd> My lawn could probably use it...   'course, then I'd have to mow it.
<NET||abuse> we have a saying in dublin.. when you look south, if you can;t see the wicklow mountains, it's raining... if you can see the mountains.. it's about to rain.
<spiv> fullermd: yes, totally server-side.  Read the NEWS entry ;)
<NET||abuse> fullermd, hmm, just thinking about how to push releases up to a web server now..
<NET||abuse> fullermd, i saw someone before mention a way to just do a push to an alias that is a branch on a web server, which has a hook of somesort that just pushes the updates straight out to a web directory.
<fullermd> Ah, now you're wandering off from the stuff I touch.  I don't use my VCS as a deployment mechanism.
<fullermd> There's a bzr-upload plugin that does some things to push up just the working files (no history).
<fullermd> If you have bzr on the server, you can make it a branch that you use 'update' to keep up to date with pushes, possibly semi-automated in various ways.
<fullermd> (you could setup a cron job to fire it every so often.  There's a push-and-update plugin which basically does a "ssh server bzr update" after each push.  Probably other choices...)
<OllieR> fullermd: "I don't use my VCS as a deployment mechanism." - what do you use out of interest?
<fullermd> install(1)
<siliconmeadow> I can't seem to find any books on Bazaar - are there any?
 * siliconmeadow notices a lot of drupalers here...
<vila> siliconmeadow: not yet but some are in the works AFAIK
<siliconmeadow> thank vila :-)
<siliconmeadow> ^thanks
<vila> good morning jam.sig ! :D
<jam> morning vila
<fullermd> Who?  I can't see him in my clone...
<james_w> bzr's gone crazy for me today
<vila> jam: sorry about that mail, I overreacted, that bug drove me a bit nuts to say the truth :)
<fullermd> It WHAT?!  It told me *I* was the only one!
<james_w> heh
<james_w> UnexpectedInventoryFormat: Invalid format version '5'
<james_w> anyone know what that could be?
<vila> make ?
<vila> I'm pretty sure we've seen that one recently
<james_w> I've done make
<vila> ubottu: UnexpectedInventoryFormat: Invalid format version '5'
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<james_w> I pulled across the API version change for the first time today
<james_w> so I'm now trying to remove the page of warnings every time I invoke bzr
<fullermd> loom?
<james_w> that's from trying to pull bzr-svn
<james_w> lp:~jelmer/bzr-svn/0.6/
 * james_w tries lp:bzr-svn instead
<james_w> same
<awilkins> ubottu: dance
<ubottu> Sorry, I don't know anything about dance
<vila> james_w: in a clean branch ?
<james_w> the other issue is that I can't update a checkout
<james_w> vila: no, pulling in to my existing branch
<james_w> a new branch works fine
<vila> Did jelmer upgrade bzr-svn to 2a ?
<vila> or did you upgrade your local branches to 2a ?
<james_w> I'm rich-root-pack locally
<james_w> the remote is
<james_w> Branch format: 	Branch format 7
<james_w> Repository format: 	Development repository format - rich roots, group compression and chk inventories
<vila> james_w: file a bug, I can't remember the details, sorry :-/
<vila> james_w: you can work with the new branch or are you blocked ?
<james_w> I've just deactivated the plugin
<james_w> I rarely need it, and I can always blow it away and pull
<vila> huh ? Yo mean it's a bzr-svn issue ?
<vila> huh ? You mean it's a bzr-svn issue ?
<awilkins> I think it's an issue with his branch of bzr-svn
<james_w> I deactivated bzr-svn so that I don't get the API version warning
<james_w> I was trying to pull to get rid of that, but deactivating it is as good right now
<vila> james_w: ok
<jam> vila: don't worry about the email. It isn't a great method to convey humor/sarcasm, so it was easy to misinterpret what I originally said.
<vila> jam: ok, but you were right, adding a test is needed :) Especially since I'm not sure neither of us is fully right about some bug details
<vila> concretely, you said the file name can end in .sig.gz, but the SigStore don't do that
<vila> and it goes both ways about conveying humor, I failed to explain what we did with fullermd to become confident we fixed it without breaking something else (granted, that was under the assumption that sigs were tested somewhere, which I'm less sure about now :-/)
<fullermd> I must say, I find it humerous that after all the work that's gone into dealing with the most insane sort of charset and unicode weirdnesses, I managed to utterly trash the test suite by use of a hostname consisting of 7-bit ASCII all-lower-case alphabetics.
<vila> jam: hmm, looking at the code right now, endswith is enough since it comes after a splitext that takes care of the optional final '.gz' so I think all is needed is a test, but if we don't have enough sig tests... it will be weak
<jam> vila: I'm ok with being a bit weak on weave formats .. :)
<vila> jam: LOL
<fullermd> If they were tested too well, people might start using them...
<vila> fullermd: that's karma for you ! When I met my gf 20 years ago, we argue about whether using accented letters in *comments* was a good idea
<vila> fullermd: the truth is we had troubles converting from Unix to DOS because some accented 'e' were transformed in CR along the way...
<fullermd> Those cross-platform relationships never work out...
<vila> fullermd: I quickly switch to rwiting my comments in american to get rid of the problem.... and never came back :)
<vila> never get rid of the gf though...
<fullermd> Well, obviously you HAVE to keep her now.  It would take too long to train yourself back into using the accents.
<fullermd> vila: Re revspecs: It doesn't.  The changes don't really make it any easier or harder to hack in the change...
<vila> Not easier ? I'm a bit surprised...
<vila> At least better localized no ?
<fullermd> Not really.  It always treated revnos directly in the main code path.
<fullermd> This would just be also checking for "r[numeric]" as well as "[numeric]", stripping and trying.
<vila> Yes, but your change should make it easier to address that bug no ?
<vila> Should be a one-liner there
<vila> (not counting tests of course :)
<fullermd> No, it would just be the same change in a different place, AFAICS.
<vila> ok
<vila> red-button-alarm: bug #432390
<ubottu> Launchpad bug 432390 in bzr "beta-ppa fails to build 2.0rc2" [Critical,Confirmed] https://launchpad.net/bugs/432390
<vila> james_w: does that have an influence on bringing 2.0 into karmic ? (I don't think so, but better checking)
<james_w> fixing now
<james_w> it's an error because some paths changed but the packaging didn't change to accomodate
<vila> james_w: sorry about that :-/ A whole week has passed >-/
<james_w> np
<james_w> uploaded
<bialix> james_w: hello
<bialix> james_w: I don't remember I've received your confirmation about uploading qbzr 0.14.2 to karmic, maybe I'm missing your mail?
<james_w> bialix: yeah, sorry, haven't got round to it yet
<james_w> I still plan to
<bialix> james_w: ok
<james_w> ah, I can't upload to bzr-beta-ppa
<james_w> vila: you are an admin of that team, would you add me?
<idnar> I'm converting a darcs repository to bzr using darcs-fast-export / bzr fast-import; the original repository is about 131MB, the import has been running for around 3.5 hours now and has so far produced a 27GB bzr repository
<idnar> can I expect that size to be reduced in some way once the import is complete?
<james_w> wow
<james_w> an increase like that suggests to me it's not a case of "more stuff that will be cleaned up at the end", but instead a bug in the conversion process
<vila> james_w: me ? Forst news :-) Which user do you want ? The regular one or the daily debs one ?
<bialix> anybody help? what is English word for append to the beginning? "prepend" seems wrong...
<james_w> vila: james-w please
<james_w> bialix: that is the correct word
<vila> james_w: done
<james_w> thanks
<awilkins> prefix also would work
<awilkins> Maybe
<idnar> that 27GB is almost entirely composed of a single file in .bzr/repository/upload
<bialix> james_w: strange... spellchecker is sutmbled
<idnar> I don't really know anything about the internal repository structure, so I'm not sure what's what
<james_w> idnar: that means everything is going in to one pack file
<james_w> which is rather odd I would say
<idnar> the conversion rate has been steadily going downwards throughout the conversion process, but that may be because it's reaching the limits of the physical memory on this box
 * bialix mutters: esr's jargon file has "prepend", ok, go on
<idnar> but it's nearly finished, so I guess I'll just let it finish and see whether the result is garbage or not
 * vila mutters to bialix, go on, prepend is ok ;)
<james_w> idnar: that's probably the best thing if it is nearly finished
<idnar> I previously tried this with an older version of darcs-fast-export, which took about 10 minutes to get halfway through the conversion before it bombed out with an exception
<vila> idnar: 'bzr info -v' as soon as it finish, then 'bzr check', and be ready to tell your story in a bug report :)
<idnar> so this is incredibly slow by comparison; I probably would have killed it a long while back if I'd been around to notice
 * vila . o 0 (Tell your tale ? Too obvious for native speakers ? )
<vila> idnar: this is abnormally slow but killing it now would be losing the opportunity to understand why it's slow
<idnar> I was using bzr-fastimport from bzr, but I didn't realise darcs-fast-export had been merged into that project, so I was using some older version of darcs-fast-export that I had lying around
<vila> idnar: that slowness itself is worth a bug, that's why I give you upfront the commands to use to put their results in the bug report :) Also, your .bzr.log file may contain useful hints about what happened so keep it handy
<idnar> *nod*
<idnar> I was just looking at .bzr.log, but it just has the same output I saw in the terminal where I was running it, which just consists of the progress reports
<rocky> is there anyway to tell bzr to forget a push location for a branch? (without using --remember to remember a new location)
<idnar> it claims to have "finished" now, but it's thrashing around doing something or other (might just be process termination, it's at around 80% of physical memory now)
<vila> rocky: short of editing branch.conf, no
<rocky> k
<dsuch> hmm would someone please direct me to any blog/mail discussion where emulating 'svn lock
<dsuch> ' has been discussed to death already?
<vila> dsuch: you mean a centralized lock in a distributed environment ?
<idnar> hmm, I suspect I'm going to run out of memory here shortly
<dsuch> yea
<dsuch> anything that resembles it, bonus points for not using a lightweight checkout
<dsuch> we have this 'awesome' tool at work and we really really need to serialize access to it
<vila> dsuch: no solution today, no precise pointer for the discussion, but Russel Winder was involved IIRC
<vila> or was it Nicholas Allen...
<dsuch> okay, will google for that names
<dsuch> thanks vila
<vila> dsuch: I think one the latest tricks proposed was to rename the file fileis-locked-by-dsuch and commit that
<dsuch> and to rename it back to the original name when done with changes?
<vila> gross of course, but there is no such thing as centralized locks in distributed environments...
<dsuch> yea I know
<dsuch> that's why I'm saying 'emulating'
<vila> On the other hand, if you believe in that, I have a bridge you may be interested in :)
<vila> dsuch: sure
<dsuch> a bridge?
<vila> A tower ?
<dsuch> a rook!
<vila> fullermd: is that a bridge or a tower ?
<james_w> oh, I haven't fixed it
<james_w> this is weird
<dsuch> vila: the trick won't work here though, the file in question is required by the tool and it needs to be foo, can't be dsuch-foo-copy and it's a proprietaru software we can't do much with
<dsuch> vila: what kind of bridge anyway?
<vila> dsuch: A tower, I can sell you the Eiffel tower if you're interested
<dsuch> ah sure
<dsuch> that sounds interesting
<vila> dsuch: "proprietaru software we can't do much with" hmm, any free software alternative instead ? :D
<Tak> is there a package deal with the arc de triomphe?
<vila> dsuch: seriously, you have binary files that can me modified in parallel ?
<dsuch> there is one, but it's been abandoned for some time
<vila> Tak: sure, some price
<dsuch> no, it's not binary but it produces incomprehensible XML, extremely hard to merge it
<dsuch> vila: I thought you were talking about some new alternative svn-to-bzr 'bridge' ;-)
<vila> dsuch: ouch, sorry :-)
<vila> dsuch: do you really need to put it under version control if you can't understand it then ?
<dsuch> I don't need to understand the underlying format, just the output it produces :)
<vila> let me rephrase, why do you need a lock ?
<dsuch> there are about 20-30 people possibly interested in modifying it, the tool chose to store all its data in XML,
<dsuch> and when people are applying changes in parallel it's quite to merge the changes,
<dsuch> quite *hard I mean
<vila> quite hard or impossible ? Still needed or refused now because it's too much work ?
<dsuch> besides, the very process of producing the output is under the control of one person (and it ought to be like that),
<dsuch> too much work
<vila> but other people still need to be able to read it right ?
<dsuch> we'd rather focus on the real stuff not on grokking the XML, it's a completely unneeded knowledge
<dsuch> yea
<vila> So your use case is a bit simpler...
<vila> but only a tiny bit
<dsuch> mhm?
<dsuch> you think so?
<vila> You should be able to hack around a solution with a commit hook and one master file replicated on a read-only file
<vila> Then the hook checks that only one people can modify the master and copy it to the read-only one, all other attempts to modify the read-only one should be refused
<vila> Still quite hackish since that means people modifying the "read-only" version will need to revert it before getting the new changes :-/
<dsuch> not to mention that it's currently way above what I know about bzr :)
<GaryvdM> Hmmm  selftest --coverage seems to only show the coverage of the first test run on windows.
<idnar> hrm, well that was exciting
<dsuch> you said I needed a commit hook, you mean a push hook, right?
<idnar> I nearly ran out of memory, but it managed to get far enough to explode with an exception
<idnar> guess I'll file that bug report now
<vila> idnar: too bad :-/
<dsuch> because I still would want to be able to hack on it and commit locally
<bialix> GaryvdM: hello
<idnar> oh, hmm, it deleted the data too, I guess
<idnar> so that doesn't help much
<vila> dsuch: push time is too late, you'll run into conflicts at merge time and will need to find a way to always revert to the "right" version (come to think of it, that may be easier: no code to write :)
<vila> dsuch: oooh, you want to commit it anyway... but then you don't want a lock !
<idnar> bleh
<vila> idnar: report it anyway !
<idnar> the exception traceback occurred in an error handling path, masking the real exception
<dsuch> vila: I'd like to commit to it /locally/ and then push it to the central place
<vila> idnar: I'm not up-to-date about fast-import, others may know better
<bialix> heh
<dsuch> vila: and to make sure no one has introduced any changes in the time I was working with it
<vila> dsuch: and you expect the lock to occurs how and when then ?
 * bialix trying one more time
<bialix> GaryvdM: hello
<GaryvdM> hi
<bialix> how's you?
<dsuch> vila: not saying it needs to be a lock, but right now, with SVN, I'm able to get the lock, work on it (no local commits unfortunately), then commit it to the repo
<bialix> GaryvdM: I've almost released 0.14.2
<bialix> rats
<vila> dsuch: If you're the one modifying it (and the 20-30 others are using it) AND you're the one managing the trunk THEN all you have to do is ensure that nobody else than you modifies it,
<dsuch> vila: right
<vila> OR if you realized someone modified it anyway, push your own version on top of theirs
 * bialix wonder what client Gary used
<vila> i.e. no lock but monitoring the changes :)
<jam> dsuch: note that fundamentally even svn locks aren't what you want
<dsuch> eh
<jam> because you don't find out that someone has the lock until you *commit* it.
<jam> which is too late
<dsuch> vila: and merge manually?
<dsuch> jam: not really, I know it when I try to get a lock
<jam> unless, I guess, people are disciplined enough to take the locks out first
<dsuch> yep
<jam> but in that case, there is some easy plugin-ish things that you could od
<vila> dsuch: you decide, you can refuse to merge and just keep your version and erased the OTHER's changes
<james_w> vila: I'm too stupid to figure out how to fix that build failure right now, and have to head out to meet someone
<james_w> I will try and fix it over the weekend or something
<vila> james_w: thanks a lot
<jam> dsuch: so *I* would hack together a "bzr lock-file" plugin that would write a file on the central target location
<jam> that says what files are currently locked
<jam> I'm happy to discuss the shape of something like that
<jam> for example, is this using a checkout (heavy or light)
<jam> a preferred submit branch
<jam> etc
<idnar> reported as bug #432586 if anyone is following along
<ubottu> Launchpad bug 432586 in bzr-fastimport "darcs -> bzr import extremely slow before failing" [Undecided,New] https://launchpad.net/bugs/432586
<dsuch> well I'll be happy to test it when you create it :)
<jam> the locations of the locks could be put somewhere hard-coded
<jam> or could be per project, etc
<james_w> idnar: did you pipe darcs-fast-export to a file, or directly in to bzr?
<dsuch> but I completely don't know anything about bzr internals, I took a peek at the code when it was at 0.0.0.8 I think :)
<jam> dsuch: can you give more information about how your work is laid out?
<jam> what branches people use, where things are stored, etc?
<dsuch> but now I can see it's somewhat larger
<dsuch> er, but we don't use bzr right now
<idnar> james_w: I piped it
<idnar> er
<idnar> james_w: I piped it in over stdin
<vila> idnar: now that you know that your PC didn't die...
<james_w> idnar: is this a public repository?
<vila> idnar: you should retry with the latest bzr and bzr-fast-import versions
<james_w> idnar: piping to a file and getting the size of that file could be interesting
<dsuch> jam: we're using SVN and we're evaluating the alternatives (a colleague is looking at git)
<james_w> if it's 300GB then that might indicate the problem is in the export
<idnar> james_w: I'm trying that now
<james_w> thanks
<jam> dsuch: so you don't actually have a layout yet
<bialix> garyvdm: hi again
<idnar> 3.3GB so far, but that's uncompressed
<garyvdm> Hi bialix
<dsuch> jam: no bzr layout, no
<bialix> how's you?
<jam> idnar: so it is expected that the fast-export => fast-import process is going to generate some large intermediate steps
<bialix> garyvdm: can we finish qbzr 0.14.2 this weekend?
<jam> idnar: you did 'fast-export > to_file.fi" first?
<bialix> garyvdm: don't disconnect please please please
<garyvdm> bialix: What needs to be done?
<jam> Is that your 27GB file?
<idnar> jam: no, the failed attempt was piping darcs-fast-export into bzr fast-import -
<jam> idnar: so first off, I don't recommend piping
<jam> I recommend redirecting to a file
<jam> and then loading from there
<idnar> the 27GB was a single pack file in the repository which got deleted along with everything else when it failed
<bialix> garyvdm: PPA
<garyvdm> bialix: ok
<idnar> I'm trying that now
<garyvdm> bialix: ubuntu karmic?
<jam> dsuch: so there are lots of potential issues
<jam> for example, how should locks be coordinated between branches?
<bialix> garyvdm: karmic, yes. james_w promised to help, but not yet
<jam> do you want anyone working on any branch to (cooperatively) block someone working on another branch?
<garyvdm> Ok
<jam> (equivalent in SVN is that you lock branches/*/file/foo trunk/file/foo, for example)
<bialix> james_w: can you coordinate with Gary?
<idnar> some brief mental gymnastics suggests that 27GB might not be unreasonable for the size of the uncompressed export file
<jam> or just always lock trunk/file/foo
<dsuch> jam: in my use case, they shouldn't, there's only one file (a directory, really) that needs to be locked upon starting the work
<dsuch> jam: and right now, it's always in trunk
<bialix> garyvdm: ok, so I'll build installer soon
<bialix> garyvdm: and will do announce after PPA
<jam> dsuch: but if you aren't using checkouts, then presumably you *want* people to be working in separate branches
<dsuch> mhm, I think I do
<garyvdm> bialix: I'll only be able to get to it on sunday.
<bialix> garyvdm: ok for me
<jam> dsuch: so if you take out a directory lock, does that lock all files underneath?
<dsuch> it does
<garyvdm> bialix: going to SFD tommorrow, and then to my Dads
<jam> dsuch: so if people are working on independent branches, then you want to be blocking *across* branches when they go to commit
<bialix> garyvdm: what is SFD
<garyvdm> It's my birthday tommorow :-)
<bialix> garyvdm: ?
<garyvdm> Software Freedom Day.
<dsuch> but we also learnt that *sometimes* we can get a lock on the master file only, sometimes it works
<bialix> garyvdm: congrat
<bialix> so, see ya later
<dsuch> jam: oh sure, if people are generally going to work in their own branches then I'd like the lock to be kept across them
<bialix> bya all
<dsuch> jam: which seems to be kind of impossible in general case
<bialix> .me means bye
<garyvdm> bialix: http://softwarefreedomday.org/teams/africa/SouthAfrica/Pretoria
<dsuch> jam: but hey, who am I to tell you what's possible :)
<bialix> garyvdm: looks cool
<idnar> hmm, I should probably attempt this on a faster system
<jam> dsuch: so basically you just configure a central location where the locks are stored
<dsuch> aha
<dsuch> I understand you're thinking aloud of some not yet written feature?
<jam> dsuch: well, being written as we chat :)
<dsuch> heh
<dsuch> want me to grab it from somewhere?
<jam> dsuch: given that it doesn't really exist as of yet, I'll let you know when I get somewhere
<jam> most likely I'll put it up as lp:~jameinel/+junk/file-locking
<jam> to eventually become lp:bzr-file-locking
<dsuch> heh that's what I meant :)
<jam> or something along those lines
<phinze> jam: back from canada? :)
<garyvdm> vila: When you said that NEWS entries must be sorted alphabetical, is that the actual text in the entry ?
<vila> garyvdm: yes
<garyvdm> thanks.
<jam> phinze: yep
<jam> garyvdm: yeah, it makes for really weird reading
<jam> for it makes reading really weird yeah,
<jam> :)
<jam> Odd that the sorted version is still rather readable
<garyvdm> jam: lol
<jam> garyvdm: but yeah, within any given section (like Bugs) we sort by the first words of the sentence
<jam> it isn't a great system, but it has reduced the amount of spurious conflicts (a little bit)
<garyvdm> bye all
<RenatoSilva> bzr+ssh is just ssh actually, right?
<awilkins> RenatoSilva: No, it speaks the HPSS protocol across the SSH to an instance of bzr at the other end
<awilkins> RenatoSilva: If you want "just ssh" you want sftp
<jam> dsuch: I'll probably be offline for some of the afternoon, but I'll let you know where I get to.
<jam> its an interesting problem that has been brought up before
<dsuch> sure, thanks anyway jam
<dsuch> it's not that we need to migrate right now
<jam> dsuch: sure, mostly you just brought up the idea
<jam> of course, there are *tons* of complications, so I'm trying to figure out how much to implement
<jam> for example, if I lock "dir/"
<jam> and you rename "dir/foo => otherdir/foo"
<jam> should "foo" stay locked?
<dsuch> remember that it doesn't need to solve all people's use cases
<jam> what about if I add "dir/bar", should that fall under the lock
<jam> etc
<RenatoSilva> awilkins: the SSH protocol is not related only to os shells, right?
<RenatoSilva> awilkins: so on the server I can put bzr and send bzr commands instead of shell commands, right?
<dsuch> jam: if it helps, 1) yes, it should stay locked in my case 2) adding a file when 'dir' is under the lock shouldn't be possible
<RenatoSilva> awilkins: is the HPSS a proprietary protocol of bzr?
<awilkins> RenatoSilva: Yes (not sure I got the acronym right either)
<RenatoSilva> awilkins: yes for which question ? :)
<awilkins> Yes, it's the bzr network protocol
<RenatoSilva> ah ok, thanks
<RenatoSilva> now I got why it is called bzr+ssh
<jam> dsuch: should it fail to 'add' or should it fail to take a lock on the dir?
<awilkins> RenatoSilva: you can do bzr:// on it's own, but it's got no security of it's own
<RenatoSilva> it's ssh, but not over the ssh port, which is for shell
<awilkins> RenatoSilva: Yes, it's over the ssh port
<RenatoSilva> 22? oh
<LarstiQ> RenatoSilva: ssh is the transport, bzr is on top of that
<awilkins> RenatoSilva: All ssh does is tunnel traffic to an instance of the shell at the remote end (bash, csh, whatever)
<LarstiQ> RenatoSilva: what it does is set up a ssh connection, start bzr on the other side, and then talk bzr across the ssh connection
<awilkins> bzr+ssh tunnels traffic to an instance of bzr
<RenatoSilva> awilkins: All ssh does is tunnel traffic to an instance of the shell at the remote end (bash, csh, whatever) ----> and in this case the "shell" is bzr
<awilkins> RenatoSilva: pretty much, yes. Part of the ssh protocol is you specify what you want to run, and if you don't, it uses the default shell configured for the remote user
<jam> dsuch: also, how do you want to handle the unlock process
<jam> how do we know if a given user has the right to unlock it?
<jam> Is it just on-your-honor?
<jam> Do we check the username first
<jam> and if that fails, allow them to 'break' the lock?
<jam> etc
<RenatoSilva> <LarstiQ> RenatoSilva: what it does is set up a ssh connection, start bzr on the other side, and then talk bzr across the ssh connection --> how about the mentioned HPSS? The way you say is like the talk are just bzr shell commands...
<jam> dsuch: and if I have 'foo/bar' locked, can you take a lock out on 'foo'?
<RenatoSilva> LarstiQ: sorry I think I misunderstood you
<dsuch> jam: you mean forcibly?
<jam> dsuch: so for example
<jam> you take out a write lock
<awilkins> RenatoSilva: It talks the server protocol ; the server is the remote instance of bzr. It's equivalent to running  `bzr serve --directory=/ --allow-writes`
<jam> then I should be able to see that
<jam> can I break your lock?
<jam> if I just do "unlock" does it do it automatically?
<dsuch> yes, you can
<jam> does it check the user?
<jam> or do you expect something stronger than that
<dsuch> currently it doesn't
<dsuch> we're a small team so if someone does it I can always get him on the phone and ask why she did that
<dsuch> eh, *her :)
<RenatoSilva> awilkins: ok thanks
<jam> dsuch: well, do you want logging of how locks have transitioned, then?
<dsuch> jam: everyone has equal rights here, so everyone can steal any lock
<jam> (see why this doesn't just exist :)
<dsuch> Yea, lots of questions.
<awilkins> In SVN, locks are more of a warning... you can ignore them (reset the write bit), and steal them
<RenatoSilva> thanks
<awilkins> They were pretty much an afterthought in the design too - I would guess because people who were used to Visual Sourcesafe and the like wanted them
<dsuch> jam: a log could be handy for answering the who-stole-my-lock kind of questions
<awilkins> SVN logs it
<awilkins> When you steal a lock you have the opportunity to provide an explanation
<dsuch> yea
<awilkins> AFAIK there are still some bugs about locks not being renamed along with their files in the repository
<awilkins> I had to write some admin scripts to purge dead locks
<jam> awilkins: files are never renamed, they are copied :)
<dsuch> what a great last words :)
<awilkins> The problem with locks is magnified by the DVCS model if you ask me
<awilkins> It's not so great in SVN ; but it works where you are working on the same branch and have files that are (eg) Visio diagrams, etc, binaries that don't merge well
<awilkins> But SVN was designed for edit / merge work cycles not lock / edit / commit like VSS
<dsuch> *nod* but then again, the case we were discussing involves a human gatekeeper who really needs to be sure he's using the latest version, not modified by anyone
<awilkins> dsuch: Which is difficult when there are branches that the server doesn't even know about
<dsuch> right
<awilkins> dsuch: I suppose you could have a "lock server" feature that keeps a map of lock : file-id
<dsuch> I think that's what jam is thinking of
<awilkins> I should refrain from joining in, my head is full of bursting/bucket tries, I need to work out how to splat them into a filesystem
<Naoki> Hi
<Naoki> Some Japanese Documents in here: lp:bzr-doc-ja
<phinze> level -JOINS -PARTS -QUITS
<idnar> bleh, hit 45GB on this export and ran out of space
 * idnar throws in a gzip
#bzr 2009-09-19
<meoblast001> hi
<meoblast001> i have 4 files that use 4 space indents and i want them to be 2 space indents.. would that be worth it in terms of VC efficiency?
<lifeless> meoblast001: do you mean 'will the vc same much space if you use 2 space indents'?
<lifeless> meoblast001: or 'how inefficient is the vc at storing a change from 4 space to 2 space indents
<meoblast001> i mean, is it worth it to make this consistent on these 4 files and lose the efficiency
<meoblast001> the sum of the 2 files is about 400 lines
<meoblast001> or, 4 files
<lifeless> worth it is up to you :)
<lifeless> its c=going to cost about 400 bytes
<meoblast001> 400 bytes? try 400 lines
<meoblast001> right?
<lifeless> 400 bytes, in 2a
<meoblast001> 2a?
<lifeless> the 2.0 default format
<lifeless> if you're not using it yet, thats fine, when you upgrade it will compress it then
<meoblast001> oh, so it only actually records changes byte for byte?
<lifeless> yes
<meoblast001> i use Ubuntu 9.04, which version do i use then?
<lifeless> bzr --version
<ScottK> 1.13
<meoblast001> Bazaar (bzr) 1.13.1
<meoblast001> does that mean i have to update now?
<meoblast001> if i want to get the new optimization
<SamB_XP> yeah ;-P
<meoblast001> so if i previously did something like this, it will still remain in it's unoptimized form?
<meoblast001> although my previous change was a rewrite of most of the source so it wouldn't really change
<meoblast001> this time it's mainly just removal of those spaces
<lifeless> when you do upgrade your repository, it will gain the benefits
<SamB_XP> meoblast001: well, if/when you convert your repository to 2a, which maybe you'll want to do after you upgrade to 2.x, you'll get the goods
<lifeless> there is no rush
<meoblast001> ah, how does that work technically?
<meoblast001> i sometimes don't believe things that sound too good to be true
<lifeless> 'bzr upgrade' converts your data from one disk format to another
<lifeless> we typically see repositories drop to 30% of their older size (once our gc kicks in and removes the rollback stuff we store in obsolete packs)
<meoblast001> "disk format"?
<SamB_XP> bzr supports a dizzying array of disk formats for repositories
<ScottK> lifeless: Is there a significant speed difference between the 1.19 format and 2.0?
<lifeless> ScottK: huge
<lifeless> ScottK: there isn't a 1.19 format though, perhaps you mean 1.9?
<ScottK> I mean the one immediately previous.
<ScottK> Let me check
<lifeless> in repo terms thats 1.9
<SamB_XP> lifeless: you didn't up the default in 1.19 ?
<lifeless> 1.14 as a label was actually a working tree change
<ScottK> 1.14 actually
<meoblast001> so how does it convert it from a format of detecting changes by lines to a format of changes by bytes?
<lifeless> SamB_XP: we haven't done a 1.19 release :P
<ScottK> Right, I mis-remembered.
<lifeless> meoblast001: reads ins, writes out :P
<lifeless> meoblast001: I'm not really sure what you're asking.
<ScottK> lifeless: OK, so from 1.14, how huge?
<meoblast001> well, if revisions 1 - 90 were made with 1.x, how would you convert those to 2.x
<lifeless> ScottK: depends on what you're doing. Small trees and short histories the difference is swamped by startup time
<meoblast001> they aren't the same format of revision logs
<lifeless> meoblast001: 'bzr upgrade'
<lifeless> ScottK: large trees, 'bzr commit' is something like 1/5 the duration; log -v is even more significantly improved.
<meoblast001> so it magically figures out "oh, this whole line didn't need changed, only these 3 bytes needed to be"
<ScottK> lifeless: bzr stat on the project I'm thinking of is currently taking 8 seconds with bzr.
<lifeless> meoblast001: nothing magic about it, it converts the data
<lifeless> ScottK: bzr st is entirely working tree; so its not going to change. However 8 seconds is about 8 times longer than stat on openoffice for me.
<ScottK> Not sure if that qualifies as large, medium, or small.
<ScottK> Hmmm.
<ScottK> Interesting.
<lifeless> ScottK: so there's a good chance something is wrong like:
<ScottK> Thanks.
<lifeless>  - missing C extensions
<ScottK> OK.
<lifeless>  - uncompiled/stale .pyc files causing just-in-time compilation
<ScottK> Could the fact that it was imported from Git matter?
<meoblast001> lifeless: but it still does exactly what i said in that quote, except in Python code?
<lifeless> meoblast001: not really, it doesn't look at the old /changes/ at all.
<ScottK> lifeless: We're operating from Ubuntu packages, so is there more was can do to make it faster?
<lifeless> meoblast001: bzr doesn't model things by deltas, rather by the full content.
<meoblast001> uh oh
<meoblast001> bzr: WARNING: bzrlib version doesn't match the bzr program.
<ScottK> Our resident git fanatic is still all over speed.
<meoblast001> lifeless: what do you mean by deltas?
<lifeless> ScottK: the packages should have the C extensions; I have seen python-* helpers blow up.
<lifeless> meoblast001: don't worry about it, we're clearly not connecting :)
<ScottK> OK.  Is there any docs on how to check into this?
<lifeless> meoblast001: if you're interested in the exact details of the storage delta algorithm, have a look at group_compress in the bzr source for 2.0
<meoblast001> but basically old revisions will be updated perfectly up to the new format?
<lifeless> meoblast001: yes
<meoblast001> ok :)
<ScottK> Oops.  Noticed the time.  Need to run.
<lifeless> ScottK: strace 'bzr st' on a empty tree
<ScottK> OK
<lifeless> bzr init; bzr st
<ScottK> Thanks
<lifeless> that will tell you the system minimum time to st
<lifeless> ask a question on LP's answers thing, or on the list
<lifeless> or back here, when you aren't running
<meoblast001> anyways, i broke my bzr install
<meoblast001> bzr: WARNING: bzrlib version doesn't match the bzr program. < that's the warning i get, followed by a crash
<lifeless> meoblast001: what did you do?
<meoblast001> make (did that on accident)
<meoblast001> then i did sudo python setup.py install
<lifeless> so, you've probably got two copies of 'bzr' on your path
<SamB_XP> meoblast001: did you wait for it to *finish*?
<meoblast001> yup
<lifeless> and the first one on your path doesn't match the first bzrlib on your PYTHONPATH
<meoblast001> PYTHONPATH is an environment variable?
<SamB_XP> yeah
<lifeless> its like PATH
<lifeless> when PYTHONPATH is empty it has a default
<meoblast001> i echo'd it, aparently i don't have one
<meoblast001> ok
<lifeless> you can see the effectice PYTHONPATH by doing
<lifeless> python -c 'import sys; print sys.path'
<lifeless> meoblast001: you should read the upgrade guide though
<meoblast001> lifeless: what should that say?
<SamB_XP> meoblast001: if he knew what it should say, he could have told you what to set PYTHONPATH to ;-P
<meoblast001> ['', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages/Numeric', '/usr/lib/python2.6/dist-packages/PIL', '/usr/lib/python2.6/dist-packages/gst-0.10', '/var/lib/python-support/python2.6', '/usr/lib/python2.6/dist-packages/gtk-2.0', '/var/lib/python-support/p
<meoblast001> ython2.6/gtk-2.0', '/usr/local/lib/python2.6/dist-packages']
<meoblast001> oops
<meoblast001> i expected that to be 1 line
<meoblast001> and not so, well, long
<meoblast001> everything looks shorter in the terminal
<meoblast001> lifeless: i just reinstalled again
<zsquareplusc> i have a remote repository with several branches and "bzr branches" lists all of them. can i also pull all of them at once? "pull" does not seem to support that
<meoblast001> am i supposed to install bzrlib seperately?
<bob2> meoblast001: no
<bob2> zsquareplusc: multi-pull plugin, not sure if it is maintained anymore
<meoblast001> is the release candidate known to be broken?
<bob2> oh, sorry, ignore me
<meoblast001> ?
<meoblast001> i honestly don't think it's installing bzrlib
<lifeless> meoblast001: python -c 'import bzrlib; print bzrlib.__path__'
<meoblast001> ['bzrlib']
<meoblast001> lifeless: is that supposed to be an absolute directory?
<meoblast001> lifeless: should i just install the debs?
<meoblast001> although i'll never really get an understanding of what installing this from source is like if i do that
<lifeless> meoblast001: that means its in your local directory
<lifeless> cd somewhere else
<meoblast001> lifeless: ['/usr/lib/python2.6/dist-packages/bzrlib']
<lifeless> thats the packaged bzr
<lifeless> which is your 1.13 or whatever version
<lifeless> you might prefer the PPA rather than installing from source
<meoblast001> should i remove the bzr package?
<lifeless> anyhow, must go, back later
<meoblast001> ok, ttyl
<zsquareplusc> bob2: hm ok. its multi-pull contained in bzrtools, when i run it, it just lists *local* file URLs and tells me that these are no branches, even though i specified a remote repo
<meoblast001> got it working
<zsquareplusc> i wonder from where it takes that local paths, i want to do a fresh download and i'm in an empty directory
<meoblast001> oh no
<meoblast001> http://codepad.org/MIoiOxGQ
<meoblast001> if i would have known upgrading to 2.0 would cause tons of problems, i wouldn't have done it
<meoblast001> nvm, i'm an idiot
<Colonel-Rosa> morning
<meoblast001> good norning
<meoblast001> morning*
<Colonel-Rosa> does bazaar have a feature where it can work with multiple push locations, eg push production, push staging
<meoblast001> you can push to 2 different locations if that's what you mean
<Colonel-Rosa> right, but bazaar would only remember 1 at a time?
<Colonel-Rosa> So I would have to keep typing in the other location
<meoblast001> i'm not sure
<Colonel-Rosa> alright, thanks
<lifeless> Colonel-Rosa: you can create location bookmarks I believe, with the bookmark plugin
<Colonel-Rosa> lifeless, I will check it out
<Colonel-Rosa> Can not find any documentation for it though
<vila> lifeless: lots of attempts to escape test isolation on OSX failures=84, errors=167 for tiger, failures=73, errors=167 for leopard, probably a single cause having to do with /tmp access rights though
<vila> vila: pff, not even, it's the infamous /tmp is really /private/tmp on OSX...
<aboSamoor> I am searching any resource to understand bzr split, any idea
<dsuch> not exactly bzr-specific question but what have you guys used to be able to tab-complete the commands?
<dsuch> I'd like to use something like that in my own Python application.
<dsuch> Or is it something specific to Bash?
<Kamping_Kaiser> if i understand you correctly, its a bash thing.
<Kamping_Kaiser> look in /etc/bash_completion.d/ , you'll probably see a bzr script
<dsuch> oh right, thanks Kamping_Kaiser
<aboSamoor> is there anything wrong with this check http://paste.ubuntu.com/274091/ ?
<dsuch> aboSamoor: sorry, can't help you, you'll need to wait a bit more
<aboSamoor> dsuch: I am trying to learn how to use bzr split which I don't know how it can help me to answer my Q https://answers.launchpad.net/bzr/+question/83031
<dsuch> aboSamoor: not really
<aboSamoor> dsuch: no problem :)
<dsuch> you'll just need to wait for someone more knowledgeable to join in
<aboSamoor> ok, any idea which is the latest format ? is it 2a ?
<dsuch> I think it is.
<aboSamoor> does upgrading branch locally upgrade the format on the launchpad repository ?
<dsuch> aboSamoor: I don't know but I would've created a test repo in a sandbox to test it out
<dsuch> in fact, I'm interested in knowing it too :)
<dsuch> aboSamoor: so I would appreciate it if you could tell me if it did
<aboSamoor> dsuch: it is giving me errors
<aboSamoor> so I will rollback then I will try to make a new branch and push it
<dsuch> pastebin it somewhere and perhaps someone will know why it's giving you errors
<aboSamoor> the error while trying to push the new format to launchpad
<aboSamoor> http://paste.ubuntu.com/274143/
<davidstrauss> aboSamoor: Upgrade the remote repo first
<davidstrauss> aboSamoor: bzr upgrade --default-rich-root bzr+ssh://rmyeid@bazaar.launchpad.net/~rmyeid/%2Bjunk/code/
<aboSamoor> davidstrauss: I am usign 1.18 because 2.0rc1 gave me errors and I am using 2a format
<davidstrauss> aboSamoor: You shouldn't be using 2a for production use yet.
<aboSamoor> davidstrauss: I asked this question https://answers.launchpad.net/bzr/+question/83031. and the answer was to use split.
<aboSamoor> split needs rich root format, so I thought the best to upgrade to the future format so I won't do it again
<davidstrauss> aboSamoor: A split branch has a rich root
<davidstrauss> aboSamoor: you shouldn't upgrade to unstable formats
<aboSamoor> davidstrauss: I see. can you please take a look at the question, so I am sure that I am in the correct path
<davidstrauss> aboSamoor: I already said you should be using split.
<aboSamoor> davidstrauss: I searched for explanation how split is working and how to use. My first VCS is bzr and I am not sure of the technical terms used
<aboSamoor> but I did not find anything other than bzr help split
<davidstrauss> aboSamoor: Split takes the current directory in the current branch and converts it into its own branch
<aboSamoor> inside the same directory ? should I move outside the directory and push as new branch ?
<davidstrauss> aboSamoor: right after running split in a directory, you can stay in that directory and push it as a new branch
<fullermd> You should note though that split doesn't rewrite any history, so you're still carrying around the whole thing.
<davidstrauss> fullermd: from before the split, yes
<aboSamoor> davidstrauss: ok, I will do the following. 1-bzr check , 2-bzr reconcile 3-bze upgrade [not sure now what to use !], 4-bzr split dir1 5- cd dir1 6- bzr push
<davidstrauss> aboSamoor: bzr upgrade --default-rich-root
<davidstrauss> aboSamoor: Otherwise looks good
<davidstrauss> aboSamoor: You can skip the reconcile if check doesn't find anything
<aboSamoor> davidstrauss: I forgot to mention to use bzr upgrade --default-rich-root remote-repo before everything
<davidstrauss> aboSamoor: Indeed
<davidstrauss> aboSamoor: You could also pick --1.14-rich-root if you'd like the latest stable rich-root format.
<davidstrauss> aboSamoor: make sense?
<aboSamoor> now, I understand the big picture. I applied the default-rich root for the remote repo .  Waiting, it takes long time.
<davidstrauss> aboSamoor: Yes, it takes quite a while
<aboSamoor> davidstrauss: I reported bug 433039 while trying to use bzr 2.0rc1
<ubottu> Launchpad bug 433039 in bzr "An inconsistent delta was supplied during upgrade" [Undecided,New] https://launchpad.net/bugs/433039
<davidstrauss> aboSamoor: Don't file those against the Ubuntu package. File them against the bzr project.
<aboSamoor> davidstrauss: done, but don't know how to remove the ubuntu package from the "Affects" column
<davidstrauss> aboSamoor: They'll have to
<aboSamoor> davidstrauss: :-D, making mess all  the time
<davidstrauss> aboSamoor: This was probably the bug you ran into: https://bugs.launchpad.net/bzr/+bug/422849
<ubottu> Launchpad bug 422849 in bzr/2.0 "Incorrect conversions in 2.0rc1 and bzr.dev" [Critical,Fix released]
<davidstrauss> aboSamoor: And I've marked yours as a duplicate
<aboSamoor> davidstrauss: it was hard for me to figure that out, but the fix was released and I still have it !
<davidstrauss> aboSamoor: but you were running rc1
<aboSamoor> davidstrauss: yeah, it is released in RC2
<aboSamoor> davidstrauss:  which I could not grab because of the build errors
<aboSamoor> davidstrauss: by the way, this upgrade process is not friendly, no sign what is going on ! still blinking cursor :(
<davidstrauss> aboSamoor: there should be a progress bar
<aboSamoor> davidstrauss: http://paste.ubuntu.com/274159/
<davidstrauss> aboSamoor: It doesn't give progress for making the backup
<aboSamoor> davidstrauss: it was giving when I make the upgrade locally, but with the remote one no progress bar
<davidstrauss> aboSamoor: that's because it's still copying the backup
<fullermd> LP really needs an upgrade widget.  Doing it remotely is pure pain.
<fullermd> It's probably much faster to dump the current branch there and push a new one fresh in the new format.
<aboSamoor> fullermd: I don't think it is a good idea to cancel the process
<aboSamoor> I got this message before the progress bar
<aboSamoor> !!! [Hook] hook(): title not found
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<davidstrauss> aboSamoor: What's the full output?
<aboSamoor> davidstrauss: http://paste.ubuntu.com/274169/
<davidstrauss> aboSamoor: I'd ignore that. It didn't cause a backtrace, so it was handled.
<aboSamoor> davidstrauss: after updating the remote repo. bzr check operation gave me this output http://paste.ubuntu.com/274179/
<davidstrauss> aboSamoor: try running reconcile on it
<davidstrauss> aboSamoor: wait
<davidstrauss> Standalone tree (format: pack-0.92)
<davidstrauss> aboSamoor: That looks un-upgraded
<aboSamoor> davidstrauss: seems ok
<aboSamoor> I upgraded only the remote repo only
<davidstrauss> aboSamoor: did that succeed?
<aboSamoor> I did not upgrade the local one
<aboSamoor> davidstrauss: http://paste.ubuntu.com/274184/
<davidstrauss> aboSamoor: OK. Does check succeed now?
<aboSamoor> davidstrauss: nothing changed after the reconcile
<aboSamoor> the check operation still gives the same output
<davidstrauss> aboSamoor: can you just get a fresh branch from the remote (upgraded) branch?
<aboSamoor> yeah, if I understand that I should branch the current repo
<davidstrauss> aboSamoor: yeah
<davidstrauss> aboSamoor: easier to do that than upgrade both
<aboSamoor> davidstrauss: I did the branching, bzr info gives me Standalone tree (format: rich-root-pack)
<davidstrauss> aboSamoor: sounds right
<aboSamoor> davidstrauss: I will delete the old branch from my desktop, and I will start to split the folders
<davidstrauss> k
<flvr8> hello all... what's the "bzr way" to move a directory between two (unrelated) branches but maintain revision control of that folder? [the branches are projects; the folder is a module; the module is "graduating" to a more general project]\
<davidstrauss> flvr8: split, mv (not bzr mv), and then join
<davidstrauss> flvr8: But upgrade your branch first: bzr upgrade --default-rich-root
<flvr8> so...    cd Project1 && bzr split mymodule   //    bzr mv mymodule bzr+ssh://somewhere/Project2/trunk     //     cd ../Project2 && bzr update    //    bzr join mymodule    ?
<davidstrauss> flvr8: do not bzr mv. just mv
<flvr8> oh
<flvr8> ok
<flvr8> thanks
<davidstrauss> flvr8: and you need to do the mv and join locally
<flvr8> is there an parallel operation for individual files?
<davidstrauss> flvr8: other than moving a file into a directory of its own and doing a split+join, i don't know of a way to take a file's history from one branch to another
<flvr8> k
<davidstrauss> flvr8: make sure you read all the split+join docs first. what you're doing is quite advanced
<flvr8> will do, thanks
<aboSamoor> davidstrauss: everything works fine, thanks very much :)
<davidstrauss> aboSamoor: :-D
<flvr8> davidstrauss: it seems to be getting stuck doing "inserting stream" after doing the above and then add/commit... it's uploaded 300MBs (of something) to the server so far (the module is fairly small); i do not see a similar growth in disk space on the server
<davidstrauss> flvr8: Commits are streamed to memory before being committed to disk, AFAIK.
<davidstrauss> flvr8: But I have to go. I'll be back online later this weekend. Not sure when. Consider posting your question to http://answers.launchpad.net/bzr
<flvr8> ok, thanks
<vila> flvr8: just passing around, no time to double check, but keep in mind that join/split still keep the while history (or you wouldn't be able to merge from before split otherwise) so that may explain the volumes you see
<flvr8> ah ok
<SamB_XP_> hmm, I really like the repoalias plugin ...
<blueyed> Are there things planned to make conflict resolving better? BeyondCompare can resolve a lot more conflicts then bzr. Maybe just because of content inspection? (it handles files in different charsets, which bzr does not, ie a file gets converted to another charset in the deriving branch).
<james_w> blueyed: that would be good
<james_w> blueyed: but check the extmerge plugin
<james_w> you can use an external tool, e.g. BeyondCompare to resolve conflicts
<blueyed> oh well.. I have a bc-resolve-conflict(s) shell script already. I'll check it out.
<blueyed> james_w: should I file a wishlist bug about encoding ambivalence in comparisons? Might you want to just file it (you now more of the inners)? (Link: https://bugs.launchpad.net/bzr/+filebug ;))
<blueyed> extmerge is nice, should get added to the core.. :)
<blueyed> btw: my script asks about resolving the conflict, when coming back.. I'll forward that as an idea
<james_w> please file bugs for anything you think could be improved
<james_w> you're in a better place to file than me as you know what you want to happen
<Colonel-Rosa> lifeless, thank you for the bzr-bookmarks recommendation yesterday, was what I needed.
<Colonel-Rosa> ta
<RenatoSilva> Is it possible to directly push a merge directive to launchpad?
<RenatoSilva> I mean, instead of pulling from it, then pushing the branch, you'd push the patch, and then pull the changes
<lifeless> vila: if they need protecting, they aren't innocent ;)
<vila> lifeless: ok, that was you and me :-D
<lifeless> vila: and jam and poolie that reviewed ;P
<vila> lifeless: ow, that's rude :)
<vila> lifeless: by the way, even if t was for a wrong reason, you trapped ~130 tests that were trying to escape isolation, not so bad...
<lifeless> vila: they were?
<vila> that's what make them failed yes
<lifeless> cool
<lifeless> uhm
<lifeless> I excluded /tmp because ETOOHARD
<vila> but you caught TESTROOT, based on tmp
<vila> or was it test_dir ?
<vila> babune has the logs if you're interested anyway
<lifeless> vila: maybe tomorrow; can you link the build in the bug?
<lifeless> vila: oh maybe I misremember stuff
<vila> lifeless: yup, I wanted to add some info there if only for historical value, I'll do that right now
<lifeless> vila: anyhow, its good that the things that have failed are legitimate escape attempts.
<lifeless> vila: I thought by the way you described it that it was an isolation-checking bug
<vila> lifeless: yes, they *look* like legitimate attempts but it's just an aliasing problem (/private/tmp is not inside /tmp, but in fact they are the same)
<lifeless> urgle
<lifeless> so we have to permit /private/tmp when we see /tmp ?
<lifeless> because realpath is /private/tmp ?
<wgrant> bzr-beta-ppa just tried to give me 2.0rc1 (karmic i386). That seems like a really bad idea.
<vila> lifeless: no, by using realpath early, we just have to permit /private/tmp and be done with the problem
<lifeless> wgrant: its a terrible idea
<vila> lifeless, wgrant : bug #432390
<ubottu> Launchpad bug 432390 in bzr "beta-ppa fails to build 2.0rc2" [Critical,Confirmed] https://launchpad.net/bugs/432390
<wgrant> vila, lifeless: Somebody might want to delete 2.0rc1 from it?
<wgrant> I think nothing is better than 2.0rc1.
#bzr 2009-09-20
<lifeless> done
<wgrant> lifeless: Thanks.
<lifeless> I like packaging branches :)
<lifeless> just need to get some tuits and fix the namespace issues
<lifeless> fullermd: \o/ freebsd just got libtool 2 :)
<meoblast001> if i have a few classes in an index that i have to indent 2 spaces, in 1.x this would be a rather large change, but with 2.x that would be very trivial, correct?
<lifeless> meoblast001: just do the change
<meoblast001> ok, i tend to freak out about things
<meoblast001> you know, going concern
<SamB_XP_> I'd be more worried about what it would do to annotate
<meoblast001> annotate?
<SamB_XP_> the output from annotate
<SamB_XP_> you know, as in "bzr annotate"?
<meoblast001> haven't used that feature yet
<lifeless> SamB_XP_: there will be an ignore whitespace flag at some point
<meoblast001> one of the developers on my project rewrote a lot of it about a month ago, i tried to go through it and fix the formatting, but every now and then i pick up on things i missed
<lifeless> I would just do it
<SamB_XP_> maybe you should get some automated nitpickers
<lifeless> bzr exists to support you:)
<meoblast001> automated nitpickers?
<SamB_XP_> but yeah, just do it, as long as you aren't actually substantial changes in that commit
<SamB_XP_> where by substantial changes, I mean changes to the substance of the code
<meoblast001> yeah
<meoblast001> thanks for the info
<idnar> what's wrong with rc1?
<meoblast001> i know in this very project i used to have ZIPs in it
<SamB_XP_> and by automated nitpickers, I mean tools that check your code style somewhat
<meoblast001> once i figured out those aren't good with version control, i extracted them all and removed the ZIP files
<SamB_XP_> well, it might be fairly reasonable if you didn't make the zp and don't expect anything in the zip to change ever ;-)
<SamB_XP_> s/zp/zip/
<meoblast001> well, the thing was that i was unsure
<meoblast001> it didn't change much, but i wasn't sure if it would in the future
<meoblast001> and if i still had it, yes, it would have changed
<meoblast001> our file format specification changed, and the contents of the files in the ZIP would have needed to be changed
<SamB_XP_> yeah
<meoblast001> what irks me is that the ZIP file is actually in there forever, even if it's not in the tree
<lifeless> idnar: brown paper bag bug
<lifeless> idnar: incorrect conversion of data; do not use.
<lifeless> idnar: it will usually completely fail to convert data, but if it doesn't fail its probably done the wrong thing
<meoblast001> and just in case this question sounds crazy, i asked the MyBB developers what happens when i hit 4294967296 posts
<SamB_XP_> lifeless: what does "brown paper bag bug" mean?
<SamB_XP_> meoblast001: what's MyBB?
<lifeless> SamB_XP_: very bad, shouldn't have released, 'oops', 'bah', etc
<meoblast001> SamB_XP_: a forum software
<SamB_XP_> lifeless: well, I was wondering why those words mean that also ;-)
<SamB_XP_> what does that have to do with brown paper bags?
<idnar> lifeless: ah, nasty
<lifeless> SamB_XP_: http://www.catb.org/jargon/html/B/brown-paper-bag-bug.html
<lifeless> idnar: yup; we pulled tarballs etc the day after releasing it or so
<SamB_XP_> lifeless: oh!
<SamB_XP_> lifeless: you don't look like you're wearing a brown paper bag!
<lifeless> SamB_XP_: it was a few weeks back :P
<SamB_XP_> lifeless: ah
<SamB_XP_> well, I don't remember seeing you with one back then, either
<lifeless> jelmer: around?
<fullermd> lifeless: A while back, actually...   it was a week or two after we talked about it.
<lifeless> fullermd: my bug just got closed
<fullermd> Ah.  I thought about checking on that after I saw the commit go through, but laziness won.
<Naoki> I changed TortoiseBZR's shell extension code.
<Naoki> Could anyone kick buildbot for windows installer?
<meoblast001> lifeless: you still here?
<matthewlmcclure> how do you set breakpoints in plugin code?
<matthewlmcclure> pdb tells me the file is not on sys.path when i try
<lifeless> breakpoint bzr itself I guess and add the breakpoint after the plugin is loaded?
<matthewlmcclure> thanks, lifeless.  it seems to work if i use the full path to the plugin source file as the argument to `b`
<AfC> So... um, I just googled "bzr ppa" and came up with https://launchpad.net/~bzr/+archive/ppa ... at which there is no bzr 2.0rc2.
<AfC> What conceptual tidbit am I missing?
<AfC> (or should I just be using the 1.18 in karmic?)
<lifeless> its in the beta ppa
<lifeless> http://bazaar-vcs.org/Download
<AfC> lifeless: er, ok. I see.
<AfC> Hm. I guess I thought that's what the "normal" ppa was for.
<AfC> so what's the difference between {what is in karmic now, what is in ppa, and what is in beta-ppa}?
<AfC> [and, when should I stop using beta-ppa for ppa for karmic]?
<lifeless> normal ppa has releases
<lifeless> beta ppa has betas
<lifeless> whats in karmic is what the debian/ubuntu packaging team select and put in there
<AfC> lifeless: ah
<AfC> right
<lifeless> what should you use is : if you want stable releases, use your distro and optionally our ppa
<lifeless> if you want newer-than your distro, use the ppa
<AfC> lifeless: so bzr ppa will have 2.0 in it for the next year or so, and bzr beta-ppa will have 2.odd.x in it?
<lifeless> if you want to help us by beta testing, or want a beta for timely access to some feature, use the beta ppa
<AfC> lifeless: ok, so given that I'm not a usual PEBKAC here, what should I be using?
<lifeless> Its not clear what will happen with 2.1b* and the ppas; Some of our users may want them to propogate to the normal ppa:- expect list traffic on it ~ 2.1b1's release :)
<AfC> yeah
<AfC> anyway, I was using 2.0rc1, so I presume I should act to get that [back] on board
<lifeless> I think you'd be fine with the beta ppa; it has a few days of roughness once a month or so
<lifeless> you definitely want to get rc2, given rc1's brown paper bag status
<AfC> but I'm wondering if I should revert to normal ppa Real Soon Nowâ¢ :)
<AfC> lifeless: yeah, but it's what the distro I had had shipped until they found out about that.
<AfC> anyway
<lifeless> so as I say, I think the beta ppa would be generally fine for you
<AfC> ok
<lifeless> its not that rough a ride :)
<AfC> lifeless: I assume that once it's out
<AfC> lifeless: I can be running 2.0 or > 2.0 on the server an not screw over 2.0 stable users?
<AfC> [that seems to be a format question, not a software version one,  now that I think of it]
<AfC> lifeless: [ie, I have to balance me wanting to be close as possible to the code you're working on to actually see fixes & features
<AfC> against
<AfC> lifeless: hosting public branches of certain projects]
<lifeless> our servers are pretty robust
<lifeless> you can upgrade the server, or stick to 2.0 indefinitely
<lifeless> in terms of formats, yes, when you upgrade, you force other users to meet that minimum version
<AfC> sure
<AfC> I'm going to do that shortly. There aren't _that_ many of them; once Gentoo ~ and Ubuntu K support 2a [or whatever] I'll upgrade the repos.
 * AfC wishes keyserver.ubuntu.com would answer
<AfC> oh, that's not actually required.
<AfC> lifeless: Robert, does one still have to do that "run Python program once as root" thing to get the .pyc files built?
<AfC> lifeless: [c.f. Hobart, me on loaner laptop, you doing bzr timing tests to find out that was my bug]
<lifeless> AfC: you should not have had to do that then; something had gone wrong.
<lifeless> AfC: if bzr is slow, and strace shows errors openning the pyc files for write, then you have the symptoms again
<AfC> lifeless: no, it's not slow now
<AfC> lifeless: [not that I've done much]
<AfC> lifeless: I was just wondering if it was a standard known thing everyone had to do
<AfC> thanks
<maxb> Is there a terse form for reverse-merging / backing out a single revision, or do I want merge -r N..N-1 ?
<lifeless> you want that
<lifeless> unless you want uncommit
<maxb> Maybe bzr should borrow -c -revno from svn :-)
<lifeless> we have it
<lifeless> it means N-1..N
<maxb> Note the minus sign before revno
<fullermd> Nono, see.  MINUS c means N-1..N, so for N..N-1 you obviously want PLUS c   8-}
<lifeless> maxb: bzr merge -c 5 will merge 4..5
<lifeless> maxb: bzr merge -c -5 will merge -6..-5
<maxb> oh.
<maxb> gah, right
<NETabuse> hmm, got an error just now trying to clean up my bzrrepo
<NETabuse> here's the output http://www.pastebin.org/18987
<NETabuse> and now every command i use throws something like it.
<NETabuse> http://www.pastebin.org/18988
<spiv> NETabuse: hmm, that's bad.
<NETabuse> arrg,, that's not what i was hoping to hear...
<spiv> NETabuse: I think you have an ignore pattern that is causing that error
<NETabuse> spiv, phew,, that did it.
<spiv> NETabuse: please file a bug on bzr
<NETabuse> i'd been messing iwth ignore patterns trying to ignore all images in the image upload data dir
<spiv> NETabuse: I just skimmed the NEWS file, and it doesn't appear to have been fixed since the version you are using.
<lifeless> we should be prettier in that case
<NETabuse> so i'd done bzr ignore path/to/uploads/*.[jpg|gif|png]   and it just put in a line in .bzrignore path/to/uploads/*.[jpg    and that was it.
<NETabuse> there   https://bugs.launchpad.net/bzr/+bug/433437
<ubottu> Launchpad bug 433437 in bzr "bzr ignore paths including [ character throws "sre_constants.error: bad character range"" [Undecided,New]
<NETabuse> i'll update it with more details soon.
<NETabuse> thanks for spotting that it was ignore patterns.
<NETabuse> hmm, how do i push my code up from my laptop to my server, server has bzr on it.
<lifeless> bzr push bzr+shh://server/abs/path/here
<NETabuse> bzr: ERROR: unknown command 'serve'
<lifeless> the server must have a _very very very_ old version of bzr
<lifeless> what does 'ssh server bzr --version'
<lifeless> report?
<NETabuse> yeh, bzr 0.8.2
<lifeless> that is so old it doesn't support being a server
<lifeless> you could use sftp, or preferrably upgrade the bzr on the server
<NETabuse> well, it's dapper.
<NETabuse> so how do i update it to newer bzr?
<lifeless> we have dapper builds in the bzr ppa
<lifeless> see http://bazaar-vcs.org/Download
<NETabuse> that's awsome, thanks, got the new bzr in and no serve command error
<NETabuse> right, i'm off for some family time.
<NETabuse> thanks for the help today.
<lifeless> np, ciao
<fullermd> Wow, 0.8.2 in the wild?
<wgrant> Scary...
<pitseleh> hello, i'm working with an online repository, i've received the contents with bzr checkout sftp://...
<pitseleh> how do i 'checkin'?
<bob2> bzr commit
<bob2> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
<pitseleh> bob2: the problem is, i haven't set up an ssh key, so i'd expect a password prompt every time i update or commit
<pitseleh> which happens on another pc i'm using
<bob2> probably
<pitseleh> but on this one.. it seems like it's not connecting to the server either during update or commit :/
<wgrant> pitseleh: Sure you didn't do 'bzr branch' rather than 'bzr checkout'?
<pitseleh> wgrant: ! that may be it lol, sorry about that
<pitseleh> i'll try again :)
<pitseleh> thank you
<Peng_> beuno: Oh! So my tshirt didn't get stolen by Customs or something?
<SamB> jelmer: I don't suppose there's been any progress in getting bzr to use .gitignore and so on?
<SamB> hmm, this one looks so simple, I'm tempted to just make .bzrignore a symlink to it ...
<Peng_> Woah, 2.0rc2. Congrats!
<NET||abuse> hey guys.. i pushed a copy of my branch up to a web server,,
<NET||abuse> how do i use it to deploy the code to the live site directories.
<NET||abuse> ?
<dsuch> Um, I'm currently fighting with multiple svn --reintegrate issues, if bzr is free of such problems then it should be one of its selling points, guys.
<pg1054> hi. i'm brand new to bzr.  i've co'd a tree (e.g., bzr branch lp:pressflow pressflow-6).  now i want to replace a dir within that tree with a backup of my files, and subsequently be able to merge updates to that tree (bzr merge lp:pressflow).  atm, i've clearly made a mistake by simply copying in my backed up files, as @ update/sync i get -> http://pastebin.com/d6d8fa07c.
<pg1054> reading the docs, i'm guessing i'm misusing workflow, and may need a "--local" flag somewhere ... but unclear to me atm.
<pg1054> any hints?
<Meths> pg1054: bzr and launchpad need to know who you are so they can communicate properly.  you need to do bzr launchpad-login davidstrauss
<pg1054> Meths: hi.  aha.  even for 'anonymous' checkout, where i am NOT contributing back to the upstream trees?
<Meths> try pull instead of merge
<Meths> or I'm talking rubbish, the message is a warning not an error, it's doing what you are asking but telling you you haven't logged in as well
<Meths> pg1054: lines 3 and 6 are the actual responses to what you are doing, everything else is message
<pg1054> Meths ok.  got it, i think. thanks.
<hsn> https://bugs.launchpad.net/bugs/433648 - there seems to be some problem with bzr push
<ubottu> Launchpad bug 433648 in bzr "bazaar crashes during push after adding tag" [Undecided,New]
<hsn> i can repeat it every time
<theAdib> hello all ! What is it that makes a 2.0in the next release?
<igc> morning
<lifeless> hi igc
<igc> hi
#bzr 2010-09-20
<spiv> Good morning.
<jbowtie> Good afternoon.
<jbowtie> Looks like my documentation patches have been reviewed. Feel like I'm making good progress.
<jbowtie> Though I've noticed several times that a bug has been fixed but never updated.
<spiv> jkakar: I wonder if that's often because someone just fixed something they happened to notice right then, without first looking in the bug tracker?
<jbowtie> spiv: I presume so. I've been slightly lazy and just marked them as "fix committed" with "2.2" as the milestone if I can see the fix in the 2.2 docs or help output.
<poolie> hi there spiv, jbowtie
<jbowtie> It would be nice if there was some simple way to figure out which version branches a revision actually ended up in, then I could be more precise.
<jbowtie> That's probably a nice loggerhead feature for me to try writing sometime.
<spiv> jbowtie: we don't use "fix committed", use either "in progress" or "fix released": http://doc.bazaar.canonical.com/latest/developers/bug-handling.html#bug-status
<jbowtie> spiv: My bad, I actually did set them to "fix released".
<spiv> jbowtie: don't worry too much about setting the milestone if you're not sure when it was fixed, the main thing is to have the bug closed.
<jbowtie> spiv: We really should get rid of that bug status though so it's not accidentally used.
<spiv> You can always leave a comment saying "this appears to have been fixed sometime before 2.2" or whatever.
<spiv> Yeah.
<spiv> It's https://bugs.edge.launchpad.net/malone/+bug/163694
<ubot5`> Launchpad bug 163694 in Launchpad Bugs "Fix Committed/Released distinction is inconsistent and unproductive (affected: 12, heat: 45)" [High,Triaged]
<jbowtie> Well, I could, but it would be good to know in particular for documentation fixes as a fair number of them can be backported and improve the user experience (like fixes for broken links).
<jbowtie> poolie: Sent through my CV a couple of days ago for the BSE, it's about 6 months out of date so let me know if you need any supporting material/links.
<poolie> jbowtie: if the "giving back" documentation could be clearer, please ask or send a patch or file a bug
<poolie> oh great
 * poolie look-s
<poolie> i don't have it from HR yet
<poolie> probably will today-
<jbowtie> poolie: No worries as long as it didn't end up in the recycle bin.  :)
<jbowtie> Wow, 3 years and no one's rolled a patch for that bug. I might be diving into the launchpad code tonight just so I stop using that bug status.
<poolie> now that would be an impressive bug to fix
<poolie> it's only about 10% code and 90% social
<poolie> getting sufficient agreement that we will indeed transition away from it
<poolie> feeling confident enough users will be ok with that plan
<poolie> communicating it
* spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | bzr 2.2.0 is officially out| bzr-2.0.6, 2.1.3 and 2.2.1 need installers, aTdHvAaNnKcSe !  | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<poolie> you're the pilot this week?
<spiv> Apparently! :)
<spiv> Which is good, because I was just starting to think how nice it would be to clear out the +activereviews page...
<jbowtie> Is there anything better than Empathy for IRC? It's annoying to connect to new rooms via the Empathy dialogs.
<poolie> spiv that would be great
<poolie> jbowtie, on ubuntu?
<poolie> i use xchat for irc and pidgin for other stuff
<jbowtie> poolie: Yes, thanks, that's the one I couldn't remember the name of. I knew there used to be a different default IRC client but could not think of it.
<poolie> spiv, thanks for the changelog merger, could you add it to the plugin guide?
<poolie> which i think is in the bzr-alldocs project
<spiv> poolie: good idea, but let's wait until it's had a little bit of real-world exercise first, in case it's horribly broken :)
<poolie> :) oh i don't know, you could always list it as 'alpha'
<spiv> I was thinking of the part of http://doc.bazaar.canonical.com/plugins/en/plugin-development.html#adding-your-plugin-to-the-plugins-guide that says "i.e. inclusion in the Guide implies a certain degree of this works as advertised."
<AfC> What is this Â«worksÂ» you speak of?
<spiv> If Eli reports that it works ok then I'll consider it to have met that hurdle.
<fullermd> AfC: It's this low-end office suite made by Microsoft...
<vila> hi all !
<vila> ping losa
<spm> heya vila
<vila> wow, instant answer :-)
<vila> spm: be careful, I may ge used to it :-p
<vila> spm: it's about RT #41434
<vila> spm: aka, pulling bzr.dev in bzr-2.3, I asked for revno 5432 in the ticket, but reno 5424 will be fine too
<vila> spm: better stick with as much 4 as possible...
<spm> more 4 is good, 4 4's are better 4 us?
<vila> spm: yeah, but don't overdo it, reno 4444 won't be good  ;)
<spm> :-)
<poolie> hello vila
<vila> poolie: hey :)
<spm> vila: Ok, re-read about 4 times, I think I know what's needed now :-)
<vila> spm: :-/ How should have I better phrased that (and is this sentence correct english ?) ?
<spm> vila: ha. no. the english etc is fine. more "switch mindset to understanding what you want"
<vila> k
<spm> if you like - translating the plain request into technical "Do X, Y and Zeee"
<spm> it's this stuff: https://wiki.canonical.com/InformationInfrastructure/OSA/PQM#BZR%20%28the%20project%29%20and%20PQM <== more or less
<poolie> vila, thanks for all the releases
<vila> poolie: about the flagship bugs, from the series pages (https://edge.launchpad.net/bzr/2.0/2.0.6 etc) I'd say: 2.0.6 -> bug #582656, 2.1.3 -> bug #525571 and 2.2.1 -> bug #633745 thoughts ?
<ubot5`> Launchpad bug 582656 in Bazaar 2.1 "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 2)" [High,Fix released] https://launchpad.net/bugs/582656
<ubot5`> Launchpad bug 525571 in Launchpad Bazaar Integration "No locking when updating files in ~/.bazaar (affected: 7, heat: 51)" [High,Fix released] https://launchpad.net/bugs/525571
<ubot5`> Launchpad bug 633745 in Bazaar 2.2 "bzr+ssh to pre-1.6 server fails with AttributeError: 'NoneType' object has no attribute 'close' in close_ssh_proc (affected: 1, heat: 18)" [Critical,Fix released] https://launchpad.net/bugs/633745
<vila> good bot... awesome
<vila> about bots, I discover http://www.youtube.com/watch?v=rSKRgasUEko this week-end, amazing and almost affordable (the rumour is ~3000euors, i.e. a big PC)
<vila> poolie: yeah, it still took me to much time but I think we have already pushed a lot of hurdles out of the way by integrating them earlier in the workflow
<vila> poolie: and I didn't find obvious mistakes in releasing.txt :-)
<vila> poolie: I changed checknewsbug.py to use hydrazine instead of lp anonymous
<poolie> hm
<poolie> is that better?
<vila> poolie: yes, notably for private bugs
<poolie> right
<vila> I was able to fix the remaining typos. The script helps to identify them but not fix them. We could try some permutations but I didn't have time to play with that
<poolie> we should post on the blog too
<vila> err, about what ?
<poolie> that we released
<vila> the releases ?
<poolie> though i guess the homepage aggregator shows it
<vila> ha, before the installers are ready ?
<poolie> and i'm not sure it's worth blogging everything
<poolie> heh
<vila> so, the remaining "problems" for checknesbug.py is that some bugs are still in progress... That is, we've fixed part of the bug and landed the fixes, yet, the bug can't be considered fix released...
<vila> #583667 #598701 #601804 #566940 #82086 #219334 #375013 etc
<vila> pfff
<vila> bug #583667 bug #598701 bug #601804 bug #566940 bug #82086 bug #219334 bug #375013 etc
<ubot5`> Launchpad bug 583667 in Bazaar "bzr talks to edge API servers to propose merges (but not for lp: url lookups) (affected: 1, heat: 2)" [High,Confirmed] https://launchpad.net/bugs/583667
<ubot5`> Launchpad bug 598701 in Bazaar "bzr should not show internal object name in "<rev> does not exist" error (affected: 1, heat: 5)" [Low,Confirmed] https://launchpad.net/bugs/598701
<ubot5`> Launchpad bug 601804 in Bazaar "test failure on hardy: bzrlib.tests.test_sftp_transport.SSHVendorBadConnection.test_bad_connection_ssh (affected: 1, heat: 6)" [Low,Confirmed] https://launchpad.net/bugs/601804
<ubot5`> Launchpad bug 566940 in Bazaar "Reducing peak memory for commit (affected: 2, heat: 12)" [Medium,Confirmed] https://launchpad.net/bugs/566940
<ubot5`> Launchpad bug 82086 in Bazaar "pycurl transport causes tracebacks if the server's SSL cert cannot be verified. (affected: 3, heat: 46)" [Medium,Confirmed] https://launchpad.net/bugs/82086
<vila> that's not so bad, but if we were able to make it pass silently we could add a regular check so further reduce the burden on the RM
<vila> s/check so/check to/
<spm> vila: fyi, that's been done: https://code.edge.launchpad.net/bzr
<vila> spm: rock and roll, release time for 2.3b1 !
<vila> spm: thanks !
<vila> meh I meant bug #522637 as flagship bug for 2.0.6
<ubot5`> Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 14, heat: 68)" [Low,Triaged] https://launchpad.net/bugs/522637
<vila> poolie: hmm, what was the last bug you used for SRU ?
<poolie> vila, for 2.2.1?
<vila> poolie: no, I'm looking for one that has already been nominated
<vila> poolie: and I found bug #636930 for 2.2.1 which I will use indeed
<ubot5`> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 4, heat: 876)" [High,Triaged] https://launchpad.net/bugs/636930
<vila> poolie: just added sru as an official tag
<poolie> k
<poolie> i don't know if it's the latest but bug 528041 is one recent one
<ubot5`> Launchpad bug 528041 in bzr (Ubuntu Lucid) "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 22, heat: 134)" [Undecided,Confirmed] https://launchpad.net/bugs/528041
<vila> poolie: right, thanks, exactly the one I had in mind
<vila> maxb: just checking, all your work on tools/packaging/* has landed in bzr.dev right ?
<vila> hmpf, lp:~ubuntu-branches 244840 owned branches...
<spiv> Ugh, hooks.py is a bit ugly.
<maxb> vila: Um, I think "all my work" was pretty much just a change of the branch naming scheme, but yes, it landed.
<spiv> We're overdue for extracting a "give me the python object named by given a module name and optional dotted attr" function, I think.
<lifeless> spiv: doesn't twisted have one of those?
<lifeless> spiv: perhaps they could have their arms twisted to make a separate release of that, and we could depend on it
<vila> maxb: excellent, I just noticed that it would be good to check for $PACKAGE as we do for $UBUNTU_RELEASES, I will do that
<vila> maxb: hmm, well, it won't fly for update-packaging-branches :-/ There is still a '~bzr' there that won't scale for other packages (when the script *creates* the local branch)
<vila> maxb: you use a single shared repo for all your packaging branches whatever the package is right ? All of them in a single directory right ? (aka bzr-lucid and bzr-svn-lucid are in the same dir on your local disk)
<vila> GaryvdM: Hey !
<GaryvdM> Hi vila
<GaryvdM> Hi all
<vila> GaryvdM: would you be working on the 2.2.1 windows installers ?
<GaryvdM> vila: Yes. I'll start maybe today, or maybe tonight.
<GaryvdM> Depending on work.
<vila> GaryvdM: cool, would you mind updating http://wiki.bazaar.canonical.com/Releases/2.2.1 ?
<GaryvdM> Ok
<vila> maxb: do you know who we should/could ping to update the debian side for 2.2.1 ?
<fullermd> vila: <http://lists.freebsd.org/pipermail/cvs-all/2010-September/321850.html> BTW, so we can mark that off if we're keeping track.
<vila> fullermd: yup
<GaryvdM> vila: pkg-bazaar-maint@lists.alioth.debian.org
 * GaryvdM trying to find out who the members are
<GaryvdM> I know offhand jelmer is one.
<vila> GaryvdM: hmm, does this mean we should start my a *mail* there ?
<vila> s/my/by/
<GaryvdM> vila: I think so
<vila> fullermd: updated
<vila> GaryvdM: k
<GaryvdM> vila: 2.2.1 should have shown up on this page in the watch column: http://qa.debian.org/developer.php?login=pkg-bazaar-maint@lists.alioth.debian.org
<GaryvdM> I'm not sure why it has not, maybe update delay...
 * vila blinks
<vila> there is a lot of numbers to grasp here...
<vila> are even
<vila> or does 'is' apply to 'a lot' ...
<maxb> vila: But all the ~bzr PPA packaging branches should be in ~bzr anyway, no, so no problem?
<vila> applies... here we go typo fest !
<vila> maxb: !
<maxb> vila: Personally, I created my packaging branches before I encountered tools/packaging/, and so haven't really found a use for those scripts yet
<vila> maxb: sounds right indeed, worth a comment
<vila> maxb: no problem with that, but since I'm starting from scratch (removing my old crufty attempts), I may as well make it easy for the next RM
<maxb> vila: http://packages.qa.debian.org/b/bzr.html says jelmer usually does Debian
<vila> jelmer. jelmer, wake up, wake up :-D
<vila> maxb: thanks for the pointer
<vila> haaa, larstiq and jonhf are there too
<vila> so, if I read that correctly they want 2.1.3 and 2.2.1 first,
<vila> then 2.3b1 will enter the game... or will they wait for 2.3.0 ?
<spiv> lifeless: twisted does have something along those lines, but it's pretty easy to do, and we already have the code for it really, just not in an especially reusable spot
<vila> maxb, GaryvdM: Anyway, it means I should forward announcements for 2.1.3 and 2.2.1 to pkg-bazaar-maint@lists.alioth.debian.org, right ?
<spiv> lifeless: which leads to e.g. hooks.py doing _LazyObjectGetter(...).get_obj(), which is obviously not lazy at all
<spiv> Also, the relevant code in _LazyObjectGetter doesn't appear to have direct unit tests, and it ought to.
<vila> spiv: +1 :-D
<maxb> vila: hmm. You could ask that list if they want release announcements. They may not, having other ways, like DEHS, to be advised of new upstream releases
<vila> maxb: Ok, I'll do that
<maxb> They may not even want 2.1.3 - the debian freeze is in effect
<maxb> the freeze exception rules are basically "critical bugs only"
<vila> maxb: ok, no critical ones for 2.1.3 (I think the 2.0 critical ones were part of 2.1.2)
<vila> maxb: mail sent
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | bzr 2.2.0 is officially out| bzr-2.0.6, 2.1.3,  2.2.1 and 2.3b1 need installers, aTdHvAaNnKcSe !  | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> Do someone remember the trick to change 'Affects' from bzr (Ubuntu) the source package to our bzr ?
<deryck> vila, hi.  unfortunately, you can't.  It's bug 80902.
<ubot5`> Launchpad bug 80902 in Launchpad Bugs "Can't target bug report from project to distribution, or vice versa (affected: 7, heat: 67)" [Medium,Triaged] https://launchpad.net/bugs/80902
<fullermd> vila: EWRONGMAILSUBJECT?   8-}
<vila> NOOOO
<vila> deryck: grumble, I'm sure spiv or someone had a workaround some months ago
<bialix> vila: Indeed, wrong
<fullermd> I blame that 'emacs' thing, personally.  I think it screws up your typing   :p
<vila> fullermd: hehe, gnus, blame gnus ;-)
<vila> losas are magicians... they fixed the review team for lp:bzr/2.3 even before I could report the problem...
<jam> GaryvdM: you around?
<GaryvdM> Hi jam.
<jam> did someone start the ec2 instance for you?
<jam> I logged on and it was already running
<jam> maybe we just forgot to shut it down again?
<GaryvdM> I'm here, but I've not yet started due to work.
<GaryvdM> jam: I did not ask anyone other than you.
<jam> GaryvdM: I was worried you'd say that
<GaryvdM> I saw that it was up.
<jam> I'm updating the pyqt now
<GaryvdM> jam: Thanks
<jam> you only need the new PyQT for 2.6, right?
<jam> any idea when we can use the latest again?
<GaryvdM> jam: When they fix a bug. I'll find the url for the bug for you.
<jam> Seems weird that the older one would have 4.6 and then we went to 4.7, but now downgrading all the way to 4.5
<GaryvdM> qbzr bug: https://bugs.edge.launchpad.net/qbzr/+bug/632501
<ubot5`> Launchpad bug 632501 in QBzr "[win32] Subwindows only paint after a keyboard/mouse event. (affected: 1, heat: 10)" [Critical,Confirmed]
<jam> vila: enjoying the multi-release management?
<jam>  /thank for not making me do it :)
<GaryvdM> jam: qt bug: http://bugreports.qt.nokia.com/browse/QTBUG-12721
<vila> jam: hehe, yeah, not so many typos so far :)
<vila> jam: you greatly deserved a break ;)
<GaryvdM> jam: Good question. - What pyqt versions do you have?
 * GaryvdM checks what versions I've got.
<jam> GaryvdM: I seem to have the source for 4.5.4, but no installer. I probably deleted it a while back to save space
<vila> jam: did you see https://code.edge.launchpad.net/~vila/bzr/integration/+merge/36012 ?
<vila> jam: aren't you amazed about all those bugs I just fixed by updating NEWS....
<jam> vila: :)
<jam> that is what, all of 2.2 into 2.3 ?
<vila> jam: aaaah, just understood, that's all the bug that I fixed but merged locally in my integration branch...
<vila> jam: that's the first time I use it for proposal on lp, so it probably freaks out a bit
<jam> vila: right, its all the bugs that have been associated with your integration branch over time
<jam> poolie had a comment a while back that it is misleading
<jam> since he re-uses 'doc' and 'trivial' a lot
<vila> ok, thanks
<jam> GaryvdM: PyQt is installed, let me know if you need anything else
<vila> jam: I was vaguely worried but I know my merge was clean so I suspected lp rather than bzr or me :)
<jam> GaryvdM: are you going to use the old build script for the old releases? (2.0, etc)
<jam> vila: I thought it could have been all the --fixes tags in 2.2 merging into 2.3, but as you say, that should include more code changes, and you only have NEWS changes
<jam> a lot of bug typos, though :)
<vila> jam: yeah, but collected from 2.[012], there should be only *new* typos from now on ;)
<jam> I thought I caught the 2.2 ones. but I intentionally didn't run the 'find bugs' script on anything else
<vila> jam: I also shake a lot of series and milestones on lp, so keep an eye open for errors (Thanks in advance ;)
<jam> btw, I'm not particularly happy with the workflow of pushing up things to the review queue that isn't meant to be reviewed. How do you feel?
<jam> (like prepare-2.3b1)
<jam> (I like knowing something is going on, but 3-emails telling me "ignore this, it is just housekeeping" bothers me)
<jam> though if LP doesn't start letting me email back, I may stop reviewing via email
<vila> well, I thought that for the lp:/bzr/2.[0123] it was worth using mps so I don't have to tell people: hey, heads-up, seen that ?
<GaryvdM> Hi vila
<vila> GaryvdM: hey !
<jam> vila: I would like to get 1 email, the problem is that it is 3-5
<GaryvdM> jam: Thanks
<jam> and it is in the "hey you really need to look at this" folder
<vila> jam: you file a bug on lp for that ?
<jam> vila: for not being able to send email, yes
<vila> jam: asking for the same aggregation that the bugs do ?
<jam> with some response from rockstar telling me it was a foundations bug, and nothing from them
<GaryvdM> jam: Yes - as far as I'm aware, the Ian's scripts don't work for older than 2.2, so yes.
<vila> jam: no to get a single mail instead of 3
<vila> jam: :-/
<GaryvdM> jam: I've never run the old scripts, so I might ask for some help.
<GaryvdM> jam: But 2.2.1 will be priority.
<vila> GaryvdM: +1 for 2.2.1 :)
<vila> GaryvdM: +0.8 for 2.3b1 so bialix can test it :-p
<jam> to be fair, it was probably the end of the week
<jam> but I don't know the name of a person on foundations so I can bug them
<jam> I guess I could go look :)
<GaryvdM> jam: I think that there was no pyqt 4.6 binary for python 2.6, and that's why we have to go back to 4.5 :-(
<jam> GaryvdM: right, probably not one for 2.6
<jam> I have it for 2.5
<jam> (well, we have it installed on desolation)
<jam> but yeah, I remember there being version issues against various python releases
<jam> I really wish the riverbank guys would keep old installers around
<jam> vila: I haven't looked through any other changes, but I'll note that sometimes a bug # gets put in NEWS because of a partial fix, which shouldn't actually mark the bug Fix Released entirely. Did you check any of that?
<jam> or did you just mark them all released?
<vila> jam: indeed, that's the problem I mentioned to poolie this morning (mine),
<jam> vila: k. I did a lot of that triage in the 2.2.0 release
<jam> some of which is "we should try to have more focused bugs"
<vila> jam: no I didn't mark them fix released so they still show up in check-newsbugs.py output but this outlines a problem
<vila> exactly
<jam> vila: why did you add the global "fix_released = False" check?
<vila> I think the rule should be: if you can't mark the bug fix released, crete a new one, more focused and mention it in NEWS and in the bug it partially addresses
<jam> are you saying "if any task says that fix is released, that is good enough" ?
<jam> and the comment is about cross-version issues ?
<jam> (2.0 says, In Progress, but 2.1 says Fix Released ?)
<jam> if you really want to do that, I think the check needs to come after the loop
<jam> since otherwise 2.0 will say "hey not in sync" but 2.2 won't if 2.0 says fixed
<vila> I think it was... a different case ;)
<vila> let me try to find it back
<vila> oh, but regarding the problem above, there is still the problem that a bug may be re-opened...
<jam> vila: sure
<jam> also, why did you assign me to bug #343218?
<ubot5`> Launchpad bug 343218 in Gentoo Overlay for Bazaar "export could take unmodified files from wt rather than repository (affected: 0, heat: 10)" [Undecided,Confirmed] https://launchpad.net/bugs/343218
<vila> oh right, so the case is that if you don't summarize fix_released, the script whines as long as it finds *one* task still not fixed released and I was encountering too many false positives
<jam> I did do the work to make it better about grabbing content all-at-once
<jam> vila: I understand your point about summarizing, my point is that there is still an ordering issue
<jam> if 2.0 is Fix Released, but 2.2 isn't, then you'll get nothing, but if 2.2 is Fix Released, and 2.0 isn't, you'll get nothing
<jam> sorry, last form, you'll get chatter
<jam> because it will see the 2.0 status before it sees the 2.2 status
<vila> in addition there are bugs where we just can't set the status (when the task is against bzr (Ubuntu) for example)
<vila> so it's not perfect, but the idea is that the RM will have already a good overview of what bugs have been fixed and which ones are in progress,
<vila> the script helps to track *progress* while fixing NEWS
<jam> vila: I can tell you when I was an RM, I didn't have a great handle on the 50 bugs that were all fixed :)
<vila> I was tempted to add a blacklist for the bug still in progress while fixed...
<hallyn> i'm apparently not doing 'merge' right.  if i want to do a merge such that histroy is maintained, does 'merge -rRN-1..Rn ~/origtree' not suffice?
<vila> well, I mean having seen the bug page at least once :)
<jam> hallyn: you're doing a cherrypick, which we won't remember history (because you are explicitly asking us to *omit* history by specifying a start rev)
<jam> bzr merge -r Rn will work
<GaryvdM> hallyn: So the history of the branch that you merge into is maintained, so i
<GaryvdM> Ah - sorry - please ignore that.
<hallyn> jam: and that merge will still only take the last commit?
<vila> jam: right, so the comment points to bug #416732, without the summary, it pops up
<hallyn> GaryvdM: thanks though :)
<ubot5`> Launchpad bug 416732 in Bazaar 2.0 "check reports "Missing inventory {('TREE_ROOT'..." for trivial non-rich-root branch (affected: 3, heat: 0)" [Critical,Fix released] https://launchpad.net/bugs/416732
<hallyn> jam: ok, thanks, i'll try that again.  i forget why i started specifying ranges
<vila> jam: may be the solution is to recognize a config variable whose value is a list of black-listed bugs :)
<jam> vila: I think hard-coding it into the script is appropriate for a script sitting in bzr's source tree
<jam> IMO
<jam> vila: also, I'm not sure why we can't change the Invalid to Fix Released on that particular bug
<Glenjamin> hallyn: "bzr merge -r Rn" will give you all revisions up to n which you don't have, which might be subtly different
<vila> jam: we can, but my comment will become obsolete
 * vila ducks
<jam> vila: note that Invalid should probably be considered a "I don't care about this bug anymore" similar to Fix Released. ...
<hallyn> Glenjamin: yeah, that's not safe for me
<jam> though why would we be fixing an invalid bug
<vila> jam: Added this discussion on the mp, feel free to review and vote now ;-P
 * vila back to release tasks
<Glenjamin> hallyn: i'm not sure you can directly do what you're after then
<jam> vila: I did vote already
<jam> hallyn: if you really want to reject all other changes, you can do "bzr merge -r N-1; bzr revert .; bzr commit -m "reject old changes"; bzr merge -r N; bzr commit -m "bring in the new change"
<jam> note that the '.' is significant, since it reverts the file content, without reverting the pending merge
<Glenjamin> can I pull changes from one tree's shelf to another, or is apply/merge --unci going to be simpler?
<Glenjamin> jam: i was under the impression that revert doesn't forget merges unless you explicitly tell it to?
<Glenjamin> i'm fairly sure i've done revert --no-backup and still had the merges pending.
<hallyn> jam: Glenjamin: ok, thanks.  I guess I'll just keep adding my own commit msgs for nwo
<vila> jam: weird, damn lp should DWIM-refresh :)
<vila> jam: thanks !
<jam> Glenjamin: 'bzr revert' with no arguments reverts everything, including pending merges, etc
<jam> Glenjamin: you can copy the shelf around and it should work (as long as you are still in the same shared repo)
<jam> however, --uncommitted is probably more straightforward
<Glenjamin> jam: revert with no args, or revert with no path?
<jam> Glenjamin: no path (no positional arguments, as opposed to -- style "options")
<Glenjamin> is there a concept similar to looms/shelf where I can move changesets around branches. Basically bugfixes that I dont want a full branch for.
<jam> Glenjamin: why not a full branch?
<jam> (with no tree in a shared repo, branches should be very cheap)
<Glenjamin> i do have a tree
<Glenjamin> oh right, treeless branch
<Glenjamin> as patch storage
<Glenjamin> that'd work
<Glenjamin> hrm, I don't think that'll work actually - how do i get the changeset into the treeless branch?
<Glenjamin> i suppose i can uncommit actually
<GaryvdM> Preliminary build of 2.2.1: http://dl.dropbox.com/u/4494367/bzr-2.2.1~a-setup.exe
<GaryvdM> But https://bugs.edge.launchpad.net/tortoisebzr/+bug/641557 still not fixed :-(
<ubot5`> Launchpad bug 641557 in TortoiseBZR "error while trying to run command via context menu (affected: 2, heat: 12)" [Critical,Fix committed]
<git__> can one export a repository based on time?
<GaryvdM> git__: I think the term we would use it to export a tree: bzr export -r date:2006-08-14,17:10:14
<GaryvdM> or bzr export -r date:yesterday
<GaryvdM> see bzr help revisionspec
<GaryvdM> note that export is for exporting an archive (e.g. .tar) of a tree. If you want to work with the files, you should rather bzr branch FROM TO -r date:...
<GaryvdM> git__ ^
<git__> thanks GaryvdM !
<GaryvdM> it's a Pleasure.
<git__> seems like bzr is not able to handle filenames : and ? in Windows
<git__> i did a "bzr clone bzr://192.168.0.109/project"
<jelmer> vila: hi
<luke-jr> git__: rather, Windows isn't able to handle them
<git__> :)
<git__> what to do in this situation?  Have a pre-script to convert : and ? to _ ?
<luke-jr> ...
<luke-jr> just don't create files with those names?
<awilkins> Ok.... working off an SVN branch. The person doing branches is an idiot and has made a branch where the first revision consists of all the files being deleted and replaced simultaneously. This does not merge well. Any suggestions for fixing (or at least merging cleanly)?
<jelmer> awilkins: not really, even svn itself would have issues with that I think
<awilkins> jelmer, Hrmmph. I have to get this merged somehow
<awilkins> Or at least recommend how to do it to someone if I am to remain sane.
<awilkins> 1816 content conflicts just trying the vanilla way :-(
<awilkins> I suppose a kind of rewrite omitting the "evil revision" and applying the changesets as patch/revisions would work...
<jelmer> awilkins: you should be able to revert his changes... but I guess that's not really what you're looking for?
<awilkins> jelmer, there are about a hundred big revisions after this one
<awilkins> If I revert it, won't I just get the same content conflicts?
<awilkins> I'm trying git in desperation :-)
<awilkins> That shouldn't be fooled by the files being "deleted" and then "added" hopefully
<awilkins> Since if they are unchanged they will be the same objects
<jelmer> git might be able to deal with it better since it works with content rather than files
<awilkins> At least I may be able to get a merge pushed from it and then go back to working with Bazaar... or I may defect (I need to understand git better)
<awilkins> This project itself is supposed to be a version controlled object database, alas, the guy writing it doesn't really understand version control
<awilkins> I was thinking of trying to superimpose the git object model on top of it (it's in a K/V store rather than a RDBMS)
<awilkins> Adding git tree/commit/blob objects to the mixture, construct an "index" of live objects by walking the tree objects
<GaryvdM> Another TDD question: If I need to test a bit of code that changes a state tracker, should I assert on the state after the change, or should I assert on the output of whatever uses the state
<GaryvdM> Ah - Let me get an actual example..
<GaryvdM> In this test: http://bazaar.launchpad.net/~garyvdm/qbzr/log_refactor/annotate/head%3A/lib/tests/test_loggraphprovider.py#L226
<lifeless> GaryvdM: you can assert on the state, or on the behaviour
<lifeless> or on both
<lifeless> depending on what layer you want to test.
<GaryvdM> Ok
<GaryvdM> In the above test, You can see I have a state, which I change in the middle of the test with state.collapse_expand_rev
<GaryvdM> I need to write some more tests for state.collapse_expand_rev.
<GaryvdM> So do I call state.collapse_expand_rev, and assert on the fields of state?
<GaryvdM> I guess that is the layer that I want to test.
<GaryvdM> but I the data structure of state is not important.
<GaryvdM> Ok - I think I'll check the fields of state, and the results of it filter, but not a full compute_graph_lines
<GaryvdM> Thanks lifeless
#bzr 2010-09-21
<spiv> Good morning
<spiv> news_merge should be active on PQM now
<poolie> hiya spiv
<poolie> yay!
<poolie> mkanat: hi?
<mkanat> poolie: Howdy!
<poolie> hi there
<poolie> are you free to work on some loggerhead bugs now? or perhaps already doing so?
<mkanat> poolie: Yeah, I could do some. :-)
<mkanat> poolie: Not at this exact second, but probably today or tomorrow.
<poolie> ok
<poolie> i was just reminded by seeing a notice of another hang the other day
<poolie> wbn to either get to the bottom of it, or go to a multiprocess thing
<poolie> or both
<mkanat> poolie: Yeah, for sure.
<mkanat> poolie: The multiprocess thing is a big project, though.
<poolie> well, actually fixing things is more satisfying
<mkanat> poolie: Absolutely!
<mkanat> poolie: I've done so many small, focused hang fixes that would all have been obsoleted if we just had a better architecture.
<poolie> hm
<mkanat> poolie: Except for one deadlock, the hangs that I've fixed haven't really been hangs--they've just been the system getting overloaded.
<poolie> i wonder if someone else could work with you on changing the process architecture
<poolie> hm
<mkanat> poolie: Ultimately I suspect it's something that would be most efficiently done by one developer.
<poolie> perhaps
<mkanat> poolie: The codebase isn't so large that it would have to be a team effort, I think.
<poolie> it would be nice to at least get review of it by someone else
<mkanat> poolie: I'm not saying that that one developer has to be me.
<mkanat> poolie: Oh, absolutely.
<mkanat> poolie: One reviewer and one developer would probably be a good match.
<poolie> mkanat: ok, let's do it
<mkanat> poolie: Sweet!
<mkanat> poolie: I'll start feasibility studies probably today or tomorrow.
<poolie> if possible keep it isolated in wsgi stuff as much as is sensible so we can switch that layer later
<poolie> and let's think about supportability/traceability stuff
<poolie> like keeping oops reporting, perhaps something to show where time is spent
<poolie> but mostly, see if you can get the basic switch done
<poolie> have fun
<poolie> don't go silent
<mkanat> poolie: Okay. :-)
<mkanat> poolie: Because we're switching from a threading model to a process model, though, there will be a lot of stuff that isn't in the WSGI layer.
<mkanat> poolie: Since we will be removing locks, and we can't share variables anymore.
<poolie> ok
<poolie> perhaps you could explain this in a mail rather than to me
<poolie> probably we should talk about that in mail
<mkanat> poolie: Okay. I will as soon as I get further into finding out what's actually require.d
<mkanat> *required
<jbowtie> I'm thinking of wrapping the docstrings in builtins.py in gettext calls in order to enable translation of at least the help text. Am I overlooking anything obvious?
<jbowtie> It should work for class docstrings; would have to be more complicated if we used method docstrings in the help output.
<lifeless> performance
<lifeless> it depends on what you mean
<lifeless> if you mean 'pass the help text to gettext when rendering help' - that should be fine.
<jbowtie> lifeless: well you still need to mark the strings for translation.
<lifeless> why?
<jbowtie> lifeless: So that they end up in the POT file?
<lifeless> there are other ways of doing that
<lifeless> we know all things to translate via introspection
<lifeless> jbowtie: _() will run afunction for every string at load time for the system, its a terrible overhead
<jbowtie> I'd be happy to know what those are, all the programs I translate use gettext.
<lifeless> jbowtie: for command in commands: text = command.help(); line = command.run._im_co.__line__ ...
 * lifeless is handwaving
<lifeless> jbowtie: in C _() is free because the code is not executed unless you go down the code path; thats not the case for python.
<lifeless> static attributes are executed at module time.
<jbowtie> lifeless: Well then maybe we shouldn't be using docstrings for documentation?
<jbowtie> I'm just concerned that currently I can't translate bazaar via Launchpad.
<lifeless> jbowtie: why not? they are designed for it
<lifeless> jbowtie: so, definitely doable; some glue needed.
<jbowtie> Handwoven glue that will need to be run every time a docstring changes?
<jbowtie> I'm just dubious, everything ends up getting patched to gettext eventually, or programs end up not getting translated.
<spiv> Well, like whatever bit of gettext that extracts _() syntax into POT files needs to be re-run when those strings change.
<spiv> It's just that rather than having a "extract _() calls in source into list of translatable strings" step, we'd have "run $handwave that has no runtime penalty in Python" step.
<mkanat> lifeless: Is Launchpad using a multi-threaded or multi-process server, right now?
<lifeless> mkanat: multi threaded
<spiv> We could even look at automating that step, e.g. PQM updating the set of strings to translate in Launchpad after every merge.
<mkanat> lifeless: Okay. Have you guys done any investigation on moving to multi-process, or are you scaling OK with multi-threaded? I'm starting to investigate possibilities for loggerhead.
<lifeless> mkanat: we have 12 or so machines running lp itself
<jbowtie> All right, I'll go look at the source for xgettext for a while.
<lifeless> mkanat: I have concerns about performance with threads and am investigating single-threaded instances (one request at a time) - because we already have a solid layer 7 proxy handing stuff to the backends
<lifeless> we could point that at loggerhead very easily
<lifeless> mkanat: e.g. tell paste to use 1 thread only and run up 4 loggerhead instances
<lifeless> mkanat: no need, in such an approach, for any multi-process glue.
<lifeless> mkanat: I have a bias against multi process wsgi; U1 tried that had it was a fairly bad experience for them.
<mkanat> lifeless: So I've heard, but I didn't really get any details on what the trouble was.
<lifeless> me neither
<lifeless> anyhow the big thing for me is that we already have a multi-process multiplexing system
<lifeless> we don't need two.
<lifeless> for the launchpad deployment of loggerhead, that is.
<mkanat> lifeless: Hmm.
<lifeless> the simplest way to get one process per request is to drop the thread count to 1 and tell ha proxy to send to 4 instances (or however many we decide to use)
<mkanat> lifeless: That certainly would be less work.
<mkanat> lifeless: Although that doesn't get us process management.
<lifeless> mkanat: what does 'process management' mean
<mkanat> lifeless: Well, say, the ability to tell when a process is hung and kill it, and then spawn another process.
<mkanat> lifeless: It's something that could be done with sysadmin work.
<mkanat> lifeless: But it's nicer to just have it in the app.
<lifeless> ah, 'spawning' was the name of the thing that gave u1 grief, IIRC
<mkanat> lifeless: Right, that's the only major multi-process WSGI server.
<mkanat> lifeless: But it's been years since U1 used that, and there have been a lot of Spawning releases since then; it's a very active project.
<lifeless> long term I'd like to be able to share the bazaar.launchpad.net load with the rest of the servers; with safeguards for rogue stuff
<lifeless> but thats -long- term, we're nowhere near ready for that
<mkanat> lifeless: You mean make loggerhead part of the normal server pool?
<lifeless> mkanat: anytihng that makes it easier to switch between paste, paste-w/1-thread, spawning, and in-lpnet-appservers is a good investment
<lifeless> mkanat: yes, just another wsgi site in the app
<lifeless> in the middle tier
<mkanat> lifeless: Okay.
<mkanat> lifeless: Who would I ask about what the U1 problems were with Spawning?
<lifeless> what tz are you in?
<mkanat> lifeless: Pacific
<mkanat> America/Los_Angeles
<lifeless> statik: would be a good entry point
<lifeless> he's not leading the team anymore but he'll know who was involved
<mkanat> lifeless: Great, thanks. :-)
<mkanat> lifeless: So from your viewpoint on the Launchpad technical side, what you'd like to see from loggerhead is a framework that makes it easier to fit it into whatever WSGI configuration you want to use.
<lifeless> I think that that would be a wise thing to work on
<lifeless> I think fixing the hangs is important too, because a hang is a user not getting a response.
<mkanat> lifeless: The hangs are a scaling problem.
<mkanat> lifeless: Or a deadlock problem.
<lifeless> and I think fixing the performance is also important
<mkanat> lifeless: Both of which are fixed by having multiple processes.
<lifeless> mkanat: deadlocking on what?
<mkanat> lifeless: Depends.
<mkanat> lifeless: Last deadlock I fixed (it was several months ago) as I recall was in cache access.
<lifeless> so, bzr serve itself is threaded.
<mkanat> lifeless: I'm just saying in general that the hangs are either a performance problem or a deadlock problem.
<lifeless> mkanat: so by perf problem you mean 'not a hang, just slow' ?
<mkanat> lifeless: I mean either, really.
<mkanat> lifeless: Oh, yes, I see what you mean. Yes.
<mkanat> lifeless: It's so slow that it might as well have hung.
<lifeless> ok
<lifeless> and the actual hangs are generally deadlocks
<mkanat> lifeless: Well, there generally aren't actual hangs.
<mkanat> lifeless: I fixed one deadlock.
<mkanat> lifeless: Also, bzr itself is not thread-safe.
<lifeless> so
<lifeless> bzr needs to be threadsafe
<lifeless>  or move to aprocess model for 'bzr serve', itself.
<mkanat> lifeless: That seemed like a pretty low priority, making all of it thread-safe to the degree that loggerhead would need.
<lifeless> mkanat: the thing is that we support 'bzr serve' so if loggerhead has an issue with bzr thread safety, so does bzr.
<mkanat> lifeless: Nobody runs a persistent bzr serve.
<lifeless> mkanat: yes, they do :) We get discussion from time to time.
<lifeless> mkanat: even if they don't, while we claim it as a supported feature...
<lifeless> mkanat: I'm not saying you shouldn't change loggerhead models
<lifeless> I'm just saying that poolie has a strong desire and incentive to have the core be solid and robust
<mkanat> lifeless: Okay.
<mkanat> lifeless: I didn't get the impression that global thread-safety across all of bzr was going to happen within the next few years.
<mkanat> lifeless: And even if you make "bzr serve" thread-safe, that doesn't make loggerhead thread-safe. bzr serve doesn't need to run the annotate code, for example.
<mkanat> At least, as far as I understand things.
<lifeless> mkanat: I'm not aware of many if any remaining unsafe things
<lifeless> mkanat: I think the right thing to do is ask poolie
<mkanat> lifeless: Okay. In any case, I don't think that multi-threaded server is a good future for loggerhead (or for any Python web app).
<mkanat> lifeless: I think that either your 1-thread solution or Spawning is probably a good way forward.
<lifeless> mkanat: sounds reasonable to me; for spawning I'd really want to know we're going to be able to jump on it when it dies.
<mkanat> lifeless: Dies as a project, or...?
<lifeless> one problem with spawning is that if the parent process has any threads, fork() becomes (sadly) dangerous
<lifeless> mkanat: the server
<mkanat> lifeless: Okay. So the parent just has to be single-threaded.
<lifeless> mkanat: yeah, which can be hard to enfoce.
<mkanat> lifeless: Well, but I have complete control over the entire application, so it shouldn't be too much of a problem.
<AfC> We run persistent bzr serve :)
<mkanat> AfC: Okay. :-) Under a high load?
<AfC> mkanat: no, not really
<mkanat> Yeah. I think loggerhead is the only high-load multi-threaded application that interacts with bzr.
 * poolie reappears
<poolie> lifeless: as i said to mkanat when i started, i don't think mpm vs internal fixes are either or
<poolie> except in the sense that you choose one of them to work on at any particular moment
<lifeless> yeah
<lifeless> makes sense to me
<poolie> having spent X amount of timing doing fixes within a single-process multithread model
<poolie> perhaps we should now alternate
<mkanat> That makes sense.
<poolie> that pyutil patch looks nice, spiv
<poolie> i haven't read it closely yet
<spiv> Oh good :)
<spiv> I was starting to wonder if it was too much of a yak shave, but the repetition of a bug-prone idiom was really grating.
<poolie> ok
<lifeless> spiv: thank you
<poolie> i'm going to try to interactively test my launchpad dkim/gpg fixes branch
<poolie> then go back to stale lock detection
<poolie> ubuntu mounted (using LABEL=) my snapshot of home, not the real home
<poolie> which made things a bit interesting
<poolie> thus my sudden disappearance
<spiv> Getting an interactive test environment running for that sounds a bit intimidating.
<spiv> Heh, tricky!
<poolie> mm it might be
<poolie> wgrant pointed me to doc/mailbox.txt
<poolie> which might be a good way to test it
<poolie> we'll see
<poolie> in theory i can tell it to just pull mails from a directory, or get a test to run from a canned mail
<spiv> *nod*
<spm> istr there's a bzr/gnome plugin that will update a desktop flag/alert that there are/aren't branches updated? Does that tool or one like it 1. access codehost bzr+ssh; 2. on a regular schedule? or more randomised? 3. thundering herd? ie all checks at once, vs randomly spread over the given period?
<spm> Or possibly something else. But evil is happening. https://lpstats.canonical.com/graphs/CrowberryLoadAverage/20100921/20100922/
<spm> it seems to be the same bunch of branches too; fwiw.
<spiv> Wow, interesting.
<poolie> is that maybe vila's bzr-gardener?
<vila> hi all
<vila> hmm, me ?
<poolie> no, not you
<poolie> hi vila
<vila> let see, I have ~350 branches I think, and it takes a while to query them all
<vila> wow, *something* is happening indeed :)
<spm> vila: yeah, not you :-)
<vila> regarding bzr-gardener, it's not optimized at all so far, but should *reduce* the load on the server ultimately by doing *less* queries
<vila> spm: so roughly the load has doubled right ?
<spm> vila: yeah
<vila> spm: was there an update around this point ? lp or bzr /
<vila> ?
<vila> crowberry == code.lp.net right ?
<spm> yup
<spm> and no, no code update
<spm> I think. checking...
<spm> no. not since the release.
<poolie> thanks for feeding my patches up spiv
<poolie> the break-lock may fail pqm, i forget
<spiv> That's ok, I'm curious to see what the failures are if there are any, and also I figure it might give news_merge a chance to show if it's working.
<spiv> Although maybe those merges cause a bunch of NEWS entries to appear under 2.3b1 that will need to be moved to 2.3b2...
<spiv> (not so much due to news_merge as due to letting branches sit unmerged for so long)
<poolie> ah it was a conflict, but not in news
<poolie> but it should be good now
<vila> spiv: yeah, that's why I gave the warning to the Patch Pilot, may be you missed it ?
<spiv> vila: apparently!
<spiv> It's not a big deal to fix them up just after they land.
<spiv> And easier than fixing them up before, thanks to the way LP reviews work :/
<vila> yeah.. we still need to fix the root problem but until then a single patch to fix the NEWS entries wfm
<spiv> An option for news_merge to force new entries to be put in the latest release seems good, except for the times when you want to change older releases (merge from 2.x -> 2.x+1, or fixing typos, etc)
<vila> spiv: I see "Simplify connect_ssh/sftp error"  in the pqm queue, great, I was about to report that babune repeatedly fail in test_bad_connection_ssh so if something is still wrong after your patch we hopefully know it soon
<vila> spiv: or allow a "floating" release so that you can insert the entries either in bzr-2.2.1 or bzr-next
<vila> or bzr-dev whatever
<spiv> vila: yeah, I'm still not 100% comfortable with it, but after sleeping on it I think the best way to get comfortable is to get it in trunk and battle-tested.
<vila> spiv: I've run it across all platforms with success as mentioned in the mp, it's better than the actual (and faulty) access to e.errno
<spiv> vila: or provide a way to override the always-add-to-newest behaviour per landing...
<spiv> Yeah, I think it's ok, I'm just still bugged by the fact that I don't understand the intent of the old code.  Probably that's because the old code was wrong :)
<vila> bzr-next *is* always-add-to-newest, if you don't use it... you don't use it :)
<spiv> Sure.
<vila> spiv: it could be that the old code was relying on a bug in the test code...
<spiv> Heh.
<vila> the comment can be read as: "We are time dependent here, let's catch it"
<vila> or rather
<vila> it may have been inspired by a time dependent behaviour
<spiv> Yeah, that's true.
<vila> poolie: I'm a bit stuck on the SRU process, bug #528041 seems to imply that I need to propose a branch (and lifeless mentioned disjoint history :-/) plus pitti replied with: "please upload"
<ubot5`> Launchpad bug 528041 in bzr (Ubuntu Lucid) "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 22, heat: 145)" [Undecided,Confirmed] https://launchpad.net/bugs/528041
<vila> poolie: both of which are close to chinese to me :-(
<vila> for the former I mean that building the same kind of branch as lifeless did is
<lifeless> vila: ?
<bialix> spiv: why not approving the patch for 2.0 as well?
<vila> lifeless: I'm lost in the dependencies between the branch you created there, the bzr stable branches and the bzr packaging branches
<vila> lifeless: oh, and I forgot the debian branches
<lifeless> vila: oh; sorry ;P
<bialix> bonjour vila!
<vila> bialix: _0/
<bialix> never seen before this acronym: aTdHvAaNnKcSe
<fullermd> 's not an acryonym, just a visual joke.
 * bialix thinks vila had too big head today
<vila> bialix: hehe, easier to decode with the caps :)
<vila> bialix: _./
<bialix> rotfl
<bialix> \o_
<fullermd> \o/ ^o^ /o_ /o\
<bialix> a gull?
<fullermd> (it's fun to stay at the...)
<vila> poolie: and on the overall releases, it seems that many things depends on the debian branches being updated, yet, I'm still unclear about which releases debian really cares about (my best guess so far is 2.1/2.2/2.3 though I think they carry only two of them :)
<poolie> vila: packages.debian.org/bzr
<bialix> heya poolie
<poolie> hi bialix
<vila> poolie: ha, cool, I've mailed the debian packagers for bzr but I'm still waiting for an answer, this is indeed part of it ;)
<poolie> vila mind you that doesn't exactly answer the question
<poolie> i guess it's 2.1, 2.2, 2.3
<vila> amazingly 2.3b1 is already there
<vila> ha, right, jelmer did that
<poolie> i wonder when natty opens, or whether it's already open
<wgrant> It can't open until Maverick's released.
<wgrant> We'd like to change that, but it's Hard.
<poolie> ah i thought so
<poolie> ok, i'm going to head off
<vila> jelmer: pingaling
<vila> GaryvdM: stop reading my thoughts
<GaryvdM> ????
<GaryvdM> Hi all
<vila> GaryvdM: Naoki just committed on bug #641557
<ubot5`> Launchpad bug 641557 in TortoiseBZR "error while trying to run command via context menu (affected: 2, heat: 12)" [Critical,Fix committed] https://launchpad.net/bugs/641557
<vila> GaryvdM: I was thinking about you and it's irritating to see you arriving just as this second as if you were reading my thoughts *again*. I told you to not do that anymore !
<GaryvdM> 1. Develop mind reader. 2 Use mind reader. 3. ????? 4. Profit
<GaryvdM> *2. Use mind reader on vila
<vila> yeah, yeah, they all say that ! That's not because I'm not paranoid that they aren't all after me !
<vila> GaryvdM: more seriously, I was updating http://wiki.bazaar.canonical.com/Releases/2.2.1, you're currently building the windows installers right ?
<fullermd> I'm paranoid.  But am I paranoid ENOUGH?
<vila> fullermd: never
<fullermd> That's just what I expected you to say!
<GaryvdM> vila: Yes - Sorry - I ment to do that, but got side tracked.
<vila> fullermd: did you notice those black helicopters *behind* you ?
<vila> fullermd: no need to turn around, they do that too so they are *still* behind you
<vila> GaryvdM: no need to be sorry !
 * fullermd nods wildly at vila.
<vila> lol
<fullermd> 's why I lay on my back.  Then I only have to worry about the black subterrines.
<vila> Oh, I'm fine on this side... mines you know
<vila> Who build the OSX installers ? Gordon ? I can't remember his IRC nick. Someone ?
<spiv> bialix: only because I didn't see it in the queue, it turns out it was the very last thing on the +activereviews page because someone else had already voted Approve
<spiv> bialix: I just changed the status to Approved for you
<knittl> what exactly is stored in a versionedfile/text-object? each line with: text of that line, author, date? or just text + revid?
<knittl> for current format if that changed over time
<bialix> vila: Gordon is doxxxx (not sure about qty of Xs)
<thumper> hey
<vila> bialix: ha right, of course, thanks !
<thumper> http://doc.bazaar.canonical.com/developers/integration.html comes from where?
<thumper> I've got a request for some extra examples for that page
<bialix> thumper: lp:bzr-alldocs
<bialix> thumper, sorry
<vila> in the source tree you mean ?
<thumper> I'd really like examples for getting a diff for a revision
<bialix> thumper: it's inside bzr.dev/doc/developers
<thumper> and a diff for a revision for a particular file
<thumper> also, how do I get a revision id from a revno?
<thumper> for a branch?
<vila> Branch.dotted_revno_to_revision_id ?
<vila> thumper: could be costly
<thumper> vila: I'm only dealing with mainline revisions
<fullermd> If it's non-dotted, there's another method, which is oodles cheaper.
<thumper> does that make it easier?
<vila> thumper: Branch.get_rev_id
<vila> thumper: in the worst case the whole ancestry graph is loaded :-/
<dlee> What's the quickest way (when no one at the server end is awake) to determine the version of an svn server?  I just read the bit about metadata pumped into svn by bzr when the upstream svn server is 1.4.
<Glenjamin> dlee: programaitcally?
<Glenjamin> it's in the footer of the webdav repo browser usually if thats good enough
<dlee> Ah, embarrassing - and yeah good enough.  I'd looked in lots of places but not with a browser to the svn path
<thumper> vila: what is the history optional param to the get_rev_id method?
<vila> thumper: no idea :) Let me see
<Glenjamin> it'd be useful if you added an example of how to turn the input from the revision option into a revision_id :)
<Glenjamin> or does it do that itself? I didn't check
<vila> thumper: shame it's not documented nor used a lot :-/ It seems to be a simple list with the revids int it indexed by revno -1
<vila> s/int/in/
<vila> thumper: but almost no callers use it
<thumper> heh
<vila> thumper: do you intend to use it a lot for the same branch or is it just one call here and there ?
<thumper> I intend to be able to walk back through history in jumps of say 20 revisions
<thumper> for display on a web page
<thumper> I could just have the revision history cached actually
<thumper> as webapp overhead
<thumper> it wouldn't be too bad
 * thumper thinks of loggerhead
<thumper> perhaps not so much of a good idea
<thumper> lets skip caches I think
<thumper> vila: primarily for page or site history for wikkid
<thumper> how do you get commit history for a single file?
<vila> thumper: the clean way or the dirty way ? :D
<thumper> actually, I might put down the laptop and watch Chuck :)
<thumper> vila: clean please
<thumper> efficient
<vila> thumper: hehe, the dirty is efficient ;)
<vila> but, well, wikkid context, so focus on single files, no dir contents involved and you always start with a known path/file-id
<vila> thumper: correct ?
<thumper> yep
<thumper> seriously though, I'm walking away ;0
<thumper> laptop is back in the office now
<thumper> and the warmth is in the lounge
<thumper> caio
<vila> thumper: ok, np, I've starting playing around with wikkid
<thumper> cool
<Glenjamin> http://wikkid.biz/ ?
<vila> thumper: more as a user but with some opinoins :)
<vila> Glenjamin: lp:wikkid
<Glenjamin> oh wow, that sounds clever
<vila> Glenjamin: yeah, thumper is :)
<GaryvdM> thumper: I've been refactoring qlog's internals. One of the things I have done is separate the cache form the state, so that it can be used more easily in a web environment (I had loggerhead in mind).
<GaryvdM> thumper: One of the things it can do is show a history view, filtered by file id.
<GaryvdM> or file ids
<GaryvdM> thumper: so it my be use full to you.
<GaryvdM> My refactored code is here: lp:~garyvdm/qbzr/log_refactor/
<GaryvdM> thumper: It's maybe to soon to use for your purposes, but please keep it in mind.
<GaryvdM> thumper: If you take a look, look at lib/loggraphprovider.py
<GaryvdM> thumper: You would cache a LogGraphProvider for the branch, and a FileIdFilter per file, and then create a GraphProviderFilterState per request.
<bialix> hey GaryvdM
<GaryvdM> Hi bialix.
<bialix> should I do the release of 0.19.2 tonight?
<GaryvdM> I don't mind doing it.
<xrmx> hello, what does this mean? bzr: ERROR: Connection error: while sending POST /bazaar/: [Errno 0] Error
<bialix> GaryvdM: please, land your latest patch
<GaryvdM> ok
<bialix> xrmx: it depends on your URL
<xrmx> bialix, bzr branch lp:wikipbx , works in my machine, does not work on a chroot
<bialix> hmm
<xrmx> bialix, chroot can ping outside world
<bialix> maybe because you need to run bzr lp-login on chroot?
<GaryvdM> bialix: Done
<Glenjamin> shouldn't do to branch
<bialix> GaryvdM: thanks
<bialix> xrmx: smells like a bug
<xrmx> bialix, my chroot is base debian squeeze plus apt-get install git bzr
<xrmx> bialix, bzr 2.1.2
<Glenjamin> can you post the ~/bzr.log ?
<GaryvdM> setting bzr lp-login would require copying you ssh key to the chroot
<GaryvdM> Ah - I think I know what is wrong...
<xrmx> Glenjamin, http://pastebin.com/8QShrp9w
 * GaryvdM finds bug
<GaryvdM> xrmx: Maybe try bzr branch http://bazaar.launchpad.net/~wikipbx-dev/wikipbx/trunk
<xrmx> GaryvdM, that works fine thanks
<knittl> what exactly is stored in a versionedfile/text-object? each line with: text of that line, author, date? or just text + revid? (latest format version if that matters)
<GaryvdM> xrmx: I think your bug has a similar cause to bug 634466
<ubot5`> Launchpad bug 634466 in Launchpad Bazaar Integration "bzr branch lp:subvertpy fails as it gets a private branch url. (affected: 1, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/634466
<GaryvdM> xrmx: Please log a bug: https://bugs.edge.launchpad.net/launchpad-code/+filebug
<GaryvdM> knittl: Disclaimer: I'm not fimilar with the internals of versionedfile. What I'm saying is based on my knowledge of the api.
<knittl> GaryvdM: that's ok. versionedfile is just an API
<knittl> and it's more than nothing :D
<GaryvdM> knittl: I think that it only stores the text.
<GaryvdM> The revid is in the reference to the versionedfile object.
<knittl> how can the text be mapped to revisions?
<knittl> let me explain shortly what i got so far, maybe you can fill in the missing bits. i'm going top down
<knittl> revision object: stores message, time, committer, branchnick, random revid (mail+time+random)
<knittl> plus a sha1 of the inventory
<knittl> and parents of course
<GaryvdM> right
<knittl> inventory maps file_ids to canonical paths
<knittl> so there is no composite pattern, an inventory cannot contain another inventory
<knittl> also stores the executable bit per path but that's unimportant compared to the other stuff
<knittl> correct?
<GaryvdM> Think so
<knittl> file_ids do not change. ever
<GaryvdM> right
<knittl> i think inventory also stores some hash of the files, but that will not matter for our simple case (without verifying content)
<knittl> so, how will an revision+inventory get the right version of the file?
<knittl> that's the bit i don't understand
<GaryvdM> I'm looking at the code for RevisionTree.get_file
<xrmx> GaryvdM, bug filed at https://bugs.edge.launchpad.net/launchpad-code/+bug/644244
<ubot5`> Launchpad bug 644244 in Launchpad Bazaar Integration "can't bzr branch lp:wikipbx from chroot (affected: 1, heat: 6)" [Undecided,New]
<GaryvdM> Revision tree knows it's revid
<GaryvdM> And we give it a file id
<knittl> so a revisiontree = state of an inventory?
<GaryvdM> That calls self._repository.iter_files_bytes((revid, fileid))
<knittl> ok, but the files have to store the revid of each line/change?
<knittl> otherwise you cannot reconstruct a particular version
<GaryvdM> Revision tree is a abstraction of a inventory, + file texts. It has the similar api to a WorkingTree, and others
<knittl> that does not really answer my question
<lifeless> knittl: the strict answer to your question is 'no, they do not'
<lifeless> there are many ways to implement that api
<knittl> lifeless: ok. then how can we reconstruct an exact version of a file for a given revision/inventory/'whatever you call it'
<GaryvdM> My understanding is that there is an index to say (revid, fileid) -> where it is stored, and where it is stored just has the text - no knowledge of the revid it's for.
<GaryvdM> lifeless know much more than me :-)
 * lifeless is going to sleep
<lifeless> GaryvdM has it right
<knittl> GaryvdM: yes. but fileids do not change. so how can you map from revid -> fileid?
<knittl> because fileids stay the same over all revisions
<knittl> if the contents of a file change, its id stays the same
<knittl> that's the part i am confused about
<GaryvdM> You start with a revid and a fileid and ask for the text. You don't start with the text, and get the revid.
<knittl> GaryvdM: yes
<knittl> you have a revision (revid) and the filename (which looks up the fileid in the inventory)
<knittl> then what? how do i get the correct version of the file?
<GaryvdM> You allready have the revid - to get the text, you can call RevisionTree.get_file
<GaryvdM> The fact that the fileid may have only been edited by a previous revision is handled by the api.
<knittl> so a file stores revids -> text?
<knittl> * a versionedfile contains multiple revisions?
<GaryvdM> I *think* a versionedfile object stores (revid, fileid) -> text
<knittl> and then maps revid -> state of file
<knittl> well, you access a versionedfile 'textstore' (?) via its fileid
<knittl> so it only needs to map revid -> text
<GaryvdM> Ok - my be wrong there
<knittl> independent of weave/groupcompress/delta/snapshot storage?
<knittl> and that is what i was saying all along: 'text' objects (versionedfile) map revid -> lines/state/text
<GaryvdM> VersionedFile is a very low level api. I'm not sure what you are trying to achive, but would recommend maybe working with I higher level api, e.g. RevisionTree
 * GaryvdM reads the VersionedFile code
<knittl> not interested in 'working with an api'
<knittl> i'm interested in the inner workings and low level storage mechanisms
<knittl> (still, because i haven't managed in weeks to fully understand and nobody in here could properly explain the bazaar object/storage model)
<GaryvdM> Ok - Then I'm the wrong person to answer - sorry.
<spiv> knittl: the low-level storage in the current format is pretty complex, aside from the revision/inventory/versionedfile abstractions that you are starting to know your way around, you need to understand packs, groupcompress and possibly the CHK maps depending on what you want to know.  And I suppose for completeness I should mention the btree indices for the stores.
<knittl> spiv: yeah, i noticed it's complex, because nobody knows it xD
<spiv> knittl: it's not so much that nobody in here can properly explain it as that to do so takes quite a bit of time :)
<knittl> spiv: but tell me, am i right with my understanding of versionedfile?
<knittl> versionedfile (accessed by fileid) stores revid -> content
<spiv> That the key into the 'texts' versionedfile is 'fileid'?  No.
<knittl> or revid -> changes (depending on the storage format)
<spiv> The key into that versionedfile is (file id, rev id)
<knittl> but a versionedfile only contains a single file?
<spiv> No.
<knittl> what then?
<spiv> The API is actually called VersionedFiles
<spiv> Plural.
<knittl> with single file i mean: all versions of a file over time
<knittl> versionedfile.py here (singular)
<spiv> Or rather the VersionedFiles class is the preferred abstraction.
<knittl> which contains multiple versionedfile objects?
<knittl> anyways, let me try again :D
<knittl> to get the contents of a file for a particular revision i'm using (fileid, revid)
<knittl> so somewhere inside file (text) storage there has to be a place to store the revid?
<spiv> None of the APIs of VersionedFiles return a VersionedFile object.  That's not the key to understanding this.
<knittl> let's not talk about concrete implemantions of that api
<spiv> I need to go in a moment, but I'll quickly reiterate what I described the other day.
<spiv> Say you have a revision, and want the contents of the file known as 'doc/manual.txt' in that revision.
<knittl> yes
<knittl> i only know of that file because it's stored in the inventory for that revision
<spiv> You have the revision already, so you know the revid.
<spiv> So you can lookup the inventory for that revision by using that rev-id as the key for the 'inventories' store
<knittl> but i don't know the filename
<knittl> yes, and from the inventory i get fileid from filename
<spiv> (or if you want to view the repository as a unified keyspace, by looking up ('inventories', rev-id) as the key)
<spiv> Then you ask the inventory object for the inventory entry for that path, 'doc/manual.txt'
<spiv> That inventory entry will have, among other attributes, a file-id and a "revision_id"
<knittl> revid is the same as the revisions revid?
<spiv> That "revision_id" might be the same as the revision id you already have, but for instance if the file hasn't changed in recent revisions it'll be some older ID.
<knittl> ok
<spiv> So you can't assume its value, you have to check the inventory for it.
<knittl> but it's a revid that can be mapped to a revision
<knittl> it's 'last changed revid' for a file
<spiv> Then you can use that (file-id, revision-id) pair as a key in the 'texts' store
<spiv> To get the bytes of the contents of that file.
<spiv> It's not 'last changed revid' necessarily.
<knittl> spiv: why not last changed? you said if it didn't change in the last revision it will be an older one
<spiv> It may often happen to coincide with that, but in fact nothing in the implementation requires it matches the ID of any stored revisions at all.
<knittl> filid+revid = content
<spiv> knittl: maybe the file contents were reverted
<knittl> spiv: so it could be any revid? not even existing? what's the sense in that
<spiv> knittl: maybe an import from a foreign system stored things slightly differently to the default implementation in bzrlib
<spiv> knittl: it's just an random, unique value â like rev-id is.
<knittl> but again i ask: fileid+revid = content. so i need to store the revid for lines of text?
<knittl> spiv: does it usually match a revision rev_id or is that unlikely?
<spiv> I don't know what "I need to store" means here.
<knittl> to be able to map from id -> content i need to store both id and content
<spiv> It usually does, but I wouldn't rely upon it.
<spiv> (it might match a revision not present in this repo, for instance)
<knittl> id in an index and content in a binary file
<spiv> What do you mean when you say "id" here?
<knittl> in that case fileid+revid
<spiv> I've described already exactly how to access the content, model-wise.
<spiv> (the exact bytes on disk are of course involve many more details)
<spiv> We call that a key
<knittl> i didn't ask about exact bytes
<knittl> filestore maps (fileid,revid) -> content?
<spiv> The 'texts' store does that, yes.
<spiv> As I'm pretty sure I've said at least three times now :/
<knittl> good. didn't i ask that ages ago?
<spiv> And didn't say that ages ago?
<knittl> and if it maps (which it does you tell me)
<spiv> s/say/I say/
<knittl> it needs to store fileid, revid and content
<knittl> right?
<knittl> that's what i want to know â¦
<spiv> What did you think I meant by "look up" and "use as a key", I wonder?
<knittl> spiv: i asked several times, and you always denied and put it in different wordings
<knittl> you said: Â»no, it blahÂ«
<knittl> i'm just confused about this overly complex system
<spiv> If I contradicted you, it's because you're using terminology inconsistently with how we use it.
<spiv> Which is only going to lead to confusion and frustration, so please be patient if I insist on being precise.
<knittl> because it's easier for me to understand 'text store stores file id, rev id, content' than to say 'bla, api, maps, key, â¦'
<knittl> i'm sorry, if i sound rude, but it's not easy to grasp all that
<spiv> 'stores file id, rev id, content' is just too imprecise.
<knittl> why? it stores all of them, and then establishes a mapping
<Glenjamin> but these are low level APIs, they're not supposed to be easy to grasp - they're abstracted away from the user/developer by APIs/UIs that are
<spiv> It doesn't suggests to me that they are stored together as a composite value, rather than that 2 of those are used to map to the other.
<knittl> Glenjamin: hg uses revlogs (easy), git uses hashes with references to other hashes (also easy)
<Glenjamin> but neither are a feature
<spiv> We'd usually say the texts store stores, well, texts, or content if you like.
<knittl> is format 2a the same as knitpack format?
<spiv> And the key for a text is the (file id, rev id) pair.
<knittl> spiv: and some index stores the ids and maps it to the store
<spiv> No, 2a is quite different to knitpack.
<knittl> where can i find docs on 2a?
<knittl> http://doc.bazaar.canonical.com/latest/developers/packrepo.html
<spiv> knittl: well, I think you can see simplifying it to "stores file id, rev id, content" is omitting important structural details.
<spiv> 2a == groupcompress packs + CHK inventories.
<knittl> where's the documentation/explanation of 2a?
<knittl> http://doc.bazaar.canonical.com/latest/developers/groupcompress-design.html 2a?
<spiv> See RepositoryFormat2a in bzrlib/repofmt/groupcompress_repo.py
<knittl> spiv: reading thousands of sourcecode lines does not help me to understand, i'm sorry. i've already read function names, comments, â¦
<spiv> That's a description of the "groupcompress" part, that doesn't cover the CHK inventories
<spiv> knittl: Well, there are docstrings that say relatively useful things like "A CHK repository that uses the bencode revision serializer."
<knittl> http://doc.bazaar.canonical.com/latest/developers/inventory.html
<spiv> Which isn't immensely helpful, but it gives some pointers.
<spiv> As does the classes it in turn references.
<spiv> Anyway, I must go.
<knittl> ok, thanks
<spiv> I'm sorry you feel it's overly complex, but fortunately or otherwise we didn't write it for your comprehension ;)
<spiv> Good luck, until tomorrow perhaps ;)
<knittl> there should be documentation nevertheless
<knittl> i want to understand the version control system i'd trust my data
<spiv> (back very briefly) So you understand exactly how your filesystem turns your data into bytes on media?  And partition tables?  ;)
<spiv> Ok, really gone :)
<knittl> no, but i understand partition tables
<knittl> and i guess there's documentation for filesystems
<knittl> which format does not change every 2 months
<GaryvdM> knittl: Thats 1. rude, 2. no longer true. 2a is more than a year old, with a commitment to stay as the default for much longer.
<vila> Hoping to get help from people by constantly bashing their work, way to go !
<knittl> GaryvdM: it was true for the past
<knittl> also i found a lot of 'in development formats'
<knittl> so i'm wondering
<knittl> vila: well, there is no 'documentationy' documentation which explains the inner workings, which i find very sad
<vila> EPARSE, I'm not an native english documentationy means ?
<knittl> vila: it's a made up adjective from 'documentation'
<knittl> for me comments in source code do not count as documentation
<vila> then we don't have a documentation suited to your needs
<knittl> â¦ which i find very sad
<vila> we know that
<vila> (both that we don't have this documentation and that you're sad)
<knittl> yes, i said it twice already
<Hydrox> is there at least a plan to add documentation?
<vila> oh of course there is a plan
<vila> see https://bugs.edge.launchpad.net/bzr/+bugs
<vila> 2000 are open, 200 of high priority, now is that plan part of these 200 ? I'm not sure
<vila> This is a GPL project, everybody is welcome to scratch his own itch, and a lot of people are... without this documentation so far
<vila> Don't get me wrong, I asked the same question very early after joining the project thinking it will help me to start quicker
<knittl> vila: i could only write documentation if i understood the internals
<vila> Well, I didn't start quicker but that wasn't a blocking factor either
<vila> knittl: I didn't ask you to
<knittl> didn't say that
<Hydrox> vila, do you write documentation about the things you add to bzr (other the code comments)?
<vila> Hydrox: when needed yes, most of my time is spent fixing bugs though, so generally it means making the code respect what the doc says ;-)
<vila> Hydrox: most of our doc is also targeted at users, mozt of the bzr hackers hang around here and on the mailing list where most of the internal knowledge is shared via discussions, merge proposals, etc. Nobody felt the need to summarize to put that into proper documentation, but any start will certainly be warmly welcome
<vila> jelmer: Pingaling
<rocky> jelmer, hey are you following setuptoolsbzr at all ?
<Fuu> nice, bazaar install crashed windows explorer :)
<vila> Fuu: file a bug mentioning versions (OS, bzr, etc), that's unheard of AFAIK
<Fuu> i'll do that
<Fuu> it wasnt why i came here though, just joined before even attempting to install :)
<vila> Fuu: you're welcome in all cases ;)
<Fuu> thank you
<jelmer> vila: hi
<jelmer> rocky: hi
<vila> jelmer: hey !
<jelmer> rocky: no, what about it?
<vila> jelmer: so my ping was about the new bzr releases and their impact on debian
<vila> jelmer: I see you already packaged 2.3b1 and I'm wondering what else needs to be done
<vila> jelmer: 2.2.1 for sid, 2.1.3 for squeeze and 2.0.6 for lenny-backports ?
<vila> jelmer: I'm not a debian expert, just reading: http://packages.debian.org/search?keywords=bzr :-D
<vila> jelmer: and also, may be more important, are the debian branches in sync with the packaging branches on lp ? Do they share the same history ? etc
<vila> jelmer: and before I ask for the ponny, feel free to update http://wiki.bazaar.canonical.com/Releases/2.2.1 (and 2.0.6, 2.1.3 and 2.3b1 though I already updated the later)
<vila> jelmer: where is my ponny ?
<ara> hello all!
<ara> I am getting this error when pushing a new branch:
<ara> > Using default stacking branch /~ubuntu-qa-website-devel/ubuntu-qa-website/trunk at lp-97781328:///~ubuntu-qa-website-devel/ubuntu-qa-website
<ara>  bzr: ERROR: KnitPackRepository('lp-97781328:///~ubuntu-qa-website-devel/ubuntu-qa-website/trunk/.bzr/repository')
<ara>  is not compatible with
<ara>  CHKInventoryRepository('lp-97781328:///~ubuntu-qa-website-devel/ubuntu-qa-website/wordpress-theme/.bzr/repository')
<ara>  different rich-root support
<ara> any ideas?
<jam> ara: one of them is in 0.92 format, the other is in 2a format, which are not directly compatible. (upgrading to 2a is a one-way upgrade)
<jam> it looks like trunk is in 0.92, and the one you are trying to create is in 2a
<jam> either:
<jam> a) Get trunk to upgrade to 2a
<jam> b) rework so that you're local stuff is in 0.92, and then push that to a new branch
<ara> how do I a)
<ara> ?
<ara> bzr --upgrade 2a?
<jam> ara: "bzr upgrade --format=2a lp:ubuntu-qa-website"
<ara> jam, thanks a lot!
<jam> (though --format=2a is now the default for upgrade)
<ara> the process crashed :(
<ara> http://pastebin.ubuntu.com/497788/
<ara> I can report the bug, if it is interesting
<fullermd> I believe that's a bug in 2.2.0, fixed in 2.2.1.
<ara> fullermd, can I use a bzr daily build to test?
<fullermd> If it's new enough, I guess.  It's probably just as easy to use 2.2.1 though.
<maxb> 2.2.1 isn't in the PPA yet, so a good option might be to branch the release branch and build it
<maxb> bzr branch lp:bzr/2.2 && cd 2.2 && python setup.py build_ext -i && ./bzr whatever
<jam> ara, fullermd: I just changed and https://edge.launchpad.net/~bzr/+archive/proposed
<jam> seems to say that the packages haven't been uploaded yet
<jam> ara: is this your personal project ? (you have direct admin access?)
<ara> jam, I do have admin access
<jam> if you want to join me to the group, I can upgrade it for you, and then leave group
<ara> jam, OK, is jam your lp id?
<jam> jameinel
<ara> jam, added
<jam> ara: working on it
<ara> jam, thanks!
<jam> ara: hmmm it is giving me permission denied errors
<ara> jam, weird, as the owner is ubuntu-qa-website-devel and you are now part of it...
<jam> yeah, but I'm getting the same error elsewhere, still investigating
<jam> ara: I'm guessing it might have had something to do with the new URLs that thumper worked on (bazaar.launchpad.net/+branch/ubuntu-qa-website vs ~ubuntu-qa-website-devel/ubuntu-qa-website/trunk)
<jam> I don't know that for sure
<jam> but I got it working
<ara> thanks!
<jam> ara: I'll let you know when the upgrade finishes
<ara> jam, cool :)
<jam> ara: looks to have completed
<ara> jam, thanks a lot, will try now the push
<jeremyw> Hello all.
<ara> jam, it worked, thanks!
<jam> ara: happy to help
<jeremyw> I'm writing a thing wrapper to some choice VCS systems and I'm wanting to add Bazaar support to my application.  I've read the integration wiki page but one thing it doesn't talk about is repository creation.
<jeremyw> I'd really like to understand the moving parts a little better.  Anyone got a minute to help me understand what a bzr repository is composed of?
<jeremyw> Basically, I'll be creating server-side repositories that will only be accessed via a network server and NEVER locally.
<Glenjamin> jeremyw: is your wrapper for the client or the server?
<fullermd> jeremyw: Be sure you're ascribing the right level of meaning to 'repositories'...
<jeremyw> Where I've gotten to at this point is I've found bzrlib.builtins.cmd_init_repository.run().
<jeremyw> fullermd: That's what I'm learning is that I think my terminology is different than what bzr uses.
<Glenjamin> i think you actually want a bzrdir
<jeremyw> Glenjamin: This would be a library uses on the server for things like repository creation and repository browsing.  For simplicity, let's just pretend I was writing a repository browser.  (That being said, please don't try to get me to use XXX repository browser as this is just an example scenario.)
<jeremyw> Glenjamin: Yeah.  I see that being used in the function mentioned above.
<Glenjamin> but repository browser XXX is great! D:
<jeremyw> haha
<jeremyw> Glenjamin++
<fullermd> I always worry about projects to create wrappers like that.  It's sure to wind up being an ugly force-fit to one system or another...
<jeremyw> Well, this tool needs to create repositories that can be accessed remotely by users but also accessed locally via my API to do things like creating the repository browser.
<Glenjamin> jeremyw: http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/core_concepts.html
<jeremyw> fullermd: Well, I'm trying to do less wrapping and more direct bzrlib usage.
<Glenjamin> admittedly its not exactly clear on repositories
<jeremyw> Right now, I just subprocess.Popen to "bzr init PATH".  ;)
<Glenjamin> if speed isn't an issue, thats likely to cause the least surprises
<jeremyw> Glenjamin: That's what I'm seeing right now...everything I've seen (docs/examples/etc) barely talk about repositories.
<Glenjamin> basically, bazaar doesn't have the repository concept in the same way as other VCSes
<fullermd> I mean wrapping in a conceptual sense.  In svn, frex, you have to take a lot of care where you put a repository, because you can't do anything outside of one, and can hardly to anything between them.
<jeremyw> Glenjamin: Well, I'd still rather do this in a Pythonic way so I'll likely use bzrlib.builtins.cmd_init_repository.run() but I'm wondering if that is ideal/performant.
<Glenjamin> a repository is simply somewhere revisions are stored, normal branches just have their own repo
<jeremyw> fullermd: Understood.
<fullermd> Whereas in bzr, it's totally different.  Meanwhile, in bzr, you have a branch granularity you center around, whereas in svn-land branches practically don't exist, and you deal with semi-arbitrary subdivisions of the repository.
<Glenjamin> in most cases, the repository concept in other VCSes maps to a bazaar branch
<Glenjamin> sort-of
<jeremyw> That's what rockstar was telling me.
<Glenjamin> i think that calling bazaar commands is likely to be the safest option, maybe going one level down and using the API the command wraps
<Glenjamin> but no lower
<jeremyw> Cool.  Now if I wanted to understand these terms a little better and how they interact, where should I start?
<vila> from fullermd wiki page I'm searching vainly for a few minutes
<Glenjamin> I'm only really familiar with the concepts from using it i think
<jeremyw> I'm reading that wiki page and the integration page.
<fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<fullermd> The Length-ier discussion linked at the bottom has some inter-VCS comparisons at the end too, which may be useful.
<vila> yeah, this one, damn ff
<jeremyw> fullermd: Thanks man.  I appreciate it.
<Glenjamin> are there other articles like this? I'm about to introduce 40 or so students to bazaar with a centralised smart server next week
<Glenjamin> in previous years we gave them svn+tortoise, and i want something less rubbish.
<jeremyw> I agree that wrapping vcs is usually bad but my project practically requires it.  I have a tool that will support N VCS systems so I need a way to do this stuff programmatically.
<fullermd> Glenjamin: I've got those SpotDocs covering general concepts (which I still need to do some weed-whacking on the editing of), the interactions of push/pull/merge/etc, and how the rev numbering and history structuring affects things.
<fullermd> If my tuits would stop being all rectangular...
<jelmer> vila: sorry, I was interrupted bny breakfast
<vila> jelmer: sure, and since it was a long one, you had to take a nap :-D
<jelmer> vila: >-)
<vila> jelmer: kidding :)
<jelmer> vila: What are the lp branches you were referring to?
<fullermd> Mmmm...   nap...
<jeremyw> fullermd: By a quirk of history and naming, that whole conglomeration (Repository, Branch, and Working Tree) is often colloquially called a "branch".
<jeremyw> Loving it.  :)
<vila> jelmer: the lp:ubuntu/xxx/bzr
<fullermd> jeremyw: In retrospect, sure, it's lovable.  When I started using bzr, and vented some epic ranting about it on #bzr, not so much   :p
<vila> jelmer: well, the lp:~bzr/unbuntu/<distro>/bzr to be precise
<jelmer> vila: No, they're different. lp:debian/xxx/bzr would be the ones matching those on bzr.debian.org, except they have the same contents but different revision data
<vila> jelmer: argh
<vila> hence my question :-/
<jeremyw> fullermd: Well, I was speaking more about how that summed up what you were saying in here.  :)
<jelmer> vila: james_w might be able to fix that
<jelmer> james_w: ^
<vila> jelmer: fixing as in updating/rewriting the debian branches ?
<jelmer> vila: making the lp:debian/ branches use the ones from bzr.debian.org directly rather than having it create them from scratch based on the source packages
<vila> jelmer: ha, right, yeah good first step, but the disjoint history will remain.
<vila> jelmer: and which bzr releases are supposed to find their way in the debian world ? 2.3b1 has, but what about 2.2.1, 2.13 and 2.0.6 ?
<vila> 2.1.3, I don't care (yet) about 2.13
<fullermd> I do.  Can I have 2.13 right now plz?
<vila> fullermd: bzr pull --from-future lp:bzr/2.13
<vila> fullermd: you may encounter ENOTIMPLEMETEND though...
 * jeremyw expects to be a bzr expert after reading these four pages...
<jeremyw> ;)
<fullermd> bzr: ERROR: exceptions.ReversedEntropyArrow
<roryy> bug 202374 might actually be easy \o/
<ubot5`> Launchpad bug 202374 in Bazaar "pull and update should accept --show-base (affected: 0, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/202374
<roryy> except for the tests, maybe, and all the error checking
<roryy> oh well
<vila> fullermd: ha cool, so --from-future has been implemented, the error you're seeing should be shallow
<fullermd> Oh, very shallow, if you perceived it from 4 dimensions.  Just infinitely deep in 3   :p
<vila> get new glasses :-D
<vila> I heard good things about 3D ones.. should work there too I'm sure (otherwise they wouldn't be talking so much about them)
<fullermd> What, you suggest Klein bottle lenses?
<vila> yeah
<fullermd> Well, it would be a unique look, I guess.  The chicks would dig it.
<vila> dogs too
<maxb> jelmer: So, for the immediate series of releases, should I wait until 2.2.1 lands in a debian branch before I do the PPA packaging, or should I go ahead with the PPAs anyway?
<fullermd> jeremyw: Well, that's the goal   :)   Understanding the foundations, working out what various commands yield, or what should be done to achieve a given end-state, _should_ (at least in theory) be a fairly straightforward exercise.
<fullermd> jeremyw: And those pages are a (sadly time-limited) attempt of mine to lay out those bricks.
<vila> maxb: my gut feeling is that you should go ahead, but we need a better short/middle/long (dunno) term solution
<maxb> oh urgh
<maxb> the bzr ppa brances are a complete mess
<maxb> The debian packaging history and the udd parallel import have been merged together
<vila> maxb: which means you can merge from debian branches but ignore everything except the debian dir ?
<vila> maxb: or worse ?
<maxb> which means the history is an evil incomprehensible mess
<vila> maxb: ha :-/
<vila> maxb: dir you tried bzr qlog bzr-* ? It helps a bit
<maxb> Also, the debian experimental branch contains a .bzrignore.THIS.THIS file, which is just silly :-)
<vila> operator error :-/
<vila> maxb: bzr qlog bzr-maverick bzr-lucid bzr-karmic bzr-jaunty bzr-hardy
<vila> maxb:  ^ is not *that* bad
<maxb> is just about bearable, yes
<maxb> not what I'd call pleasant, though
<vila> maxb: yeah :-/
<maxb> Hmm, I definitely need to talk to jelmer, as he seems to have switched from using bzr merge to using bzr merge-upstream for branch maintenance with 2.3b1
<maxb> Is there a quick way to test if two branches have any revisions in common?
<vila> maxb: ok, let me know if you're blocked or need anything, I'm about to EOD but I may pass around later
<dash> maxb: /join #tmlabs
<vila> maxb: just a sec
<dash> maxb: oops
<dash> wrong button
<dash> maxb: bzr missing will tell you
<maxb> dash: I don't want missing, I want bzr not-missing :-)
<dash> heheh
 * fullermd . o O ( bzr gnissim )
<maxb> Also I want people to have not applied different merge structures to the hardy ppa branch vs the maverick ppa branch
<jeremyw> fullermd: I apprecite it.
<fullermd> jeremyw: Were they helpful?
<jeremyw> fullermd: I just got out of the shower.  I'll be reading in about half an hour.  I'll let you know.  Will you be here for a bit?
<fullermd> (unfortunately not really aimed directly at your problem, but ...)
<fullermd> Oh, good.  My writing hates stinky people   8-}
<fullermd> I'll probably be around for a little while, yah.
<jeremyw> No sweat...you're not on the hook or anything.  Just hoping not to miss you when I give my feedback.  ;)
<fullermd> Well, I'll be in IRC even if I'm snoozing up a storm, so I'll have it in logs if nothing else.
<fullermd> (if I logged out, who knows what vila would say about me behind my back...)
<GaryvdM> fullermd: That's why I wget and grep irclogs.ubuntu.com...... ;-z
<shakaran> Hi, I did "bzr bind lp:myproject" now my bazaar repository works like subversion (centralized mode). I want revert to distributed mode, how to make it?
<LeoNerd> bzr unbind
<shakaran> just that? I have many member on the team, Should they have bzr unbind too?
<LeoNerd> bzr unbind  undoes the  bzr bind   operation
<LeoNerd> It's a setting on your particular branch. If they have a checkout/branch of their own, theirs is independent of yours
<shakaran> thanks LeoNerd
<ellimistd_> How can I download a specif old revision from launchpad?
<ellimistd_> *specific
<mwhudson> ellimistd_: bzr get <branch-url> -r $old_rev
<ellimistd_> great, thanks
<maxb> jelmer: Hi, are you around? (wanted to talk about debian packaging)
<jeremyw> fullermd: Just finished reading your docs...they helped a lot.  Thanks.
<jelmer> maxb: hi
<jelmer> maxb: somewhat
<maxb> jelmer: hi. I'd like there to be a branch which I can use as a basis for PPA packages of 2.2.1, but so far I've held off preparing a 2.2.1-1 for sid and asking for sponsorship, on the basis that it's probably easier for someone to just do, than to review
<maxb> What's your thoughts on that?
<maxb> Also, I note that with 2.3b1, it looks like you've changed to using 'bzr merge-upstream' to integrate new upstream versions into the packaging branches for Debian
<maxb> Also, what's the general criteria on Debian pkg-bazaar membership, and would it make sense for me to request membership if I'm working on this sort of stuff?
<jelmer> maxb: A sponsorship request for sid would be futile - squeeze is frozen
<jelmer> maxb: Yeah, you're more than welcome to join the pkg-bazaar team
<maxb> sid is already ahead of squeeze
<maxb> Therefore I assumed sid was being kept up to date regardless of the freeze making it less important than usual
<jelmer> maxb: That's because of unfortunate timing - I uploaded to sid less than 24 hours before squeeze was frozen.
<maxb> aha
<maxb> In that case, is there intent to put 2.2.1 into sid, or will we now leave sid alone until squeeze has released?
<poolie> hello maxb, jelmer
<jeremyw> fullermd: ping
<vishy> I did 'bzr init' and then i create branches via bzr branch, which creates a subdirectory.
<vishy> I accidentally did a bzr pull <branch> in the parent directory
<vishy> any way to revert it?
<vishy> bzr revert doesn't seem to do anything
<maxb> 'bzr init' creates a new empty branch. 'bzr branch' creates a new branch copying from somewhere else. Doing what you said suggests you may have some confusion between 'bzr init' and 'bzr init-repo'
<vishy> maxb: ah
<vishy> i think you are correct
<vishy> maxb: thanks for the help
<jeremyw> Let's pretend I was a hosting company for Bazaar.  If I understand correctly, 'bzr init-repo' will create a directory that will contain branches.  'bzr init' will create a directory that is a branch.  It seems the former would let the users of the repository create/use as many branches as they want/need while the later will only allow one branch.  Is this correct?
<jeremyw> The more I think about it, the less it makes sense but I had to ask.
<mkanat> jeremyw: Yep, you're right.
<ddaa> jeremyw: well that's a way of seeing it
<ddaa> bzr init-repo creates a shared repository
<ddaa> bzr init (and bzr push, bzr branch, etc.) create a branch, if the branch is located in a shared repo, it will use the history store of the shared repo, instead of using a branch-specific store.
<ddaa> IMO, whether you allow creation or one or multiple branches is not a property of init-repo
<ddaa> However, using a shared repository has a strong impact on access contral.
<jeremyw> I'm learning here so bear with me.  I think the analogy of me being a Bazaar hosting tool makes the msot sense.  The usage pattern I see is: You create a repositroy on the server and N number of users will access this repository by cloning it and pushing to it.
<ddaa> well
<ddaa> strictly speaking, in bzr you don't clone a "repository"
<jeremyw> Well, you clone a branch.
<jeremyw> So if I wanted to allow a repository to have N branches, I'd need a shared repository right?
<ddaa> yup
<ddaa> that's what shared mean
<ddaa> "shared history store for multiple branches"
<ddaa> not "shared by multiple users", that's an orthogonal kind of sharing
<jeremyw> I got you.
<ddaa> as a commercial hosting, you could also use stacked branches, and a custom bzr+ssh server that optimize new branch uploads without giving write access to everything to every user
<ddaa> actually, that's exactly what launchpad does :-)
<jeremyw> Nice...that's something I'll look into as well.
<jeremyw> Well, I don't plan on being a Bazaar host but at the same time, the needs of my project were easier to explain that way.
<ddaa> well, there's definitely a niche for "github for bzr"
<ddaa> launchpad is too complicated and featurful/confusing for some people
<jeremyw> When you have a shared repository, is there still a default branch?
<ddaa> default branch?
<ddaa> there's no such thing in bzr
<jeremyw> Well, 'bzr init' creates a default branch doesn't it?
<ddaa> no, it creates a branch
<ddaa> I have no idea what you mean by "default branch"
<jeremyw> Oh yeah...it's named the same as the parent dir.
<jeremyw> Doh.
<jeremyw> ddaa: I'm probably mixing terms here.  My fault.
<ddaa> well no, it's named the same as the directory of the branch
<ddaa> because well, that's what the name of a branch is, the url of its directory
<jeremyw> That's what I meant.  Sorry.
<ddaa> and no, bzr init-repo does not create branch at the root of the repository
<ddaa> you could probably set up something like that, and it would probably work, but I'm not sure you can even achieve it using the command line, without moving stuff in and out of .bzr by hand
<jeremyw> I wonder if a shared repository is necessary.  Let's say I created a repository the same way 'bzr init' did.  I could create another repository the same way and fill it with the contents of another branch riht?
<jeremyw> So I wouldn't need to have a shared repository.
<ddaa> yeah, we call that a "standalone branch"
<ddaa> that's a branch with its own non-shared .bzr/repository
<ddaa> the key object in bzr is the branch
<ddaa> repositories are just support for branches
<jeremyw> But you can still create a branch from another branch.
<ddaa> why "still"?
<ddaa> a shared repo is never necessary
<jeremyw> Too many concurrent conversations.
<ddaa> it's just a nice optimization
<jeremyw> I got you.
<jeremyw> Cool.
<jeremyw> Well, this has been enlightening.
<jeremyw> ddaa: I appreciate explaining things to me.
#bzr 2010-09-22
<ovnicraft> hi folks, i branch a project from lp i made my changes, commited now i try to pull from lp and tell:
<ovnicraft> bzr: ERROR: These branches have diverged. Use the missing command to see how.
<ovnicraft> Use the merge command to reconcile them.
<maxb> Indeed. You don't want to pull, in this case
<ovnicraft> so pull is not the way to update from lp
<ovnicraft> maxb, that is what i want, what i need to do?
<maxb> "Use the merge command to reconcile them."
<maxb> bzr merge
<ovnicraft> maxb, i dont have write permissions in lp that is not a problem?
<maxb> no
<wallyworld___> bzr 101? - if i have a branch and merge from trunk, can i commit just those changes and not my own as yet uncommitted ones so that bzr status shows just my in progress changes and not everything?
<maxb> No. bzr merge will remind you that your working tree has changes when you try to merge
<maxb> Either commit or shelve your local changes first
<maxb> Or branch your branch, merge in that, and pull the result back into your first branch
<wallyworld___> shelving may be the go. i want to keep current with trunk but am not ready to commit my in progress work
<wallyworld___> thanks
<wallyworld___> seems like a bit of a pain though. is the workflow i am wanting considered "unusual"?
<wallyworld___> coming from a svn world, it seems normal to do that sort of thing :-)
<LeoNerd> I use shelve a -lot-
<LeoNerd> To the point that when I was still being required to use CVS at one workplace, I wrote myself a  cvs-shelve  command :)
<maxb> There's no real workflow difference from svn here
<wallyworld___> yes, it's a useful feature, especially with good merge support in the VCS. not sure how well it would work with CVS :-)
<maxb> or, had you not ever committed since branching? In which case, pull, don't merge
<wallyworld___> no, i had committed.
<wallyworld___> with svn, you don't have to first shelve before updating from the central server
<maxb> In svn if you wanted to merge from trunk whilst having uncommitted changes, you'd need to "shelve" the changes off as a patch file first
<wallyworld___> so to me there is an extra step with bzr
<wallyworld___> i've never had to do that with svn - i just update and all the changes from trunk come down and a "status" just shows my uncommitted changes as expected
<dash> wallyworld___: sure, but this is about merging not updating
<dash> wallyworld___: merges change your working copy
<dash> (in both bzr and svn)
<maxb> wallyworld___: If you were in the same situation in bzr, you would pull, not merge, and you'd get the same result
<wallyworld___> would you still pull even if you had uncommitted changes? doesn't it complain?
<dash> it doesn't
<dash> for the same reason svn doesn't
<wallyworld___> ah ok. i thought that it did. sorry.
<wallyworld___> thanks for the input, much appreciated
<spiv> Good morning.
<poolie> hi spivvo
<spiv> Hi poolie, I just had a bit of a tour of the wonderful world of generating sphinx docs from optparse.  https://code.edge.launchpad.net/~spiv/bzr/html-cmd-help/+merge/36244
<mkanat> poolie: I didn't get to loggerhead today, just FYI. Perhaps tomorrow or Thursday. I did start to do some research yesterday, though.
<mkanat> poolie: Just wanted to let you know so that I wasn't going dark on anything. :-)
<mkanat> Anyhow, I'm out for the evening! :-)
<mkanat> Night. :-)
<ovnicraft> hi folk i have a question i can versioning my documents with bzr?
<spiv> ovnicraft: yep!
<ovnicraft> spiv, so bzr can show in 'rich text' the diff ?
<spiv> No, if it's not plain text bzr will just say "binary file changed" for that file in the diff.
<ovnicraft> spiv, assuming an Ooo doc from writer is a zip bzr knows how works with work?
<spiv> And similarly it can't automate merging.
<ovnicraft> i need something like that
<spiv> So bzr can happily store the different versions of binary files, but it can't help you compare them.
<spiv> (Unless someone writes a bzr plugin for that kind of file)
<poolie> spiv, wow, that specific check for '1.9' is gross
<jbowtie> Hmmm, a bzr plugin for diffing archives would be interesting; especially if you could treat archives as folders.
<poolie> meaning ppa archives?
<poolie> or zips?
<jbowtie> poolie: Meaning zips
<jbowtie> There are plenty of file formats (including ODF) that are just zips of some files; being able to diff them would be handy.
<jbowtie> Actually, being able to merge them would be even better.
<spiv> The hook point for merging them already exists.
<spiv> So it's just a simple matter of writing the plugin then ;)
<jbowtie> Actually I thought it might be more fun to write a plugin to allow merging of GIMP/Photoshop formats.
<jbowtie> As long as the changes are on different layers you can actually do a conflict-free merge.
<spiv> Heh, that would be cute.
<poolie> heh
<poolie> i don't know how often that happens but it would be cute
<jbowtie> But that's just a blue-sky project until I knock the documentation bug count down to zero.
<poolie> you know showing conflicts as layers might even kind of work too
<poolie> jbowtie: thanks so much for all your patches
<poolie> you're getting through them at a great rate
<spiv> poolie: Ooh, layers called THIS, BASE, and OTHER? :)
<jbowtie> Well, artists are always complaining about not being able to version using a DCVS. But the collaboration workflow actually usually has them touching different subfiles within some massive binary zip.
<spiv> *nod*
<jbowtie> poolie: It's for my own sanity as well; hate looking something up and having it be wrong.
<jbowtie> So being able to support layers or (in the case of Blender, animations versus meshes versus textures) would address some of those artist issues.
<jbowtie> But that involves working with the various free software art tools to come up with useful diff/merge/conflict resolution.
<spiv> Right.
<spiv> It would be a neat project.
<spiv> It would possibly also encourage us to keep improving our performance when dealing with large files...
<poolie> spiv did my 'scripts' branch fail?
<spiv> poolie: text conflict in NEWS...
<poolie> huh
<spiv> poolie: but not when I try locally with news_merge enabled
<spiv> So I guess PQM still doesn't have news_merge working :/
<lifeless> spiv: probably need to upgrade bzr
<spiv> poolie: https://pastebin.canonical.com/37408/ is how news_merge was configured on PQM
<lifeless> spiv: it runs from a source tree
<lifeless> hysterical raisins
<spiv> lifeless: the RT had step 0 as checking that bzr was already upgraded
<lifeless> spiv: the one in the source tree?
<spiv> But yes, there's enough confusing wrinkles in the PQM deployment that this sort of thing never goes smoothly :(
<spiv> lifeless: I don't know, I don't have access to see
<spiv> lifeless: it was RT #41382, if that helps you
<poolie> spiv, i'll update and repush it
<spiv> poolie: Hmm
<spiv> poolie: it's kinda nice to have the test for whether news_merge is working ;)
<spiv> But not worth holding up your branch unless that's likely to be fixed soon.
<spiv> I'm not sure what to do about it... I don't feel I have enough information to construct an RT to correct whatever is wrong.
<spiv> And I assume LOSAs would rather not receive "it doesn't work, please fix" RTs any more than we like them as bug reports :)
<spiv> Making any changes to the PQM deployment always feels about 10x more frustrating than seems reasonable :/
<poolie> iirc it's a useful but not critical patch
<poolie> so, there's no rush
<spiv> Right.
<poolie> hm
<poolie> i'm suspecting we might be better off prototyping tarmic
<thumper> hi
<poolie> *tarmac
<thumper> does the BZR_EMAIL for committer id need to be "email shaped"?
<thumper> or can it be any string
<spiv> thumper: andrew@Aihal:/tmp/a-branch$ BZR_EMAIL="any string" bzr ci -m "Foo." --unchanged
<spiv> Committing to: /tmp/a-branch/
<spiv> Committed revision 1.
<thumper> spiv: is there an expectation that it is email shaped?
<thumper> will there be a future tightening of the constraint?
<thumper> could there be a future tightening/
<thumper> ?
<spiv> I don't think so.
<thumper> thanks
<spiv> I'm pretty sure there'd already be not-email-shaped commits in the wild
<spiv> e.g. imports from CVS
<jbowtie> Just found out Rob Collins is also from NZ. I wonder how many mutual acquaintances we have?
<jbowtie> Sorry, guys, that was meant for Twitter.
<spiv> jbowtie: that's ok
<jbowtie> You say that now, but next time it'll be something far more embarrassing.  :)
<jtv> jbowtie: at least IRC doesn't spread XSS attacks quite so well
<jbowtie> jtv: I'm safe until they target Gwibber. Then all my networks are toast.
 * jtv gets the butter and prepares to wait
<poolie> it's funny how much twitter reinvents irc
<jbowtie> If I push a fix to a branch that has been proposed for merge, do I need to do anything else for reviewers to take note of the fact?
<poolie> uh kinda
<poolie> it shows up on the web page
<poolie> normally that's enough
<spiv> jbowtie: the diff on the web page will be automatically updated, but the reviewers won't get notified
<poolie> if you want to specifically ask, you have to mail the mp
<spiv> So add a comment if you want to to draw attention to the update.
<jbowtie> spiv: You answered the question before I finished typing it.
<spiv> You can also resubmit, which starts a fresh review.
<spiv> For small changes in response to a review so far I'd usually just add a comment.
<spowers> i'm transitioning my brain from svn to bzr right now.. what's the bzr equivalent of svn postcommit hooks?  i push from my laptop to a server, want the server to execute something when i push to it
<spiv> Ugh, my html-cmd-help fix broke test_help
<spiv> spowers: there's a post_change_branch_tip hook in the API
<spiv> Unfortunately you can't just put a command in a configuration file, but you can use it by writing a simple plugin.
<spiv> (Hmm, ISTR to recall I had an prototype of a plugin that could run a command from a config file when that hook fires, I should dig that up)
<spowers> it sounds like people have found other ways to solve the same problem?
<spowers> after i push to the server, i need to have it kick apache
<spiv> Well, many people just want email notifications, and there's already a plugin for that.
<spiv> For everyone else... well, as I say, it's not difficult to write a simple plugin.
<spowers> ok, i'll look into that
<spowers> there are client side hooks too, right?
<spiv> Yes, the exact same ones.
<spowers> that's probably all i need.. i have ssh keys set up, so i could just flip a switch via ssh
<poolie> good morning vila
<vila> poolie: morning poolie !
<vila> hi all !
<vila> poolie: quick chat ?
<poolie> sure
<poolie> vila, i wonder if a registry is a good fit for this because to me they seem very oriented to looking up a single thing by name
<poolie> whereas this is more of a multiple dispatch deal
<poolie> however i agree, we probably want to somehow combine various relevant sources
<vila> right, so the idea is that the registry will change the way we get our config objects from calling BranchConfig or GlobalConfig explicitly to calling get_config('branch')
<vila> from there it becomes possible to define what a branch config is or what a tree config is without being forced to create a new class
<vila> the idea of multi-level configs is that if one config doesn't define a variable, we fall back to another config
<vila> this should scale pretty well for the user once we provide a 'bzr config' command that will tell *where* a variable is currently defined
<vila> and also *which* config files are involved for a given variable
<vila> this file <-> variable relationship may need to better specified too, as currently *some* variables should not be overridden
<lifeless> I thought we already had multi level configs
<lifeless> via a composite pattern
<vila> lifeless: we have
<lifeless> good good
<spiv> There's also some code in bzr-pqm along those lines, IIRC
<vila> I'd like to replace the composite approach by a more generic list based approach where you just say branch.conf > locations.conf > bazaar.conf
<spiv> --ignore-local needed it for some reason
<spiv> vila: it's been a while, but that sounds rather like the code in bzr-pqm
<vila> to allow tree.conf > branch.conf > repo.conf > locations.conf > bazaar.conf and allow plugins to put whatever they see fit wherever they see fit
<vila> but we need some way to also define that a variable *cannot* be redefined in some cases
<spiv> vila: http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel/annotate/head%3A/pqm_submit.py#L198
<vila> spiv: exactly, thanks for finding the relevant url so fast !
<spiv> vila: see #L226 for where it is used
<vila> so, one example of a variable that we don't want to redefine may be the stacked_on url which is defined server-side (may be not the best example but you get the idea)
<spiv> vila: I'd wanted to get that put into core bzrlib, but lacked a motivation other than "it'd be nice"
<spiv> There's also some security concerns, in that using an untrusted branch shouldn't be able to e.g. configure bzr, or a bzr plugin, to rm -rf /.
<vila> spiv: yeah, exactly, you needed a new class *and* various calls to achieve: get_config('branch')
<vila> spiv: right, that should be defined at the *variable* level
<spiv> Yes, probably.
<vila> spiv: may be not specified for evey variable but what I have in mind is the ability to *declare* a variable in config and use various decorators
<spiv> Sounds like a good approach to me.
<vila> in config or elsewhere, in fact, the discussion with poolie was to make it trivial to turn any constant in the code base into a config variable
<spiv> vila: actually the motivation I did have for maybe putting StackedConfig in core is it possibly would simplify bzrlib/config.py a bit, because the general facility it provides might simplify some hard-coded "this config asks this other config" logic.
<vila> add the '-O' option from the command line and we get the ability to try various tricks
<vila> spiv: yup
<vila> ok, so I'll see what first step I could propose, any thoughts ? A first 'bzr config' showing the variables values and where they are coming from, plus a way to set a new value or delete a variable may be ?
<vila> argh reboots needed everywhere, bbiab
<spiv> The first half of that sounds like a fairly small and worthwhile step, the second half ("plus a way to set...") sounds a bit large, perhaps.
<vila> well, no, not yet, but soon
<vila> spiv: ok
<spiv> But try it and find out :)
<spiv> (That's just a quick reaction, not a deeply considered opinion)
<spiv> Hmm, it's getting late.
 * spiv -> dinner
<vila> spiv: enjoy ! Thanks for feedback
<jbowtie> Bug #636712 says we shouldn't be recommending sftp
<ubot5`> Launchpad bug 636712 in Bazaar "docs shouldn't recommend sftp (affected: 1, heat: 41)" [Medium,Confirmed] https://launchpad.net/bugs/636712
<Glenjamin> isn't sftp recommended because its the most secure way to use a server without setting anything up on the server?
<jbowtie> That implies that in the mini-tutorial, we should be telling people to set up a bzr+ssh server.
<ddaa> sftp is not recommended because it is inefficient
<Glenjamin> compared to what?
<ddaa> bzr+ssh, for example
<Glenjamin> only a smart server, which isn't introduction stuff
<Glenjamin> bzr+ssh needs bazaar on the server, sftp doesnt
<ddaa> Glenjamin: that's a different issue
<ddaa> Which transport is recommended for general use
<ddaa> and which transport is easiest to setup and secure
<Glenjamin> i quite like bzr+https personally, as the web server has plenty of ways to layer auth
<jbowtie> Well, we want to make sure people understand that sftp is not the best option.
<Glenjamin> a general transport comparison page would be cool
<Glenjamin> and then mention the comparison page in the tutorial
<ddaa> Glenjamin: IMO, that's still significantly harder to set up than bzr+ssh
<ddaa> also, I heard it's less efficient
<Glenjamin> yes it is, but its more flexible imo
<ddaa> but I don't know why
<jbowtie> Which could be reduced to just a note anywhere we mention sftp.
<Glenjamin> i dont trust file ownership with multi-user bzr+ssh, but maybe thats just me
<ddaa> that's just you
<lifeless> bzr+ssh will be better than sftp
<ddaa> if you don't trust operating systems permissions, you have a big problem
<jbowtie> Probably bad memories of early svn servers.  ;)
<lifeless> sftp masks out bits needed for multi user managed directories.
<lifeless> (on the server)
<Glenjamin> i understand them, they just tend to break
<Glenjamin> such as when other people poke around on my servers
<jbowtie> The mini-tutorial doesn't explain how to set up a SFTP server, just says "if you have access to one". With bzr+ssh we could look at linking through to the setup instructions.
<jbowtie> Really, what's the best experience for the complete newbie who wants her own server?
<Glenjamin> launchpad!
<jbowtie> Launchpad is the best option, unless you're setting up a corporate server.
<jbowtie> We already have launchpad covered in the mini-tutorial.
<Glenjamin> and if you're setting up a corporate server, you don't need the short version, you need to know the details
<jbowtie> I agree - but setting up ssh is easier than setting up http. And sftp is easier still, which is probably why the docs originally went with that.
<jbowtie> However sftp is a bad example because performance will kill you when you go to import your svn server.
<jbowtie> So I'm thinking - give bzr+ssh as the main example; with a note about the alternatives (bzr+http and sftp)
<jbowtie> Of course in the user guides we have all the details anyway, it's just the tutorial examples I'm thinking about.
<jbowtie> Setup isn't so bad, it's "apt-get install bzr sshd" (or your distro equivalent) on your server then you can push with bzr+ssh.
<jbowtie> poolie: You filed the bug, any opinion?
<maxb> The big sticking points for corporate servers are access control and organization of many branches
<Glenjamin> i'd say there's plenty of ways to do access control, but i'm not aware of a good entry-point for restricting branch organisation
<jbowtie> maxb: I know, I handle Subversion, TFS, and Bazaar servers at my current employer.
<Glenjamin> what method do you use for the bazaar repo / branch permissions?
<jbowtie> We use ssh. If branches need different permissions we put them in different locations on disk.
<Glenjamin> everyone uses their own ssh login, and shared branches are done via groups?
<jbowtie> We could also split branches across different servers if needed.
<jbowtie> Correct. And I handle merges to trunk.
<jbowtie> Normally we do feature and bug branches, so there's not too many shared branches, I create those manually.
<Glenjamin> ah, so you set the permissions for the shared branch explicitly
<jbowtie> Sort of, I have directories corresponding to our usual groups and branch into those locations so they inherit permissions.
<jbowtie> bzr+ssh://my.server/editorial/feature-X
<Glenjamin> i've got two different repo setups here - both use a wrapper to manage access/permissions and have all branches owned by the same unix user
<maxb> This is the major sticking point to corporate bazaar, I think - everyone has to reinvent a variant of this
<maxb> it's almost as if we need a mini-launchpad :-)
<jbowtie> In theory you can set up your own launchpad.
<jbowtie> I haven't had a machine to play with though.
<Glenjamin> i'm pretty happy with the latest approach i've done: loggerhead proxied through apache and bzr+https via mod_wsgi+apache at the same location
<Glenjamin> and then I use apache's access controls to limit access (using ldap)
<jbowtie> That's pretty much what we do with the Subversion servers, probably would consider it for bzr if admin load increased too much.
<maxb> jbowtie: Yes, but first you need to invest an awful lot of time in it replacing all the images
<millun> http://dpaste.com/247244/
<millun> hi
<jbowtie> maxb: True, but with open source only one person really needs to do that work once.
<maxb> ish, subject to merging ongoing development
<Glenjamin> well you could abstract out the branding
<Glenjamin> and get it back upstream
<millun> bzr fails to install on debian lenny (from backporst)
<millun> backports
<millun> http://dpaste.com/247244/
<millun> pycentral: pycentral pkginstall: error byte-compiling files (735)
<millun> maybe it needs python 2.6?
<jbowtie> millun: I'm having a quick look now to see if there's anything obvious
<millun> cheers
<millun> python on lenny is 2.5. my localhost py is 2.6
<jbowtie> millun: Do you have multiple versions of Python installed on that machine?
<millun> no
<millun> maybe not
<millun> i'll check
<Glenjamin> is there a way to get a more verbose error? that one's a bit vague (i'm not too familiar with dpkg)
<vila> millun: <shudder> we are currently releasing 2.0.*6* would you mind trying to push the upgrade on the debian side ? I don't know whether this will address your immediate problem but at least you'll get the fixes done since 2.0.3
<millun> oh ok. i'll ask the guy who decides
<vila> millun: and I should have said: we are leasing 2.0.6, 2.1.3, 2.2.1 and 2.3b1 the first three being stable releases
<vila> millun: I don't want to make your life harder (quite the contrary) but it's a bit deceiving to use a packaged distro if you can't get the last available stable updates :-/
<vila> fullermd: Quick FreeBSD question, I do regular 'updports.sh ;  portupgrade -a' (as in once every full moon) and there is a number of patches mentioned there. ~2400 seems.. hard to relate to the number of packages updated, is "patch" here referring to a CVS commit ? What's the level of detail ?
<jbowtie> vila: packages.debian.org shows 2.0.3 in lenny-backports; maybe we should bounce a reminder to their maintainer team?
<vila> jbowtie: yeah, I did that, but no response so far
<vila> jbowtie: but may be I didn't ping the right ones ? What will *you* do ?
<vila> jbowtie: or rather, if you know what to do, please do :-) And put me in the CC :-)
<jbowtie> vila: I'm looking at their mail archive right now to see what's been going on.
<vila> I'm not familiar enough with debian to know whether they are still interested with our 2.0 updates or not...
<vila> jbowtie: great
<jbowtie> vila: Sure, consider it an audition for my BSE application.  :P
<vila> jbowtie: err, which one ? url ?
<vila> jbowtie: hehe, couln't hurt, but I'm not the one taking the decision here ;-)
<jbowtie> http://lists.alioth.debian.org/pipermail/pkg-bazaar-maint/
<vila> right, so my mail should be there
<jbowtie> I see it, they apparently have no spam filter on that list though, judging from the state of the archive.
<maxb> backports.org is not technically an official Debian service yet.
<maxb> Also, it's a backports service, so if anything, they might as well update it to 2.2.1
<vila> maxb: who should decide, or better, act here ?
<jbowtie> vila: Looks like jelmer is probably the best person to talk to, he's listed as a maintainer and is active on their list.
<vila> jbowtie: hehe, yeah, jelmer is great, but looks a bit overbooked, so who is the backup there ? ;-D
<maxb> vila: Anyone who wants to volunteer their time. Non DD/DMs need to act through the Debian mentors. Reminding the person who last uploaded the package to lenny-backports is a good idea
<maxb> <maxb> backports.org is not technically an official Debian service yet.
<maxb> Ooops, now it is!
<vila> maxb: ok, DM == Debian Mentors, are you one ? I really need to start somewhere...
<maxb> Also, packages are supposed to hit testing before being considered for backports, so at the moment, it's 2.1.2 that's eligible
<maxb> DM == Debian Maintainers
<maxb> No, I have no Debian official affiliation at present
<vila> gah, so who are the mentors ? Any DD or DM ?
<maxb> Though one of these days I ought to re-investigate my potential for DM and/or MOTU
<vila> maxb: so, re-reading http://packages.debian.org/search?keywords=bzr , you mean 2.1.2 can go from testing to backports ?
<vila> maxb: can 2.2.0 go from unstable to testing ?
<maxb> No, the freeze is on
<maxb> 2.1.2 can go to backports if someone does stuff according to http://backports.debian.org/Contribute/
<vila> freeze for (sorry for the idiotic questions but as I said I ahve to start somewhere :-})
<maxb> pre-release freeze for squeeze
<vila> maxb: which means it will become stable ?
<maxb> eventually
<jbowtie> vila: I'll fire off some emails to the lists in about 10 hours to see if there are any DD's hanging around, maybe we can get jelmer to give us some names.
<vila> jbowtie: ok
<vila> jbowtie: thanks
<vila> maxb: let see, where can 2.0.6 go (in debian context) ? Nowhere ?
<maxb> correct
<vila> 2.1.2 goes to backports
<vila> 2.2.1 to unstable ?
<vila> or should we just target 2.2.1 to backports ?
<vila> maxb: quite different than Ubuntu where we want 2.0.6, 2.1.3 and 2.2.1 deployed and 2.2.1 and 2.3b1 in the ppas right ?
<vila> or may be not that much, debian being closer to what we do for ppas ?
<maxb> The key difference is that Ubuntu has an -updates pocket
<jbowtie> vila: I'll also email the debian-backports list to see if anyone wants to help sort this specific issue.
<mgz> hi all.
<maxb> vila: Debian has its own concept of updates, but they're limited to security and dire emergencies
<vila> mgz: _o/
<vila> jbowtie: good idea
<vila> maxb: how do we apply that to our releases then ?
<maxb> We put the latest stable into Debian unstable, except when there's a freeze on. We consider helping update stable-backports from testing.
<vila> wow http://backports.debian.org/Contribute/ seems a bit intimidating at first... I may to filter a bit about what we already do in bzr
<vila> maxb: ok, so 2.2.1 -> unstable except not, 2.1.2 to backports then right ?
<maxb> yes
<vila> and then... 2.2.x to unstable after the freeze or 2.3.x depending on when it occurs
<vila> in summary we push only two of our series and help our older stable releases to progress in backports unless some serious bug is considered for... testing ?
<millun> thanks guys, upgrade resolved the issue
<millun> i forgot if i should do checkout or branch
<Glenjamin> depends what you're getting
<jbowtie> millun: Checkout creates a bound branch (commit has to succeed at server before it is applied locally)
<Glenjamin> if you want a copy of a remote branch that's easy to update, i'd use checkout
<Glenjamin> if you're going to make local changes, then branch
<jbowtie> millun: Branch creates an unbound branch (commits are local, use push and pull to interact with server)
<millun> i have a php project, i want to run it on a dev server
<millun> some minor changes in config files will occur
<Glenjamin> config files which change should be outside of version control, if generally use checkout for a deployment
<Glenjamin> s/if/i/
<millun> i know i was using bzr pull command
<jbowtie> millun: If you were using pull, then you would have used branch instead of checkout.
<millun> did checkout now
<millun> should be goo
<millun> d
<millun> so now i will be using bzr update or like?
<jbowtie> Correct, or you can use bzr unbind and then use bzr pull.
<millun> ok
<millun> thankls
<jbowtie> Right, I'm off, time for bed in my time zone.
<cbz> when using bzr-svn with an existing maven'ised svn project is there something i can use in the scm section of the pom.xml file so that bzr tools will be launched locally instead of svn tools?
<maxb> I don't think so
<vila> millun: when you say " upgrade resolved the issue" which version do you use now ?
<ploum> Hello
<ploum> I'm looking for a way to store the current revision number in a file
<ploum> The file itself has to be commited with that revision
<ploum> How can I achieve that ?
<maxb> That feels wrong
<ploum> I want the revision number to be available in any export of the branch, why does it feel wrong ?
<spiv> To be pedantic, that's a different requirement to wanting the committed text to have the revision number :)
 * spiv -> bed
<vila> ploum: because a revision content should be fully known before giving it a revision-id
<vila> ploum: may be you're searching for 'bzr version-info' instead
<maxb> vila: Well, actually, you can know the revno that a revision you're about to commit will get, so it's doable :-)
<ploum> vila: I'm already using version-info
<vila> maxb: I went for the simplest explanation, there is still a chiken and egg problem there
<maxb> I think a better solution would be a trivial script that wraps bzr export and bzr revno
<maxb> vila: I agree it's not a very nice option, but I don't see any chicken/egg problem involved.
<ploum> maxb: how can I achieve that other than a "current+1" ?  (that I don't want to avoid doing +1 when the commit fail (because it is empty)
<vila> ploum: then what are you trying to achieve exactly ?
<ploum> sorry, this is not related to export, (I'm confused by another problem)
<maxb> current+1 is the only way you can predict the revno of a future revision
<maxb> But, I second vila, what are you trying to achieve exactly ?
<ploum> vila: I'm working in a very large SVN tree including multiple module. As I work only on a small part (one module), I use bzr-svn to work on that very small part.  People working with the whole tree want to know exactly what is the "internal revision" of my module.
<ploum> Bzr keep its own revno so it's fine
<ploum> for example, my revno 5 is the rev 134 of the SVN
<ploum> and I want to have a file, in that tree, that contains that internal revno
<maxb> hrm
<ploum> I currently write bzr revno
<ploum> maybe simply revno+1 could be enough ?
<vila> ha, so you'd like people pulling from your branch (even indirectly) to get what your consider to be the revno, but it doesn't have to be the bzr revno, just an incremented value (for appropriate values of incrmented) right ?
<vila> the problem with 'bzr revno[+1]' is that it would be wrong if you uncommit for example
<ploum> vila: more or less. I want it to be the bzr value so when they ask something, I can quickly revert to that number
<ploum> vila: indeed
<maxb> Would it actually be wrong if you uncommit?
<maxb> I don't think it would
<vila> nothing robust comes to mind :-/ You really want nested tree here (once more)
<vila> maxb: it won't be "wrong" but you can end up with the same revno and different content, if people have already pulled... you lose
<maxb> vila: Can you see anything wrong with a pre_commit hook which writes the revno + 1 to a file?
<vila> except for not being reliable in case of uncommit, no
<maxb> Oh, yes. But that's true of any pushed uncommit. So don't do that :-)
<vila> so I think an alternative would be a pre-commit hook which increments the value there while you still retain control over it
<vila> so it's *always* incremented (and address uncommits) but you can still tweak it when needed
<vila> of course the drawback is that it can go out-of-sync with bzr revno, but with a bit of care you should be able to resync
<vila> i.e. start with revno+1 before the next commit and in the worst case... decrement if you're sure you haven't push or something
<maxb> hmm, pre_commit docs say lots of things about not being allowed to modify the about-to-be-committed tree
<vila> also, revno can drastically change if you re-pull from trunk instead of merging, using revnos as a communication mean require some enforced workflow of the shared trunk
<vila> meh, maxb is right, I'm confused, I thought we had one hook for that...
<maxb> pre_pre_commit? :-)
<maxb> oh, wait, MutableTreeHooks.start_commit
<vila> exactly, pre_commit should reference it
<Glenjamin> does it necessarily have to be stored as a file
<Glenjamin> bzr revno svn://path would tell you the number, if they dont have svn it might be simpler to give them a way to get that info
<Glenjamin> *if they dont have bzr
<vila> Glenjamin: good point, relying on the VCS tool is generally more robust
<vila> ploum: ^ can this address your problem ? You should be able to match the svn revno to the bzr one no ?
<Glenjamin> hrm
<Glenjamin> neither revno nor version-info take the -r option
<Glenjamin> so probably can't map an arbitrary svn revno to a bzr one in this way
<vila> no, but I think bzr-svn manage to display the svn revno somewhere (no direct experience sry)
<Glenjamin> it displays it in the bzr log
<Glenjamin> and provides a revision specifier prefix svn:
<vila> so if someone mentions an svn revno, ploum can find the bzr correspoding one, ha, svn: even better :)
<Glenjamin> yes, but bzr revno -rsvn:149 won't work
<Glenjamin> log might
<vila> it sure must :)
<Glenjamin> it does in fact
<Glenjamin> as i've just tried it
<vila> ploum: does the above address your "People working with the whole tree want to know exactly what is the "internal revision" of my module" ?
<vila> or not at all ?
<maxb> http://paste.ubuntu.com/498470/ works. Until you try to run "bzr commit <some pathnames>", at which point it of course does not commit your flag file
<ploum> vila: not really
<ploum> I think that I will go with the revno+1 approach
<ploum> as we will probably not uncommit
<ploum> thanks a lot for the brainstorm :-)
<millun> vila: 2.0.3 i believe
<vila> millun: 'bzr version' could turn your beliefs into  facts :-D
<fullermd> vila: I believe 'patch' in that sense is one change to one port.  So it's sorta a proxy for CVS commits, though a commit could touch multiple ports.  (or I could be wrong; I never delved into portsnap internals)
<fullermd> I'd expect a pretty vague relation to the number of things you update.  For one, multiple changes to a port since your last update would be multiple packages.  But more importantly, you don't have most ports installed   :p
<vila> fullermd: what I was after was some rough estimate of the a threshold above which I should start to worrying
<vila> but yeah, since it's a reduced setup it could be hard for you :-/
<vila> what is your update frequency and how many patches do you see then ? (On average)
<fullermd> According to INDEX, there are 22,138 in the tree as of my last update.  I have 841 installed on my workstation; you surely have less.
<vila> INDEX is a file ? path ?
<vila> INDEX-8 in /usr/ports/ ?
<fullermd> Oh, I dunno.  Depending on the system, somewhere between a couple times a week and a couple times a month maybe.
<fullermd> Number of patches varies a lot.  There was an autoconf update recently; sweeping stuff like that, or gettext updates, tend to touch a huge number of files all at once.
<vila> hmm, I'm climbing the wrong tree it seems :)
<fullermd> Yah.
<vila> bah, nvm
<fullermd> I've seen updates like 10k patches, on stuff I let get real outdated   ;)
<vila> oh, so I'm not so bad with 2400 then
<vila> It's a bit hard to remember when everything went well ;)
<fullermd> Yeah, it's not surprising at all if there were one or two sizable things in it.
<vila> I just had a doubt this morning when I saw 2400 and went... is this really expected...
<fullermd> autoconf update was in the last week.  There was a KDE update a couple weeks ago.  Both of those touched a big ol' pile of stuff.
<fullermd> Either of those could easily be a couple hundred each, I'd WAG.
<vila> right, so autoconf should be in but not kde, as long as I can run emacs with a remote X, I'm happy. So I never tried to setup a desktop manager there :-P
<fullermd> Well, you'd still have all the patches to update the ports.
<vila> ooh, I see
<vila> ok, even less representative for my case then
<fullermd> You'd just save the 6 weeks of build time to recompile it all  ;)
<fullermd> Yeah, the 'patches' count is a proxy for "number of changes to any ports since your last update"; that's probably only vaguely proportional to "number of things I've installed that now need updating"
<vila> yeah, but those packaging stuff is eating my disk space ! I knew it, I knew it
<fullermd> Nom nom nom!
<mgz> vila, what rev did you branch 2.3b1 off?
<vila> mgz: I've mentioned it in some mail I think, let me check
<vila> 5432 revid:pqm@pqm.ubuntu.com-20100917142727-49blehg006i4nc9n
<mgz> thanks, so that's just got this fix.
<mgz> urk, but I now can't set the milestone correctly...
<vila> bug # ?
<mgz> vila, is there any way of marking bug 576269 as fixed in 2.3b1 now?
<ubot5`> Launchpad bug 576269 in Bazaar "verbose mode in selftest show "running 0 tests" (affected: 2, heat: 12)" [Low,In progress] https://launchpad.net/bugs/576269
<mgz> (it's not really that important, but I'm curious)
<vila> mgz: yes, making the 2.3b1 milestone active, marking the bug, making the milestone inactive again
<vila> mgz: https://edge.launchpad.net/bzr/2.3/2.3b1 do you see pen icon near change details there ?
<vila> no NEWS entry for it right ?
<mgz> nope.
<vila> mgz: ok, that's why I missed it
<mgz> on the pen, that is.
<vila> done
<mgz> and probably no on the news as well, I was changing a bunch of testing things and getting news conflicts on pqm for every merge
<vila> then you don't have enough rights to activate a milestone
<vila> I can leave the milestone active if you think there are other bugs like this one
<vila> but we try to keep the list of active milestones minimal to make it easier to use
<mgz> no, I just pushed that literally as I was leaving the house on Friday and am only now getting back to updating the bug tracker
<vila> though, until the release is officially announced, I may as well leave it active
<mgz> so mark it inactive again.
<vila> no other bugs ?
<mgz> nothing else landed in that window, no.
<vila> anyway, if you need it again, you know where to ask :)
<Glenjamin> guys, is the general idea to move towards pycurl or away from it (in bzr)?
<mgz> yeah, thanks for the walkthrough vila.
<vila> Glenjamin: away
<Glenjamin> is there a list of bugs blocking this somewhere?
<Glenjamin> i keep hitting issues due to bzr on ubuntu using pycurl =/
<vila> roughly we need to implement ssl cert verification into our urllib-based implementation
<vila> what kind of issues ?
<Glenjamin> bzr: ERROR: Generic bzr smart protocol error: Invalid http response for https://<host>/servers/auth/.bzr/smart: Unknown response code 401
<vila> wut ?
<vila> 401 is an authentication error... I thought the invalid cert was different... .bzr.log says more ?
<Glenjamin> https with http auth using pycurl doesn't prompt for credentials
<vila> ha ! right, yeah
<vila> Glenjamin: do you care about the certs being verified ?
<Glenjamin> nope, i've just installed that default urllib plugin you did
<vila> Glenjamin: and is it a problem just for you or do you need to address it for a wide range of people ?
<vila> Glenjamin: ha, right, sorry, didn't connect the dots :D
<Glenjamin> its a problem i need to address globally, but i'm ghosting the machines
<vila> so, yes, we want to go away and only retain pycurl so far for 1) people that needs cert verification 2) some support for auth protocols that may not be supported in our urllib implementation
<vila> my vagueness on the later indicates that it's less important than the former
<fullermd> Well, either that of you're just vague   ;)
<jszakmeister> As I'm writing up some notes, I actually sat down to look at the difference between "bzr checkout" and "bzr branch --bind".
<jszakmeister> The only difference I found that was branch sets the parent location, while checkout does not.
<jam> mgz: if you could forward my message back to the tracker. I responded before I remember LP will reject any emails I send it, and I don't really feel like rewriting it.
<jszakmeister> Any reason why checkout doesn't set the parent location?
<Glenjamin> bzr branch --bind == bzr branch && bzr bind :parent
<mgz> I shall jam.
<Glenjamin> would be my assumption.
<mgz> is there any progress on the bug that's eating your email?
<ddaa> jszakmeister: because the branch parent is a useful default for "merge" and "pull"
 * fullermd rallys himself for another checkout discussion..
<ddaa> typically, you'd make a checkout of a feature branch in centralized development process
<ddaa> and you'd want "bzr merge" to merge from "trunk"
<Glenjamin> then what's bzr branch --bind for?
<ddaa> whereas, by using "bzr branch --bind", you indicate that you are working in a decentralized workflow, and you want to start with your branch bound.
<jszakmeister> ddaa: I'm not sure I understand what you're saying there.  If the parent location isn't set, the you have to specify what you're merging from, right?
<fullermd> A checkout has a parent location.  It's on the branch.
<ddaa> Glenjamin: it's a shortcut for branch + bind.
<Glenjamin> yes, i get that - but why?
<jszakmeister> fullermd: but not locally.  Note: I'm not talking about lightweight checkouts... which is another topic all together.
<fullermd> It shouldn't be.
<ddaa> Glenjamin: because bound branches are branches that do "push" automatically for you.
<Glenjamin> so you're saying that conceptually a bound branch is in some way different from a checkout?
<ddaa> There are really two ways to look at bound branches.
<jszakmeister> ...man, I didn't mean to start any fires. :-)
<ddaa> One way is to think of them as "lightweight checkout with a local cache, and the ability to do the occasional local commit when working offline"
<ddaa> The other way is to think of them as "branch that pushes automatically whenever you commit"
<ddaa> (or pull)
<jszakmeister> ddaa: doesn't it work the same under the hood?  Certainly, from a branch perspective, the contents of .bzr/branch are the same...
<ddaa> jszakmeister: yes, it does work the same.
<jszakmeister> with the exception that branch sets the parent and checkout doesn't.
<ddaa> it's only a matter of how you want to think about your branch.
<Glenjamin> basically, i don't get why you'd ever do branch --bind
<Glenjamin> it sets parent, which is used for pull and merge - but in this case update will do the same
<ddaa> Glenjamin: because you're too lazy to remember to "bzr push"
<Glenjamin> but why use branch --bind instead of checkout
<fullermd> Because hopefully some day, that giant pile of bugs will be fixed...
<ddaa> fullermd: you say they should behave the same?
<ddaa> I see a useful semantic distinction.
<fullermd> Quite the contrary.
<ddaa> fullermd: then you say there should be additional differences between checkouts and bound branches?
<fullermd> I say we should _have_ heavy checkouts, and bound branches, rather than neither masquerading as both.
<jam> mgz: no progress yet. Martin mentioned that they recently started checking timestamps to help avoid replay attacks.
<ddaa> and how would they further differ?
<Glenjamin> what would be the difference? ^^
<fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/BoundBranches
<jam> however, the timestamps look good to me...
<dash> i still find that page incoherent
<jszakmeister> fullermd: is the distinction that a checkout modifies the remote branch, rather than committing locally and pushing?
<ddaa> dash: I think the "Consequences and Changes to Current UI" section makes sense
<fullermd> No, the fundamental distinction is that for a checkout there IS only one branch.  You can't modify a local branch, because there conceptually isn't one.
<ddaa> I WAS burnt in the past by doing "update" in a bound branch, wanting to update the tree to the branch, not pull the master.
<Glenjamin> what benefits would that bring?
<jszakmeister> fullermd: I think that's what I was trying to say... you modify the remote side (the target of the checkout) directly.  It's not really a branch locally.
<fullermd> Yah.  It distinguishes the use-cases of "I want to work on that branch" from "I want to automate keeping these branches in sync"
<ddaa> Glenjamin: it's not really a discussion about "benefits", but about "clear concepts"
<Glenjamin> my point is, what would be gained by separating the concepts. And I can't think of anything
<fullermd> The benefits (on the co side; fixing that 'update' bug on the bound branch side would be bigger) are relatively small; a big part of them is just fixing all the misbehaviors of heavy vs. light checkouts that are caused by acting boudnish, like handling of branch config.
<ddaa> Glenjamin: among other things, a meaningful answer to "what's the different between checkout and branch --bind"
<ddaa> Glenjamin: also, the ability to update the tree of a bound branch without actually pulling from the master.
<Glenjamin> My workflow involves heavy checkouts for pretty much everything, so I guess I haven't run into these issues
<jszakmeister> One thing I found surprising is that in my environment "bzr branch --bind" works fine using http:// against a smart server...
<jszakmeister> checkout fails.
<jszakmeister> I always have to use "bzr+http://" to make checkout work.
<Glenjamin> you mean http dumb server?
<Glenjamin> oh right, autodetect
<fullermd> As does mine.  I've never had any use for bound branches, but I'm all about checkouts.  But certainly some people are just the opposite way aroudn.
<Glenjamin> when I make a new branch, i update local trunk, branch local trunk, push to central, bind to push
<Glenjamin> presumably if checkouts != bound branches, i'd have to do something differently
<ddaa> fullermd: actually, the update misbehavior can occur when you have lightweight checkout of a bound branch.
<Glenjamin> what's this update misbehaviour by the way?
<mgz> okay jam, I've replied to both the mails I got from you so they'll be in the mp record.
<ddaa> update on a bound branch is equivalent to update + pull.
<ddaa> (modulo conflicts)
<ddaa> let me rephrase that
<ddaa> update on a lightweight checkout of a bound branch, is equivalent to "pull" in the branch then "update" in the lightweight checkout.
<ddaa> Which is surprising.
<jam> mgz: well the second one I went straight to the website. I've also been attempting to set my local time differently, etc.
<jam> mgz: btw, can you check the gpg --verify output from the original email?
<ddaa> It should just do "update" in the lightweight checkout.
<jam> Knowing the timestamp it thinks  is present, etc, would be helpful
<ddaa> And a lightweight checkout of a checkout should not be allowed.
<jam> I know what is says *here* but I'd like a second opinion
<Glenjamin> I see
<ddaa> But this discussion is somewhat of a nitpick.
<fullermd> More abstractly, "update is a command that writes to the working tree based on reading the branch.  Oh, except in this other magic case where it writes the branch based on a different branch"
<mgz> jam: you'd also sent one about 2.3-filter-tests
<mgz> I'll check with gpg now.
<jam> ah rgiht
<jam> right
<jam> thanks
<fullermd> Model-breaking mental page faults FTL  :(
<jszakmeister> Is there any movement on changing things?
<fullermd> Not AFAIK.  It's not entirely uncontroversial.
<ddaa> well, it does sound like an arbitrary restriction
<ddaa> and there WILL be a reconfigure option to switch between bound branches and checkouts
<ddaa> so it will be possible to break the model
<jszakmeister> Well, I like the idea of checkouts... at least in the sense that they update the remote branch rather than push revision after committing locally.
<mgz> jam: reckons that's a good sig here
<ddaa> fullermd: I think that would be a good thing, because it would make for easier documentation.
<jszakmeister> I'm still not sure what happens when two people try to commit at the same time...
<jam> mgz: the sig is good, can you give me the time that it thinks it was at?
<ddaa> on of them will have an error "out of date"
<fullermd> Well, so do I.  That's why I keep griping about it   8-}
<mgz> gpg: Signature made 09/22/10 15:26:02 using DSA key ID 848D0003
<mgz> gpg: Good signature from "John A Meinel <john@arbash-meinel.com>"
<jszakmeister> I guess it all works out in the end (whoever loses, the commit gets uncommitted)
<mgz> I'm on BST (+1)
<Glenjamin> dont bound branches grab a write lock before comitting locally?
<mgz> this is the 2.3-filter-tests message. which has the header:
<mgz> Date: Wed, 22 Sep 2010 09:26:02 -0500
<Glenjamin> or at least exhibit equivalent behaviour
<jam> mgz: that certainly sounds like it matches mine, which is 09:26 CDT (-5)
<ddaa> Glenjamin: "out of date" or "lock taken", anyway.
<fullermd> Yes, which I think is another bit of conflation fallout (at least, it's made "easier" by the conflation)
<ddaa> Glenjamin: the contract is that only one commit will succeed.
<ddaa> The other will fail atomically.
<ddaa> bzr use a two-step commit in this case, it won't update the local branch until the remote branch was sucessfully committed to.
<jszakmeister> Is there a plugin that provides the equivalent of graphlog in Mercurial?
<jszakmeister> Google didn't turn up anything.
<Glenjamin> got a screenshot?
<Glenjamin> ah, i see
<Glenjamin> jszakmeister: qlog does that graphically, not sure about on the command line
<jszakmeister> Oh, I'm familiar qith QBzr and friends. :-)
<jszakmeister> I was looking for something textual though.
<fullermd> You use bzr-hg, push into a mercurial repo, and...
<jszakmeister> :-)
<fullermd> Or push into mtn; it draws those things by default.
<fullermd> Wish it wouldn't, thought; for anything not trivial and tiny, it's just wasted space.
<jszakmeister> Wow.  I haven't played with monotone in a while.
<jszakmeister> Yeah, that's one of those things that's occasionally useful... I wouldn't want it all the time either.
<mgz> Gary's done the hard bit for qlog tests anyway, you might be able to persuade him to pull some of that out into a plugin
<jszakmeister> mgz: that's a good idea
<jasonlife> I created a branch and updated a file, and tried to merge this new branch in trunk, but merge doesn't work..  any way to investigate this problem?
<dash> what kind of doesn't work?
<jasonlife> merging don't work..
<dash> yes. how doesn't it work?
<jasonlife> the file I updated in branch doesn't applied to the same file in master..
<dash> what does it do instead?
<jasonlife> I ran "bzr merge ../test-branch" , and got bzr: ERROR: [Errno 5] Input/output error
<jasonlife> I normally get this error without any problems for other bzr commands though..
<dash> jasonlife: yikes!
 * fullermd is a little creeped out by "normally" and "get this error".
<dash> what OS are you using? what filesystem?
<jasonlife> hang on..
<jasonlife> fedora 10
<jasonlife> nfs
<dash> yeah um, sounds like you've got some nfs issues
<jasonlife> I see..
<jasonlife> Is it known issue?
<jasonlife> any way to fix? or investigate?
<jasonlife> Are there other ways to merge between branches?
<dash> what version of bzr are you using?
<jasonlife> Bazaar (bzr) 2.1.0
<dash> jasonlife: this may be relevant: https://bugs.launchpad.net/bzr/+bug/98836
<ubot5`> Launchpad bug 98836 in Bazaar "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability (affected: 12, heat: 156)" [High,Confirmed]
<dash> oh, this is the specific one: https://bugs.launchpad.net/bzr/+bug/137387
<ubot5`> Launchpad bug 137387 in Bazaar "close or truncate of os-locked file gives EIO on some NFSv4 servers (dup-of: 98836)" [Low,Incomplete]
<ubot5`> Launchpad bug 98836 in Bazaar "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability (affected: 12, heat: 156)" [High,Confirmed]
<jasonlife> it seems the issue with ntfs hasn't been resolved yet..
<jasonlife> hmm..
<jasonlife> Is there any other way to merge between branches  ?
<jasonlife> sorry,,,  ntfs/nfs
<jasonlife>  s/ntfs/nfs
<jam> jasonlife: use a local checkout anywhere on your filesystem that isn't nfs, the branches can stay where they are
<jasonlife> i see.. thanks jam
<jeremyw> Is there an API for telling if a directory is a bzr branch or not?
<jszakmeister> jeremyw: not as far as I know.  I think you just have to try opening the directory and seeing if you get NotBranchError.
<jszakmeister> via Branch.open(), that is.
<jeremyw> Okay.
<thumper> jam: around?
<dOxxx> Good evening.
<dOxxx> Downgrading pyqt is a pain in the ass. Riverbank Computing doesn't keep old versions in their downloads.
<poolie> hello doxx
#bzr 2010-09-23
<dOxxx> hey poolie
<dOxxx> I'm contemplating getting tagged versions of pyqt and sip from their mercurial repo instea.
<dOxxx> except of course they only have sip in the repo and not pyqt itself
<dOxxx>  /facepalm
<jam> thumper: just passing by, I may be around in about 3-4 hours, though
<thumper> jam: can we chat tomorrow?
<jam> thumper: sure
<thumper> jam: I'd like to talk about your thoughts on branch revisions :)
<jam> sure
<thumper> jam: as in the LP table
<jam> though what time?
<thumper> can you do 22:00 UTC?
<thumper> or perhaps half an your earlier?
<jam> 5pm is usually when I stop, extra important tomorrow because my wife is out of town
<jam> 22:00 = 5pm
<thumper> ah
<jam> 02:00 or so might be better
<jam> 21:30 would work
<jam> gotta go
<thumper> ok
<spiv> Good morning.
<dOxxx> howdy spiv
<spiv> Hey dOxxx, haven't noticed you around for a while.  Probably you've just been awake in more sensible timezones ;)
<dOxxx> spiv: I'm not normally on IRC :)
<dOxxx> I'm doing the Mac installers right now and vila suggested we talk about them on IRC
<dOxxx> but I guess his timezone is not compatible
<spiv> He's in Europe, typically he'll be online in about 5.5 hours from now.
<dOxxx> spiv: Hmmm... awkward.
<poolie> hi spiv
<dlee> When I'm about to try something I think might be a bad idea that could be hard to reverse, I tend to copy .bzr somewhere so I can restore it if I make a mess.  Is it safe to do that for a branch under a shared repo, without also copying/restoring the shared repo itself?
<dlee> I sorta have this 6 meg .bzr branch under a 3 gig shared repo. :)
<spiv> It's safe to do that.
<dlee> Really good news for this project!
<dash> dlee: but you can also use bzr revert and bzr uncommit :)
<spiv> dash: well, assuming the operation being tried is a commit, or a pull that adds one new mainline revision (with the old tip as the lefthand parent).
<dlee> Learning how to manage a multiperson bzr workflow at the far end of a large svn repo... lots of syncing that confuses me if I make a wrong step.
<poolie> thanks for the ascii mode patch spiv
<ovnicraft> hi folks i am searching something like this http://bit.ly/aF2hqw anyone knows about?
<ovnicraft> plugin for diff with Ooo files
<poolie> i think you want 'bzr diff --using "oodiff -u"'
<poolie> then you might want to define a bzr command alias to run that
<ovnicraft> in another hand i want to know is tortoisebzr will be support on linux?
<ovnicraft> poolie, i dont know why initially linux is not supported
<ovnicraft> poolie, this is great https://edge.launchpad.net/bzr-oodif
<poolie> ovnicraft: tbzr is very windows-specific
<poolie> there's some bzr nautilus integration
<poolie> i think in bzr-gtk
<poolie> but 'bzr explorer' is a better option there
<ovnicraft> btw is not too important i  can live with stdout
<ovnicraft> but i am really interested in bzr-oodiff
<ovnicraft> and great foudn it
<ovnicraft> found*
<jbowtie> We have file-specific merge hooks; do we not have file-specific diff hooks?
<jbowtie> I'm thinking I might propose a blueprint for handling diff and merge of various free software "binary" formats.
<poolie> good idea
<spiv> +1
<jbowtie> Then you hire me so I actually have time to implement it, right?  ;)
 * jbowtie did not put subtlety on his CV
<fullermd> Subtlety?  I think I heard of that once...
<vila> hi all !
<fullermd> Again?  Didn't you just say that yesterday?
<vila> yup, mummy told me I should do that every time I meet people, so they smile just a bit more everyday :-D
<fullermd> Remember, it takes more muscles to frown than it does to smile.  But it doesn't take ANY muscles to just sit there with a dumb look on your face!
<vila> Yeah, but it doesn't make you richer whereas smiles are supposed to make everybody richer... The trick is to find a way to get some of *their* richness there...
<poolie> hi there vila
<vila> poolie: hey !
<poolie> hi there
<GungaDin> is there a way to uncommit a list of commit and reapply them at the end of the history ?
<spiv> Uncommit only works on commits from the end of history.  But perhaps you are looking for rebase, from the bzr-rewrite plugin?
<maxb> Although, that'll only work if the list of commits is a side-chain in the revision graph
<maxb> There's no way to splice commits out without rewriting everything that comes after the change
<GungaDin> we've made a mistake: we have branch B1 and branch B2 - both were branched of V1 & V2 (different branches, corresponding to different versions of the codebase). B2 was merged into B1 and updates of V1 are merged through to B1 every now and then...
<maxb> ouch
<GungaDin> now that we want to merged B1 into something else we get a criss cross merge...
<GungaDin> and it's a mess.
<GungaDin> the thing is that the updates from V1 are in mutually exclusive directories to the rest of the commits.
<poolie> you want rewrite then
<GungaDin> what will that do?
<poolie> that will let you hoist out the good bits of your history, leaving behind the stuff you shouldn't have merged
<GungaDin> and what will happen with the bits of the history I take out?
<poolie> bzr-rewrite produces a new branch, and in that branch they will never have been merged
<vila> spiv: here we are http://babune.ladeuil.net:24842/view/selftest-all-platforms/job/selftest-jaunty/lastFailedBuild/testReport/junit/bzrlib.tests.test_transport/TestSSHConnections/test_bzr_connect_to_bzr_ssh/
<GungaDin> how do I enable these plugins?
<spiv> vila: huh, it wants me to login...
<spiv> Is that new?
<vila> argh
<spiv> GungaDin: if installing from source, typically by placing them into (or symlinking them into) ~/.bazaar/plugins/, or else by installing it as a system-wide Python package.
<vila> spiv: yes, new, I'm trying to allow some users to run jobs and ... that seems to have restricted anonymous access :-/
<spiv> vila: :(
<vila> spiv: since you will be part of these users, you may as well create a login until I fix the problem
<spiv> Ok
<spiv> vila: I don't suppose Hudson has OpenID support? ;)
<fullermd> I read that as "since you will be part of the problem, [...] until I fix these users"    :p
<vila> spiv: hehe, I haven't see that (nor searched either ;)
<vila> spiv: fortunately I have all relevant config files under bzr as yesterday evening *I* couldn't login anymore at one point...
<vila> and I had to revert to a working config
<vila> one click and boom :-/
<GungaDin> installed bzrtools on my fedora.. but bzr rebase isn't accepted
<spiv> Wow, apparently I got the first two captchas wrong.
<fullermd> vila: Doesn't that infringe some Amazon patent?   :p
<vila> fullermd: you think I can sue Amazon for damages ?
<fullermd> GungaDin: It's not part of bzrtools...  look for 'bzr-rewrite'
<spiv> GungaDin: bzrtools is a different plugin.
<spiv> GungaDin: the plugin you want is called 'bzr-rewrite'
<fullermd> vila: I think it's the other way around...  they sue you for doing something with one click.
<spiv> vila: "spiv is missing the Read permission"
<spiv> vila: for the front page
<spiv> (and the log in question)
<vila> try again ?
<spiv> Ok, I can view them now.
<vila> and try again without login too, it seems to be fixed (I just love when I fix things without knowing why...)
<spiv> vila: that's a really intruiging log
<spiv> vila: bah, I don't want to have to re-enter my password :P
<vila> nvm, I tried from another host, seems good
<spiv> It appears to allow anon read access.
<vila> that's the idea
<vila> spiv: a possible explanation can be: the client try to use the socket before the hand-shake with the server has been done
<vila> spiv: jam fixed a similar issue with the sftp test server
<vila> spiv: most of the time the hand-shake happens quickly enough but it sometimes takes a bit more time
<vila> spiv: did this match ?
<GungaDin> is it possbile to find where a criss cross originates?
<spiv> vila: the log implies otherwise, but of course in the presence of threads the impression of sequential events it gives is likely to be a lie....
<spiv> GungaDin: a visualisation tool like 'bzr qlog' or 'bzr viz' ('qbzr' or 'bzr-gtk' plugins, respectively), may help.
<GungaDin> there are tons of commits...
<spiv> I suppose there should be an option to get merge to report which revisions were involved.
 * spiv -> dinner
<lifeless> vila: I have a thought for you about this coding style thing.
<lifeless> vila: Two thoughts.
<vila> lifeless: I'm sure about that and I'm happy you share them :)
<lifeless> vila: firstly, I think you may be proposing a *surrogate* metric. That is it itself doesn't indicate anything good or bad, but perhaps its often correlated with actual good/bad things.
<vila> lifeless: I don't want to start a holy war but I suspect there are more problems than it appears behind this subject and I'd rellay like to understand them
<lifeless> I don't like surrogate metrics because they are *follow* they don't *lead*.
<lifeless> Fixing the metric doesn't make things good.
<lifeless> it took me a while to understand this, (and when I did I did a big about face on my opinions in coding standards)
<lifeless> Secondly, I wonder if you've taken the time to deeply listen to what Andrew Martin and I are saying about how we find code more readable when done clearly on a case by case basis rather than being strongly-mandated.
<lifeless> I feel like you're brushing us off a bit.
<vila> ha, sorry about that, certainly not my intent
<lifeless> no worries
<lifeless> like I say, just a couple of thoughts.
<lifeless> The one about surrogates is the key one.
<vila> I came to this proposal mostly by applying it previously on the assumption that they were an agreement and specifically to address bugs in the first place
<Glenjamin> when you say coding standards, do you mean something like PEP8?
<vila> and I still feel there is a relative vagueness about how we handle the overall bzrlib namespace and I'm still not comfortable about that
<lifeless> yes; bzr builds its standards on pep8
<lifeless> vila: I don't know quite what you mean there
<vila> as poolie commented, my intent was to *discuss* the policy and I expect to at least understand why people agree with it in certain cases but not others
<lifeless> vila: Well, do you understand why I don't agree with it *at all* ?
<vila> no
<vila> 'warning' for example, I never know which one we're calling
<lifeless> I think you're specifying something best left unspecified.
<vila> that won't help talk about it :)
<vila> names spaces are an important concept, how to use it is worth discussing no ?
<lifeless> vila: we already do.
<vila> 'from module import *' while allowed is not the best example of use
<lifeless> vila: we could a little more in terms of where we put htings.
<lifeless> vila: but you're not really talking about namespaces, more about scopes.
<lifeless> vila: I dunno, the rules you're proposing would drive me batty.
<vila> yes, name spaces are all about defining scopes to partition the global name space
<vila> lifeless: hehe, right, some aliasing related bugs indeed drove me nuts ;)
<vila> not to mention the spurious failures ending with illegal use of scope replacer...
<vila> lifeless: I realize the proposed rules put a small burden on the writer, but the write *knows* clearly when he use a symbol from which module it comes, and *this* information is not passed to the reader, I think that's the crux of my concern
<lifeless> vila: what concerns me is:
<lifeless>  - the reduction in flexability
<lifeless>  - the reduction in readability
<lifeless>  - the reduction in performance [small but exists]
<vila> I don't understand how this reduce flexibility
<vila> ha ! Finally someone mentions the performance ;)
<lifeless> when you say 'do it X way', you exclude all 'non-X' ways
<lifeless> thats less flexible.
<neaj> erm, i'm sorry to show my oar in, but could someone help me with a simple 'bzr init' ?
<neaj> jean@klippie:~/tmp$ mkdir screnum ; cd screnum ; bzr init
<neaj> bzr: ERROR: '/home/jean' is not a working copy
<lifeless> neaj: interesting
<lifeless> neaj: `which bzr` ?
<neaj> looking in .bzr.log, the traceback dies on File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/format.py", line 196, in _open
<lifeless> neaj: oh
<neaj> what's it messing about with svn for?
<neaj> this is bzr on ubuntu 10.04
<lifeless> you can do 'bzr --no-plugins init' to avoid that; please do file a bug on https://launchpad.net/bzr-svn
<neaj> will do :-)
<vila> lifeless: well, one way or another you refer to a symbol. There are only two ways (excluding the ones we don't use and we don't use a lot of alias)
<lifeless> neaj: you have bzr-svn, the bzr svn integration layer installed.
<neaj> hehe, that dies with bzr: ERROR: No repository present: "file:///home/jean/tmp/screnum/
<lifeless> neaj: your previous failure left you with half-a-dir
<neaj> yes, i want to make local branches of svn repos also
<neaj> ah OK, i'll clean up and restart
<lifeless> vila: sure, but when you specify you're making a global assertion...globals are bad ;)
<neaj> Created a standalone tree (format: 2a)  <-- yay, thank you very much
<lifeless> neaj: my pleasure
<vila> lifeless: 'from module import symbol' is more global than 'module.symbol' at the module (the one doing the import ;)  level
<lifeless> removing the authors choice is more global than that
<lifeless> so you need a very strong justification to do that.
<vila> lifeless: does it fly both ways ? Can *I* use module.symbol because I find it more readable ?
<Glenjamin> the rule you're suggesting is to disallow from module import symbol?
<lifeless> vila: I need to sleep; If its still going around tomorrow, I might ask you to argue my case, and see if that helps.
<vila> lifeless: ok
<lifeless> vila: If its clearer sure; mass patches forcing it one way or the other would just be noise and regarded as such, I think, reading martins comment ('flip flop..')
<vila> Glenjamin: yes, see https://code.edge.launchpad.net/~vila/bzr/imports/+merge/36324 comments welcome (whatever your opinion is of course)
<Glenjamin> I can see the justification, but knee-jerk is that its a bit restrictive
<vila> lifeless: sure
<vila> lifeless, Glenjamin : I thought I made this clear with: "Moving from the ``from <module> import symbol`` style is a work in progress, submissions should avoid using it for new code but should not either includes huge cleanups that obscure the purpose of the  proposal. When in doubt, use the ``<module>.symbol`` without modifying the ``from <module> import symbol`` part.
<lifeless> vila: you need consensus that it *is* a work in progress.
<lifeless> vila: that is sorely lacking.
 * lifeless goes to bed. Gnight.
<Glenjamin> I;m unlikely to start doing any major hacking bzr, but my inclination would be that this is more guideline than rule territory.
<neaj> Looks like it's a regression: https://bugs.launchpad.net/bzr-svn/+bug/182140
<ubot5`> Launchpad bug 182140 in Bazaar Subversion Plugin "bzr-svn interferes with bzr operation (affected: 1, heat: 10)" [Undecided,Fix released]
<Glenjamin> neaj, can you get the bzr and bzr-svn version from "bzr version" and "bzr plugins"
<neaj> posted on the issue
<Glenjamin> if you try adding the bzr ppa, you can get newer versions of both.
<Glenjamin> which will probably let you use it, although not really fix the underlying problem
<neaj> it was fixed on 0.4.9 but it's biting me on 1.0.2, so i don't think new-ness is the problem.
<Glenjamin> is it possible to bind a branch to two locations?
<Glenjamin> i'm using colo (which does lightweight checkouts), but I want the branches mirrored onto my central server
<Glenjamin> presumably a lightweight checkout of a bound branch doesn't propagate commits up
<jbowtie> What is the scenario where I'd actually use bzr add --file-ids-from?
<Glenjamin> help provides an example, sounds pretty obscure
<Glenjamin> "This option is rarely needed but can be useful when adding the same logical file into two branches that will be merged later (without showing the two different adds as a conflict). It is also useful when merging another project into a subdirectory of this one."
<jbowtie> It is obscure, I'm trying to find a more useful way to say that in order to fix #505086
<Glenjamin> bug 505085 (making myself a link)
<ubot5`> Launchpad bug 505085 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon extensive disk usage (affected: 11, heat: 62)" [Undecided,Confirmed] https://launchpad.net/bugs/505085
<jbowtie> No, bug 505086
<ubot5`> Launchpad bug 505086 in Bazaar "[doc] bzr add help mentions but doesn't explain file ids (affected: 1, heat: 0)" [Low,Confirmed] https://launchpad.net/bugs/505086
<Glenjamin> oh, whoops
<Glenjamin> oh right, i see
<Glenjamin> something like --same-files-as=TREE
<jbowtie> I need to sleep on it, I'll have another look at it in the morning.
<knittl> what is the last number in a bzr file_id?
<knittl> filename-timestamp-random-X
<knittl> what's X?
<Glenjamin> looks like an incrementing number to me
<knittl> Glenjamin: incrementing when?
<Glenjamin> at a guess, when the file changes.
<maxb> knittl: technically, the whole fileid is an opaque string
<knittl> and why? using those 16 byte randomness + timestamp make it pretty unique
<knittl> Glenjamin: that would mean the file id changes all the time
<knittl> maxb: yes, but that string has to be generated first
<maxb> knittl: imagine committing 5 files called README.txt in the same commit
<Glenjamin> i was about to say that, looking at my inventory i have file_ids of an entirely different format
<maxb> in different directories
<Glenjamin> it's probably just an enumerator per-commit then.
<spiv> It's a guaranteed (within reasonable limits of probability) unique ID.
<knittl> so start_bzr.bat in bzr.dev exists 9 times?
<spiv> The exact way it is generated is unimportant for basically every use I can think of.
 * maxb points to bzrlib.generate_ids.gen_file_id if you REALLY care
<maxb> But you really shouldn't care
<knittl> i do care, otherwise i wouldn't ask
<spiv> It is implemented a) to meet that constraint, b) in a way that is reasonable performant and convenient to implement.
<spiv> But design-wise the details don't matter.
<knittl> maxb: ok, i.ll look at that function
<spiv> knittl: why?
<knittl> spiv: because i do. i'm not writing code to work with bzr file ids
<Glenjamin> for example, bzr-svn imported file_ids appear to be svn-revno@random:full_path
<knittl> i simply need to know. is that so much to ask?
<maxb> knittl: Not at all, but we want to make sure you don't mistakenly build semantics on top of something that has none
<spiv> knittl: Well, it's just that it frankly sounds like a waste of your time
<maxb> Glenjamin: s/random/svn-repository-uuid/
<Glenjamin> yeah, i just got that :)
<knittl> spiv: writing a thesis is not wasting my time
<Glenjamin> when i noticed they were all the same
<spiv> knittl: ah!
<spiv> knittl: what are you writing a thesis on, if you don't mind saying?
<Glenjamin> all week you've been asking obscure questions, you could have said why!
<knittl> maxb: i don't â¦ but i'm describing bzr's internals and defaults
<knittl> spiv: dvcs
<knittl> Glenjamin: well, the answers should be the same regardless of my reasons?
<Glenjamin> yes, but the willingness to provide answers is higher if the answerer understands the justification
<knittl> â¦
<spiv> nittl: Just DVCS in general?  I wouldn't have thought the exact details of our default file-id generation in current versions of bzr aren't really very interesting for a thesis...
<maxb> Also, the answerer can tailor the answer to the purpose being asked
<spiv> But it's possible I'm missing some aspect of it that you find particularly interesting.
<knittl> spiv: dvcs (bzr git hg), inner workings, storage model, object model, storage formats, performance
<knittl> so it matters a lot how bzr generates ids
<Glenjamin> i'm intrigued as to what comparison metric you can apply to something like the file ids
<spiv> Right: I'm saying these details aren't relevant to any of those things you just listed, unless "inner workings" encompasses arbitrary implementation details.
<knittl> Glenjamin: nothing to compare with file ids, but it's good to know
<spiv> Or at least, that I'd be surprised to find they are.
<knittl> spiv: i simply do that, it's important for me and my paper. ok?
<spiv> In terms of storage model, these are restrictions on what forms a valid ID (for files, and revisions).
<spiv> s/these/there/
<Glenjamin> knittl: if you haven't already seen it, http://video2010.scottishrubyconference.com/show_video/11/0 is an excellent presentation on git's workings
<spiv> e.g. it's a valid UTF-8 string
<knittl> Glenjamin: git and hg chapters have been finished a long time
<maxb> It sounds to me like knittl is following the "Understand (almost) everything, then write about the interesting bits" approach
<knittl> please don't tell me how to write _my_ paper
<spiv> knittl: I don't mean to tell you how to write your paper
<knittl> answer my questions that i have â and might sound weird to you â and everything will be fine
<maxb> knittl: Easy there, we're just interested
<spiv> knittl: I do hope I'm able to give you some guidance on what I, as one of the developers, consider to be the key design aspects vs. uninteresting implementation details, though.
<knittl> maxb: the impression i have is different, i only get told what not to do with bzr and what is unimportant
<spiv> knittl: which is not to say I'll be 100% right :)
<knittl> i'm mostly interested in implementation details
<spiv> knittl: also, you ought to be aware that you're the first person to be asking these questions for the sake of it.  We're much more used to helping people *do* things with our tool and code
<knittl> anyways. if the last number in a default file id is incrementing, why is it 9 for start_bzr.bat?
<spiv> knittl: so naturally our reactions so far have been oriented towards that
<knittl> spiv: i thought i was clear, everytime i asked something, that i'm interested in it, because i'm interested, and not because i want to build tools on top of bazaar or write extensions to it
<maxb> knittl: When someone asks about details which are deliberately unspecified, there is a natural caution to make sure they are not attempting to interpret semantics that don't exist. Once you explain that your reasons, that caution is allayed.
<knittl> ok
<spiv> I'd expect it increments for every file added in a single 'bzr add' call (in the default implementation), because that is the simplest way to implement it to meet the constraints.
<knittl> sounds better than the last weeks
<spiv> knittl: so far everyone, even you, that has asked questions, has wanted to achieve *something*, not just asking to understand for the sake of it :)
<spiv> knittl: I'm glad to know your goal, it will help me answer your questions better I think.
<maxb> The design interesting bit about file-ids is simply: (something derived from file basename) + (something unique)
<knittl> i want to achieve understanding
<maxb> Actually, now I'm curious. Why do we put something derived from the file basename in there?
<spiv> knittl: understanding in a specific context, though.
<knittl> maxb: yes. filename in lowercase ascii, 20 chars, first period removed. timestamp in YYYYMMDDhhmmss. random 16 byte string. X
<spiv> knittl: I can debate these semantics with your endlessly if you like, or you can trust me that I have much better idea of where your questions are coming from now.
<spiv> knittl: just like you want us to trust you ;)
<knittl> spiv: ok. bzr add file1 file2 file3. bzr commit will create: file1-time-random-1, file2-time-random-2, file3-time-random-3?
<spiv> knittl: bzr add creates the file IDs, not commit.
<maxb> knittl: probably. I don't care. Why do you?
<knittl> spiv: ok. so bzr 'un-add' removes them again? or leaves them as stale ids?
<fullermd> maxb: I'd imagine because it's easy to grab, somewhat unique, and just-because-it's-opaque-doesn't-mean-it-can't-look-good.
<spiv> knittl: How to put this?  If they're never committed, then they're never committed.
<knittl> spiv: yes, but they are created on add (at least the string)
<maxb> fullermd: A debugging aid. That makes sense. I vaguely recall something about it helping sort like content into groupcompress blocks also?
<spiv> knittl: and recorded in the working tree metadata
<knittl> ok
<spiv> Just like renames via 'bzr mv', or merge revisions from 'bzr merge', etc.
<knittl> yeah. dirstate (same name as hg)
<knittl> i'll write and come back
<knittl> i hope you remember the reason for my questions :D
<spiv> maxb: actually, IIRC the file-id being based on basename only isn't especially good for groupcompress, or something like that.
<spiv> knittl: don't worry, you've been quite memorable :)
<knittl> spiv: haha.
<spiv> Happy writing!
<knittl> spiv: on an unrelated note, what about my cat-signature branch?
<knittl> still no tests
<spiv> knittl: is there a merge proposal or bug for it?
<knittl> couldn't wrapp my mind about it, because i need to access bzr.dev to have something to test regressing against
<spiv> knittl: it seems like a reasonable addition (as a hidden command)
<spiv> knittl: ah, no
<Glenjamin> the justification in the docstring for gen_file_id seems to be based on the assumption that the file_id will be used in the filesystem
<knittl> no bug, and no proposal yet
<spiv> knittl: tests shouldn't assume that bzr.dev exists, it's perfectly possible to create the test data you need in the test
<fullermd> Glenjamin: They were, in knit and earlier formats, where each file had its own [set of] file[s] in the repo.
<knittl> spiv: well, the test would need to create a new revision, sign that revision (with a key which is then stored within the test), then cat it, then verify it
<Glenjamin> makes sense
<spiv> knittl: that's more than necessary
<spiv> knittl: you just need a test that shows cat-revision outputs the signature content for the specified revision
<spiv> knittl: there's no need for the test to generate that signature on the fly first, it can be pre-canned
<knittl> spiv: yes. but to get the contents i'm just calling my code
<knittl> or what do you mean?
<spiv> I'm sure the existing tests for signatures should already have examples
<knittl> couldn't find any signature tests, maybe i was looking in the wrong places
<Glenjamin> you only need to prove that if you store some text as a signature, that cat-signature outputs it
<spiv> knittl: I mean: use the bzrlib APIs to create a precise signature record in the database
<spiv> knittl: and then assert that cat-signature emits exact output (with that content)
<spiv> You don't need to generate the signature during the test execution, it can be a literal, predefined string in the test code.
<spiv> Consider what you are trying to test:
<knittl> hm, i'll look. brb
<spiv>  * not that bzr can generate signatures
<spiv>  * not that bzr can generate revisions
<spiv>  * but that cat-signature will retrieve and display whatever content it finds for a revision
<spiv> (we do of course want those other things to be tested, but that's the job of other, already written, parts of the test suite)
<spiv> (overly broad tests obscure intent and make tests slower than necessary, among other drawbacks)
 * spiv -> zzz
<jml> what do the cool kids use for bzr / emacs integration these days?
<knittl> how can i run a bzr command inside a test?
<Kinnison> jml: I use a shell :-)
<jml> That doesn't count.
<Kinnison> Bah
<jml> Although I'm sure you are one cool kid, that's not integration.
 * Kinnison treats his entire desktop environment as the integration layer :-)
<jml> At least not for my purposes.
<spiv> knittl: http://doc.bazaar.canonical.com/latest/developers/testing.html
<knittl> spiv: go to bed :P
<neaj> is there a standard way of selectively committing chunks from a file?
<maxb> interactive shelve to first remove what you don't want to commit
<jml> there ought to be an interactive commit option though
<jml> particularly since there's an interactive merge
<neaj> maxb: thanks!
<fullermd> Somebody wrote a 'record' plugin once that did that I think.  Dunno if it really worked, or still does.
<jml> it ought to be in bzr if shelf is.
<maxb> The term 'record' is woefully overused
<maxb> I wish loom called its command record-loom at least
<fullermd> I imagine it was chosen to call out to 'darcs record'
<fullermd> (since that does the same interactive type stuff)
<jml> "bzr commit -i". There, I've solved the naming problem.
<knittl> can someone help me write that blackbox test?
<knittl> please :)
<jam> morning all
<jam> knittl: what test?
<knittl> hi jam
<knittl> tests for cat-signature
<knittl> i can create one for cat-signature -r0 easily (no output xD)
<Glenjamin> is it useful for me to say i think it should be called show-signature ?
<jam> knittl: you can look for bzrlib/tests/blackbox/test_cat.py and copy that file to test_cat_signature.py
<knittl> Glenjamin: hahaha
<knittl> jam: i believe i copied cat_revision
<jam> knittl: same thing, sounds fine
<jam> do you have the code somewhere you want me to look at?
<jam> basically it would be something like:
<jam> just a sec
<knittl> Glenjamin: https://code.launchpad.net/~knittl/bzr/cat-signature look at the history (r5432 and r5433)
<knittl> jam: well, i need a signature to validate against
<jam> there would be two ways to do it, IMO, one is to use the "run_script" method
<knittl> i think jam told me to name it "cat-signature" :]
<jam> knittl: you need a signature, but it doesn't have to be valid or gpg signed :)
<Glenjamin> knittl: you'll need to track down the commit code which signs, and see how it adds the signature to the revision
<knittl> my best name would be print-signature, because it prints to the terminal
<Glenjamin> and just do the last bit
<jam> knittl: I think an alias is reasonable, but it is more consistent to call it cat-sig
<Glenjamin> is cat-revision new?
<knittl> jam: not signed? hm, ok
<jam> knittl: there are a couple of options here, let me look at the gpg code for a sec
<knittl> jam: i use run_script to test "test_cat_signature_no_signature"
<knittl> jam: ok
<knittl> appreciate it
<jam> knittl: if you wanted to exercise more of the stack, you could set the config var "gpg_signing_command" to something custom, and then we should grab that and use it to "sign" the revision on commit.
<jam> however, it may be easier to just force it
<knittl> begin pseudo-signed content?
<knittl> (test_re_sign.py)
<jam> knittl: right that is probably the easiest way, just fudge the signing strategy, and assert the content matches what you want
<jam> then you don't have to worry about having gpg on the test machine, etc.
<knittl> ok, i'll try
<knittl> jam: yes, that was my real problem :D
<knittl> not having gpg or having the same key everywhere
<jam> knittl: so in a test, you can use the monkey-patch command, then add "branch.get_config().set_user_option('create_signatures', 'always')"
<jam> and then "tree.commit()" should generate a signature
<jam> which you can check with "tree.branch.repository.get_signature_text()"
<knittl> jam: i also want to test the output for 'no signature' (empty output
<Glenjamin> imo you shouldn't worry about the signing process at all - you should just directly add some signature content to a revision
<jam> knittl: sure, commit 1 without setting create-sig and once with
<knittl> isn't there an option to commit?
<knittl> BzrDir.create_standalone_workingtree('.').commit(â¦)
<jam> knittl: not directly, only via config var
<knittl> ok
<knittl> hrm. i created two revisions, but cat-signature is empty for revid:B as well (the signed one)
<knittl> first, set_user_option(always) then monkey_patch_gpg, then wt.commit
<Glenjamin> how confident are you that the test is broken, and the command isn't?
<knittl> 100 %
<Glenjamin> knittl: i'd do away with the gpg bit, since your command doesn't do anything with it. just use repository.add_signature_text(revision_id, signature)
<knittl> ha! it's working :)
<knittl> http://paste2.org/p/1000141
<Glenjamin> hrm
<Glenjamin> you're testing that a command which calls get_signature_text returns the value of get_signature_text
<knittl> yes. i said that in the beginning
<knittl> tell me how i can test that command without calling get_signature_text
<Glenjamin> you have to explicitly set the signature content
<jam> knittl: the revision-id is known, the signing strategy is known, just put the content into the output
<Glenjamin> using repository.add_signature_text
<jam> --- BEGIN PSUEDO-...
<Glenjamin> or that
<knittl> ok, just a min
<jam> knittl: I do agree with Glenjamin that 'add_signature_text' exercises less of the stack, and makes it more focused on what you want to be testing, namely cat-revision.
<jam> However, a few more thoughts:
<jam> 1) the return code from 'cat-signature -r NO-SIG' should probably be nonzero
<knittl> sha1 changes everytime
<knittl> how can i set the return-code?
<jam> knittl: all right, because the testament changes
<knittl> haha, just found another bug
<jam> knittl: in cmd_cat_signature.run() return an integer
<knittl> gotta fux that
<knittl> * fix
<Glenjamin> write the testcase which reproduces it first :p
<knittl> Glenjamin: the bug?
<knittl> easy: bzr cat-revision -r0
<knittl> jam: return 1? or are there constants like EXIT_FAILURE?
<jam> knittl: I would honestly consider that passing -r0 is a BzrCommandError('invalid revision supplied')
<jam> return 1 is ok
<jam> we use 3 for unhandled exception, I don't remember exactly where it is documented.
<jam> but it isn't with constants
<knittl> jam: if it is bzrcommanderror, then my last bugfix was wrong
<Glenjamin> cat-revision has an unhandled exception with -r0 :)
<knittl> Glenjamin: yes, i'm going to fix that
<jam> Glenjamin: -r0 => revision_id = None
<knittl> after having this test figured out
<jam> which is often not handled all that well :)
<jam> (though maybe it is revision_id= 'null:' ?)
<Glenjamin> so takes_options = ["revision"] decodes into a revision_id?
<knittl> entries(self): if self.root is not None: descend(self.root, u'')
<knittl> is how i fixed the last bug for -r0
<jam> Glenjamin: it decodes into a RevisionSpec which can then be decoded further by applying it to a branch
<jam> I don't remember if 0 is special cased or not
<knittl> no, it's not
<knittl> wt.branch.repository.add_signature_text('B', 'dummy signature')
<knittl> AttributeError: 'NoneType' object has no attribute 'add_bytes_record'
<knittl> i guess it takes a signature object, not a string?
<jam> knittl: you'll need a wt.branch.repository.lock_write(), and wt.branch.repository.start_write_group() before you can call add_signature_text()
<jam> and some othe bits
<cheater> hi
<knittl> oh.
<jam> (commit_write_group())
<cheater> i am thinking of using bzr
<cheater> how difficult is it to migrate from cvs?
<jam> cheater: difficulty is generally expressed in how hard you swear at cvs :)
<dash> cheater: no more difficult than anything else, probably
<Glenjamin> cheater: in terms of technical setup, or usability?
<cheater> let's consider both options
<jam> it depends on what kind of fidelity you want from the conversion given that CVS's understanding of history is not particularly accurate across the whole project
<Glenjamin> well, bazaar's commandset is pretty much understandable to anyone who's used svn (and thus cvs). I haven't really encountered many instances where commands have the same name and do something surprising
<cheater> what sort of different "fidelity" can i get jam?
<cheater> Glenjamin: ok
<cheater> so that's 'usability' i guess
<cheater> we're not integrating cvs with anything
<cheater> which is good because that falls away
<jam> cheater: If you have used cvs in a 'basic' capacity, probably pretty good. The problem is that cvs is a bit limited, so people add a lot of hacks on top of it (like copying ,v files, etc)
<knittl> jam: isn't there something more complete to add signature text?
<cheater> what are ,v files?
<cheater> but yes
<Glenjamin> knittl: that's the highest up command which doesn't use gpg
<cheater> i cannot guarrantee it but i don't think they were using any cvs hacks at ALL
<cheater> just the usual stuff, branches, and merges
<cheater> that's all tbh
<jam> knittl: take a peak at cmd_re_sign, there is 'repository.sign_revision()' passing in a signing strategy, but it still requires a write lock and a write group to write into
<jam> cheater: ,v is the data storage of cvs
<jam> foo.c,v is the history of the 'foo.c' file
<cheater> no, i'm almost certain they were not doing that.
<jam> stored on the cvs server
<jam> cheater: (it also depends if you want ongoing conversion, or one time conversion, or...)
<jam> the short answer is that you can look into
<Glenjamin> sign_revision calls store_revision_signature which calls add_signature_text
<cheater> one time conversion
<jam> cvs2bzr my_project my_project.fi; bzr fast-import my_project.fi, though there is more documentation than that available
<cheater> mhm
<Glenjamin> do you intend to replace the company's central repository with something bazaar based?
<cheater> will it be best to convert straight from cvs to bzr?
<cheater> or say from cvs to svn to bzr?
<jam> cheater: http://cvs2svn.tigris.org/cvs2bzr.html
<maxb> cheater: The cvs2svn project (of which I'm a commiter) also supports targetting bzr. It is mature and many people have stared at its output, so the fidelity should be good
<jam> basically, the code that was used to go cvs => svn was then updated to target bzr
<knittl> this test is complicated -.-
<cheater> ok
<fullermd> You don't have to paint very far outside (or even outside) the lines in CVS to make some very tricky to deduce/convert history.  Only way to know, really, is to try.
<maxb> I have two recommendations: 1) Use the tip of trunk of cvs2svn/bzr. 2) Use bzr qlog to examine the results
<fullermd> There was a whole lotta headscratching in Postgres in their just-completed CVS->git conversion.
<cheater> can it take very long to do that?
<cheater> maxb: i don't know what "use the tip of the trunk" means
<Glenjamin> depends how big your history is :)
<cheater> about 10 years
<cheater> but the code in itself is only about 500 000 lines now
<cheater> i am guessing that shouldn't take much longer than 2-3 hours?
<fullermd> The number of revisions (which will be guesswork short of trying it) or the size of the repo would be good ballparking figures.
<cheater> i can tell you the size of the checkout
<cheater> not sure if i have access to the repo
<cheater> not sure how to get the "number of revisions" either
<knittl> AttributeError: 'TestCatSignature' object has no attribute 'add_cleanup' <- what's this?
<fullermd> 10 years old...   a commit a day?  A hundred commits a day?
<cheater> 1-2 commits
<cheater> it's really mostly been 1-3 devs
<cheater> fluctuating in size
<fullermd> OK, so that's only a few thousand revs.
<cheater> the team was fluctuating in size, that is. the devs were fluctuating in size, too, though :D
<Glenjamin> knittl: somewhere along the line something is trying to add a cleanup callback
<knittl> Glenjamin: yes, i did
<knittl> trying to add that write lock stuff
<Glenjamin> ah
<Glenjamin> i assume you copied it from a command
<Glenjamin> which has add_cleanup, the testcases probably have an equivalent
<knittl> yep
<fullermd> If it takes 2 seconds per rev to convert, you can convert 3600 revs in 2 hours.  On a reasonably sized tree, that's probably an upper bound (and I wouldn't be shocked if it were a VERY upper bound) on the time/rev.
<fullermd> Seems to me the last tree I converted was pretty small, maybe 3, 400 revs, and took something like a minute?
<knittl> Glenjamin: it's passing the tests, but i'm unsure if the way i lock the repository is the right one
<knittl> simply doing b.repository.lock_write(); b.repository.start_write_group()
<knittl> hrm. is write_group just a very bad name for 'transaction'?
<knittl> jam, Glenjamin: http://paste2.org/p/1000182
<knittl> hm. can probably remove the gpg lie
<knittl> * line
<knittl> how can i test exitcode?
<Glenjamin> knittl: the commend on line 32 is now incorrect. if you add the lock stuff into the try: and put an ensure: block which releases the lock
<knittl> what's ensure?
<Glenjamin> sorry, ruby
<Glenjamin> rescue
<knittl> well 'signed' = 'has a (dummy) signature'
<Glenjamin> no, finally
<Glenjamin> i mean a finally block.
<knittl> what's the else: block for try/except?
<Glenjamin> else is "run this if there's no exceptions"
<cheater> knittl: so what do you think, how much should that take to convert?
<cheater> knittl: just ballpark :)
<cheater> erm
<knittl> Glenjamin: so, i could just put it after the thing that throws the exception? (for that oneliner)
<cheater> *fullermd :))
<cheater> sorry!
<knittl> cheater: don't know, i don't use bazaar
<cheater> (wow, it IS hot in this office today)
<cheater> knittl: heheh yeah
<fullermd> cheater: Well, hard to say without more numbers on the size.  But I'd guess you'd have headroom at hours.
<knittl> cheater: no, i'm serious â i don't use bazaar for my own personal work
<fullermd> I'd just grab it and try an initial run to see.
<fullermd> Assume it'll be a throwaway, so you don't need to worry too much about getting trunk cvs2bzr and tweaking configs and all that, just a first blush to see how long it takes and how well it converts.
<knittl> Glenjamin: i can only create a writegroup after locking the repo. so i'd have two nested try blocks?
<knittl> Glenjamin: also, else: makes no sense for me. if i don't run into an exception, it could simply be the last statement inside try?
<Glenjamin> knittl: http://paste2.org/p/1000188
<Glenjamin> the else block isn't subject to the except
<knittl> Glenjamin: to what then?
<knittl> and hm. start_write group is outside of try in cmd_revsign
<Glenjamin> hrm
<Glenjamin> they're probably right
<Glenjamin> but the finally is the bit you need
<Glenjamin> i don't do much python stuff
<knittl> works either way (inside or outside)
<knittl> Glenjamin: can you try explaining the else: part?
<Odd_Bloke> knittl: Are you looking for a specific explanation, or just information about try, except, else?
<Glenjamin> its for statements which shouldn't be caught by the except, but should happen before finally
<Glenjamin> (had to read the bit in the manual a few times to get it myself)
<knittl> Odd_Bloke: just found it in the docs. exceptions from else: will not be caught
<knittl> ok, i think the tests are finally passing
<knittl> (again xD)
<knittl> how can i test exit status?
<knittl> i'd just use $? but i guess that's not the pythonic way xD
<Glenjamin> i think you can do something with 2> in the script runner thingy
<Glenjamin> or you might have to use the blackbox command runner thing
<knittl> run_bzr
<knittl> ah. found an assignment
<knittl> out,err = self.run_bzr
<knittl> but i'd like to also check output
<knittl> ideas?
<knittl> (without running the command twice)
<Glenjamin> presumably there are some existing tests which do this?
<knittl> ah, i'm stupid. run_bzr returns output
<knittl> which should be empty
<Odd_Bloke> knittl: Yeah, it'll be in 'out'.
<knittl> hmm. output does not match
<knittl> but when i call it from the command line it returns with 1
<knittl> what?
<knittl> oooh, run_bzr asserts against 0
<knittl> can i circumvent that?
<knittl> retcodeâ¦
<knittl> finallyx
<knittl> s/x/ â¦/
<knittl> http://paste2.org/p/1000221
<knittl> https://code.launchpad.net/~knittl/bzr/cat-signature more comments?
<jam> knittl: things should be indented 4 spaces (no tabs)
<knittl> 4?
<jam> and it should be "retcode=1" not "retcode = 1"
<knittl> ok
<jam> knittl: everything else in bzrlib is 4 spaces
<knittl> cat_signature was not â¦
<jam> knittl: ... because you wrote it?
<knittl> probably ^^
<jam> (it should be fixed)
<knittl> in the next series
<jam> anyway the test seems ok
<knittl> pushed a new version (--overwrite)
<knittl> 5 commits in total
<knittl> jam: should i make a merge proposal?
<jam> knittl: yep
<knittl> who wants to fix -r0? or should i go on and fix its symptoms?
<knittl> hm. cat_revision raises an exception â¦ which in turn makes bzr crash
<knittl> ehm
<vila> jam: ping, any news about the windows installer ?
* maxb changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | bzr 2.2.0 is officially out | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 need installers, aTdHvAaNnKcSe ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<maxb> (just tidying some dodgy spacing)
<vila> maxb: what is missing for the plugins you listed in your mail ?
<maxb> That list was generated purely based on the deb Depends criteria. *Assuming* that was correct, they need a new release compatible with bzr 2.3
<vila> maxb: ok
<vila> We haven't bumped the minimum API for 2.3 though, so that may not be needed
<maxb> When will we know whether 2.3 will contain a bzrlib api bump?
<vila> maxb: well, when it happens ;) But as far as 2.3b1 is concerned, it won't
<maxb> Maybe we should rebuild the packages just marking them as working with 2.3, and hope
<vila> maxb: yup, that's also what betas are for here, generally the API problems are encountered by people running from source
<jam> vila: Gary was working on it, but I haven't heard since
<jam> vila: why do we need the test suite to run as root ? (Versus just having selftest say "sorry fool, no running as root")
<vila> jam: because that's how the buildds works ?
<vila> jam: bug #644015
<ubot5`> Launchpad bug 644015 in bzr (Ubuntu) "bzr package build should run the test suite (affected: 1, heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/644015
<vila> jam: was there any pending problem (last you heard) ?
<jam> vila: you mean running as root? Just that it is usually a bad thing to do. but I've approved your patch
<knittl> jam: i already fixed the 4 spaces problem
<jam> knittl: well, you hadn't pushed that up yet, or LP hasn't seen it
<knittl> i have pushed
<jam> but with the minor tweaks, i think its ready
<knittl> but i only realized after merge-proposal
<vila> jam: yes, running as root, this makes sense to build packages... especially when you need to installl dependencies
<knittl> also, why empty lines? i tried to mimic code from other functions
<jam> vila: sudo works pretty well to install dependencies, without running arbitrary code as root. I'm not saying I'm going to change what their doing
<jam> knittl: most have the style I specified, if they don't, it is a bug
<jam>  s/bug/should be fixed/
<knittl> http://bazaar.launchpad.net/~knittl/bzr/cat-signature/revision/5438 here's the whitespace fix. but i'll add some newlines and push again
<jam> knittl: it is just our style guide, we're pretty consistent on it, though you may have found some exceptions
<vila> jam: sure, I was a bit scared about the test failures at one point as implying lock would not work anymore but the tests were only testing weird setup errors
<vila> jam: sudo query for the password, this should run unattended
<jam> vila: you can set up sudo to not require it. Anyway, I'm not saying we should fix the buildd code. If it is the way it is, then it is the way it is.
<jam> buildds run as vms that get wiped per install anyway
<jam> (and yes, if you have auto sudo upcast it could still do arbitrary things, but you can limit what it has access to)
<knittl> jam: pushed
<dOxxx> good afternoon...
<vila> dOxxx: Hey !
<dOxxx> vila: heya. working from home so I'm not firewalled from IRC ;)
<vila> dOxxx: I tested the mac installer
<dOxxx> vila: thanks :)
<vila> only slight tests as I did it on a mac where I barely have an account but I ran bzr explorer, branch bzr, run qlog
<dOxxx> vila: I think that's probably good enough. Any problems (that I can fix) should be pretty obvious.
<dOxxx> vila: I was wondering if we could try building the installer on your 10.5 Mac?
<vila> dOxxx: just a sec, booting it
<vila> dOxxx: ok, where do I start ? I have a running setup for bzr from source (including gcc/pyrex but no paramiko)
<vila> weird, why don't I have paramiko... >-/
<dOxxx> vila: you'll need the Qt Cocoa framework, Packages app and MacTex installed.
<vila> dOxxx: hmpf
<dOxxx> vila: MacTex is a monster
<vila> dOxxx: is this documented somewhere ?
<vila> dOxxx: well, it was years ago ;) Or was it OzTeX ?
<dOxxx> the project page for the installers https://launchpad.net/bzr-mac-installers has a brief rundown
<dOxxx> the README in the actual installer project has links
<dOxxx> I should update the project blurb...
<dOxxx> so, start off with "bzr branch lp:bzr-mac-installers/2.2"
<vila> done with branching
<dOxxx> have a look at the README in there, it should have the URLs you can download the dependencies from
<dOxxx> although I think I have subsequently switched to Qt 4.6.3...
<dOxxx> so use http://get.qt.nokia.com/qt/source/qt-mac-cocoa-opensource-4.6.3.dmg instead
<vila> dOxxx: still pyrex-0.9.8.5 ?
<vila> there is a maxtex2010, should I stick with 2009 ?
<vila> mactex
<dOxxx> vila: As far as I know newer pyrex versions interacted badly with bzr. Try the MacTex2010, it probably won't break...
<dOxxx> vila: if there is a newer pyrex that is known to work with bzr, then use that.
<dOxxx> just let me know what the version is so I can update the doc :)
<vila> dOxxx: I'm updating the README as I download ;)
<dOxxx> ok cool :)
<vila> fetch-externals is unrelated right ?
<vila> ouch, still 1h47 to download qt :-/
<dOxxx> yeah, those dependencies are nasty
<dOxxx> fetch-externals downloads all the plugins and packages that are compiled during the install
<dOxxx> so once you have qt, mactex, packages, etc. installed, you run "python fetch-externals.py -p" to download the specific versions of plugins and packages the config requires
<dOxxx> then "python build.py" will compile everything into local build directories and then builds the installer package and disk image
<vila> dOxxx: I have a python-2.6 here, but I can't remember if it's the default version or the default provided one ?
<dOxxx> python 2.5 is the default for 10.5
<vila> dOxxx: and that's it ? I just have to sign/upload the result ?
<dOxxx> yes
<vila> dOxxx: great
<dOxxx> it takes a while to compile, which is mostly pyqt's fault.
<dOxxx> it's about 30m on my wife's macbook pro
<vila> dOxxx: ouch the macbook air will suffer
<dOxxx> well, it's newer than mine so maybe, maybe not
<vila> dOxxx: will paramiko be taken into account by fetch-externals ?
<dOxxx> yes
<dOxxx> config.py lists all the stuff it downloads
<dOxxx> beware, config.py is a UTF-8 file with non-US characters in it (Japanese and Russion doc file names) so be careful if you edit
<vila> dOxxx: ok, seems fine here
<vila> dOxxx: how do you install pyrex ?
<dOxxx> pyrex needs to be installed by you for the system default python
<dobey> anyone have any idea, why if i commit 3 revisions to a branch, trying to fetch revno 3 would fail?
<dobey> http://pastebin.ubuntu.com/499279/
<fullermd> How are you trying to do that fetch?
<vila> dOxxx: done
<fullermd> I suspect you're calling an API that isn't expecting a revno.
<vadi2> How can I search across -all- revisions of a text file that is tracked by bzr?
<dOxxx> vila: I guess you're still downloading Qt and MacTex?
<dobey> fullermd: merge()
<vila> d0still dowloading qt, installing MaxTeX
<vila> meh
<vila> dOxxx: still dowloading qt, installing MaxTeX
<vila> dOxxx: ghaa, approaching disk space limits...
<vila> quick quick what can I kill
<dobey> fullermd: or more specifically WorkingTree.merge_from_branch() it seems
<dobey> fullermd: i'm trying to write unit tests for a part of tarmac that is untested with unit tests, but which does work with live branches (as i've been using it for many months now)
<fullermd> dobey: Well, I'm not authority on the API.  I just suspect you're at far too low a level for it to accept revno's.  You'll probably need to manually parse that to a revid (or maybe a revision object of some sort?  I have no idea...)
<dOxxx> vila: yeah sorry about that. tex is stupid big.
<vila> dobey: if you're writing tests you can force the revids, easier to reuse then
<dobey> fullermd: nah, it accepts revnos. because that's what we've been passing in, with the live runs
<dOxxx> vila: I just remembered another dependency that I forgot to add to the README... Sphinx. :P
<vila> dOxxx: hehe, yeah, I blame *you* for TeX size :-D
<dOxxx> vila: ;_;
<vila> dOxxx: sphinx... which version ?
<vila> dOxxx: 1.0.4 ?
<vila> dOxxx: 1.0.4 installing.... grabbing docutils, jinja, kitchen sink and pygments
<dOxxx> vila: apparently I had 0.6.4 installed
<vila> dOxxx: hmm, will see
<dOxxx> I don't have a download tarball so I must have used easy_install
<vila> dOxxx: for 2.5 ?
<vila> I have it for 2.6 but not for 2.5 here...
<vila> dOxxx: still 43 minutes to go for qt
<vila> dOxxx: this is so last century dl speed ;)
<dOxxx> haha
<dOxxx> is easy_install a 2.6 thing?
<vila> dOxxx: could be, I vaguely remember having upgraded to 2.6 for it
<vila> dOxxx: have you built the 2.3b1 installer ?
<vila> dOxxx: well, I mean, is there any difference for the 2.3b1/10.5 installer
<dOxxx> vila: yes, I'll upload now. also have the 2.1.3 installer done.
<vila> dOxxx: cool
<dOxxx> 2.3b1 I build using tip versions of all the plugins
<dOxxx> hmm upload is making remote desktop to work computer somewhat laggy :P
<dOxxx> vila: 2.3b1 and 2.1.3 uploaded
<vila> dOxxx: excellent
<dOxxx> vila: release pages updated. formatting is a little wonky though, I don't grok the wiki formatting language yet
<vila> dOxxx: don't worry, 1) the content is more important, 2) I can fix it later
<jml> guys
<jml> can you please implement a visual AST-based diff for bzr?
<jml> that'd be great, thanks.
<jml> bye.
<dobey> oh bzrlib, she is a harsh mistress
<vila> dOxxx: but once it's uploaded, just mention it in the 'DONE' section instead of the 'IN PROGRESS' one
<vila> dOxxx: look at the 2.2.1 page, I've updated it
<vila> dOxxx: I even broke the formatting :)
<vila> dOxxx: fixed :)
<dobey> lifeless: can you see anything obviously meaningful in http://pastebin.ubuntu.com/499279/ as to why bzrlib would tell me that revision 3 doesn't exist, when it was just committed?
<dOxxx> vila: well I've put it in the in progress section because the 10.5 installers aren't done yet but I suppose I could separate them
<dOxxx> vila: I'll update the other pages
<vila> dOxxx: yup, that's what I did for 2.2.1
<vila> dOxxx: thanks
<lifeless> dobey: not without context
<lifeless> dobey: you might, for instance, have a read locked repo already which won't see new info until you refresh/unlock-readlock it
<dobey> hmm
<dOxxx> vila: release pages updated
<vila> dOxxx: perfect
<dobey> lifeless: hm, is_locked() is saying it's not locked
<vila> dOxxx: installing Qt...
<dOxxx> vila: woot woot
<vila> dOxxx: fetch-externals: no module named bzrlib ;)
<dOxxx> hmm... I suppose I should mention that it requires bzr installed too? :)
<vila> any version ?
<dOxxx> yeah whatever works to fetch the branches required
<vila> k
<dOxxx> I started originally with 2.0
<vila> dOxxx: seems ok with trunk :)
<vila> dOxxx: you should use doc.bazaar.canonical.com instead of doc.bazaar-vcs.org though
<dOxxx> where?
<vila> dOxxx: dunno, saw the urls pass in the output
<vila> dOxxx: for the pdfs ?
<dOxxx> vila: oh, yeah, if you're using the -d option on fetch-externals.py, you don't need to since they're now built using sphinx. I need to remove that option from fetch-externals.
<vila> dOxxx: no urgency but if the redirection is ever broken in the future
<vila> dOxxx: hehe, I'm fllowing the README :)
<vila> following
<dOxxx> vila: good on you sir. it is I who is the forgetful slacker that has not updated it.
<vila> dOxxx: hehe, don' t worry, any more hints before I run build.py ?
<dOxxx> vila: my only exuse is that sphinx support was the thing I was experimenting with most recently, so it isn't "final"
<dOxxx> um...
<dOxxx> so, you have the Packages app installed?
<vila> dOxxx: yes
<dOxxx> then I think you're good to go.
<vila> dOxxx: MacTeX, qt, sphinx, pyrex
<vila> fire
<vila> dOxxx: I should say that I'm impressed, things have gone pretty smoothly (bar qt download ;)
<vila> sphinx runnign
<vila> hmm, errors and warnings there :-/
<dOxxx> dang
<vila> weird, this doesn't seem to stop it
<dOxxx> >_>b
<vila> ha, may be new with sphinx-1.0.4...
<dOxxx> I honestly don't recall if there are errors and warnings during the sphinx phase when I build it using 0.6.4. I just start it and then go do something else for 30 minutes, come back, curse at the error that occurred after 5 minutes, fix it, rinse repeat.
<vila> dOxxx: is says build succeeded
<vila> ha, pdflatex not found :-(
<vila> dOxxx: do I need something in my PATH for MacTeX ?
<vila> dOxxx: /usr/texbin ?
<vila> dOxxx: works better
<vila> dOxxx: don't forget that we haven't yet officially switched to sphinx, so report any bugs you encounter there
<vila> dOxxx: hihi Overfull \hbox, I had almost forgotten that one :)
<vila> dOxxx: compiling SIP, what's that ? :D
<vila> dOxxx: pyqt now
<dobey> how can i make lp:foo point at file:///blah/blah/blah/tmpdir-bzrblahblah/branch instead of giving me the 'invalid protocol' error, through bzrlib?
<dOxxx> dOxxx: hmm... I think I did encounter some path issue with finding pdflatex
<dOxxx> err right talking to myself again
<dOxxx> vila: Hopefully I can change the build script to deal with the path issue
<dOxxx> vila: looks like I made symlinks in /usr/local/bin. I hadn't noticed /usr/texbin. That's a much better solution. :)
<vila> dOxxx: pure luck ;)
<vila> dOxxx: it's mentioned in the What is Installed.pdf for MacTeX... err no, I *mistyped* /usr/tex instead of /usr/local/tex  and found it ;)
 * vila kills one more chicken
<DanielCordeiro> Hi, I'm having a little problem with bzr and I would like your help. :) *Sometimes* I'm getting an "bzr: ERROR: [Errno 5] Input/output error" that doesn't allow me to do even basic operations such as "status".
<dash> are you using nfs?
<DanielCordeiro> Yes.
<dash> well, that's why
<DanielCordeiro> :(
<DanielCordeiro> It is supposed to not work when using NFS?
<dash> i think it's _supposed_ to work, but it doesn't
<DanielCordeiro> :)
<DanielCordeiro> It is strange. I always used bzr in a NFS filesystem and never had any problem.
<dOxxx> vila: are you fixing this in build.py or should I?
<vila> dOxxx: please do, it's still running here, I just did export PATH=$PATH:/usr/texbin and mentioned it in the README
<DanielCordeiro> Is this problem documented anywhere or is there any workaround?
<dOxxx> ok
<dash> there's a bug open for it
<DanielCordeiro> I have submitted a bug report also, I will update it and tell that I'm using NFS. :P
<dash> https://bugs.launchpad.net/bzr/+bug/137387
<ubot5`> Launchpad bug 137387 in Bazaar "close or truncate of os-locked file gives EIO on some NFSv4 servers (dup-of: 98836)" [Low,Incomplete]
<ubot5`> Launchpad bug 98836 in Bazaar "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability (affected: 12, heat: 156)" [High,Confirmed]
<dOxxx> vila: btw, the way I've been trying to manage the branches for the installer is that tool changes, like fixing this pdflatex thing are usually made on trunk and merged to the different branches, and changes to the config.py for a particular version are made on the corresponding branch.
<dOxxx> vila: although that does usually have some trouble with conflicts merging from trunk due to its own config.py changes
<vila> dOxxx: that seems to be the good workflow... but you can also try to do such a fix in the lowest branch and merge up instead, that should create *less* conflicts
<vila> dOxxx: kind of daggyfix, you fix the bug at its first occurrence (the oldest branch)
<vila> dOxxx: bzr should then recognize some changes as already taken into account and merge only the new ones
<dOxxx> vila: how do I avoid the branch config.py changes merging into trunk's?
<DanielCordeiro> Thanks for the link to the bug report, dash.
<knittl> knitpack != format 2a?
<fullermd> Correct.
<vila> dOxxx: you can't at the first merge, but the subsequent merges should respect what you decided at the first merge
<knittl> k, thanks
<knittl> does anybody have an bzr-svn project at hand?
<knittl> oh wait. i have myself
<knittl> :d
<vila> dOxxx: should I expect the same amount of time to create the other installers or are there some components reused ?
<dOxxx> vila: there is no re-use of components between branches of the installer except what you installed by hand
<vila> dOxxx: ok, makes sense, was just trying to estimate if I will be able to build another one before falling asleep...
<dOxxx> vila: so if you want to build 2.3b1, you'll need to get the 2.3 branch and do the fetch-externals & build thing again
<dOxxx> vila: theoretically, you should be able to "python fetch-externals.py -p && python build.py" in the branch and let it run
<vila> dOxxx: yup
<vila> dOxxx: qt just finished compiling
<dOxxx> vila: ooh ouch
<vila> hu ho compile error in subvertpy
<dOxxx> vila: yeah I get errors and warnings from sphinx too
<dOxxx> vila: hmmm
<dOxxx> vila: then I guess that subvertpy 0.7.3.1 still doesn't include the correct fix.
<vila> dOxxx: meh, but you were able to compile it for 10.6 right ?
<dOxxx> yes, it's specifically a problem with svn 1.5 that's installed on OSX 10.5
<vila> http://paste.ubuntu.com/499341
<dOxxx> vila: try changing the subvertpy block in config.py to this: http://pastebin.com/dmkxtfNe
<vila> dOxxx: I didn't install svn at all should I ?
<dOxxx> oh hmm
<dOxxx> no
<dOxxx> it's already installed
<dOxxx> that's a different error
<dOxxx> from what I recall
<dOxxx> try using the config block I pasted above
<dOxxx> that uses the specific revision that jelmer fixed the bug in for me
<dOxxx> there may be other changes since then which are included in 0.7.3.1 that are breaking it
<dOxxx> you'll need to use "python fetch-externals.py -p" after you've changed the config
<vila> ok, done, I had to ctrl-C the build, any problem with at ?
<dOxxx> nope
<vila> k
<dOxxx> just run build.py again
<dOxxx> it used to start from scratch but that was such a pain in the ass, I made it preserve the build results and added an explicit clean command
<vila> it seems to re-run a lot of sphinx related stuff though ;)
<vila> but as long as it doesn't recompile qt, I'll be happy :)
<vila> dOxxx: hmm, back to fetch-externals, I previously missed the 'branch' part (manual copy/paste doesn't work well ;-/)
<dOxxx> vila: did fetch-externals not give you an error message the first time?
<vila> dOxxx: it says: revno mismatch in subvertpy, expected 2219 but was 103
<vila> dOxxx: no it didn't
<dOxxx> vila: uh, add the -u option to fetch-externals.
<dOxxx> vila: fetch-externals could do with some smarts about when and what it needs to update/download. :(
<vila> argh, not a branch %2bBranch, blah blah, propably need an already resolved url
<dOxxx> that used to work, I don't know what it doesn't anymore
<dOxxx> I think lp:subvertpy used to redirect to jelmer's repo on samba.org but not anymore
<dOxxx> I ran into the same problem yesterday and I had to use the samba http URL directly
<vila> dOxxx: or a lp bug
<dOxxx> vila: I've updated lp:bzr-mac-installers/trunk to add /usr/texbin to the PATH in build.py so that sphinx can find pdflatex. I'm going to merge it across to the other branches now.
<vila> dOxxx: works with the http@samba url
<dOxxx> k
<Crshman_> How can I tell who made what change in a bzr diff?
<dash> Crshman_: 'bzr blame'
<Crshman_> what about removed lines that are no longer in the file?
<vila> dOxxx: woohoo build succeeded !
<dOxxx> vila: awesome!
<vila> dOxxx: congrats for all your hard work !
<dOxxx> vila: but now does the installed product work? ;)
<vila> trying
<dOxxx> vila: btw I've merged the pdflatex PATH fix into 2.2 and 2.3 branches, the 2.1 branch is somewhat out of date so there's a lot more to merge. I'm somewhat reluctant to do that now until we decide that we need an installer for 2.1
<vila> dOxxx: I'm fine with no installers for 2.1.3 and 2.0.6 but I thought you already did one ?
<dOxxx> yeah, it uses the downloaded pdf docs
 * maxb wonders whether we *really* need a special postinst script in our PPA packages to tidy up after broken bzr-beta-ppa packages in the 1.6rc era
<maxb> poolie: You around? ^^^
<vila> dOxxx: by the way, it would be nice if we can create some shortcut to launch bzr-explorer *without* needing access to Terminal...
<dOxxx> vila: it would. that needs a .app bundle, and I think there's a bug on the bzr-mac-installers lp project with one that somebody assembled. I just haven't investigated any further to see what's necessary to integrate it into the installer build.
<vila> maxb: I don't think we still need them except for very old releases for people doing a very late upgrade ???
<dOxxx> vila: I think it also suffers from a problem where there might be password prompts in the console when using bzr-explorer but that wouldn't be visible with a .app bundle
<vila> dOxxx: I don't think so, the only remaining case that I can think of is related to ssh on windows but that shouldn't be a problem on OSX, the provided ssh agent (wait it *is* provided right ?) works quite well for me
<vila> dOxxx: I had to switch to a different user to test, *my* setup can't use the just-installed bzr without to much tweaks
<vila> dOxxx: works
<dOxxx> vila: it works? woohoo!
<maxb> vila: The key thing here is that the bug was only in 1.6beta packages ever, so presumably only ever from the bzr-beta-ppa
<vila> maxb: then shoot
<vila> dOxxx: so I should rename the img and sign it right ?
<vila> dOxxx: or is there a script for that ?
<dOxxx> no script for that. rename it to include "OSX-10.5" in the name like I've done for the 10.6 images
<dOxxx> then gpg -ba to sign it
<vila> dOxxx: I need so start my Ubuntu vm for that :-) :-/
<vila> or copy it elsewhere instead
<dOxxx> vila: ah bummer
<dOxxx> vila: I plan to make the build produce the correct dmg filename according to the OS version
<dOxxx> vila: however I don't think I can help you with the signing problem :)
<vila> done :)
<poolie_> hello vila!
<vila> poolie_: hey !
<poolie_> you're up late
<vila> poolie_: no no, you don't have to go back to sleep :)
<poolie_> :)
<vila> poolie_: yeah, helping dOxxx building the OSX 10.5 installers
<dOxxx> with vila able to build the 10.5 installers, we can probably get them done pretty soon after the source release, barring any problems with plugin versions.
<vila> dOxxx: uploading
<maxb> *right*, finally finished unpicking the status of the ppa hardy branch
<vila> maxb: targeting the bzr-beta-ppa right ?
<vila> maxb: will there be a point that we can reuse for the 2.0.6 SRU ?
<vila> dOxxx: pushed a branch with my tweaks, do you want a merge proposal or will you just pick the rights bits ?
<dOxxx> vila: ehh I'll just merge it myself, what's the branch name?
<knittl> is there something like an inventory_id?
<vila> dOxxx: lp:~vila/bzr-mac-installers/tweaks-for-10.5
<dOxxx> and that was for 2.2?
<vila> dOxxx: yes
<dOxxx> k
<vila> dOxxx: sry, I jsut realized I should have specified that in the branch name, on the other hand... there is some history in this branch anyway :-D
<dOxxx> vila: yeah no worries. I'll also merge the appropriate stuff into the 2.3 branch too so that you can build that without futzing.
<vila> dOxxx: so, for the 2.3 branch, f-e -d -u ?
<dOxxx> for 2.3 you shouldn't need the -d option, it will just build docs using sphinx
<vila> dOxxx: oh, ok, I should wait then ?
<dOxxx> yeah go to bed, we can finish this tomorrow :)
<vila> errr, I meant -p -u
<vila> yeah, babune just started eating all the PC CPU anyway ;)
<dOxxx> nomnomnom?
<vila> perfmeter for the 4procs/8threads close to 100% yeah, nomnom :)
<dOxxx> haha
<vila> dOxxx: one last thing: config.py is really nice, what would be even nicer is a way to output some summary of which versions are used for all the compoenents
<vila> dOxxx: bzr plugins won't be as precise as what you allow there
<vila> dOxxx: I don't have a clear definition of what I want but something that will allow us to quickly check/compare the various releases across the platforms
<dOxxx> vila: I think I understand. I'll give it some though.
<dOxxx> thought*
<vila> dOxxx: cool, thanks
<vila> poolie_: before I quit
<poolie_> sure
<vila> poolie_: I fixed some more bugs on the SRU paths, but I still haven't nominated the bugs (see my mail)
<poolie_> that's great, thanks
<knittl> http://wiki.bazaar.canonical.com/BazaarFormats this page is long outdated, rigtht? no format2a â¦
<vila> poolie_: if  you could shepard the SRU a bit (at least the maverick one, I think we have more time for the others), that would be nice
<poolie_> knittl, probably, deletede
<poolie_> vila, ok, sure
<poolie_> i'll do the nominations today
<poolie_> thanks for pushing on the bugs
<poolie_> thanks too for posting about the namespace convention
<vila> poolie_: great thanks, see my mail, the urls are there ;)
<knittl> poolie_: deleting does not do any good
<vila> poolie_: well, not the easiest subject to start open my mouth it seems, rest assured that my intentions were friendly and accept my apologies if I hurted anyone
<knittl> i've followed many dead links inside the wiki and only got mad at it
<poolie_> i deleted it
<poolie_> :(
<poolie_> vila, i don't think anyone is hurt
<poolie_> i hope you're not
<poolie_> knittl, in general i'd rather have docs in the docs tree
<poolie_> if there are broken links let's clear them up, either in the wiki or by pointing to docs
<poolie_> vila, we're just trying to find the best solution together
<knittl> poolie_: well, that sounds like adding a hint to visit some other site might be a good idea
<knittl> not to confuse users
<poolie_> knittl, where were you looking to end up on this page
<poolie_> hi sidnei
<sidnei> hi!
<knittl> poolie_: i don't know, found it somewhere, maybe in the wiki, maybe on google
<knittl> was still in my bookmarks
<fullermd> Mmph.  Is there a good reason 'tags' doesn't accept a branch as an arg?
<knittl> that wiki reads like legacy information anyways
<poolie_> as i say we're mostly putting docs in to doc.bazaar.canonical.com
<poolie_> the wiki could do with a good scrub to remove old information
<knittl> put a banner on top of every page: this wiki is outdated, please see docs.blah for current docs
<poolie_> hm, good idea
<poolie_> there are a few pages that are meant to live in the wiki
<fullermd> Urg.  If the pages are really outdated, they otter just be deleted, not enheadered...
<poolie_> right
<knittl> it's lost information though. no historic record
<knittl> i don't know where to look for past formats now
<poolie_> well, i think they'll still be documented in the in-tree docs
<poolie_> the docs for our previous releases are available on the doc web site
<poolie_> and the wiki is presumably in webarchive.org if you really want to see what we said about formats 2 years ago
<fullermd> And the wiki still stores the history anyway, neh?
<knittl> fullermd: not if the page was deleted
<knittl> and i'm going to bed now. good night!
<fullermd> Really?
 * fullermd adds another to his list of reasons wikis are bogus...
<fullermd> Wiki: Just like a VCS, but dumber!
<mwhudson> wikkid!!!
<mkanat> ISTR some people making a wiki based on a VCS.
<mkanat> Would be possible if your VCS was fast enough.
<knittl> fullermd: yes, it's pretty much like a CVS ,v file. if you delete it, history is gone too
<fullermd> Well, sure, but you don't delete RCS files (unless you intend to have that effect), you just Attic'ize 'em.
<cheater99> hi
<cheater99> i am thinking about using bzr or git or hg for my new project
<cheater99> what should i be using?
<cheater99> also: why is bzr better than git?
<dash> bzr. duh.
<fullermd> bzr.  Or git.  Or hg.
<mkanat> cheater99: There are some things that I like about bzr more than git.
<dash> cheater99: less crazy UI, more flexible, actually updates svn mergeinfo when interacting with svn :)
<mkanat> cheater99: I like the fact that it explicitly supports directory and file renames.
<mkanat> cheater99: Also, I like the fact that it works well on Windows and is easy to install there.
#bzr 2010-09-24
<mkanat> cheater99: Also, for people who are familiar with CVS or Svn, it has a basically-compatible command set.
<mkanat> cheater99: And finally, it can do remote operations, which git cannot.
<cheater99> ok
<mkanat> cheater99: git's advantage is that it is ridiculously, blindingly fast.
<cheater99> what's the slowest thing in bzr?
<mkanat> cheater99: Probably annotate, like every DVCS (git and hg will be the same). Also, "bzr log -v" can be slow on large projects.
<poolie_> interesting question
<poolie_> 'check' is probably the least optimized code
<cheater99> what is the slowest thing in bzr that is comparably very fast in git?
<mkanat> poolie_: But also one that normal users will almost never be running.
<poolie_> probably also check
<cheater99> what about local branching?
<poolie_> bzr being in python has a startup time overhead of a fraction of a second on each command, which git doesn't have
<cheater99> how does that work out?
<cheater99> aha
<mkanat> cheater99: If you have created a "repository" with bzr, local branching is very fast.
<cheater99> but can't you have a python daemon..
<poolie_> bzr commit was recently measured (benchmarks are all bogus) as faster than hg
<poolie_> which didn't used to be true
<cheater99> mhm
<mkanat> cheater99: The day-to-day difference of speed using bzr and git makes no significant difference in my development productivity.
<cheater99> but if you have a running python process already then there's no startup overhead
<mkanat> cheater99: But if I had 100,000 commits in my repo, that might be a different story.
<mkanat> cheater99: The startup overhead is not something that's going to affect your productivity.
<mkanat> cheater99: There isn't any common operation where there isn't a linear difference between bzr and git.
<cheater99> aha
<cheater99> that is good to know
<poolie_> cheater99, there is a plugin that gives you a longrunning python process
<poolie_> and then a c program that passes commands to it
<mkanat> poolie_: That's cool; I didn't know that.
<cheater99> nice
<mkanat> cheater99: Also, I suppose one of the advantages of bzr is that you go into #bzr and the project lead helps you out, there. Hahaha.
<mkanat> (Although actually, pretty much everybody in this channel I've found to be pretty helpful.)
<cheater99> who's the project lead?
<mkanat> cheater99: poolie
<cheater99> ah
<cheater99> nice
<cheater99> hi
<cheater99> also, very different experience from the git channel :)
<mkanat> Yeah.
<mkanat> Where you go in and people insult you because you're not doing it right. :-D
<mkanat> (Well, not always, though. Sometimes #git is helpful.)
<cheater99> that's sadly the kind of experience i got
<cheater99> what do you think is missing most in bzr?
<poolie_> ah, cleaner colocated (git-style) branches
<poolie_> s//and built-in
<poolie_> ditto built in nested trees aka submodules aka externals
<cheater99> is it far off?
<cheater99> i guess it doesn't matter that much though :)
<cheater99> bzr feels very solid
<cheater99> what i really like about it is the manuals are so friendly
<cheater99> big difference from cvs, git, svn, rcs, ..
<cheater99> can i somehow make bzr version files inside archives?
<poolie_> how do you mean?
<cheater99> well
<cheater99> some applications save documents as archives. for example, mysql workbench
<cheater99> it has this .mwb file format, which is in fact a zip with xml and other ascii files in it
<cheater99> :)
<fullermd> cheater99: The answer to that is "no, but it comes up from time to time"
<cheater99> cool
<cheater99> i would need to convert from cvs to bzr.
<cheater99> will that make historical commits in cvs atomic?
<mwhudson> most of the conversion tools put some effort into that, yes
<cheater99> cool
<cheater99> does that actually work?
<cheater99> the repository i'm talking about isn't huge
<fullermd> Often   :)
<cheater99> and it wasn't extremely busy
<cheater99> about up to 5 developers at any time... doing just a handful of commits every day
<mwhudson> should be fine
<cheater99> that will atomize the non-atomic commits in cvs?
<cheater99> really?
<cheater99> nice!
<cheater99> hm, one thing that would be cool: to be able to use bzr for my editing buffer in vim ;)
<cheater99> for undo/redo
<cheater99> :)
<fullermd> Well, most converters try.  CVS makes it difficult to be sure of success, so results vary.
<cheater99> that's cool though
<cheater99> after all we're not talking about rocket brain surgery
<fullermd> If you haven't done repo surgery, or a lot of cross-branch work, it usually turns out OK.
<cheater99> not at all
<cheater99> i would say, maybe 3 concurrent branches at most
<fullermd> Well, things like having a file on one branch that are later added to another branch can be squirrely.  And figuring branch points is educated guesswork.
<fullermd> It really just ends up as "try and see".
<jbowtie> cheater99: I'm drafting a blueprint specifically for that use case (diffing and merging zip files)
<fullermd> (that's not bzr-specific; it's the "figure out what actually should have happened from CVS records" side of things)
<cheater99> jbowtie: nice!
<cheater99> jbowtie: any cool bits to talk about? :)
<jbowtie> The proposal is specifically for working with free software formats that we currently treat as unmergable binaries.
<cheater99> yes
<cheater99> but then i ask myself
<cheater99> if a zip has a zip in it
<cheater99> you will have to merge recursively.
<jbowtie> For zip files (and variants and other archives) we should be able to treat them as folders.
<cheater99> and then you are really defining a new "dimension" of files
<cheater99> so not only horizontally across the file system
<cheater99> but also vertically inside files.
<jbowtie> And we already know how to merge folders recursively.
<cheater99> yes
<cheater99> i guess if you think of it that way
<cheater99> then it becomes easy
<cheater99> a folder is just a different "file format" then
<cheater99> and then, i guess, other formats which do not depend on zip etc, but still have some sort of modules in them, could possibly have a plugin that talks to some sort of api
<jbowtie> Well, there are going to be performance issues working with archives (particularly tar files) but the improved user experience should make up for it.
<cheater99> yes
<jbowtie> Yes, that's what I really need to pin down in the blueprint proposal - what the API looks like.
<cheater99> but those "performance issues" should only happen when they choose to merge, right?
<dOxxx> any operation that requires accessing the contents of the files is going to incur some overhead from decompression
<cheater99> i think the simplest api would be: present the plugin with both files to be merged, expect a third file in a special location :))
<jbowtie> Correct; I imagine in the first iteration of an implementation you'd have to turn it on via plugin.
<cheater99> dOxxx: that's obvious :)
<dOxxx> that's me, captain obvious :P
<cheater99> jbowtie: but if you want your merge to only overwrite?
<cheater99> jbowtie: you'd need to have a special way to do that too
<cheater99> i.e. i want to merge, but all my binaries overwrite remote binaries.
<dOxxx> something like that might be possible with the per_file merge hooks
<cheater99> ah
<dOxxx> there's already a plugin that handles merging of NEWS files specially
<cheater99> but, that's a bit crappy not to have this granularity then and there
<jbowtie> We just need to make sure the merge hook API covers our scenarios, and add corresponding diff hooks.
<cheater99> i would even like to be able to say "bzr always-overwrite-on-merge myarchive.tgz"
<dOxxx> yeah, I'm not sure how configurable it is, whether it can selectively operate on some files some of the time
<jbowtie> What you do is have your plugin use the hooks, then make the plugin configurable.
<cheater99> :)
<dOxxx> theoretically, the plugin could add a file to the .bzr directory in the branch which contains a list of files that have to merged specially
<cheater99> btw
<cheater99> can i use bzr with github?
<cheater99> not as the main repository
<cheater99> but just so that i can use github statistics, graphs, and all that silly stuff
<jbowtie> But I'm also looking at more complex scenarios, like merging Photoshop files - the diff and merge works on layers instead of lines of text.
<cheater99> yes
<jbowtie> Yes, just use the bzr-git plugin.
<cheater99> i guess you'd need a graphical log then huh?
<cheater99> displaying graphics :)
<cheater99> i really like this jbowtie
<jbowtie> I think you need to work with the GIMP folks to see what can be reported in text (layer names perhaps) as well as hooks for the (existing) graphical diff tools.
<jbowtie> My goal is to ultimately make bzr a good experience for artists as well as programmers.
<mkanat> jbowtie: Does bzr even do binary deltas right now?
<jbowtie> Working on, say, a game, you should be able to version your art assets in the same repository as your code assets.
<mkanat> jbowtie: That would definitely fix the third common unanswerable question that people come in here with.
<mkanat> jbowtie: "I have this repository with these 20GB files in it, and..."
<jbowtie> mkanat: I'm pretty sure it does, but diff and merge is reduced to (these binaries differ) and (choose mine or theirs) respectively.
<jbowtie> mkanat: Though I'd actually have to look at the branch format to see how it stores things.
<mwhudson> the problem of course is that compressed content doesn't diff well, on the whole
<mkanat> jbowtie: *nod*
<cheater99> jbowtie: great idea
<mwhudson> hard to squeeze out entropy in two ways at once
<cheater99> jbowtie: does it let you interactively download and open the two binaries?
<cheater99> jbowtie: so that you actually know what you're overwriting,
<cheater99> and so that you can open it in, for example, photoshop.
<jbowtie> cheater99: Yes, if you use qdiff right now it shows you images side-by-side, that sort of thing.
<cheater99> yeah but what if they're, say, UnrealED maps.
<cheater99> i need to open them in the level editor
<cheater99> (just giving you an idea of where you need access to the files)
<jbowtie> cheater99: That's the point of the blueprint I'm drafting; so you have an API that lets plugins hook in and provide that for both diffing and interactively merging.
<cheater99> yep
<cheater99> but that api won't be implemented for everything!
<cheater99> so the situation i describe will still be the default for most things..
<jbowtie> Absolutely - but we'll start by handling zips (I would think) and start talking to the main free software artist tools.
<jbowtie> Once we've got a decent API and good examples to build of off, people will be able to write plugins for any binary format.
<jbowtie> And we always have a fallback for generic, unhandled binary files, which is the current behaviour.
<cheater99> yup
<cheater99> :)
<cheater99> i'm off to sleep, cya guys!
<cheater99> thanks for the info!
<cheater99> :)
<dOxxx> ciao
<mkanat> poolie: I'm going to do some loggerhead research and possibly some work today. :-)
<poolie> mkanat: nice
<mkanat> I can't help but feel like loggerhead.config is a reinvention of a wheel that exists somewhere else.
<mkanat> It's not that complex, though.
<mkanat> There's got to be duplicate code in bzrlib, though, since it's doing very bzr-ish things.
<mkanat> In fact, looking over the general startup code for loggerhead, I'm tempted to join the "this should entirely be a bzr plugin" camp.
<mkanat> Man, there's a lot of Paste stuff in loggerhead, strewn about. :-(
<mkanat> Largely because Paste itself does too many things.
<mkanat> jam: Does the existing bzr-history-db stuff do on-disk file locking? That is, would multiple loggerhead processes running be OK?
<mkanat> I assume it does, and that it's just part of the normal bzr locking mechanisms.
<poolie> mkanat: i think that's correct
<poolie> it uses a pack db i think, which is multi writer safe
<mkanat> poolie: Okay.
<jbowtie> poolie: Did you need any supporting material for my CV?  Last time I asked you were still waiting on HR.
 * poolie looks
<poolie> i still am waiting :/
<poolie> will ping them tonight
<poolie> actually can you send me a copy direct, in parallel?
<jbowtie> Sure, will do.
<jbowtie> poolie: Sent through to your canonical account.
<poolie> thanks
<mkanat> poolie: I'm starting to lean toward's lifeless's suggestion of making a 1-thread paste server and running it multiple times, and just putting it behind a proxy.
<poolie> ok, interesting
<poolie> why behind a proxy?
<mkanat> poolie: The reason being that Paste is sort of littered throughout the code.
<mkanat> poolie: For load-balancing.
<mkanat> poolie: That is, we simply would run serve-branches four times, on four different ports, on a four-core machine.
<mkanat> Or we'd run it 10 times, if we wanted to be able to handle 10 simultaneous requests.
<poolie> you know you can actually have multiple processes listening on the same port
<mkanat> poolie: Yes, with a master + forking situation.
<mkanat> poolie: Which would be Spawning, then, not Paste, since Paste can't do multi-process.
<poolie> doesn't SO_REUSADDR let you bind a port that's already open?
<mkanat> poolie: Unless you just mean have the process release the port when it's working, and then wait in a queue.
<poolie> imbw
<poolie> i'm just saying it seems nice to avoid adding a proxy if it's only going to distribute work across ports
<mkanat> poolie: What lifeless suggested is what Launchpad does now.
<mkanat> poolie: The advantage is that it's just a configuration change.
<mkanat> Although I'd have to test it locally and make sure that running multiple loggerhead processes actually works.
<mkanat> poolie: The scaling problem is only a problem at Launchpad, AFAIK.
<poolie> ok, that makes sense
<mkanat> poolie: The complexity of threading is a problem everywhere, so it would still be nice to switch to a multi-process model, and I'd love the code cleanup that would involve. But I feel like the best time investment might be to investigate the 1-thread paste server solution.
<GungaDin> how do I get the source for bzr-rewrite? using bzr?
<GungaDin> I have the url for trunk... but how do I check it out?
<GungaDin> doesn't seem to be a repo
<poolie> GungaDin: 'bzr branch lp:bzr-rewrite' doesn't work?
<GungaDin> will try
<GungaDin> works
<GungaDin> thx
<mkanat> poolie: Next time I work on loggerhead I'm probably going to try out the 1-thread system and see if it works and what would need to be fixed.
<jbowtie> spiv: Thanks for reviewing those doc patches so quickly.
<jbowtie> I was thinking that more of those links should be turned in Sphinx ref directives, might reduce link breakage bugs.
<spiv> jbowtie: yeah, that sounds good
<spiv> jbowtie: we only switched to just Sphinx relatively recently
<spiv> Before that we were a bit limited by also supporting plain docutils.
<GungaDin> I've accidently rebased a branch and I'd like to undo it... how can I do that?
<GungaDin> (using bzr rebase)
<spiv> GungaDin: Perhaps with 'bzr pull --overwrite -r revid:OLD_REVID', if you know the old revision ID (or can find it with 'bzr heads' from the bzrtools plugin)
<GungaDin> something very weird happened.. because I specified a branch I had merged into and not the parent branch
<GungaDin> and now both branches looks the same
 * spiv -> lunch.  Looking forward to some replies from PQM when I get back...
<anteru> Good evening
<anteru> http://img137.imageshack.us/img137/2454/bzr3.png (some more work on a new website)
<anteru> (for bzr, that is :) )
<poolie> hi there anteru
<poolie> spiv could you take a pass through the New bug queue?
<anteru> Slow progress, as I'm investing 1 hour every two weeks or so right now, busy with work...
<poolie> it's good
<poolie> i wonder if the command-line samples are a bit too directly derivative of the git homepage?
<anteru> hg has the same :)
<poolie> also, to me, the different shades of blue kind of clash with each other
<anteru> Yeah, the colors are crap, I need to fabricate a few images later on.
<anteru> And I still wonder how to place the explorer screenshot
<anteru> after all, it's a usp for bzr
<poolie> right, i think we want to communicate both the gui and cli bits
<jbowtie> I assume you're going to align the second block to the grid at some point?
<anteru> I'm going to pull a grid over this really soon now, wanted to get the big fat bazaar text right today.
<anteru> navigation will be close to what ubuntu.com has, that shouldn't be a problem as it's canonical here as well
<anteru> I wonder if someone agrees that it's enough to have the version number at the downloads instead of having it below the bazaar text?
<anteru> At least for me as a user, I'm going to search the version at downloads, to see if X.Y is available for my OS.
<jbowtie> I agree, though it would be good if a major release made a bit of a splash on that page - is there an obvious place for that?
<poolie> agree
<poolie> i like having the blog and announcements syndicated there
<poolie> above the fold
<poolie> also it kind of sucks to say "no test release"
<poolie> let's just omit that if there is none
<anteru> well, you could always add a big 3 next to bazaar
<anteru> Ok, taking some notes: Different color scheme, gridified layout, place for syndication, less version numbers.
<jbowtie> For the color scheme you might want to see what the full Ubuntu palette looks like (I'm sure they have compatible shades of yellow and blue to go with their dominant colors)
<jbowtie> Once you've nailed down the grid I'll start overhauling the documentation templates to coordinate.
<jbowtie> That'll probably bring up color issues with the images in the doco.
<anteru> Do you have a link to the ubuntu color scheme?
<jbowtie> I'd probably start on design.canonical.com - I'm just running off to a meeting or I'd hunt it down.
<anteru> Ok, thanks!
<anteru> Should do it
<anteru> Found the color palette
<GungaDin> when merging only several commits, how come you can't see the merged commits in qlog?
<anteru> You don't see the plus sign?
<GungaDin> nope
<GungaDin> just one commit
<GungaDin> without a plus sign
<anteru> and bzr log --include-merges shows it?
<GungaDin> qlog doesn't accept that. and with just log doesn't seem so .
<anteru> If bzr log doesn't show it, then it's not a qlog problem.
<anteru> Are you sure you didn't push?
 * anteru never had an issue with a merge loosing history ...
<GungaDin> just merged and commited
<GungaDin> no, log doesn't show them.
<anteru> Sounds like a bug.
<spiv> GungaDin: "merging only several commits", you mean "bzr merge -r x..y"?
<spiv> GungaDin: if so, then that's cherrypicking, bzr can't record those as merges, it's more like just applying the diff
<spiv> GungaDin: if you look at the "bzr st" output before committing that sort of merge it won't have any "pending merges"
<spiv> GungaDin: so I think it's not a qlog issue, just a bzr limitation: http://doc.bazaar.canonical.com/latest/en/user-guide/adv_merging.html#cherrypicking
<GungaDin> yes
<GungaDin> -r x..y
<GungaDin> I'm just looking for a way to move commits to a different branch... if that's possible.
<GungaDin> I have a branch where there are two sets of commits which are mutually exclusive.
<spiv> Well, one option may be to "bzr branch original-branch different-branch; cd different-branch; bzr merge -r Y..X; bzr ci -m 'Revert changes from X to Y'" â note the order of Y..X, i.e. a reverse cherrypick.  So all the revs are still in the history, but then you add a rev that undoes the changes those revs make.
<spiv> Not sure if that suits your needs or not.
<anteru> Hm, is bzr going to track cherrypicking in the future?
<spiv> anteru: hopefully, but we're unlikely to work on that in the near future :(
<spiv> Stuff like co-located branches are higher on Canonical's todo list... but patches are always welcome ;)
<anteru> Ok. I often cherry-pick something before merging the rest of the branch later on, didn't notice that yet.
<anteru> spiv: I'll look again at contributing to bzr when I'm back at home, ~ 2 months.
<anteru> The use case I'm running into is that I do some quick fix on a feature branch, and I want to move that fix immedialtey back to my trunk, and merge the rest of the feature later.
<spiv> In practice cherrypicking often works out ok, because although bzr doesn't track them, it does avoid reporting a conflict when you merge two branches that appear to have independently made an indentical change.
<spiv> s/indentical/identical/
<anteru> Ah ok. Colocated-branches is branches svn:external?
<anteru> Args: Colocated branches are the svn:external equivalent?
<spiv> No, colocated branches is having a single working tree that can contain multiple branches that you can 'bzr switch' between.
<anteru> Similar to what git does?
<spiv> Right.
<anteru> Ah ok. All the DVCS are so similar now, it's just a question until they converge to a common feature set ...
<spiv> There's a bzr-colo plugin already, but there's some progress towards making it a polished feature of core bzr.
<anteru> Sounds useful for some of the C++ stuff I do, as I won't need to have several build trees.
<spiv> Right.
<spiv> You can already have a single working tree for multiple branches in bzr, but it's a bit more effort to set up and use than we'd like.
<spiv> (Make a shared repo of tree-less branches, and have a single lightweight checkout that you 'bzr switch' between those branches, and of course create/remove/etc branches in the repo)
<anteru> I can see why colocated branches are moving into core :)
<spiv> :)
<anteru> I really hope that some more high-profile projects finally pick up Bzr, the amound of Fud on the intertubes is incredible.
<GungaDin> it'd be nice if cherry picking was better supported.
<GungaDin> if you could see the actual partial commits that have been merged..
<anteru> night
<poolie> i'm using colo now
<poolie> quite good so far
<vila> poolie: quick chat ?
<vila> err, hi all !
<spiv> Hi vila :)
<vila> spiv: hey !
<vila> spiv: did I thank you for the unicode patch ? I don't think so, so THanks !
<vila> spiv: is there a reason you didn't try to target it at 2.0/2.1 ?
<spiv> vila: 2.2 was the source of the initial repot
<vila> spiv: ok
<spiv> It's probably easy to backport (at least of the affected tests doesn't exist in 2.1, I'm fairly sure).
<vila> spiv: if we try to activate the testsuite during the builds in the future we may want to backport it
<vila> spiv: if you could do that that will be great
<spiv> vila: your 644855-test-isolation just bounced due to a NEWS conflict, btw
<spiv> yeah, a backport makes sense to me.
<vila> spiv: shudder, thanks for the heads-up
<vila> spiv: I thought about it and... forgot :-/
<vila> spiv: I mean, I suspected that adding the first bug entry may lead to problems down the road and forgot to check
<vila> dOxxx: thanks for merging my README changes !
<vila> dOxxx: <cough> of course I made typos :-/ I'll fix them in the 2.3 branch
<poolie> hi there vila
<vila> poolie: we can't officially release 2.2.1 yet, we still miss the windows installers, and a complete bzr-proposed PPA
<poolie> ok
<maxb> vila: I just uploaded the last bits to bzr/proposed
<maxb> Unfortunately the launchpad build farm is broken
<vila> maxb: hurrah !
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | bzr 2.2.0 is officially out | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 need installers, aTdHvAaNnKcSe ! Some of them are already available, please test !| work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> maxb: does this means that *you* need to resubmit something or only that your submissions are delayed ?
<maxb> Just a delay, I hope
<maxb> vila: Is there anything left to do under "ping Debian maintainers" on http://wiki.bazaar.canonical.com/Releases/2.2.1 ?
<vila> maxb: hmm, I was waiting for an answer from them, but I think you proxied quite nicely so I guess we should delete this item
<jelmer> 'evening maxb, vila
<vila> jelmer: wow, now, *where* are you ?
<vila> jelmer: maxb, maxb: jelmer, I think you have matter to discuss and I will carefully listen :)
<jelmer> vila: I'm in California :-)
<maxb> we do? Debian packaging? Nothing urgent if jelmer is somewhere esoteric
<vila> jelmer: cool :)
<poolie> hello jelmer!
<poolie> are you at a conference?
<jelmer> 'morning poolie!
<vila> maxb, yes, debian packaging and plugins for the PPAs needing (or not( new releases), this also can have an impact on OSX and windows installers
<vila> meh
<jelmer> yep, I'm at the storage conference in Santa Clara
<vila> maxb, yes, debian packaging and plugins for the PPAs needing (or not) new releases, this also can have an impact on OSX and windows installers
<vila> I can't tolerate typos in parens, no way
<vila> :D
<maxb> vila: On the second point, if bzrlib has not api-bumped in 2.3, then it's purely an issue with the debian packaging metadata assuming it will
<maxb> vila: proposed PPA is now complete apart from one karmic build which is still running
<vila> maxb: rock-and-roll ! Thanks a lot for all your efforts there !
<vila> maxb: started 28 minutes ago on shipova ?
<vila> so all we need now are the windows installers and we can push for testing, which means the official release is already delayed until at least monday
<vila> I will mail the list as soon as I get feedback from Gary
<vila> that's for 2.2.1
<vila> maxb: what's the overall status of the bzr-beta-ppa ? Already testable ?
<jelmer> maxb: email is perhaps the best medium for me at the moment, the connection is pretty bad here.
<jelmer> alternatively we can discuss it when I get back on monday
<poolie> vila, re the SRU
<poolie> http://doc.bazaar.canonical.com/bzr.dev/developers/releasing.html#getting-the-release-into-ubuntu
<poolie> basically says subscribe the sru team
<poolie> (it should say) tag it sru
<poolie> and add a comment asking for it
<vila> just a comment then and "they" will now how to get the diff ?
<poolie> well, you may need to get in #ubuntu-devel and nag someone to help with it
<poolie> they're basically just going to pull in the new tarball or tag, i think
<vila> ok, yeah, I'd like to better understand what happens there and what is missing to make it easier and/or address the issues (or at least understand what they are)
<vila> I know it's about parallel imports but I'm unclear about what workarounds are available... or not
<poolie> vila, well, i think diving in and trying to document or solve things that come up is pretty worthwhile
<vila> poolie: so, bug #636930 to start with. It already affects 'bzr (Ubuntu)' so I sould nominate it for maverick
<ubot5`> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 4, heat: 876)" [High,Triaged] https://launchpad.net/bugs/636930
<vila> but there is no 'nominate' button anymore ;) so is it 'also affects distribution' or 'target to release' ? Neither it seems
<poolie> both i think
<vila> poolie: well, 2.2 is already targeted, and distribution seems to be for Ubuntu (not maverick or lucid)
 * poolie looks
<vila> or may be I don't have enough access to add the needed distrotask (or whatever it's named) to the 'bzr (Ubuntu)' part
<vila> I can't even change the assignee to 'ubuntu-sru'. 'no items matched "ubuntu-sru"' >-/
<poolie> so basically you want to follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<vila> eerk https://bugs.edge.launchpad.net/ubuntu/+source/bzr 28 New bugs ???
<poolie> though, you can't do all of that
<spiv> Ok, I have a small human grabbing at my foot, time to go I think :)
<poolie> you need to subscribe them, not assign them
<poolie> omomom
<poolie> g/l
<maxb> poolie: the StableReleaseUpdates wike page still says subscribe ubuntu-sru, not tag sru
<spiv> Happy weekend, everyone!
<vila> maxb: yeah but we want to tag it anyway for easier tracking for *us*
<maxb> ah
<poolie> you can tag it
<poolie> vila, so i think: tag it, subscribe them, create a distro task, post a comment asking for an SRU
<poolie> let's do that and see if they have any further feedback
<maxb> vila: HAH
<vila> ok, but still, how do I 'create a distro task' ?
<maxb> I have found the missing nominate button
<vila> maxb: haaa, where ?
<poolie> "also affects distribution"
<maxb> nope
<poolie> can you add this to the docs too?
<vila> poolie: no, it's the already existing 'bzr (Ubuntu)'
<maxb> So, it appears that Launchpad shows "Target to release" if the selected bugtask is a project one, and "Nominate for release" if it's a distro one
<poolie> ok, you don't need to do anything else then
<poolie> ah yes, you can go into the distro bug context
<poolie> that's pretty damn obscure
<poolie> https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/636930
<ubot5`> Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 4, heat: 38)" [High,Triaged]
<maxb> So, if you want to create an Ubuntu maverick task, you first hack the URL changing bzr to ubuntu/+source/bzr
<poolie> so this would be maverick only?
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | Release Manager: vila | bzr 2.2.0 is officially out | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 need installers, aTdHvAaNnKcSe ! Some of them are already available, please test !| work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> maxb: 8-(
<vila> poolie: pfewwwwwwwwww. ok, I'll try to replicate that for the others and will document in in releasing.txt
<vila> maxb: thanks the back-magic hint
<vila> black
 * vila kills one more chicken, deploring that it becomes a bad habit especially for the chikens
<poolie> i'll comment there
<poolie> :)
<vila> poolie: ok, I'm watching the blinken lights :)
<vila> poolie: p-e-r-f-e-c-t, that's all I needed, I'll do the others
<vila> adapting the comments as the policy will be slightly different (open to discussion) for 2.1 and 2.0
<vila> and 2.3
<fullermd> vila: Maybe you should switch to goats?
<vila> but 2.3 is irrelevant for now
<poolie> done
<maxb> vila: Hmm, didn't the TB want us to run the testsuite as part of the buildd build?
<poolie> yes
<maxb> In which case, shouldn't we be doing the packaging work for that *first*
<poolie> istm the reasonable thing is to grandfather the current releases where that doesn't pass
<vila> fullermd: chickens and chicken thieves are the rage in France these says (black humour)...
<vila> these days
<vila> maxb: it will most probably fail with various degrees for 2.0 2.1 2.2, we can only try to make it succeed for the next releases for the *build* itself
<vila> maxb: see my mail about the related bugs
<maxb> ah, ok
<maxb> So, we're going to opt for getting a -proposed upload done, and then playing with selftest against the built package until we've convinced ourselves the world is good?
<vila> maxb: I'm trying to target as low as 2.0 as possible and spiv will also try to backport its fix, but that will probably not be enough
<vila> maxb: how, we *are* convinced the world is good :) We want to reach the point where the build itself share this conviction ;D
<maxb> lol
<fullermd> Yeah, but chickens have limited power.  Sacrificing a few goats can be much more effective at smoothing the way.
<maxb> noooo
<vila> maxb: care to add some goats to the packaging branches ?
<vila> I... am not sold yet myself on goats
 * fullermd sells vila to some goats.
<vila> . o O (Great, as if my desk wasn't already such a mess...)
<fullermd> See?  Perfect solution; a couple goats will eat your desk clean in no time   ;)
<vila> Noooo ! Not these notes ! Boom, one goat sacrificed already... there goes the restriction...
<fullermd> My neighbor has been mostly out of town for, like, the last year.  I keep her front lawn mowed, but the back is an absolute jungle.
<fullermd> She quite seriously says she'll just drop a few goats back there when she gets back.
<vila> I see where the goat selling stuff is coming from now...
<vila> you've got mail: Want some goats ? I'm the lawyer of...
<fullermd> Teehee.  "My late husband was Minister of Finance for Ghana.  I require your assistance to transfer five million US goats..."
<poolie> ok, good night all
<vila> poolie: good night !
<vila> fullermd: lol
<vila> maxb: I'm sure you could answer this one: I'm about to ask for an SRU for 2.1 in lucid and 2.0 in karmic, should I also target jaunty and hardy for 2.0 ? Or are they already considered EOLed and we should just tell people to use the stable ppa for them ?
<maxb> jaunty is EOL real soon now
<maxb> It's not worth the effort of SRU processing
<vila> maxb: just what I wanted to hear :) And about hardy ?
<maxb> The only kind of SRU that would be eligible for hardy would be a 1.3.2 release :-)
<vila> maxb: good ! I'm making progress :)
<maxb> Hmm. I have a question. Is there any way to move the tree root file-id to not-the-tree-root, and create a new root?
<vila> maxb: where to you want to move the old root ?
<vila> maxb: you can't
<maxb> :-/
<maxb> I was pondering Chris Hecker's "help getting a clue about tracking changes in an integrated library" email
<vila> what you can do is merge a whole tree inside an existing one (eventually into a sub folder)
<vila> I don't remember if we support this directly and from which release, but that's definitely something we want to improve
<maxb> Won't that lose the root-id of the secondary tree?
<vila> no, we fixed a bug about that
<vila> so you can then merge again from this tree
<maxb> *blink*
<vila> maxb: was I unclear ?
<maxb> How can that work? You merge the secondary tree, and all its contents end up in the root of the merge target initially
<maxb> How is the root-id of the secondary tree going to end up assigned to the new subdir that you then make to move all the stuff into?
<vila> 1) you can move the merged content 2) we manage to track the parent of the merge files and recognized that they once was in the other root-id
<vila> merged files
<maxb> 2) sounds very magic
<vila> we don't track the root-id itself, we track where it was used as a *parent*
<vila> maxb: that was bug #375898
<ubot5`> Launchpad bug 375898 in Bazaar "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1' (affected: 11, heat: 13)" [High,Fix released] https://launchpad.net/bugs/375898
 * maxb reads
<vila> maxb: prepare some coffee first :)
<vila> https://code.edge.launchpad.net/~vila/bzr/375898-fix-root-more will NOT show you the diff because... it has been merged... sounds like a bug to me even if I kind of understand why the diff is empty :-/
<vila> ha no, silly me, it's there: https://code.edge.launchpad.net/~vila/bzr/375898-fix-root-more/+merge/22625
<vila> I'm afraid the patch itself will make you think it's even more magic though :-/
<maxb> hrm
<maxb> I think this is a subtley different thing to what I want
<maxb> I am addressing the question of newly added files in the subproject's upstream branch, which I want to *automatically* merge in underneath the subtree in the aggregate branch
<vila> maxb: right, it fixes a case in the same area so most of the support was there already
<maxb> For what I want to work, I think the tree_root fileid of the subproject needs to end up propagated to the container directory within the aggregate branch
<vila> maxb: I'm not sure about this precise point but at worst they will end up in the root of the new tree and may need to be renamed
<maxb> yes, that's what happens
<vila> ha
<vila> file  a bug
<vila> or search for a duplicate maybe
<maxb> I think the fix basically involves making bzr merge-into a first-class command
<vila> maxb: I think spiv worked on that to make it possible to define it in core or something
<vila> I don't remember the outcomes though
<maxb> either that or doing something loathesome like resetting the fileid of an added directory to match the old parent of its children if they are all being freshly added
<maxb> It is at this point I should stop pondering the guts of bzr and actually go to work
<vila> bzr-builddeb may also have some hacks for some cases, I'm not (yet) up to date there
<vila> well, I'm totally out-of-date here to be honest :-}
<vila> maxb: and the plan is to get involved in the bzr packaging using udd to address that
<vila> maxb: starting now by watching what you're doing :D
 * maxb chuckles and enworkifies
<cheater> hi
<vila> chuckle
<vila> lol, bad window :)
<cheater> :)
<vila> can't find the meaning of enworkify though :-/
<cheater> quick question: bzr on an older suse system - does bzr have a lot of dep's?
<cheater> we can't use the package manager for one thing
<Glenjamin> it has mostly python deps
<cheater> mhm
<Glenjamin> so pip/easy_install should do it
<cheater> this one has no internet connection
<cheater> but i can handle that
<vila> you'll need pyrex to generate the c files unless you start with a tarball that shoul contain them
<cheater> i don't know
<cheater> what's the best thing to install from source?
<vila> then you'll "just" need to run 'make'
<vila> cheater: if you need to bootstrap you can't 'bzr branch lp:bzr' so you need to start from a tarball
<cheater> yes
<vila> cheater: from there it depends when and how you intend to update
<cheater> mhm
<vila> cheater: you can't use the package manager because you don't have an internet connection ?
<Glenjamin> is there any way to get remerge to only do bits that are still herringboned? I fixed half a file manually then ran into two methods which were mixed up together, after a remerge --weave its fixed the really broken one, but undone my other fixes
<cheater> yes
<cheater> well, i can use the package manager
<vila> I confess I don't know what is packaged in suse anyway
<cheater> but it's an old suse that hasn't been supported for the last 3 years :p
<Glenjamin> at the risk of asking a silly question
<vila> wow, so better start from source then,
<Glenjamin> why not upgrade/replace the box?
<cheater> yes vila :)
<cheater> Glenjamin: it's not mine :)
<vila> cheater: which python version ? python -V
<cheater> i think it's 2.6
<cheater> so that shouldn't be a problem
<cheater> maybe 2.5..
<cheater> let's see
<vila> really ? 3 years old and already 2.6 ?
<cheater> i think they updated it
<vila> suse or opensuse ?
<vila> there is http://wiki.bazaar.canonical.com/DistroDownloads#openSUSE but I don't know how up-to-date it is nor how it applies to your case
<cheater> 2.3.3 xDD
<vila> cheater: updating the wiki page with your own case will be welcome ;) (hint hint nudge nudge)
<vila> cheater: python ? argh
<fullermd> Well, either that or a REALLY up to date bzr   :p
<cheater> that'll be FUN.
<vila> cheater: end of story then, we support >= 2.4 ~< 2.7
<cheater> vila: that's ok, i'll upgrade it
<cheater> :)
 * cheater has root
<vila> cheater: go for 2.6 then
<cheater> yeah
<cheater> i see no reason to go for 2.7 yet
<cheater> most libs aren't ported are they?
 * cheater doesn't actually know
<vila> cheater: the support for 2.7 is... a bit unknown
<cheater> ok
<vila> cheater: from a bzr pov that is
<fullermd> vila: You could upgrade that vm and make it known  ;p
<vila> fullermd: the vm *is* upgraded and we know we have failures but no time to investigate :-/
<fullermd> Well, knowing is half the battle, so we're almost done!
<vila> fullermd: hehe, yeah almost...
<vila> fullermd: except almost when it comes to regression testing is marginally better than not at all. I've missed several incidents because I'm used to the red icon meaning  'failures' even when the failure involved a vm crash and a file system corruption :-/
<fullermd> Ah, you just need to run a more reliable OS then...
<vila> hehe, I'm pretty sure the OS is not involved here as the failures has happened across all the OSes used by babune including ... nah that would be cheap ;)
<fullermd> Pfft.  Since when has that stopped you?   :p
<vila> fullermd: always ! You saw only the expensive ones ;)
<cheater> lol
<Glenjamin> is there anything I can do about ghost revisions?
<cheater> what are ghost revisions?
<vila> cheater: revisions created by a bzr ghost, but you won't be there until you kill your bzr, you need a bzr first
<vila> Glenjamin: it depends on where you encounter them and if it causes problems or not
<cheater> i have bzr on my laptop
<cheater> :)
<vila> ;)
<spiv> maxb: I actually did implement a cmd_merge_into, but removed it before the final landing, but it should still be in the revision history
<spiv> maxb: look at the parent revisions of where MergeIntoMerger landed, I guess
<spiv> Or use bzr-search ;)
<vila> spiv: what was the rationale for not landing it ?
<spiv> vila: we weren't sure it was a good feature, IIRC, but check the review comments on the merge proposal.
<spiv> https://code.edge.launchpad.net/~spiv/bzr/merge-into-merger/+merge/28824 I think?
<vila> spiv: nah, just wanted a quick summary ;) My stack already includes too many pending items ;)
<vila> including reading the night mail...
<spiv> Hmm, actually the reason isn't in those comments.
<spiv> But the comments do say "(This history of this patch includes an
<spiv> updated cmd_merge_into it could use.)"
<spiv> (talking about updating bzr-merge-into to use the APIs from this patch, rather than its own old code that doesn't work with 2a)
<vila> ha right, so the plan is more to update merge-into than to make it a core command, at least for now, right ?
<spiv> Yeah.
<Glenjamin> vila: in the history, some blame/log commands wont work
<spiv> Anyway, there's a UI for it now: make a recipe and use bzr-builder ;)
<Glenjamin> it's not crucial, but it's annoying sometimes. And i think it messes up loggerhead a bit
<spiv> But the cmd_merge_into I had had a fairly flexible (although perhaps not intuitive?) UI.
 * spiv wanders off
<vila> dOxxx: small problem here, It seems I can fetch pycrypto, I will copy the 2.2/src one manually instead
<vila> Glenjamin: first, try 'bzr check' just to be sure
<vila> Glenjamin: then, do you know where these ghosts are ?
<Glenjamin> http://pastebin.com/Yv6f1cXS
<spiv> vila: http://bazaar.launchpad.net/~spiv/bzr/merge-into-merger/revision/5272 is the diff removing cmd_merge_into
<vila> Glenjamin: if you do, it may just be a matter of fetching these revisions into your repo
<Glenjamin> I'm not sure they exist anywhere
<vila> Glenjamin: like 'bzr branch -r<ghost> <dummy> ; rm -fr <dummy>'
<vila> Glenjamin: ha, this kind of ghost
<Glenjamin> we used bzr locally with an svn server for about 8 months
<Glenjamin> i've got the rev id of a ghost; GhostRevisionError: {mbrown@macbook-mb.genesys.local-20100716092059-4so0wsqli7tqcxwy} is a ghost.
<vila> Glenjamin: we intend to support them as gracefully as possible, so file bugs if you're annoyed so we can fix it
<vila> Glenjamin: do you know who mbrown is ? Can you check whether or not this revision exists in one of its repos ?
<vila> Glenjamin: start by checking in whatever central or shared repo you have of course
<Glenjamin> he's sitting next to me, how do i find out?
<fullermd> Start with a pair of pliers and a blowtorch...
<vila> ...of course
<fullermd> "*slap*  What were you doing the morning of July 16th?!  TALK!"
<Glenjamin> bzr cat-revision -r revid:{id} is how I test if it's there?
<vila> Glenjamin: like 'bzr branch -r<ghost> <dummy>' or even bzr log -c<ghost> should do (not sure about the later though as they're may be a check against the branch ancestry)
<vila> Glenjamin: yup, same caveat about cat-revision than for log
<Glenjamin> bzr branch -r<ghost> <repo> <dummy> presumably?
<vila> yeah, but with an existing branch for <repo> just to find the repo
<Glenjamin> vila: if i manage to get a ghost repo into my local repo, do i just push the dummy branch to the central repo to get it across?
<vila> Glenjamin: yup
<vila> Glenjamin: if the central repo is a bzr repo that is
<Glenjamin> it is
<vila> k
<vila> Glenjamin: I'm about to do a break for lunch, did your ghost chase gave any results ?
<vila> gave... ? give ?
<vila> garyvdm, GaryvdM: Get out of this grep and come talk to me, I'll be there in ~1h ;-P
<Glenjamin> vila: i got as far as doing -v on check to get the list, and found that the rev ids aren't in any of the repos
<dOxxx> vila: hmmm pycrypto website seems to be dead
<dOxxx> vila: I'll be off IRC today until ~7pm EST. Email me if you need anything for the Mac installers.
<Glenjamin> how difficult would it be to add a post-resolve hook? I'd quite like something to remind me to commit after a merge before making any other changes
<Glenjamin> does http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/builtins.py work for anyone?
<vadi2> How can I diff a file between two bzr revisions? need to repair some partial damage
<Glenjamin> in the same branch?
<vadi2> yes
<Glenjamin> bzr diff -r<revision>..<revision> <path>
<vadi2> thanks much
<Glenjamin> Interestingly, I can't see a way to diff 2 revisions of a file in different branches.
<fullermd> Arbitrarily more complex revspecs.
<fullermd> Actually, I'd imagine you could select any rev in the repo by revid, so if the branches are sharing a repo you could just go like that.
<vila> dOxxx: bah, too late, anyway, I managed to build the 2.3b1 installer for OSX 10.5 by copying the parmiko .tgz so all is well
<vila> Glenjamin: ok, so your ghosts are lost then
<vila> Glenjamin: try #launchpad if the problem persists on this link
<Glenjamin> it's been like that for days
<Glenjamin> i think its loggerhead
<Glenjamin> big file, lots of history
<vila> Glenjamin: diff --old <branch1> --new <branch2> <file> should work
<vila> Glenjamin: ha, no, just got a response
<Glenjamin> vila: how to specify revisions form each branch?
<Glenjamin> aha, works for me now too
<fullermd> See help revisionspec.  You can do 123:/some/branch to get revnos from the branch.
<vila> Glenjamin: ooooh, the tricky one now...
<vila> pfew, saved by fullermd :)
<Glenjamin> ah
<Glenjamin> was looking at revisionspec, but didn't see that bit
<fullermd> (this "working between branches" thing is one place where branches being FS objects makes things arbitrarily inconvenient  :| )
<Glenjamin> something along the lines of git's remotes might be nice
<Glenjamin> some sort of intelligent bookmarks, but i'm not really sure how they'd work
<dobey> hmm
<dobey> wasn't there a bzr plug-in somewhere to allow arbitrary shortcut definitions? something like how lp:foo works, but so that you could define gnome:foo or otherserver:foo for example?
<Glenjamin> I've been writing my own for each repo we use here
<Kamping_Kaiser> not aware of it, but sounds handy
<Kamping_Kaiser> i thoguht the thing was 'copy the lp one'
<Glenjamin> i'm not sure how the plugin would store it, but it's simply enough to do
<Glenjamin> you just need prefix, url pairs
<vila> Glenjamin: the most recent one I heard about in this family is lp:bzr-debuntu (be aware that it will be merged in to bzr-builddeb though IIUC)
<Glenjamin> i was just reading the source for that
<vila> dobey:
<Glenjamin> it sets stuff up with a dict
<Glenjamin> the slightly non-trivial bit is moving the dict to a config file
<vila> and then rely on lp for the resolution
<vila> bzr config files should be able to provide a mapping to a [xxx] section to a dict with little nudge I think (but that's not part of the officially supported stuff)
<dobey> what i want to do is set up a "lp:foo" alias to point to "file:///tmp/blah/blah/foo" for example, for unit tests
<Glenjamin> we don't really need a dict, just pairs
<dobey> or well, s/want/need/
<vila> dobey: not sure I understand the constraints here, but if you're using bzr TestCaseWithTransport or even TestCaseWithTempDir, your current dir is already under /tmp so you can use relative paths 'dir/file'
<vila> dobey: if you need a transport, you can (with TestCaseWithTransport) do self.get_transport('dir') too
<dobey> vila: i'm trying to write more unit tests for some of the code in tarmac, which is currently untested, which handles the actual merging of branches and talks to launchpad to get proposals and stuff. and tarmac complains if branch identities do not use the lp: protocol. and with the TestCaseInTempDir (which we're already using), lp: is not a valid protocol, so after setting up the config for a couple of branches to test the merger of, 
<james_w> bzr-bookmarks is the arbitrary one
<dobey> james_w: i was looking at it last night, but it seems to only allow doing "foo = file:///foo" rather than "lp:foo = file:///foo" afaict
<vila> dobey: you don't access lp: right ?
<james_w> dobey: right, it's not what you need
<james_w> you need to define a directory service in your tests
<vila> dobey: so you can *redefine* the lp: protocol for your tests no ?
<dobey> vila: i need to avoid hitting the network, yes. can i redefine it?
<vila> dobey: sure
<dobey> the lp plug-in tests seem to have a way to set up a fake Factory for the URLs, but it seems to only support doing it for one url at a time?
<vila> dobey: you wan to look at bzrlib.transport.transport.list_registry
<vila> dobey: you wan to look at bzrlib.transport.transport_list_registry
<vila> dobey: the latest transport registered for a given protocol wins, so your tests need to register your lp: implementation (and presumably unregister it during cleanup),
<dobey> hmm, ok
<vila> dobey: look in bt.test_transport.py for more examples
<dobey> ok
<vila> dobey: hmm, and poke the lazy that put a FIXME there instead of doing the cleanup so you'll get proper examples ;)
<vila> dobey: there is also bt.per_transport.py
<dobey> heh
<vila> maxb: yeah for bzr/proposed !!
<vila> GaryvdM: hey !
<Glenjamin> here's a thought
<Glenjamin> why do directory services have to be instantiated?
<Glenjamin> return service().look_up(name, url)
<Glenjamin> it's easier to factory object which have a lookup method than to factory objects which after being called have a lookup method :|
<GaryvdM> vila: Hi
<GaryvdM> vila: Esh - I've been busy a work! - But I'm free now
<vila> Glenjamin: ECANTPARSE, could you rephrase in simpler english ? (I'm not a native speaker)
<vila> GaryvdM: great ! I wanted to ask about the windows installers
<vila> GaryvdM: 2.2.1 being the priority
<GaryvdM> Trying to get going with with win installers, but need to finish off the bzrw/qbzr/tbzr/bzr-explorer
<GaryvdM> issue
<vila> ok, do you have an estimate ?
<GaryvdM> can I answer that in a while - Not sure yet.
<vila> I'd like to mail the list asking for testing focused on 2.2.1
<GaryvdM> Ok
<mgz> which bit are you on now Gary? I'm actually around today and this weekend
<vila> GaryvdM: ok, take your time,
<vila> GaryvdM: you still have.. 5 minutes or such
<vila> GaryvdM: mwhahahaha kidding of course
<mgz> (so, yell if you need help, was the subtext there)
<GaryvdM> vila: If people want to test, the installer I linked to on this page: http://wiki.bazaar.canonical.com/Releases/2.2.1
<vila> GaryvdM: I know, I wanted to ask you put it on lp instead, if there are problems you will have to use a new name anyway, so need to buffer here IMHO
<vila> so *no* need to to buffer
<vila> GaryvdM: unless you think it's not usable yet, in which case, better wait for the fix since we will need it to be tested again anyway
<GaryvdM> vila: I've seen lots of people who don't consider themselves as testers get test copies of installers from launchpad, and then complain about instability
<GaryvdM> So I think it is important to buffer.
<GaryvdM> (by dropbox may not be the best place...
<GaryvdM> *but
<vila> hmm, you're right of course... chicken-and-egg
<GaryvdM> I've not been keeping up with the mailing list. :-0 waterfall....
<vila> On the other hand, that's what test is about... if people don't want to test they can just wait, the release hasn't been officially announced (whatever my poor phrasing was ;-)
<mgz> just read the Roadmap for Bazaar thread, unless you're really interested in nested trees
<mgz> or visual studio integration
<mgz> or vila's many release posts :)
<vila> GaryvdM: don't even read that :) Focus on the present, the future can wait :-D
<GaryvdM> This is the issue I'm trying to fix: http://osdir.com/ml/bazaar/2010-09/msg00189.html
<vila> GaryvdM: release posts are "present" in this respect ;)
<GaryvdM> Easy fix, then have to release new versions of qbzr, tbzr, and bzr explorer...
<Glenjamin> vila, directory_service.DirectoryServiceRegistry.dereference does return service().look_up(name, url)
<mgz> ah, yeah, I saw that and was going to respond, but poolie posted saying what I was going to before I got there
<vila> GaryvdM: wrong way, delay 2.3b1 if you want, but not 2.2.1 unless it's critical
<Glenjamin> look_up is an instance method of a directory service, it'd make more sense for it to have been a static/class method
 * GaryvdM often wants to merge bzr-explorer in to qbzr to reduce release work...
<vila> GaryvdM: when releasing, there is *nothing* easy
<GaryvdM> vila: It's a regression in 2.2.0, So I think it's important.
<GaryvdM> Caused by bzrw.exe.
<vila> GaryvdM: then it's critical, ok
<GaryvdM> and bad code.
<GaryvdM> ok
 * GaryvdM focusses...
<vila> Glenjamin: ISTM that making it a static/class method reduces the flexibility no ?
<Glenjamin> in the general case maybe, but the constructor gets no arguments
<vila> Glenjamin: oh, you want to pass some arguments to service() constructor ?
<vila> hehe, crossed on the wire ;)
<Glenjamin> well not really, i'd rather not have to make something instantiable
<Glenjamin> i'll show you in a sec, just making the plugin
<vila> I encounter the same problem in a another area and resort to define class attributes and new classes :-/
<vila> 137 downloads for the 2.3b1 tarball, do we have so many installer builders ???
<vila> or packagers
<Glenjamin> I always install from source on my windows box
<mgz> or gentoo users?
<Glenjamin> or did, when I did any dev on it
<vila> any gentoo packagers around ?
<vila> mgz: I'm not sure gentoo users will jump on the first beta...
<Glenjamin> vila: lp:~glenjamin/+junk/bzr-shortcuts (the __call__ hack works around having to be callable)
<vila> mgz: 'lost connection during test' rings a bell ?
<mgz> yeah, babune hits it sometimes, it's a generic subunit failure scenario
<vila> mgz: subunit, thanks
<mgz> if for instance, the child process dies
 * mgz hopes he's remembering this correctly
<vila> mgz: yeah, find another example will you, I don't like that one :D
<mgz> child process closes the pipe? :)
<vila> far better :)
<vila> keep going :)
<vila> I want one that could match a spurious failure that can be target at someting outside the test suite :)
<vila> 6 jobs in raw failing on jaunty for different reasons.... some bug wants to die today... or knows I'm knee-deep in releases...
<vila> in a row (right ?)
<Glenjamin> dobey: Kamping_Kaiser lp:~glenjamin/+junk/bzr-shortcuts is a first draft of a plugin for defining arbitrary url prefixes
<vila> Glenjamin: it's a bit weird or at least not using the API as it was intended, i.e. you  don't call register_transport
<vila> Glenjamin: it's true that this sounds a bit heavy in your case, but you're supposed to call register_urlparse_netloc_protocol less often then register_transport
<vila> blah
<vila> you're supposed to call register_urlparse_netloc_protocol less often then register_transport
<Glenjamin> i think i just copied the launchpad one
<dobey> hmm
<vila> in your case you want to call register_netloc and register_transport for each one
<Glenjamin> what does register transport do?
<vila> >-/
<Glenjamin> as i'm not defining a transport, just an alias
<vila> Glenjamin: oh, sorry, wrong layer
<dobey> hmm
<dobey> interesting
<vila> Glenjamin: I think you should at least mail the list about it, I'm not sure there is a lot of users of DirectoryServiceRegistry and even then, we can find ways to make the API evolve
<Glenjamin> it's not exactly prohibitive, but its a bit odd
<vila> Glenjamin: forget most of my previous remarks I wasn't on the right page
<Glenjamin> and every matching service instantiates an object unnecessarily
<vila> the class has a single method too, so it may just mean it did the job when it was introduced
<mgz> ugh, two failures on maverick from my selftest changes and test_selftest sucking
<mgz> will work around rather than launching in to making the tests sane
<vila> the 7th was the good... looks like goats work better than chicken ?
<mgz> there's more blood in a goat.
<vila> mgz: 24,567 tests... took 36ms...
<vila> mgz: ha, so you're part of this conspiracy against goats too...
<mgz> I'll fix that timing thing when I work out where it needs fixing.
<vila> mgz: plan for mutiple targets :D
<vila> GaryvdM: sorry to interrupt, just one question: do you plan to build installers for 2.0/2.1/2.2/2.3 or only 2.2/2.3 ? I'll tend to prefer the later if that matters
 * GaryvdM wishes that bzr (version|plugins -v) would tell me what dirs it looks for plugins in.
<GaryvdM> vila: I prefer to only volunteer to to 2.2/2.3
<vila> GaryvdM: fine
<GaryvdM> the build method is different, and I've never done a 2.0/2.1 build
<vila> GaryvdM: I;m not sure we should continue to support 2.0/2.1 on windows at all, but it's not the place nor the time to discuss it
<Glenjamin> if i sent a message to the list and got bounced for not being a member, then joined; is it better to resend or leave someone to approve it?
<vila> GaryvdM: and, until "bzr (version|plugins -v) would tell" you, remember that you get full control with BZR_PLUGIN_PATH
<GaryvdM> vila: Yes - and you can also see in .bzr.log.
<vila> Glenjamin: depends on the list, if it's bazaar@, feel free to sent it again, at worst we;ll get it twice, but AIUI, the moderators are more harmed by spammers than by good willing citizens
<Glenjamin> i'll just resend then, ta :)
<GaryvdM> It's just easier to type bzr plugins -v than less ~/.bzr.log - ^H^H^H^H^H^ Aghhh  where is .bzr.log on windows :-)
<mgz> %APPDATA%/.bzr.log by default I think
<mgz> but point taken :)
<GaryvdM> mgz: :-)
<vila> GaryvdM: LOL
<Glenjamin> i think it belongs in version -v
<vila> Glenjamin: right, but most of the people that really care about it, especially care about it after running plugins -v and pestering that it's still not there :) practicality vs purity, I'm 50/50
<Glenjamin> should it be at the top of plugins -v or the bottom? :p
<vila> Glenjamin: blue
<mgz> I prefer pink.
<vila> mgz: I knew it :)
<mgz> and on that topic... /me gets back to it
<GaryvdM> No! the bikeshead should be yellow!
<dobey> Glenjamin: hrmm, does your plug-in actually work?
<GaryvdM> :-P
<dobey> Glenjamin: how can i test it?
<vila> ok, blue, yellow, pink, which country flag is that ?
<Glenjamin> dobey bzr info test:
<Glenjamin> you'll get an error that http://example.com isn't a repo
<mgz> http://bazaar.launchpad.net/~parthm/bzr/403687-shelve-summary-in-status/revision/5426/bzrlib/shelf.py <- funny commit, says something about lazy_import (lack of) usability I think
<dobey> Glenjamin: hrmm, i wonder if the bzr testcase is preventing me from doing the same thing inside the testcase setUp() then :(
<Glenjamin> is the thing you're testing itself dereferencing locations?
<dobey> well, bzr is trying to do something, and then gives me UnsupportedProtocol: Unsupported protocol for url "lp:branch1"
<Glenjamin> at a guess, i'd say lp: isn't registered with the netloc urlparse thing
<Glenjamin> what throws that exception?
<dobey>   File "/usr/lib/python2.6/dist-packages/bzrlib/transport/__init__.py", line 1576, in convert_path_to_url
<dobey> it seems like my factory isn't getting called
<mgz> things tend to run with --no-plugins for testing by default?
<mgz> how about stubbing in a fake lp: thingy just for your tests?
<mgz> ...wait, that's what you're trying to do
<mgz> post some code?
<dobey> that is exactly what i'm doing. i'm not calling load_plugins()
<mgz> it needs to run in setUp or later as tests are isolated from general hooks
<dobey> it's in setUp()
<dobey> mgz: http://pastebin.ubuntu.com/499785/
<mgz> thanks.
<Glenjamin> dobey: name is undefined there
<Glenjamin> shouldn't it be throwing an exception
<mgz> presume that's just an extracting c/p error
<dobey> undefined where?
<Glenjamin> directories.register in setUp
<mgz> the general idea looks fine, any ideas vila?
<vila> EOVERFLOW
<james_w> there's no upcall in setUp() that might be making things wonky
<dobey> Glenjamin: true, not sure why it didn't except there, but changing it to a string had no useful effect :)
<mgz> was guessing that's also a c/p error, as we throw if you forget
<dobey> james_w: there is a super() for it, i just omitted it in the pastebin
<Glenjamin> if it really was undefined, it means setUp isn't being called
<james_w> dobey: is the super before or after that?
<Glenjamin> althought it might have just picked up a variable called "name" from a different scope
<dobey> james_w: it's the first call in the setUp()
<dobey> setUp() is being called, because it's failing after things that are done in setUp, are successfully completed
<Glenjamin> can you inspect the directories registry and try a call to directories.dereference at the end of setup?
<Glenjamin> dobey: eureka
<Glenjamin> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/registry.py#L107
<Glenjamin> override_existing defaults to false.
<Glenjamin> although it excepts, so its not that :<
<dobey> yeah i don't know what it is
<GaryvdM> Ok - Fix committed -  another bug is now showing, but maybe not critical.
 * GaryvdM kicks off install build.
<dobey> :-/
<mgz> you're a star Gary.
<mgz> dobey, my next step would be to pdb the test and look at the various internals during the run
<dobey> yeah, will have to wait though. it's nigh time for me to hop off for lunch and an appointment
<jml> hello
<jml> we're geting a strange status. a file is showing up as "nonexistent" in status
<jml> it's a .OTHER file for something that we've deleted.
<jml> we're not sure what to do about it
<vila> jml: you deleted it in your branch but modified in the other, if you still don't care about this file delete .OTHER and resolve
<jml> vila, .OTHER does not exist!
<vila> jml: oh, and .THIS was modified ?
<jml> vila, who knows?
<jml> vila, bzr is just telling us that there's a thing called foo.OTHER that has the status of 'nonexistent'
<vila> jml: you ?
<vila> jml: it was probably modified :)
<jml> vila, perhaps. foo doesn't exist in our tree either.
<vila> huh
<vila> jml: shudder
<vila> jml: .bzr/checkout/conflicts pastebin ?
<Glenjamin> tried revert/resolve on it?
<vila> Glenjamin: I think jml wants to know before acting
<vila> jml: anything related to the parent dir ?
<Glenjamin> heh, my userland approach would be to hit it with sticks til it worked :)
<jml> vila, I don't have access to the branch... it's on someone else's machine
 * vila cries
<Glenjamin> oh, on the ghost thing - is there any way for me to make some fake revisions to replace the missing ones?
<vila> jml: 'nonexistent' or 'missing' ?
<jml> vila, nonexistent
<vila> jml: I need to know the conflict type
<jml> vila, ok. let me reproduce locally...
<jml> vila, http://paste.ubuntu.com/499800/
<jml> vila, buildd-dispatching.txt is the "foo" from above
<jml> If I do "bzr status", lib/lp/soyuz/doc/buildd-dispatching.txt.BASE is "missing"
<vila> jml: ok, Contents conflict, always misleading, content refers to the path: The files are of different types (or both binary), or not present
<jml> vila, right.
<jml> vila, the file has been deleted in our local branch, and we want to keep it deleted
<jml> vila, if I just do "bzr resolve lp/.../buildd-dispatch.txt", resolve the other conflict and then commit...
<vila> jml: so deleted in this and modified in other, so yes
<jml> vila, I get this... http://paste.ubuntu.com/499804/
<vila> jml: how did you resolve ?
<vila> bzr resolve lp/.../buildd-dispatch.txt --take-this
<Glenjamin> reminds me, i get an attribute error whenever i do --take-other
<jml> vila, no option.
<vila> Glenjamin: file a bug, with a reproducing recipe if possible, the simplest the best
<Glenjamin> mm, doing now
<vila> jml: bzr version ?
<vila> jml: nvm, 'bzr rm lp/.../.OTHER' ; 'bzr resolve lp/.../.OTHER'
<jml> $ bzr rm lib/lp/soyuz/doc/buildd-dispatching.txt.OTHER
<jml> bzr: ERROR: Can't safely remove modified or unknown files:
<jml> added:
<jml>   lib/lp/soyuz/doc/buildd-dispatching.txt.OTHER
<jml> Use --keep to not delete them, or --force to delete them regardless.
<vila> jml: sudo amke me a sandwich
<vila> --force
<jml> aiee
 * fullermd slaps vila with a salami.
 * vila seriously reconsider paying for those goats
<Glenjamin> why does --take-other do a transform, rather than just a filesystem move?
<jml> un baguette de pain
<vila> Glenjamin: EOVERFLOW, nasty edge cases
<vila> jml: une ! :)
<Glenjamin> anyway, bug posted as 646961
<vila> jml: can't you guess from the shape ???
<jml> vila, heh heh
<fullermd> If we hit you enough, it'll be whatever gender we WANT it to be!
<jml> vila, I suggest you steal fullermd's salami and make your own sandwich
 * fullermd has a feeling this conversation took a turn somewhere...
<vila> jml: will think about it, AFTER you tell me your conflict is gone for good
<mgz> was that a multilingual pun?
<jml> vila, that works.
<jml> mgz, yes.
<vila> pfew
<vila> jml: so, 'bzr version' ?
<jml> Bazaar (bzr) 2.2.0
<mgz> un pain de peine would also work.
<vila> mgz: I don't know what 'un pain de peine' is
<vila> Now, that's a multilingual pun :-D
<mgz> or my french fails.
<fullermd> My french should be great.  Heck, in school, I took 4 years of French I.
<jml> gone
<roryy> i've got patch for bug 202374 at https://code.launchpad.net/~ryorke/bzr/202374-pull-update-showbase -- do i just run bzr lp-propose and take the defaults?
<ubot5`> Launchpad bug 202374 in Bazaar "pull and update should accept --show-base (affected: 0, heat: 4)" [Medium,In progress] https://launchpad.net/bugs/202374
<mgz> roryy: you can also click "Propose for merging" and fill in the details on that page
<roryy> mgz: ok.  do i need to worry about what the submit branch is?
<mgz> you pick what you based it off, which should be lp:bzr (the default)
<roryy> mgz: ok, thank you
<roryy> s'pose i should actually run *all* the tests before proposing a merge
<mgz> it's not the end of the world if you don't, as PQM will do that for you before landing
<mgz> but doing `./bzr selftest -s bt.test_source -s $your_test_module` can be useful
<GaryvdM> mgz: Please could you test an installer for me? http://dl.dropbox.com/u/4494367/bzr-2.2.1%7Ed-setup.exe
<GaryvdM> http://dl.dropbox.com/u/4494367/bzr-2.2.1~d-setup.exe
<mgz> getting.
<vila> GaryvdM: I'm about to crash, I'm sending an email to the ML about the releases status
<GaryvdM> vila: ok
<vila> GaryvdM: feel free to reply to it once you're comfortable with your installers
<vila> GaryvdM: I tried to make it quite clear that we want testers,
<vila> GaryvdM: the osx installers are already on lp so it;s up to you to decide where you want them to be dl from
<GaryvdM> Ok - I'll reply with links to what ever I have.
<vila> GaryvdM: a big thank you for your help here !
<mgz> do you need me to include tortoisebzr?
<GaryvdM> mgz: yes -
<GaryvdM> mgz: I'm just writing up reproduce steps for a bug.
<vila> ok, EODing EOWing but will probably pass around...
<vila> have fun !
<mgz> looks fine at first blush, anything in particular that needs poking with a stick?
<mgz> bye vila!
<GaryvdM> bye vila.
<GaryvdM> mgz: http://pastebin.ubuntu.com/499833/
<mgz> ta.
<GaryvdM> mgz: I'm trying to reproduce that with out tbzr
<GaryvdM> I saw something similar when I was fiddling with bzrw's boot_common.py
<mgz> I didn't get anything there, I'll try again.
<GaryvdM> When bzr is finished tries to flush stderr/stdout, which was erroring.
<GaryvdM> And there's nothing in .bzr.log :-(
<GaryvdM> I'm blaming tbzrcommand at the moment.
<mgz> okay, trying with a bigger shared repo, and log is struggling...
<mgz> hm, still no error message here
<GaryvdM> Oh  - Ok
<GaryvdM> mgz: The other thing I would like for you to try for me is to try run the testsuite.
<GaryvdM> I wonder how that will go.
<mgz> just selftest on the command line?
<GaryvdM> mgz: Unless you think that this is something to try between releases?
<mgz> no, it's worth doing, I filed a bug on it a bit back, as there are a few things that need resolving
<mgz> ha, couple of deprecation warnings, and that __subclasscheck__ thing Andrew was fixing
<GaryvdM> mgz: I'm just going to grab so food.
<GaryvdM> bbl
<mgz> nothing unusual looking so far
<tsmith> is it possible to remove tags?
<mgz> they're part of the history, so it's the same story as commit messages, you'd need to rewrite history
<tsmith> nah
<tsmith> bzr tag --delete <tag>
<tsmith> thanks
<mgz> ha, whoops, so overwrite has been implemented there where it hasn't been for messages
<mgz> need to poke around some of the bits of bzr I never use
<maxb> It's not a case of overwrite being implemented
<maxb> It's simply a case of tags not actually being part of history, but mere annotations on top of it
<mgz> ah, so I was wrong about the base thingy?
<maxb> base thingy?
<mgz> concept maybe, pick a word.
<mgz> have we got any dev docs on tags? I'm not finding much.
<maxb> Tags are a dictionary of name: revid, stored in a branch.
<maxb> That's pretty much it
<mgz> okay, I'll go back to not worrying about them but be able to answer the question correctly next time
<jasonlife> If I maintain a branch for each release, and keep updating master with new features and bug fixes,  how can I apply the bug fixes to the released branch?
<jasonlife> it seems "bzr merge" doesn't work for this purpose..
<fullermd> Well, it sorta does, insofar as you can cherry pick.  How well that works over time is more questionable.
<jasonlife> I need to digging the cherry pick stuff.. I always wondered what the cherry pick is..
<jasonlife> I'm new to bzr.. :)
<fullermd> A cherrypick is basically any merge that, for one reason or another, can't be recorded as a merge.
<fullermd> In this case, it would be a cherrypick because the graphs are disjoint; a merge of one revision transitively includes all its ancestors.
<fullermd> Since you don't actually want that in this case, we can't make it a real merge.
<jasonlife> yes..
<jasonlife> I can't do the real merge.. I need *partial* merge for bug fixes..
<fullermd> You could make sure everything's connected by using DaggyFixes, but that would probably just get increasingly more difficult as time went by, so it's probably not really a general option.
<fullermd> Right.  So we can't record the merge; as far as bzr is concerned after the fact, it's no different from you manually editing the files and committing, so it can't use any of that information to attempt future merges.
<jasonlife> I might make a patch file from the master for the bug fixes, then apply the patch to the released branch, but I would think there is a better way..
<fullermd> It often works just fine, and it's pretty much always going to be at least as smart as doing diff | patch yourself.
<fullermd> But as things get more diverged, there'll tend to be more and more cases where bzr can't figure out how to move things across, because the common ancestor it works from gets really far back.
<jasonlife> except from bazaar wiki.. "A cherrypick is an operation in which the delta between two revisions is applied to a working tree. The process is roughly similiar to generating a diff between two revisions and applying it to a working tree."  I think this is what I need..
<jasonlife> thanks..
<jasonlife> s/except/excerpt
<jasonlife> fullermd: thanks.. cherrypicking works beautifully..
<jasonlife> Is there a bzr command to list the braches available?
<jasonlife> like "git branch -a"..
<mgz> ls
#bzr 2010-09-25
<poolie> wow, bzr-colo is really nince
<poolie> *nice
<cheater99> hi guys
<poolie> hi
<sinasalek1> I have strange question! how to lock file in bazaar?! i couldn't find anything on the internet so i think i'm using the wrong keywords
<sinasalek1> Anyone?
<Kamping_Kaiser> lock?
<sinasalek1> yup
<sinasalek1> Kamping_Kaiser: why i'm unable to find any documentation regarding to this?
<vila> sinasalek1: because locking a file requires a central authority to record that one user has locked so everybody else can ask whether they can lock or not
<vila> sinasalek1: when working in a distributed env, there is no central authority, so can't implement locking
<sinasalek1> vila: So you meant the question is wrong? even if i used cnetralized workflow?
<vila> sinasalek1: not wrong, there are some cases when you still want to do that, but yes, this requires a centralized workflow
<ddaa> vila: really?
<ddaa> I mean, cases when you still want to do that?
<sinasalek1> vila: so it's supported ?
<vila> sinasalek1: bzr itself doesn't implement it, but there have been a few attempts to handle it via plugins
<vila> sinasalek1: I don't remember the references though :-/
<sinasalek1> vila: Thanks that helped :)
<vila> ddaa: files in binary format like word or the like
 * ddaa bends his mind into trying to see things this way
<vila> sinasalek1: but unless you're dealing with files that *can't* be merged properly, it's generally a better idea to avoid locking
 * vila just loves when they do that :-/
<vila> ddaa: yeah, doesn't really fit the distributed model isn't it ?
<ddaa> not just the distributed model
<vila> ddaa: but some people cared enough about it to start implementing it
<ddaa> after all those years immersed into a DVCS mindset, it's hard not to see it as a principle that locking is neither needed nor desirable.
<vila> ddaa: it boils down to how you handle concurrent edits or if you prefer to just avoid them
<ddaa> I kindaaaa see it now
<ddaa> it's a bit like checkouts, only more so.
<ddaa> stop me before I open the file for editing, not when I commit.
<ddaa> I don't see how to make that fit into the bzr model though.
<ddaa> first, it would require a new *branch* format
<ddaa> since it would be non-versioned branch-local data.
<ddaa> then a new tree format, to translate the lock into fs permissions
<ddaa> "bzr lock FILE" would acquire a write lock on the branch, and open, say ".bzr/branch/file-locks"
<ddaa> okay, I see it now
<ddaa> file-lock is a mapping of file ids to uuids.
<ddaa> bzr lock FILE adds line to file-lock, and record the uuid in the working tree
<ddaa> bzr unlock FILE checks if the working tree uuid matches that of the branch, and remove the lock
<maxb> don't forget to record the whoami in a lock record too
<ddaa> maxb: same recipe as branch lock
<ddaa> need to identify the user, and be unique too
<ddaa> now, there must be guards in anything that can write to the branch tip
<ddaa> like commit, push, pull, etc.
<ddaa> that the user has a file lock on any file requiring locks that is modified by the delta
<ddaa> that means we also need an inventory data identifying "files requiring locks"
<ddaa> fuck
<ddaa> sorry
<ddaa> that's a really complicated feature to implement
<ddaa> it just got past my "I don't really want to think about it" threshold
<ddaa> and we don't have versioned file properties yet
<ddaa> so it would require another bit of working-tree metadata to identify file ids requiring locks
<ddaa> now, another riddle
<ddaa> after using "bzr branch", we can't do the locking anymore
<ddaa> at least, not properly
<ddaa> the user will still need to lock to edit the file, but it won't acquire the right lock
<ddaa> so, the working tree needs to record the URL of the branch that has the real lock
<ddaa> now, what happens when pulling a delta that changes that information?
<ddaa> gaaah!
<ddaa> vila: did anybody answer that one, yet?
<ddaa> now, there's another desirable feature
<ddaa> that's for a *branch* to take a file lock from another branch
<ddaa> so you can say "this file can only be modified on this feature branch, not on trunk"
<vila> ddaa: I don't remember the details, but AFAIR, they went with a pretty simple thing that appeared to "work for them"
<ddaa> I can imagine that.
<ddaa> There can be a world of difference between "simple enough that worksforme" and "robust enough for general use"
<ddaa> "simple enough that worksforme" can just be a pumpkin
<vila> and as far as bzr is concerned, it will be more profitable to support hooks for diffing and merging more of this binary formats
<ddaa> different use cases really
<vila> we already have the hooks for merge
 * vila off for lunch
<ddaa> actually, the "lock location" info should be unversioned branch data too
<ddaa> and the "assign lock to another branch" is the same mechanism that should be used when locking to a heavy checkout.
<JoshBrown> How do I merge a change from downstream, back upstream? There seems to have been some confusion and someone has made an upstream change in the downstream version, i.e: code â deb â code-bugfix (â code). I want to merge code-bugfix back into code without adding all the debianization, what is the best way to do this?
<maxb> cherrypick merge?
<JoshBrown> maxb: Thanks, I'll try it.
<JoshBrown> maxb: Seem to be having some trouble. When I try cherry-pick merging I get "All changes applied successfully." (I'm running `bzr merge --rev 36..33 ../code-bugfix/ `).
<mgz> 33..36 surely.
<mgz> you want his changes included, not to back them out after they've already been committed
<git__> hey, does "bzr export ftp://[username]:[password]@ftp.domain.com  work?
<JoshBrown> mgz: Ooops, I actually ran 33..36, then tried 36..33 (just in case I misunderstood the manual). So neither 33..36 nor 36..33 works.
<mgz> do `bzr revert` then try again with --preview added?
<git__> i accidently delete everything in my working tree ... .bzr directory is still there, how do I get my working tree back?
<mgz> also `bzr revert` provided you didn't commit your deletion.
<git__> thanks mgz !!!
<git__> what's the equivalent of "git co [hash value]" in bzr?
<jam1> mgz: hi, I think I've updated my patch as requested, can you look at it again? https://code.edge.launchpad.net/~jameinel/bzr/2.3-filter-tests/+merge/33938
<git__> i want to go to revision 6, the current revision is 12
<mgz> `bzr update -r 6`
<mgz> sure jam, I'll take a look.
<mgz> ...when launchpad updates the diff, because I'm lazy
<mgz> all looks reasonable, I'll run the tests locally as well.
<mgz> I think the _report_* method additions won't be needed when the existing issue with how the bzr/testtools boundary works for exceptions, but it's easy to just remove them again when that's sorted
<mgz> +is fixed
<mgz> bt.test_selftest.TestSubunitLogDetails.test_success_has_no_log fails here, it does contain the log.
<mgz> you appear to have just not changed addSuccess
<jam> mgz: I just didn't commit before my last push :)
<mgz> :D
<jam> mgz: just push rev 5393
<jam> I just pushed 5393
<mgz> pulling.
<jam> which should have a few more subunit permutations
<mgz> okay, that's more like it.
<mgz> ha, I see you gave in and made a generic testing class for test_selftest
<jam> mgz: yeah, you need something to do the permutations, and i was using it 2x
<jam> the --subunit stack is *quite* different from our regular stack
<jam> subunit doesn't inherit from testtools, for example
<mgz> yep, it's a bit of a pain
<JoshBrown> mgz: I used --preview - it just returns a diff of the to-be merged changes.
<mgz> JoshBrown: that was the point, are they the right changes?
<JoshBrown> mgz: No, I only want the code changes
<mgz> if so, just do the same thing without --preview, then `bzr commit -m "Cherry pick ... changes from ..."`
<JoshBrown> The diff shows code and deb changes
<mgz> so the deb changes were part of the same commit as the fix you want?
<mgz> then you can just revert them before running commit
<mgz> `bzr revert ./debian`
<mgz> (or whatever)
<mgz> jam: have put a comment in the mp, don't know if you want to tackle the annoying merge now
<jam> mgz: you mean submitting it? or what do you mean by 'annoying merge'?
<mgz> yup, that. there have just been a few selftest changes lately, so there's always a conflict
<jam> thanks for the heads up
<jam> *glee* 2 conflicts
<jam> mgz: and yeah, I had tried to do some of it using TextTestResult or whatever, and it was a bit... joyless
<mgz> we don't really want to be using that in bt.test_selftest at all I think, leave it for bb.
<mgz> could just use some cleanup.
<jam> mgz: I find the current state still rather messy. Even without our extensions.
<jam> What goes on Result what goes on Case, what goes on Runner
<jam> and then the inconsistencies
<mgz> yup.
<jam> testresult.expectedFailures is a list with different items than testresult.unexpectedSuccesses
<jam> (one has tuples of (test_id, reason) the other a list of [tests])
<swebo> hi
<swebo> i want to find out how many lines each developer on a project has written.
<swebo> i'm doing a homework assignment at university with bzr and it's important that both developers have written an equal amount of lines ...
<swebo> is that possible with bzr?
<fullermd> What a bizarre requirement...   do you mean lines written total over history, or just lines in the current version?
<fullermd> If it's just the latter, you could figure it from annotate pretty easy.
<swebo> i think it's over the total history
<fullermd> So, all you need is one partner who writes really bad code, and has to keep rewriting it?   ;)
<fullermd> Anyway, it's certainly _conceptually_ possible.  I don't know if anybody's written a plugin to do it though.
<swebo> well... i don't think it's a fair requirement, either ...
<swebo> i think 60:40 might be ok as well, but he doesn't want one of both to do nothing..
<swebo> and annotate shows only the lines in the current version?
<fullermd> Heck, if it's over history, you just need one guy to be SO bad the other guy has to write all his stuff, and *bam*, 50/50, even though he doesn't have a single line in the final version   :>
<fullermd> Well, annotate shows the lines in any version you ask it.  But it would take a lot of postprocessing work to figure a cumulative-lines-in-history from that.  And many times more work than doing it below that.
<swebo> ah, ok.. now i got what you were saying ;-)
<fullermd> If you were doing that, it would probably be easier to go from diffs of each revision than annotating each file/revision.
<fullermd> Well, a little anyway.  Certainly a lot less redundant bzr churning at least.
<fullermd> Hm.  If you wrote a rich-root-weave format for bzr, you could process it right out of the text storage pretty easily.  Would be a little on the slow side though.
<mgz> just hack something together with bzr annotate and wc, it's a dumb requirement that doesn't need a perfect solution
<fullermd> Hush, you.  Writing a perfect solution would be WAY more fun than wasting time on classwork   :p
<mgz> :)
<swebo> well as i'm not studying computer science, it doesn't have to be perfect at all ;)
<git__> what's the diff between bzr upload and bzr export ?
<soren> git__: Couple of things..
<soren> git__: export doesn't let you push to a remote location.
<soren> git__: ..and doesn't let you export to a location to which you've already exported (it complains about a not being able to export to a non-empty directory.
<soren> git__: upload does supports both of those things.
<soren> git__: So export is what you use for a one-off sort of export, while upload is good for e.g. doing development locally and every once in a while pushing to a remote location, like a webserver.
<git__> thanks soren, you are very thorough with your answer, really appreciated !!!
<soren> git__: Sure.
#bzr 2010-09-26
<mtaylor> jelmer: how hard is it to use the rewrite plugin to go through and replace the committer on a bunch of revs? (as in, retroactively fix someones commits who had never done bzr whoami...) ?
<jelmer> mtaylor: you'd have to patch it to do something like that
<jelmer> mtaylor: it shouldn't be too hard to do using a patch, but it's not possible using the current UI
<mtaylor> jelmer: ok. good to know
<mtaylor> jelmer: I may poke at that at some point - I think I'd like to make a pass on our tree to clean up a bunch of revs that have bogus people having committed them
<jelmer> mtaylor: this will affect the revision ids of all revisions since the first that is changed, of course.
<echo-area> Hello, I upgraded to bzr-2.2.0 on my Windows machine, and then get this error every time I execute bzr: "Unable to load plugin u'rebase'. It requested API version (2, 1, 0) of module <module 'bzrlib' from 'C:\Program Files\Bazaar\lib\library.zip\bzrlib\__init__.pyo'> but the minimum exported version is (2, 2, 0), and the maximum is (2, 2, 0)"  How to resolve this?
<echo-area> I see that rebase is now renamed to ``rewrite''.  Could I simply remove the subdir `rebase' in plugins?
<echo-area> I've done that and don't see problems.  I think it works
<fullermd> Yes, the plugin was renamed.
<nprasath002> Does netbeans has a bzr plugin? is the developement still active?? where can i get it??
<lifeless> nprasath002: I'm not aware of one; it would be awesome to have one.
<snowdrop> I did a "checkout --lightweight" but can't commit to it, get the followin error msg: "bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~wtdevs/wtactics/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() "
<snowdrop> any pointers? (And yeah, I'm new to bzr... only had some experience with SVN before.)
<mgz> checkout from a branch you can write to, which means not over http.
<mgz> if you used a lp: shortcut, this means running `bzr launchpad-login` and setting up ssh, then doing the same thing again.
<snowdrop> mgz:  i see....  is there a way to change the http:// stuff in the branch I already checked out?
<snowdrop> mgz: So i don't have to check it out once again?
<mgz> `bzr pull --remember lp:<sameasbefore>` should work I think.
<snowdrop> mgz:  thanks.. on it.
<snowdrop> mgz: Hrm.. "bzr pull --remember lp:~wtdevs/wtactics/trunk/" gave me same error.
<mgz> did you do `bzr launchpad-login <yourid>` first?
<mgz> you need the ssh access rather than the http, is our aim here.
<snowdrop> mgz: Should I use my personal ID, or the groups id? Cause " lp:~wtdevs"  = the group (wtdevs), while my personal ID is "snowdrop".
<mgz> your personal id.
<snowdrop> mgz: snowdrop@snowdrop:~/WTactics$ bzr launchpad-login snowdrop
<snowdrop> snowdrop@snowdrop:~/WTactics$ bzr pull --remember lp:~wtdevs/wtactics/trunk/
<snowdrop> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~wtdevs/wtactics/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<mgz> okay, try... `bzr switch lp:~wtdevs/wtactics/trunk/` instead
 * mgz doesn't use checkouts much
<snowdrop> mgz: Ah.. success!
<snowdrop> snowdrop@snowdrop:~/WTactics$ bzr switch lp:~wtdevs/wtactics/trunk/
<snowdrop> Tree is up to date at revision 13.
<snowdrop> Switched to branch: bzr+ssh://bazaar.launchpad.net/~wtdevs/wtactics/trunk/
<mgz> good good, and now, if you've made changes, and run `bzr diff` you should still see them
<snowdrop> mgz: Since I did a "checkout --lightweight"... all my "commits" directly upload to launchpad, right? (kind of SVN)? In contrast to when I used "branch" and they were done locally?
<mgz> yup. you should think about changing how you work, but this preserves the svn style for now
<snowdrop> mgz: Thanks a bunch. =)
<snowdrop> mgz: If you take paypal I'd happily buy you a coffe... have been wasting 7h on this... = P
<mgz> I'm good for coffee but feel free to email "Martin Pool <mbp@canonical.com>" and say how helpful I was :)
<snowdrop> = ) will do.
<snowdrop> done.
<vila> mgz: ping, just passing around, were did you end up with garyvdm on the windows installers ?
<thumper> I wish windows would sort out the ssh support
<thumper> https://answers.edge.launchpad.net/launchpad-code/+question/125565 for anyone who knows putty
<mgz> vila: he's got one built that looked solid, but he hit another issue that I couldn't reproduce here
<vila> thumper: hey ! Feeling really optimistic for a monday morning... windows and sort out in the same sentence... :D
<mgz> I'll try and catch up with him on it when I see him in the channel next
<vila> mgz: Thanks. I'll try to read the log tomorrow so use my nick when you think I should double-read ;)
<mgz> I've got another testtools change babune will want, to deal with the log oddness we were seeing on maverick
<mgz> might see if I can track down the timings thing as well tonight.
<vila> I don't quite get what happened here and whether there is a way to address this kind of issue that delay the official announce for a single installer... but we should definitely think about it ;)
<vila> mgz: you mean the leaks ?
<vila> the log leaks that is ?
<mgz> yup, that jam was nibbling at the other end of.
<vila> ha, I wish there was an option to keep the log for successful tests, pqm is one thing, babune is another and even if hudson doesn't provide access to this yet...it's a shame to not collect it anymore ;-/
<mgz> yeah, I think we can back out the hacks but keep the tests for that change when we fix some other things in future
<vila> I didn't have the time to follow more closely and I
<vila> 'm wondering which object is responsible for or can introduce a variation in the way such test attributes are handled...
#bzr 2011-09-19
<poolie> hi all
<nigelb> Morning poolie!
<poolie> hi nigel
<vila> hi all !
<poolie> hi vila
<jam> morning all
<poolie> hi there jam
<poolie> vila, istm wrt packaging plugins, the most scalable thing is to get babune jobs going for bzr+plugins
<vila> poolie: right
<vila> poolie: the issue is to install the right plugins for the right bzr versions and decide what kind of test run we want
<vila> poolie: all selected plugin tips against bzr.dev is probably the first step
<poolie> sounds good to me
<poolie> as a first step, doing that just for one plugin would be good
<poolie> we can get that green then iterate
<vila> poolie: but it should be done in a way tht doesn't break running bzr.dev itself (i.e. without plugins)
<poolie> that could be either one that's really unlikely to break, or that's very actively maintained
<poolie> what do you mean?
<poolie> i think we need a separate job from the tests for bzr itself
<vila> yes, separate run isolated from the plugins
<vila> but the plugins still need to installed on the slaves, jenkins tracks a single branch for a given run
<vila> s/to/to be/
<poolie> oh, i see
<poolie> it has no capability to test combinations of branches?
<poolie> i'm surprised
<vila> poolie: it's somewhat related to testtools/subunit deployment on all slaves and also with bug #839461
<ubot5> Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [High,Confirmed] https://launchpad.net/bugs/839461
<poolie> surely other people use jenkins to test combinations of one project running on another?
<vila> poolie: nothing in the GUI hints at that (imbw)
<vila> or if they do they use other tricks, maven ?
<poolie> hm
<poolie> http://stackoverflow.com/questions/7189874/how-can-i-automatically-build-multiple-eclipse-plug-in-projects-as-one-jenkins-pr suggests it is "make everything look like one big branch"
<poolie> does it really need to know about all the branches?
<poolie> how about having just one job that runs every day and just does a 'pull' on every branch, then runs the tests?
<poolie> i know that's not quite elegant
<lifeless> sorry, I'm missing a subtlety
<lifeless> whats the problem ?
<poolie> i would like to test bzr tip against the tip of various plugins
<poolie> vila says this is hard because jenkins does not have a concept of one job depending on multiple branches
<lifeless> its pretty straight forward
<lifeless> setup one job that as you say branches LP then uses a script to branch in the dependencies / plugins.
<lifeless> setup one job per thing you want to trigger that job, and have that jobs test be a no-op (or even run just the tests for that plugin, if you like)
<lifeless> et voila
<lifeless> s/branches LP/branches bzr/
<lifeless> the script is the 'pre actions' in jenkins, doesn't need to be formal; just a few lines of bash in the config pag.e
<poolie> so the second job is "when lp:bzr-svn changes: do nothing; then run job 1"
<lifeless> for instance, yes.
<lifeless> it could be 'package and build bzr-svn; if that works run job 1'
<vila> multiply by supported platform
<lifeless> which is what dx's hudson does/did - it would ppa build take the package then use it as a dep in all the things that use it.
<lifeless> vila: the platform multiplier should be straight forward with matrix
<lifeless> vila: but even a single platform would be a big win on its own, no?
<poolie> +1
<vila> patches welcome ? :D
<poolie> seriously, just ignoring multiplication for now would still give us something really useful
<poolie> then if it turns out that it is useful, but we're missing things that only occur on other platforms, we can work out how to add it
<poolie> doing just a single version does not seem like it would make that any harder to do later on
<lifeless> vila: I'll trade, you can bootstrap SOA on Launchpad and change nappies in alternating hours, I'll drive your point-n-click CI tool :P
<poolie> ow
<vila> I can put that on top of my babune TODO list but I'd like to clean up my plate a bit before switching to it
<vila> changing nappies....
<vila> cute memories :)
<vila> anyway, babune's backup is under way and therefore it's off-line right now
<MvG> Hi! I'm trying to deprecate an argument to a builtin command (wrt. lp:~gagern/bzr/log-omit-merges). Added code using symbol_versioning.deprecated_passed and so on as other parts of bzrlib do. selftest does see the deprecation warning in its captured command output, but I myself don't. And I'm not running a final version of bzrlib either. Does anyone know whether deprecation warnings might be configured off somewhere?
<lifeless> MvG: running a recent python ?
<lifeless> MvG: upstream turned deprecations off globally. Because they were ugly or something.
<MvG> lifeless: Yes, very recent python.
<MvG> So if I want to warn the user about something, I'll have to drop the warning category?
<lifeless> I don't know what we should do here.
<poolie> MvG, DeprecationWarning is only for developer-oriented deprecations
<poolie> there is a separate ui_factory.user_warning
<poolie> (sp?)
<poolie> which is more appropriate
<lifeless> theory is that devs will turn deprecations on so that they know.
<lifeless> however, your experience demonstrates the obvious flaw there, that I was worried about :)
<poolie> we use a separate mechanism for a bunch of reasons, one being that the python deprecations tend to error out or to print lines of code that are not appropriate for users
<poolie> also to vary across platforms
<poolie> lifeless, i think one of the best things is to set the equivalent of -Werror from the test suite
<poolie> at least optionally
<poolie> which bzr does
<vila> lifeless: there are various ways to make this work with jenkins, none are trivial and I'm already focusing on other stuff for today (bug #795321 and some config stuff for/with jelmer)
<ubot5> Launchpad bug 795321 in Ubuntu Distributed Development "udd importer should make tea while launchpad is down" [High,In progress] https://launchpad.net/bugs/795321
<lifeless> vila: thats fine, we've moved on haven't we ?
<vila> lifeless: yeah ;)
<vila> ok, let's have tea
<MvG> jelmer, vila, jam: Will you re-review https://code.launchpad.net/~gagern/bzr/log-omit-merges/+merge/74821 or should I file a new merge request?
<poolie> MvG, you don't need to file a new request but asking for review (as you did now) is useful
<jam> MvG: arr, matey, I be slackin' on givin' ya feedback
<jam> MvG: did ye just push some changes? It be claimin that the diff be updatin soon
<MvG> jam: Pushed some a moment ago, yes, and to me lp talked about updating the diff. Done so now.
<jam> http://www.talklikeapirate.com/ in case ye be wondrin
<MvG> ARG! the diff has a merge conflict, although I just merged bzr.dev into my treee. Probably hadn't pulled bzr.dev before that...
<poolie> o/ jelmer
<MvG> vila: thx 4 the review!
<vila> MvG: be my guest ;) Wait for some more opinions though ;)
<MvG> It's not as if I could send this to pqm mysel before that, is it?
<vila> hehe :)
<vila> touche
<MvG> btw: added one release notes item after your review. is that going to confuse pqm?
<vila> MvG: nope, pqm uses the lp branch when it receives the submissions and nobody sent the submission so far
<MvG> So I could slip an arbitrary change into a branch after sane stuff has been approved? Sounds frightening.
<MvG> btw: I'm (mostly) around in case someone wants to talk about the really evil bug #842695.
<ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695
<vila> did anybody ever witness rsync "pausing" for a long time ? (the file it's trying to sync is ~30GB if that's relevant)
<vila> "pausing" in this case includes a case where the tmp file on the receiving side wasn't updated for ~1h and both client or server rsync processes were sleeping (AFAICS)
<MvG> nope, but does sound bad.
<MvG> strace those processes'?
<vila> can I do that for an already running process ?
<MvG> yepp
<MvG> at least on linux
<MvG> probably won't tell you mich if the process is really asleep, but otherwise you should see some i/o
<MvG> can even gdb the running process, see what it's waiting for, but that will probably require debug symbols.
<MvG> The "Unmerged revisions" list in https://code.launchpad.net/~gagern/bzr/log-omit-merges/+merge/74821 is incomplete, and doesn't indicate so. I'd consider this a bug in LP, do you agree?
<poolie> yes, very much
<poolie> not one i remember seeing before either; please file it
<vila> MvG: only the 10 most recent ones but none of the previous ones ?
<jelmer> hi poolie, MvG, vila
<jelmer> sorry, had to go out for some emergency coffee beans
<poolie> :) tut tut, insufficient preparation :)
<vila> jelmer: _o/
<poolie> i see Riddell's pilot this week
<poolie> ok i'm off to squash
<poolie> possibly but probably not back later
<Riddell> I shall steer the ship of patches with precision!
* Riddell changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: Riddell
<poolie> pilot like a pirate
<poolie> riddell did you see my blog post draft?
<poolie> if you can't get at it, ask in #is
<Riddell> poolie: no I don't thinkso
<Riddell> on the bazaar blog?
<jelmer> poolie: have fun :)
<poolie> can you click login on blog.bazaar.canonical.com?
<jelmer> vila: Have you seen issues with http redirects to the root of the server rather than the actual location?
<jelmer> http://varnish-cache.org/svn/trunk/ is permanently redirected to https+urllib://www.varnish-cache.org/
<Riddell> poolie: i don't see a login option
<vila> the only bell ringing is one about some path lost inside bzrlib or a plugin, I forgot the root cause
<Riddell> oh "log in"
<Riddell> poolie: ok I see "bzr starts speaking your language"
<poolie> yep, edit to taste and post
<poolie> or not
<Riddell> I had a blog post on my own blog last week
<Riddell> but my blog seems to have falled off planet bazaar :(
<Riddell> probably because of the move to a new kde.org domain
<poolie> oh right, i saw that
<poolie> sorry i forgot
<poolie> file an rt i guess
<Riddell> I'll just post this one then do the rt thing
<jelmer> vila: HttpTransport._redirected_to seems to strip it, I'll have a closer look
<vila> that rings another bell... unclear, but I seem to recall some servers not sending back the proper url to redirect to under... some circumstances ? Sorry for the vagueness :-/
<jelmer> vila: if we redirect to something non-http/https then we drop the path component
<vila> urgh, including http+urllib ?
<vila> oh, httpS+urllib ?
<jelmer> yep
<vila> hmm, I thought this was taken care of, I'm pretty sure there are even tests for that... regression ?
<jelmer> it might be a regression, but at least there are no tests for this
<vila> test_redirected_to_same_host_sibling_protocol
<vila> test_redirected_to_same_host_different_protocol
<jelmer> vila: that second test doesn't check the r.base
<vila> that's the hole :)
<vila> hmm, well, the base may change for a redirect so the test is... incomplete ?
<jelmer> yeah, I'll add some tests for r.base too
 * vila nods
<jelmer> vila: hmm
<jelmer> vila: it looks like the issue is that self._path has a trailing / whereas the source URL that is being passed in does not
<vila> stupid Apache ? They are the same damn thing but Apache insists that a dir must have a trailing /, is this the case here ? Or is there more than the final / that differs ?
<jelmer> this is actually in our tests, we seem to assume that the server will send a trailing slash
<jelmer> I'm hitting this trying to test _redirected_to directly
<vila> hmm
<vila> I think our test servers follow apache and *will* send a trailing slash, not a good reason to assume they will always do though
<vila> jelmer: yeah, see http_server.py ~line 198
<vila> how do the tests assume that ?
<jelmer> Transport adds a trailing slash
<jelmer> >
<vila> transport as in our own bzrlib.transport ? I know there was a very old bug about *not* stripping the final slash when we know we're talking about a dir, I'm pretty sure this has never been fixed though
<jelmer> vila: see bzrlib/transport/__init__.py:1326
<vila> jelmer: yeah, bzrlib.transport.Transport.relpath line 513 blindly strip
<vila> jelmer: but who talks last ? :)
<jelmer> vila: Transport.relpath isn't broken, but _redirected_to has its own relpath implementation
<jelmer> and that relpath implementation breaks with a trailing slash
<vila> strip() triggers only if there is one to strip, what is breaking exactly ?
<jelmer> vila: it returns an empty string
<jelmer> vila: and that causes parsed_url.path[:-len(relpath)] to break
<jelmer> as parsed_url.path[:0] == ""
<vila> I miss some context here, what is the abspath that leads an empty relpath() ?
<vila> s/leads/returns/
<jelmer> e.g. http://www.example.com/foo, for transport with base http://www.example.com/foo/
<vila> right, so that's 'base_path = parsed_url.path[:-len(relpath)]' which is bogus, the base_path should just be relpath right ?
<vila> errr,should just be parsed_url.path
<jelmer> that was my thinking too, that would also simplify a bit of the other code
<vila> jelmer: so, in your case, the server redirected from 'xxx/' to 'xxx' ?
<jelmer> vila: the server redirects from http://foo/bar to https://foo/bar
<jelmer> (note the missing trailing slashes)
<jelmer> and what _redirected_to sees is a call with "http://foo/bar" and "https+urllib://foo/bar"
<vila> ooooh, no slash nowhere and *we* injected a slash
<vila> and probably never encountered it before because we received redirected urls with trailing slashes ?
<jelmer> yeah
<vila> (including our test servers....)
<vila> wow
<jelmer> this might be a regression when I introduced the URL classes
<vila> doesn't seem to be the case, the relpath handling there is... unclear, the comment says why we do it, but an example may have been clearer
<vila> jelmer: do you know what kind of server is involved there ?
<jelmer> no idea
<jelmer> vila: it seems to break with our existing _redirected_to tests too
<jelmer> see the tests added in r-2 in lp:~jelmer/bzr/853765-http-redirects-broken
<vila> what ? the fix we just ... let me look
<vila> jelmer: meh, I've got failures from test_http.SmartHTTPTunnellingTest.test_open_bzrdir ???
<jelmer> vila: try the second to last revision, that just changes tests
<vila> eeerk, tests failing on trunk !
<jelmer> which ones, and how?
<vila> at revno 6144, the ones I mentioned above, no pycurl on pqm nor babune ?
<vila> InvalidURL: Invalid url supplied to transport: ""
<vila> bzrlib.tests.test_http.SmartHTTPTunnellingTest.test_open_bzrdir(pycurl,HTTP/1.1)
<vila> bzrlib.tests.test_http.SmartHTTPTunnellingTest.test_open_bzrdir(pycurl,HTTP/1.0)
<jelmer> seems fine here
<jelmer> what's the backtrace like?
<vila> http://paste.ubuntu.com/692972/
<vila> jelmer: ha, some plugin is involved, using BZR_PLUGIN_PATH=-site, the test succeed
<jelmer> vila: ah, ok
<jelmer> vila: I'm looking into the redirected_to issue further, thanks for the hints
<vila> ok, thanks
<jelmer> vila: fixed, https://code.launchpad.net/~jelmer/bzr/853765-http-redirects-broken/+merge/76014
<vila> jelmer: looking
<vila> jelmer: BB:tweak
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer, hey. i updated the bug comments if you saw it :-)
<jelmer> Noldorin: yep! did you post the actual script to reproduce it ?
<Noldorin> jelmer, no but i can give it to you now
<Noldorin> it's a powershell script
<Noldorin> or just push the test repo somewhere if you like
<jelmer> Noldorin: the test repo won't be of much use, but it'd be great if you can attach the powershell script
<Noldorin> jelmer, will do
<Noldorin> did you see my previous note about the rename error btw?
<Noldorin> that may be the cause
<Noldorin> that bzr-git isn't handly it properly...
<jelmer> Noldorin: how do you mean?
<Noldorin> jelmer, the error in my penultimate comment
<jelmer> Noldorin: doesn't that happen before you call dpush?
<Noldorin> jelmer, yes but i think it could still be a hint as to whjat's 'upsetting' dpush
<jelmer> hmm, that's an interesting thought
<jelmer> although that's definitely a different issue from the original bug
<Noldorin> okay
<Riddell> MvG: log-omit-merges seems to be approved, I don't think you have permission to send it to PQM, would you like me to do so?
<MvG> Riddell: Yes, please.
<MvG> Should I enter a comit msg in lp first, or will you take care of that as well?
<Riddell> MvG: yes do, you'll know better than me a good message
<Riddell> jam: don't forget the question for you on https://code.launchpad.net/~spiv/bzr/faster-stacked-tree-build/+merge/70381
<MvG> Riddell: Should I include my name in the commit msg, or will pqm add that automatically?
<Riddell> MvG: no need, your name will be in the merge changelog and more importantly in doc/en/release-notes/bzr-2.5.txt
<MvG> Riddell: OK, commit message updated (was already entered but out of date). Ready for pqm as far as I am concerned. Thx for submitting it!
<Noldorin>   jelmer back
<Noldorin> jelmer, will upload shortly
<MvG> Trying to figure out what behaviour people expect, I've got a question for everybode around here, related to bug #842695.
<ubot5> Launchpad bug 842695 in Bazaar "log --include-merges apparently prints unrelated commits" [Undecided,New] https://launchpad.net/bugs/842695
<MvG> Suppose a feature branch branches off trunk at revision 10, at some point merges r 30 of trunk, and gets itself merged into trunk at r 40. Suppose furthermore that some other branch gets merged at trunk r 20, and that that branch modifies files in a given directory foo, not modified by any other branch since trunk r 10.
<MvG> Now if you do "bzr log -n0 foo" on the trunk, would you expect to see the commit where trunk was merged into the feature branch?
<MvG> Personally, I would not, because the feature branch was not dealing with directory foo at all, except for merging from trunk things which the log will already report in other places. But current log implementation does (mostly) report that, based on the fact that the merge modified that directory relative to the leftmost parent inside the feature branch. Which is unserstandable, once you think of it in those terms, and really makes me wonder whether
<Riddell> MvG: whether...   I think you got cut off
<MvG> I did? Pidgin doesn't reflect that fact... :-(
<MvG> [...] and really makes me wonder whether other people would expect the same behaviour that I expect. So please let me know what you think!
<jelmer> MvG: I think the current behaviour makes sense, but I don't feel strongly either way.
<MvG> Current behaviour can lead to a single file being reported as "added" multiple times in the verbose log. Which I consider one of themost confusing aspects about this interpretation, and which is also the root of the bug described above.
<Noldorin> hi jam
<Noldorin> jelmer, just added a new comment with the script attachment
<jelmer> Noldorin: thanks
<Noldorin> jelmer, you can probably write a bash script to do the same thing
<Noldorin> jelmer, then have a very simple example to debug. i bet you will see immediately :-)
<Noldorin> jelmer, hey, back
<jelmer> Noldorin: hey :)
<Noldorin> jelmer, okay so i guess you're actually wanting me to write the unit test for this ;-) still, we are very very close now
<Noldorin> in that...
<Noldorin> we have it reproduced in a *new* branch
<jelmer> Noldorin: well, close to that but yeah :)
<jelmer> Noldorin: it's still a branch with a lot of extra data that makes it hard to see what the actual issue is
<jelmer> and something that's indeed hard to turn into a unit test
<Noldorin> jelmer, no, it's precisely a new branch. it doesn't import any metadata, just file data
<jelmer> Noldorin: that's still a lot of extra data
<Noldorin> true
<Noldorin> let me see what i can do...
<Noldorin> jelmer, i also am curious when the 2.5b1 windows setup will be out...i guess jam builds it
<jelmer> Noldorin: related to that, I just proposed adding bzr-git to the installer: https://code.launchpad.net/~jelmer/bzr-windows-installers/bzr-git/+merge/76100
<Noldorin> jelmer, awesome :-D
<Noldorin> jelmer, site we got site-packages though, it's pretty easy to add manually anyway though
<Noldorin> only that annoyingly python doesn't recognise symlinks on windows :-S
<jelmer> Noldorin: presumably it shouldn't matter what the contents of the files are that change, just whether they changed
<Noldorin> so i can't link it to the repository
<Noldorin> jelmer, indeed
<Noldorin> jelmer, okay, got a script that reproduces it from scratch :-D
<Noldorin> will post now
<Noldorin> jelmer, done! check the comment log
<mars> Hi, has anyone noticed that the Ubuntu Software Center in Oneiric has two packages named Bazaar?
<mars> One is Bazaar itself (titled Bazaar Version Control System), the other is bzr-gtk
<wiz> hello everyone :)
<jelmer> hi mars
<jelmer> mars: no, I hadn't seen that. Can you file a bug?
<mars> jelmer, certainly
<mars> fwiw, here is what I see when I search: http://people.canonical.com/~mars/USC%20Bazaar%20search%20-%20Screenshot%20at%202011-09-19%2016:54:02.png
<wiz> it would be great if someone can provide a bit of light for me regarding the bazaar :) I'm currently considering to begin to use it... but there is one thing that bothers me and I didn't find it within documentation yet :(
<Noldorin> jelmer, so?
<poolie> hi all
<mgz> hey poolie.
<poolie> hi mgz
<jelmer> hi poolie, mgz
<jelmer> Noldorin: I'll have a look in a second
<poolie> hi jelmer
<jelmer> mgz: did you see my follow question to the bug you filed about cache files opened by bzr-git on windows?
<jelmer> *follow-up
<mgz> ah, not yet, I'll look at it.
<poolie> hi jelmer
<jelmer> hey poolie
<jelmer> hmm, glitch in the matrix?
<mgz> :)
<Noldorin> jelmer, ok cool
<jelmer> poolie: do you have anymore thoughts on landing the colocated format changes?
<jelmer> I'd like to move it forward but am not entirely sure how to do so.
<jelmer> mars: thanks for filing that bug
<AfC> poolie wins coolest unicode glyph of the day award with 'âª'
<poolie> :)
<poolie> i hope it means what i think it means
<jelmer> a tent falling in the sea?
<soren> There are some delightfully confusing glyphs in that section. âª is particularly spectacular. "Can you use it in a sentence?"
<Noldorin> jelmer, that other rename error can be dealed with separately you think eh?
<Noldorin> jelmer, i guess the first thing with your testing is to convert that into a bash script (pretty easy i think) and then check what's going on in bzr-git!
<Noldorin> the problem boils down to moving a subdir into a newly created dir it seems
<Noldorin> hmm
<jelmer> Noldorin: looking now
<Noldorin> great
<Noldorin> jelmer, just poke me if you need help with the script/other stuff, i'm not going anywhere. :-)
#bzr 2011-09-20
<Noldorin> jelmer, any progress?
<Noldorin> zzz...
<Noldorin> jelmer, well, will be around another hour or so still i think
<Noldorin> just saw the update
<Noldorin> awesome
<smoser> is it possible to do what i want here:
<smoser> bzr diff ../milestone-proposed -r 1184
<poolie> that command works
<poolie> what do you want it to do?
<smoser> well, yes. it exits 0
<smoser> i want to know what the differences between this dir and the branch at tip ../milestone-proposed at revision 1184
<smoser> s/tip /tip and /
<smoser> err...
<smoser> this dir at tip and revision 1184 of ../milestone-proposed
<smoser> poolie, ^
<poolie> bzr diff -r 1184:../milestone-proposed
<poolie> if by 'this dir' you mean '.'
<smoser> thank you sir.
<smoser> is there a way to say "tip" in the above ?
<smoser> i guess '-1' works.
<smoser> but that always seems so counter-intuitive to me
<smoser> i like git's "HEAD" alias
<spiv> smoser: do you mean rev 1184 of 'this dir' or of milestone-proposed?
<smoser> milestone-proposed
<smoser> poolie's answer was what i wanted.
<spiv> Oh, right.
<poolie> smoser, if you want to diff . to the tip of milestone proposed
<poolie> bzr diff -r ../milestone-proposed
<Noldorin> jelmer, catch you tomorrow probalby...
<idnar> under what circumstances does the submit branch get set by bzr?
<AuroraBorealis_> the waht
<idnar> submit_location, :submit, I'm not sure exactly what to call it; it's used as the default target for bzr send, among other things
<AuroraBorealis_> hmm
<AuroraBorealis_> ive notused that feature so i'm not sure
<AuroraBorealis_> is it in bzr.conf or the user config file?
<idnar> it's stored in .bzr/branch/branch.conf along with push_location, parent_location etc. (although the global locations.conf can override that)
<idnar> I don't use it much either, but somehow my "trunk" branch keeps on getting some random local branch set as the submit branch
<AuroraBorealis_> what is it set to by default?
<idnar> nothing
<idnar> unfortunately every time I notice it, it's been too long since I actually did anything with the branch it's referring to, so I can never figure out what it is I'm doing that causes it to be set
<idnar> oh hang on
<AuroraBorealis_> one of the other developers will probably know better
<idnar> I think I just figured it out (this always happens as soon as I decide to ask on IRC about something)
<AuroraBorealis_> i know right =P
<idnar> bzr merge sets the submit branch if it's not already set; that seems... weird
<vila> idnar: use --no-remember
<idnar> yeah, but how will I ever remember to do that? :P
<idnar> I suppose it makes sense for "downstream" merges
<idnar> it's just that I mostly only do "upstream" merges, so it seems backwards to me
<vila> yeah, that's the problem with default values, sometimes you can't satisfy everybody :-}
<idnar> is there some way to make --no-remember the default for bzr merge?
<idnar> perhaps I should just not care about it, I don't think I ever run any command on my "trunk" branch that uses the submit branch, so it doesn't really matter if it gets set to something
<vila> well, having a submit_branch set
<spiv> idnar: "bzr alias merge='merge --no-remember'"
<vila> idnar: yup, that's what I do (don't care), in rare cases I have to 'bzr config --remove submit_branch' or force a different value, but still, in most of the cases, --remember is what I want
<idnar> vila: I guess we have different workflows or something
 * vila nods
<idnar> 90% of the time when I run bzr merge, it's to land a branch on trunk
<vila> idnar: just set a submit_branch for trunk and it will be kept
<AuroraBorealis_> how do you set a submit branch
<spiv> vila: trunks typically don't have a submit branch, though?
<AuroraBorealis_> edit the config file?
<idnar> yeah, but what would I set it to? I suppose I could make it the same as the push location
<vila> spiv, randi: indeed, but I use the remote branch i.e. the push_location
<spiv> (I mean you could set it a dummy location like /dev/null, but that's obviously a hack)
<vila> using the push_location also is the Right Thing for diff -rsubmit:
<spiv> vila: sure, a copy of trunk might have a semantically sensible push_location
<idnar> hmm, I keep forgetting about bzr lp-submit
<spiv> vila: I don't think it makes good sense to say it has a submit_branch though.  It's a sink for submissions, not a source.
<idnar> yeah, ideally if I run some command that uses the submit branch, it would just give me an error about there being no submit branch, instead of doing something meaningless
<idnar> not that it's a big deal, more of a semantic nit
<spiv> (A setting that happens to produce ok behaviour in the tool does not automatically equal a setting that makes sense to humans)
<idnar> hmm, that reminds me, there's a bzr merge --preview; but is there a way to do it from "the other side", like bzr send --preview or something?
<idnar> (I'm not sure if bzr send would be the right command for that, just trying to explain what I mean wrt direction)
<spiv> idnar: instead of 'bzr merge --preview FOO', 'bzr merge -d FOO --preview .", perhaps
<idnar> hmm, that only works with local FOO
<spiv> Otherwise you could probably use -rancestor: or something like that
<spiv> idnar: hmm, I thought that might be the case :/
<spiv> idnar: that's probably a relatively easy to fix limitation
<spiv> (and it probably already has a bug report...)
<idnar> heh
<idnar> well, not really important, I was just pondering if I could actually eliminate bzr merge from my workflow almost completely ;)
<idnar> Tarmac eliminates the need to actually land the branch on trunk myself; but I still need a way to preview the merge result for code reviews, when Launchpad's preview isn't sufficient
<vila> spiv: I've yet to encounter a case where using such a submit_branch cause problems
<idnar> (not that there's any particular need to eliminate bzr merge from my workflow, it was just an interesting thought)
<vila> err
<vila> s/<engrish>/I've never encounter/
<vila> and hi all !
<vila> spiv: and to be honest I have to "trunks": a mirror of upstream and an integration one. The later is where I merge various other branches before submitting to pqm.
<spiv> vila: I'm not saying bzr will misbehave, I'm saying that it doesn't make sense to a human reader of that value.
<vila> The later has a push_location which is *not* lp:bzr, in fact public_branch and push_location are my lp corresponding branch and the *submit_branch* is lp:bzr, all locations make perfect sense there (parent_location is lp:bzr)
<spiv> vila: sure, in your workflow for working with lp:bzr (which involves PQM, etc) that's fine
<spiv> vila: there are common workflows where having a submit_branch set doesn't match reality, even if it is technically harmless
 * vila nods
<vila> It also works for the plugins I maintain where I have: parent_location=lp:plugin, push_location=lp:plugin and submit_branch=lp:plugin where my "trunk" branch in this case is really the authoritative branch and the integration one
<vila> When I say "works" I mean: having a submit_branch is enough to avoid merge setting it to an inappropriate value
<spiv> But don't you agree that ideally in that case it wouldn't be set at all?
<spiv> The answer to "where are changes made on this branch submitted to by default?" is "they aren't!"
<vila> well, no :) *I* use it with diff -rsubmit: to check what I will push
<spiv> Wouldn't diff -rpush: would make more sense for that?
<spiv> (and be shorter to type!)
<spiv> Or missing :push, perhaps.
<vila> could be, but diff -rsubmit: is faster because it's bound to H-z m (2 keystrokes) whereas diff -rpush: is not :-D
 * spiv raises an eyebrow
<vila> spiv: but yes, I agree that for authoritative trunks, there is no places from where you want to merge, they are potentially different for every merge
<poolie> hi vila, diff
<poolie> s//spiv
<vila> lol
<vila> poolie: _o/
 * spiv waves
<poolie> Riddell, hi
<poolie> jelmer, vila, riddell, jam, chat in 5m?
<Riddell> hola
 * vila nods 
<jelmer> already doing the audio configuration dance
<jelmer> :)
<poolie> :)
<jam> hi poolie, I'm in
<jam> vila: I have to go work with my wife for a little bit, but it would be nice to hear your thoughts on the select() issue.
<jelmer> Riddell: is there more work to be done on the packaging guide for UDD?
<poolie> hi jam
<poolie> is there any discussion about it other than the mp?
<poolie> i was going to say specifically for EINTR
<vila> jam: sure, roughly: let's make it simple in production (no loop), pay a bit in the test suite while filing a bug about easier ways to get servers running in their own process (there are ways to get *one* process shared between tests)
<Riddell> jelmer: I don't think so (there's more work to be done on it for traditional packaging)
<jam> poolie: I think it has mostly been on the mp or on the bug. Though I guess there has been a fair amount last week between vila and I on IRC
<poolie> you should almost always just restart the syscall, perhaps just checking any other preconditions like "was i interrupted" or "has the timeout expired"
<jam> poolie: right. which points me at vila: we need a loop to handle EINTR, we may as well keep the loop
<vila> poolie: I went to the bug yesterday to mention the error handle only to find you an spiv already saying the same thing
<vila> jam: only for tests no ?
<jam> vila: EINTR we need to handle in production
<poolie> keep the loop and use it for what?
<jam> otherwise if someone resizes the terminal during 'bzr serve' it could cause weird interactions.
<poolie> right
<jam> poolie: to handle EINTR, we nede to catch the exception and restart select()
<vila> resizing the terminal in production ?
<jam> so we need a loop
<jam> vila: "bzr serve" on my terminal, and then resize it
<jam> triggers signals
<jam> which the application might ignore
<jam> we've had bugs in the past
<jam> where it caused EINTR that we didn't handle, and bzr crashed
<poolie> i'll reply abotu that
<jam> I *think* we fixed them by no longer listening to SIGWIN* or whatever
<poolie> yep, we don't want that
<poolie> correct
<poolie> but, eintr should still be handled
<vila> sounds out of scope for the bug you're after no ?
<jam> but it is something that, in general, we should have a loop to handle EINTR for cases where we get a signal
<jam> which is unrelated to this select
<jam> vila: getting *any* signal causes all blocking calls to return
<jam> with EINTR
<jam> read/select/etc
<vila> yeah, not the bug you're fixing right now
<jam> vila: we would be *introducing* a new bug if I don't handle EINTR
<vila> ?
<jam> vila: specifically, with the code I'm writing, if I don't handle EINTR, I will disconnect clients if the process gets a signal
<jam> (the way the code is written today)
<jam> vila: as a "for example", say we have a signal that you can use to tell bzr to do a memory dump. We don't want clients to get disconnected while trying to get a memory dump of the running server process.
<vila> and you want to take care of that for every call to select/recv/send ?
<jam> vila: we already should be taking care of it, and don't
<jam> we do in some places
<jam> which is why the osutils wrappers exist
<jam> vila: "osutils.read_bytes_from_socket" has EINTR handling
<jam> as does osutils.send_all
<jam> And a fairly obvious "osutils.until_no_eintr"
<vila> how about having the main thread takes care of signals and put the real server in its own thread so we get the same model for PipeServer and TCPServer instead of tracking every call that happens in the call stack then (but I didn't mention that to in your bug scope...)
<poolie> jam, done
<jam> poolie: thanks for the review. I did fix the rs/xs stuff but forgot to push the latest, though you still found a couple bugs I didn't fix
<jam> poolie: actually, because you noticed I wasn't terminating the loop on 'xs', that might be why I was seeing bugs even when passing errfds.
<jam> Specifically, the first call would get 'you have an error here', and return it into xs
<jam> but then I wouldn't stop the loop
<poolie> right
<jam> and then the rest of the calls wouldn't say anything
<poolie> that could very well cause it to hang if the near end of the socket closes
<poolie> though...
<poolie> i would have kind of expected select might just error out entirely
<poolie> oh, on the other topic of running the server out of process
<jam> poolie: I would think I would have kept getting xs returned, though, so even if we loop until timeout, it would still end up with xs
<poolie> it does seem like it would fix some persistent kinds of bugs where tests misbehave or are not realistic
<jam> The issue was that I was never seeing "xs".
<jam> Anyway, I'll poke at it.
<poolie> also, there is the 'testresources' library which might help with having an external server that runs across multiple tests
<poolie> obviously we would not want to stop and start it on every test
<vila> yup, lp:bzr-local-test-server is a variation around this idea where you explicitly start/stop real servers and inject the running ones into the test suite
<poolie> i'll send out the standup notes
<Riddell> do plugins in bzrlib/plugins/ have unit tests?
<jelmer> Riddell: yes, usually in the tests directory in the plugin
<Riddell> jelmer: oh aye, and do they get run with the normal test suite?
<vila> Riddell: yes, even when you do BZR_PLUGIN_PATH=-site, they are the so-called 'core' plugins
<Noldorin> jelmer, hey :-)
<jelmer> hi Noldorin
<jelmer> Noldorin: do you *ever* sleep?
<Noldorin> haha
<Noldorin> no, i'm always online to pester you ;-)
<Noldorin> i often go to bed very late and wake up around midday
<jelmer> you're in Europe?
<Noldorin> London, yep
<Noldorin> netherlands for you i presume
<jelmer> yep
<Noldorin> want to visit some day :-)
<Noldorin> jelmer, any luck with the issue anyway?
<jelmer> Noldorin: I added a test case for it yesterday
<Noldorin> ok cool
<jelmer> Noldorin: I'm hacking on it in my spare time though, working on other stuff at the moment.
<Noldorin> yes i saw
<Noldorin> okay
<Noldorin> other core bzr stuff eh?
<jelmer> yep
<vila> james_w: ping
<james_w> hi vila
<Noldorin> jelmer, playing more with the script reveals that moving a directory -or- renaming a directory works fine, but doing *both* at once screws it up
<Noldorin> jam, hi?
<vila> james_w: hey ! That was quick :)
<vila> james_w: If you know how to make tea, can you have a look at https://code.launchpad.net/~vila/udd/795321-make-tea/+merge/76058 and give feedback ?
<james_w> vila, yeah, it's in my inbox
<james_w> along with 100 other things :-)
<james_w> I'll look today
<vila> james_w: awesome !
<james_w> I read your cover letter and I think I like your approach
<james_w> I certainly agree that the circuit breaker pattern isn't quite the right fit
<vila> james_w: we expect more lp downtimes so probably more failure storms and I suspect the should_retry have rotten (I'm sure you added transient failures for lp in the past but sigs have probably changed since them)
<vila> james_w: yeah, not a perfect fit, but it helps making the actual code smaller
<vila> (and can be tested independently *today*
<Noldorin> jelmer, that shoudl really narrow it down :-) hopefully you can work on the issue today?
<jelmer> Noldorin: no idea, working on more things than just this...
<Noldorin> okay
<Noldorin> jelmer, we all have our own priorities i guess :-P this is obviously high for me
<Noldorin> but much less high for the bzr time
<Noldorin> jelmer, is bzr-git still the best solution for mirroring LP branches on GitHub?
<jelmer> Noldorin: yep
<mssever> How can I check that a copy of a branch is correct without overwriting the existing branch? I'm trying to recover from serious file corruption caused by Dropbox, and I want to check that they restored things correctly. But when I run bzr in the restored directory, I get this error: No working tree exists for <path to restored dir, which is different from the original>. When I symlink it to the original location, I get the same error, showing the target path,
<mssever> not the symlink path.
<jam> mwhudson: did any of your anonymous ssh stuff land? I'm running into problems with "bzr branch lp:bzr-rewrite" giving me a "bzr+ssh://" URL, even though the build machine has not called "launchpad-login"
<jam> (I don't have an ssh key there, etc.)
<jam> jelmer: Help? It looks like 'bzr-rewrite' lost its development focus branch.
<jam> https://launchpad.net/bzr-rewrite/trunk
<jam> doesn't have a branch link.
<mssever> How can I check that a copy of a branch is correct without overwriting the existing branch? I'm trying to recover from serious file corruption caused by Dropbox, and I want to check that they restored things correctly. But when I run bzr in the restored directory, I get this error: No working tree exists for <path to restored dir, which is different from the original>. When I symlink it to the original location, I get the same error, showing the target path,
<mssever> not the symlink path.
<jam> mssever: if you are running "bzr status" that doesn't apply to a repository/branch that doesn't have a working tree.
<jam> You could try "bzr log" or some other command.
<mssever> bzr log says Not a branch <path> location is a repository
<mssever> jam: See ^^
<mssever> jam: And, it is supposed to be an exact copy of a working tree. Does this mean that it isn't an exact copy?
<jam> mssever: ls .bzr ?
<mssever> jam:  The .bzr directory is there, but I don't know if it has the right contents.
<mssever> Dropbox Updated part of the tree with an old version, and deleted some files
<jam> mssever: sure, I'm asking for the output to help discovering what is going on.
<jam> for example, if there is a ".bzr/branch" or ".bzr/checkout" directories.
<mssever> Oh, OK. Here goes:
<mssever> ls .bzr:
<mssever> branch/  branch-format  branch-lock/  checkout/  README  repository/
<jelmer> jam: I'll set one, thanks for the hint
<jam> jelmer: well, I failed to build the windows installers
<jam> Not sure what changed
<jelmer> jam: fixed
<jelmer> jam: I converted my branch mirrors to code imports
<jam> ok
<jam> are there any others that would be affected?
<jam> jelmer: and, of course, you've now broken my test case for fixing the related mis-communication in bzr :)
<mssever> jam: Did you notice my last reply? I forgot to mention your nick...
<jelmer> jam: I'm checking the other branches now
<jelmer> jam: sorry! I can re-unlink it if necessary :)
<Noldorin_> jam, any idea when the Windows build of 2.5b1 will be available? :-)
<iorec> helos. new to bazaar. looking for a solution to this situation: we have a software project that has public and private source parts. we want both in one repo with user access control to allow some people whole r/w access and others only write access to the public parts. is such a setup feasible  with bzr?
<Noldorin_> jam is ignoring me :-(
<vila> Noldorin_: he is probably building them, that doesn't count as ignoring you :)
<Noldorin_> vila, i was mainly teasing...but yes, i hope so anyway! :-)
<vila> iorec: bzr doesn't support different access patterns inside a given branch, you need to define separate branches
<vila> jelmer: by the way, should you upload 2.5b1 to debian ?
<iorec> vila: so i could have a single repository with public and private branches?
<vila> iorec: see http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief so use the same meanings for the same words :)
<vila> iorec: a repository is just a bag of revisions, a branch is a pointer to an entry point in a graph of revisions (directed and acyclic, so-called DAG)
<vila> you can use the same repository for unrelated branches, but in your case that will make it harder to separate who can write from who cannot
<Noldorin_> jelmer, i see a comment in the bzr-git code saying "renames not supported:...?
<vila> if you keep unrelated branches separate, it will be easier to define the access with scripts like contrib/bzr_access and the like
<cerf> hello all
<cerf> I've just installed bzr v2.4.1 from PPA
<cerf> I'm wondering how to use branch.fetch_tags
<jelmer> Noldorin_: that's for roundtripping
<cerf> should it be set in .bzr/branch/branch.conf or ?
<Noldorin_> jelmer, how do you mean?
<cerf> bazaar.conf ?
<jelmer> cerf: it should be set for the source branch, so either in the source branches' branch.conf, bazaar.conf or an entry in locations.conf
<jelmer> Noldorin_: "regular" push
<jelmer> Noldorin_: not dpush
<Noldorin_> jelmer, oh ok
<Noldorin_> so i can ignore that huh?
<jelmer> Noldorin_: git doesn't do renames
<Noldorin_> got it
<Noldorin_> ooh. another reason not to like git ha!
<iorec> vila: the thing is that we want people with full access to be able to checkout one revision of the main branch and have everything they need (public and private parts) and others with public access only checkout the same revision but only get the public parts.
<Noldorin_> jelmer, i thought bzr cannot do "push" at all to git though?
<Riddell> jelmer: I'm looking at https://code.launchpad.net/~jelmer/bzrtools/unused-imports/+merge/73265 what's the best way to run the test suite of bzrtools?
<jelmer> Noldorin_: it can
<jelmer> Riddell: BZR_PLUGINS_AT=bzrtools@`pwd` bzr selftest -s bp.bzrtools
<Noldorin_> jelmer, but dpush is preferable for some reasons.../
<Noldorin_> ?
<jelmer> Noldorin_: it's experimental, not enabled by default
<Noldorin_> okay sure
<Noldorin_> makes sense
<jelmer> vila: yeah, I should upload to experimental I guess..
<Noldorin_> jelmer, since i am so eager with this, maybe you could point me to the bit of code that handles bzr moves/renames in dpush? :-)
<vila> iorec: bzr tracks whole trees so having people use different trees won't work out of the box, there are some parts of your needs that can be addressed with views, others may work with nested trees (not implemented yet), but overall, there is no way to get what describe directly
<cerf> jelmer: thanks I'll try it
<vila> iorec: s/what describe/what you describe/
<cerf> hope this can help for bug https://bugs.launchpad.net/bzr/+bug/843684
<ubot5> Ubuntu bug 806348 in Launchpad itself "duplicate for #843684 BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged]
<iorec> vila: thanks. it seems so strange that ours is obviously a special case setup since none of the popular revision control systems seem to support such a setup. so it seems to me we'll have to manually handle 2 repos and always say rev XY of repo A is the one that fits rev ZW of repo B.
<vila> iorec: well, once you start using distributed VCS, access rights... are less relevant, to start, either you publish or you don't, if you publish, you don't blindly accept submissions, they are generally checked before being accepted and at that point, the checkers generally have write access
<cerf> so bad, that didn't help
<cerf> still get 'missing chk node(s) for id_to_entry maps '
<vila> iorec: keeping two related projects in sync is what nested trees are about, but the progress is slow on that front as we focus on other subjects (with our limited resources ;)
<cerf> in bug report https://bugs.launchpad.net/udd/+bug/806348
<ubot5> Ubuntu bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged]
<cerf> jameinel talked about a quick regression avoidance with https://bugs.launchpad.net/bzr/+bug/771184
<ubot5> Ubuntu bug 771184 in Bazaar "option to disable/enable fetching of all tags" [Critical,Fix released]
<cerf> how to use it ?
<cerf> I've put 'fetch_tags = True' in the bazaar.conf file of my source branch, but still got a crash
<cerf> I've also tried 'branch.fetch_tags = True" with no luck
<jelmer> Noldorin_: there is no such thing, as git doesn't store renames
<jelmer> cerf: are you sure you're actually hitting *that* bug?
<iorec> vila: yes, i am still new to distributed vcs and hoping i haven't fully understood its potentials yet..
<cerf> I'm not sure, my original bug report (843684) was considered as a duplicate of 806348
<cerf> is it really a duplicate ?
<Noldorin_> jelmer, well, put it this way...where in the code do you "handle" bzr renames...translate them to git?
<cerf> For bug 806384, John A Meinel suggested a "quick regression avoidance" actually bug 771184
<ubot5> Launchpad bug 806384 in Nikki and the Robots "Allow dynamic block coloring" [Undecided,New] https://launchpad.net/bugs/806384
<ubot5> Launchpad bug 771184 in Bazaar "option to disable/enable fetching of all tags" [Critical,Fix released] https://launchpad.net/bugs/771184
<vila> iorec: there is a bunch to read at http://doc.bazaar.canonical.com/ not sure what is the most relevant for you, but asking questions here or on the mailing list is welcome (answers depend on available time though ;)
<jam> mssever: Sorry, I had to step away for a sec. If you have ".bzr/branch" but it says "not a branch", then something is particularly broken.
<cerf> so this where I am, I'm stuck at trying to do do simple merge between two branches
<jam> I don't really have the time to debug it at this point. You can try to create another branch in a different location, and see how they differ.
<iorec> vila: ya thanks i'm already reading...
<jam> Noldorin_: I don't specifically know when 2.5b1-1 will be available. I started working on it this afternoon, but ran into problems with plugins no longer being available. (jelmer changed some things, and accidentally broke the linking).
<jam> That looks to be fixed, but as I'm past the end-of-day here, it won't be worked on until tomorrow at the earliest.
<jelmer> Noldorin_: renames aren't "handled", but _revision_to_objects (IIRC) is where generating the git objects happens.
<Noldorin_> jelmer, okay got it
<Noldorin_> ta
<jam> vila, jelmer, Riddell: Have a good night. I'll see you guys around tomorrow
<vila> jam: _o/
<Riddell> ciao
<Noldorin_> jelmer, i see no such function...which file might you know
<Noldorin_> ?
<Noldorin_> jelmer, never mind i see
<Noldorin_> jelmer, oh interesting...i just noticed the tracelog suggests bzr-git is doing a *pull* when i run dpush :O
<jelmer> Noldorin_: it is, it pulls the changes pushed into git back into your local branch
<Noldorin_> jelmer, that's interesting, didn't know. why does it need to do that?
<jelmer> Noldorin_: as you're aware, dpush changes the source branch
<Noldorin_> indeed
<jelmer> Noldorin_: this is how
<Noldorin_> right
<Noldorin_> it's just *why* it needs to pull back into local branch that i'm wondering :-)
<jelmer> Noldorin_: otherwise you have a diverging source and target branch
<Noldorin_> okay..
<Noldorin_> jelmer, does the pull-back actually affect a) the content of the branch b) the revision data c) some other metadata?
<jelmer> Noldorin_: it discard the existing branch
<Noldorin_> obh
<jelmer> Noldorin_: but you've used dpush, so you should've seen what it does?
<Noldorin_> jelmer, so i lose all bzr metadata in the local branch too?
<jelmer> Noldorin_: yes, unless you use --no-rebase (which prevents that pull)
<jelmer> Noldorin_: if you don't rebase you can't pull from the git repository
<Noldorin_> ahh
<Noldorin_> got it
<Noldorin_> jelmer, well no-rebase is fine for me for now :-)
<Noldorin_> jelmer, eventually when you get proper push support working i can change over...i guess you are gradually working on that
<abentley> Riddell: why are you reviewing bzrtools merges?
<Riddell> abentley: because I'm patch pilot and I've run out of bzr patches to review so I'm doing all bazaar
<Riddell> and these patches have been sitting around for over three weeks, clearly the bzrtools maintainer is slacking :)
<abentley> Riddell: bzrtools isn't a Canonical project, and I'm not asking for the patch pilot's reviews.
<abentley> Riddell: I'm slacking, sure.  But I already know how I feel about those patches.
<mgz> abentley: could you set a state on those kinds of mps so people know not to be helpful?
<abentley> mgz: That wouldn't be slacking.
<mgz> :)
<Noldorin_> jelmer, what's interropostiroy?
<Noldorin_> jelmer, even closer in finding what it is, if you're curious :-)
<Noldorin_> when you try to access non-existent items, the error messags are not very informative btw
<Noldorin_> non-existent files/dirs that is
<Noldorin_> jelmer, okay, so i have identified exactly what the problem is :-)
<jam> Noldorin_: apparently I lied, bzr 2.5b1-1 has been uploaded. :)
<Noldorin_> jam, just saw it, that's excellent. thank you :-)
<Noldorin_> jam, any indications how stable it's proving btw?
<jam> Noldorin_: I don't know about the installer, but I use bzr.dev daily
<Noldorin_> jam, ok that's reassuring
<Noldorin_> jam, i understand it supports collocated branches. but does that mean individual local branches can be pushed to a remote collocated branch?
<Noldorin_> using some special URL syntax
<jam> Noldorin_: you'll need to check with Jelmer, but I think you still need the 'bzr-colo' plugin to enable collocated branches.
<Noldorin_> ah right
<jam> It does have the new syntax  (http://url/to/repo/path,branch=X)
<Noldorin_> jam, awesome. i hope that works with git branches too!
<jam> Noldorin_: i'm pretty sure that was the inspiration. I don't think bzr-git is bundled yet.
<jam> I think Jelmer has a patch, that I'll bring in for the next beta
<jam> so bzr-2.5b2-1 will probably have bzr-git support
<Noldorin_> jam, yeah so i heard. but i have no prob installing it as a plugin for now
<Noldorin_> jam, just pestering jelmer to fix this bug now that i've very narrowly identified it :-)
<Noldorin_> with dpush to git
<Noldorin_> jelmer, ping?
<jelmer> Noldorin_: hi
<Noldorin_> hi jelmer
<Noldorin_> get my updates?
<Noldorin_> jelmer, i left some comments on LP
<mwhudson> jam: no, i wanted to put it under a feature flag and that required a bit of infrastructure (which has now landed)
<jam> mwhudson: yeah, it turned out that the lp:bzr-rewrite just wasn't connected to an actual branch
<mwhudson> jam: :-)
 * Noldorin_ waits for jelmer to return
<jelmer> Noldorin_: your comment doesn't really make sense, bzr-git with dpush doesn't create entries for empty directories one way or another
<jam> mwhudson: we just had a bug with the error reporting. It would say "bzr+ssh://..." no service available
<jelmer> it skips empty directories
<mwhudson> jam: ah
<Noldorin_> jelmer, it does create some sort of sha hash :-P
<jelmer> Noldorin_: for empty directories? it really shouldn't
<Noldorin_> jelmer, if for example you do a 'bzr st' on an empty directory in the git repo that shouldn't have been pushed...
<Noldorin_> then it returns a key for it
<Noldorin_> which it can't find
<Noldorin_> jelmer, it shouldn't but it does ;-)
<Noldorin_> jelmer, it would explain the error, i think..
<Noldorin_> jelmer, well?
<jelmer> Noldorin_: I really don't understand what you mean, the sha for an empty tree (if it were valid) would be 4b825dc642...
<Noldorin_> jelmer, i will test it now with you if you have some time
<Noldorin_> and demonstrate
<cody-somerville> If I do a Branch.open() on something over ssh, how can I close the transport down properly to avoid the disconnection from host (e.g. bazaar.launchpad.net) message? I currently use 'remote_branch.control_transport.disconnect()' but that doesn't seem to work for bzr 2.1.4.
<poolie> hi all
<jelmer> g'morning poolie
<jelmer> Noldorin_: I'm looking at the problematic code now for the first time
<Noldorin_> jelmer, okay :-)
<jelmer> cody-somerville: we haven't really had a need for a way to disconnect transports, I think that's the closest thing
<cody-somerville> jelmer, control_transport isn't a property on Branch in 2.1.4.
<Noldorin_> jelmer, here is what i'm seeing. run the test script (i forgot to replace IrcDotNet with 'baz' in it btw), then do:
<Noldorin_> ./git-branch//foo/
<Noldorin_> err
<Noldorin_> bzr ls ./git-branch/ -r 1
<Noldorin_> you should get back:
<Noldorin_> ./git-branch//foo/
<Noldorin_> jelmer, my tinkering indicates the problem probably lies in either _tree_to_objects or import_git_tree (objectstore.py and fetch.py)
<jelmer> Noldorin_: that's kindof obvious, as those are the functions that actually do the conversion :)
<Noldorin_> jelmer, sorry, of course. but they weren't to me...as i didn't write the code ;-)
<Noldorin_> jelmer, the problem is in the push side, i'm convinced
<Noldorin_> jelmer, e.g. do a dpush --no-rebase (it should succeed), and then run "bzr ls .\git-branch\baz -r 2"
<Noldorin_> should give you an error
<Noldorin_> jelmer, well good luck! :-)
<jelmer> Noldorin_: located the error, rewriting revision_to_objects
<AuroraBorealis> soooo
<AuroraBorealis> what exactly does this error mean:
<Noldorin_> jelmer, that's great. what was it (briefly)?
<AuroraBorealis> https://gist.github.com/e4d86236e79bbc009bd3
<jelmer> AuroraBorealis: when are you getting that?
<AuroraBorealis> well
<jelmer> Noldorin_: order in which directories are processed
<AuroraBorealis> tried to commit a new revision
<AuroraBorealis> and then it was out of date
<Noldorin_> jelmer, hah okay. as we both thoughts some days ago ;-)
<AuroraBorealis> i tried to update and now i got that xD
<jelmer> AuroraBorealis: that's really odd - any plugins used, other special things?
<AuroraBorealis> nope
<AuroraBorealis> could it just be corruption on the server side?
<jelmer> I'd doubt it; can you file a bug?
<AuroraBorealis> yeah, branching it from the server normally works fine
<AuroraBorealis> i shall attempt to file a bug!
<Noldorin_> jelmer, btw jam said 2.5b1 still requires the bzr-colo plugin -- is this correct?
<AuroraBorealis> so...what should be the name of the bug?
<jelmer> AuroraBorealis: thanks
<AuroraBorealis> not exactly sure what is going on here haha
<jelmer> AuroraBorealis: I guess just something like "InconsistentDelta error during 'bzr up'" ?
<AuroraBorealis> i have however archived the repository in case someone wants to look at it
<jelmer> Noldorin_: I'm not sure I follow, requires the bzr-colo plugin for what?
<Noldorin_> jelmer, colocated branches in bzr
<jelmer> Noldorin_: yes, they haven't landed yet
<Noldorin_> okay sure
<jelmer> Noldorin_: I thought you were asking about being able to address git branches though?
<Noldorin_> jelmer, yes, just curious about that too :-)
<jelmer> that's possible with bzr 2.5b1 and bzr-git trunk
<Noldorin_> jelmer, i can address git branches with git-url,branch=foo right?
<Noldorin_> yep
<jelmer> Noldorin_: yes
<Noldorin_> ta
<Noldorin_> jelmer, just let me know when ready and i can test on my case with launchpad/github.
<AuroraBorealis> stupid launchpad didn't report my bug :<
<AuroraBorealis> jelmer: https://bugs.launchpad.net/bzr/+bug/855155
<ubot5> Ubuntu bug 855155 in Bazaar "InconsistentDelta error when using bzr update" [Undecided,New]
<briandealwis> is there an equivalent to git's reflog?  I.e., to find out what was the previous tip?
<jelmer> briandealwis: no, though there is "bzr heads" which can display old heads
<briandealwis> jelmer: the cause himself :)  I was actually askig as I'd like to revert to my last head of bzr-git, since the new one requires dulwich 0.8.1
<briandealwis> I never understood the purpose of the reflog previously
<poolie> lifeless, jelmer, iirc upgrading should (must?) be done on the stacked branch and then the stacked-on branch?
<poolie> or vice versa?
<jelmer> that's a good question, I'm not sure either
<mwhudson> upgrading stacked first will work
<mwhudson> i don't know if upgrading stacked-on first will work, it depends how upgrade opens the thing being upgraded
<mwhudson> of course both approaches leave the stacked branch a bit broken until both are upgraded
<poolie> ah, i think that's it
#bzr 2011-09-21
<lifeless> mwhudson: poolie: order doesn't matter
<lifeless> mwhudson: it was written with the assumption in mind that you can't use a composite repo until the sides are independently upgraded
<poolie> ok
<Noldorin_> jelmer: Sorry, lost Internet... Did you make the fix then?
<Riddell> quiet the day
<vila> Riddell: hehe, split storm
<Riddell> qbzr's NEWS.txt file seems to be in UTF-16, anyone know why?
<vila> WAG: edited on windows ?
<jam1> jelmer: are we still doing the UDD meeting in 10 min?
<jelmer> jam1: I'm not sure to be honest, I haven't heard much about it
<jelmer> let's see if Barry and poolie will be around
<jelmer> jam: I guess not..
<poolie> hello all
<Riddell> good evening poolie
<Noldorin> hi jelmer, poolie
<jelmer> hi poolie, Riddell, Noldorin
<jelmer> maxb: do you know what happened with the ~bzr recipes?
<maxb> I've not looked at them recently
<poolie> i don't
<poolie> hi mgz?
<mgz> hey poolie.
<jelmer> maxb: I'll investigate further.
<Noldorin> jelmer, hi :-)
<Noldorin> jelmer, any updates?
<jelmer> Noldorin: hi
<jelmer> Noldorin: no, I'll update the bug when I have more
<Noldorin> ok cool
<Noldorin> jelmer, at least you know exactly what to rewrite eh?
<Noldorin> jelmer, i noticed you committed a few other fixes already though ;-)
<Noldorin> i will test everything later today i guess, when it's all done
<jelmer> Noldorin: yes, those aren't related to your issue though
<Noldorin> fair enough
<Noldorin> jelmer, okay, i'll just try to wait patiently then :-) thanks
<vila> hmm, interesting, trying to reproduce http://package-import.ubuntu.com/status/musescore.html#2011-09-18%2022:07:55.177188 locally with 2.4.1 fails...
<vila> err, I mean, it seems if 2.4.1 is deployed on jubany that may be enough to fix this import failure
<Noldorin> jelmer, i am trying to push to a branch on github now but no luck...any tips please?
<Noldorin> i try this:
<Noldorin> git://github.com/alexreg/ircdotnet.git,foo-branch
<briandealwis> Noldorin: you have to use ,branch=foo-branch
<briandealwis> Noldorin: and 'git+ssh://git@github.com/XXX,branch=YYY'
<briandealwis> that's what I use at any rate
<Noldorin> hmm
<Noldorin> briandealwis, this suggests otherwise: http://doc.bazaar.canonical.com/developers/colocated-branches.html
<Noldorin> it still says "extra argument to command dpush: branch=foo-branch"
<jelmer> Noldorin: that's a specification, it's not completely implemented yet
<jelmer> Noldorin: see briandealwis' comment on the syntax
<Riddell> yay, I have this unicode import error working locally
<vila> Riddell: you mean failing locally ?
<Riddell> it no longer errors here
<Riddell> character encodings can play with your head
<vila> ha, fixed, even better :)
<vila> hehe, indeed
<Riddell> well I wouldn't say fixed, I need to work on it more tomorrow
<Noldorin> jelmer, ok...but that will eventually be the syntax?
<Noldorin> jelmer, even the suggestion of briandealwis does not work yet unfortunately :-(
<Noldorin> PS C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\dump\dump2\bzr-branch> bzr dpush git://git@github.com/alexreg/ircdotnet.git,branch=foo-branch
<Noldorin> bzr: ERROR: extra argument to command dpush: branch=foo-branch
<vila> Noldorin: git: != git+ssh:
<Noldorin> oops
<Noldorin> vila, didn't notice that even ;-)
<vila> I don't know what I'm talking about to be honest ;)
<Noldorin> vila, still same error though
<briandealwis> Noldorin: what version of bzr-git are you running?
<Noldorin> briandealwis, latest master.
<Noldorin> 0.6.3dev that is
<briandealwis> hmm, I just pushed something a few minutes ago, but I'm not running the very very latest.
<Noldorin> latest dulwich too of course
<Noldorin> bzr 2.5b1
<Noldorin> odd
<Noldorin> still the "extra argument" ERROR
<jelmer> Noldorin: what's the exact command you're running?
<Noldorin> jelmer,
<Noldorin> PS C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\dump\dump2\bzr-branch> bzr dpush git+ssh://git@github.com/alexreg/ircdotnet.git,branch=foo-branch
<Noldorin> bzr: ERROR: extra argument to command dpush: branch=foo-branch
<Noldorin> bbs
<jelmer> Noldorin: is windows perhaps splitting arguments based on comma?
<vila> Riddell: you meant bug #508258 ? Wow !
<ubot5> Launchpad bug 508258 in Ubuntu Distributed Development "Failure to import non-ascii filenames" [Medium,Confirmed] https://launchpad.net/bugs/508258
<vila> Riddell: which package did you use to reproduce and what was the filename ?
<Riddell> vila: liblingua-de-ascii-perl
<Riddell> filename is t/words_with_umlaut_and_Ã.t
<Riddell> but in iso-8859-1 not utf-8
<vila> :-/
<fullermd> 7 bits ought to be enough for anybody.
<vila> Riddell: I wonder about what happens on OSX
<Riddell> vila: why?
<vila> because osx sometimes decides to re-normalize for your own good
<vila> one case I encountered  when looking at this bug was a file in NFKD form that bzr couldn't handle
<vila> which means at some point someone created a tarball or a commit on OSX
<vila> since we use NFKC, we can't grok the path
<vila> the file was some .pdf in a contrib/doc or something so probably few people realized the issue and linux doesn't care since paths are just bytes
<htorque> hello everyone! i'm probably just blind, but how do you change between revisions? like "git checkout HASH".
<beuno> htorque, bzr revert $revno?
<htorque> hm
<htorque> $ bzr revert 1588
<htorque> bzr: ERROR: Path(s) are not versioned: 1588
<beuno> htorque, sorry
<beuno> bzr revert -r $revno
<htorque> beuno: but that's not the same as going back in time - version-info still shows the latest revision.
<beuno> htorque, you want to blow away history?
<htorque> beuno: i'm looking for the commit that caused a regression and therefore like to test a few suspicious revisions.
<fullermd> You probably want update, not revert...
<htorque> fullermd: that's it, thanks! :)
<Noldorin> jelmer, hey, back
<Noldorin> that's possible
<Noldorin> let me check
<Noldorin> jelmer, yes that's the problem :-)
<Noldorin> jelmer, actually still one error when i dpush :-S
<Noldorin> PS C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\dump\dump2\bzr-branch> bzr dpush "git+ssh://git@github.com/alexreg/ircdotnet.git,branch=foo-branch"
<Noldorin> bzr: ERROR: refs/heads/master, .have failed to update
<Noldorin> odd
<Noldorin> disappeared the 2nd time...
<Noldorin> jelmer, hello?
<jelmer> Noldorin: hi
<Noldorin> jelmer, have you encountered that odd error before?
<Noldorin> it is strange
<Noldorin> jelmer, well, goodbye i suppose :-P
<jelmer> Noldorin: ?
<jelmer> Noldorin: I haven't seen that error before. Did the repository update?
<Noldorin> jelmer, it did, but it removed all my tags in master :-S
<jelmer> are you running bzr-git trunk?
<Noldorin> yup
<Noldorin> tags always worked fine for me before :-S
<Noldorin> jelmer, i guess i can wait for you to commit the fix too (tonight?)
<Noldorin> and then test again
<jelmer> this one should be easy..
<Noldorin> okay
<Noldorin> :-)
<Noldorin> jelmer, does that info give you enough to fix it you think?
<jelmer> Noldorin: try again now
<Noldorin> jelmer, sure
<Noldorin> jelmer, pull bzr-git again first?
<Noldorin> i presume
<jelmer> Noldorin: yes
<Noldorin> okay
<Noldorin> jelmer, ooh very nasty error now
<Noldorin> PS C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\dump\dump2\bzr-branch> Unable to write to standard output: The pipe is being closed.
<Noldorin> fatal: The remote end hung up unexpectedly
<jelmer> Noldorin: that doesn't say much, unfortunately?
<Noldorin> jelmer, unfortunately no...it's a new error though
<Noldorin> jelmer, just appeared after i pulled your bzr-git update
<jelmer> Noldorin: does it also occur with the previous revision of bzr-git?
<Noldorin> no
<Noldorin> i'll check again
<Noldorin> but don't think so
<Noldorin> jelmer, nope, just in your latest revision
<Noldorin> since i updated
<jelmer> Noldorin: can you check ~/.bzr.log to see what refs it was going to update ?
<Noldorin> jelmer, sorry, my bad. it happens with previous revisions too now
<Noldorin> strange
<Noldorin> 3.695  updating refs. old refs: {'.have': ('16e7f78f1acde7f85b0366546010968edcf0d3e7', None), 'refs/heads/master': ('8fd19796b7ca400d29b4d8d6783ddd8c03b86448', None), 'refs/heads/foo-branch': ('f66e413bceea0acc287defb17aff3e8d3e94d471', None)}, new refs: {'refs/heads/foo4-branch': (None, 'git-v1:f66e413bceea0acc287defb17aff3e8d3e94d471')}
<Noldorin> NoSuchRef: The ref refs/heads/foo4-branch was not found in the repository at git+ssh://git@github.com/alexreg/ircdotnet.git,branch=foo4-branch.
<Noldorin> jelmer, there you go
<jelmer> ah, bzr-git has trouble with refs that it doesn't know the revision of
<Noldorin> jelmer, easy to fix? :-)
<Noldorin> btw, does bzr-git implement rmbranch?
<jelmer> Noldorin: only for local repositories IIRC
<jelmer> feel free to file a bug about it
<Noldorin> jelmer, got it. i guess i can always use git itself for the time being...
<jelmer> Noldorin: actually, remote removal does work but there's a trivial change necessary in dulwich
<Noldorin> jelmer, just submitted the bug. it still throws NotImplementedException
<Noldorin> NotImplementedError*
<bignose> I'm setting up SD, a distributed bug tracking system
<bignose> it wants to store bug database state in the branch
<Noldorin> jelmer, if you briefly explain, i'd be happy to make the change even :-)
<bignose> am I foolish if I tell it to create a new directory â$(bzr root)/.bzr/branch/sd/â?
<Noldorin> jelmer, but in any case, still more concerned about this new issue and the old 'r47' one heh...
<bignose> is there a convention for storing state for plug-ins that will be replicated as part of the branch metadata?
<spiv> bignose: you can store the metadata as data, i.e. as files versioned in the tree.  e.g. .bzrmeta/my-plugin
<bignose> spiv: is â.bzrmetaâ a special name, or just an example?
#bzr 2011-09-22
<spiv> It's not special, but IIRC it was the proposed convention
<jelmer> Noldorin: lp:bzr-git and lp:dulwich
<Noldorin> jelmer, hmm?
<jelmer> Noldorin: rmbranch support
<Noldorin> jelmer, oh, update both of them eh?
<jelmer> yep
<Noldorin> okay :-)
<Noldorin> jelmer, weird. now i get accessed denied every time i pull
<Noldorin> try to pull dulwich
<Noldorin> bzr: ERROR: [Error 5] Access is denied: 'c:\\users\\alex\\appdata\\local\\temp\\tmp5trcyz.pag'
<jelmer> Noldorin: no idea..
<Noldorin> https://bugs.launchpad.net/bzr/+bug/820805
<Noldorin> known bug
<ubot5> Ubuntu bug 820805 in Bazaar "access denied on Pageant .pag file" [Undecided,Incomplete]
<Noldorin> jelmer, how's work on the other bugs going?
<Noldorin> ERROR: Repository not found.
<Noldorin> bzr: ERROR: The remote server unexpectedly closed the connection.
<Noldorin> jelmer, now i get that error when dpsushing ^
<jelmer> Noldorin: typo in your repository URL?
<Noldorin> sorry it was
<Noldorin> forgot to change : to / this time
<Noldorin> jelmer, thanks, that works now :-)
<Noldorin> jelmer, how close are we to fixing the bug with directory processing order?
<jelmer> Noldorin: Sorry, I've got lots of bugs in progress and this is just one of them (and a harder one at that)
<jelmer> Noldorin: I'll update the bug report
<Noldorin> no prob
<Noldorin> jelmer, i was just under the impression you had already re-written that function yesterday?
<Noldorin> or at least you know
<jelmer> Noldorin: well, I looked at that a bit but that's a nontrivial amount of work.
<Noldorin> jelmer, ok sure. well if you update the bug report, maybe i can try..?
<Noldorin> hrrm, rmbranch still gives:  Unable to write to standard output: The pipe is being closed.
<jelmer> Noldorin: not sure I follow, update it how?
<Noldorin> jelmer, add a comment explaining how it need to be fixed? :-P
<jelmer> Noldorin: it's not as easy to describe as that, I'm going to make some pretty rigorous changes to it. You're welcome to have a stab at it though.
<Noldorin> jelmer, ahh fair enough
<Noldorin> jelmer, well, i have time so, so if you update the bug report then i can try... no promises though ;-)
<Noldorin> jelmer, maybe this 'Unable to write to standard output' issue is simpler though?
<jelmer> Noldorin: basically, I'm hoping to gather the changed blobs first and then update the affected trees.
<jelmer> Noldorin: WHen are you getting that last error?
<Noldorin> jelmer, during rmbranch i said...
<jelmer> Noldorin: no idea about that, it sounds like an issue with ssh
<Noldorin> jelmer, yeah
<Noldorin> jelmer, only happens during rmbranch though
<Noldorin> jelmer, well i get this: NotBranchError: Not a branch: "git+ssh://git@github.com/alexreg/ircdotnet.git,branch=foo1".
<Noldorin> in .bzr.log
<jelmer> Noldorin: that's correct, there is no such branch
<Noldorin> jelmer, oh lol, i already removed it
<Noldorin> jelmer, so actually, rmbranch behaves correctly in all cases now.... it just gives an error *even* when it succeeds
<Noldorin> that being Unable to write to standard output: The pipe is being closed.
<Noldorin> jelmer, .bzr.log contains this: http://pastebin.com/uzeF34tE
<jelmer> Noldorin: that's windows specific I'm afraid
<Noldorin> yeah
<Noldorin> makes sense
<Noldorin> jelmer, do you know the exact cause though...any way around it?
<Noldorin> jelmer, it may me windows-specific, but it's still a ""bug""
<poolie> good morning
<Noldorin> jelmer, i am probably done for today, but if you could fill in the info on the LP bug about directory renames, would be cool :-)
<Noldorin> jelmer, the Windows SSH issue....no idea! should be trivial though
<Noldorin> g'night
<Kamping_Kaiser> is it possible to have bzr ignore a particular sub directory so i can version it independently?
<poolie> yes
<Kamping_Kaiser> in my case /etc/ is maintained by bzr, and i'd like /etc/cfengine/ to be a seperate repo
<poolie> just ignore it, and don't add it
<poolie> that's fine
<Kamping_Kaiser> fab, thanks poolie
<Guest2952> I currently have a shelved change, which I cannot access (bzr unshelve crashes). If I manually fiddle the change out of .bzr/checkout/shelf/shelf-1, do I have to keep anything in mind to avoid corrupting the repository? How do I then get rid of the broken shelf? Just delete .bzr/checkout/shelf/shelf-1?
<poolie> i think that's enough
<poolie> it won't damage the repositoyr
<poolie> please file a bug about the crash, if you haven't already
<vila> hi all !
<poolie> hi there vila
<Guest2952> Thanks poolie. Here is the bug report, for reference: https://bugs.launchpad.net/bzr/+bug/850594
<ubot5> Ubuntu bug 850594 in Bazaar "unshelving new file fails if its directory has been committed since shelving" [Undecided,New]
<poolie> oh, ok, i think i saw that before
<poolie> thanks
<Guest2952> on a related note, what is the recommended workflow to get new files in new directories committed separately from their directories?
<vila> Guest2952: you can't do that, bzr tracks trees, a file is always part of a tree
<Guest2952> so my "bug" isn't really a bug? Just a misunderstanding on my part of how bzr works?
<poolie> well, it should never crash
<poolie> you should never get a traceback whatever you do ,that's always a bug
 * vila nods
<poolie> vila, i think he's asking for the opposite
<poolie> he/she
<poolie> which is to commit the addition of the directory but not the addition of the files within it?
<vila> ooooh
<poolie> given that shelving apparently doesn't handle this
<Guest2952> yes, what poolie said
<vila> 'bzr version' ?
<poolie> i would recommend doing 'bzr rm --keep dir/newfile'
<vila> 2.4.0, sry
<poolie> which will unversion it
<poolie> then commit the directory addition
<Guest2952> Bazaar (bzr) 2.4.1
<Guest2952>   Python interpreter: /usr/bin/python 2.6.5
<Guest2952>   Python standard library: /usr/lib/python2.6
<Guest2952>   Platform: Linux-2.6.32-33-generic-i686-with-Ubuntu-10.04-lucid
<poolie> or use 'bzr add --no-recurse' in the first place
<vila> Guest2952: you're not the first asking for committing new dirs first in one commit and new file later, I don't completely understand the use case, can you elaborate ?
<poolie> we ought to add a 'commit --no-recurse' too
<vila> Guest2952: some background: we try to make directory tracking as transparent as possible so dirs are added when needed (i.e. if you add a file and its directory is not yet tracked, it's added automatically)
<vila> poolie: so we can commit a dir without its content ?
<vila> poolie: so, I did some prodding of the package importer and found some interesting stuff:
<vila> Trying to reproduce some failures with 2.4.1 failed (so deploying 2.4 on jubany is more important than ever)
<Guest2952> For example, my project starts out small, and I only use a single test file for my testing. At some point it grows to the point, where I want to use a more elaborate testing framework, which requires a complex directory setup mapping my test files 1:1 to the tested modules. So I want to commit "setting up the dir structure to support the testing framework" as a separate commit to the actual "implement test foo" commit.
<vila> requeuing with --full fixed several DivergedBranches failures too (but not all, a bit ruining the web page regarding the history of the last failures, no big deal but if you track it you may be surprised)
<vila> Guest2952: right, I just did the same yesterday evening and I committed the new file and its associated test file which triggered committing the dir containing them, but I see your point
<Guest2952> having the directory setup commit separate from the file implementation commit means I can later reject the "implement foo test" without breaking "implement bar test" and "implement quux test"
<vila> Guest2952: waiting for the 'commit --no-recurse' poolie just mentioned, the only workaround I can think of is to commit an *empty* dir (after all, that's what bzr will create if you ask for this revisions to be checked out from scratch)
<vila> Guest2952: ha ! I see even better with that !
<Guest2952> that's what I thought, so I shelved the file, and committed the empty dir, but now bzr won't let me unshelve the file again
<vila> poolie: so, toying with requeue --full, lead to think that we should make sure import_package can always be retried from scratch (I think we're pretty close to that already but if it's guaranteed, it will simplify the way we think about it)
<vila> Guest2952: hmm, can you add that on the bug report ? It's probably a key fact to reproduce the issue
<Guest2952> which part?
<Guest2952> the steps I list in the report reproduce it
 * vila re-reads
<vila> oh yeah, perfect (sorry, I jumped to the backtrace at first read)
<poolie> jelmer, hi?
<vila> poolie: I also noticed some packages are retried more than others (lxc, lillypond among others), I suspect some cruft in JOB_TABLE or something, not sure yet
<vila> it's more obvious when using analyze_log from a tail -F process_log as most imports are processed in lexical order and those aliens pop up in-between
<Guest2952> ok, I'm happy to change/add/clarify/test anything that might help resolve it. For now, I'll just manually extract the shelf, and be more deliberate about my directories in future. Until bzr (at some point possibly) supports my use case, it would be nice, from a user perspective, if bzr would refuse to let me shelve things that I won't later be able to unshelve. It's a big break of trust when your change-manager gobbles up your change :)
<vila> lxc just popped up again
<vila> and apt-daemon and linux-firmware,
<vila> not an issue in itself, this breaks nothing, but the cumulated effect on the time to try all imports is increased for no good reason
<poolie> huh, ok
<poolie> that's interesting
<poolie> i don't know off hand what order it uses
<vila> I thought it was all controlled by mass_import (JOB_TABLE, then packages) but I discovered that categorize_failures trigger some imports
<vila> i.e. each time the web page is refreshed, we requeue some packages, that may be it, I need to check
<vila> and lxc again
<vila> and landscape-client, the pattern is a bit hard to grasp (the timing vary depending on which imports are in flight but that's roughly every 5 minutes)
<vila> hmm, the crontab also runs add_import_jobs but I think this one is for tracking lp)
<vila> It's nice to see people from all over the world trying to hack my desktop, but guys, fail2ban makes your brute-force attempts a bit futile, please find another target ;)
<bignose> vila: sadly, the computers actually attacking are likely not doing so with the knowledge of their owners
<bignose> but rather are under the control of a small number of individuals, who control them en masse to attack indiscriminately
<vila> bignose: Oh, I'm sure about that :)
<vila> similar attacks coming from russia, china, brazil, france and so on, clearly indicates puppets
<jam> morning all
<poolie> hi jam, bignose
<Riddell> morning
<poolie> hi riddell,
<poolie> jam, would you mind doing a quick rereview of https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 ?
<jam> poolie: certainly. It will be a little bit, getting lunch now, then I have to read in the conversation again. But it will be done by your tomorrow
<poolie> thanks very much
<poolie> wallyworld offered to land it but he wants some reassurance
<AfC> What's the git equivalent of `bzr revert`?
<AfC> [I know, I know, don't ask; having just established this project is at all viable I'm going to bzr import it now]
<vila> AfC: 'git  help stash' ?
<vila> AfC: no guarantee
<AfC> vila: found it; `git checkout .` or `git checkout filename` apparently.
<vila> AfC: or git reset ?
<AfC> Turns out `git revert` â `bzr uncommit`
<AfC> !
<vila> ouch
<Riddell> jelmer: when you were asking about translating plugins did you have any one in mind?
<jelmer> Riddell: not specifically. the most interesting plugins for this are the ones that have some public-facing bits, e.g. because they add a command or raise some custom exceptions
<jelmer> Riddell: bzr-rewrite, bzr-svn or bzrtools might be a good candidate if you're looking for an example
<jelmer> Noldorin: hi
<Noldorin> hi jelmer
<jelmer> Noldorin: I've added some comments to the dpush rename bug
<Noldorin> yes i saw just before i went to bed :-)
<jelmer> Noldorin: not sure about the windows rmbranch issue
<Noldorin> jelmer, the error has appeared before in other contexts. some difference with the way plink and openssh work?
<Noldorin> jelmer, where is rmbranch in the code? maybe i can take a look
<jelmer> Noldorin: dulwich/client.py in the dulwich code
<Noldorin> ta
<Noldorin> jelmer, specifically within that file? sorry, i see no mention of removing branches
<jelmer> Noldorin: removing branches is done by updating the refs of the remote repository and excluding the ref you want to remove
<jelmer> Noldorin: this gets called by destroy_branch() in remote.py in bzr-git
<Noldorin> ah ok
<Noldorin> makes sense!
<Noldorin> jelmer, i presume it's using TraditionalGitClient here?
<Wiz_KeeD> hello everyone
<Wiz_KeeD> how's everybody feeling?
<Wiz_KeeD> can anyone give me a hand with configuring bzr?
<jelmer> Wiz_KeeD: hi
<Wiz_KeeD> hello jelmer
<LeoNerd> configuring?
<Wiz_KeeD> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Registering_the_key_with_Launchpad
<Wiz_KeeD> trying to follow this guide so i can download and install aeroolib
<Wiz_KeeD> to build aeroo reports in openerp, i can see the ssh key in the file (don't know if i generated it well_
<jelmer> Wiz_KeeD: you should be able to download branches from launchpad without setting up ssh
<Wiz_KeeD> yeah i did that buuut...
<jelmer> wiz_keed: just through http
<Wiz_KeeD> i don't know how to install aeroolib
<Wiz_KeeD> and if i do
<Wiz_KeeD> ImportError: No module named setuptools
<Wiz_KeeD> that when executing python setup.py install
<Riddell> why does this small change to bzr-rewrite prevent me from running the bzr rebase command?  http://bazaar.launchpad.net/~jr/bzr-rewrite/broken-import/revision/239?start_revid=239
<vila> Riddell: <whistles> a plugin is imported specially under the bzrlib.plugins namespace, I have *no* idea what import __init__ will do there
<vila> Riddell: there may be some info in .bzr.log, otherwise, try adding a pdb.set_trace() before this import
<vila> well, 'import pdb; pdb.set_trace()' that is
<Riddell> ah, using from bzrlib.import.rewrite  works
 * vila nods (fixing the tyop on the fly ;)
<timrc> The context of file system storage, is there a way to "stack" a branch on top of an existing branch? It seems to me like a "stacked" branch in bzr cannot share a file system location with its parent?
<timrc> In the context^
<timrc> I guess I'm expecting something akin to quilt
<Noldorin> jelmer, hey
<Noldorin> jelmer, the .pag issue btw is a problem with Pageant... when you run it in admin mode
<Noldorin> nothing wrong with bzr of course
<jelmer> Noldorin: hi
<jelmer> Noldorin: ah, interesting. any chance you can add a comment to the bug about that?
<Noldorin> jelmer, the old bug submitted by someone else?
<jelmer> Noldorin: yeah
<Noldorin> https://bugs.launchpad.net/bzr/+bug/820805
<Noldorin> i think
<ubot5> Ubuntu bug 820805 in Bazaar "access denied on Pageant .pag file" [Undecided,Confirmed]
<Noldorin> jelmer, sure will do
<Noldorin> done
<Noldorin> jelmer, btw should i be concerned with HttpGitBranch or TraditionalGitBranch in dulwich?
<jelmer> Noldorin: ? I don't think there is anything by those names
<Noldorin> jelmer, sorry, s/Branch/Client
<jelmer> Noldorin: TraditionalGitClient for SSH (you'll see SSHGitClient derives from that)
<Noldorin> ah ok
<Noldorin> didn't notice that, makes sense now!
<Noldorin> jelmer, this "Unable to write to standard output" bug is interesting, since i don't get the message until *after* bzr has terminated it seems
<Noldorin> jelmer, that is, i get the command prompt again first
<Noldorin> it's asynchronous i'm guessing...
<Noldorin> jelmer, the send_pack function in dulwich never returns
<jelmer> Noldorin: it's not asynchronous
<Noldorin> jelmer, well Plink is doing something strange anyway
<Noldorin> jelmer, and the send_pack function definitely throws an error
<Noldorin> specifically, i get:
<Noldorin> bzr: ERROR: exceptions.UnboundLocalError: local variable 'new_refs' referenced before assignment
<Noldorin> err, my bad sorry
<Noldorin> jelmer, basically the dulwich client needs to handle the remote SSH host hanging up unexpectedly...in a more graceful way
<jelmer> Noldorin: the server shouldn't be hanging up unexpectedly
<jelmer> Noldorin: it should confirm the refs have been changed
<Noldorin> jelmer, shouldn't, but is
<Noldorin> hmm
<Noldorin> jelmer, when you try to delete a branch that does not exist it does
<Noldorin> jelmer, by the way, i read your comments. it looks complicated to fix the rename-related bug :-P i might leave it to you
<Noldorin> jelmer, withouy being too pushy...any idea when you might be able to submit that fix? :-)
<jelmer> Noldorin: again, please see the bug report
<Noldorin> jelmer, with regards to? :P don't think it contains any answer to any questions i'e asked
<jelmer> Noldorin: the bug report will automatically be updated as soon as there is a branch that addresses the bug
<jelmer> Noldorin: which questions?
<Noldorin> jelmer, i know... i was just specifically asking for estimates...because i'm a very impatient guy :-P
<jelmer> Noldorin: I have no idea, I work on this in my spare time and that's pretty unpredictable. I could be days or weeks.
<Noldorin> jelmer, ohh i see. sorry, i thought bzr-git was part of your job
<Noldorin> jelmer, only core bzr i guess
<jelmer> Noldorin: well, it's not as black and white as that, but this bug isn't particularly high priority
<Noldorin> jelmer, well, just for me it is ;-)
<Noldorin> very high priority for me
<Noldorin> but in general, fair enough...
<Noldorin> jelmer, okay, as long as these two items are on your task list, i'll just leave them with you
<Noldorin> jelmer, thanks so far...feel free to contact me over the next week, though i'll try not to pester you :-)
<Noldorin> ta
<jelmer> Noldorin: thanks, I'll update the bug reports when I have more
<Noldorin> jelmer, cheers.
<Noldorin> jelmer, if you like i can submit a quick report on the 'Unexpecte pipe close' issue too
<Noldorin> and then leave you to tackle those 2 issues in your own time
<jelmer> Noldorin: Sure, I do want to help out getting this bug fixed
<Noldorin> jelmer, https://bugs.launchpad.net/bzr-git/+bug/856769 -- there you go
<ubot5> Ubuntu bug 856769 in Bazaar Git Plugin "rmbranch on non-existent branch fails with SSH error" [Undecided,New]
<Noldorin> jelmer, two fun bugs to work on :-) good luck, and i look forward to testing the fixes!
<poolie> hi all
<jelmer> hi poolie
#bzr 2011-09-23
<icule> Hi, gang!  I'm in the process of learning / trying Bazaar.  My background is Git, so I'm trying to reformulate my Git habits with Bazaar.  One thing I miss is, having many branches over a shared repository, seeing them all at once (a bit like I do with gitk).  Any hint or idea?
<AuroraBorealis> bazaar explorer can do that
<AuroraBorealis> which is the GUI written in qt4
<icule> I start it at the level of the shared repository?
<AuroraBorealis> are you using it right now?
<icule> Yes.  But I'm pretty new to all this, so you might have to take me by the hand a bit :-).
<AuroraBorealis> so you just go to "open exisiting location"
<AuroraBorealis> and open up the shared repo
<AuroraBorealis> and it should list all the branches that are under it
<icule> (I have to find the equivalent translation for the terms you use.  Maybe I'll restart explorer with the English locale.  A minute! :-))
<icule> Do I open the top-level .bzr?
<AuroraBorealis> http://i.imgur.com/uMX4l.png
<AuroraBorealis> that button
<AuroraBorealis> in bazaar explorer
<AuroraBorealis> no you just open the folder that "is" the repositiory
<AuroraBorealis> (that has the .bzr folder )
<icule> You're quick! :-)
<icule> I then get a list of branches.
<AuroraBorealis> yeah
<AuroraBorealis> there might be a way to do it via the command line too
<icule> But now, I would like the common DAG.
<icule> I mean, the graph from with which I could see all branches.
<icule> All DAGs of all branches combined into a single DAG.
<icule> That would allow me to visually have an idea of how the branches are inter-related, the amount of commonality between them.
<AuroraBorealis> DAG?
<icule> (Directed Acyclic Graph)  I mean, the drawing full of circles (one per commit) and the lines showing the parental relationship between them.
<icule> This is at least shown with "bzr viz" and "bzr qlog".
<AuroraBorealis> http://i.imgur.com/3jZfM.png
<AuroraBorealis> you mean that?
<icule> Yes, exactly.  Currently, I can only see one branch at a time.
<AuroraBorealis> well i think you only see stuff related to that branch
<AuroraBorealis> like in the screenshot
<AuroraBorealis> thats just one branch (the main one)
<AuroraBorealis> but you can see other branches were split off and were eventually merged back into it
<icule> I would like to see all branches at once, and where various branches fit in that dag.  Like with gitk.
<icule> (if you know it)
<AuroraBorealis> so it only shows the other branches if it got merged back into
<AuroraBorealis> the branch you are looking at
<AuroraBorealis> but i dont think there is something like what you are talking about, which i think is the github like view
<AuroraBorealis> which is a shame cause it would be awesome to have :<
<icule> Hmph!  I thought about merging branches randomly before examining them, but that's not negligible overhead, both human and machine.
<AuroraBorealis> but yeah, unlike github (and i guess whatever else) it doesn't show the other branches if they haven't been merged back
<icule> If I have many branches, and do not know how they relate to one another, there would be a lot of exploratory work and comparison to get the overall picture.  So I wondered if there is any (easy) tool for that.
<AuroraBorealis> https://github.com/a-musing-moose/morph/network
<AuroraBorealis> is that what you mean?
<AuroraBorealis> what you want at least
<icule> Because one needs the overall picture *before* merging.
<AuroraBorealis> but is that what you are wanting ^ like the github network grapbhs
<icule> Yes, that GitHub graph shows it in some way, yet the graphics is not as clever as gitk, and the tips are a bit randomly selected (GitHub explains somewhere its algorithm).
<AuroraBorealis> i dont think there is a tool that does that currently
<icule> bzr viz does it nicely (more nicely than GitHub in my opinion), but a single branch at a time.
<AuroraBorealis> but it would be really nice to have one. is there an paper on how they do that? cause it would be an interesting feature to work
<AuroraBorealis> in
<AuroraBorealis> on*
<icule> OK.  I just wanted to ask here.
<fullermd> qlog can show multiple branches at once...
<AuroraBorealis> can it?
<icule> I studied Git a bit deeply, years ago, it is quite simple internally.  I do not know the internals of bzr structure.  Do you know if there is a document about it?
<AuroraBorealis> i have no idea, but i probably should ask since i'm messing around in the code haha
<icule> Git is simple enough that I understand how it is possible to merge all branches in a single place.  Bazaar, I do not know.
<icule> I'm slower than you.  Let my try qlog.
<icule> Oh, before going further, "bzr explorer" does not show graphs, does it?
<AuroraBorealis> graphs?
<icule> The circles and lines, like you showed me in one of your (blazing fast) screenshots.
<icule> Hey hey!  "bzr qlog" does it, if I start it above branches!  :-) :-)
<AuroraBorealis> yeah
<AuroraBorealis> bazaar explorer has a "log" button
<AuroraBorealis> and that starts qlog
<icule> Oh, thanks for this bit of info!  Nice.
<AuroraBorealis> and oh crap it does. nice work whoever makes bazaar explorer hehe
<icule> Another question, which may look like a criticism, but I do not mean it that way.
<fullermd> A lot of what Explorer does is just launch other q-commands.
<AuroraBorealis> and yeah, it works with multiple branches. i think this is what you want: http://i.imgur.com/8vgwm.png
<icule> I compared "bzr viz" and "bzr qlog" a bit.  Both are slow, but in a different way.  "viz" preconditions its work, and is reasonable afterwards.  "qlog" starts faster, but crawls more and more if I keep opening branch expansions.  I guess it abuses the graphical toolkit.  (Maybe both do).   Is there any trick to know to regain more speed, with either of them?
<AuroraBorealis> probably not. its probably just the code being a bit rough i guess
<AuroraBorealis> dunno about 'viz' but qlog uses qt4, which is in c++ so qt4 isn't slow
<icule> Exactly what I want.  It allows me to get an overall idea of the interrelation between branches.
<icule> Well, if *all* tens of thousands of commits are drawn all at once, even a C++ program would crawl.  Normally, the drawing shold open lazily around the visible part of it.
<fullermd> viz is gtk
<icule> gtk, qt4, are likely both C or C++.  Oh, you mean, with a Python wrapper or not?
 * fullermd doesn't know that he'd classify qt4 as 'not slow'   :p
<AuroraBorealis> bzr viz opened up in like a few seconds and drew the graph in 5 seconds
<AuroraBorealis> which is pretty good considering the number of revisions...
<icule> For small graphs, it likely does not matter.  The repositories I'm playing with have many tens of thousands commits.
<icule> I guess there is not much to do, but I do not know that much about Bazaar, so I thought that I might ignore some tricks :-).
<AuroraBorealis> the bazaar trunk branch has 37,890 revisions soo
<icule> AuroraBorealis: Amusing nick! :-)
<AuroraBorealis> so i feel thats a fair number =P
<AuroraBorealis> amusing D:
<AuroraBorealis> and bzr viz is kinda crappy, you can't resize the columns so they dissapear to where you can't see them...
<icule> You say, 5 seconds for 30000 commits?   Nice indeed.  I got the impression that qlog quickly gets slow (hmph, pun not intended) if I keep expanding merges.
<icule> Thanks a lot for helping me on these things, and not bashing me over my newbeeness!
<AuroraBorealis> hehe
<AuroraBorealis> i mean im playing with the qlog graph
<AuroraBorealis> and i see that some expansions are slow but its not unusable
<AuroraBorealis> i mean, if it takes half a second to expand then...thats fine xD
<icule> I should confess I've been rotten by Git, which is instantaneous in most circumstances.
<AuroraBorealis> lol
<icule> But then, after the expansion (which is fast) the scrolling crawls.
<AuroraBorealis> i mean every program can always be faster
<AuroraBorealis> its usable for me, but then again i have a pretty good video card so i dunno =P
<icule> The machine I use, while not being so slow, has a few years already.  It could also be part of the problem.
<icule> So far, Bazaar has been reasonably fast.  I was expecting worse (because of what I read).  One thing which surprised me is that Bazaar repository compression is as good as Git.
<AuroraBorealis> yay!
<icule> How does garbage collection go in Bazaar?
<AuroraBorealis> garbage collection?
<icule> Suppose I have a share repositoy, and in one branch, I "bzr add" many movies :-).  Then I scrap the branch.  How does the space taken by the movies, in the respository, gets reclaimed?
<AuroraBorealis> i am not sure.
<Kamping_Kaiser> icule: are you suggesting they should be removed from the history?
<AuroraBorealis> someone more knowledgeable then me will have to ask hehe
<AuroraBorealis> well if he just deleted the branch
<AuroraBorealis> is what i think he means
<icule> Kamping_Kaiser: Should it not?
<icule> In my understanding, if there is no branch, and no tag, reaching a set of commits, there is no need to retain the space they describe.
<Kamping_Kaiser> i've not worked with shared repositories, so don't know how they behave
<icule> Kamping_Kaiser: You never work on more than one branch at a time?
<icule> Is there a formal bzr command to get rid of a branch?
<Kamping_Kaiser> correct. on the rare occasion i have multiple branches i simply branch again
<icule> I tried this exactly, a few hours ago, and the repository seems to be automatically shared.
<icule> (Given you used init-repo to start with.  This is the natural thing to do if you intend to branch many times, so I think.)
<AuroraBorealis> here seems to be
<AuroraBorealis> http://doc.bazaar.canonical.com/bzr.2.4/en/user-reference/remove-branch-help.html
<AuroraBorealis> remove-branch
<icule> AuroraBorealis: Thanks!  You're the king of the screenshot, my friend! :-)
<icule> I should learn to imitate you.  Should get a bit more speedy on the mouse, I guess :-).
<Kamping_Kaiser> hm, remove-branch. guess i have used shared repos then, in some sense (the sense that i removed a lot :p)
<AuroraBorealis> well thats the actual documentation page hehe
<AuroraBorealis> brb~
<icule> I tried "bzr branch" on unrelated places.  There is first the stream of commits, and in a second phase, the building of the file tree.  If I "bzr branch" in a neighbouring directory in the same "init-repo", the stream of commits is nearly instantaneous, it immediately switches to the tree extraction.
<icule> brb~ ??
<icule> May I ask another question.  If you reply, you encourage me to ask more.  That's your fault!
<Kamping_Kaiser> just ask, if he/she/it can reply (or someone else can reply), they will
<icule> Suppose we have a "master" repository and we branch out of it.  When we merge back, the version numbers get a bit more complicated, and this is later reflected in other branchers.  Now, let's presume we *loose* the master repository.  We restore it from one of the copies.  Is there a way to "renumber" or "simplify" the version numbers then?  Or do they get forever dirty?
<icule> (OK, dirty is a bit strong.  Let me say "compound without reason".)
<fullermd> Numbers are dependent on the head.  If the head is the same, the numbers are the same.
<icule> fullermd: Maybe my fear is unjustified.  I'll have to experiment more to get a more firm idea.  It's more intuition than knowledge right now.
<fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering
<icule> fullermd: Thanks for the link.  I read a lot of pages today, but I do not remember having seen this one.
<icule> OK, thanks again everybody.  It was a pleasure to meet you.  Have a good end of day!
<fullermd> The other stuff under http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs may also be useful to you.  In particular, PiecesInBrief talks about terminological usage, which differs somewhat among different VCSen.
<chrissbx> When using "bzr git-apply ../00*", all patches that have multiple lines in the message, when afterwards shown in bzr log, end up missing two newlines between the first (subject) line and the rest (body).
<chrissbx> I'm on Debian stable, bzr 2.1.2. Has this been fixed, or is my interpretation wrong?
<chrissbx> Ah well, and it doesn't apply the changes at all.
<AuroraBorealis> ive never used git-apply o.o
<chrissbx> So, this alternative actually almost worked: bzr fast-export-from-git foogit/.git exportfile && mkdir foobzr && cd foobzr && bzr init && bzr fast-import ../exportfile
<AuroraBorealis> what are you trying to do
<chrissbx> The only thing is it uses the git committer time for patch times, and looses the git author times.
<chrissbx> I've previously converted a bzr repo to git, worked on it, now trying to bring my work back into bzr.
<AuroraBorealis> i dont think you are meant to use fast import/export repeatedly :3
<chrissbx> well, the bzr history has been kept identical.
<chrissbx> Only thing that bothers me a bit is that my author times are lost.
<AuroraBorealis> might be a bug with the git things
<AuroraBorealis> i dont use git with bazaar so i cant say
<fullermd> I'm pretty sure bzr doesn't have multiple timestamps...
<chrissbx> I'd like to have a flag to tell it "use my author times, not committer timestamps as bzr timestamps"
<chrissbx> Are bzr timestamps changing if you rebase or cherry-pick (well that's git terminology..) patches?
<AuroraBorealis> i thought bzr really isn't meant for..cherry picking
<fullermd> They're set when a revision is created, and fixed afterward.
<fullermd> Whether rebase copies over the timestamps to the new revs, I dunno.  For rebase-ish operations, I think I'd guess no...
<fullermd> But that's implementation detail, not fixed.
<chrissbx> Can you create a patch file with everything and apply it afterwards? (like git format-patch  and git am)
<chrissbx> with everything in a commit
<fullermd> That sounds like the territory of merge proposals and bundles.
<GungaDin> Is there a way to specify excluded files/paths without specifying -x infront of each of them?
<AuroraBorealis> put them in .bzrignore?
<GungaDin> nah.. can't you just specify them with one -x???
<GungaDin> comma separated?
<GungaDin> something?
<AuroraBorealis> im not sure
<AuroraBorealis> never used that before
<fullermd> And .bzrignore is unrelated to [ci] -x.
<vila> hi all !
<vila> poolie: ping ?
<poolie> hi vila
<vila> \o/
<vila> I'd like to discuss about library_state
<vila> the scope is unclear to me at the moment as is the intended use,
<vila> do we intend to support threads ? Recursive calls ?
<vila> Which kind of global do we expect to add ? (Apart from the comment saying none should be added)
<vila> "Accessing the current BzrLibraryState  through this variable is not encouraged: it is better to pass it around as part of the context" puzzles me,
<poolie> oh hi
<poolie> sure i'd be happy to discuss that
<vila> passing the state around ? Do we want to add such a parameter everywhere (almost) ? Rely only on a few strategic objects to propagate it (branch, repo, wt) ?
<poolie> the simple end of it is: there is a bunch of global state
<poolie> for instance, the ui factory, hooks, etc
<poolie> this needs to be initialized when a program using bzrlib starts
<poolie> (and possibly closed off)
<poolie> also, it is typically reset when running tests
<poolie> at the moment, this is done ad-hoc for different types of state
<vila> encodings and i18n also comes to mind
<vila> right, so you describe indeed a simpler scenario: initialize the state once
<vila> but nothing about threads or possibly calling bzrlib with a new state while preserving the current one
<poolie> right
<poolie> perhaps eventually you'd want to have multiple threads each with separate state
<poolie> that would be perhaps a clean way to allow multiple completely independent threads more safely
<poolie> (each running a ui, for instance)
<poolie> but that's not really on my radar at the moment
<poolie> yes, i18n and encoding are good examples
<poolie> similarly i don't see much urgency to do recursion except for the particular case of testing
<poolie> now as far as propagating it
<poolie> to start with, having just one global (the state) that points to every other bit of global state is in itself an advance
<poolie> at least it's easy to switch just that and know you've reset it
<poolie> obviously that wouldn't scale to threading, but as i said that's not urgent
<poolie> so
<poolie> by 'pass it around'
<poolie> you wouldn't want to pass it to every function
<poolie> we might manage to put it into eg the bzrdir, then pass that down in to objects opened off there
<poolie> this tends to run in to trouble when we pass through a non-method function
<vila> yeah, that's what I meant with "strategic" objects but it's blurry at best
<vila> yeah
<poolie> anyhow
<vila> ok, so, that means the "various bits of global state that are slowly being eliminated" really means the aim is to centralize first and may be, in the long term, eliminate it, but nothing I can nor should worry about right ?
<poolie> right
<vila> haaaa
<poolie> so, your specific thing is reading configs just once ,right?
<vila> hmm, not a haaa of surprise but of relief :)
<vila> nope
<vila> not yet
<vila> the specific bit is about bug #491196
<ubot5> Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [High,In progress] https://launchpad.net/bugs/491196
<vila> and how this should be shared with all stacks
<vila> so not the config files yet but kind of the same issue
<vila> there is only one instance of some dict holding the overridden options and it should be used by all stacks
<vila> short path: a new global
<vila> preferred (?) path: use library_state, but AFAICS it's not even supported by the test suite today
<vila> chicken-and-egg
<poolie> oh ok
<poolie> i'd so much love to see that added
<vila> should we start by filing a bug asking for library_state to be used by the test suite ? (Note that we can now debug code where stdin/stdout are redirected which should help a lot !)
<poolie> so i do think that belongs in the library state
<poolie> perhaps not exactly a specific concept of 'command line options' (though that would be ok)
<vila> overrides ! not options
<poolie> but rather 'low priority config stacks' and 'overriding config stacks' or something
<vila> yup
<poolie> so
<vila> but you realize that using a specific state for tests is a recursive use case (simpler than a general case but recursive nevertheless)
<poolie> yes i do
<vila> good
<poolie> <poolie>  similarly i don't see much urgency to do recursion except for the particular case of testing
<poolie> :)
<vila> oh, sorry :D
<poolie> np :)
<poolie> so, i think it would not be much harder to put it in the library state than in a global
 * vila nods
<poolie> even-if the test integration doesn't promise to save and restore the whole state, and it only does the specific config stuff
<poolie> but, perhaps it will turn out that just an overrideAttr on the library state is enough to make it work
<vila> hehe, right I always miss those shortcuts :)
<vila> hmm, I'd feel better with a bug about library_state so we can focus on some minimal stuff there without mixing that with other aspects, I'll do that unless you object
<poolie> what would that bug say?
<vila> library_state cannot be used
<poolie> :/
<poolie> yes it can :)
<poolie> actually
<vila> by the test suite mainly, but even by code as the recommended usages are unclear
<poolie> i think we can get there one step at a time by adding new stuff to it, or migrating
<poolie> and since we're adding something new
<poolie> i think it will be no harder than adding a global, and it may make stuff easier
<poolie> so i'd like you to try it
<poolie> if it turns out to cause byzantine failures, let me know
 * vila scratches head
<vila> oh, you mean I should overrideAttr for tests... but only for the part I care about ?
<poolie> well, i think that would still be incrementally better
<poolie> than just having a global
<vila> ok, I think I see :)
<vila> thanks for the teddy bear'ing
 * vila switches to make tea, lp rollout planned at 0830 UTC
 * fullermd wonders what vila is adding to the tea to cope with that   :p
<vila> caffeine
<vila> and other substances I'm not allowed to speak about publicly
<vila> no, I didn't even write that
<poolie> stinky cheese :)
<poolie> bit early for that though
<vila> my daughter was doing that when she was young ;)
<vila> Roquefort was her favorite...
<poolie> vila, i'm going to go out in a bit
<poolie> hi jam
<vila> poolie: it's ok, I have enough feedback
<poolie> oh, did you understand my terse comment about lazr.restful?
<poolie> i fixed a bug in it to do with indexerror
<poolie> we would need to either release and deploy it, or run from a checkout
<poolie> i could look into it next week
<vila> oh yes, I knew about that, what I don't know is how and when it will be deployed though
<poolie> it will probably help the existing backoff stuff work quite a lot better
<poolie> me either :)
 * vila nods
<poolie> but those are the main choices
<poolie> 1- run from a checkout
<poolie> 2- make a release, build it, backport it, cat-rebuild it, get that installed
<vila> I commented about that: 'make tea' is a catch-all, it doesn't mean we shouldn't fix every case where we can
<jam> morning poolie
<vila> poolie: I prefer 2 despite 1 giving better control
<jam> hi vila
<vila> jam: _o/
<vila> poolie: the aim should still be to be able to control the imports without ssh access, so the less specific bits we maintain ourselves, the better
<vila> poolie: and I deal with my own contradictions on the topic ;)
<poolie> vila, ok so then the next step is for someone to make a tarball release
<poolie> either you or i, or we moan at someone from #launchpad to do it
<poolie> since this is only the first step of a bunch of changes perhaps it's easier to just do it
<poolie> that package has so much weird stuff for its size i don't anticipate the release being trivial but perhaps it will be
<vila> poolie: please do :)
<vila> http://egbg.home.xs4all.nl/counterscript.html ftw ! Just got a telemarketer hang up *during* the 2nd question !
<vila> make tea experiment failed (due a minor bug, I have a fix): the circuit_breaker failed to access the db
<vila> ~100 failures will be retried shortly
<vila> the first failure was unknown: bzrlib.errors.UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'xmlrpclib.Fault', '<Fault -1: \'Unexpected Zope exception: DisconnectionError: could not connect to server: Connection refused\\n\\tIs the server running on host "lp-prod-pgbouncer.canonical.com" and accepting\\n\\tTCP/IP connections on port 5433?\\n\'>')
<vila> I've added it to the known transient ones
<vila> two more imports failed with the same error
<vila> the following ones were lazr.restfulclient.errors.HTTPError: HTTP Error 500: Internal Server Error so covered by the next lazr deployment (poolie you confirm?)
<vila> ha, poolie is gone, nm
<vila> I'll monitor again during next rollout currently planned next Tuesday 0830 UTC
<vila> all transient failures has now been re-processed, so we recovered in one hour only, with some manual prodding, still better than the several hours previously needed (less failures though)
<vila> testing my fix right now (found a way to trigger the faulty code path without shutting down launchpad ;)
<vila> test successful, ready for next rollout
<briandealwis> is there any way to tell if a plugin is being run from the smart server rather than the bzr client?
<jelmer> briandealwis: how do you mean?
<jam> jelmer, briandealwis: I think he means something like bzr-email. Is there a way to tell that the server-side hook is running and causing the email to be sent, rather than the client.
<jam> I don't know of any sort of generic way.
<jam> You could always disable the client plugin with "BZR_DISABLE_PLUGINS=pluginname"
<briandealwis> jam: I actually have a plugin (just polishing and will then announce) and wanted to alter the plugin's behaviour if it's running within the server
<jam> briandealwis: so you mean can you tell from-within-the-server
<jam> you could tell based on the URL you are working on
<jam> whether it is a local or remote one.
<briandealwis> though it would be local if bzr client was working on local branch too, right?
<jam> briandealwis: yes
<jam> though I wouldn't be surprised if you wanted that
<jam> depending on what you are doing, you could just check hostname
<jam> "socket.gethostname()"
<jam> I don't know how specific this is to your system.
<briandealwis> jam: I'm polishing up a "reflog" plugin for bzr.  I want to record the action that changed the tip though (e.g., pull, commit, uncommit), but that info isn't available from the post_change_branch_tip hook.  So I'm currently hooking the other branch hooks, but those aren't sent on the smart server.
<briandealwis> Maybe I should just change the bzr source to provide a reason the ChangeBranchTipParams
<jam> briandealwis: That would make more sense, though the layering might make it a bit tricky. As noted, though, it does sound like you want that to run for clients as well as on the server.
<jam> Since probably 90% of the time the server side is "pushed" :)
<briandealwis> exactly
<briandealwis> a separate question: how do I specify an encoding when requesting or writing a file through a transport?
<briandealwis> nm, I didn't realize I needed to encode and decode lines explicitly
<jam> briandealwis: yeah, content is binary
<jam> get_bytes/put_bytes
<briandealwis> thanks
<jelmer> jam: hi
<jam> hey
<jelmer> jam: thanks for that review. In general, I was going for minimal impact with that foreign-branch-tests-pt-6 branch.
<jelmer> jam: You're probably right that we should do some refactoring
<jelmer> jam: I think a .is_initializable() would make sense; do you know if there's any particular reason assertInitializeEx doesn't just raise TestNotApplicable itself?
<jam> jelmer: assertInitialize ?
<jam> jelmer: found it
<jam> I think it should just raise TestNotApplicable
<jam> it would clean up a lot of other code, too
<jam> I'm guessing it was before we had NotApplicable
<jam> where there was a debate between SKIP being used for a test that is missing a dependency
<jam> (a test you could make pass somehow)
<jam> and NotApplicable meaning never-will-happen
<jelmer> jam: ah, fair enough
<jam> vs just passing the test because it wasn't something you could fix
<jam> ever
<jam> jelmer: if you look at the code, all the code paths have "if control is None: return"
<jam> and you can get rid of all that boilerplate by raising the exception.
<jelmer> jam: Well, that's what I thought. But I also figured whoever wrote it probably was doing that for a good reason :)
<jelmer> I think I forgot there was a time when we didn't have TestNotApplicable
<jam> jelmer: yeah, that was quite a while ago :)
<jelmer> jam: Thanks, I'll have a look at raising TestNotApplicable and introducing .is_initializable()
<jam> jelmer: of course, all of those lines were recently copied by you, so it is a bit hard to see how old they are :)
<LeoNerd> I'm honestly surprised nobody's registered  bzrhub.com  yet
 * vila runs
 * jelmer counts further down.. 28 failures left :)
<vila> jelmer: \o/
<exarkun> yo what's up, http://codepad.org/bU40nmSJ
<jelmer> hi exarkun
<jelmer> exarkun: you need a newer version of bzr-fastimport that matches your bzr
<exarkun> How do I know what version of bzr goes with what version of bzr-fastimport?
<jelmer> exarkun: generally speaking, newer versions of bzr-fastimport will work with bzr >= 2.0
<jelmer> r313 of lp:bzr-fastimport fixes this particular issue
<exarkun> Thanks, I think that worked
<exarkun> I think I did my fast-import-filter wrong though
<exarkun> How do I remove one directory from history?
<exarkun> I have /master/ and /support-master/ and I want to get rid of /support-master/
<exarkun> I tried -i master/ but that dumps all of master/ into /
<jelmer> exarkun: perhaps -x ?
<jelmer> though I should note I don't have much experience using fast-import-filter
<exarkun> oh right, I should have re-read the docs after upgrading.
<exarkun> yea, -x works just right.  thanks.
#bzr 2011-09-24
<Nitz> Why are version control software so unintuitive?
<Phantomas> does bzr as a project use a shared repository with repository branches or just standalone branches?
<Phantomas> what should I use for my project?
<jelmer> Phantomas: it's a thing you can decide on a personal basis, there doesn't have to be a project policy on it
<jelmer> Phantomas: as a bzr developer, I use shared repositories locally, but bzr itself uses a standalone repository (living at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev, along with the branch)
<Phantomas> jelmer: oh, it doesn't make any change if I upload it to launchpad?
<jelmer> Phantomas: yep, it doesn't make a difference.
<Phantomas> jelmer: ok so to be sure, if I do  bzr init-repo project  and then  bzr init project/trunk  and push it to launchpad it would be the same with bzr init trunk  and push
<jelmer> Phantomas: yep
<Phantomas> cool :D
<Phantomas> jelmer: something else: I read everything about the "Lockstep Development", and understood that it uses checkouts, but has this anything to do with the initialization of the branch?
<Phantomas> I mean do I need a different process from bzr init-repo ... bzr init ... ?
<Phantomas> jelmer: documentation doesn't mention such a thing... but then how could you be sure that developers use checkouts and the "Lockstep Development" instead of just a normal branch clone?
<Phantomas> or this is also a personal choice?
<jelmer> Phantomas: checkouts are also just a personal choice, it means all commits you do locally automatically go upstream
<Phantomas> Perfect... jelmer thanks a lot... you have been very helpful :)
#bzr 2011-09-25
<lifeless> jelmer: why did you marjk lp:~jelmer/testrepository/fix-uxsuccess rejected?
<AuroraBorealis> hmmm
<AuroraBorealis> anyone know what this error means? :<
<AuroraBorealis> bzr: ERROR: Failed to rename C:/Users/Mark/Code/bzr/mips/csc252/trunk/prog2 to C:/Users/Mark/Code/bzr/mips/csc252/trunk/.bzr/checkout/limbo/new-5/prog2: [Error 5] Access is denied
<jelmer> lifeless: I got a disapprove vote and I'm not going to look into it further at this point.
<Noldorin_> hi jelmer
<jelmer> hi Noldorin_
<Noldorin_> how's it going?
<jelmer> alright, how are you?
<lifeless> jelmer: I thought it was just needs-tests
<lifeless> jelmer: jml said he was going to look at landing it himself
<jelmer> lifeless: yes, but with tests - my fix was trivial
<jelmer> lifeless: anyway, I was mainly just trying to clean up my list of in-progress branches
<jelmer> lifeless: I agree it wasn't really rejected as such, but there isn't really a way to stop being involved in a MP otherwise
<lifeless> rejection doesn't stop involvement either :)
<jelmer> lifeless: ok, you got me there. but it at least means it no longer shows up in my wip and needsreview listings
<lifeless> sure. I can understad the motivation
<lamont> bzr: ERROR: exceptions.AssertionError: get_next() called when there are no chars left
<lamont> sigh
<lamont> that's in 2.2.4-0ubuntu1
<jelmer> lamont: hi
<jelmer> lamont: that's usually a sign of a corrupt dirstate because of a truncated file - unsafe unmount?
<jelmer> lamont: FWIW, newer versions of bzr fdatasync more agressively
<lamont> jelmer: machine panic
<lamont> so yeah, that could be consistent with an unsafe umount
<lamont> OTOH, it should be ext3
<jelmer> lamont: removing the checkout and creating it again should fix, but will discard any pending metadata changes you had in bzr
<jelmer> "rm -rf .bzr/checkout; bzr co"
<lamont> something tells me that a bzr co might tend to modify files in the working directory
<spiv> lamont: IIRC it's not impossible for the "write tmp file, rename tmp to final location" idiom to leave 0-byte files after a crash with ext3, because by default it allows metadata to be committed before data.
<lamont> spiv: and whether or not that is a grave bug in ext3 has been debated before
<spiv> The O_PONIES feature request :)
<jelmer> hey spiv :)
<spiv> o/
<lifeless> spiv: thats ext4 I believe
<lifeless> spiv: ext3 cna't selectively sync journal contents
<spiv> lifeless: IIRC it's possible (but less probable) under ext3 too
<lifeless> spiv: you need journal_data_writeback for that
<lifeless> spiv: IIRC which is not on ext3 by default (it defaults (or defaulted?) to journal_data_order
<lifeless> spiv: IMBW - I haven't checked the code since ages ;)
<spiv> lifeless: http://lwn.net/Articles/351422/ says the defautl mode under ext3 switched from data=ordered to data=writeback around 2.6.30
<spiv> Possibly that change got reverted later due to this sort of fallout?
<lifeless> ah! heh
<spiv> But anyway that's enough for me to stop short of being certain that "default ext3" == "necessarily safe for that idiom"
<lifeless> so if they changed that, then yes, its unsafe
<lifeless> and sigh, still no user space barriers
<lifeless> to we have to choose between slow and crap
<lifeless> or use btrfs!
<poolie> hi lamont, spiv, jelmer, lifeless
<lamont> howdy
<poolie> there is a repair-dirstate operation
<poolie> 'bzr repair-workingtree'
<lifeless> morning poolie
<Peng> /1/1
<Peng> >.>
<poolie> lamont, i think that's https://bugs.launchpad.net/bzr/+bug/709158 btw
<ubot5> Ubuntu bug 709158 in Bazaar "bzrlib._dirstate_helpers_pyx.Reader.get_next: AssertionError: get_next() called when there are no chars left" [High,Confirmed]
<poolie> thanks for pointing it out
<lamont> ah, cool
<jelmer> g'morning poolie
<wgrant> Morning.
<wgrant> wgrant@lucid-test-lp:~/launchpad/lp-branches/separate-zopeless-mail$ bzr pull :push
<wgrant> bzr: ERROR: Unsupported protocol for url "lp:~wgrant/launchpad/separate-zopeless-mail"
<wgrant> Is that meant to not work?
<wgrant> I believe the push URL is set in locations.conf.
<jelmer> wgrant: it's a known issue; bzr itself always sets expanded URLs (not requiring directory services) in configuration files
<wgrant> jelmer: Hmm, but bzr push works fine.
<jelmer> wgrant: does "bzr push :push" work?
<wgrant> Indeed not. Good point.
<wgrant> At least there is a workaround, then. Thanks!
<jelmer> wgrant: anytime
#bzr 2012-09-17
<mgz> morning!
<jelmer> moin
<mgz> jelmer: shall we pre-thingy mumble even if jam isn't back in time?
<jelmer> mgz: sure
<jelmer> mgz: ?
<mgz> jelmer: hopping on
<quotemstr> There's no interactive rebase for bazaar, is there?
<jelmer> quotemstr: no interactive rebase, no
<jelmer> mgz: still there?
<mgz> jelmer: yup
<delinquentme> OK so if i've got the primary repo with --no-trees
<delinquentme> and a branch of the primary repo
<delinquentme> then I copy the files from that branch ... back into the primary repo
<delinquentme> will anything within the /.bzr dir have changed in the primary repo?
<mgz> what do you mean by "copy"?
<delinquentme> mgz, like a shell command of $ cp the_branched_dir /trunk
<mgz> right, so genenerally you don't want to do that with branches under shared repositories, use branch to move stuff from one to another
<mgz> `bzr branch`, that is.
<mgz> cp then `bzr reconfigure` is safe in a limited set of circumstances, and you risk breaking things with it if you get it wrong.
<delinquentme> mgz, so basically in the situation above ...
<delinquentme> can I just delete all the files which I CPed in
<delinquentme> and leave the .bzr dir and it will be peachy =]?
<mgz> delinquentme: yup
<mgz> provided you mean also removing the branch/.bzr but leaving .bzr for the repo
<mgz> then doing `bzr branch` to copy the old branch under the new repo
<SamB_MacG5> huh, the test directory isolation code doesn't normalize URLs ...
<SamB_MacG5> so, say, TMPDIR=/var/folders/4b/4b+Qm+OQFj8f23emq17tBU+++TM/-Tmp-/ can cause problems, though perhaps not in bzr's own tests
<SamB_MacG5> (Thankfully, the fact that /var actually a symlink to private/var seems not to be a problem.)
<SamB_MacG5> ... is there some secret development channel that nobody told me about, or has bzr, like, died or something?
<jelmer> no, there is no cabal ;)
<jelmer> see the recent lwn article
<SamB_MacG5> hmm, that could be an issue if I want to build a Haskell package in the future...
<jelmer> SamB_MacG5: hehe
<SamB_MacG5> ookay, why does google think "lwn" is a synonym for "vs" ?
<jelmer> heh, no idea
<SamB_MacG5> you mean https://lwn.net/Articles/515652/, which is evidently paywalled for the next 3 days?
<jelmer> ah, yes
<jelmer> sorry
<jelmer> it is based on a public thread on the mailing list though
<SamB_MacG5> how did the thread get so fragmented ....
 * jelmer v
 * jelmer blames certain individu als
#bzr 2012-09-18
<jfcaron1> I had a local project versioned with bazaar, and now I want to push it to launchpad.  Unfortunately I didn't realize that my local system had versioned some very large data files (multi-GB) which never changed.  Is there a way to push only the recent revisions, or to somehow push the changelog without having to upload all those files to launchpad?
<spiv> jfcaron1: not trivially
<jfcaron1> Can I just "unversion" the whole directory and start anew?
<spiv> jfcaron1: the easiest thing to do is to throw away the existing history, yes.  Another option is to create a new history without the unwanted parts, I think you can use the bzr-rewrite plugin to do that, or otherwise the bzr-fastimport plugin can do it (dump the history; filter it; reimport it).
<spiv> jfcaron1: (to throw away the existing history I'd suggest 'bzr export' it to a clean directory, then 'bzr add' etc there.)
<jfcaron1> spiv: I installed bzr-rewrite to use the rebase command, but I don't understand the syntax.
<jfcaron1> spiv: Will that make an entire new local copy of all the files, even the non-versioned ones?
<jfcaron1> What if I just delete the .bzr directory?
<mgz> morning
<jelmer> hi
<mgz> how are you today jelmer?
<jelmer> mgz: not great, actually
<jelmer> mgz: are we standing up today?
<mgz> hm, I think we should be
<tbf> do i really have to merge for rescuing commits from some obsolete branch?
<tbf> or is there something like git's cherry picking?
<tbf> i actually found http://wiki.bazaar.canonical.com/CherryPick, but this one also talks about merging
<mgz> tbf: what's confusing you? just that the interface uses the merge command?
<tbf> mgz, i just want to rescue some single commits from some obsolete branch
<mgz> a cherrypick is just applying the changes from a set of revisions
<tbf> mgz, but i don't like how bzr creates merge commits for that cherry picks
<mgz> you could do that by taking a diff of the changes that you want then using patch,
<tbf> mgz, that drops timestamps and and forces me to retype the commit message
<mgz> but `bzr merge -rA..B` is a handy tool that uses the bzr smarts
<mgz> ah, so you really want to rebase changes.
<mgz> look at the rebase plugin
<bjp> in bzrlib, i've been looking at builtins, most commands aquire a lock, but when i look at the individual functions, it looks like they have decorators that automatically aquire locks
<w7z> bjp: the decorators release the lock on function exit
<w7z> if you want to do more than one thing that requires a lock, it's therefore more efficient to explictly grab the lock at the start, then do the operations
<bjp> k, i thought that might be the case
<bjp> does doing multiple operations within a lock perform them over the same ssh connection (as opposed to opening a new ssh connection for each one) ?
<w7z> bjp: there's a possible_transports argument you can give on branch creation to reuse the transport
<w7z> but just keeping the same branch object around is also enough if you're only working with one
<bjp> i'm working with a tree object
<bjp> hopefully this speeds my script up a ton
<bjp> when i get it all worked out
<bjp> the operations in bzrlib spit out a lot of ssh debug output, can i turn that off?
<w7z> bjp: like what? generally ssh is used as a subprocess and its output doesn't reach the bzr terminal
<bjp> stuff like this: pastebin.com/yHJs1XJW
<w7z> huh, fun, never seen that before. aparrently comes from paramiko
<bjp> yea, i never saw it until i started testing my script with bzrlib
<w7z> I suspect you need to do something with logging
<w7z> are you using `with bzrlib.initialize(): ..` to wrap your program?
<bjp> no
<bjp> is that needed?
<w7z> strictly, no, but depending on what you need from bzrlib (logging, for instance) you diverge from what the bzr script does without it
<bjp> i don't do anything with bzr logging, but i use python's logging
<w7z> I suspect that's how the paramiko log stuff it getting through, bzr would send it to .bzr.log
<w7z> you can probably just look at how paramiko uses the logging module and forward just 'paramiko' to a null handler or something
<w7z> or set up a default logging handler that goes somewhere, and only catch your local bits for putting on the terminal, or so on
<bjp> weird, even if i set level to ERROR i still see all paramiko junk
<w7z> try calling enable_default_logging() from bzrlib.trace and see if that magically makes it vanish
<w7z> (might also mess with your logging, but worth an experiment)
<bjp> no change
<bjp> hmm i removed bzrlib.initialize, and my loglevel settings take effect
<w7z> hm, less, that probably overwrites them for the contained logic
<w7z> s/less/yes/
<w7z> but apparently not you handler that shows things on stdout
<bjp> well i wasn't using initialize before, if i drop it and explicitly set paramiko's logger to ERROR, i only see my logger
<w7z> that'll do then
<mark06> how can I tell bzr to export all but one file (the deploy script itself performing bzr export)?
#bzr 2012-09-19
<bob2> why did you version things you don't want to keep
<mgz> morning
<jam> hi mgz
<jelmer> jam, mgz: hi
<mgz> morning jelmer, feeling any better this morning?
<jelmer> mgz: Somewhat, fever seems to be gone  but still having an aching head.
<mgz> cut it off!
<fullermd> Cut off his head, or cut off his body?
<mgz> just the achy bit
<vila> doh, sorry about that jelmer, I didn't know that kind of virus can propagate via IRC...
<jelmer> :P
<mgz> vila: on bug 996401
<ubot5> Launchpad bug 996401 in Bazaar "'bzr config' fails to display config templates referring to "unknown" options" [High,Fix released] https://launchpad.net/bugs/996401
<vila> yes ?
<mgz> as far as I can see, there's still no way for gordon to store the line needed for the merge tool without config trying to expand things that don't exist when just using `bzr config OPTION`?
<vila> let's split your remark into 1) no way to store 2) just using bzr config OPTION
<vila> 1) is not true, there is no expansion when storing a value
<mgz> there's no way of quoting the { to say "this is a { in the option, not an config template"?
<vila> 2) is not applicable for a template that will provide the missing options
<vila> there is no need for quoting
<vila> the trick is that most options are expanded by default, but *some* should not (templates for examples)
<mgz> currently it seems like any config option that might have {} in it will behave oddly in some circumstances
<vila> hehe, name one :)
<mgz> well, the merge tool, it's using {} for its own templating, not done by config
<vila> but that's a template so when dealing with config you should ask for no expansion
<vila> that's the point of templates...
<mgz> but it's not a *config* template, it's a string config stores that happens to be a template
<vila> config provide (now, not when gordon wrote his stuff) .expand_options() for exactly this purpose
<mgz> ah, so you now want the config lookup to do the resolution?
<vila> dig the review of gordon's proposal, it was a known missing feature and I didn't want to block him
<mgz> that's a little complicated by merge needing to know what arguments are present to know what files to create on disk
<mgz> as different merge tools expect different inputs
<vila> no, templates should use expand_options(string, env={the needed additional options that are not config options})
<vila> the additional options do not need to be registered, each template can define whatever it sees fit
<vila> the only drawback is that 'bzr config TEMPLATE' needs to specify --all to *avoid* expansion, small price to pay for an edge case IMHO
<mgz> right, but merge tool needs to know what the additional options are specifically (which vary for different merge tools), before doing work
<vila> err, it cannot deduce unknown options from thin air, there is only a limited supported set
<vila> it's unrelated to config but specific to mergetool
<mgz> right
<mgz> so, mergetool should really have a way of just escaping the templating entirely...
<vila> it has, config.get('template', expand=False)
<vila> and I'm pretty sure it already uses it
<mgz> this is an edge case, but having magicstring  syntax without a way to say in the string that the next bit isn't syntax is odd
<vila> YAGNI
<vila> so better keep that stuff simple
<mgz> it'd be like having \0 mean something but \\0 meaning \ + NUL rather than \ + 0
<vila> yeah, I know the rationale and generally dislike the absence of escape notation, but there is just no need here
<vila> at least I've yet to see a case where it's needed
<mgz> I find the story from the question linked to that bug a pretty persuasive one, and it's not fixable from the mergetool side
<jelmer> mgz: still there?
<vila> mgz: url ?
<vila> mgz: sry, missed 'from the bug'
<mgz> https://answers.launchpad.net/bzr/+question/196441 <- ftr
<vila> right, the misunderstanding there is that template can be used with 'bzr config TEMPLATE' as said above, that's an edge case where you should indeed use 'bzr config --all TEMPLATE'
<vila> why will an escape mechanism address that ?
<vila> you may as well say that templates should use a different reference format
<vila> and a different expansion framework
<mgz> but from the user perspective, that series of steps seems sensible, but the output makes it look like you've messed up
<vila> doc bug then
<mgz> it's not really, why should they read documentation for that?
<vila> where did they hear about mergetool ?
<vila> how would they find which parameters they need to provide to their new mergetool without a description of {this} {other} {result} {tmp-whatever-I-can-never-remember-that-one}
<mgz> what do we add to <http://doc.bazaar.canonical.com/bzr.2.5/en/user-reference/configuration-help.html#bzr-mergetool-name> to make it clear that using mergetool breaks config?
<vila> oh come on, using mergetool do not break config, mergetool *cannot* be used without config
<vila> and you just found where the fix should go :)
<vila> also note that this piece of doc mentions that some arguments need to be quoted (yeah, a different issue than the config escape mechanism)
<vila> I mean, I'd rather add an escape mechanism to config than deal with users confusion when they need to use it :)
<vila> bah, bzr.mergetool.kdiff3 is not even registered :-/
<vila> mgz: https://pastebin.canonical.com/74784/
<mgz> vila: in unrelatedness, the progress bar config option is nice
<vila> in itself you mean ? Or how the proposal fixes the bug so trivially ?
<mgz> both!
<vila> right, you know, my new config proposal started with: "Not all needs can be addressed by the default values used inside bzr and
<vila> bzrlib, no matter how well they are chosen (and they are ;)."
<vila> progress bar is the canonical example: we went through several iterations to dwim... but in the end, there are always edge cases where the user should be able to set the Right Thing
<vila> ... and without needing to write a single line of code
<mgz> vila: so, apart from "the following will (rightly) break"... that doc change is okay
<vila> hehe
<vila> so s/(rightly)// ?
<vila> https://code.launchpad.net/~vila/bzr/mergetool-doc/+merge/125150
<vila> by the way
<mgz> I'm not sure you want to give the broken example at all
<fullermd> If we don't give broken examples, how will people know it's open source software?
<vila> well, then the working one makes less sense as --all requirement is less clear
<vila> fullermd: pff
<mgz> if we don't give "you're doing it wrong you silly user" documentation, how will people know...
<fullermd> ... that they're using git?  But this is for bzr, isn't it?
<vila> well, I'm pretty sure simone (the guy/girl) asking the question read that doc you cited and mergetool templates can be tricky...
 * fullermd has got his snark burner running on overdrive tonite.
<vila> lunch break, bbl, daughters hate it when they prepare it and I'm late ;)
<mgz> girl I think, but that sounds so much more condecending that guy
<mgz> there's not a good equivalent, so guy should just become gender neutral
<fullermd> "motile sack of mostly water"?
<vila> I think simone can be a male italian first name
<fullermd> Anyway, it's English; the masculine has always been the gender mixed-or-indeterminate form for pronouns, at least up 'till the last couple decades of rampaging.
<mgz> ...blasted continentals, I'm still not used to andrea being a male name, or anne
<fullermd> Many years ago, in my youth, I knew this guy named Jamie, who was dating this girl named Jamie.
<mgz> everyone needs sensible, obviously masculine names, like matthew.
<fullermd> (I'm pretty sure that was the _only_ reason they dated, briefly as it was)
<fullermd> No, only the most handsome and brilliant people should have named like Matthew.
<bob2> haha
<bob2> I knew a couple of James's
<ant384> Hello.
<mgz> hey
<ant384> Just starting with Bazaar. I set up a repository on a server, checked out a trunk, and now I'm playing with stuff. I managed to get info on all subjects except creating a header with keywords such as $Date$, $Author$, etc. I installed bzr-keywords, but can't figure out how to make it work. I used the version-info command to generate a version.py, but don't know where to place it. Please help. :)
<mgz> so, in general keywords are a bad habit from older vcses that you want to drop for other ways of doing things with a dvcs
<fullermd> For the former, the keywords plugin functions mostly at a PoC level.  For the latter, it depends what you want to do with the version.py   ;)
<mgz> putting that info into your build system rather than your versioned source is generally advisable
<ant384> I'm only working on python and shell scripts so far, so I'd like to have a header in them, in order to know what I'm testing / working on. Is it a bad idea in itself ?
<mgz> ant384: yes, you can just get that info from the vcs itself
<mgz> with a fancy editor, you can even have a call out to bzr to display that stuff to you alongside the file
<mgz> fullermd may have suggestions on that front
<ant384> So if I have a script that does X things on serveral machines, how do I make sure it's updated to the last version, if all I see is the code itself, with no version information ?
<fullermd> In probably a good 75% or so of the cases where you'd use keywords in CVS, there are better choices in modern systems.
<fullermd> In the other 25 or 20 or 10 or whatever percent...   well, you suffer.
<mgz> ant384: so, for example in that case, seeing the revno/date of last commit to the branch you're working on by the file would solve that
<ant384> So simply compare the script creation date with the date of the last commit to the branch ?
<fullermd> That wouldn't tell you anything definitive, at least absent very particularly constrained workflows.
<fullermd> One common simple setup would just be that you don't throw the script around by itself, you just have real branches or checkouts or whatever of it on each system, so you have all the VCS info right there to see.
<ant384> Aiee.
<ant384> Well, here's my current situation: maintaining / developing some bash and python scripts for my employer, aside from my real job. They're generally unique to the machine they're deployed on. I "develop" on my workstation, and use "header" type information in each file. Now I got a server that's usable as a central repository for code (among other things).
<ant384> The idea was to get everything on that server in Bazaar, then checkout scripts when I work on them, commit, and then deploy.
<ant384> Are you suggesting that it's a sane (you can tell I'm not really a programmer :) ) solution to check out each script on each machine it's used on ?
<mgz> what would you do otherwise, scp?
<fullermd> It can be.  A very situational thing.
<mgz> the real question is whether it's sane to have a branch per independant script
<mgz> and I do do that for some things (again, with a few helpers to making using bzr-as-rcs a bit nicer)
<ant384> Some of the scripts get very large. I would love to use a versioning system to track changes and plan work.
<fullermd> The alternative, assuming the keywords PoC isn't sufficiently there for you (which I expect it isn't) is that the "deploy" process has to do whatever rewriting to stash the info somewhere convenient.
<ant384> I see.
<fullermd> (e.g., with sed(1), as I do in one project)
<ant384> So instead of linking version info to the source file, I should link it to the deployment process, and only generate it as needed.
<mgz> yes, or just have checkouts as your deployment
<ant384> I'll give it some more thought. Thanks a lot for the opinions, guys. :)
<SamB_MacG5> okay, I've got a run_bzr()-based test, and I want to look at the output of a bzr command for debugging purposes ... what can I stick into the test temporarily to do that ?
<SamB_MacG5> hmm, "assert False" after a selft.run_bzr *almost* works, but it has "\n"s instead of actual newlines
<mgz> so, run_bzr returns (out, err) as strings
<mgz> one way to develop is to do `out, err =  self.run_bzr(...); self.debug()`
<mgz> which will drop you into pdb and you can look at the locals
<mgz> or you can `self.assertEqual("", out)` and work from there
<SamB_MacG5> ah, cool
<SamB_MacG5> darn, something is wrong with "bisect run" ...
 * SamB_MacG5 wonders if he can have broken it?
<mgz> SamB_MacG5: more specifically? or have you worked it out?
<SamB_MacG5> Well, at least, I'm confused about my attempts to write a grep-using testcase for the -r feature I'm adding ...
<mgz> SamB_MacG5: if you stick some code in a branch or pastebin I'd be happy to give pointers
<mgz> the hiccough is probably that the current tests aren't that great
<SamB_MacG5> well, it doesn't seem to make a difference whether I tell it to run "grep one test_file_append" or "grep -v one test_file_append" in my attempt at a test ...
<SamB_MacG5> lp:~naesten/bzr-bisect/683822-bisect-start-range-argument/ and https://gist.github.com/3750150
<SamB_MacG5> and yes, I know it's kind of silly to use gist for bzr stuff, but I had an Emacs command for it handy, so ...
 * SamB_MacG5 has to run
 * SamB_MacG5 will check back for tips later, though: thanks for offfering!
<SamB_MacG5> mgz: so long!
<mgz> later!
<mgz> SamB_MacG5: so, run_bzr doesn't actually start a shell subprocess, so you can't just use grep
<mgz> bisect has support for running a script, but that's as a seperate command
<mgz> ...which you're using, but not with an actual script, but directly?
<mgz> bisect is somewhat arcane here, what's it actually doing
<mgz> SamB_MacG5: your grep is just wrong I think, you want it to only match on rev 3 but not rev 4 and 5
<mgz> but test_file_append alwasy has 'one' in it... it gets appended to, not replaced
<mgz> SamB_MacG5: and more specifically, -v is not useful because there's always at least one line that doesn't match -> returncode 0
<ls3_> Hello. How can I find out where 'bzr push' is going to push to by default?  (ie with no push args)
<LeoNerd> bzr info
<ls3_> ah wow, thanks.
<mgz> what LeoNerd said, or `bzr config push_location` for just that
<ls3_> Do you mean 'parent_location' ?  I get push_location does not exist.
<mgz> right, that. :)
<mgz> hm, no, push_location
<mgz> but it might not be set
<mgz> in which case `bzr push` will tell you that
<SamB_MacG5> mgz: oh, duh, always one line that doesn't match ...
<SamB_MacG5> thanks!
<SamB_MacG5> oh, he's gone
<jelmer> ... and there's no wgz atm :(
<SamB_MacG5> anyway, yes, the documentation for "bzr bisect run" should mention that the command is run through the shell...
<delinquentme> hey all .. I want to add a single file to a commit
<delinquentme> and bzr decided to add every file that was changed to the commit
<delinquentme> i used $ bzr add /path/to/file.rb
<delinquentme> and then $ bzr commit -m "som merssage"
<delinquentme> then i get this: https://gist.github.com/60ff7b7c9c6f886e1946
<delinquentme> am I doing something wrong here?
<SamB_MacG5> delinquentme: bzr assumes you want to commit everything unless told otherwise
<SamB_MacG5> lately I've been using the qcommit command, which lets you uncheck what you don't want
<delinquentme> how can I only add files which I specify to be committed
<SamB_MacG5> "bzr help commit" probably says?
<delinquentme> looking ...
<delinquentme> and how about to drop back to the previous commit?
<delinquentme> something akin to $ git reset --hard HEAD^
 * SamB_MacG5 forgot
<delinquentme> bzr help qcommit giving me nothing
<delinquentme> in the event of a conflict
<delinquentme> which file is the one that is .moved
<delinquentme> the one which was previously committed to the repo is the normal one ... right?
<delinquentme> and the local copy which differed... is renamed with .moved
<fullermd> As for the former, you're reading 'add' in a git way.  In bzr it just adds the file to the list of those being tracked.  If you want to commit only a subset, you list them in the commit command line.
<fullermd> "previous committed to the repo" is pretty ambiguous.  .moved comes about because a new file (dir, etc) was created independently in the local and the remote branch.  I believe the one called .moved is the one that came about locally.
<lifeless> git add really should be git stage
<lifeless> calling it add just breaks folks brains if they use svn/cvs/bzr/hg/monotone/tla/darcs
<fullermd> Sure, but it's great for those p4 people!
<lifeless> all three of them?
<fullermd> It's a question of quality over quantity.  At least, it better be...
<bjp> is there a way to specify a revision range after (but not including) a tag?
<bjp> like -rtag:sometag..  without the tag
<bjp> *without the tagged revision
<delinquentme> fullermd, example of the "  If you want to commit only a subset, you list them in the commit command line. "
<delinquentme> ?
#bzr 2012-09-20
<fullermd> bzr ci foo.c bar.pl baz.pl quux.sgml [...]
<fullermd> bjp: Not via the UI, I don't think.  And it may not be specifiable as a range period, since there may not be a unique starting point.
<bignose> how can I view the log entries which affected a file that is now deleted or moved, when I don't know when that was?
<bignose> âbzr log foofileâ just gives âbzr: ERROR: Path unknown at end or start of revision range: foofileâ.
<fullermd> Think you gotta find the last rev that has the file first, then use that as the end.
<lifeless> you could use bzr search foofile to find the file in your inventory /somewhere, then bzr log -r ..lastrev foofile
<lifeless> or bzr log -v and grep/search for foofile.
<bignose> bzr: ERROR: No matches were found for the search [u'foofile'].
<bignose> I remember this being asked a while ago but can't find it.
<lifeless> huh
<lifeless> I may not have finished my path indexing spike. I thought i had :(
<bjp> fullermd: really?  theres a before: seems like there should be an after: :)
<fullermd> Well, for one thing, ancestry is like a single-linked list, so finding the after: revs would mean shuffling through the whole repo, rather than just reading an id.
<fullermd> But there can be multiple revs in after: none of which are related to each other, so which would you pick to start from?
<fullermd> (well, end with, more accurately...)
<bjp> well, what does -rtag:sometag.. show for its second tag?
<bjp> starts at sometag and goes to the end right?
<fullermd> Roughly speaking, but close enough, yes.
<bjp> and i'm using it with bzr log
<bjp> so i would figure -rafter:tag:sometag.. would show all the same revs except the first one with the tag? :)
<bjp> i'm using it to print all the changes/commits since it was last tagged
<fullermd> But that leaves you with a range with no unique start [end].  How to display that without misimplication isn't quite as easy as it sounds.
<fullermd> (in the general case, which is what the tool has to look at)
<fullermd> It's not an insurmountable issue, but it's more complicated than you'd think at a glance, and nobody has put in the time to answer all the ambiguities and figure out a good display and whatnot.
<bjp> so is there a better way to "show the log changes since sometag"? or is the easiest way to just "bzr log -rtag:sometag.." and just ignore the first entry
<fullermd> 's probably the best.  More accurately, figure out which rev tag:sometag is, and ignore that one.
<fullermd> (you definitely don't want to ignore the _first_, since that's the head; lists backward, remember  ;)
<bjp> right
<bjp> i'm parsing it all in python and spitting it out in wiki syntax anyway, so its not hard to add
<bjp> i just thought there was a builtin way of doing it that i was missing
 * fullermd nods.
<fullermd> I think log shows the tags by default too, so you don't even have to figure out the revno/revid for the tag yourself to exclude it.
<bjp> and i usually look for the method with the least amount of work :)
<fullermd> If you're doing it in python, you could probably bypass a lot of the UI level stuff and get the data more directly from bzrlib.
<fullermd> Though that's almost certainly the opposite of "least amount of work" unless you already know the API top to bottom.
<fullermd> And probably a long cry from it even if you do...
<bjp> yea i was messing with bzrlib in another script
<bjp> it's nice, but not nearly as well documented as the tools
<bjp> and if i was doing more than just 'bzr log' i'd consider it
<delinquentme> is there a way to drop an individual file back to the way it was at a particular commit?
<fullermd> delinquentme: See revert
<mgz> morning btw
<vila> morning mgz ;)
<mgz> morning vila!
<vila> mgz: care to re-review https://code.launchpad.net/~vila/bzr/mergetool-doc/+merge/125150 ?
<vila> jelmer: I know I've been far too long to propose https://code.launchpad.net/~vila/bzr/514301-auth-config-unicode/+merge/124627 but I also hope you will review faster than me ;)
<vila> darn, tyop in bug # again (bug #388725 instead of bug #388275)
<ubot5> Launchpad bug 388725 in Duplicity "Report when duplicity is 'done' with restoring a file" [Wishlist,New] https://launchpad.net/bugs/388725
<ubot5> Launchpad bug 388275 in Bazaar "want configuration option to control progress bars" [Medium,In progress] https://launchpad.net/bugs/388275
<emeric> Hi folks,
<emeric> I have a bzr repository checked out somewhere, and would like to check out the same repository on another computer. Is there a way to find out the URL used in the first checkout ? bzr info does not display it.
<mitya57> I hope I can ask loggerhead-related question here:
<mitya57> Does this error (http://anonscm.debian.org/loggerhead/pkg-grub/trunk/grub/revision/2550.1.1)
<LeoNerd> If bzr info doesn't say, then likely the information doesn't remain. But you can always checkout from the first computer.
<mitya57> happen because of old loggerhead version?
<mitya57> or is that a known bug?
<emeric> LeoNerd: I can checkout/commit from the first computer, but if I want to code from another one, I'm out of luck if the URL is not displayed in bzr info ?
<fullermd> If it's a checkout, info will certainly show it, otherwise it couldn't work.  As an independent branch, you _could_ have cleared out the info so it's no longer there, but why would you?
<LeoNerd> If you're committing, then you are just committing to that local branch then
<LeoNerd> Otheriwse, brz info would be showing the commit branch
<emeric> Output of bzr info.http://www.privatepaste.com/f2817d362b
<LeoNerd> Yup, so there's no upstream checkout or submit branch there
<emeric> Which means I can only work from the place where the first checkout has been made ?
<emeric> (Sorry, I sound like complete helpless , but that's what I currently am regarding bzr)
<emeric> bzr checkout bzr+ssh://root@ctrl/root/atta_dev lctests
<emeric> This one seems to work, yay !
<emeric> Note to self: also install python*-gobject*. Thanks alot for the help folks.
<fullermd> I'm not sure what value of "works" corresponds to "can ssh in as root"...   :p
<emeric> Automated tests having to run as root, written on a test computer, in root home, versioned using bzr. If I want to develop more tests from a workstation, it seems the only option I have is to bzr+ssh as root, unless I missed something.
#bzr 2012-09-21
<_kbulgrien> I have a web host that has an old python so only bzr 2.3.4 is usable.  Is there an easy way to know what versions of a plugin are compatible.  I'm interested in fast-export/import etc. as I made my repo too big and want to break it into smaller pieces.
<AfC> _kbulgrien: do the work on your local system, then send the results back up to the server. Distributed.
<_kbulgrien> Hmm.  Heh.  Yeah, new to the whole distributed thing.  Thanks for that thought.
<_kbulgrien> hrm.  not having luck installing the plugin.
<_kbulgrien> bzr plugins lists it, but when I try to use it I get bzr: ERROR: Unable to import library "fastimport": bzr-fastimport requires the fastimport python module
<_kbulgrien> I guess that means my python installation needs something called fastimport.
<_kbulgrien> fun. nothing in the distribution that looks like that.
<AfC> _kbulgrien: it's the bzr-fastimport plugin on Debian/Ubuntu
<_kbulgrien> I got that, but I think I need https://launchpad.net/python-fastimport too
<AfC> _kbulgrien: you're obviously not on Ubuntu, or this would Just Workâ¢
<lifeless> _kbulgrien: how are you installing the plugin ?
<_kbulgrien> i untarred the tarball and put it in ~/.bazaar/plugins/fastimport then ran python setup.py build_ext -i there.
<_kbulgrien> bzr plugins shows it installed
<_kbulgrien> Now I just found python-fastimport and have run python setup.py install for it... (working through it bit  by bit as I'm not a python guy)
<_kbulgrien> I think I might have to set up PYTHONPATH now
<lifeless> _kbulgrien: ok, so the usual way if you are using ubuntu etc is to do 'apt-get install bzr-fastimport' which will take care of all the dependencies for you.
<lifeless> _kbulgrien: thats what AfC was referring to above.
<lifeless> _kbulgrien: you might find docs in README or something in the source tree for bzr-fastimport documenting its dependencies.
<_kbulgrien> Yeah, but I am not an ubuntu user
<lifeless> _kbulgrien: ok
<_kbulgrien> and apparently this distro does not have python-fastimport packaged or I do not have the right source set up for it.
<lifeless> you might find 'pip install fastimport' works
 * _kbulgrien isn't aware of pip
<_kbulgrien> ok, got it.
<_kbulgrien> did python setup.py install --user for python-fastimport
<_kbulgrien> now bzr fast-export worked
<_kbulgrien> this would be so much simpler with partial checkout... just sayin...
<mgrandi> how would you do partial checkout with no .bzr directories in every folder
<mgrandi> which makes me loathe svn
<mgrandi> so much
<_kbulgrien> well, I don't know the techie details... sorry... but I am so used to partial checkout I haven't figured how to emulate it in bzr yet.
<_kbulgrien> I don't like svn either
<mgrandi> i dont see the need for partial checkouts when you have branches
<_kbulgrien> I probably would get abused if I said I was a cvs user
<_kbulgrien> of course not, you're not me
<_kbulgrien> everyone sees things from the way they learned to work.
<mgrandi> we used to use svn with partial checkouts, but it was different projects inside a root folder managed by svn
<mgrandi> which could of easily been split up into branches, but i dunno
<_kbulgrien> I happen to find partial checkouts in cvs really powerful.  I have to learn a new way now, but since I only used cvs and svn enough to know I didn't want to migrate to it... well, I have to figure it out.
<mgrandi> haha
<mgrandi> my teacher told the students to use cvs
<mgrandi> for the final, at the end he asked how many people lost data / had problems, nearly everyone raised their hands
<_kbulgrien> I must be old and musty because I think cvs works fine as I use it all the time at work and find it easy compared to picking up distributed vcs, though bzr comes the closest to fitting the idea I think a vcs should work.
<mgrandi> instead of partial checkouts, put the things you would partially checkout into separate branches/repos
<_kbulgrien> we never loose data in cvs.  the reason we are on cvs is because we lost data on everything else.
<_kbulgrien> but then that was maybe 15 years ago when cvs came to the shop.
<mgrandi> and yes bzr is nice cause you don't have to be forced into one way of doing things
<mgrandi> which i dont like about git
<_kbulgrien> I tried git first.
<mgrandi> git is nice with a pretty UI, which on osx there are plenty of
<mgrandi> on windows, nopenopenopenopenope
<mgrandi> the only thing ive seen is the github app for windows, which is using a c# library that produces/consumes git stuff, rather then actually using the git program itself
<_kbulgrien> After two weeks of struggling, I ran into  wall.  In <1hr I had converted the git repo to bzr and was working without even looking in a manual.
<_kbulgrien> only I find now that doing stuff like this is more complicated.  I also find bzr has some annoying bugs that seem like they will not get fixed.
<mgrandi> like
<_kbulgrien> https://bugs.launchpad.net/bzr/+bug/1012907
<ubot5> Ubuntu bug 1012907 in QBzr "Access denied in uncontrolled folder prevents add in controlled folder" [Undecided,Incomplete]
<_kbulgrien> and similar file system permissions issues with command-line
<mgrandi> ah yes.
<mgrandi> i should take a look at that, that shouldn't be very hard to fix.....
<mgrandi> its probably doing a 'os.walk()' without catching exceptions
<_kbulgrien> well what is odd is that it goes digging around where it shouldn't go in the first place.
<_kbulgrien> then if you have anything fail, the whole operation fails
<_kbulgrien> cvs would baulk but would keep going
<mgrandi> so what folder are you trying to actually monitor?
<_kbulgrien> bzr upchucks and bails without doing anything
<_kbulgrien> well in this use-case, I am controlling user directory type stuff so I can share my setups between machines... keep a reference setup to push/pull in and out off.
<mgrandi> hmm yes
<mgrandi> C:\Documents and Settings\kbulgrien\Favorites\yadayada.url
<_kbulgrien> exactly
<mgrandi> it went down a directory then went into all users
<mgrandi> weird
<mgrandi> i'll take a look at it, ive been meaning to actually write some code for bzr
<_kbulgrien> In that case, I could go command-line and make it work.
<_kbulgrien> But the problem is that I also deliberately control areas of the filesystem that have stuff I can't read too, and command-line is just hosed there.
 * SamB_MacG5 doesn't remember noticing a lack of gitk on Windows ... wonders why?
<mgrandi> git was written by linus, so it pretty much depends on the gnutils or whatever its called
<mgrandi> _kbulgrien: where is the bzr repo on your disk?
<_kbulgrien> C:/ for that scenario in that bug
<mgrandi> ahh
<SamB_MacG5> oh, right, that's because it works finefine
<mgrandi> but then you go onto windows, you need cygwin
<mgrandi> which sucks sometimes
<_kbulgrien> oh... repo... no... the repo is somewhere else
<SamB_MacG5> msys doesn't suck as slowly, I think
<_kbulgrien> like bzr+ssh://linushost....
<mgrandi> well the local copy of the repo
<_kbulgrien> I use msys
<mgrandi> cause a repo monitors things inside of it, so its in C:/ ?
<_kbulgrien> no... repo is completely somewhere else... .bzr is in C:\
<_kbulgrien> I answered wrong the first time
<SamB_MacG5> As I recall, gitk on Windows actually looks a lot nicer than on OS X ...
<mgrandi> well the thing is with bzr and other DVCS, if you have a 'branch ' of something, then you technically have the complete copy of the history
<SamB_MacG5> something to do with the font metrics...
<mgrandi> so you technically have the repo on C: and on your server
<_kbulgrien> except in this case I used --lightweight or whatever
<mgrandi> unlike svn where you don't have the history ever, its all on the server
<mgrandi> ah
<mgrandi> but its in C:/
<mgrandi> so thats slightly better, i thought bzr was going up a directory
<SamB_MacG5> mgrandi: that's what bzr-svn is for ;-)
<mgrandi> and thats kind of bad
<mgrandi> but like i said, its probably doing some sort of os.walk() without any error handling
<mgrandi> i'll take a look at it, this seems like a nice place to start~
<_kbulgrien> I also don't like that bzr status doesn't allow --no-recurse
<mgrandi> well, it makes sense when you think about it...
<mgrandi> the whole point is that stuff under the repo folder is monitored
<_kbulgrien> well when, say I am working on a webserver, I lots of times don't give a rip about status anywhere except where I am, and all the boatload of status is annoying
<mgrandi> you can probably do bzr status --versioned
<_kbulgrien> hm...
<mgrandi> you have a weird case where your repo is your entire hard drive
<_kbulgrien> ok... will have to try to remember that
<mgrandi> but you are only versioning certain parts
<mgrandi> usually everything (like in a code project) in the folder wants to be versioned unless you specifically ignore it
<mgrandi> but yeah, use --versioned, will only show files that are actually versioned instead of all those ? ones
<_kbulgrien> well  I know my grief is that I want to do version control for things that aren't typical software dev, but I think version control transcends software dev...
<mgrandi> but no recurse wouldn't make sense, cause where would it not recurse?  =P
<mgrandi> well bzr/git/whatever works fine for this, but yeah have to do some things a little different
<mgrandi> the same thing with dropbox, everything in the dropbox folder gets uploaded
<_kbulgrien> well, I don't know what you are saying because cd ~/public_html; bzr status --no-recurse makes sense to me.
<mgrandi> but if there are files in /public_html/stuff and /public_html/stuff2, it has to enter those folders
<_kbulgrien> why does it have to?
<mgrandi> but no recurse makes me think that it just only goes into public_html
<mgrandi> i kinda get what you are saying,
<_kbulgrien> All I care about most of the time is the folder where I am, and I don't really need to know status for the whole sub-tree all the time
<mgrandi> kind of like ls
<_kbulgrien> Sure, at some point I care, but not while I'm working locally in that folder only.
<_kbulgrien> I use bzr status . all the time to not get history outside a sub-tree.  It's the same principle.
<mgrandi> have you filed a bug report on this yet? (just so people remember)
<_kbulgrien> Not yet.
<_kbulgrien> I'm still getting used to things and the annoyance pressure hasn't built up to file a bug level yet.
<mgrandi> should and link it, again shouldn't be that hard
<mgrandi> to add --no-recurse
<_kbulgrien> well  I guess I'm not sure if bzr status is the only thing that doesn't have --no-recurse that I wish had it... so part of the delay is to see if there are other commands that get annoying because of no --no-recurse.
<mgrandi> might as well start with the status one =P
<_kbulgrien> otoh bzr status not having it _is_ the most annoying.
<mgrandi> i'll look into it and see if its easy
<_kbulgrien> I guess I'm skeptical that anyone cares these days.
<mgrandi> open source software for you =P
<_kbulgrien> And I feel since I don't know python that people think I'm just whining... you know... submit a patch then doofus...
<mgrandi> hehe
<_kbulgrien> but learning python to patch a vcs is not something done lightly
<_kbulgrien> well, really, its not the learning python part... its learning the bzr source part.
<mgrandi> yes
<mgrandi> people have discussed that bzr and any vcs is hard cause of complex data structures that really can't fail ever =P
<mgrandi> but if its just command stuff like this, i feel i can take a stab at it
<_kbulgrien> I code in so many languages and scripting languages that its really not about learning python.
<_kbulgrien> This is the other bug that kills me https://bugs.launchpad.net/bzr/+bug/964338
<ubot5> Ubuntu bug 964338 in Bazaar "bzr status abort on encountering an unreadable file." [Low,Confirmed]
<_kbulgrien> heh, I see bug listed for bzr revert needs --no-recurse
<_kbulgrien> Ok, so maybe I add one
<mgrandi> yeah, it seems that bzr should not be failing on these
<_kbulgrien> ok, its been did
<mgrandi> link?
<_kbulgrien> https://bugs.launchpad.net/bzr/+bug/1053778
<ubot5> Ubuntu bug 1053778 in Bazaar "bzr status needs --no-recurse" [Undecided,New]
<mgrandi> ok
<mgrandi> i;ll take a look at it
<mgrandi> but now need to go, later!
<_kbulgrien> Hmm. well, I guess that went ok.  Looks like I broke apart the repository the way I intended out, though I went about removing the top-level directory in a harder way than was necessary... it turns out fast-import-filter public_html/ with the trailing slash is the right way to prune top-level folder levels out of the fast-export.
<_kbulgrien> I guess the grammar on that was bad... I meant ...specifying extra path levels is the way to prune...
<mgz> morning
<emeric_> moin moin
<Ovocean> Hi! I'm quite new to bzr and I have come across a situation I don't know how to deal with:
<Ovocean> I have uploaded a branch for Lutris on Launchpad, it's been merged with the main branch. But I had done a couple commits to my local branch before the merge, and didn't upload them yet. Now I need to get/merge back the last version of the main branch (rev 163) and have my last commits (rev 176 & 177 on my local branch) put on top of that as rev 164 and 165. How would I do that?
<fullermd> Why do you want to?
<Ovocean> To be able to continue to work on my branch, and not loose my last commits. What's the normal way to do this?
<fullermd> Just merge trunk and move on.
<Ovocean> Right, but then the rev numbering doesn't match the main branch. It doesn't matter? Doesn't look clean to me.
<fullermd> Doesn't matter.
<Ovocean> Fine then. Thanks for the help
<fullermd> Only thing that matters in merging and suchlike is what revs are present where.  revnos just relate to the shape of the local history.
<Ovocean> Ok
<kiretooo> hello :)
<kiretooo> what means that:
<kiretooo> You have not informed bzr of your Launchpad ID, and you must do this to
<kiretooo> write to Launchpad or access private data.  See "bzr help launchpad-login".
<jelmer> kiretoo: exacyl
<jelmer> kiretoo: exactly that. you have not told bzr what your username on launchpad is yet
<kiretooo> jelmer, i've already has a username
<jelmer> kiretooo: does bzr know about it? have you run bzr lp-login?
<kiretooo> i have to add some ssh keys ?
<SamB_MacG5> kiretooo: yeah, you need to set up an ssh key on your system and paste the public key into a box in your launchpad profile/configuration
<SamB_MacG5> hmm. Bzr 2.3's lsprof cachegrind/callgrind output needs work :-(
<vila> SamB_MacG5: have you tried getting a more recent python on your G5 ?
<SamB_MacG5> I suppose I could, though also getting the extra batteries might be a bit of a pain...
<vila> SamB_MacG5: easy_install ?
<vila> SamB_MacG5: that was just a thought, no idea how complex it can turn out
<vila> SamB_MacG5: on the other hand, if you can get up to 2.7, you should be good to go for quite a while
<SamB_MacG5> would it be reasonably easy to build an installer for that, is another worry
<SamB_MacG5> (a bzr installer, I mean)
<SamB_MacG5> oh, and another complication would be that 10.5's xcode only comes with SVN 1.4
<SamB_MacG5> oh, I was thinking of trying to build from Apple's python sources...
<vila> SamB_MacG5: I was thinkinh more about http://python.org/ftp/python/2.7.3/python-2.7.3-macosx10.3.dmg
<vila> jelmer: is bzr-svn trunk compatible with svn-1.4 ?
<vila> SamB_MacG5: well, you could start with a reduced number of plugins (all is defined in config.py right?) ?
<vila> SamB_MacG5: http://python.org/download/ says the above is for 10.3 through 10.6
<SamB_MacG5> vila: I suppose bzr *probably* doesn't have much use for apple's extra pack-ins ...
<vila> SamB_MacG5: sry was afk, extra pack-ins as in python modules added by apple ? In this case, I'm pretty sure the answer is yes. The only one I can think that may use apple specific stuff is for the keyring (sry, can't remember the plugin name) and I seem to recall it doesn't use any apple-specific python stuff
<SamB_MacG5> I mean Python extensions/libraries that Apple has bundled into Python, though upstream (and in most distros) they're packaged separately
<SamB_MacG5> er. I should have said "into the Python framework"
<SamB_MacG5> basically, the stuff in /System/Library/Frameworks/Python.framework/Versions/2.5/Extras
<vila> SamB_MacG5: right, I'm pretty sure bzr uses nothing from there (well, I'm sure for the core, pretty sure for the plugins)
#bzr 2012-09-22
<jelmer> vila: it doesn't really matter what bzr-svn is compatible with, but what subvertpy is compatible with
<jelmer> 1.4 is almost certainly too old though
<_kbulgrien> hmm... bzr+ssh doesn't load user environment on far end?  I get prompt for password then get `bash: bzr: command not found
<_kbulgrien> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.`
<_kbulgrien> Hmm... BZR_REMOTE_PATH...
<_kbulgrien> ok, that helps, but doesn't get by needing PYTHONPATH set to point to where bzrlib is on the remote.
<_kbulgrien> I had to load bzr and bzrlib in my home directory on a web host. Now I can't seem to get bzr+ssh to work there because the remote bzr can't find its bzrlib because PYTHONPATH in .bash_profile on the remote isn't loaded.  Is there a way to work around this other than, for example, putting the repo in an ftp space and avoiding the smart server?
<_kbulgrien> sftp:// works.
<_kbulgrien> ls
<vila> jelmer: right, so next question is: if SamB_MacG5 can find a subvertpy version old enough to support svn 1.4, will bzr-svn.trunk be still compatible ?
<vila> _kbulgrien, too bad you left. The trick to address your issues is to use a local wrapper so you can set anything you want.
<vila> _kbulgrien: After that bzr_remote_path in locations.conf (so you can set it differently for different hosts) and you're done
<vila> _kbulgrien: the wrapper I use is: '#!/bin/sh \n python /path/to/bzr $*'
<vila> _kbulgrien: In locations.conf I have: '[bzr+ssh://myhost.local] \n bzr_remote_path = /path/on.myhost.local/to/wrapper
<fullermd> Or fix his shell config.
<fullermd> vila: and you want "$@" not $*
<fullermd> (well, and 'exec' for cleanliness, but...)
<vila> fullermd: ha, thanks for the tips. (shell is one of those languages I never took the time to master (I know make even better than shell...)).
<vila> fullermd: so, even reading the doc didn't give me the feeling that one is better than the other in practice. Any caveat to be aware of ? "$@" is always safer than "$*" ?
<fullermd> $@ keeps the borders between the arguments.  $* resplits.
<fullermd> Rather "$@" does.  Both unquoted end up resplitting, but * quoted is a single.
<fullermd> vila: e.g.: http://pastebin.com/42tNmcBi
<fullermd> Upshot being that the $* will fail to DTRT any time there are single args with spaces in them.  Filenames, paths, a `-m "log message"`, etc.
<vila> fullermd: right, so to be on the safe side, the rule is to always use "$@" then right ?
<vila> argh, mgz effect, sentence too long with the same word at the beginning and the end ;)
<fullermd> If the goal is "pass args through as if we were aliasing to this other command", yeah.
<vila> yup, which is the case I care the most about
<vila> I think I always missed to read the right part in bash help as $@ == make target
<vila> in my mind and I just couldn't use that in shell
<fullermd> Let's not go there.  It'll bring up memories of the awk scripts I wrote to handle bmake vs gmake...
<vila> urgh, suffering already :)
<fullermd> Someday, I'll get the time to finish my make replacement, and I won't have to deal with any of that crap again.
<vila> ha, the adage (haha) about the small and beautiful language hidden in the monster  applies to make IMHO
<fullermd> I dunno.  Hidden inside the monster of make, there's a language that's small, beautiful, and completely incompetent.
<vila> the fact that it allowed creating such awful results should be used against it
<fullermd> ... as opposed to the whole, which is large, terrifying, and still pretty incompetent...
<vila> nah, there are some drawbacks (like in any other) but there are also sane ways to use it right
<vila> but I reckon I rarely saw clean and light makefiles :-/
<vila> err, not reckon,
<vila> recognize ? confess ? concede ? yeah, probably concede
<fullermd> Spend some time in the bowels of the ports system sometime; that'll teach you how many clean light makefiles there are out there   ;p
<fullermd> 'reckon' would work too.  Especially down here.
<vila> exactly my point then
<vila> for example, how many makefiles truly support -j ?
<fullermd> All of the ones I write, and most of the ones I deal with  ;p
<vila> oh, that wasn't ironic ?
<fullermd> Life is too short to wait for serial compiles...
<vila> You really mean the ports makefiles are correct ? Worth having a look one day then. But you're not talking about the makefiles provided by the packages then right ?
<vila> (Which are the ones I have the most exposure too)
<fullermd> Well, the compilation is [almost] never part of ports itself; that would come from the upstreams.  And I know a fair number of those are broken stupidity (even before we consider they came from automake).  But I don't so much deal with those, as just tolerate them temporarily untarred on my system during the build.
<vila> (yeah, let's exclude automake, that's clearly outside of this discussion ;)
<vila> ok, so we seem to agree now that the context is a bit clearer ;)
<fullermd> But ports itself is an excellent object lesson in the terrors and horrors that away in an almost-competent language.  By the time you realize how wrong a choice it is, it's far too late to change and you have to bull ahead anyway.
<fullermd> s/that away/that await/
<vila> ha, 'far too late to change'... the weight of compatibility... 'be ready to throw it, you will' or whatever he said ;)
<fullermd> In practice, anything nontrivial in "make" winds up really just being a framework for calling a giant pile of unrelated obfuscated inline sh(1), with demonic contortions to get the data from A to B.
<vila> right, don't do that in make then is my attempt to answer
<fullermd> Which is why doing anything in ports involves calling fork() about a thousand times.
<fullermd> Right.  But *way* too late for that  ;p
<vila> I mean, make manages dependencies, it has limited support for complex actions
<vila> indeed
<vila> or not
<vila> that's the point, it's an organizational choice not something the tool is really blamable for
<vila> (and I'm not saying I have the magic bullet either...)
<fullermd> Yeah, but the tool being almost-competent ensures that it will continue to be chosen and then the organization is left to force the last 10% by hook or crook.
<fullermd> The "solution" is to have tools that are fully competent and tools that are so weak as to be almost worthless.  Which is stupid too.
<fullermd> So the end of life-as-we-know-it is really the best solution, as I've said all along.  No software problem is so intractable it can't be solved by a good supernova.
<vila> yeah, it's a well known fact that things are always simpler when you cool down a bit
<vila> so when you coll down a lot, they have to be even simpler
<vila> cool
<vila> spurious tyop, joke alert
<fullermd> It don't get much cooler than 2.725 Kelvin   ;p
<vila> hehe
<fullermd> Some day I'll write up and submit a patch to make(1) to allow it to read email.  Just to see if I can get it accepted.
<vila> hehe, BCc me ;)
<vila> <vila> _kbulgrien, too bad you left. The trick to address your issues is to use a local wrapper so you can set anything you want.
<vila> <vila> _kbulgrien: After that bzr_remote_path in locations.conf (so you can set it differently for different hosts) and you're done
<vila> <vila> _kbulgrien: the wrapper I use is: '#!/bin/sh \n exec python /path/to/bzr "$@"'
<vila> <vila> _kbulgrien: In locations.conf I have: '[bzr+ssh://myhost.local] \n bzr_remote_path = /path/on.myhost.local/to/wrapper
<_kbulgrien> Oh, ok... that makes sense... almost feels like a doh moment...
<_kbulgrien> I did figure out the locations.conf part.
<_kbulgrien> hmm.  I'll have to dink with it. My first few attempts to add PYTHONPATH aren't working, but then I've not used fancy hashbangs like that before.
<_kbulgrien> doh.
<_kbulgrien> I read \n as literal but then with a little grey matter applied... that didn't make sense.
<_kbulgrien> I got it working.  Thanks vila
<vila> _kbulgrien: PYTHONPATH shouldn't be needed, the bzr script arranges to call its associated bzrlib
<_kbulgrien> it doesn't actually... PYTHONPATH is required in this situation as bzr barfs up with bzrlib not found without it ( http://pastebin.com/pYrVQNjw )
<_kbulgrien> Adding "export PYTHONPATH=${PYTHONPATH}:${HOME}/lib64/python" to the wrapper fixes that error.
<vila> hmm, weird, I haven't needed that but then the various .rc involved when you connect this way and that left me... discouraged
<_kbulgrien> of course the webhost only has 2.3.4 because of the old version of python, so maybe this was improved in a later version?
<_kbulgrien> I had to manually install bzr in my home directory since it was not pre-installed.
<vila> urgh, stuck with python 2.4 ?
<SamB_MacG5> vila: oh, I've got an old enough version of subvertpy
<SamB_MacG5> 6.533  bzr-svn: using Subversion 1.4.4 (), subvertpy 0.8.1
<vila> SamB_MacG5: with bzr-svn trunk ?
<SamB_MacG5> vila: no, doesn't work with trunk
<vila> SamB_MacG5: which version then ?
<SamB_MacG5> 1.1.0, but the test code is broken ...
<vila> ha too bad :-/
<SamB_MacG5> maybe I should try and fix subvertpy
<vila> SamB_MacG5: check with jelmer for details there, I'm not sure the tests have been thoroughly and regularly run on osx
<SamB_MacG5> vila: I meant *besides* the breakage due to missed URL escaping wrt TMPDIR
<vila> but there ought to be a combination of bzr-svn/subertpy that works for your case (config.py in the installers may be a good start too (sorry I didn't mention that earlier))
<vila> ^_o
<vila> TMPDIR URL escaping ?
<SamB_MacG5> iMac:pyprof2calltree user$ printenv TMPDIR
<SamB_MacG5> /var/folders/4b/4b+Qm+OQFj8f23emq17tBU+++TM/-Tmp-/
<SamB_MacG5> I get a bunch of "tests tried to escape" complaints
<vila> ha crap
<SamB_MacG5> due to the plus signs
<vila> I did a fix for that in bzrlib involving using realpath or something
<vila> I'm not sure it's caused by the plus signs, I'd rather bet on some symlink being resolved or not when needed
<vila> It took quite a long time and several shots to get them all, not sure all of them are in 2.3
<vila> grepping for osx in bzrlib/tests should get you there
 * SamB_MacG5 checks for sure
<SamB_MacG5> https://gist.github.com/a4eff1160a82eb92602d
 * SamB_MacG5 blames his IRC client this time
 * SamB_MacG5 wonders how his IRC client knew how to authenticate itself as him with github, anyway
<SamB_MacG5> vila: okay, it's also possible that the URL got fully escaped, but was then unescaped before being checked against the list ...
<vila> I don't think so, I'm pretty sure the isolation stuff is encoding neutralassume it receives the urls in the right encoding
<vila> I don't think so, I'm pretty sure the isolation stuff is encoding neutral
<vila> gree
<vila> grrrrrRR
<vila> there may a way to temporarily disable the isolation check too
<vila> *may be
<SamB_MacG5> well, it's easier to just add "TMPDIR=/tmp" at the beginning of the commandline
<vila> oh yeah, far easier ! :)
<vila> perfect work-around, you can pretty safely ignore the isolation errors, the check is here to guarantee we don't introduce new leaks
<vila> but all existing tests have passed that check countless times now
<SamB_MacG5> actually, there seems to be more code that doesn't quite work ...
<SamB_MacG5> outside the test harness
<vila> ha, less good, you really need jelmer there then
<SamB_MacG5> so obviously fixing up subvertpy is better ...
<vila> or search launchpad for later fixes
<vila> probably
<vila> SamB_MacG5: did you try a more recent python version by the way ? (just curious)
<SamB_MacG5> oh, no, not yet ...
<vila> ok, let me know about the end result if/when you do
<SamB_MacG5> but that probably wouldn't help a whole lot with bzr-svn?
<vila> I can't answer that, sorry
<vila> in theory, it could be better as well as worse, so the theory isn't really helpful there, you need the expert's specific knowledge ;)
<SamB_MacG5> well, subvertpy trunk will still need fixing to make it build with SVN 1.4...
<vila> SamB_MacG5: and you really need bzr-svn *there* ? (As opposed to another host where you could use recent stuff and publish with bzr+ssh)
<SamB_MacG5> oh, and about config.py, I know it's supposed to have all the right versions listed, but it had issues even *before* I merged from lp:bzr-mac-installlers
<SamB_MacG5> I'm still trying to sort out the right versions of everything to make things mostly work
<vila> eerk, don't ever merge from lp:b-m-i, you should only work on top of lp:b-m-i/2.3
<SamB_MacG5> it had some nice-looking infrastructure improvements
<vila> hmm
<vila> there are two things here
<vila> one is config.py, use only the lp:/2.3,
<vila> the other is everything else probably which should be safe to use but has never been tried so may have introduced regressions ?
<vila> but config.py, wow, be extra conservative there or you'll run into an endless maze of compat issues
<SamB_MacG5> it's kind of annoying that launchpad download URLs include the series ...
<vila> why ?
<SamB_MacG5> then it would be simple to build the URL from a template and the version number
<SamB_MacG5> I mean, if they didn't
<SamB_MacG5> anyway ... yeah, I knew I would have to revert a lot of the version numbers in config.py when I did the merge
<vila> err, you mean 'bzr lp:<project. -rtag:<version>' vs 'lp:<project>/<series>' ?
<SamB_MacG5> vila: no, I meant the tarball URLs
<vila> Well, I thought config,py used a format and some params and build the URL from that no ?
<SamB_MacG5> it seems to just run % on all of the strings with the dict as right-hand argument
<vila> the series is often part of the version
<SamB_MacG5> yes, but sometimes the series has varying length ...
<vila> so if you have 'series' and 'version' as parameters or 'minor_version' stuff like that
<SamB_MacG5> well, I suppose that could be done, yes
<SamB_MacG5> though some of these projects are actually rather irregular in their series usage
<SamB_MacG5> so you basically have to just look up the URL anyway...
 * SamB_MacG5 thinks he's thinking of bzrtools
<vila> yeah, so tweaking config.py at release time was generally light enough to never itch enough ;)
<SamB_MacG5> anyhow, yeah, I know about config.py and am, in fact, trying to prepare it for a release ;-)
 * SamB_MacG5 wonders how to disable lazy imports
<vila> yeah, so the rules when doing releases (up to you to follow them or not) was to push for plugins trunks for beta releases, freeze at 2.x.0 time, update only to dedicated series for plugins providing them otherwise stay frozen
<vila> which is another way to say: if you want to do a 2.3.n+1 release, stick with whatever was in 2.3.n *unless* plugins like qbzr released 2.3 targeted point releases
<vila> looking at the history of config.py should give you the most precise view of it, including divergences from these rules ;)
#bzr 2012-09-23
<delinquentme> bzr branch lp:~bzr/bzr-gtk/trunk ~/bzr-gtk/john   ... this guy here ... what does the lp stand for?
<delinquentme> and can I take downstream commits ... commit them to a new branch .. then push that branch to the parent repo?
<ChristopheT> delinquentme: lp = launchpad <https://launchpad.net/>
<delinquentme> ChristopheT, Oh so thats where the trunk is located at
<ChristopheT> You do not have the right to push <https://launchpad.net/bzr-gtk> but you can push to your own account or submit a patch to the bug tracker.
<delinquentme> thanks ChristopheT
<delinquentme> !
#bzr 2013-09-16
<zodiak> how do I skip a revision in a branch ?!
<zodiak> eg; cherry pick everything EXCEPT one revision
<__marco> Hi, can I install a plugin only for a specific branch? I want to build the deb package every time I do a pull
<__marco> but only on a specific branch
<jelmer> __marco: you can't install a plugin for a specific branch, but most plugins will look at the configuration at a branch to see whether they need to do anything
<__marco> jelmer: Could you please name one so that I can see how it does?
<jelmer> __marco: e.g. bzr-email
<__marco> jelmer: thanks
<__marco> Is a post_pull hook executed only after a successful pull, right?
<jelmer> __marco: yeah
<bjp> i'm doing 'bzr serve' in win7 and it says it is listening, but there are no listening ports in netstat
<bjp> anything i can try to figure out why?
<bjp> firewall is disabled
#bzr 2013-09-18
<focus_it> hello, a noob to the bazaar system here and I'm trying to do "bzr branch xx" command, to retrieve sources for  http://releases.linaro.org/latest/ubuntu/raring-images/alip  (linaro-raring-alip-20130826-474)
<focus_it> what should i type in for xx to retrieve the correct branch?
#bzr 2013-09-19
<quicksilver> bzr: ERROR: Unable to delete transform temporary directory ......./.bzr/checkout/limbo
<quicksilver> how odd.
<fullermd> Obviously, it couldn't go THAT low.
<quicksilver> :)
<quicksilver> it then suggested I look in that directory for any files I wanted to keep
<quicksilver> there was nothing there at all
<quicksilver> except .DS_store which is always everywhere
<vila> quicksilver: eerk, no, .DS_store is only where you look with your Finder
<vila> and bzr is overly peeky about that limbo dir, there is a bug for that
<vila> quicksilver: workaround is empty the dir with $whatever (!= Finder)
<quicksilver> vila: it's odd because the only command I had issued was "bzr co bzr+ssh://path/to/remote"
<quicksilver> vila: and I've done that many many times before to the same remote, never seen this error
<quicksilver> it appears harmless, the working tree looks fine
<quicksilver> PS I have never looked inside that dir with the finder
<vila> quicksilver: it is generally harmless, let me find the bug
<vila> quicksilver: meh, can only find fix released or incomplete bugs, what bzr version are you using ?
<vila> quicksilver: are you the only one that can visit that directory with the finder ?
<quicksilver> it's possible that the person who pushed the remote directory had visited it in the finder on his mac
<quicksilver> nobody browses the remote directly with a mac (it's a linux machine, we don't have afp or samba running)
<vila> quicksilver: wait, is ./bzr/checkout local or remote ?
<quicksilver> local, vila
<quicksilver> it was a brandnew checkout
<quicksilver> it gave that error at point of chekcking out
<vila> quicksilver: then I'm lost :-/ The thing is: limbo and pending-deletions must be empty or bzr whines
<vila> quicksilver: the rationale was that if some bug occurred, precious files may have been left there (.DS_store is not preicous ;) so remove it and forget about the issue
<vila> a "brand new" ??? Wow, if you can reproduce that would be an annoying bug
<quicksilver> vila: yes, it was a fresh checkout into an empty directory
<Amis> HellÃ³!
<Amis> I'm checking out a project from FTP but it never finishes
<Amis> I know Bazaar does some repacking but the .bzr directory is "only" 152 MB but the network traffic while checkout out exceeds 2 GB
<Amis> And it never seems to finish
<Amis> What can I do with this?
<vila> Amis: pack the repository in the server (*not* from your client)
<vila> Amis: avoid ftp as most as you can, it's a protocol that is provided for convenience but there is no way to get good performances out of that
 * fullermd continues to dream of the day FTP is eradicated from the face of the Interweb.
 * vila thought he could avoid summoning fullermd by dismissing ftp but realized that was bound to failed ;)
<Amis> I have no real choice here since the repo is managed by someone else, meh
<Amis> I'm at 3.5 GB now, yay
<vila> Amis: something weird is going on, you're sure you're checking out not committing there ?
<Amis> Yep, checking out using the GUI
<Amis> It's doing inserting stream
<vila> Amis: first time ever ? You don't have another branch from the same repo ?
<vila> Amis: the bzr log file may give more details (bzr version will tell you where it is)
<Amis> Let me see
<Amis> Actually...
<Amis> I see a bunch of these:
<Amis> 4014.845  Adding the key (<bzrlib.btree_index.BTreeGraphIndex object at 0x02F3D5B0>, 503597, 48833298) to an LRUSizeCache failed. value 100672643 is too big to fit in a the cache with size 41943040 52428800
<Amis> By bunch I mean a few thousand
<fullermd> Totally logical.
<fullermd> After all, you can't spell "pathological" without "logical".
<Amis> Seems messed up
<fullermd> The two aren't contradictory   :)
<Amis> It seems my bzr is stuck forever
<Amis> I may not even be able to checkout this?
<Amis> Yay?
<fullermd> No, it _is_ progressing.  Just very slowly and painfully.
<Amis> The value is always the same
<Amis> Every little detail in these messages are the same
<Amis> I don't see any progress here
<vila> Amis: including 0x02F3D5B0 ?
<Amis> vila, yap
<Amis> It downloaded a 4.7 GB before I shut it down
<Amis> It's pointless
<Amis> Just as a reminder, the .bzr folder with all the history and stuff is 152 MB
<vila> Amis: remotely ? what about the local one ? (May me too late if you killed it ;)
<Amis> Huhh?
<vila> Amis: during the checkout, bzr was storing stuff under .bzr locally, but it has probably cleaned it when it died
<vila> Amis: I can't find such message in my logs of the last 3 weeks, what bzr version are you using ?
<Amis> vila, 2.5.1
<Amis> I think the repo is v2
<vila> bzr info -v <url> will confirm but then I don't know what's happening there, sorry, try filing a bug at  http://pad.lv/fb/bzr
<Amis> I'll see tomorrow, now I can an important task pending called sleeping
<Amis> Thanks for the help
<Amis> Bye!
#bzr 2013-09-20
<mgrandi> hello, i was wondering if there was a bug about bzr getting 'too many concurrent requests' on windows when your private key isn't loaded (on pageant for example)
<mgrandi> i did a google search but found only bugs that were related to other problems
#bzr 2013-09-21
<slowjoe> I'm trying to download mariadb via bzr.  It appears my problem is https://bugs.launchpad.net/bzr/+bug/1177521 - is there a workaround?
<ubot5> Error: Could not gather data from Ubuntu for bug #1177521 (https://launchpad.net/bugs/1177521). The error has been logged
<jelmer> slowjoe: looks like launchpad is down
<slowjoe> yeah, still down - bzr: ERROR: Invalid http response for https://xmlrpc.edge.launchpad.net/bazaar/: Unable to handle h\
<slowjoe> ttp code 502: Proxy Error
<NSA_> hi anyone here?
<LeoNerd> 88 people are here
<NSA_> ok,
<NSA_> the situation is that,
<NSA_> i need to have 5 projects or more, each of it uses some shared code files (classes etc)
<NSA_> the shared code is often changed
<NSA_> what then? should i have one repository or repository for each of this projects?
<NSA_> help!
<NSA_> !ops
<ubot5> Help! Channel emergency! (ONLY use this trigger in emergencies) - elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici,  jpds,  gnomefreak, bazhang,  Flannel, ikonia, maco, h00k, IdleOne, bkerensa, nhandler, Jordan_U, DJones or k1l!
<NSA_> ubot5 thanks, kid
<NSA_> ok another question
<NSA_> !ops should i create new branch after i created project?
<ubot5> NSA_: I am only a bot, please don't think I'm intelligent :)
<NSA_> ubot5 /help new branch when new project
<ubot5> NSA_: I am only a bot, please don't think I'm intelligent :)
#bzr 2014-09-16
<ElMonkey> does anybody know if bzr 2.6.0 can be installed on python 2.7?
<ElMonkey> when i try to install it to python 2.7 i get "ImportError: No module named _chunks_to_lines_py" when running bzr
<fullermd> Works fine.  Sounds like an incomplete installation of some kind (doubly incomplete, since if it's even trying that, it presumably means it can't find the pyx version)
<ElMonkey> fullermd, osx :/
<ElMonkey> works fine if i install on py2.6, but then i have to muck with the PYTHONPATH every time i want to run bzr
<fullermd> Well, you can poke around the libdir to see what's what and why it's not finding the file...
<ElMonkey> _chunks_to_lines_py is supposed to be in bzrlib as far as i can tell
<ElMonkey> but it's not there
<fullermd> Are any underscore files?
<ElMonkey> yea, one
<fullermd> Only one?
<ElMonkey> _groupcompress_py.pyc
<fullermd> % ls /usr/local/lib/python2.7/site-packages/bzrlib/_* | wc -l
<fullermd>       56
<ElMonkey> and __init__
<fullermd> I'd say that's pretty b0rked.
<fullermd> I'm probably not gonna be much help figuring why, how, or how to fix, though.  Your average monkey knows more about dealing with OS X than I di.
<fullermd> (New World monkeys, anyway.  Old World monkeys are another story; they just look ridiculous trying to use Macs...)
<ElMonkey> oh well
<ElMonkey> it would just be a fallback now, as i had to migrate off bzr
<ElMonkey> for most of my stuff
#bzr 2014-09-17
<captine> hi all.  sorry to bug.  tried google.  Am looking to use Bazaar for version control on some text files which are calculation rules used in IBM Cognos TM1.  Just have some questions on whether it will work for my use case
<captine> we have 1 windows 2012 server with a directory containing all the rules as well as other application files in the same folder. (This is a dev box).
<captine> we have 2 admins that can change rules and edit the files..  Can Bazaar track the changes by users seperately even though both admins connect on RDP to the same windows server nd work in the same folder?
<captine> I am an accountant by trade and one of the admins as the tool is a budget and forecast tool... so i am not that clued up on version control systems.  am just wanting a way to manage changes and implementation of them to production
<bsd> captine: you can use "bzr commit âauthor 'Name <email>" to change the author/committer
<bsd> It sounds like you just want something to track local changes?
<stbatduke> Hello #bzr!!  I am trying to undo a branch update, and move backwards from revision 485 to 484, for example.  When I try this with `bzr revert -r-2` or `bzr revert -r484` nothing seems to happen.  Then if I bzr commit it creates a new revision 286.  I want to step backwards completely, how can I do this?
<jelmer> stbatduke: bzr update -r484
<stbatduke> thanks jelmer!  though when I now do a `bzr revno` it still says 486
<jelmer> stbatduke: it only updates the branch
<jelmer> stbatduke: you'll also need to do a "bzr revert" to update the working tree
<stbatduke> ok, so I have done the bzr update and bzr revert as follows, but it still says bzr revno is 486: http://pastebin.com/nXQ5tKiV
<jelmer> stbatduke: what version of bzr is this?
<stbatduke> 2.1.2-1
<stbatduke> from debian squeeze 6.0.9 february of 2013
<stbatduke> sortry 2014
<stbatduke>         500 http://snapshot.debian.org/archive/debian/20140211T040335Z/ squeeze/main i386 Packages
<jelmer> stbatduke: that doesn't have this feature in "bzr update" yet I suspect
<stbatduke> hmm
<stbatduke> any other way do you think to rebert backwards to 484?
<jelmer> stbatduke: create a new branch using "bzr branch -r484 ..."
<stbatduke> I unfortunately do not have access to apt-get
<stbatduke> oh! ok!
<stbatduke> Can I do that in the same location, or do I need to move some folders around also?
<jelmer> stbatduke: that will create a new branch
<stbatduke> ok cool ty
<fullermd> Er.  update doesn't update the branch.
<fullermd> If you really want to step the branch back and throw away the later stuff, you'd want pull --overwrite.
<stbatduke> oh! cool! tyty
<fullermd> (or creating and swapping branches around, as above)
<jelmer> fullermd: newer versions of update do update the branch I'm pretty sure
<fullermd> Only if there's something newer than my bzr.dev   :)
<fullermd> (well, aside from the nutsoity of bound branches, but that's a whole different kettle of skunks)
<jelmer> oh, right.. that's only in checkouts
<fullermd> Even then, I don't think it does anything with the branch with update -r.  Just the gymnastics it does with arg-less and branch syncing.
<jelmer> I think my bzr is getting rusty :)
<fullermd> That's worth extra giggles if you think back to when some people were advocating it be pronounced "buzzer"   ;)
<jelmer> haha
#bzr 2014-09-19
<marcoceppi> is bzr log -r date: still broken? I can't seem to get it to accept any values
<jelmer> marcoceppi: it is broken in some regards
<jelmer> I think that is still true
<jelmer> for more details, see the bug tracker
<marcoceppi> jelmer: I found a way around it
<marcoceppi> if use date:today and there were no commits for today, you get an error
<marcoceppi> I ended up just looping through the date range I wanted and ignored bzr errors
<jelmer> marcoceppi: I think bzr log -rdate: works best for date ranges
<jelmer> since a specific day just translates back to a timestamp
#bzr 2015-09-17
<vegibione> Hi there ! Might be a stupid question butâ¦ I could I plugin an authorization mechanism into the "bzr serve" command. This would ask an external service if a user/key is allowed to push/pull to the repo/branch. Any help welcome!
<spiv> vegibione: yes, it should be possible to write a plugin that does that
<spiv> I don't recall how tricky it is.
<vegibione> A plugin. OK, because I've tried with hooksâ¦ and you cannot get all the information you want from them. And apparently, they are not called where I would like them to be called from ! :-(
<vegibione> I haven't figured out yet the class/function to modify  to get the user, the branches and the "action". The logic isn't yet clear to me.
<vegibione> mmmâ¦ no real documentation on bzr plugins. Thx anyway, I'll keep on looking.
#bzr 2015-09-18
<OnkelTem> Hi all
<OnkelTem> Why I can't apply a patch created with 'bzr diff'?
<OnkelTem> I'm applying with 'patch p1 < patch'
<OnkelTem> -p1
<OnkelTem> it says: can't find file to patch at input line 4
<OnkelTem> Oh fuck, why p1 :) p0!
<OnkelTem> works!
<OnkelTem> sorry
#bzr 2016-09-21
<Shentino> I think the perfect VCS would be git's branching and merging logic combined with bzr's flexibility and ability to handle directories as first class objects
#bzr 2017-09-21
<saigkill> Hello. I provide a file on https://bazaar.launchpad.net/~sascha-manns-h/bzrmk/trunk/view/head:/bzr.mk. From time to time i update it. Now i want to implement an autoupdate, so the cripts downloads the latest version of itself on bzr. What is the best way to wget the latest version from the shell?
<saigkill> The file should be in raw.
