#bzr 2008-05-19
<spiv> Peng: you can use branches to do the same thing as looms, but it's a lot more convenient with looms.
<Peng> Okay.
<spiv> igc: https://bugs.edge.launchpad.net/bzr/+bug/230550
<ubottu> Launchpad bug 230550 in bzr "bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2" [Critical,Confirmed]
<igc> bbiab
 * igc lunch
<lifeless> hey guyes
<lifeless> spiv: ah good, you found the bug report :)
<igc> hi lifeless
<spiv> lifeless: yep :)
<lifeless> spiv:  -> food, but happy to discuss later if you need to chat about it
 * igc pick up kids - bbian
<lifeless> spiv: back; so how is that bug going ?
<spiv> lifeless: _SmartClient._base is getting out of sync with _SmartClient._medium's URL
<spiv> lifeless: so it appears that the client/medium sharing logic in RemoteBzrDir isn't quite right.
<lifeless> spiv: excelennt; that was my suspicion :)
<vila> lifeless: http://paste.ubuntu.com/13090/
<vila> Note that the http benchmark spend 212 seconds waiting for a 502 Bad gateway. So subtract that.
<vila> After the substraction I can't see huge differences so I'm wondering about wether there is such a discrepancy between sftp and http.
<uniscript> how do I bzr ignore .svn directories?
<vila> In other words, either the kenisson (sp?) experiment was flawed or I need better info on how to reproduce it.
<bob2_> "bzr ignore .svn" doesn't cut it?
<uniscript> I get errors with the bzr-svn plugin
<uniscript> with bzr add .
<uniscript> tries to do a PROPFIND
<uniscript>  bzr add --dry-run -v .
<uniscript> bzr: ERROR: libsvn._core.SubversionException: ("PROPFIND request failed on '/svn/repos/keith/DocCharConvert/trunk/DocCharConvert'", 175002)
<spiv> vila: you mean Kinnison?
<vila> spiv: yeah! Thanks. Thanks for your review and invalidating my bug report too ;-)
<vila> Kinnison: apologies for the typo, I need another coffee :)
<spiv> vila: You're welcome :)
<spiv> vila: that's the easy part compared to actually fixing a bug :)
<spiv> vila: I had a quick look at it when it was reported and couldn't see what was needed, but you made the solution look pretty easy.
<vila> spiv: yeah, I had a wtf moment when realizing that _post wasn't calling _raise_curl_http_error and then another when I realized that _post wasn't using accepted_errors, that made the bug quite subtle
<vila> but overall, I'm gulty of not working more on the hpss ;-)
<spiv> If _post isn't reusing stuff that it should, then it would be great to fix that :)
<poolie> i'm going to do a couple of reviews of ian's work then call it a day
<vila> spiv: now that I can write tests, I may as well refactor _post, I think we shouldn't annex _post just for the smart server when we already have send_http_smart_request...
<spiv> vila: that sounds good.
<vila> ... even if that means having two send_http_smart_request implementations ;-)
<spiv> vila: although I'd be tempted to land a short-term fix first, before embarking on a bigger change
<spiv> Depends on how quickly you can do the proper fix :)
<gour> is anyone using fish shell? (there is no tab-completion for bzr :-(
<lifeless> vila: is your http cached perhaps ?
<lifeless> vila: kinnison is usually quite good ;P
<vila> lifeless: no cache here, never, pipe is big enough (which explains why I'm so bad at undersanding squid issues and high latencies problems ;)
<gour> hmm, it looks that bash-completion is also not up to date :-/
<vila> lifeless: I don't doubt Kinnison, it's just that I can't reproduce ;-)
<vila> Kinnison: when you come back, let's discuss a bit, I'd be interested in some stats via the transportstats plugin
<visik7> I'm new to vcs, I would using it to fork my project to have 2 version: one for experimental purpose the other for production
<visik7> but before this I've some questions:
<visik7> 1st: I've a so called "projects" folder
<visik7> is more logical to put the dir under a unique bzr branch or to create a bzr branch for each project ?
<Peng> The latter.
<visik7> 2nd: how can I fork my project ? should I use the switch command ?
<poolie> visik7: use 'bzr branch production experimental'
<poolie> well
<poolie> first put your code in a directory called eg 'production'
<poolie> then that will create another copy of it called experimental
<visik7> and when I need to merge some or all the code from experimantal to production ?
<jamesh> visik7: the workflow I usually use is to develop features on their own branches
<jamesh> this makes it easy to merge them on their own
<visik7> jamesh: so no split the code into 2 dirs ? becouse I would to continue to develop on devel and production as well
<visik7> maybe I've not understand your workflow
<visik7> :(
<bob2_> merging only part of one branch into another is a bit problematic (in bzr at the moment)
<Kinnison> vila: hi, bug me when you're around and we can discuss
<igc> night all
<vila> Kinnison: installing stuff on a windows machine in parallel, let's discuss
<Kinnison> okies
<Kinnison> So what are you after me for?
<vila> lifeless told me you were observing different behaviors between sftp and http regarding bandwidth usage. I can reproduce it. Can you tell me more about your experiment ?
<vila> grr, s/can reproduce/can't reproduce/
<spiv> vila: I make that typo lots too.
<vila> broadcast: read my mind while I'm using windows
<Kinnison> vila: sure, let me prep, I've reinstalled my PC since then.
<vila> ok
<Kinnison> Okay, so here's the deal, when I did the test, I was branching bzr.dev over my 'net connection which is a 10Mbit cable service from my Colo box which has plenty of bandwidth and reasonable enough CPU etc.
<Kinnison> Now, this is plain http (I.E. not smart) and it seemed to take around twice (wallclock) that of sftp
<Kinnison> I have an http_proxy set, which is on my local network to my seriously overpowered core server which runs a reasonably well configured squid
<Kinnison> Now when it's fetching the packs, the HTTP fill the 1.2MB/s
<Kinnison> But once it's on to the smaller files, it slows down dramatically
<Kinnison> As though it's not pipelining or something
<spiv> Kinnison: (btw, I've seen the opposite effect: a bug in the way some versions of squid handle "Range: 0-..." request causing fetching of data from packs to be extremely slow)
<Kinnison> This is an initial branch
<Kinnison> so presumably it fetches the whole pack, no?
<spiv> Depends on the pack.
<Kinnison> oh
<spiv> e.g. if it's shared repo
<Kinnison> standalone branch
<spiv> There will almost certainly be revisions in there you don't need, so bzr won't fetch the whole pack.
 * Kinnison runs the branch again to re-time
<visik7> bob2_: are other vcs less problematic with this kind of usage ?
<Kinnison> since last one got moosed by presence of updatedb
<vila> Kinnison: Wait ! Can you do that with the transportstats plugin installed and prefix your urls with 'stats+' ?
<Kinnison> where do I get that plugin?
<vila> as I did in http://paste.ubuntu.com/13090/
<vila> bzr branch lp:~vila/bzr/transportstats
<bob2_> visik7: I'm not sure.  jamesh was suggesting that you develop each feature in different branch, then you can choose which whole branch to merge into production or experimental
<visik7> bob2_: I think that will drive me crazy 'couse I would use this as a one man developer tool
<visik7> :)
<Kinnison> vila: running the http branch now
<vila> Kinnison: You said "seemed to take around twice (wallclock)", so we may not be dealing with bandwidth problems here...
<vila> Regarding  the transportstats plugin, it creates a '.transport_stats_for_bzr' file cumulating the operations measured, so let's try to be clean about how we use it, i.e. run your operations in different directories as much as possible
<vila> .. or alternatively and surely easier for you rename the file between each operation when necessary
<Kinnison> okay, how do I get the stats for this op?
<visik7> ops
<poolie> night
<vila> Kinnison: bzr ts-display
<sabdfl> visik7: it's actually nice to work on features separately
<sabdfl> you can merge them if two features become interdependent
<visik7> sabdfl: someone point me to hg queues
<Kinnison> vila: http://rafb.net/p/D4vKEA23.html
<Kinnison> vila: woah, that's huge latency
 * Kinnison tries the same op again, without the http proxy
<Kinnison> For reference, that took 4:29.06 wallclock to branch bzr.dev
<sabdfl> visik7: i think you'll find independent branches better, it's easier to keep track of the thread of development of each feature
<sabdfl> but, try everything
<vila> Kinnison: Beware! It's not your usual latency, that's the "real" latency as measured between when we send a request and when we receive the response, not to be confused with ping
<visik7> sabdfl: and on #git they told me that "you can cherry-pick every commit you want from one branch to another"
<Kinnison> vila: indeed, hence it seems huge
<Kinnison> considering my average ping time is 15ms
<vila> ouch, yes, that's huge
 * Kinnison tries without squid now
<visik7> sabdfl: I wouldn't to start with a vcs to realize that don't do what I look for
<vila> you can try 'bzr ts-display -v' but be prepared to receive a huge output
<sabdfl> visik7: i'm sure every tool has a way to achieve your goal
<vila> Kinnison: do you know if you use the pycurl or the urllib based implementation  ?
<sabdfl> my recommendation would be to setup a share repo, with branches in directories under that
<Kinnison> I haven't a clue, this is a fresh hardy install, with bzr.dev
<sabdfl> have a trunk branch, then branches for each of the features you are working on
<sabdfl> you can merge the features into trunk when they are ready
<sabdfl> works really well for me
<vila> try 'import pycurl', if it's there it's used
<Kinnison> vila: right, without squid in the way, it takes 2:24 wallclock with an average latency of 420ms
<visik7> sabdfl: thanks for the advice
<sabdfl> sure
<Kinnison> vila: not present
<vila> hmmm, squid playing tricks again :-/ Yet 420 seems still huge, let me check from here (you branched from lp:bzr ?)
<Kinnison> No, from my server
<vila> Kinnison: good, so you're using the urllib based one
<Kinnison> since I can monitor that and be sure it's not overloaded when I do the trials
<Kinnison> :-)
<vila> Kinnison: apache ?
<Kinnison> Zeus
<Kinnison> (very high performance web server)
<vila> Kinnison: I don't know that one :-/
<Kinnison> SFTP is 1:53.21 wallclock with 107ms average latency
<vila> let start again then, let's forget stats, there is chances that Zeus does not handle range requests as we want, try 'bzr branch -Dhttp' and mail me the relevant .log
<Kinnison> where does the .log end up?
<vila> sftp/ 1.53, http/2.24, that's more reasonable
<vila> bzr version will tell you, but on linux it's ~/.bzr.log
<Kinnison> I'll clear that down first then
<vila> you can delete it before
<vila> z:)
<vila> Kinnison: perfect
<Kinnison> branching -Dhttp now
<vila> great
<uniscript> I dimly remember there is a way to disable plugins for a bzr command?
<vila> uniscript: bzr --no-plugins
<uniscript> ta
<Kinnison> vila: http://www.digital-scurf.org/files/http-proxied-debug.log
<Kinnison> vila: http://www.digital-scurf.org/files/http-direct-debug.log
<Kinnison> vila: of use?
<vila> Kinnison: just downloaded, let me look :)
<Kinnison> for reference, that http-direct took 1:54.8 and the http proxied took 4:06.67
<vila> the proxied one seems to choke on some very big range requests, triggering a retry that is accepted
<vila> the timings appears in the log, I need more time for a more precise analysis, I'll kept you informed
<Kinnison> Okay, be sure to prefix with my name, I'll go off to do other things and i'll come back if this window goes red :-)
<vila> Kinnison: ok, it may not be today though, tonight at best (i.e. in ~10 hours)
<Kinnison> Heh, okay, I'll try and spot in scrollback
<vila> Kinnison: But one important thing already: Zeus seems to happily handle our range requests, so comparing sftp with zeus-not-proxied should be relevant in terms of relative performances *today*
<visik7> sabdfl: I realized that maybe multibranch is a little bit complicated for the task that I want to acheeve: I have a project, I want to "fork" it and develop 2 different version, but only one feature is in the new branch, I would keep the 2 branch synced is it possible ?
<visik7> sabdfl: sorry if I bother you
<jml> hi
<jml> statik: sorry about the plugin name thing.
<mwhudson> jml: hello!
<mwhudson> jml: how is europe?
<jml> mwhudson: europe is wonderful and european.
<jml> mwhudson: I wish I could spend more time here
<mwhudson> jml: are you going to get out of the city at all?
<jml> mwhudson: unlikely.
<jml> mwhudson: it'll take a fair bit of effort to make sure I see the city, in fact.
<mwhudson> jml: :/
<mwhudson> at least prague is worth seeing
<jml> mwhudson: *nod*
<mwhudson> (i hear, not been there myself)
<jml> mwhudson: it is.
<jml> mwhudson: also, I think that the pubs here rival and perhaps best English pubs
<mwhudson> heh
<jml> mwhudson: oh btw, I read _Rob Roy_ on the flight over.
<jml> I want to go to Scotland now.
<mwhudson> i've seen his grave, i think
<mwhudson> rob roy is wallace?
<mwhudson> er, scott
<jml> yes.
<lifeless> poolie: hi; I may have come across badly in my latest email
<lifeless> poolie: please forgive :)
<mwhudson> jml: scotland is well worth seeing
<ToyKeeper> visik7: You might want http://bazaar-vcs.org/Rebase
<mwhudson> the valley containing the church where rob roy's grave is is beautiful
<mwhudson> jml: http://www.lochsidecottages.co.uk/Image8.jpg for example
<jml> mwhudson: yeah. indeed.
<lifeless> visik7: all you need to do is merge from one brancht o the other on a regular bssis
<lifeless> visik7: this sort of synchronisation is the reason bzr exists :) - its core functionality
<ToyKeeper> visik7: bzr rebase and git-rebase and hg patch queues are all very similar...  but it's better not to use them if you don't really need to.
<ToyKeeper> visik7: Er, the rebase features basically help you work around certain problems...  but why work around a problem when you can avoid it entirely?
<visik7> ToyKeeper: how ?
<ToyKeeper> If you have write access to the main branch, there is probably no need to maintain a stack of patches separate from the trunk.
<ToyKeeper> But if upstream is read-only, and you have extensive local changes which upstream won't accept, 'rebase' features can help you keep your local patches up to date.
<visik7> follow my reasoning: I've a project up and running, I would develop new features on a parallel brench keep syncing with the "trunk" and I need to develop new features also on trunk
<visik7> so rebasing or merging seems the right solution isn't it?
<ToyKeeper> In that case, regular merging should be fine.  That's what bzr is best at.
<visik7> so I've not understood the difference between merge and rebase
<ToyKeeper> Merging is the normal process in bzr.  You can push/pull/branch/merge freely.
<ToyKeeper> Rebase is for pretty specific types of use.
<ToyKeeper> For example, you get foo-1.3.tar.gz, unpack it, and make changes...  then foo-1.4.tar.gz is released.
<ToyKeeper> 'foo' is not in bzr, but your patches are.
<ToyKeeper> Rebase makes it easier to take your foo-1.3 patches and make them work on foo-1.4.
<visik7> I got it
<spiv> visik7: rebase writes a new history for a branch
<spiv> visik7: which is detrimental to regular merging
<visik7> thank you guys for all those infos, time to dive into bzr
<visik7> see you soon
<brilliantnut> spiv: I see that you have a fix for bug 230550 ... does this means it goes into 1.6?
<ubottu> Launchpad bug 230550 in bzr "bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2" [Critical,In progress] https://launchpad.net/bugs/230550
<spiv> brilliantnut: yes
<brilliantnut> hmm, and is there a chance that I can try it out before?
<brilliantnut> I have a branch off bzr.dev, if it makes a difference...
<spiv> brilliantnut: it's a work in progress, but I just registered the branch in LP and linked it to that bug
<spiv> brilliantnut: http://people.ubuntu.com/~andrew/bzr/bug-230550 is the URL
<Peng> What would cause .bzr/repository/lock/foo.tmp/info to be left behind from months ago, but not be causing problems when trying to push?
<lifeless> Peng: that is a tmp file used when obtaining/releasing a lock, not an actual lock
<statik> jml, no apologies needed for the plugin name, thanks for writing a useful plugin!
<dennda> Hi. I have settings.py under version control but want to ignore it from now on, without removing it (it's values change from machine to machine.) How do I do that?
<thekorn> dennda, bzr remove --keep <yourfile>
<thekorn> bzr ignore <yourefile>
<thekorn> that's at least what I would do in such a case
<dennda> thekorn: thanks :)
<siretart> jelmer: hi. would you please commit your latest bzr_1.5-1 upload to debian to bzr.debian.org? TIA!
<dato> siretart: are you going to upload bzr to backports?
<siretart> dato: I have just merged bzrtools, and wanted to prepare an bzr upload, so yes
<siretart> preparing in the sense of building and publishing it on gluck, and having it ready to be uploaded as soon as stuff transitions to testing
<dato> ah; I've been asked a backport of 1.3.1, that's why I asked
<demod> hi
<lifeless> jam: ping
<lifeless> jam: unping, have test passing remoind me sometime to discuss write_revision_to_string with you
<vila> 1.5 has been released ? Or is it still in rc ?
<vila> lp doesn't have 1.5 series defined (hence the question)
<vila> lp doesn't have 1.6 series defined (hence the question)
<vila> grr
<beuno> vila, it's been released, yes
<vila> 1.6 serie or 1.6 milestone, I'm unclear about the vocabulary, but I need the later for marking a bug as released
<vila> beuno: thks
<pickscrape> Would I be right in thinking that 1.6 is going to be quite an exciting release?
<jam> vila: if we don't have 1.6 marked, I'll go do it
<jam> we certainly should have a milestone for it
<jam> and possibly a release series
<vila> jam: thanks
<jam> vila: we now have both a release series and a milestone for 1.6
<vila> jam: faster than light ;-)
<jam> In the past, a lot of milestones were based on 'trunk' rather than a specific release series, but the last few have been on the series
<jam> so I kept it that way
<jam> vila: it isn't too hard when you've done it several times :) It is a bit tricky when you don't know where to look
<jam> (like that milestones aren't against the project, they are against 1 release series, etc)
<jam> man I hate that 'series' has no plural form, and that its singular form *looks* plural
<jam> stupid English
<pickscrape> sheep
<jam> vila: is it any better in French?
<vila> is that described in the how-do-I-make-a-new-release doc ? I'm under the impression that starting the new release is always a bit ... delayed
<jam> pickscrape: sure, but at least sheep and moose don't look plural, goose geese is always bad
<vila> jam: no, in french serie is singular, series is pluaral
<vila> plural even
<vila> but we have temps (time) which is both singular and plural
<vila> and surely a few others, my gf is far better than me in french grammar, I specialized early in computer languages grammars and forget about the rest :)
<jam> vila: time as in 'occurrence' or time as in "clock" ?
<vila> time as in clock and weather and music
<vila> :)
<jam> vila:  I always wondered about time as in weather, as spanish has the same thing (Tiempo)
<jam> Hace tiempo hay (or something like that) is how is the weather
<jam> Que tiempo hace ?
<jam> man my spanish is bad
<beuno> jam, que tiempo hace is pretty good  :)
<vila> my daughterS also suggest: nez (nose), souris (mouse), vers (rhyme)
<vila> tapis (carpet) and generally all words ending with 's' :)
<vila> gee, the things they learn at school today....
<vila> jam: funny, time passing express both the clockl and the weather for me...
<jam> vila: sure, as an English person they seem very different, but I think most Latin languages mix them
<jam> Just that "what time is it" is very different to me than "how is the weather"
<jam> In arabic, they actually ask "Which hour is it"
<jam> vila: to your earlier question, the "mark a new series" may be in the release documents, but they are also rather long
<jam> There are quite a few steps, and it is pretty easy to miss some
<jam> I think we have to register the release in about 4+ different places (freshmeat, pypi, Bazaar home page, bazaar-announce@, etc)
<jam> Also, if it isn't there I just create one
<jam> NEWS bothers me more
<jam> because you have to wait for it to merge to mainline, and then merge it back into your simple bugfix branch
<jam> or run into merge conflicts because 2 people created the new NEWS section
<vila> yeah, we have less conflicts in NEWS since we sort it inside each section, but still...
<jam> vila: right, especially after a release when all the sections are empty
<vila> "what time is it" and "how is the weather" *are* also different in french, yet, in a movie, I often saw clouds moving faster than normal used to represent some time passing, that's the image I was referring to
<vila> jam: exactly :) Got bitten recently :)
<jam> vila: that is very common in movies, but I only view it as time sped up, you can do it with people walking fast, clock hands spinning quickly, etc
<jam> actually, I think one of the downsides is that we are slightly more likely to merge something into an "old" release
<jam> when it used to conflict all the time, you would fix it and put it in the right location
<jam> now older patches can quietly claim to fix old releases
<vila> jam: Yeah, I'm always afraid of that when working in long lived branches :-/
<vila> and I'm quite surprised I never made a mistake there (or may be I did and nobody noticed :-( )
<jam> vila: I *try* to be careful when I merge. And certainly for a release we should do "bzr diff -r branch:../last-release"
<jam> One thing I actually snuck in on this release were tags for '1.5rc1' and '1.5' final
<jam> though they didn't seem to propogate to bzr.dev for some reason
<jam> propagate
<lifeless> woo
<lifeless> .revisions and .signatures in use, no more _revision_store
<lifeless> all tests passing
<lifeless> jam: quirk for you
<jam> lifeless: what was your 'write_revision_string' comment?
<lifeless> jam: in repository.get_revision_xml
<vila> go go... go  lifeless go go :)
<lifeless> jam: if you change it from using a stringIO to do _serializer.write_revision_to_string(), the non_ascii tests fail
<jam> lifeless: I *think* that is a bug in cElementTree.tostring versus ElementTree.write(f, 'utf-8')
<jam> lifeless: not sure, though
<jam> lifeless: you have to pass 'encoding=XXX' to tostring()
<jam> so I think you need
<jam> === modified file 'bzrlib/xml_serializer.py'
<jam> --- bzrlib/xml_serializer.py    2008-03-28 02:10:23 +0000
<jam> +++ bzrlib/xml_serializer.py    2008-05-19 17:36:50 +0000
<jam> @@ -87,7 +87,7 @@
<jam>          self._write_element(self._pack_revision(rev), f)
<jam>      def write_revision_to_string(self, rev):
<jam> -        return tostring(self._pack_revision(rev)) + '\n'
<jam> +        return tostring(self._pack_revision(rev), encoding='utf-8') + '\n'
<jam>      def read_revision(self, f):
<jam>          return self._unpack_revision(self._read_element(f))
<jam> lifeless: that is my guess, at least
<jam> lifeless: is get_revision_xml() used in anger anywhere? I think it used to be the basis for get_revision() but now it is defined in terms of get_revision
<gour> where can one see what do you cook for 1.6?
<gour> to, at least, smell it a bit
<lifeless> bzr.dev
<gour> lifeless: i did not mean to 'cook', just to smell ;)
<lifeless> yes,I understand
<LeoNerd> bzr tags --help     suggests a --sort=ARG  argument, but doesn't give a hint on what ARG can be
<lifeless> LeoNerd: ugh, indeed
<jam> lifeless: this is the bug with option formatting
<jam> where someone wanted a flag to always be true
<jam> but that allows "--foo" isntead of just "--sort=foo"
<jam> And the person who wrote the first patch didn't step up to fix the help formatter
<jam> so that you can get the sub-info when the setup is False
<jam> I don't remember the specific variables
<dato> the person that wrote the first patch provided an initial patch to fix the help formatter which went uncommented :P
<dato> but at this point I guess it may be time to do what somebody proposed on the list a bit ago: use value_switch=True everywhere...
<jam> dato: but that allows '--foo' which isn't what we want
<jam> bzr tags --date
<jam> rather than 'bzr tags --sort=date'
<dato> particularly, isn't what *I* wanted. I couldn't stand the idea of tags --date, so that's why I used value_switch=False, knowing the options would be undocumented...
<jam> anyway /away lunch
<TheSheep> Hello. I want to a vcs for storing versioned data in my python app. Would it be easy to import some part of bazaar and use it internally? Does bazaar require a working tree to really exist on the disk?
<TheSheep> s/a vcs/use a vcs
<jelmer> TheSheep: you should be able to use the VersionedFile API
<jelmer> TheSheep: If you use the Knit implementation it would just create two files on disk (one for the index, one for the actual data)
<TheSheep> jelmer: the thing is, I want to make the commits from different users in the app look like commits from different branches, without having to physically create a copy of the repository
<lifeless> jelmer: there is no VersionedFile api once my branch lands :P
<lifeless> TheSheep: yes you can do that
<jelmer> TheSheep: ah, ok. I misunderstood then
<lifeless> TheSheep: we do it ourselves in the test suite using MemoryTree's
<TheSheep> great
<TheSheep> thank you
<TheSheep> hmm... so memorytree.get_file will create a StringIO object, or will it actually create a file somewhere in the filesystem?
<Pilky> if I create a project on launchpad, does that automatically create a bazaar repo that I then just have to push my initial branch to?
<beuno> Pilky, you just have to push
<beuno> it creates it when you push
<Pilky> cool, thanks
<beuno> http://kubasik.net/blog/2008/05/19/bazaar-and-its-rockage/
<beuno> :)
<Pilky> beuno: I think one of the biggest benefits of bazaar is that it isn't built upon the idea that there is "one true way"â¢ of doing things
<LeoNerd> bazaar is the mechanism, not the policy
<beuno> Pilky, yes, they really got that right...
<Pilky> the fact that you can get all the benefits of centralised and all the benefits of distributed as and when you need them is pretty damn useful
<Pilky> though to be honest, having a disk image installer for OS X with a really nice background is what got me most ;)
<Pilky> I'm a sucker for the little things
<beuno> hahah
<beuno> that's the benefits of a great community  :)
<gour> can one use some of launchpad features by not sharing the code? we would like to work on something before opening it to the public...you know that: "premature forking is the root of all evil " :-)
<beuno> gour, well, can can *not* upload the code
<beuno> I don't know how that works along the lines of policy, but it's certainly possible
<gour> ok, then we might wait a bit before using launchpad by using our own roundup tracker
<beuno> gour, if it's going to be open source, I don't see a problem with it at all
<Pilky> hmm, ok, I think I might be a little confused by --no-trees... my branch doesn't seem to want to let me do anything
<gour> beuno: it will be, of course, open-source, most probably GPL
<Pilky> what exactly is the benefit of --no-trees, besides being able to put branches in branches?
<beuno> gour, than I'd say go for it
<gour> Pilky: i read in the user-reference about using --no-trees and then switching checkouts around
<gour> beuno: cool. thanks
<Pilky> ah, I think I understand it now, --no-trees is for when you're not working on something, just when you're hosting it and don't need the extra editing related stuff
<sabdfl> Pilky: yes, exactly
<sabdfl> on my laptop, i have a directory ~/foo/ which is a repository of branches of foo
<sabdfl> so ~/foo/trunk and ~/foo/feature1 and ~/foo/feature2
<sabdfl> and each of those branches has all the files in it
<sabdfl> so i can just cd into the branch, and work / hack / merge / commit
<sabdfl> on a server, i have a repo ~/foo-storage/
<sabdfl> and i have setup my ~/.bazaar/locations.conf so that i can automatically push a branch to the server
<sabdfl> just cd ~/foo/feature1; bzr push
<sabdfl> and it automatically goes to the server ~/foo-storage/feature1
<sabdfl> and creates that branch on the server if it does not yet exist
<sabdfl> but on the server i don't need the "working directory"
<sabdfl> just the revision history
<sabdfl> so that's a --no-trees repo
<sabdfl> make sense?
<Pilky> yeah
<sabdfl> it's really easy to setup
<Pilky> was just a little confused by a bit of the documentation that says that Bazaar recommends using --no-trees, but looking at it now I see that it relates to shared repositories
<sabdfl> in ~/.bazaar.conf:
<sabdfl> [/home/mark/foo]
<visik7> good evening
<sabdfl> public_branch = bzr+ssh://server.my.com/home/mark/foo-storage
<visik7> I can't figure out the difference between init and init-repo
<sabdfl> push_location = ï»¿bzr+ssh://server.my.com/home/mark/foo-storage
<visik7> I've a project without any vcs
<sabdfl> push_location:policy = appendpath
<sabdfl> and voila
<Pilky> sabdfl: cool, thanks
<sabdfl> np
<Pilky> visik7: I had that problem yesterday, let's see if I can explain it
<sabdfl> visik7: init-repo gives you a shared repo
<sabdfl> go ahead Pilky :-)
<gour> Pilky: see this "Another possible use for a checkout is to use it with a treeless repository containing your branches, where you maintain only one working tree by switching the master branch that the checkout points to when you want to work on a different branch."
<visik7> Pilky: you have my attention
<Pilky> visik7: if you use init-repo it creates a shared repository for all revision info
<Pilky> then you use init to create a branch
<Pilky> and essentially all that is stored in that branch are the revision numbers
<Pilky> which reduces disk space and improve performance
<visik7> Pilky: so if I need to devel my proj splitting and merging a repo is better than a branch
<Pilky> well, no, you're developing in a branch, the repo is just a sort of efficient container for many branches
<sabdfl> if you will have lots of branches of the same code, then use a shared repo
<sabdfl> make a directory structure like this:
<sabdfl>  - repodir
<visik7> but if I've already started a branch how can I import it into a repo ?
<sabdfl>     - branch 1
<sabdfl>     - branch 2
<sabdfl>     - branch 3
<Pilky> visik7: branch it off into the repo
<sabdfl> that's each
<sabdfl> mkdir ~/my-repo
<sabdfl> cd ~/my-repo
<sabdfl> bzr init-repo
<sabdfl> then bzr branch ~/path/to/branch branch
<sabdfl> you will then have:
<sabdfl>  ~/my-repo
<sabdfl>    [this is where the revisions are all stored, shared, in .bzr]
<sabdfl>  ~/my-repo/branch
<sabdfl>    [this is where the working files for this branch are]
<sabdfl> and you can make a second branch by going:
<sabdfl> cd ~/my-repo
<sabdfl> bzr branch branch new-branch
<visik7> 'couse I've already branched by project than rebranch and devel new features but outside of a repo
<visik7> now I need to branch both inside the repo ?
<sabdfl> (eek, calling that first branch "branch" was bad)
<sabdfl> the first time you branch "into" a repo, it copies all the revisions into the repo store
<sabdfl> from then on, each new branch just re-uses the previous revisions for everything that's common
<sabdfl> which is most of history, usually
<sabdfl> say you have a project with 1000 commits
<sabdfl> and you make a new branch, with 10 extra commits
<sabdfl> that's only 1% "new"
<sabdfl> so it makes sense to share history
<visik7> yes yes I got it
<visik7> but the problem now is that I've 2 branches of a project outside of a repo
<visik7> :(
<Pilky> visik7: I don't see any problems with branching both into the repo
<Pilky> you just need to change the default merge location for when you merge back together
<Pilky> so that you're merging back to the copy in the repo, not the one outside of it
<visik7> ops
<visik7> how can I undo a merge ?
<beuno> visik7, bzr revert
<pickscrape> As long as you haven't committed yet...
<beuno> actually, bzr revert --forget-merges
<visik7> fiu
<radix> --forget-merges is only if you don't want to revert the changes to the files that the merge made
<beuno> yes, if you already committed, then you'll have to specify to which revision to revert  (bzr revert -r -1 would be the last revision)
<beuno> radix, oh?  that *doesn't* revert the changes made?
<radix> beuno: right. the point of --forget-merges is that it *only* forgets the metadata about the merge, while keeping the changes to the files.
<beuno> radix, hrm, I wonder if that's the best name for it...
<visik7> I'm really really new to vcs concepts, I was expect some question when I run a merge, instead it do all the work but what really a merge do ?
<visik7> a part from coping files ?
<Pilky> visik7: well, if there are no conflicts then it should perform the merge for you
<Pilky> which merges directories, but also the files themself
<Pilky> say you edited line 5 of a.txt in one branch and then line 20 of a.txt in another branch
<Pilky> when you merge them it will try to put the new stuff in line 5 and line 20 into a.txt
<radix> visik7: it does more than just copying. It "merges" in all the changes made in another branch, without overwriting other changes that have been made otherwise.
<Pilky> of course, if you were to edit line 5 in both branches and try to merge, you'd get a conflict as there are two new bits of data and the VCS doesn't know which to choose
<visik7> anyway it's request to manually check if everythings works as expected right ? 'couse it can't be aware of what my code relies  on
<Pilky> in this case you'll have to choose yourself and then resolve it
<radix> visik7: This is why bzr doesn't automatically *commit* the changes when you merge --
<radix> visik7: you have a chance to review the changes with "bzr diff" before running "bzr commit".
<visik7> good, clear
<mtaylor> bzr: ERROR: Invalid revision number 447
<mtaylor> when pushing a just-merged branch back to launchpad
<mtaylor> what does that mean?
<mtaylor> nm - I think it was a local hook
<mwhudson__> mtaylor: interesting, we've had a few branches with that problem
<mtaylor> mwhudson: oh, ok. then it _wasn't_ my fault :)
<mwhudson> mtaylor: can you check 'bzr revno' vs 'bzr revision-history | wc -l' ?
<mwhudson> they should give the same number
<mwhudson> mtaylor: well, maybe it was :)
<mtaylor> mwhudson: they equal
<mwhudson> mtaylor: oh good
<mtaylor> then it was my fault
<mwhudson> it's possible
<mwhudson> mtaylor: which branch?
<mtaylor> mwhudson: lp:ndb-connectors
<mtaylor> gah
<mtaylor> lp:ndb-bindings
<mwhudson> hm, branch on lp seems ok too
<mwhudson> so i don't know what you did, but it doesn't seem to be related to our mystery branch problem
<mwhudson> good news for you :)
<mtaylor> yay!
<schmichael> just upgraded to 1.5 and a commit seems to be frozen on pre_commit hooks (stage 3/5)
<schmichael> afaik i have no pre_commit hooks
<schmichael> anybody know where i should start looking to fix this?
<schmichael> i hit ctrl-c, and it seems to have committed just fine
<schmichael> now bzr push appears frozen (ssh+bzr protocol, bzr 1.5 on the server as well)
<schmichael> i had also run bzr upgrade on both branches... perhaps thats the problem?
<LaserJock> jelmer: around?
<jelmer> LaserJock: hi
<LaserJock> jelmer: I'd like to upgrade my bzr/bzrtools version to the bzr PPA
<LaserJock> but bzr-svn doesn't seem to be ready
<LaserJock> can I get bzr-svn from a bzr branch instead?
<schmichael> argh!  i'm trying to commit with the old copy of my repo, and it still doesn't work
<schmichael> what have i done to break bzr 1.5? :(
<jelmer> LaserJock: yes, just use the 0.4 branch
<schmichael> hm, i have bzr-svn and bzr 1.5 installed... could that be the problem?
<jelmer> schmichael: that shouldn't matter
<jelmer> do you have any other plugins installed?
<schmichael> any package that starts with bzr- in debian sid
<schmichael> dbus, email, gtk, pqm, rebase, svn, tools
<schmichael> i probably only use gtk, svn, and tools though
<schmichael> huh, it appears my push did succeed
<schmichael> well, i guess everything is working well enough
<schmichael> i just have to hit ctrl-c to kill commits at the pre_commit hook stage
<schmichael> for pushing, i guess just count to ten and hit ctrl-c
<schmichael> i'd love to file a bug but i don't have any clue where to even start diagnosing this
<beuno> schmichael, you downloaded the bzr 1.5 tarball?
<schmichael> beuno: using debian sid packages on my desktop and easy_installed 1.5 tar ball on my etch server
<schmichael> bzr push on my desktop shows 'Using saved location ...', the doesn't-update-working-copy warning, then '/ (0,0)' displays briefly
<schmichael> that disappears and it just hangs
<schmichael> the push has already completed (its on the server), so i just hit ctrl-c to exit
<beuno> schmichael, can you take a look at the ~/.bzr.log?
<beuno> there might be some information there
<schmichael> beuno: thanks for the tip, this looks revealing: http://pastebin.com/m310f07c6
<schmichael> seems the dbus plugin is to blame?
<LaserJock> hmm, can you use bzr-svn to separate svn branches into separate bzr branches in a shared repo?
<beuno> schmichael, yes it is  :)
<schmichael> beuno: removing bzr-dbus fixed it!  thanks!
<jelmer> LaserJock: yes
<jelmer> schmichael: please file a bug
<schmichael> jelmer: with debian?
 * schmichael hates debian's bts
<beuno> schmichael, you're welcome  :)
<beuno> jelmer, is a bug in order?  he's not using bzr from the debian repo
<LaserJock> jelmer: I'm trying  bzr svn-import --all --trees <svn repo>, would that work?
<schmichael> beuno: i am actually
<schmichael> locally its from debian sid
<LarstiQ> schmichael: the easy_installed one?
<schmichael> LarstiQ: nope, that one works fine (no dbus plugin installed on the server)
<schmichael> sorry for the confusion
<schmichael> its only on my debian sid desktop using debian's bzr 1.5 packages
<jelmer> LaserJock: yes
<LaserJock> jelmer: how do I then update my branches? bzr pull ?
<LaserJock> I'm a little confused as to the relationship between svn-import and just using bzr branch <svn repo>
<jelmer> LaserJock: yes
<jelmer> LaserJock: think of "bzr svn-import" as a series of "bzr branch" commands
<LaserJock> ahhh
<LaserJock> jelmer: wow, that's pretty sweet
<LaserJock> jelmer: is there a way to update the whole shared repo?
<jelmer> LaserJock: only the existing branches in the repo
<jelmer> "bzr multi-pull"
<jelmer> although "bzr svn-import" should work incrementally as well
<LaserJock> yeah, ok I think this is perfect
<LaserJock> I won't be pull'ing tags and usually only one branch at a time anyway, but multi-pull is just what I was looking for
<poolie> good morning
<jam> morning poolie
<beuno> mornin' poolie
<poolie> jam, hi, we were going to talk now iirc
<poolie> hello beuno
<jam> poolie: I'm sure you're right, I should get this on my schedule :)
<jam> poolie: I have skype, and I'm ready when you are
<visik7> morning ?
<poolie> morning visik7
<visik7> where are u ?
<poolie> sydney
<visik7> cool I was there last summer
<visik7> but too much one way only roads for my liking
<TheSheep> does bzr allow me to save metainformation on files? like, for example, a comment?
<mwhudson> TheSheep: no
<TheSheep> mwhudson: thanks
<beuno> TheSheep, of course, there is some potention for a plugin there...
<beuno> you might want to mail the list and see if someone catches on with it  ;)
<TheSheep> beuno: nah, it's not that important
<TheSheep> beuno: besides, my use case is far from common
<beuno> well, bzr is all about uncommon use cases, but, I won't insist
<Peng> Googlebot is having lots of fun downloading all of my knits. :)
<beuno> mueheheh
<beuno> should be interesting to see what they do with that
<Peng> It already indexes some bundle files, and occasionally people search for weird things and find them.
<LaserJock> dang, bzr multi-pull is so sweet
<igc> morning
<LaserJock> I was just going to write shell scripts to go through and update all my VCS checkouts
<LaserJock> for bzr all I have to do is cd bzr/ && bzr multi-pull
<jam> morning igc
<beuno> heya igc
#bzr 2008-05-20
<igc> so my focus for today is reviews, namely poolie's ones on LockableFiles and jam's ones on graph ops
<poolie> igc, any opinion on 'agile' vs 'adaptive version control'?
<igc> poolie: I'm ok with Agile version control
<beuno> agile seems a bit complicated for non-english speakers, doesn't it?
<igc> I prefer adaptive but that's because I wrote a blog article on what that is :-)
<beuno> agile is a good word, but most people won't know what it means
<beuno> might not be a good reason to reject, but I thought I'd throw it out there
<igc> beuno: it means something very specific in this content i.e. the Agile Development movement
<igc> I see open source as being the next generation of process beyond Agile - there's a large focus in SCRUM/XP on all being in the same room
<poolie> i wonder if "agile" will be out of fashion in a few years
<poolie> oh well
<igc> Adaptive takes more explaining - that's true - so Agile is good enough
<igc> I don't think Agile will go out of fashion any more than OO went out of fashion
<igc> Like OO, I think it will get incorporated into most approaches over time and there will something more fashionable in a few years
<igc> poolie: Hmm - let me respond to the email and I'll plug adaptive for one last time :-)
<poolie> igc, i'm happy with either
<poolie> spiv, i thought you fixed bug 220806, but it's still marked open
<ubottu> Launchpad bug 220806 in bzr "PyCurlTransport doesn't define the _remote_is_at_least_1_2 property" [High,Confirmed] https://launchpad.net/bugs/220806
 * spiv looks
<poolie> if not you don't need to do it right now, it was just still flagged in my mail
<spiv> Oh, I see the root cause.
<spiv> The attribute is defined on SmartClientStreamMedium rather than SmartClientMedium
<spiv> Fixing that is trivial.
<beuno> vila, docs for bzr-upload committed  :)
<spiv> poolie: http://rafb.net/p/5bJz9I27.html is the fix
<spiv> poolie: is it ok with you if I merge that, even without adding tests?  We don't have any "medium-implementations" tests unfortunately :(
 * spiv sends it to the list
<libwilliam> I am having an issue with WorkingTree.get_ignore_list() and I was hoping someone might realize what I am doing wrong. I think the main problem is my lack of knowledge on Python Lists and Tuples. Here I am passing in a working tree and trying to print out the list of ignored files. http://pastebin.com/m7fb33e08
<libwilliam> SystemError: ../Objects/listobject.c:137: bad argument to internal function
<libwilliam> I end up with that error on the size function, which is making me think the get_ignore_list isn't returning a list
<libwilliam> Atleast a list in the C/Python way of being a list.
<Odd_Bloke> libwilliam: get_ignore_list returns a Python set.
<libwilliam> ok, i'm going to tweak the code for a set and see if I have any luck, thanks Odd_Bloke
<pickscrape> Is there some way to debug authentication.conf? i.e. to find out if the file is being picked up, which rules are being applied etf.
<pickscrape> etc
<spiv> libwilliam: rather than assuming get_ignore_list returns a specific type, you ought to just treat it as a generic iterable I think.
<spiv> libwilliam: see http://docs.python.org/api/iterator.html
 * pickscrape tries -Dauth, but it does nothing :(
 * spiv -> lunch
<libwilliam> ill try that out spiv, thanks
<spiv> pickscrape: have you looked in ~/.bzr.log after using -Dauth?
 * spiv -> really lunch
<pickscrape> I hadn't, but having done so I see no difference in the output...
<pickscrape> Grr. -Derror and -Dhpss are doing things, but -Dauth is doing absolutely nothing. :(
 * igc lunch
<spiv> PQM is still surprisingly slow.
<spiv> Output like this looks particularly weird: [ascii] ..._converged_merge_dir_changes(RepositoryFormat5)   OK                  86ms
<spiv> [ascii] ..._converged_merge_dir_changes(RepositoryFormat6)   OK                  88ms
<spiv> [ascii] ...erged_merge_dir_changes(RemoteRepositoryFormat)   OK               16261ms
<poolie> spiv, yes, john mentioned that this morning
<poolie> will send mail
<poolie> done
 * igc pick up kids
<poolie> igc, are you back?
<igc> yep
<igc> poolie:^
<lifeless> moin
<vila> morning all
<demod> morning
<vila> pickscrape: if -Dauth outputs nothing, it means it's not involved, what is your use case ?
<vila> beuno: you rock :)
<poolie> hello vila
<igc> poolie: you dropped out
<chandlerc> anyone able to help me with a data loss issue?
<Peng> Not me, but what's going on?
<chandlerc> i did a bzr upgrade, which failed, and upon restoring backup.bzr, bzr refuses to acknowledge the repository as existing
<chandlerc> obviously, this is extremely bad, and seems to have erased a large portion of my history
<chandlerc> =[
<chandlerc> namely, everything that didn't happen to get shoved into subversion for ohloh.net and other tools to aggregate... all the move information and a lot of the other important VCS info was in the bzr repository, along with several un-pushed commits
<spiv> chandlerc: maybe https://bugs.edge.launchpad.net/bzr/+bug/145812 ?
<ubottu> Launchpad bug 145812 in bzr "Upgrade can leave a broken repository (with backup)" [Low,Triaged]
<beuno> vila, :)
<spiv> chandlerc: is there a repository.backup in the .bzr ?
<chandlerc> yes
<spiv> But no repository?
<spiv> If so, move the 'repository.backup' to 'repository' and that is likely to fix it.
<spiv> Probably safest to manually copy the whole thing first, though.
<spiv> Just in case.
<chandlerc> is there any chance to damage? ok
<chandlerc> yea, i moved backup.bzr to .bzr hurridly assuming it would get me instantly back to a working state
<chandlerc> paying for that now
<spiv> It should be safe, but if nothing else typos are far too easy to make :)
<chandlerc> it would be _really_ awesome if --upgrade were less fragile, and the restoration process a bit more fool-proof... it appears i'm adding to the number of fools in the world here
<spiv> It'd be great if you could add a comment to that bug after you've repaired your repo.
<chandlerc> ok
<spiv> Assuming it looks like the same bug, of course.  Otherwise, file a new bug :)
<beuno> hey james_w  :)
<james_w> hi beuno. How are you?
<beuno> great video you recorded on bzr and ubuntu, congrats
<chandlerc> that bug isn't very informative sadly, so i'm not sure if its the same as what i'm hitting
<spiv> chandlerc: fair enough, file a new one then
<spiv> chandlerc: it's easy to combine them later if it turns out to be a duplicate
<beuno> james_w, pretty good, you?
<james_w> beuno: good thanks, though UDS is pretty tiring.
<james_w> the video is out?
<beuno> james_w, your first one?
<beuno> james_w, http://www.youtube.com/ubuntudevelopers
<james_w> second
<beuno> 145 views already  :p
<james_w> oh :-(
<james_w> not sure I want to watch it.
<beuno> that's a good thing, isn't it?
<james_w> it's quite embarrasing
<spiv> chandlerc: did moving that directory fix things?
<chandlerc> sorry, making copious backups
<spiv> Ah, right :)
<beuno> james_w, not at all. It's a great explanation on where Ubuntu is going package-wise, and a great plug for bzr  :)
<lifeless> poolie: igc: ping
<chandlerc> spiv: brilliant... it seems to have fixed it
<spiv> chandlerc: great!  Glad I could help.
<chandlerc> so i should file a bug asking for a better recovery process?
<chandlerc> ;]
<spiv> chandlerc: well, just for upgrade not to break, or at least fail safely.
<chandlerc> it failed safely, just with no obvious path to recover it. ;]
<chandlerc> its more of a UI bug then a functionality bug
<spiv> Well, fail gracefully :)
<chandlerc> hehe
<chandlerc> yea
<chandlerc> i'd like large and detailed instructions about what to, and not to do in the event of a failure to maximally protect the history
<spiv> Backup .bzr of the branch (and of the shared repository, if any).
<chandlerc> sorry, i meant in the error message from the failed upgrade
<spiv> Ah, right.  Well the right thing is to stop upgrade from leaving things in a damaged state.
<chandlerc> basically, i felt like i understood the recovery process, and i apparently didn't
<spiv> A message with recovery instructions might be an ok band-aid in the short term, but we really shouldn't require users to poke in .bzr.
<lifeless> spiv: is poolie are your place?
<chandlerc> that first part being the far more dangerous component... ignorence is fine, i'll come here and find wonderful people like you... it was my rash early attempt to fix it that scared me
<spiv> lifeless: not today, no
<chandlerc> fair enough
<lifeless> spiv: kk
<chandlerc> i'll just tack on a message to that bug since its already in the same ballpark
<lifeless> spiv: I want to grab him and Ian to talk about this 'is a format required' thing
<lifeless> it seems to be generating angst; and thats sad
<chandlerc> with a more tricky (but less upsetting) question, anyone around familiar with bzr-svn?
<chandlerc> got a weird assertion pushing my latest batch of changes over to the svn server
<lifeless> somewhat familiar
<chandlerc>   File "/home/chandlerc/.bazaar/plugins/svn/transport.py", line 149, in add_file
<chandlerc>     assert self.recent_baton[-1] == parent_baton
<lifeless> so presumably either the baston as been popped; or was not added
<chandlerc> ??
<lifeless> I would probably add some more logic there to try and be more precise in the error
<lifeless> baton's are callbacks used by the svn library to obtain commit messages and so on
<spiv> like 'assert self.recent_baton[-1] == parent_baton, "recent_baton: %r, parent_baton: %r" % (self.recent_baton, parent_baton)'
<chandlerc> is it because a moved A -> B, and added a new file A, within the same commit?
<spiv> (Although that probably won't be hugely revealing.)
<lifeless> chandlerc: I don't have enough to speculate on the cause yet
<lifeless> chandlerc: I wouldn't assume that that is the cause; though it may be :P
<chandlerc> assert self.recent_baton[-1] == parent_baton, "recent_baton: %r, parent_baton: %r" % (self.recent_baton, parent_baton)
<chandlerc> AssertionError: recent_baton: [<libsvn.core.GenericSWIGWrapper instance at 0x15e2ea8>, <libsvn.core.GenericSWIGWrapper instance at 0x17c7290>, <libsvn.core.GenericSWIGWrapper instance at 0x17c7248>, <libsvn.core.GenericSWIGWrapper instance at 0x17c7560>], parent_baton: 'https://inc.googlecode.com/svn/parser/trunk/test/expression_node_test.cpp'
<chandlerc> happy to keep shoving code in here. =]
<chandlerc> i can also provide access to the bzr repository if it helps
<lifeless> wheeee parent_baton is invalid
<spiv> Well, that was surprise :)
<chandlerc> expression_node_test.cpp is one of the files i added...
<chandlerc> specifically thats the A file i added, after moving the existing file of that name to B
<chandlerc> ;]
<lifeless> first step; file a bug
<spiv> I suspect the add_file call around line 255 of commit.py is missing a 'baton' parameter after the 'full_new_child_path' parameter.
<spiv> (judging from the invocation 10 lines higher up)
<spiv> But there's a large degree of guesswork in that, so filing a bug is probably best :)
<uniscript> dummy question: if I branch base to tidyup and cd tidyup, what command do I need to do to merge such that I can remove a particular revision from tidyup?
<uniscript> merge -r 80..79 ../base ?
<uniscript> (to remove r 80)
<beuno> uniscript, bzr uncommit?
<lifeless> yes
<uniscript> thanks
<lifeless> q
<poolie> lifeless: hi
<lifeless> hi
<lifeless> psting you
<vila> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<vila> <cough> some lp hacker around ? :-)
<Peng> Protocol 3 is only in bzr.dev, right?
<spiv> RIght.
<Peng> We'll have to wait for 1.6 to be released, and Launchpad to do their what, weekly or monthly upgrades, then.
<vila> Peng: could be ;-) Was kidding.
<spiv> Yeah, I expect LP will be upgraded quite soon after the 1.6 release.
<chandlerc> spiv: bug filed (#232125), would it be safe to add the baton parameter and see what happens?
<spiv> chandlerc: My guess is that it would be safe (i.e. it'd either work or fail very quickly), but to be honest I don't know.
<chandlerc> i'm willing to try it -- i just made several backups! =]
<chandlerc> and the subversion repo isn't my authoritative VCS... if it gets weird, its not a tragedy
<spiv> chandlerc: actually, looking a second time, I'm more confident that that is the problem.
<chandlerc> it makes sense
<chandlerc> especially with what is showing up as parent_baton in add_file
<spiv> So feel free to try that fix... but if it breaks you get to keep both pieces! ;)
<chandlerc> tried it, and it worked
<chandlerc> http://code.google.com/p/inc/source/detail?r=121
<chandlerc> the SVN commit successfully appears
<spiv> chandlerc: woo!
<chandlerc> i'll post the patch to the bug
<spiv> chandlerc: it's nice of jelmer to leave easy bugs for us ;)
<chandlerc> =]
<chandlerc> thx for the help spiv! =]
<gour> hi, i'm trying to 'fix' fish-shell's script to include support for bzr-completion...does every short option in bzr's help has the long one as well?
<james_w> hi gour
<james_w> I'm not sure I understand your question, are you asking whether there are any options that only have the short form?
<spiv> chandlerc: glad I could help!
<gour> james_w: yes, i've to add support for bzr-completion by tweaking some regexs
<james_w> I don't know of any options that are only short
<james_w> except perhaps the -D ones, but I'm not sure you even want to complete them.
<gour> ok. ta
<visik7> I've a problem
<visik7> I've my branch locally
<visik7> now I run bzr init-repo sftp://remotehost/path/to/repo
<visik7> and
<visik7> bzr push sftp://remotehost/path/to/repo/branch
<visik7> the dir branch is created
<visik7> with a .bzr inside
<visik7> but there are no other files
<visik7> obviously executed inside my local branch
<AfC> visik7: That is correct behaviour
<visik7> oh can I upload my branch content to the repo ?
<visik7> remote repo
<visik7> I've also bind the repo remotely
<AfC> visik7: there is a "repository" & "branch" there but not a "working tree"
<visik7> a working tree here ?
<visik7> or there ?
<AfC> there
<AfC> Locally *only* operations  combine push & update. While this is convenient and makes it Subversion like, it means that bloody well everyone trips over what you are having trouble with right now
<AfC> Because it does *not* do an update when operating remotely.
<AfC> visik7: (try this:
<visik7> so I need to setup a working tree there right ?
<AfC> $ bzr missing --line ï»¿sftp://remotehost/path/to/repo/branch
<AfC> visik7: from within your local branch and you will find that it tells you nothing is wrong)
<AfC> visik7: if you need one, yes
<AfC> visik7: see the very end of
<AfC> $ bzr help working-trees
<visik7> bzr missing --line says: Branches are up to date.
<AfC> visik7: which it could not have said if there was no branch there. You're all set.
<visik7> the help on working tree says something like copy file remotely by hand
<visik7> or something like that
<visik7> does it make sense ?
<visik7> I dunno how to setup a working tree on a remote server
<Kinnison> Morning
<Kinnison> vila: any progress with those notes?
<vila> Kinnison: not yet, sorry, I thought a bit about it though and my overall feeling is that sftp is better for *your* current setup
<vila> What I need to do to get a better understanding of the differences is to build a similar setup
<vila> Oh, of course, there is a problem with squid
<vila> my remark above was taking it out of the picture
<Odd_Bloke> visik7: Do you have SSH access to the server?
<Kinnison> vila: right. I'm happy to have bzr ignore my proxy for now.
<Kinnison> vila: But understanding why http is slower would be nice.
<vila> there is a pending bug about bzr ignoring caches anyway
<visik7> Odd_Bloke: yes
<Kinnison> vila: Does the http code interleave requests?
<visik7> Odd_Bloke: I  technically  ignore how to do ir
<visik7> it
<vila> Kinnison: no. http has a higher overhead than sftp which issue "remote file seeks" while http have to buffer all the seeks in one (or several) requests, build the canned response (server side), uncanned the response
<vila> the difference you're seeing may well be explained by the server having to can the response
<vila> Kinnison: is that enough as an answer ?
<visik7> do I need to checkout on the deploy server ?
<Kinnison> :-)
<Kinnison> It's something to think about, certainly
<AfC> visik7: yes
<AfC> visik7: (incidentally, ï»¿if you can stick bzr on the server things will work much better)
<visik7> AfC: I can't
<visik7> :(
<visik7> can I checkout on an sftp ?
<vila> I didn't check the sftp code, but from memory it can still  be optimized :)
<vila> Kinnison: what triggered your comparison in the beginning ?
<lifeless> Kinnison: oh, do you have a suqid? what *exact* version
<AfC> visik7: {shrug}
<AfC> visik7: try it and see
<Kinnison> vila: I was miffed with how long it was taking to branch/pull over http
<Kinnison> lifeless: give me a sec
<Kinnison> Squid Cache: Version 2.6.STABLE14
<Kinnison> says 'squid -v'
<Kinnison>  *** 2.6.14-1ubuntu2.1 0
<vila> Kinnison: is that still the case without using squid ?
<Kinnison> says apt-cache policy
<Kinnison> vila: It still takes longer than sftp
<Kinnison> vila: but not twice as long.
<visik7> strange behaviour running   bzr checkout trunk sftp://location/path/branch : bzr: ERROR: sftp://location/path/branch.bzr/ is not a local path.
<vila> Kinnison: indeed, so I think the relevant bug is bug #120697
<ubottu> Launchpad bug 120697 in bzr "bzr shouldn't bypass http caches" [Unknown,Fix released] https://launchpad.net/bugs/120697
<vila> well, not exactly :-/
<vila> but strongly related
<vila> visik7: os/bzr versions ? You may need to install paramiko to activate sftp support
<visik7> vila: 1.5
<vila> visik7: os ?
<visik7> ubuntu 8.04
<visik7> yes paramiko is already installed
<visik7> but
<visik7> the odd thing is that it create a .bzr inside the remote path
<visik7> but didn't upload files
<vila> visik7: Oh ! Sorry I misread. Yes, bzr can't upload working trees, you need to ssh connect there and issue bzr update
<visik7> vila: O_o
<vila> generally bzr checkout is used in the other direction to create a local working tree from a remote branch, what are you trying to achieve here ?
<visik7> vila: I've my branch on my laptop and I want to deploy the working tree remotly
<vila> visik7: what is in your working tree ? A web site ?
<visik7> yes python code
<vila> visik7: and you really want your branch to be available as part of your web site ?
<visik7> vila: no I just want to upload the code remotly make it synced with my local branch
<visik7> in a smooth way
<visik7> without sshfs remotely and cp  the code
<vila> have a look at lp:bzr-upload then, it's targeted to *you* personally :)
<visik7> it's your
<lifeless> Kinnison: http://www.squid-cache.org/Versions/v2/2.6/changesets/11996.patch
<lifeless> Kinnison: you need http://www.squid-cache.org/Versions/v2/2.6/changesets/SQUID_2_6_STABLE19.html
<lifeless> visik7: I wonder if detecting squid versions with the bug would be useful, give a warning
<lifeless> meh, sorry visik7
<visik7> Mu ?
<lifeless> vila: ^
<visik7> :)
<Kinnison> lifeless: I don't think warning will help
<Kinnison> lifeless: A lot of people don't have control of their cache versions, or are in companies or places where they are forced to go via the cache
<Kinnison> lifeless: unless you can make it a one-shot warning the first time it is encountered
<visik7> vila: I dunno how to install it  copy the dir inside .bazaar/plugins maybe ?
<lifeless> Kinnison anyhow, upgrade your squid; it will be better
<Kinnison> lifeless: heron has 2.6.18-1ubuntu3
<Kinnison> lifeless: I take it that's no good, so I'd have to go unpackaged... grr
<vila> visik7: cd ~/.bazaar/plugins ; bzr branch lp:bzr-upload upload
<visik7> cool
<lifeless> Kinnison: NMU FTW, backports etc
 * Kinnison is such a pansy-user these days
 * igc dinner
<visik7> upload
<visik7> ops
<vila> lifeless: by parsing the header: 'Via: 1.0 ennui.i.flarn.net:3128 (squid/2.6.STABLE14)' ? Ghaaaaa
<vila> lifeless: I updated the bug report though.
<lifeless> the format is specified in rfc2616
<vila> visik7: don't forget to remove your *remote* .bzr directory if you don't intent to publish it
<visik7> vila: indeed it's a django app so it's impossible to access it even if exists :)
<visik7> visik7: does it upload only changes right ?
<vila> visik7: ok. Any feedback about the plugin greatly appreciated, it's still in beta
<vila> visik7: yes, only changes
<visik7> any changes done remotely are not tracked obviously
<vila> indeed, that may even trigger bugs if you rename/move files around
<visik7> would be usefull if the plugin notice that something is changed and stop with warning errors and such things
<vila> the bug tracker is lp :)
<visik7> ;)
<vila> visik7: monitoring the remote tree will defeat the purpose of the plugin which is to upload incremental changes
<visik7> vila: just some checks with ctime
<visik7> just to not commit wrong things
<vila> visik7: or said otherwise: it helps keeping a remote tree under version control when version control is not available remotely
<vila> so doing changes on remote can't be tracked, trying to do so will involve huge bandwidth for bad results
<visik7> for a ctime ?
<vila> visik7: ctime is not enough :-)
<visik7> first line of defense
<vila> visik7: so it's part of 'bad results'
<visik7> :(
<vila> visik7: since I can't provide a robust solution to address remote changes, I prefer to provide no solution at all to avoid building false hopes or a false sense of security
<vila> the plugin use a trick: the whole remote tree is known as a whole by a revid. If that relation is broken, there is no easy way to rebuilt it. You have to download the whole tree.
<vila> But if you keep that relation, updating the remote tree is uploading only the modified files.
<vila> All you have to do is work/test/commit locally, upload. Boom, the remote site is up to date
<vila> visik7: does it make sense ?
<visik7> yes it make sens
<spiv> Argh, setting TCP_NODELAY doesn't seem to be enough to force multiple small send(2) calls to all transmit immediately.  I'm still seeing it wait for ACKs :(
 * spiv reluctantly adds some buffering to _ProtocolThreeEncoder
<fullermd> Isn't that what you expect from NODELAY?   :P
<spiv> fullermd: Hmm?
<fullermd> NODELAY means that it sends ACK's straight off, instead of holding them for a little while to see if there's more user data to ship back along with them.
<fullermd> You'd have to increase the TCP window size to have more packets in flight.
<spiv> I'm writing a total of 82 bytes in this instance.
<spiv> I'm fairly sure that fits inside the TCP window size for a freshly created loopback socket...
<spiv> I thought delayed ACKs were different to the Nagle algorithm, and "man 7 tcp" says Nagle is what NODELAY disables.
<fullermd> Ah, right.  But disabling Nagle doesn't affect whether you're waiting for ACK's; just how quickly you send your bits at a level above that.
<spiv> Right, but if Nagle is disabled, why would it wait for an ACK to send a second small packet?
<fullermd> Because Nagle is sorta "higher level" than that.
<fullermd> Nagle determines "how long do I wait to finalize this packet and pass it down to be sent".  Waiting for an ACK happens at a layer below that, where it figures out "how many packets/bits can I have inflight at once".
<fullermd> It's odd that you'd have such low limits over loopback, though.  Slow-start?  That should be auto-disabled on loopback or local nets...
<[CroX]> I'm trying to branch from a FTP, but my username has an at sign (@) in it, which causes Bazaar to fail. How can I make this work?
<spiv> CroX: URL-escape the @
<fullermd> [CroX]: URL-encode the @ (%40 I think?)
 * spiv wishes he had a copy of TCP/IP Illustrated handy...
<fullermd> Normally, mine would be about 2.5 feet from me.
<[CroX]> fullermd: Great, that seems to have worked. :) Now, to figure out why it wont see the branch..
<fullermd> Unfortunately, it's currently in storage as a side effect of my place being hit by a tornado   :|
<spiv> fullermd: Hmm, I thought slow start wouldn't be relevant when talking about so few bytes.  The initial window size is 32k, according to wireshark.
<fullermd> Yeah.  Shouldn't be relevant period over loopback; 32k sounds like a standard full window size.
<[CroX]> Wow, bazaar just worked. That's awesome. And with bare FTP even. :)
<spiv> fullermd: my naive understanding was that modulo Nagle, it was the number of unACKed payload bytes that mattered, rather than the number of individual tcp segments outstanding.
<spiv> fullermd: I guess I'm wrong :)
<fullermd> I have very vague memories that there is packet scaling hidden somewhere in there too.  But I could be dreaming.
<fullermd> It could just be a weird artifact of something on your system or something in the kernel or yada yada.  Could be worth a try in a few different situations.
<spiv> fullermd: yeah.  But if I have weird voodoo on my system, I'm probably not the only one.
<spiv> fullermd: (it's just a laptop running Hardy, after all)
<fullermd> Oh, well, a laptop.  1 packet inflight limit is a power-saving measure   8-}
<spiv> fullermd: so fixing/changing my system doesn't really help deal with the problem, I need to fix it in the code one way or another.
<fullermd> Yeah.
<fullermd> Wish my copy of Stevens were handy   :(
<spiv> Until today, I thought setting the NODELAY flag in the code was adequate, but it appears I actually have to avoid calling send repeatedly :(
<spiv> Which at least has the advantage of being definitely portable ;)
<fullermd> Yeah.  If you buffer it long enough, it's even DOS 2.1 compatible   ;)
<visik7> can I rename a branch inside a repo without drawbaks ?
<Odd_Bloke> visik7: Well, references to that branch won't be updated, but other than that it should be fine.
<Odd_Bloke> Assuming by 'repo' you mean a shared repository.
<visik7> yes
<visik7> mm dunno
<visik7> init-repo
<Odd_Bloke> Yeah.
<Peng> When using dumb http, is gzip compression enabled?
<lifeless> our data files are already gzip compressed (except for the indices)
 * Peng blinks.
<Peng> Right.
<fog> where does one find a list of allowed values in --log-format?
<fullermd> It lists them in the 'log' help.
<fog> no, it does not. there is a description and examples and that's all.
<fullermd> Sure it does, right below it; line, long, and short
<fog> it says:
<fog> --log-format=ARG    Use specified log format.
<fog> what can I put in ARG?
<fullermd>     --line              Log format with one line per revision
<fullermd>     --long              Detailed log format
<fullermd>     --short             Moderately short log format
<fog> you mean I can't create my own format? just line, long and short?
<fullermd> You can via a plugin.
<fullermd> AFAIK registering the log format will add it to the list in help.
<fog> ok, lets say that having the --log-format option _and_ the formats as options is not very intuitive.
<fog> --log-format=ARG makes you think about something like --log-format="%r %f ..."
<fog> thank you for the clarification
<fullermd> It could be a bit clearer in the help.  Seems to me we've gone aronud that a time or two in the last few years...
<Jc2k> jelmer: i have #186876 (with http://svn.gnome.org/svn/eog/) on bzr-svn 0.4.10. launchpad says fix is released.. do you want a new bug opening?
<Jc2k> jelmer: it also hits if i branch /tags/EOG_2_16_2/ rather than svn-import
<antares> Hi!
<antares> I have a question about bazaar, I'm using a central repository where I store web modules versioned with bazaar
<antares> When I start a project, I want to get some of those apps, so I do a checkout of the applications I need into the project
<antares> The project is versioned as well, but bazaar doesn't version the checkouts of the apps. Can I change this?
<antares> What I need is to version a bunch of checkouts of other applications
<fullermd>  There are 1.5 ways of doing the overall task.
<fullermd> The .5 is versioning the checkouts, which is the NestedTree stuff.  It's only .5 because it doesn't usably exist.
<fullermd> The other one is not checking them out, but merging them in, which has a different set of tradeoffs.  But you can do it.
<antares> merging? are there any docs about that?
<fullermd> (not, perhaps, as smoothly as you can when NestedTree's come in, since they also address a variant of that case)
<fullermd> Well, it's just like any other merging, except you're merging branches with no common ancestor [the first time you merge them in], so you have to explicitly give the revision range.
<fullermd> You end up with a branch with multiple initial revisions, but that's no problem.  I do it all the time.
<antares> ok, but I don't really understand what you are saying, I'm a kind of newbie in bazaar :-)
<antares> you mean using bzr pull?
<fullermd> No, using `bzr merge`.
<antares> ok, I have to read about this
<antares> So nested trees are still in development?
<fullermd> In "normal" merging, the branch you're merging is based on [an older version of] your current branch.
<fullermd> In this particular case, it's not.  So it's a kinda special case, but it all Just Works(tm) about the same.
<antares> ok
<fullermd> Yeah.  The general impression I have is that much/most of the backend support exists, but there's no frontend to work with it (which also means the backend is probably full of sharp corners)
<fullermd> It's fairly back-burnered behind other priorities.
<antares> ok
<antares> Thank you for your help, I'm gonna try
<antares> 1 more question, if I make changes to this merge directory, and then I want to commit them to the application, can I do it?
<fullermd> Yes, that's one of the tradeoffs of merging the modules in rather than having them checked out.
<fullermd> Since they're merged in, you can make and maintain local changes from the 'upstream'.
<antares> that's cool,I'm gonna try it
<gour> igc: i'm not coming anywhere with darcs2-git...i installed latest tailor and now building latest darcs with some new patches which should improve migration of larger repos...in any case, i'd say that, atm, tailor is the best 'front-end' for migrating from darcs
<igc> gour: interesting. thanks for the update
<gour> igc: darc2git produces something like http://rafb.net/p/xClKaI75.html for looong time and not coming anywhere
<igc> gour: so the beauty of the fast-import architecture is that front-ends can be written using what language makes the most sense ...
<igc> gour: I would expect that the one for darcs would be best to be written in haskell
<gour> igc: right...now i'll test tailor by converting darcs' repo into bzr
<igc> gour: hope it goes well
<igc> I'm heading off now
<gour> igc: the tailor's dev wrote me: "AFAIK it's the only tool able to translate a repo like darcs2
<igc> night all
<gour>         into something else, to date"
<gour> night
<gour> (tailor)
<gour> let's see
<TheSheep> how would I go about starting a new repository from python code? bzrlib.repository.Repository(...)?
<lifeless> jelmer: ping
<jelmer> lifeless, hi
<lifeless> TheSheep: look at bzrlib.builtins.cmd_init and cmd_init_repo
<lifeless> jelmer: in bzr-gtk, if you go to global preferences, plugins tab, the text down the bottom appears wrong
<TheSheep> lifeless: thanks!
<jelmer> lifeless, please file a bug
<jelmer> :-)
<Jc2k> jelmer: ping
<jelmer> j2ck: hi
<Jc2k> hi
<Jc2k> i have a bzr-svn bug that is already reported against 0.4.8 with "Fix Released" - i'm getting it in 0.4.10. shall i raise another bug?
<Jc2k> (https://bugs.edge.launchpad.net/bzr-svn/+bug/186876)
<jelmer> yes, please file a new one since launchpad can't split bugs
<ubottu> Launchpad bug 186876 in bzr-svn ""The file id FOO is not present in the tree" on svn-import" [Medium,Fix released]
<Jc2k> okie dokie
<lifeless> jelmer: https://code.edge.launchpad.net/~lifeless/bzr-svn/help/+merge/277
<lifeless> jam: ping
<jelmer> lifeless, thanks
<lifeless> jelmer: you will probably want to do it differently, but the concept should be clear
<jelmer> lifeless: That pretty much duplicates what's already in README
<jelmer> and adds yet another place to update the feature list, etc
<lifeless> jelmer: right; in my plugins I put less in README
<lifeless> jelmer: to put it differently, online help FTW
<jelmer> lifeless: I don't like the online help system
<jelmer> It's ok for dynamic things (commands list, formats list) since there's no real alternative there
<jelmer> for everything else I prefer just files I can browse however I like
<lifeless> jelmer: most users won't know where to find README in a installed bzr-svn package
<lifeless> jelmer: I don't want you use any system other than what you find best;
<lifeless> jelmer: but I love the online help system for making things discoverabble
<jelmer> lifeless, I'm ok with providing help topics if that helps some people
<jelmer> I'm just concerned about the maintainance overhead of having both (and the wiki)
<lifeless> I would be inclined to write a script to:
<lifeless> export the local help to the wiki
<lifeless> create the local README from a template which you fill out from the module docstring
<jelmer> yeah, that would work
<visik7> anyone know how to get commit-notify working ?
<visik7> I got it in the help
<visik7> but when I run bzr commit-notify I got this:
<siretart> jelmer: would you please commit your last bzr upload to unstable to the packaging branch?
<visik7> bzr: ERROR: unknown command "commit-notify"
<visik7> maybe becouse the registration of the command is commented
<lifeless> its not commented in my copy of gtk trunk
<visik7> in hardy is commented
<visik7> uncommenting it cause a crash
<visik7> saing:
<visik7>     from bzrlib.plugins.dbus import activity
<visik7> ImportError: No module named dbus
<lifeless> yes, it needs bzr-dbus
<visik7> oh
<visik7> stange package choices
<jelmer> siretart: done, sorry
<jelmer> lifeless: it used to be disabled because bzr-dbus wasn't packaged I think
<jelmer> lifeless: sid already has a fixed version (now that bzr-dbus is also packaged)
<visik7> jelmer: it's all packaged
<visik7> on hardy
<jelmer> visik7: that's the original reason it was disabled
<jelmer> bzr-dbus doesn't appear to be in ubuntu yet
<jelmer> actually
<visik7> jelmer: you are right
<visik7> I've the ppa repository of bzr
<visik7> :)
<siretart> jelmer: no problem, thanks!
<visik7> what commit-notify is supposed to do ?
<visik7> I change my files on a branch but doesn't popup anything
<jelmer> it should notify you of commits from the notification area
<jelmer> if you changed + committed it should show up
<visik7> mmm
<visik7> no
<visik7> :(
<jelmer> visik7: did you follow the instructions for setting up the dbus plugin?
<jelmer> visik7: ppa contains an old version of that plugin so I'm not sure if it does all the necessary setup
<visik7> jelmer: was there instructions ?
<jelmer> visik7, I don't recall, sorry
<jelmer> visik7: hmm, looks like it does the required setup already actually
<jelmer> visik7: and you've got "bzr commit-notify" running?
<visik7> yes
<jelmer> you may also have to restart dbus
<visik7> mmm
<visik7> restarting dbus was not a good choice
<visik7> but does it need to be executed inside the branch ?
<visik7> or it monitoring the bzr commit command ?
<jelmer> visik7, "bzr commit" sends a message to dbus which then propagates it on to "bzr commit-notify"
<visik7> it doesn't do anything uff
<jelmer> so no need to run it in the same branch
<visik7> anyway it doesn't popup
<yacc> If I understood that correctly, bzr is capable of pushing/pulling via ssh. And most importantly, I can use pull from the other direction instead of push?
<visik7> jelmer: dbus-monitor doesn't show any message from bzr
<jelmer> yacc, yes
<bob2> yacc: yes
<jelmer> visik7, looks like bzr-dbus isn't loaded correctly in your local bzr then
<jelmer> visik7, I'd recommend trying newer versions of bzr-dbus and bzr-gtk
<visik7> :(
<visik7> I'll wait until some newer version on ppa
<visik7> of both
<visik7> if sometimes in the feature it will happen
<jelmer> I don't update ppa anymore
<visik7> Nooooo
<visik7> :(
<jelmer> you may be able to use the package in sid though
<visik7> backporting from ibex ?
<jelmer> or request a sid->intreprid import
<nslater> how do i check the head revision of a remote bzr repos?
<visik7> jelmer: I've 0.1~bzr34-1~bazaar1~hardy1
<visik7> jelmer: on sid/ibex there is bzr35
<yacc> Ok, is it a good idea to mix bzr 1.3.1 with bzr 1.5 when interoperating?
<emgent> hello
<emgent> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eemgent/ubuntu-cve-tracker/universe-security-updates/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<emgent> some idea?
<visik7> emgent: http is readonly afaik
<james_w> emgent: did you run "bzr checkout http://bazaar.launchpad.net/%7Eemgent/ubuntu-cve-tracker/universe-security-updates/" ?
<emgent> james_w: mmh, no just a moment :)
<jelmer> yacc, yes, shouldn't be a problem
<james_w> emgent: don't, you're not supposed to :-)
<james_w> emgent: that's just the usual cause, but not the usual one.
<jelmer> visik7, yes - what about it?
<lifeless> emgent: try 'bzr update' :P
<james_w> emgent: what operation are you doing? How did you get the branch that you are working on?
<emgent> simple push
<james_w> emgent: try "bzr push --remember bzr+ssh://emgent@http://bazaar.launchpad.net/~emgent/ubuntu-cve-tracker/universe-security-updates/.bzr/repository/lock"
<emgent> now, checkout in progress
<emgent> i will try, thanks :)
<yacc> Hmmm.
<yacc> No revision control details recorded for Bazaar Bookmarks Plugin Series: trunk.
<yacc> <= where do I get then the bookmarks plugin?
<james_w> emgent: if you run "bzr lp-login emgent" then the above becomes "bzr push lp:~emgent/ubuntu-cve-tracker/universe-security-updates"
<james_w> yacc: https://code.edge.launchpad.net/bzr-bookmarks/
<yacc> ndreas@andi-lap:~/.bazaar/plugins$ bzr branch https://code.edge.launchpad.net/bzr-bookmarks/
<yacc> bzr: ERROR: Not a branch: "https://code.edge.launchpad.net/bzr-bookmarks/".
<james_w> yacc: it's not a branch, it's a webpage that lists the branches of the project
<yacc> thx.
<james_w> bzr branch lp:~luks/bzr-bookmarks/trunk
<emgent> james_w: ok solved
<visik7> is there something like a bzrweb ?
<emgent> thanks.
<james_w> emgent: no problem
<james_w> visik7: look in to loggerhead, and bzr-webserve
<lifeless> visik7: yes, loggerhead, bzr webserve  etc
<lifeless> loggerhead is probably a better bet long term (as launchpad uses it so its getting lots of care)
<yacc> What protocol does bzr assume when it gets something like user@hostname:dir ?
<yacc> I'd expect it to create /home/user/dir on hostname, but I'm somehow a directory short.
<yacc> Ok, that's a local directory ;)
<fullermd> I think it assumes you're giving it bad input   :)
<visik7> jamesh: push and pull are notified
<visik7> james_w: but local commit aren't
<visik7> ops
<radix> yacc: right, anything that doesn't have a scheme is assumed to be local, AIUI
<pickscrape> Are there decent bzr gui tools available for the Mac?
<lifeless> yacc: without a protocol it will assume local disk
<mneptok> ladies and gentlemen, #bzr has arrived. we now have an insane Finn on-channel. a prerequisite to a "real" IRC experience.
<radix> mneptok: Man, I miss the days when every IRC channel had a good, crazy Finn or two
<lifeless> liw: has import performance notiable degraded as that repository grew ?
<liw> mneptok, I don't see why it's insane to keep disk images in bzr
<lifeless> radix: watch out for the mickey's
<liw> lifeless, not that I noticed, I can instrument when I import universe
<lifeless> (My first IRC experience was in a channel called callahans)
<mneptok> liw: as long as they are encrypted, multi-petabyte images, you should be OK
<james_w> liw: it worked?
<lifeless> james_w: main did
<lifeless> james_w: 5.6Gb repository/packs dir
<liw> james_w, one repo for all source package, one branch per source package, ubuntu main: worked
<james_w> ooohhh!
<bob2> a single pack?
<lifeless> bob2: single pack repo
<lifeless> liw: how long does it take to 'bzr branch' one of the main packages?
<liw> lifeless, with the script to unpack universe sources also running, 46 seconds real time, of which 12 seconds user, 2 seconds system
<liw> lifeless, for abiword
<lifeless> not bad
<CardinalFang> Hi all.
<CardinalFang> I have two trees I want to apply a change to.  One is a superset of the other.
<CardinalFang> So, I branch from the smaller one, apply the patch, commit.  Then I branch from the other, "merge ../subset", "commit".
<CardinalFang> All that makes sense and I'm happy with it.
<CardinalFang> But, "bzr missing" only shows that merge commit message, which I didn't add a lot of description to, as there was nothing to say that wasn't in the first change message.
<CardinalFang> I /guess/ that "missing" only shows the left edge of the graph, when all my useful information is in the right edge.
<lifeless> uhm
<CardinalFang> In any case, is there a way to show what my branch has outstanding beneath that "merge" change?
<lifeless> missing shows left hand only yes
<lifeless> bzr log REMOTE -r -1
<awilkins> Missing shows both sides unless  you instruct it not to, no?
<lifeless> yes
<CardinalFang> lifeless, ah, perhaps   "bzr log -r ancestor:REMOTE.."
<lifeless> but only the left-hand edge within each side
<CardinalFang> ...but that's making some assumptions about order.
<yacc> How does one rebuild the checkout tree from .bzr?
<CardinalFang> lifeless, The use of left edge for revno ordering makes sense, but I don't see any reason to prefer it for any other operation.
<CardinalFang> It's completely arbitrary.
<lifeless> yacc: 'bzr checkout .' or you can use some 'bzr reconfigure' option, but I don't know what the option is offhand
<yacc> lessless bzr checkout . is ok.
<lifeless> CardinalFang: its sufficient yo describe what you need to pass to merge or pull to obtain the detail, and it describes the merges done so is sufficient
<gour> one can register project under lp and then have several 'products' under it?
<gour> like different components of the project
<luks> gour: yes
<gour> luks: ta
<visik7> where are the terms and conditions of launchpad usage ?
<CardinalFang> lifeless, maybe if the output of "missing" we such that I could put it in backticks and for parameters to something else, I would agree with you.
<TheSheep> sorry for all those questions, but I'm stuck again: how would I add a file to a memorytree, without actually writing that file to disk?
<CardinalFang> lifeless, Which would you like, a patch to fix the wording of "Purpose: Show unmerged/unpulled revisions between two branches.", or a patch that shows the unmerged revisions between two branches?
<gour> visik7: https://help.launchpad.net/Legal
<luks> gour: hm, looks like I was wrong. I know I created one such 'project group' myself some time ago, but I can't find a way to do it now
<abentley> lifeless: That push I was complaining about ultimately took 2394 seconds.
<abentley> That's without copying any revisions, because they were already present.
<visik7> so only opensource projects hosted on launchpad
<visik7> right ?
<visik7> just to be sure
<jam> abentley: I *think* it might be because the LP tree has a lot of ghosts, which confuse the RemoteRepository.get_parent_map() code
<jam> I'm guessing, though
<jam> abentley, lifeless: Certainly I remember looking at the debug log and seeing that it was transmitting several queries of the same length
<jam> all of them something ilke 177kB long
<jam> and that is generally upload bandwidth bottlenecked
<jam> The good was that it seemed to actually change the revision ids
<jam> the weird was that the queries were *exactly* the same length each time
<pickscrape> Is there anywhere I can go to have a look at what's 'landed' for 1.6 so far? I like to keep up with such things. I'm sad, I know...
<pickscrape> BTW my presentation went well. Unless something unforeseen happens we're going to be switching to bzr (from svk) soon.
<Odd_Bloke> pickscrape: NEWS in bzr.dev.
<abentley> pickscrape: or  "bzr log http://bazaar-vcs.org/bzr/bzr.dev --short --limit 100" to see the last 100 merges.
<pickscrape> kewl...
<abentley> jam: casual inspection suggests that latency dominates when doing those get_parent_map queries.
<pickscrape> Is there some equivalent of git's 'show' command? i.e. I want to see one revision, including log and full patch.
<LeoNerd> bzr log -r 123 ;  bzr di -c 123
<LeoNerd> The -c meaning --change.. i.e. the change introduced at 123
<pickscrape> Would anyone be opposed to a show command that does that for you more simply?
<pickscrape> (Just thinking of something fairly simple I could do mysqlf)
<pickscrape> myself. Bah, I can't type myself without typing mysqlf
<pickscrape> I suppose 'show' would be a prime candidate for a plugin...
<abentley> pickscrape: considering that there have been multiple requests to add diff display to log, "log -p -r 123" will probably do that in the future.
<yacc> Can it be that bookmarks are not support for bzr pull ?
<yacc> (lookery)andreas@andi-lap:~/customers/lookery/trunk$ bzr pull bookmark:lookery-cluster
<yacc> bzr: ERROR: Not a branch: "/home/andreas/customers/lookery/trunk/bookmark:lookery-cluster/".
<pickscrape> abentley: yes, that would do it too
<yacc> Any one here using the bookmarks plugin?
<luks> yacc_: 'bzr pull' doesn't work with custom handlers like bookmark: or lp:
<luks> it's a bug in bzr, not the plugin
<lifeless> abentley: wheeeee
<Pilky> is there meant any sort of consistent use of error codes in bzr? and if so is there somewhere where they are all listed?
<Pilky> oh wait... I see what's happened, ignore me
 * TheSheep obediently ignores Pilky 
<Pilky> heh
<visik7> is there a way to setup a working tree on a shared repository ?
<visik7> I can't figure out how
<fullermd> No, the concept is nonsensical in bzr.  Working trees only have meaning on branches.
<fullermd> (now, you could make the working tree of a branch in the root of a shared repo.  Whether that's sensible is another question...)
<lifeless> night all
<abentley> lifeless: night.
<visik7> fullermd: so a branch has a working tree right ?
<visik7> if I branch into a remote server do I need to commit every push there ?
<visik7> or there is some autocommit on push ?
<fullermd> Well, a working tree always has a branch.  A branch doesn't need to have a working tree (or it may have several)
<fullermd> Push pushes commits; you don't commit pushes.
 * fullermd crafts sentences out of as few words as possible   :)
<visik7> how can I have 2 working tree of a branch onto 2 machines ?
<fullermd> Using 'bzr checkout'.
<visik7> and then I can commit from a machine to another ?
<visik7> I mean
<visik7> push
<visik7> no ?
<LeoNerd> Anyone here on debian/unstable..? I've noticed sftp:// no longer works...
<LeoNerd> Though, bzr+ssh does
<beuno> LeoNerd, do you have python-paramiko installed?
<LeoNerd> Yes.. It always used to work... this is a recent breakage (last week or so)
<LeoNerd> bzr: ERROR: exceptions.AttributeError: 'SSHSubprocess' object has no attribute 'get_name'
<beuno> hrm, that's very odd...
<dato> LeoNerd: are you using 1.5?
<dato> I meant to ask here what was up with that, but my problem went away when I switched to 1.5
<LeoNerd> ii  bzr                  1.3.1-1              easy to use distributed version control system
<LeoNerd> ii  python-paramiko      1.7.3-1              Make ssh v2 connections with python
<dato> LeoNerd: so, upgrade bzr...
<LeoNerd> OK
<dato>     * Incompatibility with Paramiko versions newer than 1.7.2 was fixed.
<dato>       (Andrew Bennetts, #213425)
<vila> wasn't there a bug introduced in paramiko 1.7.3 but worked around in 1.4 or 1.5 ?
<vila> dato: too fast :)
<dato> that's from 1.4
<LeoNerd> Aaah yes.. that's got it, thanks.
<ollman> bzr
<weigon_> hmm, is there a nice tool to cherry pick and merge patches with a nice UI ?
<ollman> bzr
<weigon_> I can do it by hand with bzr merge -c ... yeah
<ollman> bzr
<beuno> ollman, ?
<ollman> beuno, what do you want to know?
<pickscrape> He's not a bot is he?
<ollman> what is a bot?
<beuno> if he is, he should be kicked
<ollman> he is not a bot, what ever that is
<pickscrape> Just thought it was weird that you kept saying "bzr" and nothing else.
<pickscrape> Weird.
<beuno> very
<pickscrape> Maybe it was a bot, designed to act like it wasn't. Some sort of AI experiment.
<ollman> bzr
<Pilky> .
<ollman> yes
<vila> ollman: reboot
<vila> ollman: --help
<ollman> you want help?
<Pilky> ollman: When Littlefoot's mother died in the original 'land before time', did you feel sad?
<beuno> lol
<ollman> never heard of it
<Pilky> hmm, inconclusive... we could try the tortoise problem?
<pickscrape> ollman: which is better: old ï»¿Star Wars or new Star Wars?
<ollman> the revenge of the sith is the best part
<beuno> damn, he's good
<Pilky> beuno: actually no, he's crap
<Pilky> return of the jedi is the best ;)
<beuno> hehe
<pickscrape> :)
<pickscrape> Might betray age.
<ollman> empire strikes back is the second best part
<vila> you mean the best in the second part (or is that the previous revision (trying to get back on topic...))
<Pilky> pickscrape: Age is no excuse, I wasn't even born when return of the jedi was out ;)
<pickscrape> hehe
<ollman> why do you want to talk about starwars?
<Pilky> ollman: where did you hear about bazaar?
<ollman> what the hell is that?
<Pilky> a type of fruit
<ollman> cunting hun
<beuno> ollman, Ã±
<ollman> what?
<beuno> (let's see if he's UTF-8 safe)  :p
<beuno> right, you win this round
<Pilky> ollman: where are you based?
<ollman> in Switzerland
<Pilky> what time is it there?
<ollman> 00:21
<Pilky> and why are you in this channel if you don't know what bazaar is?
<ollman> because it's interesting
<Pilky> why did you choose to come in in the first place though?
<ollman> out of curiosity
<Pilky> odd
<ollman> why is that odd
<Pilky> just find it a bit odd that someone would come in here just out of curiosity
<ollman> ok
<ollman> if you say so
<beuno> and repeating bzr randomly helped the oddness too  :)
<ollman> alright
<ollman> I like being odd
<beuno> ah, k-lined isn't normally good
#bzr 2008-05-21
<igc> morning
<beuno> goooooooood morning igc
<Pilky> igc: you in australia or something?
<igc> Pilky: yes, Brisbane
<igc> morning beuno!
<thumper> jelmer: ping
<jelmer> thumper, pong
<thumper> jelmer: lp:~jelmer/python/trunk is this still wanted?
<thumper> jelmer: it is having problems scanning
<LaserJock> jelmer: around?
<jelmer> thumper: no, should be ok to remove
<jelmer> LaserJock, hi
<LaserJock> jelmer: it's me again :-)
<LaserJock> jelmer: I'm trying to get bzr-svn going on Fedora 9
<thumper> jelmer: do you want to delete it or shall I?
<LaserJock> jelmer: when I try to use bzr-svn it gives me "Installed Subversion version does not have updated Python bindings."
<jelmer> thumper: I don't think I can, can I?
<thumper> jelmer: you should be able to
<LaserJock> I looked in the bzr-svn README about the issue, but I'd like to avoid having to build my own Subversion 1.5 if I can
<LaserJock> jelmer: I wondered if you'd had other people wondering about bzr-svn on Fedora. Surely somebody must use it
<jelmer> LaserJock: you do really need to have subversion 1.5 or 1.4 with the patch, there's no way around that
<jelmer> afaik everybody who has used bzr-svn on fedora has done the patching
<LaserJock> jelmer: ok, do you know where the patch is?
<jelmer> LaserJock, yes, it's linked from the bzr-svn wiki page
<LaserJock> doh
<jelmer> thumper: hmm, it's mirrorred so it'll just be recreated next time I run my register branches command :-/
<jelmer> thumper: I'll see if I can create a new branch from python svn and upload that
<thumper> jelmer: ok
<thumper> jelmer: lp:~jelmer/bzr-gtk/AUTHORS??
<jelmer> thumper: yeah, error in my script that did the registration :-/
<thumper> jelmer: are you going to clean up those branches?
<thumper> jelmer: https://code.edge.launchpad.net/~jelmer/ shows lots of mirror failures
<jelmer> thumper: are the failures a problem? The web ui doesn't make deleting them very easy
<thumper> jelmer: no not really a problem, it just looks messy :)
<Verterok> moin
<mrbrocoli> how do i remove a stale bzr lock?
<spiv> "bzr break-lock URL"
<mrbrocoli> awesome, thanks!
<beuno> spiv, maybe we should add that to the message that says the repo is locked?
<spiv> beuno: yeah.  I think there's even a bug about that :/
 * beuno goes look
<beuno> found it, bug #139202
<ubottu> Launchpad bug 139202 in bzr ""Could not acquire lock" error doesn't tell you how to fix it" [Medium,Triaged] https://launchpad.net/bugs/139202
 * beuno diggs into the code
<mwhudson> heh, i thought from the summary that that was probably an mpt bug
<Pilky> does it take a while for launchpad to recognise a push to it on the site?
<mwhudson> Pilky: it can take a minute or two
<Pilky> ah there we go
<LaserJock> jelmer: woot! I finally built new Fedora 9 subversion rpms and bzr-svn now loads
<jelmer> LaserJock, nice
<jelmer> would you perhaps be interested in putting them up somewhere and linking to them from the wiki?
<LaserJock> I was just thinking of that
<LaserJock> it'd be a shame for me to horde them all to myself ;-)
<LaserJock> jelmer: alright, all done, have a look at http://bazaar-vcs.org/BzrForeignBranches/Subversion#fedora-9-i386 and see if it looks ok
<poolie> jam, did you work out what was wrong with your ssh keys?
<LaserJock> unfortunately right now I can only make i386 rpms
<tolstoy> Hi Folks. I have a repo (via init-repo) with no files in it, and I'd like to create a new repo style branch (NOT in init-repo) that also has no files in it.
<tolstoy> Sort of like I had "branched" from the original, then "pushed" elsewhere. Possible?
<tolstoy> I don't see a --no-tree option on a lot of these things.
<mwhudson> yeah, i think that must be possible but not necessarily from the command line
<tolstoy> Ah.
<tolstoy> Hm.
<mwhudson> probably easy-ish to do it in a plugin
<mwhudson> how badly do you want it? :)
<tolstoy> I just have a bash script. Running it against the output of a cvsps conversion to arrange the repo how I want it.
<tolstoy> So it's not really worth it.
<tolstoy> I can just "branch" to a staging area, then from there, "push" it to the "source-of-truth" area.
<tolstoy> Hm. Can I do a push from a repo with just a .bzr in it and end up in the same place?
<tolstoy> I think that works, actually.
<tolstoy> Yep!
<mwhudson> yes
<tolstoy> Faster, too.
<mwhudson> you can also do a regular branch, then 'bzr remove-tree' i think it is
<mwhudson> though this is obviously a bit of a waste of effort :)
<tolstoy> Yes. I'm glad I didn't see that earlier.
<tolstoy> My experiment here is to see if we can organize project repos by releases.
<tolstoy> Sort of ruins the shared-branch repo thing, but ah well.
<bob2> another way: mkdir foo ; bzr init foo ; bzr reconfigure --branch foo ; bzr push ~/repo/blah foo
<tolstoy> Cool.
<tolstoy> The push method (just have bash cd in and push) worked, but, alas, the branches are not consistently named.  Still, it mostly worked and was slow only on the project with 8000 revisions.
 * igc lunch
<poolie> spiv, i'm reading your patch
<beuno> poolie, lifeless, are you guys coming to DebConf after all?
<poolie> beuno: i am not, i think robert may be
<beuno> poolie, ah, ok. Because I just saw you guys didn't send a talk for bzr
<mwhudson> man, using bzr on launchpad on an old-ish os x/ppc laptop hurts a bit
 * igc pick up kids
<lifeless> beuno: poolie: I'm not as far as I know; we had discussed my going to talk but that was all
<beuno> lifeless, well, you can still organize one or two BoFs
<beuno> are you registered?
<lifeless> no
<beuno> au, I suppose you don't need to get sponsored anyway
<beuno> well, if you do decide to come, let me know and I'll do as much as I can to help out
<lifeless> unless canonical actively wants me to go, I doubt I will at this point
<beuno> well, poolie, ball's in your court now  :)
<keithy> any loggerhead users?
<mwhudson_> i am a loggerhead developer, for my sins
<keithy> can I serve non-public branches?
<mwhudson_> i think i need more context
<mwhudson_> before i can answer that question
<keithy> my first problem is noone can see whats in my repo
<keithy> secondly I have two private clients
<mwhudson_> i don't understand the first problem at all
<mwhudson_> 'see'?
<mwhudson_> for the second, i'd run loggerhead behind apache and do authorization type stuff in apache
<keithy> so they need to see what in my repo, but not what is in eachothers reps
<keithy> iam thinking tubogers is too much hassle
<mwhudson_> i love my isp!
<mwhudson_> keithy: it's getting late here, so if you mail the bazaar list i can try to help there
<mwhudson_> or you can try to get life out of someone else here :)
<beuno> keithy, I'll give it a try
<beuno> you want to setup loggerhead, which gives access to different branches depending on the user?
<keithy> beuno: yes thats about it
<keithy> last time I tried I gave up at turbogears
<beuno> keithy, I can't think of a straight forward way of doing that, unless you run multiple loggerhead instances in different ports, and do some magic from apache
<keithy> man
<keithy> why are bzr branches so invisible
<beuno> keithy, invisible in what sense?
<keithy> well on mac os x all you see is an empty directory
<beuno> keithy, that's because it's a hidden directory
<beuno> .bzr
<keithy> right...
<beuno> ls -a should show it to you
<keithy> so how is anyone able to know what branches you have to push to?
<beuno> keithy, either where you branched from, or you specify it once, and bzr remembers it
<keithy> arg I dont want to have to install XCode on my server
<lifeless> keithy: I would run three loggerhead instances:
<keithy> so how do I install turbogears?
<lifeless> keithy: 1) with your branches that are public, 2) with client A's branches, 3) with client B's branches
<keithy> why cant I install turbogears without having to put 2Gb worth of XCode on my server
<TheSheep> is there a simple way to find all revisions that change a particular file from python, or do I have to look through all revisions and filter them?
<beuno> that's it for me
<beuno> g'night all
<keithy> arg even fink wants xcode
<poolie> igc, thanks for the reviews!
<igc> poolie: np
<gour> igc: see https://bugs.launchpad.net/bzr-fastimport/+bug/232177
<ubottu> Launchpad bug 232177 in bzr-fastimport "Better darcs support needed" [Undecided,New]
<liw> lifeless, so... the bzr process is still running on add universe, RSS is 6.7 GiB, and strace tells me it does brk occasionally, but nothing much else
<poolie> liw, hi
<liw> poolie, greetings and salutations!
<igc> gour: thanks for putting that issue in and collecting your progress
 * igc dinner
<poolie> liw, if you're wanting to see where it's spending its time try pressing C-\ but be aware there is some chance this may make it crash
<liw> poolie, I'm going to wait for lifeless to come and do that :)
<poolie> :)
<liw> although I may have to find \ for him on this keyboard
<vila> mneptok: ping, can you have a look at bug #229076 and enlighten us ?
<ubottu> Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Fix released] https://launchpad.net/bugs/229076
<mneptok> vila: enlighten you in what regard?
<vila> what is the setup of www.gnome.org, what is the server that close the connection when the header is 'User-agent' instead of 'User-Agent' ?
<mneptok> AFAIK, "User-agent" is non-RFC for HTTP1.1
<mneptok> http://www.faqs.org/rfcs/rfc1945.html
<mneptok> http://www.faqs.org/rfcs/rfc2068.html
<mneptok> i agree it's a bit strict, but is is understandable, IMO
<vila> https://bugs.edge.launchpad.net/bzr/+bug/229076/comments/13
<ubottu> Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Fix released]
<vila> it's a bit clear that header names are case-insensitive :)
<vila> taken straight from rfc2616
<vila> anyway, the bug has been fixed, what I'd like to know is what is the server that triggered it since that the first time we encounter such strictness
<vila> well "strictness"
<liw> the reply from www.gnome.org, port 80, includes: Server: Apache/2.2.3 (Red Hat)
<liw> lifeless, update: bzr is now continuing past the place it was stuck, I didn't do anything except kill the interactive python process I had open (the one on which you counted files/tips/whatever it was)
<vila> liw: yes, but apache2 itself has always been perfectly happy with that
<liw> vila, indeed
<liw> vila, could be a (transparent) proxy somewhere, perhaps
<vila> liw: hence the question :) My 8-ball doesn't reveal that transparent one :) Which by the way could at least politely answer  with 400 or any 5xx :)
<vila> that's why I'd like to contact it to report the problem even if we fixed it on our side
<liw> yeah
<mneptok> vila: it looks like the case sensitivity is a deliberate change to the GNOME infrastructure
<mneptok> vila: it was put in place after DDoS attacks
<mneptok> it's not an optimal fix, but it works.
<lifeless> mneptok: rfc2616 - any captilisation is valid for field names
<lifeless> liw: interesting
<mneptok> lifeless: OK I'LL READ THAT AFTER I HAVE SOME COFFEE. THANKS FOR POINTING ME AT IT.
<mneptok> >:)
<liw> lifeless, now doing pool/universe/p/portsentry
<lifeless> Ok i SeE iF i CaN hElP yOu
<mneptok> :)
<liw> lifeless, I guess bzr was stuck into swapping mode for a while, but eventually got past that
<liw> lifeless, typical bzr processes are right now in the 20-30 megabyte range (for RSS)
 * vila find the coffee idea too tempting to resist
<lifeless> liw: how long is it taking for each package?
<lifeless> liw: and what is the repo size up to ?
<liw> lifeless, a couple of seconds for most small packaes
<lifeless> poolie: got a few?
<lifeless> liw: (just du -sH .bzr/repository/packs)
<liw> lifeless, 17 GiB total in the directory, with 16 GiB in one big pack file
<lifeless> liw: I think it was paused doing a full pack :P
<jml> that's absolutely no history, right?
<lifeless> yeah
<lifeless> can you time doing a branch from one of those packages to a standalone branch ?
<lifeless> liw: ^
<liw> lifeless, sure
<liw> aalib: real    0m2.370s
<liw> user    0m1.332s
<liw> sys     0m0.128s
<liw> (now I'm busy for a while)
<lifeless> liw: awesome
<vila> lifeless: the liw experiment is for all universe packages in hardy ? Sources ?
<lifeless> vila: unpacked sources, yes
<vila> awesome, 17GiB is cheap for that IMHO, is that an hint that one of my dream will come true ? Having all sources available in sync with my install ?
<liw> vila, it's still running
<vila> liw: ok, you will report here isn't it ?
<liw> vila, yup
<vila> great
<vila> lifeless: bzr-email is failing tests, I have a patch, should I send it to you or push to lp ?
<lifeless> send to the list  with Merge/bzr-email
<james_w> bzr-email/MERGE isn't it?
<lifeless> sounds plausible
<vila> james_w, lifeless: grr, so not only did I forget the /bzr-email and re-send it, but now I read that ;-/
<lifeless> :
<jml> what's the difference between Branch.pull & Branch.clone? I'm guessing that the latter preserves format and the former doesn't?
<jml> also, clone needs a bzrdir it seems -- is this right?
<lifeless> pull mirrores between existing branches
<lifeless> clone makes a new branch
<lifeless> vila: what is should_send returning ?!1
<jml> lifeless: I guess I meant in the case where a branch has just been created.
<vila> the email itself
<jml> eg.g bzr init; bzr pull <url>
<lifeless> vila: then i don't think the fix is appropriate; for starts the method is wrongly named
<vila> lifeless: hey man, I fix the tests as they are because I'm tired of adding --no-plugins to selftest :)
<lifeless> vila: well, this is what review is for no? To identify slippery-slope events  :)
<vila> LOL
<vila> lifeless: ok, you won. My daughters also found my weak point when I'm angry about them: make me laugh.
<lifeless> :)
<lifeless> seriously though, it sounds like something has creeped here, and that the method has come to have a different purpose - thats fine, but it should be trivial to give it a better name and then the test and code won't be confusing
<vila>     def should_send(self):
<vila>         return self.to() and self.from_address()
<lifeless> so it can return None or to()
<vila> +        return bool(self.to() and self.from_address())
<lifeless> 'return self.to() is not None and self.from_address() is not None' would be wrong, because '' is wrong for an email address
<lifeless> yes, thats good
<lifeless> that would avoid changing the tests
<vila> and about the name ? should_send seems to capture "check that we have enough info before sending"
<lifeless> I think the name is ok given the details we've just looke at
<lifeless> if it had been returning the email body as I thought you meant it would have been an issue
<jml> lifeless: Is there a way to pull stacked branches such that I only pull the stacked bit, and not the whole thing.
<lifeless> jml: I think you want init --stacked=url && pull in command line terms
<lifeless> jml: in library terms, doing branch.bzrdir.clone(target) should DTRT I think
<jml> lifeless: and pull as well? or just clone the bzrdir?
<lifeless> just clone
<lifeless> subsequent pulls will preserve the stacking bit and add data not accessible as one would expect
<gour> if one uses 'restricted' subscription policy on launchpad, what is restricted to other lp members?
<gour> /to/for
<poolie> gour: is this a restricted team?
<lifeless> poolie: ping
<poolie> pong
<gour> poolie: i'm reading lp feature high. document, team managament section --> subscription policies
<lifeless> gour: restricted means that you hasve to invite people
<gour> poolie: and i'm interested if i create a project, how it can be managed...in the beginning we want a smaller number of devs to discuss and commit
<gour> lifeless: that's clear. but what will be seen by non-invited people? code, bugs, blueprints?...
<lifeless> gour: it des not affect visibility of the team, just how to get into it
<gour> lifeless: hmm, so everything is visible except commit rights?
<lifeless> gour: everything is visible, full stop.
<gour> lifeless: everyone can commit his stuff in main trunk? strange...
<lifeless> gour: no
<lifeless> gour: *membership* and *visibility* are differewnt
<lifeless> gour: membership grants commit rights
<lifeless> gour: everything is visible
<gour> lifeless: ahh, ok. that makes sense
<keithy> I am trying to setup loggerhead
<keithy> its complainging about no module sqllite
<keithy> no mention of anything in the eadme's etc
<keithy> readmes*
<keithy> It hought squeak was bad at dependencies
<keithy> I am beginning to feel there is some python initiation ritual I havent been through
<keithy> or are you guys just used to things not working?
<lifeless> turbogears is rather painful; I believe the loggerhead devs such as mwhudson would like to use a different toolchain to ease the pain
<keithy> seaside?
<lifeless> in this case I can help; there are sql alchemy optional modules or something under the hood there
<keithy> so I need sql lite?
<keithy> no mention of this in the docs
<keithy> so not what do I do?
<keithy> so now what do I do?
<bob2> install pysqlite2
<keithy> how?
<bob2> how do you normally install libraries on your OS?
<keithy> download dmg and double click on an installer!
<keithy> how else
<keithy> so far I have needed c compilers
<keithy> and all sorts
<bob2> fink, darwinports?  I don't use os x, sorru.
<keithy> and they require xcode and xcode is 1G install
<lifeless> keithy: by a different toolchain I mean cleaner and more self containined python libraries
<lifeless> keithy: I suggest that you file a bug on loggerhead; I too have had trouble installing it
<bob2> is python2.5's included 'sqlite3' module the same as 'sqlite'?
<keithy> like seaside! ;p;
<keithy> lol
<bob2> it looks pretty dbapi2-y
<TheSheep> bob2: it's sqlite
<keithy> ah so it is loaded!
<keithy> I winder where it si
<keithy> I wonder where it is
<siretart> would someone please to upload bzr-svn 0.4.10 to the bzr ppa?
<liw> lifeless, 39619 seconds total run time (real time), 21 G total pack directory size, 16 G for the biggest pack file, then 1.7, 1.6, 1.2, 0.39, and then pretty smal ones
<keithy> so do I need to install sqllite3 separately?
<keithy> so fink doesnt work
<lifeless> keithy: I'm sorry I can't be more help right now, I'm in a week long sprint of meetings
<keithy> np
<lifeless> keithy: if you can put a bug/question against loggerhead in launchpad I think its likely you can attract mwhudon's attention in his workday which is GMT+12 or so
<keithy> the dependency on sqllite is already in the bugs list
<lifeless> well I am talking about docs on how to get it going largely
<lifeless> -> going for a while
<keithy> k cya
<jml> lifeless: is there a way to use the test machinery to create a branch with a specific branch format?
<lifeless> format=
<jml> lifeless: it's unclear whether that's a bzrdir format, a repo format or a branch format.
<jml> lifeless: I'm guessing there's something about the interrelation between formats that I don't get.
<keithy> sqlite3 is included in pythin, why does loggerhead want sqlite
<lifeless> jml: format='dirstate'
<lifeless> bah, I have been sucked back into IRC. let me outta here!
<jml> lifeless: feel free to talk to me IRL.
<liw> lifeless, http://files.liw.fi/temp/output.log -- I forgot to capture theoutput of the universe run, but that's the one for the main run
<keithy> after all that! loggerhead renders my hierarchical branches structure as flat!
<keithy> I am dissappointed
<awilkins> Do you just add stuff to the top of NEWS when pathcing?
<awilkins> And does a small extra option for a command count as a feature or an improvement :-)
<visik7> hi
<visik7> "This transport does not update the working tree"  means that there is another transport that support it ?
<bob2> only file://
<bob2> or ssh if you have the update-after-push plugin installed (which just does 'ssh remotehost bzr co /path'
<jml> lifeless: ping
<matkor> vila:I have noticed yours recent commit to bzr-gtk. Could you please merge https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ?
<matkor> One-line chages but close two bugs (I think). TIA, regards
<vila> matkor: better ping bzr-gtk@lists.canonical.com, it looks like I didn't really respect the process by pushing that way
<gour> if someone wants to migrate repos from darcs, no matter whether darcs-1 or darcs-2 format, and no matter how old are they, tailor is the only player which does the job atm - pull latest tailor and latest darcs. both darcs-to-git and darcs2git fails with either darcs-2 repo format or older date-format in darcs
<vila> matkor: wow, looks like your patch doesn't even appear on http://bundlebuggy.vernstok.nl/bzr-gtk/
<vila> matkor: what you should do is send it to bzr-gtk@lists.canonical.com with [MERGE] in the subject or nobody will be informed of its existence, I'm not a core bzr-gtk dev, just an occasional contributor
<gour> ...or new tailor-0.9.33
<matkor> vila: should I subscribe or can I just send e-mail out of ist ?
<vila> matkor: I don't know for sure, look at https://lists.canonical.com/mailman/listinfo/bzr-gtk
<matkor> ok tnx
<gour> igc: i updated 'darcs support' bug with latest info...
<matkor> Is it OK to send bundle intendent to merge having  target_branch: file:///home/users/matkor/src/bzr-gtk/trunk/ ? Which is checkout of http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/ ?
<vila> matkor: taget_branch yes, that's how bzr calculated it, bonus points if public_branch is set though, look at bzr help send
<matkor> vila: I got confused with:  bzr send ./ http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/ -r -3..    giving me: bzr: ERROR: No mail-to address specified.
<vila> matkor: add --mail-to bzr-gtk@lists.canonical.com
<vila> matkor: or use -o my.patch
<vila> matkor: but your public_branch is wrong, you should use *your* branch here, it's where the bundle can be merged from
<vila> errr, wait
<visik7> bob2: any possiblity to get it on bzr:// transport  ?
<vila> bzr send <where you want your patch to be applied> <where your patch have actually been applied>
<vila> matkor: ^
<bob2> visik7: not supported as yet, as far as I know
<vila> visik7: the idea is that you have working tree where you can.. work. So you need at least a shell access there, and then you can just do bzr co or bzr update
<visik7> yes I'm in the process of misusing bzr as a deploy tool :)
<visik7> 'couse I work with some pigs&dogs that puts their hands on the server so I need to track them
<bob2> ghetto workarounds include push-after-update and bzr co from cron
<TheSheep> ok, I have finished writing a storage plugin for my wiki that uses bzr repository to keep the pages and history. Would anyone want to take a look at it and maybe suggest doing some things differently?
<visik7> TheSheep: based on some web framework ?
<TheSheep> visik7: no, just wsgi
<TheSheep> the code for the plugin is here (sorry that it's Mercurial) http://sheep.art.pl/devel/dandelion/file/tip/dandelion/plugin/bzrstore.py
<visik7> :)
<visik7> ahahah
<visik7> funny
<TheSheep> I had trouble for example with getting the list of all files that were changed in a revision
<visik7> TheSheep: from the bzrlib or from the command line tool ?
<TheSheep> visik7: from bzrlib
<visik7> maybe whatching in the command line tool you got how it does
<visik7> no ?
<TheSheep> in the end I did [entry.name for path, entry in entries if
<TheSheep> entry.revision == rev_id]
<TheSheep> :)
<luks> repository.get_revision_delta or something like that
<matkor> bzr: ERROR: Please specify smtp_server.  No server at default localhost - how can I do it ?
<matkor> bzr send does not mention any option for that ...
<luks> TheSheep: working_tree.commit(message="imported existing pages", author="wiki")
<luks> er, maybe you meant committer there?
<luks> and unicode(revision.message, "utf-8")
<luks> the decoding there is wrong, it's already unicode
<TheSheep> luks: ah, I thought it stores bytes, cool
<luks> no, most things in bzrlib are unicode
<bob2> matkor: -o foo.patch, then send it using your mail client
<TheSheep> luks: isn't delta just another tree?
<luks> TheSheep: delta is the list of files that changed in a revision
<TheSheep> great
<TheSheep> I'm sure some parts of this code can cause nightmares for anyone familiar with bzrlib :)
<luks> not bzrlib relased, but you have some locking problems in try/finally there
<luks> it should be lock(); try: ... finally: unlock()
<luks> you have try: lock(); ... finally: unlock(), which might call unlock even if lock failed
<TheSheep> ah, right, so that it doesn't try to unlock when the lock fails
<TheSheep> thanks
<matkor> bob2: Thats last option, seems  $HOME/.bazaar is place where I should specify smtp server ...
<bob2> matkor: yes, ~/.bazaar/bazaar.conf - it presumably defaults to localhost
<matkor> ok .. it went ... I doubt it gets through to bzr-gtk@lists.canonical.com with strange from adress ...
<luks> usually you want 'bzr send' to just launch an external mail client
<matkor> How often http://bundlebuggy.vernstok.nl/bzr-gtk/  is updated ?
<vila> matkor: you need to set mail_client in bazaar.conf for that, smtp_server is adifferent beast
<vila> matkor: presumably http://bundlebuggy.vernstok.nl/bzr-gtk/ get the mails from bzr-gtk list so if you don't see your mail here neither does it
<matkor> vila: I do not see even my subscribe confirmation mail .. but I am postgreyed so might have delays ..
<vila> matkor: just be patient then, may be an admin need to validate your subscription,
<gour> i'm new with bzr, but somehow feel strange that bzr status reports nothing when there is no change. what do you think about something like darcs' "No changes!" ?
<Odd_Bloke> gour: I dunno, I think you'll find you just adjust to the lack of output.
<gour> Odd_Bloke: i consider that providing some output is nice HIG
<Odd_Bloke> It does provide output, a newline followed by a prompt.
<gour> well, i'm serious
<Odd_Bloke> Me too, I don't want our UI cluttered up for no reason.
<pickscrape> Just create a file and never add it. Then you'll always have output :)
<Odd_Bloke> Regardless, if you think something about bzr should be different, submitting a patch to the ML is a much better way of getting it discussed than IRC (especially as most of the core devs are probably in bed ATM). :)
<gour> pickscrape: i'm not interested for *any* output, but info that nothing changed
<gour> will do
<nekohayo> hmm. let's say I cherry pick r3..6 from some branch, and later I just "bzr merge" from it, what would happen?
<nekohayo> and if that branch has a change I don't want to incorporate ever, that means I need to always cherry-pick?
<luks> or you can merge it and revert the particular change
<nekohayo> oh, you can do that? how can you revert a past committed change?
<luks> if that change in a single commit?
<luks> is
<nekohayo> yeah, but for example 10 revisions earlier
<luks> yeah, so merge, commit the merge, and then `bzr merge -r X..before:X .` and commit the reverted change
<nekohayo> bzr merge -r150..22 ?
<nekohayo> oh -r 150..149
<nekohayo> that uncommits revision 150?
<luks> -r 150..149
<luks> or -r 150..before:150
<luks> that will revert the change from revision 150
<nekohayo> ok, thanks :)
<lelit> hi all
<lelit> I'm playing with bzr and tailor lately: it was able to migrate the whole darcs history to bzr without a glitch! :-)
<jelmer> hi lelit
<lelit> now I'm trying the other way around, and notice that bzr is *very* slow in collecting the "missing" changesets
<lelit> hi jelmer
<lelit> how's going?
<jelmer> pretty well, thanks :-)
<jelmer> lelit: Collecting missing changesets in what regard, "bzr missing" ?
<lelit> I have a local bzr.dev clone, and when I do (tailor backend does, that is) "cd /tmp/p; bzr init; bzr missing SomeSourceRepo"
<lelit> see http://progetti.arstecnica.it/tailor/browser/vcpx/repository/bzr.py#L168
<lelit> that missing_revisions() takes something more than 1h here, with 100% cpu
<jelmer> there was talk about reimplementing it using a somewhat smarter algorithm earlier
<jelmer> jam, ping
<lelit> after than, in another couple of hours the migration completes
<lelit> jelmer: ah, ok, it's a known problem then, not something wrong with that code
<jelmer> lelit: I think bzr itself only uses that particular function for the "bzr missing" command, not for anything else
<lelit> do you think there's a better way of knowing the list of csets that a "bzr pull" would fetch?
<lifeless> bzr.dev makes missing much faster
<lelit> lifeless: ?
<lifeless> john landed a patch to improve missing yesterday
 * lelit goes to update
 * lelit restarts the test
<lelit> thank you
<gour> lelit: good luck ;)
<cjean_> Hi, I'm looking for a complete tutorial explaining how to manage a decentralized workflow with gatekeeper
<jam> jelmer: pong
<cjean_> there is no much details on the current documentation
<jam> jelmer, lelit: I did land a patch yesterday that made missing better, and another that made the function missing used even better
<jelmer> jam: sorry, was wondering about your missing improvements but lifeless already replied
<lelit> jam: thankyou, I'll write here the result. It's still using 100% cpu, since 25 mins ago now...
<jam> lelit: using the latest bzr.dev?
<jam> I would really like to understand your circumstance
<jam> here, things run on bzr.dev in <10s
<lelit> tailor is doing (look at the trac URL for the function) a missing() from an empty new repo, pulling from a local bzr.dev clone
<lelit> I just want the *list* of patches, "darcs pull --dry-run" in darcs parlance
<lelit> I *must* be doing it wrongly...
<lelit> jam, and yes, updated and reinstalled current bzr.dev
<lifeless> lelit: is it possible that the repository is not locked ?
<jam> lelit: are you writing your own plugin for it?
<jam> lifeless: 'find_unmerged' would be locking the branches
<jam> I'm not sure what function he is using
<lelit> jam, see http://progetti.arstecnica.it/tailor/browser/vcpx/repository/bzr.py#L168
<lelit> it's just my tailor business :)
<jam> a Branch.missing_revisions
<jam> I don't know if that is ever used
<jam> it certainly doesn't scale well
<jam> andprobably doesn't take a lock
<lelit> what you'd suggest?
<jam> lelit: ATM, bzrlib.missing.find_unmerged(this_branch, other_branch, 'local'/'remote'/'all')
<lelit> ok, thanks alot, I'll try that way
<jam> The only place that uses Branch.missing_revisions() is one function in the test suite
<jam> lifeless: what do you think, should I just nuke the function, or should I move the 'find_unmerged' functionality over into it?
<jam> I think it *used* to be used as part of pull/push/etc to figure out if branches had diverged
<jam> Now, I think we use get_graph.().heads()
<lelit> later, ciao
<jelmer> jam: bzr-svn uses it
<lelit> so, that's *three* places :)
<jam> jelmer: well, it's a Bad(tm) function
<fullermd> Our *three* users are...   wait, I'll come in again.
<jam> we could improve it
<jam> just not sure if it is worthwhile
<jam> jelmer: what do you use it for?
<jelmer> jam: actually, never mind me
<jelmer> jam: I added a custom implementation for bzr-svn later on
<Lo-lan-do> Hi all
<jelmer> jam: it's being used from Branch.pull()
<jam> jelmer: you mean SVNBranch.pull(), right?
<jelmer> jam: yep
<Lo-lan-do> jelmer: I am under the impression that bzr-svn is slower and slower as time passes, and possibly that it's doind more and more connections to the SVN repo
<jelmer> Lo-lan-do, what version are you using?
<Lo-lan-do> Is that known and/or addressed?
<jam> jelmer: well, there is example code in Branch.update_revisions() which shows you how to do it with a Graph instead of missing_revisions
<jam> though we could arguably do something similar in missing_revisions
<Lo-lan-do> 0.4.10 + bzr 1.5, I guess
<jelmer> Lo-lan-do: in that case, it's not a known issue
<jelmer> jam: thanks, I'll see if I can steal that
<Lo-lan-do> I just did a bzr commit on a svn-bound branch for gforge, and it took 4 minutes and 40 seconds, and 276 sockets opened to the repo
<gumpa> Howdy, I've hosed my gui bazaar stuff.  Started after creating ~/.bazaar/plugins, and branching lp:bzr-gtk  and qbzr there
<jam> jelmer: any chance you could be around for a skype call tomorrow around 1900 UTC time ?
<jam> we are thinking about talking about bzr-svn in my next "This Week in Bazaar" post
<jam> and it would be nice to have your input
<jelmer> jam: yep, sounds good
<jam> jelmer: great
<jelmer> Lo-lan-do, ouch, that's wrong - please file a bug
<gumpa> now olive crashes
<jam> gumpa: did you branch "lp:bzr-gtk ~/.bazaar/plugins/gtk" ?
<jam> just to make sure it was named correctly
<gumpa> I've removed and installed bzr-gtk, removed the plugins dir, still ng
<jam> lifeless: how is UDS going, btw
<gumpa> I had changed bzr-gtk to bzr_gtk, just changed bzr_gtk to ~/.bazaar/plugins/gtk still crashes
<jelmer> gumpa: what's the error you're getting?
<jelmer> jam/lifeless: Somewhat related to Branch.missing_revisions(), any chance you can reply to https://lists.ubuntu.com/archives/bazaar/2008q2/041834.html ?
<gumpa> just did apt-get remove bzr-gtk --purge, now 'bzr qdiff' says 'Not running bzrlib.plugins.gtk, things may break'
<gumpa> and lots of 'Two plugins defined the same command:'
<jelmer> gumpa, qdiff is not part of bzr-gtk
<jelmer> bzr gdiff is
<gumpa> typo s/gdiff/qdiff
<gumpa> same messages with gstatus
<gumpa> Previously this command was registered from <module 'bzrlib.plugins.bzr_gtk' from '/home/ktenney/.bazaar/plugins/bzr_gtk/__init__.pyc'>
<gumpa> after Two plugins defined the same command: ...
<jelmer> gumpa: remove the bzr_gtk directory in ~/.bazaar/plugins
<gumpa> Fixed. You make it look so easy.  thanks
<lifeless> jam: good
<gumpa> can I apt-get install bzr-gtk to get Olive now?
<jelmer> gumpa, Olive is part of bzr-gtk
<gumpa> how do I start it?
<jelmer> gumpa, So you should already have it if you installed bzr-gtk into ~/.bazaar/plugins/gtk
<jelmer> start the olive-gtk binary from that directory
<xif> Hi. I have a file that I need to use in two code tree (two separate projects). How would I share that file among the two projects, if they're both managed with bzr?
<gumpa> jelmer great, thanks, see you
<matkor> xif: Those separate project are not self-branches  ?
<xif> matkor: nope, they're completely separate projects.
<xif> to further explain: these projects are web applications.
<xif> the file they're sharing is a Javascript library.
<LeoNerd> Hrm... Any reason why bzr doesn't ignore directories called "CVS" by default?
<NfNitLoop> LeoNerd: Heh, I've wondered that myself.
<fullermd> LeoNerd: Because the speed of add varies inversely (and significantly) with the number of ignore rules.
<LeoNerd> fullermd: Ahh... OK.
<NfNitLoop> bzr init; bzr add . ; bzr commit;   What!?  CVS/?
<fullermd> So the default set is pared down as much as possible.
<LeoNerd> Besides... bzr ignore CVS    isn't exactly difficult
<LeoNerd> It's just something I hadn't thought about and just presumed would work
<jam> LeoNerd: at one point we ignored lots of things by default
<jam> but it turned out to slow things down
<jam> when you had to check every file against 100+ possible ignores
<LeoNerd> Right
<jam> so we turned it down a bit
<NfNitLoop> Wouldn't the better solution be to fix the performance of ignore?  ;)
<jam> NfNitLoop: It isn't ignore
<jam> it is stuff like 'add' having to compare against a large list
<jam> we already use tricks to make it faster
<jam> but if you are adding 20,000 files
<jam> the overhead of each one makes a difference
<NfNitLoop> aaah.  Yeah.
<xif> OK, nobody has an answer?
<xif> doesn't BZR have something like svn:externals?
<NfNitLoop> Not that I know of, but I'm not a bzr developer. :)
<NfNitLoop> IIRC, you can check out a project within the directory of another.
<xif> OK, that might be a solution...
<NfNitLoop> but there's nothing to tie revision X of baseProject to revision Y of innerProject.
<xif> hm, this kind of sucks :/
<lifeless> jam: do you remember if we fixed the problem where commit did not notify the dirstate of the sha1 of files read in during commit ?
<lifeless> jam: sabdfl is still seeing status on large trees as 70-80% slower than hg's.
<jam> lifeless: afaik we never fixed that
<xif> OK, looks like this has been thought of before: http://bazaar-vcs.org/NestedTreeSupport
<beuno> xif, LarstiQ is working on that, but it might take a while to land
<xif> a Nested Tree "by reference" is basically svn:externals.
<vila> jam: what's that "This Week in Bazaar" post thing ? 8-)
<jam> vila: jam-bazaar.blogspot.com
<xif> beuno: good to know, that's a useful feature :)
<jam> http://jam-bazaar.blogspot.com
<jam> vila: I'm just doing a weekly blog post with statik
<jam> if you have ideas of something to talk about let me know
<jam> it is a "spend 45 minutes every week to get some publicity"
<vila> ok, reading it.
<jam> so, quick topics, nothing terribly fancy
<jam> just that we do a lot of work that doesn't get noticed because we forget to communicate ti
<jam> it
<vila> ooh, the 'my' plugin I wanted to code for ages exists and is called 'bookmarks' :)
<vila> ooooh 'removable' !
<htd> hi, i am totally new to bzr - if i merge my changes, can i control if the full history of my changes gets merged or just the most recent revision?
<Pilky> jam: might have something for you next week
<matkor> htd: you can control what changes are marged
<jam> Pilky: what is that?
<Pilky> first release of a OS X GUI client for Bazaar
<htd> matkor: sounds great, thanks for the info
<jam> sounds interesting
<Pilky> gonna be pretty basic to begin with (add, init, init-repo, commit, status) but should still be pretty helpful
<pickscrape> beuno: what happened to your plugin_management plugin? I just did a pull and upstream has vanished.
<gumpa> I am getting a traceback and hang on "Please wait, loading ancestral graph" when I click  the 'Log' button in Olive, current lp:bzr-gtk
<jam> Pilky: have you tried QBzr on Mac?
<jam> just wondering if your time might be better spent expanding something that already works there
<gumpa> pastebin?
<Pilky> jam, possibly, I just don't think that there's going to be a huge adoption of a GUI client on the Mac if it's not native
<jam> Pilky: perhaps, though there won't be huge adoption if it is underdeveloped, either :)
<pickscrape> One of my colleagues spotted BazaarX the other day
<pickscrape> Which is apparently a bzr client for cocoa.
<jam> jelmer: I responded
<Pilky> heh, but an application is only underdeveloped for a certain amount of time ;)
<Pilky> pickscrape: that would be the app I'm working on
<pickscrape> Ah
<jelmer> jam: earlier you mean, or just now?
<jam> jelmer: just now
<jelmer> jam: Thanks :-)
<Pilky> We only started coding it yesterday but we've got pretty far
<pickscrape> Yes, it caused a small flurry of excitement amongst the Crayon Monkeys who aren't too keen on the idea of using the command line :)
<pickscrape> Unfortunately I have no idea how to compile it, so I can't advise them :(
<Pilky> compile BazaarX?
<Pilky> at the moment there's not much to compile, just some unit tests for the bit that talks to bzr, but we'll be providing disk images with the app on for each release
<pickscrape> Cool. Yeah, I realise it's young. I just get frustrated by the whole apple thing. At least with windows I can easily run it under vistualbox.
<pickscrape> virtualbox.
<awilkins> I'd rather people diverted all their attention to Olive, frankly, and shamelessly stole as many ideas from TortoiseSVN as possible.
<awilkins> Is vistualbox a euphemism for "The OS before Windows 7" ?
<awilkins> ;-)
<pickscrape> That would be Windows ME II ;)
<jam> jelmer: do you use the 'stop_revision' parameter of missing_revisions?
<jam> I'm just trying to understand it
<jam> I *think* it is a revno
<jam> I was going to clean up the function
<jelmer> jam: in my implementation it is a revid
<pickscrape> ï»¿Pilky: either way, my colleagues are very much looking forward to your work on that, and it is appreciated.
<jam> but now I'm thinking about just deprecating it because it is crufty
<jam> jelmer: well I see:
<jam> if stop_revision > other_len:
<jam> jelmer: so I'm pretty sure it *has* to be a revno
<jelmer> jam: It may've changed since I created my implementation though
<jam> at least for the base implementation
<Pilky> pickscrape: nice to know that others are interested as well :)
<jelmer> jam: Mine is called lhs_missing_revisions() these days
<jam> jelmer: update_revisions() takes a revision id
<jam> I think missing_revisions is just badly broken
<jam> and nobody noticed
<jelmer> jam: looks like it
<jam> jelmer: ok, deprecation and future nuking it is
<steelpotato> can somebody help me an error message?
<steelpotato> I'm trying to use bzr switch, and it says:
<steelpotato> bzr: ERROR: Cannot switch a branch, only a checkout.
<Pilky> steelpotato: did you use bzr checkout to get the files?
<steelpotato> I guess not :) No, I think I used branch.. so that makes sense, but I still want to switch it
<steelpotato> the url I'm switching to is a branch of the url I originally branched from
<Pilky> so you're wanting to change the default URL to merge/push/pull?
<Lo-lan-do> Then first bind to your initial URL, and switch after that
<steelpotato> Pilky: well, yes, but mostly I want to change to the new files, since they contain some changes
<radix> steelpotato: then maybe you just want to pull or merge
<jam> steelpotato: bzr pull http://new_url ?
<jam> or maybe
<Pilky> steelpotato: try bzr pull URL
<jam> bzr pull --remember --overwrite http://new_url
<steelpotato> that would change the files
<Pilky> and add --remember to that if you want to set that as the default
<steelpotato> but what if I wanted to switch back?
<Pilky> to the previous files?
<steelpotato> yeah
<radix> steelpotato: or... maybe you just want to branch again? :)
<steelpotato> this is an experimental change i'd like to review
<Pilky> just bzr revert -1
<beuno> pickscrape, I moved it: https://code.edge.launchpad.net/~beuno/bzr/automatic_plugins
<beuno> it has almost-working-install now  :)
<jam> steelpotato: alternatively "bzr merge http://new_url"
<radix> steelpotato: ok, so someone made a branch and you want to review the changes it has?
<jam> if you just want to review it
<steelpotato> Let me explain my background a little bit...  :) I'm used to using git, where I could branch all over the place
<steelpotato> and switch between them at wil
<steelpotato> I'm trying to duplicate that without needing to create new checkouts
<steelpotato> because the folders are flex projects and the IDE doesn't like duplicate projects
<radix> Yeah, I suggest merging it and then viewing the diff.
<radix> And you can branch as much as you want. branch branch branch.
<bob2> steelpotato: create a repository, branch things into it, checkout from it and then switch that checkout amongst the branches
<steelpotato> bob2: right, that's what I am trying to do, but since I used bzr branch instead of bzr checkkout originally, switch isn't working
<steelpotato> I could just check it out again
<Pilky> steelpotato: just wondering why you don't just branch from the repository with the new files?
<steelpotato> Pilky: I'm not sure I understand
<bob2> steelpotato: right, so 'bzr init-repo ~/somewhere', 'bzr branch . ~/somewhere/trunk', 'bzr bind ~/somewhere/trunk', 'bzr reconfigure --checkout'
<steelpotato> Pilky: you mean get a new folder with the branch?
<Pilky> yeah
<Pilky> I'm assuming the files you want are in some central location
<steelpotato> Pilky: they are, but I can't create multiple copies locally
<Pilky> why not?
<steelpotato> Pilky: because the IDE gets mad at me for having two projects claiming to be the same one
<Pilky> odd, which IDE?
<steelpotato> Flex Builder
<steelpotato> Eclipse
<Pilky> ah
<steelpotato> I just use it for compiling and linking :)
<Pilky> I can see how that would be an issue
<radix> steelpotato: IMO merge is the easiest thing you could do right now.
<steelpotato> bob2: I totally don't understand those commands, but I could give them a shot... Why would I need to use the bind command to get that to work?
<radix> steelpotato: If you merge it, it'll change your working copy but not the branch; you can view the differences and then revert them.
<steelpotato> radix: would my local commit history be any different than the branch's?
<steelpotato> radix: would it show a new commit or something, or would that match the branch I'm merging from ont he server?
<radix> steelpotato: No. merging doesn't affect your branch (i.e., it doesn't add any revisions). You have to commit the merge if you want to save it.
<pickscrape> beuno: thanks. And bzr pull --remember Just Worked too :)
<steelpotato> bob2: or is it the reconfigure --checkout thing
<radix> steelpotato: and if you don't want to save it, you can "bzr revert" and the merge goes away.
<beuno> pickscrape, sorry about moving it  :)
<bob2> steelpotato: well, the idea is that a checkout doesn't actually include a branch, it just points at one. those commands put the branch elsewhere, then attach the existing branch dir to that other place.  you're right, the reconfigure is redundant.
<pickscrape> Not a problem
<steelpotato> bob2: alright... i'm going to try to switch my working copy to be a "checkout" instead of a "branch"
<bob2> steelpotato: or, like someone else said, you can just bind to the remote branches directly
<steelpotato> bob2: ? Is that what they said? :D
<steelpotato> well, I don't like the merging idea (it would work, but I want something more flexible)
<steelpotato> you mean bzr bind the_new_branch?
<steelpotato> that makes it send all commits to the server, right?
<bob2> bzr bind sftp://whatever
<bob2> yes
<steelpotato> would the bind command get me those new files?
<steelpotato> then I could unbind, or somethign?
<steelpotato> Because I don't want my commits sent to the server automatically
<radix> steelpotato: fyi, a "checkout" is a bound branch, and means that commits automatically get sent to whatever branch you "checked out"
<steelpotato> ohhh
<radix> steelpotato: then you don't want to reconfigure to a checkout.
<steelpotato> radix: but I DO want to do the switch
<steelpotato> so I could bind, switch, then unbind, right?
<steelpotato> I think I'm totally missing the point here
<lifeless> indeed
<lifeless> switch assumes you have your work stored elsewhere
<radix> oh, or you could bind to a branch on your own machine? I guess that's what beuno's suggesting
<steelpotato> Maybe I should read more about the design decisions of bzr
<lifeless> if you just want a new basis, just pull --oveerwrite
<radix> merging sounds like a much simpler way to review changes than all of this stuff :)
<steelpotato> lifeless: yeah, that would work like I'm expecting switch do, right?  Would it changed my "stored location"
<steelpotato> radix: yeah, but I might want to work on it, then switch back to something else, etc
<Pilky> steelpotato: have you read through the user guide? might be worth identifying what workflow best fits your situation and reading the relevant section
<steelpotato> radix: I'm looking for something that willl support the workflow I'm used to
<steelpotato> Pilky: thanks
<bob2> steelpotato: what I would do: create repository, branch everyone else's stuff there, make your 'trunk' or 'reviewed' or whatever branch, co it, then use switch to move between all the others
<Pilky> bzr is incredibly flexible to various workflows. I'm using it for solo stuff, distributed stuff that's centralised on launchpad and the friend that is working on the launchpad project is hoping to switch over from subversion while using it similar to subversion
<steelpotato> bob2: so, basically what I'm doing now, except I'm bound to the branch I'm working on?
<steelpotato> bob2: we have a repo on the server, it has some branches there
<steelpotato> bob2: somebody branched locally, then pushed their changes up to a new folder up there
<steelpotato> bob2: we're planning on distributing lots of experimental changes there until it is reveiwed, when it will be merged into the trunk
<steelpotato> I'm thinking this will work ..
<steelpotato> Pilky: yeah, I like it so far...
<steelpotato> thanks everybody
<steelpotato> I'll fool around with it more
<sabdfl> steelpotato: the user guide is still very cool to gain an understanding of all the different workflows that are easy with bzr, because you can then compose a customer wokflow that right for you
<Psy|ecimTech> Hi there, someone can guide me a bit on a problem trying to install bzr-eclipse?
<beuno> Psy|ecimTech, I can try, and, if not, I'll try and drag the developer in here
<Psy|ecimTech> Thanks
<Psy|ecimTech> I'm on XP SP3, I have the bazaar executable intalled and the xml plugin on the plugin directory
<Psy|ecimTech> I'm now configuring bazaar's plugin on eclipse, but the preference dialog keep telling me that there is no bzr-xmloutput plugin
<Psy|ecimTech> on bazaar plugins path I have
<Psy|ecimTech> bazaar\plugins & bazaar\plugins\bzr-smloutput
<beuno> Psy|ecimTech, could you fire up a console in windows, and run:  bzr plugins
<Psy|ecimTech> oh I see
<Psy|ecimTech> seems that there is a problem with the folder name
<Psy|ecimTech> bazaar recomends rename it to bzr_xmluoutput
<Psy|ecimTech> lets see..
<Psy|ecimTech> Solved!
<Psy|ecimTech> thanks very much
<beuno> Psy|ecimTech,  :)
<Jc2k> jelmer: i'm looking at bug #232196 and wondered if you could spare 5 to see if i'm hot or cold..
<ubottu> Launchpad bug 232196 in bzr-svn ""The file id FOO is not present in the tree" on svn-import or branch" [Undecided,New] https://launchpad.net/bugs/232196
<Jc2k> jelmer: i actually just realised i'm coooold :-(.. *goes back to digging*
<matkor> Is it posible to mark bug as duplicate of another ?
<matkor> https://bugs.launchpad.net/bzr-gtk/+bug/232551
<ubottu> Launchpad bug 232551 in bzr-gtk "Olive hangs when 'Log' is clicked" [Undecided,New]
<beuno> matkor, sure, on the left hand side, you have "Mark as duplicate"
<matkor> ahh
<matkor> thanks bueno
<beuno> matkor, np
<jelmer> Jc2k, hi
<Jc2k> jelmer: lo
<Jc2k> i thought the branch commit history was weird, but it looks similar to branches that do work
<Jc2k> so im no closer to finding out whay these branches are screwy/different to normal
<jelmer> it's probably just a corner case bug
 * jelmer tries to branch the eog url
<grahal> is there something similar to git-send-email in bzr?
<grahal> bzr send doesn't seem to be the answer
<fullermd> It's the usual one.  What's it lack?
<Jc2k> jelmer: changing trains. be back in a bit..
<grahal> I was expecting the ability to break commits into several emails
<grahal> not a single email with all the merge
<grahal> 1/3, 2/3, 3/3 kind of thing
<fullermd> grahal: You may want to see the thread at <https://lists.ubuntu.com/archives/bazaar/2008q2/thread.html#41611>
<fullermd> The topic seems to come up every few months; that's the last time through it (it generally quickly goes a bit meta)
<lifeless> grahal: you could also do send -r -4..-3; send -r -3..-2; send -r -2..-1
<grahal> I see, thanks for the info
<grahal> will have a look
<jelmer> Jc2k, it's svn revnum 3335 that is the culprit
<lifeless> tchau
<jelmer> Jc2k, ping
<Jc2k> jelmer: pong
<jelmer> Jc2k, I think I have a fix
<Jc2k> jelmer: awesome :D
<keithy> I am attempting to setup loggerhead still
<keithy> the directions for ProxPass in apache dont setup the static files
<lelit> jelmer, lifeless: for whatever reason, bzr.dev took even longer in that .missing()
<Jc2k> jelmer: got a diff so i can take it for a spin?
<keithy> I am struggling to get the static content served by appache
<keithy> for loggerhead
<keithy> has anyone got some conf I could look at
<sabdfl> keithy: expert is mwhudson_
<keithy>  
<jelmer> Jc2k: yeah, I'll commit to bzr-svn's 0.4 branch in a few minutes
<jelmer> I was trying to add a test case to reproduce this
<jelmer> but I haven't been able to do so yet
<Jc2k> cool
<Lo-lan-do> jelmer: Sorry about the duplicate bugs, by the way
<keithy> mwhudson_ hello: :
<jelmer> Jc2k, pushed
<Jc2k> awesome
<Jc2k> *patches and kicks off some imports*
<Jc2k> jelmer: happily your patch is what i was thinking, but i just couldn't figure out a test case to go with it
<jelmer> Jc2k: Yeah, me neither :-(
<Jc2k> SVN seems to stop you creating that kind of a state these days?
<jelmer> well, I must admit I haven't reproduced the full state, just the bits I thought mattered
<Jc2k> well, same here
<Jc2k> *shrugs*
<NemesisD> hi all, ive found the documentation on using the ssh+bzr:// protocol a little spotty, is there a way you can specify the username and password so that several dirs can be pushed with a shell script
<Lo-lan-do> NemesisD: You can do the username with ~/.ssh/config, and use keys to avoid the password problem
<NemesisD> hmm
<NemesisD> Lo-lan-do, ok im following the guide on bazaar's site but its a bit confusing, i did an ssh keygen
<NemesisD> and its telling me to copy the contents to my local authorized_keys file, do i just copy the big huge key or am i copying the DEK-Info part and th Proc-Type part?
<Lo-lan-do> Actually, you need to copy it to the remote authorized_keys file.
<Lo-lan-do> The ssh-copy-id command does it for you.
<NemesisD> hmm,  i just did cp id_bzr.pub authorized_keys on the remote system then i scp'ed the authorized_keys to my local .ssh directory
<beuno> NemesisD, and make sure the permissions for that file are set to 600
<NemesisD> i entered a passphrase when it asked when i did the keygen, should i not have done that?
<beuno> NemesisD, then, you will be asked for a passphrase every time
<beuno> if you don't want to use a passphrase, re-generate it without one
<Lo-lan-do> Or use ssh-agent, which will cache it in memory.
<NemesisD> hmm, im a bit confused, i think i would like to be prompted for a password when i ssh in manually to do stuff but i want my script that uses bzr+ssh:// to not be prompted, but i suppose that doesn't make much sense
<NemesisD> i tried resetting the password to blank and its still prompting
<NemesisD> crap, ive somehow done the process in reverse, now the remote can ssh into me with no pass but not vice versa
<beuno> BB is down, The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
<beuno> abentley, ^
<NemesisD> fix'd
<abentley> beuno: Should be up in a minute.
<beuno> abentley, cool, thanks. Didn't know if you where aware  :)
<abentley> No, I wasn't.  Thanks.
<abentley> Every now and then it hangs badly enough a kill -9 is needed, and the auto-restart doesn't do that.
<beuno> abentley, always sqlite's fault?
<beuno> (loggerhead seems to do the same, so it makes me wonder)
<abentley> No, an interaction between sqlite's and turbogears.
<NemesisD> ugh, ok so rather than doing a bzr push with ssh, would it be equivalent to, on the local machine, do bzr checkout foo/ temp/, scp temp/ to the remote machine then delete the local copy of temp?
<beuno> abentley, I haven't looked into it, but, would adding a postgre backend be too complicated?  I think you already use alchemy, right?
<abentley> No, adding the backend isn't complicated.  I just don't see an easy way of migrating the data.
<beuno> abentley, well, I want to use BB for a few projects, so, if you're willing to point me in the right direction now and then, I can try and add postgre/mysql support, and a migration script
<beuno> (and, of course, to improve BB's uptime for bzr :p)
<abentley> I'd love it if you did that.
<beuno> cool, I've just finished work, so I'll plunge into the code now and start snooping
<beuno> is there anyway I can get my hands on the current bzr sqlite DB to run tests?  I don't know if there's any sensitive data on it like passwords and such
<keithy> have we a loggerhead expert in the house?
<keithy> I have a heirarchical arrangement of brances
<abentley> There are passwords.  I can get you a copy, but I'll have to scrub the passwords first.
<keithy> and some duplicate names
<keithy> loggerhead flattens them
<beuno> abentley, no hurry, but if you could, it would probably speed things up for me  :)
<keithy> and the duplicates are pointint to the same repo
<beuno> keithy, mwhudson_ seems to be still away. He's in New Zeland, so don't expect him to be up for a couple more hours
<abentley> beuno: Actually, he's awake and active on the private irc server.
<beuno> ah, well, he must be busy then (I assumed because he has the _ in the nick)
<keithy> mwhudson_: hello
<keithy> do any of the other web frontends support a heirarchy of repos?
<keithy> I cant see the "download tarball" option
<beuno> keithy, loggerhead currently doesn't have that option
<beuno> some work might be done on loggerhead in the following months, so expect improvements  :)
<keithy> sigh
<keithy> so nothing works
<beuno> that may be a bit over the top, but feel free/encouraged to file bugs toward loggerhead as feature requests
<keithy> http://bzr.warwick.st/
<keithy> the published urls for the repositories are wrong
<keithy> thats on the front page!
<beuno> keithy, please file bugs with as much detail as you can so it can get fixed
<mwhudson_> keithy: what's wrong with the urls?
<keithy> I access my repo via
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.10/LPF/pr_tools
<keithy> the url listed for pr_tools is
<keithy> bzr push ssh://bzr.warwick.st/squeak/pr_tools
<keithy> there are two LPF branches
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.10/LPF
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.9.1/LPF
<keithy> they show up as the same repo
<keithy> again with the wrong url
<keithy> I spent 6 hours or more trying to get the apache config to work
<keithy> I set up a virtual host instead
<keithy> so that working now
<mwhudson_> loggerhead displays the public_location url for each branch i think
<keithy> sorry I dont know what that means
<keithy> a branch should not know where it is in the hierarchy
<mwhudson_> keithy: well, i don't really understand your description of your problem
<mwhudson_> keithy: so i guess we're about even
<keithy> I have a heirarchical repo
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.7
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.8
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.8
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.9
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.10
<keithy> etc
<mwhudson_> ok
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.10/LPF
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.9/LPF
<mwhudson_> oh, i think i see
<keithy> bzr push ssh://bzr.warwick.st/squeak/3.9/LPF/pr_tools
<keithy> each level is a specialization of the one above
<keithy> http://bzr.warwick.st  ignores the hierarchy
<mwhudson_> so i guess one thing to say is that the urls loggerhead is using in the web browser and the paths you push to using ssh don't inherently have anything to do with each other
<mwhudson_> keithy: can you pastebin your loggerhead.conf file?
<keithy> url?
<mwhudson_> http://pastebin.ubuntu.com/
<keithy> http://pastebin.ubuntu.com/13727/
<keithy> the repo heirarchy is fairly invisible since .bzr is a hidden directory, so my public users have no idea what is in the repo
<keithy> so something should tell them what bzr command to use to access the repo
<beuno> abentley, meeting all dependencies for BB in hardy is turning out to be quite a challenge
<mwhudson> ah dammit i don
<mwhudson> 't have the loggerhead source on this machine yet
<mwhudson> (my hd in my other laptop died yesterday)
<keithy> ouch
<abentley> beuno: What's the problem?
<beuno> abentley, BB asks for a newer (or older) version of almost all the dependencies
<beuno> pkg_resources.VersionConflict: (PasteScript 1.6.2 (/usr/lib/python2.5/site-packages/PasteScript-1.6.2-py2.5.egg), Requirement.parse('PasteScript>=0.9.7,<1.6'))
<beuno> finding newer egg's for the other ones was fairly easy, finding *older* versions is turning out to be much harder
<abentley> I find you have to hand-hack the URLs for PyPI.
<beuno> RuleDispatch above revision 3201 was a tough one too
<abentley> But I honestly was unaware of any issue.  That PasteScript is not a dependency I deliberately put there.
<abentley> Neither the RuleDispatch.
<beuno> pkg_resources.VersionConflict: (RuleDispatch 0.5a0.dev-r2115 (/usr/lib/python2.5/site-packages/RuleDispatch-0.5a0.dev_r2115-py2.5-linux-i686.egg), Requirement.parse('RuleDispatch>=0.5a0.dev-r2303'))
<abentley> This is all sounding suspiciously like *TurboGears* requirements, not BB's.
<beuno> hrm
<abentley> Have you installed Hardy's TG?
<beuno> they are...
<beuno> yes
<mwhudson> keithy: so basically the problem is that loggerhead only really seems to expect branches to be directly in the repo
<mwhudson> repo/
<mwhudson> repo/branch1
<keithy> something like that
<mwhudson> repo/branch2
<mwhudson> keithy: you can sort of fudge around this by not using auto_publish_folder i expect
<keithy> and it finds branches at a deeper level, but "moves" them to the top level
<mwhudson> or by using it for each part of your repo or something
<keithy> k
<beuno> abentley, I've got /usr/lib/python2.5/site-packages/TurboGears-1.0.4.3-py2.5.egg/turbogears/
<mwhudson> i think you could say that the auto_publish_folders feature wasn't amazingly well thought out
<abentley> So what are you doing that's triggering the demand for PasteScript.
<beuno> abentley, starting BB. Although, traceback *is* from TurboGears
<abentley> You don't have an old TG install do you?
<abentley> in addition to the Hardy one?
<beuno> abentley, let me check, but the traceback is coming from the path above
<abentley> beuno: Please pastebin the traceback.
<beuno> abentley, http://paste.ubuntu.com/13732/
<abentley> beuno: It doesn't look like you're starting BB.
<beuno> abentley, I was running setup for BB there, but it's the same error
<beuno> in fact, I get the same error while importing turbogears in ipython
<beuno> so it's definetly not a BB problem...  :/
<mwhudson> i think i'd look for out of date crap on $PYTHONPATH
<abentley> beuno: Yeah, I've just double-checked and BB only specifies versions of TG, Elixir, SQLAlchemy and bzr.
<beuno> mwhudson, I'm starting to suspect it has something to do with when I installed loggerhead  :)
<beuno> :p
<mwhudson> eh, i wouldn't recommend actually _installing_ loggerhead
<beuno> cleaning things up, installing them all over again
<kwah> hi everyone
<beuno> mwhudson, setup.py outdated?
<kwah> are there features in bzr helping out in tracking refactoring ?
<mwhudson> beuno: i haven't looked at setup.py once since i started maintaining loggerhead
<beuno> mwhudson, aaah, good to know
<beuno> (makes a lot of sense now)
<mwhudson> beuno: perhaps i should have made it more obviously broken
<mwhudson> oh actually i have looked at it
<mwhudson> but only to get sdist to work
<beuno> ok, yes, it was the loggerhead which b0rked everything
<mwhudson> which reminds me, i should see if bzr 1.5 breaks loggerhead like i expected it to
<beuno> oddly enough, for python2.5, if I run BB with python2.4, it works fine
<beuno> mwhudson, I
<beuno> I'd recommend breaking setup.py in a very obvious way  :)
<beuno> if things go well, I might end up packaging, so I guess I'll have to fix it eventually, but, for now...
<mwhudson> and wa-hey, no python 2.4 on this machine yet eithr
<mwhudson> oh er, or tg
<johan> is there a command similar to git log -p in bzr. which shows me a log but includes the diffs?
<beuno> abentley, ok, cleaning up everything and doing clean installs worked.  Thanks, and sorry for the noise
<pickscrape> johan: that's a request already in launchpad
<johan> pickscrape: okay, that's good enough for me
<abentley> beuno: No problem.
<beuno> abentley, is there a specific problem you see in going from sqlite to postgre?   I'm running a few quick tests now against MySQL, and I don't see many problems in the horizon
<abentley> No, I don't know of any specific problems.
<abentley> I just have all this data and no simple way to convert it.
<beuno> abentley, that's good news, I thought I was missing something
<beuno> I'll try and hack together a script that does it, and, when you send me the data, I'll run tests against it
<abentley> I guess you should try exercising all the hardcoded queries, since that's most likely to differ.
<beuno> once I get all the data over, I'll look into testing those
<abentley> beuno: The other thing to try would be getting the test suite running under PG.
<beuno> abentley, sure, sounds sane. I'm going to start with mysql, because it's what I know best, and will spend the less amount of time with trivial problems, but jumping to pg after that should be very easy
#bzr 2008-05-22
<Odd_Bloke> beuno: OOI why Postgres over MySQL?
<beuno> Odd_Bloke, because that's what I've been working for the past 6 years  :)
<beuno> I'm not saying that should be *the* backend
<beuno> it's just easier for me to start with that, implement it, and then jump to pg
<Odd_Bloke> beuno: My question was the other way around. :p
<Odd_Bloke> Or, why is Postgres the end goal? Won't MySQL be good enough?
<beuno> Odd_Bloke, ah, sorry, was expecting a MySQL bashing  :p
<beuno> yes, MySQL should be good enough, but I suspect PG will be prefered from people coming from LP
<mwhudson> has anyone here installed turbogears on leopard?
<Odd_Bloke> beuno: Ah, yeah, that hadn't occurred to me.
<mwhudson> without wanting to maim someone (possibly themselves)
<abentley> Odd_Bloke: Yeah, familiarity with PG, and I understand that PG is a more correct SQL implemplementation.
<beuno> abentley, any idea why I would get this while voting?  http://paste.ubuntu.com/13751/
<abentley> Your account doesn't have any submitter associated with it, I would imagine.
<abentley> If you used the create_account script, that shouldn't have happened.
<beuno> I did
<beuno> I'll clean the DB and try it again
<abentley> It looks as though the submitter list is optional, but you should have at least one.
<Odd_Bloke> abentley: Well, there's certainly an argument that being a correct SQL implementation isn't necessarily a good thing. :p
 * Odd_Bloke had Hugh Darwen teach his Intro to Databases course, and has disliked SQL since. :D
<abentley> beuno: How do you want this sqlite file?  Email?
<beuno> abentley, email is fine, yes
<Odd_Bloke> abentley: Might be worth putting it somewhere several people can get, if it could aid development...
<abentley> Odd_Bloke: Okay.
<beuno> hrm, I'm making some progress with moving over the data, although I'm not sure how I'm going to automate some steps
<beuno> I've got *most* tables in mysql with data
<abentley> beuno: What approach are you taking?
<beuno> abentley, exporting the SQL db, replacing known differences between sqlite and mysql queries, and dumping into the mysqldb
<abentley> beuno: Are you prepared to deal with binary data that way?
<beuno> abentley, AFAIK, binary data should be dumped and imported correctly, but I'll get back to you when I actually test it  :)
<beuno> that would be mainly for patch_text, right?
<abentley> beuno: There are some UTF16 files in there.
<abentley> IIRC.
<beuno> abentley, I'm going to aim at getting all the tables created and data fully imported into them, and then start to check consistency
<beuno> that's where the bzr db will come in handy  :)
<beuno> I'm going to head home now to get something to eat, but I'll be back in a while, I'm curious to see how far I can get without running into substantial blocker
<abentley> beuno: http://code.aaronbentley.com/bundlebuggy/devdata.sqlite.nopasswords
<beuno> abentley, great, thanks! I'll use that as soon as I get mysql to create all the tables correctly  (already home)
<NemesisD> how does bzr treat symlinks by default?
<NemesisD> i made a change to a symlink file and i noticed that bzr commit didn't list the file as changed
<bob2> if the symlink and destination are versioned by bzr, it should work (and does for me)
<beuno> abentley, I haven't tried with the bzr db, but with small adaptations to the table structure, and replacing a few characters from the sqlite dump, data seems to get imported correctly into mysql. I'm leaving for a few hours, and hopefully I'll be back to test it against the bzr db
<beuno> (I imported the blobs from sqlite, and they seem to get imported correctly)
<abentley> Well, that sounds promising.
<igc> morning
<igc> poolie: Thanks for your emails re file categories. I've emailed the list with my latest thoughts so I'd be keen for you to consider them when times permits.
<hersonls> poolie: here
<abentley> beuno: I've updated the docs.
 * igc lunch
 * igc pick up kids
<Odd_Bloke> ZOMG netsplit.
<poolie> hello lifeless
<poolie> lifeless: could you look at balleny again if you get a chance or ask a sysadmin to do so, it's still ridiculously slow
<lifeless> poolie: will nag
* You're now known as ubuntulog
<lifeless> liw: how is the rsync?\
<liw> lifeless, the big pack file has about 43 more hours to go, and then there's another 227 thousand more files
<lifeless> are you copying the working trees?
<liw> nope
<lifeless> strange
<lifeless> let the big file finish
<lifeless> then stop the rsync, and do 'for branch in branches; bzr zap-tree $branch'
<liw> ack
<Peng> "zap-tree"?
<lifeless> something like
<lifeless> remove-tree, zapt-ree, I dunno
<Peng> remove-tree.
<Peng> zap-tree would be a useful alias. "remove-tree" is long.
 * igc dinner
 * gour wonders why igc always has dinner so early...we hardly took a breakfast here
<lifeless> timezones ftw
<gour> timezones? i thought there is no life out of the europe
 * gour is joking a bit...holiday is here today ;)
<mtaylor> .THIS .OTHER .BASE - is there a doc describing them anywhere?
<gour> mtaylor: http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#resolving-conflicts
<spiv> mtaylor: "bzr help conflicts"
<spiv> Hmm, test_35_wait_lock_changing has bitten me twice today.
<[reed]> How does bzr compare to this? http://quotes.burntelectrons.org/3715
<luks> [reed]: ideally, you don't rebase, but merge instead
<luks> but if you really must, there is a plugin, so you can do just 'bzr rebase'
<LarstiQ> or just pull
<luks> LarstiQ: I guess the situation is that you have a committed change and you want to pull
<luks> at least that's what I understood from the hg sequence of commands
<LarstiQ> luks: that explains the need for rebase, the 'cvs up -A' is a bit misleading though
<luks> er, I meant ;'and you want to push'
<[reed]> yeah
<[reed]> k, thanks
<lifeless> [reed]: ouch, that quote hurts my eyes
<[reed]> lifeless: hehe
<elmo> lifeless: fail.  :/  dapper chroot is <1s on my laptop
<lifeless> elmo: garh
<elmo> should bzr build-depend on the pyrex stuff?
<elmo> nm
<lifeless> no
<jml> abentley: ping
<emgent> hello people
<emgent> http://pastebin.ubuntu.com/13848/
<emgent> some idea?
<emgent>   launchpad            /usr/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
<fullermd> Think that's fixed in newer bzr.  1.5 should have it.
<fullermd> bug 217701
<ubottu> Launchpad bug 217701 in bzr "attempt to add line-delta in non-delta knit" [Critical,Fix released] https://launchpad.net/bugs/217701
<emgent> fullermd: uhm
<emgent> i think no
<emgent> http://pastebin.ubuntu.com/13849/
<emgent> i have newest bzr
<fullermd> No, you have 1.3.1.
<fullermd> 1.5 has the fix.
<emgent> uhm just a moment
<emgent> uhm true
<fullermd> Coffee.  Blame it on lack of coffee   :)
<emgent> :)
<elmo> lifeless: "fixed"
<elmo> best non-solution ever
<abentley> jml: pong
<jml> abentley: I've got a patch to the stacked branch stuff that only really makes sense to apply to your branch.
<jml> abentley: it make BzrDir.clone() also clone stacked_on information.
<abentley> jml: Wouldn't it also make sense to apply to Robert's branch?
<jml> abentley: logically yes. I haven't tried applying it though.
<abentley> thumper and I haven't discussed what he wants me to do vis-a-vis an integration branch, but I'm happy to look it over.
<jml> abentley: http://pastebin.ubuntu.com/13853/
<jml> abentley: lifeless paired with me to do that, fwiw.
<abentley> So I guess the main concern I have is whether "push" uses clone or sprout.
<lifeless> elmo: new kernel?
 * lamont idly wonders why the ppa archive for bzr doesn't bother with a bzr_1.5.0.orig.tar.gz
<lamont> admittedly, bzr_1.5.0-$mumble.tar.gz is only 3.5MB, but still...
<pickscrape> Is the PPA archive suitable for debian users, or is it Ubuntu only?
<lamont> installing ubuntu debs on debian and vice versa is an action that is fraught with peril.
<lamont> OTOH, bzr_1.5-1 is in sid
<pickscrape> What's sid?
<lamont> debian unstable
<lamont> and I rather expect that someone has tossed it at backports.debian.or
<lamont> g
 * pickscrape is a debian distro noob. Long time gentoo user.
<elmo> lifeless: yea, that 'fixed' it - it's still reproducable on tungsten, which is edgy (2.6.17.4)
<lamont> welcome to the fold
 * lamont rotfl at the bzr packaging using quilt.
<sabdfl> nfw
<Psy|ecimTech> hi there!
<sabdfl> hi Psy|ecimTech
<Psy|ecimTech> Just a quick question :P
<Psy|ecimTech> I'm playing a bit using the smart server, but seems that when I kill the process, the 4155 port remains open.
<Psy|ecimTech> So, next time I fire up the server, I get this error: error: (98, 'Address already in use')
<Psy|ecimTech> Oh, now its ready, seems that it takes time to close up the port on ubuntu
<MattCampbell> Looks like the smart server may not be setting the SO_REUSEADDR option; I'll check.
<Psy|ecimTech> Yep, seems that you must wait for a timeout to reuse the port
<MattCampbell> Indeed the SO_REUSEADDR socket option isn't being set.
<MattCampbell> Wait, I'm not looking at the latest code.
<Psy|ecimTech> BTW, whe are playing a bit versioning thru smart server on windows <-> ubuntu 64.
<MattCampbell> If you're running a smart server on Ubuntu, why not use bzr+ssh instead?
<MattCampbell> (I'm waiting on a checkout of bzr trunk so I can see if the smart server sets SO_REUSEADDR in the latest revision.)
<Psy|ecimTech> Oh, we're just starting, and just avoid any problem on windows side...
<MattCampbell> Looks like the smart server sets the SO_REUSEADDR option in bzr trunk.  Anyone know when this was done?
<MattCampbell> Psy|ecimTech: What version of bzr are you running on the Ubuntu machine?
<Psy|ecimTech> Wait a minute, the Ubuntu guy is just comming in
<Psy|ecimTech> there!
<MattCampbell> The SO_REUSEADDR fix was done on 2008-04-21.
<Psy|ecimTech> Gus_Tronador: -> MattCampbell: Psy|ecimTech: What version of bzr are you running on the Ubuntu machine?
<Psy|ecimTech> Gus_Tronador: -> MattCampbell: The SO_REUSEADDR fix was done on 2008-04-21.
<MattCampbell> So it should be in 1.5.
<Psy|ecimTech> Seems to be 1.3.1
<Psy|ecimTech> Could it be a RC?
<MattCampbell> An update to 1.5 should fix the problem.
<MattCampbell> 1.5 came out a few days ago.
<MattCampbell> BTW, I'm a bzr newbie too, so maybe what I'm saying is obvious to everyone else here.
<Psy|ecimTech> No, thats great, but seems that ubuntu's repo is still not updated to the latest
 * MattCampbell looks on packages.ubuntu.com
<luks> you can use https://launchpad.net/~bzr/+archive
<Psy|ecimTech> ahhh great!
<Gus_Tronador> Hello! ... I'm using BZR in ubuntu 8.04 Hardy Heron and I have an issue with "bzr server" ... When I run it from console and I stop it with "ctrl+c" socket remains open or address-port 0.0.0.0:4155 remains binded to socket
<Gus_Tronador> so ... I wish I could unbind it to restart server. Could someone please help me?
<Gus_Tronador> (when I try to re-run "bzr server" I get : "bzr: ERROR: Cannot bind address "0.0.0.0:4155": Address already in use." )
<radix> heh
<radix> Gus_Tronador: someone just mentioned this problem half an hour ago :)
<radix> Gus_Tronador: it should work after a couple minutes.
<radix> Gus_Tronador: oh, and it seems to be fixed in bzr 1.5, according to conversation that just happened
<Gus_Tronador> radix: I think it wasn't fixed in 1.5 because I'm using that version :( ... address-port remains binded for a couple of minutes
<Gus_Tronador> radix: and after those minutes I can restart server.
<radix> Gus_Tronador: you're using the final version of 1.5?
<radix> maybe it's not in a release yet
<Peng> WFM on Ubuntu with bzr.dev.
<Peng> (I dunno if I have 1.5 installed.)
<Peng> Well.
<Peng> Yeah, WFM in 1.5 too.
<ignas> hi
<ignas> in our ssh configuration we had a limitation that people can only run "/usr/bin/svnserve -t"
<ignas> what command is needed to allow them to use bzr smart server?
<fullermd> bzr server [some args]
<fullermd> Er, 'serve'.
<ignas> "serve" ?
<ignas> it starts the bzr server
<ignas> i am talking about bzr+ssh://
<fullermd> Same thing.
<fullermd> It uses serve --inet [various others...   --allow-writes at least, --directory=/ maybe?  Not sure]
<Peng> Yeah, --directory / is among them.
<ignas> so i just edit .ssh/authorized_keys
<gour> i need some help (in order to provide bzr completion for fish shell) how is bzr help formatted, i.e. in string "-v, --verbose        Display more information."
<ignas> and add "bzr serve --directory=/ --allow-writes" there
<gour> ...space is used between short & long option, but what about long option and description?
<Peng> ignas: Don't forget --inet.
<james_w> gour: have you seen "bzr shell-complete"?
<gour> james_w: no, i'm figuring out where and how are helo topics generated
<gour> james_w: shell-complete misses descriptions
<gour> james_w: see http://rafb.net/p/7k94LV34.html - this is the fish (shell) function which generates tab completion for several (D)VCSs, bzr is missing :-(
<gour> hg is covered with case '*'
<meuserj> getting a weird error doing a bzr status on a branch on an NFS mount:
<meuserj> /usr/lib/python2.5/site-packages/bzrlib/dirstate.py:237: DeprecationWarning: struct integer overflow masking is deprecated
<meuserj>   , st.st_dev, st.st_ino & 0xFFFFFFFF, st.st_mode))[:-1]
<Laney> Can I cherry-pick changes to commit?
<demod> Laney: iirc the record plugin can do that
<Laney> demod: I found bzr shelve, looks to do what I want
<demod> Laney: kk
<demod> hm, it was the interactive-plugin anyway... ,)
<vila> lifeless: ping, loom breaks the bzr test suite (6 test failing related to push), should I file a bug ?
<lifeless> vila: sure
<vila> lifeless: damn, I was hoping you would have say: "Holly cow! I'll fix that right *now*" ;-)
<lifeless> vila: I'm fixing 'why does gdm not list latin as a language even though I clicked on latin int he various gui thingys'
<vila> lifeless: gee
<beuno> abentley, ok, after a few hours of cursing, I've got the SQL to create the tables in MySQL, and, a problem while importing the bzr DB, due to single quotes in BLOBs
<abentley> Yeah, that's the kind of thing I ran into with that approach.
<beuno> I'll have to look into other ways of exporting data from sqlite, but I've got a reproducible list of changes to the sqlite dump that make it "mysql-importable"
<lifeless> vila: https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/234101
<ubottu> Launchpad bug 234101 in gdm "Support latin locale" [Undecided,New]
<beuno> abentley, I'm going to get some work done, and try a different approach
<pickscrape> I went though a lot of pain moving our trac installation from SQLite to Postgres because of string quoting issues
<pickscrape> Shortly after I muddled through it myself, they released an offical migration script
<pickscrape> Could be of use to you if you want to have a look at the code: http://trac-hacks.org/wiki/SqliteToPgScript
<abentley> pickscrape: Yeah, I saw that.  Unfortunately, it seemed very Trac-specific.
<pickscrape> I'll see if I can dig out what I did.
<lifeless> vila: and https://bugs.edge.launchpad.net/ubuntu/+source/langpack-locales/+bug/234105
<ubottu> Launchpad bug 234105 in langpack-locales "Support latin locale" [Undecided,New]
<pickscrape> Bad pickscrape. I can't have version controlled it. Shame: there was all sorts of clever shellery involved. :(
<vila> lifeless: regarding bug #234105 are you sure latins had telephone ???
<ubottu> Launchpad bug 234105 in langpack-locales "Support latin locale" [Undecided,New] https://launchpad.net/bugs/234105
<lifeless> vila: see my comment re accuracy :)
<vila> I saw it :)
<vila> lifeless: regarding loom, is there a reason for record to not be part of commit ?
<vila> I'm still unclear on when I should record...
<jam> jelmer, statik: ping
<jelmer> jam: hi
<statik> jam: hi! any chance you can host this week? I'm not able to punch a hole in the router for gobby here
<jam> jelmer: are you available on skype?
<lifeless> vila: yes, they are orthogonal operations, commit and record are definitely different
<jam> statik: I'll give it a shot
<lifeless> vila: you should record before you push
<jelmer> jam: yep, let me see if I can find a headset of some sort
<vila> the use case I have which seems broken is: bzr merge --uncommitted
<jelmer> jam: my skype name is jvernooij
<vila> lifeless: I use that when hacking on one "slow" machine and running the tests on a faster one
<jelmer> jam: one sec
<jam> jelmer: np
<vila> well, more precisely I do: bzr revert --no-backup; bzr pull; bzr merge --uncommitted (on the faster machine)
<lifeless> jam: whats 'notification' as opposed to the thing I wrote for bzr-gtk ?
<jam> lifeless: ask statik
<lifeless> statik: ^
<statik> lifeless: it just pops a notify_send bubble when a push or pull completes
<statik> notify-send even
<lifeless> statik: thats what the bzr-gtk commit-notify does
<statik> lifeless: cool
<lifeless> statik: I am smelling wheel reinvention :)
<statik> lifeless: i will have to check out commit-notify
<statik> the other one doesn't require me to do anything, I must need to do something to turn on commit-notify
<jam> jelmer: are you ready yet?
<lifeless> statik: you just run it, or set it on in the bzr-gtk prefs (though they seem somewhat borked at the moment)
<lifeless> statik: jelmer knows all about it, ask while you are on the phone
<lifeless> statik: it listens on dbus and can tell you about commits from other machines on your network if lan-notify is also running
<jam> lifeless: from what statik said, it also notifies you when a push/pull finishes
<jam> so you can start it, and switch your focus
<jam> and it will pop up when it is done
<jelmer> jam: almost - couldn't find a headset but I'm just going to use an external mike
<jam> jelmer: np
<lifeless> jam: commit-notify hooks on set_rh
<jam> lifeless: which doesn't trigger anymore :)
<jelmer> jam: Ok, I'm ready
<lifeless> jam: so modulo the obvious trivial update, which belongs in bzr-dbus, it sounds identical
<jam> lifeless: sounds similar to me, too
<lifeless> jam: (except commit-notify is devcoupled, yada yada yada
<jam> I don't use either
<statik> lifeless: sounds very cool, i should switch :)
<lifeless> elmo: https://pqm.bazaar-vcs.org/ errors now?
<LaserJock> any LP bzr people about? I'm wondering what happened to the gchemutils vcsimport
<LaserJock> as a related question, can cvsps import only a part of the history?
<hersonls> where a found documentation for loggerhead?
<lifeless> night all
<mtaylor> hey guys - what's the reasoning behind having bzr branch not set a default push location ?
<mtaylor> or rather, having bzr push not default to using the parent location?
<Jc2k> 90% of the times i've branched in bzr i've not pushed back to the parent
<Jc2k> (not a reason, just what i've found as a user)
<beuno> that's odd, it's the oposite with me, 90% of the times I push back to parent
<beuno> but I guess that's the beauty of DVCS
<fullermd> 90% of the time I never push anywhere   :)
<mtaylor> hehe
<beuno> alright, you win, we should remove push by default and make it a plugin
 * fullermd nods.
<fullermd> More secure that way.
<fullermd> Really, we should do the same with 'commit'.  It's far too dangerous a tool to allow people to use willy-nilly.
<beuno> yeah, and that should improve performance quite a bit
<mtaylor> so I'm guessing we don't have a default push location then because, well, because that would waste resources on fullermd's machine setting it
<beuno> yes, that sounds like a solid answer
<mtaylor> good
<mtaylor> as long as there is a reason
<beuno> if IIRC, this was discussed at some point, and some good reasons given for it, finding the thread will be impossible
<mtaylor> I figured
<mtaylor> I'm _guessing_ it has something to do with there not really being a "default" usage pattern for this
 * CardinalFang doesn't figure there are /good/ reasons, just reasons.
<beuno> it sounds like something lifeless would know, but he's changed timezone
 * mtaylor punches timezones in the face
<fullermd> Well, I would guess there are 2 factors.
<abentley> lifeless: I'd like to talk about looms.
<fullermd> One is that having the parent loc and push loc being the same is definitely a non-starter; there are vhastly many cases where that would be useless.
<fullermd> And the other is that the more you increase the number of "X uses the Y location, except if that's not set, then it defaults to Z" cases, the more confusing everything gets.
<CardinalFang> Different is fine.  Defaults, though?
<fullermd> (some might say we're already too far in that pit)
<beuno> mtaylor, http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/37064/match=default+push+location
<beuno> I could never understand how to navigate through gmane, but that's the thread
<mtaylor> beuno: great. that's a good summation I think
<mtaylor> CardinalFang: see above link
<jam> beuno: click on the "subject" link: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/37041/focus=37064
<beuno> jam, aaaaaaaah, yes, thank you  :)
<mwhudson> morning
<beuno> mornin' mwhudson
<tolstoy> Folks: I just installed bzr 1.4 (via the Mac OS installer) and I get a bzrlib problem. Anyone familiar with this?
<tolstoy> bzr: WARNING: bzrlib version doesn't match the bzr program.
<tolstoy> This may indicate an installation problem.
<tolstoy> bzrlib from ['/Library/Python/2.5/site-packages/bzrlib'] is version (1, 4, 0, 'final', 0)
<mwhudson> tolstoy: i did that yesterday, worked fine
<tolstoy> Did you install over the top of the bzr 1.3 installation?
<tolstoy> Might that be an issue?
<mwhudson> no, it was a clean install
<mwhudson> it indeed might be the issue
<tolstoy> Hm. I wonder if there are any uninstall instructions.
<mwhudson> tolstoy: what does `which bzr` say?
<tolstoy>  /usr/bin/bzr
<mwhudson> it sounds like you're getting the right bzrlib but possibly the wrong bzr script
<mwhudson> tolstoy: is there a /usr/local/bin/bzr as well?
<tolstoy> Yep. That's the issue.
<tolstoy> the /usr/bin/bzr has a _script_version_ of 1 3 0 (or something like that).
<tolstoy> I guess I can just delete it, but.... eek. ;)
<fullermd> Well, that's why it does the version checking   ;)
<tolstoy> Yep. Well, thanks for the help!
<tolstoy> I've re-arranged my path to prefer /usr/local/bin, at least for now.
<mwhudson> i would /guess/ that this was really a bug in the old installer
<mwhudson> it shouldn't really have been putting files in /usr/bin, that's naughty
#bzr 2008-05-23
<igc> morning
<hersonls> poolie: hi
<hersonls> poolie: where i found documentation of the loggerhead?
<yacc> I just wonder, is it possible to push a branch to two different branches concurrently?
<yacc> bzr push a in one terminal and bzr push b in another?
<poolie> yacc: yes, it should work, the readlock is not exclusive
<poolie> hersonls: in the branch for it i think
<poolie> well, "it should work" sounds uncertain, i know it will work
<yacc> Ok, if I've got bzr installed on the target, and ssh access, should I be able to do something that works faster than sftp:// ?
<spiv> yacc: "bzr+ssh://" rather than "sftp://"
<spiv> yacc: it's not much faster than sftp yet, but I'm working on that right at the moment :)
<spiv> (Some other operations are already faster with bzr+ssh:// though)
<yacc> spiv: well, I'm nailed to 1.3.1 on Hardy anyway (the PPA was missing bzr-svn last time I checked)
<yacc> Hmmm, the stupid thing complains about not finding bzr, despite that it's installed via a .deb on the server *scratch-head*
<spiv> yacc: Does "ssh host bzr --version" work?
<yacc> Nope, isn't that beefy.
<poolie> lifeless: hi, pqm seems to be having a lot of trouble
<yacc> spiv: ok, found the problem.
<yacc> It's not from a deb, it's in ~/bin :(
<spiv> yacc: you can still use it
<Rhamphoryncus> Anybody know of a grand trick to work around https://bugs.launchpad.net/bzr/+bug/150438?  Right now I'm afraid to touch it.  I'm thinking I should back up the whole repository, then probably end up recreating it all from my working tree :/
<yacc> Can I?
<ubottu> Launchpad bug 150438 in bzr "AssertionError: Could not find target parent in wt in wt4 _process_entry" [High,Confirmed]
<spiv> yacc: you just need to set bzr_remote_path in your locations.conf (or BZR_REMOTE_PATH as an environment variable)
<beuno> ls
<yacc> spiv: locations => ~/.bazaar?
<beuno> er, wrong window   :)
<yacc> spiv: And as I have no such file, what's the format?
<spiv> yacc: Right, ~/.bazaar/locations.conf
<spiv> yacc:
<spiv> [bzr+ssh://foo/]
<spiv> bzr_remote_path=/home/blah/bin/bzr
<yacc> Ok, ConfigParser with the URL as sections.
<spiv> (Or maybe the URL needs to be the local path?  I forget.)
<yacc> Nope, it worked fine with the prefix of the remote url ;)
<spiv> Ah, good.
<yacc> And even an empty push is much faster than sftp:
<yacc> 8 vs. 14 seconds.
<yacc> wall time.
<spiv> yacc: excellent
<spiv> (though that's still a bit slower than necessary I suspect)
<yacc> Well, both values are faster than bzr-svn ;)
<yacc> But then I guess I shouldn't complain, be happy that I can work with upstream without svn or svk ;)
<jelmer> yacc, empty push with bzr-svn should only be a few seconds - or is that not what you're doing
<jelmer> ?
<yacc> jelmer: well, actually the last time I did upstream it was 4 revisions.
<hersonls> lifeless: you be here?
<yacc> jelmer: Actually empty push seems to fine with 25s wall.
<jelmer> yacc, I wouldn't call 25s fine :-)
<yacc> jelmer: you are European too, so I would expect you better tuned to my cynism :-P
<jelmer> heh, ok :-)
<jelmer> yacc, are you running 0.4.10 ?
<yacc> Nope, 0.4.9
<yacc> jelmer: the Hardy packages in this case.
<jelmer> ok, 0.4.10 should be better in this regard
<yacc> svn 0.4.9
<yacc>     Support for Subversion branches
<yacc>     /usr/lib/python2.5/site-packages/bzrlib/plugins/svn
<yacc> jelmer: as I said I don't really complain. As the sole developer I do batch upstream pushes and nobody complains ;)
<jelmer> yacc: ah, ok :-)
<jelmer> yacc: In any case, if you can still reproduce this at the time you upgrade to 0.4.10, please file a bug
<yacc> jelmer: It's a bi-weekly operation more or less to me, usually when I ponder bzr log output for creative timesheet comments ;) => so the performance is really fine for me.
<beuno> abentley, I've pinpointed the single quotes problem, all I need is a good regex to catch the exceptions, and I think we're in business  :)
<hersonls> poolie: to resolve a text conflicts, i need run bzr revert first?
<beuno> hersonls, no, you have to actually resolve them. Take a look at the docs: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#resolving-conflicts
<hersonls> beuno: tanks
<beuno> hersonls, welcome'
<hersonls> i dont understand, i need uncommit to resolve conflict ?
<beuno> hersonls, no, why would you get that impression?
<hersonls> beuno: i try, bzr resolve test.py
<hersonls> beuno: and try merge again, and show me a message, "has uncommitted changes. "
<beuno> hersonls, you resolved all the conflicts and ran "bzr resolve test.py"?
<hersonls> beuno: after try bzr resolve, no showme any messages
<spiv> hersonls: what does "bzr status" report?
<ToyKeeper> beuno: Single quotes?  As when escaping a command to run?
<ToyKeeper> beuno: Can you use os.spawnvp() instead?
<hersonls> spiv: modified:
<hersonls>   teste.py
<hersonls> pending merges:
<hersonls>   hersonls 2008-05-22 Alteracao branch1
<beuno> ToyKeeper, this is for exporting sqlite and importing into mysql/postgre
<ToyKeeper> Ah, okay.  :)
<spiv> hersonls: ok, so you have changes to commit.
<hersonls> beuno: i need commit the resolv?
<hersonls> spiv: :D
<beuno> hersonls, yes, you need to commit every time you change the working tree
<spiv> hersonls: a merge edits the working tree, very much like editing it with your text editor.  Either way, you need to commit the changes to keep them.
<hersonls> beuno: obviously :D
<hersonls> spiv: i can edit the file with <<<<<< TREE?
<spiv> hersonls: yes
<spiv> hersonls: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#text-conflicts
<hersonls> spiv: i dont undersand, im brazilian and my english is bad
<sidnei> niemeyer: oi?
<hersonls> spiv: i edit the test.py or teste.py.THIS ?
<niemeyer> sidnei: Yo!
<sidnei> niemeyer: hey there!
<niemeyer> sidnei: How're things in the chimarrÃ£o land?
<sidnei> niemeyer: don't know, im in houston right now :)
<spiv> hersonls: test.py
<niemeyer> sidnei: Oh, yeah.. might be hard to get good chimarrÃ£o there ;)
<sidnei> indeed
<sidnei> niemeyer: btw, you've been talked about a lot this week over here
<niemeyer> sidnei: Oh, good to head, I guess :-)
<niemeyer> hear even
<sidnei> niemeyer: just introduced some folks to geohash yesterday to solve a problem
<spiv> hersonls: the THIS/BASE/OTHER files are just for reference if you want to look at them.  You can ignore them if you like, and they'll go away when you run "bzr resolve"
<niemeyer> sidnei: Nice!
<niemeyer> sidnei: What was it about?
<hersonls> ï»¿spiv: ok, i edit, and save file, and bzr resolve and finaly i commit, and push again.
<hersonls> spiv:  correct?
<spiv> hersonls: right
<sidnei> niemeyer: trying to locate greek orthotodox churches within a certain range of a user-specified location
<niemeyer> sidnei: Aha, I see
<hersonls> spiv: i update in brach, when i see test.py, "<<<<<<< TREE" this thera
<niemeyer> sidnei: It's good to see it being useful in diverse situations
<spiv> hersonls: you need to remove that yourself
<spiv> hersonls: that's the conflict that bzr can't do automatically
<sidnei> niemeyer: so, i just pushed that storm-mssql branch, long overdue
<spiv> hersonls: so you need to fix it manually
<spiv> hersonls: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#text-conflicts gives an example
<hersonls> spiv: removing ?
<sidnei> niemeyer: now, im not very experienced with bzr, so i am wondering if i should run bzr merge and do another push or what
<niemeyer> sidnei: Ah, I just got the mail about it.  Thanks a lot for sending it.  We're lucky that you didn't end up killing it thinking it was safe indeed.
<spiv> hersonls: the two branches have both made different changes to the same part of the file
<hersonls> spiv: ok
<spiv> hersonls: generally, what you want to do is have *both* changes after the merge
<niemeyer> sidnei: That'd be terrific.  It shouldn't have bad conflicts since we haven't changed pretty much anything in the area of backends.
<sidnei> niemeyer: got only one conflict apparently
<hersonls> spiv: more I corrected in one branch, I would not have to correct in the other after to make bzr push?
<sidnei> niemeyer: so if i solve that i can just do another push?
<niemeyer> sidnei: Right, solve conflict/test/commit/push
<spiv> hersonls: once you've committed the merge, other branches that branch/merge from your branch will tend to reuse your conflict resolution.  Is that what you were asking?
<sidnei> niemeyer: great, thank you
<niemeyer> sidnei: Thank you!
<sidnei> niemeyer: i have to go now, if you have some time later or tomorrow, i have a different subject to talk to you about
<hersonls> spiv: yes
<niemeyer> sidnei: Sure thing, I'll certainly be around tomorrow.. just ping me
<sidnei> thanks. cya
<hersonls> poolie: i can import another branch in one branch?
<hersonls> spiv: i can Commit an unversioned file or tree into the repository.
<hersonls> ?
<poolie> hersonls: by definition if it is unversioned you cannot commit it
<poolie> you must add then commit
<poolie> not sure what you mean about imports
<hersonls> poolie: i import of athoner branch ï»¿unversioned, for a new branch, for new versioned
<hersonls> poolie: you understand?
<poolie> sorry no
<poolie> can you explain more in smaller steps?
<hersonls> yes
<hersonls> i have one branch with skel versioned
<hersonls> and i create another branch, and need a copy of skel, in this new branch for new versioned
<hersonls> poolie: ?
<hersonls> poolie: you understand
<hersonls> ,w
<hersonls> ?
<Verterok> moin
<beuno> hey Verterok
<Verterok> hi beuno
<poolie> hersonls: you can branch the skel underneath it if that's what you mean
<hersonls> poolie: ï»¿one exemple of this, can be maked use: bzr export, and  bzr add in new branch
 * igc lunch
<poolie> hersonls: you could do that
<bob2> http://bramcohen.livejournal.com/52148.html
<mwhudson> some of those things make sense
<mwhudson> he doesn't have "use PQM" or anything like that on there though
<lifeless> hersonls: I am now
<lifeless> poolie: will inevestigate
<lifeless> abentley: hi; might be able to this afternoon, otherwise travel will obliterate theweekend
<poolie> lifeless: hello
<poolie> did you mean investigate pqm?
<lifeless> yes
<lifeless> after breakfast :P
<poolie> :)
<poolie> how's czech breakfast?
<lifeless> good and bad :)
<lifeless> lots of food
<lifeless> nice eggs, but shell too often
<lifeless> http://advogato.org/person/robertc/diary/83.html
<lifeless>  /wave
<spiv> Ah, "bzr push -r NNN --overwrite" is broken with bzr.dev (but not my branch where I've rearranged some of the involved code).
<liw> lifeless, the big pack file, ETA in 15 hours :(
<spiv> That had me confused for a bit, I was expecting bugs to be the other way around :)
<lifeless> liw: Not to worry, I shall play next week
<lifeless> poolie: web ui wasn't running
<lelit> jelmer: hi! I tried using bzrlib.missing.find_unmerged() to get the list of missing revision as suggested by jam, but it still takes a *lot* of time, with 100% cpu...
<igc> night all - have a good weekend
<spiv> igc: g'night
<poolie> lifeless: was it just lost in a reboot
<lifeless> yes, I think
<lifeless> we replaced the kernel after all
<poolie> thanks
<poolie> steve told me what you discovered re socket performance
<poolie> how odd
<spiv> Oh, what's the news there?
 * spiv calls it day
<lifeless> poolie: I think it was thread starvation
<lifeless> spiv: the slow tests on pqm were the reader thread in remote* tests spinning on recv
<lifeless> spiv: I postulate that some threading quirk in the dapper kernel combined with the GIL to lead to a priority inversion situation with the writer never activating
<spiv> lifeless: oh, funky.  So it seems to be gone now?
<lifeless> we replaced the kernel
<lifeless> its reproducible on other datacentre machines
<spiv> Interesting!
<spiv> G'night.
<lifeless> gnight
<lifeless> see you folk mondayish
<poolie> lifeless: are you still in prague?
<poolie> have a good/safe flight back
<poolie> hope you avoid heathrow :)
<lifeless> yes, avoiding heathrow :)
<poolie> well i think i'll call it a week too
<alienbrain> Can bzr read users from LDAP? Or is it possible to do by writing a plugin?
<poolie> alienbrain: interesting idea
<poolie> alienbrain: for what purpose?
<poolie> probably putting it into your systemwide nsswitch isbest
<alienbrain> poolie: usually organizations have centralized LDAP directories where departments are projects and people are recorded there. And the idea is that everything else should read from there.
<alienbrain> s/are/and/
<poolie> sure but what in particular do you want it to read?
<alienbrain> poolie: which users has access to which repositories :)
<poolie> oh i see
<poolie> could you send mail about this to bazaar@lists.canonical.com?
<poolie> i have to go...
<alienbrain> poolie: sure, be aware I'm not a bzr user yet! :)
<alienbrain> poolie: thanks
<Jc2k> hey guys
<Jc2k> am i right in thinking if i'm using bzr+ssh to push to server, that invokes the copy of bzr installed on the server?
<awilkins> Jc2k: Yes, although you can tell it which copy to use by setting the correct env variable
<Jc2k> awilkins: cool. can i use commit hooks to control where people can push to?
<awilkins> I don't know the hooks that well
<Jc2k> ok
<alienbrain> poolie: done
<lifeless> Jc2k: we tend to use file system permissions, because branches are direcotires
<lifeless> *directories*
<lifeless> Jc2k: its certainly possible to add hooks to the bzr server to allow such control
<Jc2k> lifeless: file system perssions seems like a better idea
<Peng> Does 'bzr pack' optimize the pack in any way?
<lifeless> Peng: yes; it orders the revision texts topologically
<sabdfl> spiv: fixing bugs before you even know they exist? that's neat
<liw> the default bzr storage format now supports tags; is there any reason not to convert existing branches/repos? I assume that's doable with bzr upgrade
<lifeless> yes, just bzr upgrade in each branch
<lifeless> for network, do bzr upgrade sftp://url
<liw> ack
<lifeless> repo's do not need to change to supoprt tags
<lifeless> just the branch object
<liw> find / -type dir -name .bzr | ...
<lifeless> liw: 'bzr branches'
<liw> lifeless, bzr: ERROR: Transport error: [Errno 107] Transport endpoint is not connected: u'/home/liw/.gvfs/.bzr/branch-format' [Errno 107] Transport endpoint is not connected: u'/home/liw/.gvfs/.bzr/branch-format
<lifeless> liw: interesting
<lifeless> liw: is your gvfs session active?
<liw> lifeless, I've no idea, how do I check?
<lifeless> i dunno
<lifeless> sabdfl: ping
<sabdfl> lifeless: pong
<lifeless> can rob savoye and I get together with you now ?
<sabdfl> sure, meet you at the reception desk in 5
<lifeless> where the admins are?
<sabdfl> yes
<lifeless> kk
<lifeless> abentley: ping
<abentley> lifeless: pong
<lifeless> make_mpdiffs
<lifeless> if I read this correctly, all it needs from the internals of a versionedfile is the _extract_blocks facility
<abentley> I would think so.
<lifeless> I'm thinking of putting _extract_blocks as a method on the objects yielded by the get_record_stream interface
<lifeless> how does that sound to you?
<lifeless> I think one problem is that it would actually get the content before checking that it can extract blocks from it
<lifeless> so for 1/200 (the delta chain length) we'd do more work
<lifeless> alternative, I can keep it where it is if you'd prefer
<abentley> Well, I wonder if it would be extra handling vs getting the blocks from the versionedfile.
<lifeless> (but migrated to the new api)
<lifeless> so what I was thinking is that the get_texts is going to iterate the contents *anyway*
<lifeless> because its going to be getting the contents of every version it wants to emit, plus the basis texts for the exit points of the dag
<abentley> And then extract_blocks only gives output against the build parent?
<lifeless> right
<lifeless> (as it does today)
<abentley> And then you have to figure out whether the build parent is the ancestor you want to diff against.
<lifeless> fulltext.extrct_blocks -> None
<lifeless> somedelta.extract_blocks -> delta_parent, blocks
<abentley> I don't think it makes a huge difference to me.
<lifeless> cool
<lifeless> I think I'll leave it where it is in order to port code; then see how it fits in the location I proposed
<abentley> There were two things about looms.
<lifeless> shoot
<abentley> One was the outstanding queue of patches.  I was wondering if you'd forgotten about them.
<lifeless> I had; I wish there was a bb instance to remember them for me
<gour> lifeless: nice post on the planet ;)
<lifeless> gour: :)
<abentley> lifeless: Well, I'll see what I can do about that.
<gour> lifeless: it's very encouraging
<lifeless> abentley: you could file 'merge requests' in launchpad for them into https://code.edge.launchpad.net/~bzr-loom-devs/bzr-loom/trunk
<abentley> The other is that I fear my practical desires and your design ideas are in conflict re: record.
<abentley> Basically, I don't want to record.
<lifeless> ok
<abentley> I especially don't want to have an extra step be required for push to work properly.
<lifeless> there is room to use the working-loom to avoid needing to record, though it obviously costs in the ability to collaborate on ooms because of the loos of 3-way mergeing
<lifeless> *or*
<lifeless> auto-record at commit, which will incur a cost in storage/depth
<lifeless> (and conflicts rather adly with handling merges and conflict resolution at the loom scale)
<abentley> I still don't understand when someone should record.  Doing it at push time sounds like you really should have done it earlier, but you're fixing it before it goes public.
<lifeless> you should record when you want people to be able to merge from you/before you merge from them (so you can revert)
<lifeless> just like in a branch you commit at the same points
<lifeless> anyhow, I'm very open to finding some compromise that works; a pure tool with no users -> fail
<abentley> It seems like I would want to record at every commit, more or less.
<abentley> Perhaps if I was merging from upstream, I would commit to all threads and then record.
<lifeless> right
<lifeless> I think if you bzr merge of looms actually did something it would be more obvious
<lifeless> there is room in the working-loom to do merge, but noone has written the code
<lifeless> it basically needs to zip from the bottom up, doing a pull where possible or merge otherwise
<lifeless> letting users resolve conflicts etc
<abentley> I would only want pull if the current revision was a lefthand ancestor of the other tip.
<abentley> But basically I was agreeing with the notion of auto-record at commit.
<lifeless> I'd like to get merge doing the right thing before doing that
<lifeless> because at the moment noone is really collaborating on a stack of threads
<lifeless> so its kind of like very early bzr where we didn't have merge :)
<lifeless> I agree that there are some possible options in the implementation of merge; they mainly seem to be policy related
<abentley> Every time I try to share a loom with someone, it doesn't work properly.  I haven't investigated.
<lifeless> I'm -> coding again
<jml> is there a doc (or a good example) for extending an existing bzr command in a plugin?
<matkor> What I have to do to have my patches sent Wensday to bzr-gtk@lists.canonical.com to  be visible in http://bundlebuggy.vernstok.nl/bzr-gtk/ ? As I understand it is right way of submiting patches for olive-gtk...
<matkor> Who can vote for patches BTW ?
<awilkins> matkor: If you're not a list member, your posts will languish in limbo on that mailing list
<awilkins> I had to subscribe to get my patches to arrive in the bundlebuggy in a timely fasion
<phanatic> matkor: the people who are considered the core contributors. like jelmer, beuno, abentley, schierbeck, vila...
<phanatic> matkor: but you could also request voting rights, since you contributed quite a lot in the past
<matkor> awilkins: I think I am subscribed, as I get e-mails form list ...
<phanatic> matkor: it could be the temporary brokenness of bb as well
<phanatic> matkor: did you send patches or bundles, erm merge requests?
<matkor> phanatic: I used bzr send <list> using kmail
<phanatic> then it should be fine
<tale_> I've created a local branch of a project on launchpad.  I've made some commits to my local branch, but I haven't pushed them back to the main branch.  Now I see that the main branch has some new commits.  What command should I use to update my branch with the main branch's commits?
<Peng> "bzr merge"?
<tale_> so i don't need to specify the main branch?
<radix> yes, "cd local-branch; bzr merge <main branch URL>"
<radix> "bzr commit" (after reviewing them or running the unit tests or whatever)
<bob2> (bzr remembers where you branches from and considers that the parent url, by default, for pull and merge)
<vila> phanatic: thanks for promoting me as a gtk core dev :) What do I need to do to log into gtk-BB ?
<phanatic> vila: oh, sorry, i thought you were one :) please ask jelmer for credentials, he runs the server.
<tale_> thanks.  That worked.  I'm loving the capabilities of bzr.  I wish I didn't have to use Clear Case at work!  :-)
<radix> hmm. if I used --fixes, how do I later find out what tickets a revision fixes? It seems it doesn't show up in 'bzr log' like --author does, which would be ideal.
<jelmer> radix: "bzr viz" can show you, I'm not sure if there's a way to do so on the command line
<radix> jelmer: I don't see it, maybe I don't have a recent enough version
<jelmer> there should be a "bugs" tab
<jelmer> but it's been added pretty recently
<matkor> jelmer: Any idea why my tiny patches sent Wensday to bzr-gtk@lists.canonical.com to  be visible in http://bundlebuggy.vernstok.nl/bzr-gtk/ ?
<matkor> jelmer: "to be visible" -> "are not yet visible"
<lifeless> elmo: vostok; loggerhead; swapping?
<CardinalFang> "bzr revid", like "bzr revno", would be very useful.
<CardinalFang> Any takers?  It should be easy, I'd think.
<Odd_Bloke> CardinalFang: File a bug if one doesn't exist. :)
<jelmer> matkor, hmm, odd
<jelmer> matkor, I'll see if I can find what causes it to break
<bob2> heh, bzr lookup-revision $(bzr revno)
<fullermd> CardinalFang: bzr revision-info | cut -f1 -d' '
<fullermd> Er, -f2.
<luks> bzr version-info --custom --template {revision_id}
<jelmer> matkor, should be fixed now
<matkor> jelmer: Thank you - should I  bzr send <list> again both patches ?
<matkor> Oh I see them :)
<Pieter> Hi. I'm trying to use bzr fast-export on the bzr repository, but it fails when trying to find revision john@arbash-meinel.com-20050711051006-2d11704675600e95
<Pieter> when doing a bzr log --show-ids, it can find a commit with that revision as parent, but not the revision itself
<Pieter> how is that possible? :)
<Peng> Pieter: Same results here.
<Peng> (For anyone else, it's r897, which does have two parents.)
<Peng> Pieter: Maybe bzr made more ghosts in 2005. I dunno.
<abentley> Pieter: Bazaar supports revisions like that.  They're called "ghost revisions".
<jelmer> lifeless, ping
<jelmer> lifeless, just wondering if you have an eta on when you'll be updating your shallow-branch branch to bzr.dev
<Pieter> abentley, Peng: ah, I didn't know that.. thanks :)
<Pieter> dato: any chance on an easy fix to support ghost revisions in bzr fast-export? :)
<lifeless> jelmer: EUDS
<lifeless> jelmer: maybe on the plane
<Pilky> anybody here who could explain in a nutshell what it is that makes bzr slower than other systems?
<jelmer> lifeless: k
<lifeless> Pilky: broadly; its mainly bugs
<gour> Pilky: it's not optimized yet, that's all ;)
<Pilky> heh
<lifeless> Pilky: in some cases we do do more work deliberately, to get a nicer user experience, but the delta in performance should be small once bugs etc are fixed
<lifeless> Pilky: we started with 'good ui' rather than 'fast performance'
 * gour likes such approach and that's why he migrated to bzr recently
<Pilky> just started thinking about it as I was talking to a friend who uses mercurial and he can do a log on 1000 revisions in 0.25s, took me 1.9s to do a log on 5 revisions :P
<Pilky> lifeless: much easier to improve bad performance than a bad UI ;)
<lifeless> Pilky: 'log --line' is more approximately what hg log does
 * pickscrape likens it to why Postgres is better than MySQL
<lifeless> bbiab
<gour> Pilky: i never 'understood' hg, but bzr 'just clicked'
<Pieter> why doesn't bzr log use a pager by default?
<Pilky> gour: I never fully looked into hg
<Pilky> I started looking at git and then glanced over hg before bzr took my attention
<gour> Pilky: i use(d) darcs for long time, but have chosen bzr as the next one
<Pilky> yeah, I used svn for half a year, used nothing for half a year then half used Xcode's snapshots feature for half a year
<gour> Pilky: git is, imho, too complex to invest lot of learning to understand its mechanisms...DVCS is just a tool, and bzr 'just works'
<Pilky> yeah agreed
<gour> hg could be ok, but it does not match my mind :-)
<Pilky> in my normal use bzr's speed isn't too much an issue, more speed would be a nicety
<gour> that's why i liked darcs, but it has problems which are not so easy solved
<gour> i agree. i do not need to handle linux kernel's history
<Pilky> but as I'm running unit tests against some code that calls bzr now, it starts to get a little bit painful
<gour> Pilky: the best it to play with bzr and see how it feels
<gour> Pilky: have you read http://www.advogato.org/person/robertc/
<Pilky> yeah, I've been using bzr for over a month now, it's just the speed annoys me slightly in my "not very usual" use case
<gour> bzr's speed is constantly improving
<gour> 'cause it gets lot of attention lately
<gour> soon it will be 'good enough' for all the tasks..
<Pieter> I hope bzr log path/ will get somewhat faster
 * fullermd hopes more that bzr log path/ will get somewhat useful.
<lelit> speaking of speed: jelmer, did you read my comment about find_unmerged() not being any faster than old way for me?
<Pilky> gour: yeah, bzr seems to be getting new versions pretty frequently
<lelit> it took 1h23min to fetch the missing changeset between an empty branch and bzr.dev (a local clone)
<Pilky> though I still haven't updated to 1.5 yet because the Leopard installer package hasn't been made yet (and I don't like going through MacPorts)
<gour> Pilky: right. another good reason to stay with bzr - regular (monthly) releases, active herd of devs and friendly #bzr community...what else you want?
<pickscrape> It doesn't make coffee for me yet
<Pilky> heh, a GUI, but I'm working on that one ;)
<fullermd> A marshmallow-pooping unicorn.
<gour> lelit: hi lelit. optimizing tailor?
<Pilky> a pony would be nice too :P
<lelit> gour, no, just making it more powerful :)
<gour> Pilky: there are two guis gtk+ & qt
<Pilky> gour: a native Mac GUI
<gour> lelit: testing with fallback VCS, nice ;)
<lelit> yep!
<gour> Pilky: there is, afaik, native gtk+ port
<Pilky> by native I mean, designed for the Mac
<gour> i see...no experience with Mac here
<lelit> gour: and now it seems that tailor has first class support for either VCS!
<lifeless> lelit: bzr --lsprof-file foo.callgrind
<gour> lelit: keeping the whole history? have you seen my reply to DVC ml?
<lifeless> lelit: post foo.callgrind somewere bzr devs can look at
<lelit> lifeless: but I'm not using the bzr frontend
 * gour recommends tailor to everyone for the migrating csets tasks
<Pilky> gour: well this is the mock up we have for bzr status in our OS X client: http://dropbox.mcubedsw.com/bazaarx/images/screenshot.png
<lelit> but I think that the bzr missing is using the same code path...
<lelit> I'll try that
<gour> Pilky: looks nice & clean
<lifeless> lelit: import bzrlib.lsprof
<lifeless> lelit: retvalue, stats = bzrlib.lsprof.profile(thing, args etc)
<Pilky> gour: yeah, it's what we're aiming for, plus we're hoping to integrate some Mac only stuff to make it better for Mac devs
<lifeless> stats.calltree(open('foo.callgrind', 'wb'))
<gour> Pilky: keep up the good job
<lifeless> lelit: you can look at it with kcachegrind yourself too; it will likely show something obvious:P
<Pilky> gour: will do :)
<lelit> lifeless: uhm, "bzr missing" is actually very fast, so I'm obviously doing something wrong...
<lifeless> :P
<lifeless> Well, time for the after conference event now
<lifeless> so ciao!
<gour> lifeless: take care ;)
<lamalex> Hi bzr folks, I'm trying to use bzr-svn, how does it handle authenticated checkouts?
<jelmer> lamalex, see the FAQ
<lamalex> er, any specific question?
<lamalex> the bzr-svn wiki page it links to doesn't exist
<jelmer> lamalex, http://samba.org/~jelmer/bzr-svn/FAQ.html
<jelmer> lamalex, Maybe there's a broken link somewhere - where did you find it?
<lamalex> http://bazaar-vcs.org/FAQ#head-563231e3f43f95a0e818d54ed945fd7c72a32faa
<jelmer> ah, sorry - I meant the bzr-svn FAQ
<lamalex> :P
<lamalex> np
<lamalex> thanks for the link
<lelit> uhm, I found what seems a "no way out" condition with the tailor bzr backend :-|
<lelit> it broke on http://pastebin.com/d8f22c27: what a strange patch indeed!
<lelit> how should one interpret the "xml6.py" life? was it added? removed? renamed?
<fullermd> xml6 existed before that branch.  In that branch, it was renamed to xml8 and a new xml6 was created.  Later in the branch, xml8 was deleted, and a new xml8 was created via a move from xml5 (and a new xml5 was created)
<fullermd> It shows removed on the old xml6 because the xml6->xml8, rm(xml8) was collapsed away so the move doesn't get shown.
<fullermd> Showing the file-id's makes it clearer.
<fullermd> removed:
<fullermd>   bzrlib/xml6.py                 xml6.py-20060823042456-dbaaq4atrche7xy5-1
<fullermd> added:
<fullermd>   bzrlib/xml6.py                 xml6.py-20080327235607-1skmbg4o9cd1o636-1
<lelit> fullermd: thnx, but how is that "bzr log" on that file does not brings up the previous (2006-08-23) patch?
<fullermd> Presumably, because you're `bzr log`'ing from now, which means you're actually logging the file xml6.py-20080327235607-1skmbg4o9cd1o636-1
<fullermd> So you only coincidentally see the changes to xml6.py-20060823042456-dbaaq4atrche7xy5-1 when they happen to have occured in the same revisions.
<fullermd> 3311.3.1 was the first rev where that [new] file existed, so it's the first you see.
<catlee> Hello
<catlee> I'm trying to use bzrlib to inspect a bzr repo
<catlee> I'm using repo = BzrDir.open(pathToRepo), and then repo.revision_tree(rev) to get a Tree object
<catlee> I want get a directory listing of one directory in the tree
<catlee> without walking the whole tree
<catlee> is there a way to do that?
<lelit>  lifeless: solved! the problem was that the code needs to be wrapped by a lock!
<abentley> catlee: Are you trying to avoid listing subdirectories of the directory you are listing?
<catlee> abentley, yes, I just want a shallow directory listing
<abentley> I don't know if we have provide a way to do that directly.  You could just look at InventoryDirectory.children, though.
<oly> I have been looking in the docs for an overwrite local type command, basically i want to re pull the remote overwritting my local changes and resolving conflicts
<oly> what command should i use for such a task ?
<abentley> oly: pull --overwrite ?
<oly> i tried that but it says no revisions to pull
<abentley> Are you sure you're not up to date?
<oly> i think because i did a pull, and it created a load of conflcits
<oly> i am uptodate, its just a mess basically, hence why i want the latest version from the server
<abentley> Oh, so you want "revert".
<abentley> It sounds like your branch is up-to-date, but you have local, uncommitted changes.
<oly> not sure is that a local revert ?
<abentley> Yes.  It just changes the tree contents.
<oly> probably not what i want then
<oly> i dont want a previous version, just all the files to match the online ones
<oly> i did a commit at work of my very latest changes and want to pull them to this machine, but i must of made change here at some point and taken them to work on a memory stick instead of committing them
<abentley> When you run log, what's the latest commit?
<abentley> Is it the online one?
<oly> yes
<abentley> So like I said before, your branch is up to date with the online one.  You just need to revert the changes in your tree.
<oly> lol, im confused now
<oly> bzr revert looks like its taking changes locally, so i thought i could then bzr pull --overwrite
<oly> but it still says im upto date
<oly> aha, i think its worked though thanks
<oly> even though i dont understand how
<abentley> The first time you pulled, you had local, uncommited changes in your tree.
<abentley> So it updated your branch and left you with a dirty tree.
<abentley> Then you reverted, and it changed your tree to match the latest revision in your branch, i.e. the online revision.
<oly> okay so its reverting to the latest online branch
<oly> that makes more sense, thanks for clarifying that
<abentley> It's the latest revision in your local branch.
<abentley> It happens to be the same as the latest revision in your online branch.
<oly> okay,
<lelit> yay! http://pastebin.com/d263128ed
<Pieter> bzr log --line only show commits on the mainline?
<beuno> Pieter, yeap
<Pieter> ah, that's unexpected.. I'd thought it would just display each commit on a line
#bzr 2008-05-24
<latexer> anybody have any suggestions for good "stastics tools" for bzr branches?
<beuno> latexer, there is a stats plugin written by jam, but I'm not sure what kind of statistics you're looking for
<beuno> latexer, bzr branch lp:bzr-stats ~/.bazaar/plugins/stats
<beuno> that should get it installed  :)
<latexer> yeah, i checked that out, it's pretty slim on stats though.
<latexer> i'm thinking something web based, show commit timelines, LoC added/removed maybe, etc.
<beuno> latexer, well, not currently, no
<beuno> I don't see it very far away, or too complicated even
<beuno> but it hasn't been done
<latexer> fair enough.
<ischnura__> Hi
<ischnura__> I have been playing with the gtk front end of bzr
<ischnura__> and I could not get the nautilus integration working
<ischnura__> does someone know how to get the plugin to work?
<beuno> ischnura__, what version of bzr-gtk?
<beuno> it was enabled in 0.93
<beuno> er, disabled
<beuno> so you should try 0.94
<Kamping_Kaiser> i find bzr a little strange at times :/ rename a file and it lists it as 'removed' name it back and re add it and its both removed and added ;|
<ischnura__> I am back sorry for the delay
<ischnura__> I am using Hardy with the version from the repositories
<ischnura__> 0.93
<ischnura__> beuno, Is there some configuration that I need to do in nautilus?
<bob2> Kamping_Kaiser: that's what bzr mv is for
<Kamping_Kaiser> bob2, yeah. i'm still getting used to having an rcs (and as such not using coreutils)
<bob2> (not using bzr mv does fracture the files history by storing a delete and an add)
<Kamping_Kaiser> drat.
<beuno> ischnura__, well, I'd use 0.94, where it's enabled by default, and many performance issues fixed
<ischnura__> beuno, thanks
<ischnura__> I will get the latest version then
<bob2> 'bzr mv --after oldname newname' will fix it if you haven't commited
<Kamping_Kaiser> i had commited, but i've reverted that change. bzr seems happy with it now for some reason.
<bob2> for reference, if you haven't commited anything else, 'bzr uncommit' might be simpler
<Kamping_Kaiser> neat
<Odd_Bloke> Kamping_Kaiser: See also 'bzr mv --after'.
<Kamping_Kaiser> thanks.
<bob2> another idea might be to alias commit to 'commit --strict'
<Kamping_Kaiser> looks like bzr has everything covered, if only i stopped to think and look in doco *heh*
<bob2> every vcs except for rcs and cvs have mv commands, fwiw
<Odd_Bloke> And most other VCSs don't track moves at all.
<ischnura__> beuno, I have read the README file in the 0.94 version
<ischnura__> they talk about installing a the python-nautilus package
<ischnura__> and to paste the installation files in .bazaar/plugins/gtk and the nautilus python script in  ./nautilus/python-extensions ...
<ischnura__> the problem is that it is still not working did you do any other extra configuration?
<ischnura__> beuno, did you do any extra configuration?
<beuno> ischnura__, try restarting nautilus
<ischnura__> sudo killall nautilus
<ischnura__> but still not work...
<ischnura__> I will try to restart the system...
<ischnura__> beuno, I will let you know if it works
<ischnura_> beuno, no luck
<ischnura_> I still can not get the nautilus integration to work...
<ischnura_> beuno, did you have to do any other configuration to get it to work?
<gour> morning
<gour> what do you think about 1st item in http://bramcohen.livejournal.com/52148.html ?
<spiv> gour: well, having two sets of half-done work is generally worse than having one finished thing
<spiv> So from that perspective, it's good to minimise the number of things you are doing at once.
<spiv> But I think he's too extreme.  Sometimes it's unavoidable.  Sometimes you do have a long-lived experiment, or need to collaborate with someone in a different timezone (e.g. "does this change fix the bug for you?").
<spiv> In fact, one of the great things about one-branch-per-feature is that if work on one feature isn't mature yet, that doesn't interfere with landing a different feature.
<spiv> He says in the comments "I just plan out what I'm going to do and then start typing, with very little experimentation and patch management."
<gour> right. branches are also not so expensive when we have shared repos
<gour> and can be easily discarded when feature is merged back
<spiv> That's fine if you're the only person working on the code, and you don't have process where all code is reviewed by someone else before it lands.
 * gour is accustomed to darcs where branching is quite normal operation
<gour> yes, that's what i was doing with darcs, not pushing stuff 'out' which is not stable
<Odd_Bloke> abentley: Is the BundleBuggy "This change has been merged." message a new feature?  I like it. :)
<gour> will new bzr-gtk still have dependency on seahorse?
<sabdfl> if it does, i hope seahorse learns to pop up in front of the window it's being used in, instead of hiding away
<RAOF> I think that's focus stealing prevention.  In my experience it happens under compiz but not metacity.
<gour> why seahorse and some extra gnome-stuff? gpa is not enough?
<antoranz> What's up, guys!
<antoranz> anybody awake?
<antoranz> I wanted to ask how to "efficiently" handle "new lines" between diferent architectures?
<bob2> hello
<bob2> ideally, use an editor that will not mess them up
<antoranz> but is there a way to make bazaar "figure out" how to handle the noe lines by itself?
<bob2> it handles them fine
<antoranz> perhaps with an option when run?
<antoranz> Yesterday I made a brnach of my project on a M$ mox
<bob2> if  you're asking for it to translate between platform native line endings, that's under development
<antoranz> and when a line was edited (on wordpad) when you sae the diff of the file, it was replaced from top to bottom (because of the new lines)
<bob2> right, notepad messed it up by not using the existing line ending format
<bob2> afaik auto translation is under development but close
<antoranz> notepad is not even an editor. :-)
<bob2> well, wordpad
<antoranz> and wordpad is close to noet being one either. :-D
<antoranz> so it's under development.
<antoranz> Is there a timeframe to have it on the stable or trial versions?
<antoranz> now... a question not directly involved with bazaar but close.....
<antoranz> let's say I will stick with the other guy working on windows.
<antoranz> and have his file replaced everytime.
<antoranz> i could "merge" his changes (which will make bazaar think the file has been rewritten from top to bottom)
<bob2> it's reallyt not a platform issue per se, it's an editor one
<antoranz> (yes... that's hat I told the guy.... that he needed to set up his editor to use Unix new lines.... and you know what he replyed? Hold on to your chair: He was very happy using windows and won't install GNU/Linux... HUH?!?)
<bob2> (I don't know when it will be released, but there's been increased chatter about it on the list)
<antoranz> so... as I was saying.... I get his files replacing mine completely.... is there a command (or series of commands) that I could run on GNU/Linux to replace all the M$ new lines for unix ones?
<antoranz> Just curious
<bob2> sure, dos2unix
<antoranz> or even better: series of command on windows he can run so he doesn't mess up the files? say just before committing
<Pilky> antoranz: is your friend using notepad for editing?
<bob2> on the flip side, most unix editors are competent enough to just not damage files with windows line endings
<bob2> so if you conceded defeat and use them, you should be ok
<antoranz> I just don't know what he will be using... it was just a "trial baloon"
<Pilky> if so, I strongly recommend something like notepad 2.0 which I believe can work with unix line endings
<antoranz> ok... you make it an editor problem and that's it. I don't know how I will be coping with that... I guess I can work dos2unix to "correct" HIS problem on my side.
<bob2> no, you misunderstand
<bob2> your editor will probably be happy with the line endings
<antoranz> Oh.. I know... kate has no problem with that at all.
<antoranz> but when he save (not saves... save) a file, if he's not careful, he will mess up bazaar and it won't be able to see line changes but file replacement instead
<bob2> how so?
<antoranz> say... I make a file... 100 lines long and put it in my repository
<bob2> unless you convert back on your end, it'll be fine
<antoranz> he "merges" it into his repo
<antoranz> opens it.... say.. in wordpad
<antoranz> he adds two lines
<antoranz> saves it
<antoranz> if he does a diff, bazaar won't see the two-line change
<bob2> ah, yes, that will suck, if you want this scheme to work, you'd need to add files with windows line endings, too
<antoranz> he will think the file as it was was completely removed and added 102 lines of code to replace it
<antoranz> I know.... that's exactly what we're taling about. The problem is that he won't install GNU/Linux so he can have the lines the way I want (man... I'm still wondering at his lack of understanding of the problem :-S)
<antoranz> :-)
<bob2> hehe
<fullermd> Take off and nuke the site from orbit.  It's the only way to be sure.
<bob2> well, at the moment you can either: use windows line endings yourself, or insist he uses a competent editor or use dos2unix a lot
<antoranz> ok... bottomline: bazaar agnostic new lines recognition is on the way
<bob2> at some point :)
<antoranz> I can use dos2unix to "correct other people's carelessness"
<antoranz> is there a tool that does the opposite for the windows side?
<bob2> well, if you run it after every merge from him and before he sees your tree, yeah
<bob2> unix2dos
<antoranz> for windows? OK.....  that's will do it... at the worst, I could add a batch file to the project that he could run before he commits.
<antoranz> man.... do I hate people at Microsoft
<fullermd> Could be worse; you could have Mac newlines mixed in too   :p
<antoranz> yeah! ;.)
<antoranz> I have never programmed for the CMD.
<antoranz> how can I build a while read line; do ; ; ; ; done < filelist.txt
<antoranz> if anybody knows, I mean
<name> antoranz: if he's got python i could help you :D
<antoranz> well.... If he didin't have it, bazaar installed it for him, cause bazaar is working
<antoranz> and that's obvious..... use python to do the job
<antoranz> as a matter of fact, I've been trying to get my head in python for a while... perhaps it could be a nice exercise to begin with
<antoranz> :-)
<name> antoranz: should i write a file ending replacer for multiple files for you?
<antoranz> nope... don't worry... I'll do it myself. ;-)
<name> antoranz: okay..
<antoranz> that's anyway, name
<name> it's not really hard anyway :)
<name> look at os.listdir
<name> and just replace ;) "\r\n" with "\n" or counterwise
<name> if you got any questions, just ask me, query if you want
<antoranz> ok. :-)
<antoranz> let me give it a try. ;-)
<name> ofcourse ;)
<bob2> os.walk would be simpler
<name> bob2: ah right, forgot that it could be multiple dirs :)
<antoranz> I won't start that high... I'll setup a file where the files that have to be checked will be.
<antoranz> I will think of simpler ways later
<antoranz> (once I get a grip on python)
<name> http://diveintopython.org is good
<name> (if you have some programming knowledge)
<bob2> if tou can't get this person to understand the issue, you might be better off just doing the work on your side
<antoranz> bob2: Well... after his response that "he won't install GNU/Linux", I'm starting to wonder if I'm better of by myself. :-D
<name> lol
<antoranz> but well.... I'll just create this script just in case I'm stuck with him. :-)
<name> and learning python is always good ;)
<antoranz> I know.. I know... I was just waiting for one excuse to come by... and it's here... so.... let's not waste anymore time, right? ;-)
<antoranz> let's see how I go,.
<name> antoranz: nopaste it so i can check how you did it :)
<antoranz> ok... I'll call dos2unix (to begin with).
<antoranz> (i mean... for my python script)
<antoranz> I'll do the whole job from the script later
<name> lol
<antoranz> don't laugh! :-)
<antoranz> I mean.. I'll create a script that will call dos2unix
<antoranz> a python script.... I'll change it later to do the converion by itself.
<name> what's the point of the script them o.O
<antoranz> give me a break, guys! :-D
<antoranz> that I can't make a while read line < file_with_filenames on cmd... can I?
<antoranz> :-P
<name> antoranz: think the python way, query? :D
<antoranz> what?
<antoranz> :-)
<antoranz> I'm sorry: say what?
<name> antoranz: if i can query you for that is offtopic here
<antoranz> if you can query me for what? :-S Man... I'm dizzy already
<name> antoranz: about your script
<antoranz> yea, my script
<antoranz> wan't to see how it's going?
<antoranz> I've made huge leaps forward
<antoranz> http://www.pastebin.ca/1027994
<name> antoranz: WOW!
<antoranz> Told you! :-D
<name> i can't speak spanish tho
<antoranz> well.... the first line is not important... but the rest of the script speaks for itself.... doesn't it?
<antoranz> do you recomend to use tabs or spaces for indentation?
<name> antoranz: that file contains the files to be converted, eh?
<antoranz> yes... (to begin with)
<name> i think i just wrote your script ;)
<antoranz> I already know that python uses indentation to figure out "blocks"
<antoranz> so which do you recommend to use?
<name> i use spaces, but with the tab key
<name> my ide does it well :)
<antoranz> ok
<bob2> pep8 (the python style guidelines) say 4 spaces
<bob2> but like name says, it is your ide's problem to sort that out when you hit tab
<name> WingIDE for the rule!
<antoranz> what do I have to import to use fopen?
<name> nothing
<name> use open
<name> or file, it's the same
<antoranz> it worked with open
<name> antoranz: loops are not the same as in C, for is not the same as C for...
<antoranz> give me a minute,... I think I almost got V1.0
<name> lol i sent u a paste o.O
<antoranz> what do you "pass" dos2unix? the name of the file and it will reconvert it?
<antoranz> no new file is created?
<name> u don't need dos2unix, just use replace of python
<antoranz> come on, guys... that's V2.0
<name> it's easier to do anyway ^^
<name> messing with subprocesses is not easy for windows
<bob2> it should be pretty easy with the subprocess module
<antoranz> V1.0: http://www.pastebin.ca/1028003
<antoranz> let me commit it in the repository ;-)
<name> why in gods name so complicated o.O
<antoranz> man... I'm a rookie! Give me a break
<antoranz> in a few minutes i'll have it working _your_ way
<name> using external tools is just as hard or easy as using python internals
<name> i tell you i've had loads of problems with subprocesses, namely wesnoth.exe for windows
<antoranz> let it go, man.... com eon... breath... count to ten. :-)
<name> i just warn you.
<antoranz> I'll do the change in a few minutes... hold on
<name> i had hundres of running processes with windows and loops and subprocess, tho it worked fine with linux
<name> *hundreds
<name> basically what u want is open(file, "w").write(open(file).read().replace("\r\n", "\n"))
<name> no guarantee for that tho :)
<antoranz> as I'm reading the filename from another file, I have a \n at the end of the filename
<antoranz> how can I remove it?
<name> antoranz: using readlines
<name> file.readlines()
<antoranz> same thing: No such file or directory: 'interfaz_standalone.php\n'
<name> then use .strip on the string, tho it should not happen
<antoranz> I hate python already. :-D
<name> antoranz: it just hates you ;)
<name> show me your code
<name> and i'm sure it'll be PEBKAC
<name> ;-)
<antoranz> archivo = archivo.replace("\n", "")
<antoranz> I'm not stupid, man... I know how to program, man... I just don't know my "resources" nor sytax with python... take it easy
<name> yes, that's what i mean
<name> but that replace will make it hard to tell between the lines
<antoranz> no no.. that's just for the name of the file I have to process
<antoranz> see ho it's going
<name> sure but aren't there multiple files in that file?
<antoranz> yes, there are
<antoranz> see how it's going
<antoranz> let me put it in  the pastebin
<antoranz> http://www.pastebin.ca/1028011
<lifeless> gour: the gtk dependency will be removed
<lifeless> gour: it should really be 'optional usage' but its buggy right now
<antoranz> guys.... I have to go for a while... I'll come back later to continue working on it
<antoranz> thanks for your kind help
<antoranz> name: thank you, man
<name> np, look at the code i sent you in query
<antoranz> I saw it... but I have to go to by some groceries
<name> okay hf
<antoranz> I'll come back to work on it later... I promise
<name> lol
<antoranz> take care.
<gour> lifeless: you mean seahorse dependency? what is bzr-gtk without gtk?
<Pieter> gtk doesn't depend on seahorse
<gour> Pieter: bzr-gtk was crashing without seahorse
<gour> my question is seahorse is really required for bzr-gtk 'cause it brings some gnome-stuff deps, instead of e.g. gpa
<gour> s/is seahorse/is if seahorse/
<jelmer> gour: The explicit dependency on seahorse is a bug
<jelmer> it's going to be fixed in the next release
<gour> jelmer: thanks. that's i wanted to hear ;)
<abentley> Odd_Bloke: Indeed.  Just implemented yesterday.
<lifeless> gour: I thought that was what I said ? :P
<gour> lifeless: "the gtk dependency will be removed" is not quite the same
<gour> lifeless: how can bzr-gtk be without gtk?
<lifeless> meh :)
<lifeless> I mean the erroneous dependency *of* bzr-gtk
<gour> np ;)
<antoranz> OK... I'm back! Hell... I'm very sleepy
<antoranz> |-)
<antoranz> OK... got it... perhaps it's a little rough... but it does the trick (just tried it)
<antoranz> http://www.pastebin.ca/1028099
<antoranz> thanks for your help, guys!
<antoranz> I'll be coming once in a while to see what I can help with.
<antoranz> C ya!
<Pilky> If I've just pushed to a launchpad and my friend hasn't changed anything since he last pushed, should he do bzr merge or bzr pull?
<Pilky> or are they both equivalent in this case?
<radix> Pilky: he should just pull
<Pilky> ok, cool
<Solarion> hmm
<Solarion> my repo seems horked
<Solarion> I think I unknowingly shut down during a very long operation
<Solarion> any recommendations?
<Solarion> bug #234647
<ubottu> Launchpad bug 234647 in bzr "bzr dies with parse error on corrupted history" [Undecided,New] https://launchpad.net/bugs/234647
<Solarion> ubottu: thanks
<ubottu> You're welcome! But keep in mind I'm just a bot ;-)
<gour> ubottu: it's nice that you help people here ;)
<ubottu> gour: Error: I am only a bot, please don't think I'm intelligent :)
<gour> ahh, i expected some more intelligence
<Pieter> how can I pull all branches at once?
<Verterok> Pieter: if you have bzrtools installed, bzr multi-pull
<Pieter> right, thanks
<lamalex> bzr won't add my directory! I do bzr add dirname and nothing happens
<lamalex> it's listed as unknown in bzr status
#bzr 2008-05-25
<Nyad> Hi. Some friends and I are looking at creating an opensource project, but we need a version control system which is easy to use and will work on either Sourceforge or the google code hosting thingy. We have narrowed our choices down to bazaar and SVK, is there any advice or extra info you can give that will help us come to a decision?
<lamalex> SF and google code both use subversion
<lamalex> you could use bzr-svn to interface if you want
<lamalex> or launchpad.net offers project hosting
<Nyad> but launchpad.net isn't under GPL
<Nyad> which would be easier to use? bzr-svn or SVK(which I think has a svn interface)
<Pieter> is google code GPL'd?
<Pilky> Nyad: why does launchpad need to be under GPL?
<Nyad> is it still free?
<Pilky> it's always been free afaik
<Nyad> tnx
<lamalex> Nyad: launchpad's license doesn't affect your code's license
<lamalex> you can license your code however you want
<lamalex> I think it does require and open license though
<Nyad> well we are opting for GPL or LGPL so that should be fine
<Pilky> lamalex: I don't think it requires it, but the fact that your code will be online implies it
<lamalex> Pilky: not necessarily, it could restrict modification/redistribution
<Pilky> true
<Nyad> so it's actually possible to put your source up but say nobody is allowed to modify it or spread it? but then can't people just port it and make their own version from the source?
<Pieter> no, that'd be modification
<Pieter> which you disallowed
<Pieter> so they'd be violating your licence :)
<Pilky> yeah, but in all fairness, how well do licences stand up in court
<Pieter> closed licences better than open :)
<Pilky> best way to prevent modification is to keep your source closed
<Nyad> thanks
 * dennda just created a bug report for that sftp issue
<dennda> https://bugs.launchpad.net/bzr/+bug/234682 <-- Do you feel like there's anything missing?
<ubottu> Launchpad bug 234682 in bzr "bzr fails in combination with ssh" [Undecided,New]
<fullermd> Your upgrade to 1.4, which includes a fix for that?   O:-}
<dennda> fullermd: Oh, it is fixed in 1.4?
<fullermd> https://bugs.launchpad.net/bzr/+bug/213425
<ubottu> Launchpad bug 213425 in bzr ""'SSHSubprocess' object has no attribute 'get_name'" with paramiko > 1.7.2" [High,Fix released]
<Peng> Does using curl provide any benefit over urllib?
<fullermd> Yah.  Paramiko 1.7.2 and later changed somethingorother; 1.4 and later have the update.
<Peng> bzrtools 0.91.0?!
<dennda> fullermd: When will 1.4 be released?
<fullermd> dennda: A month ago   :)
<dennda> I don't want to use the old paramiko version through the cheeseshop
<dennda> Oh
<dennda> why isn't it in the repo yet :/
<Peng> Apparently the Arch maintainers aren't big bzr users?
<fullermd> 1.5 was actually released a week ago...
<orphe> hi, i've got some questions about developping with bzr
<orphe> what would be the easiest way to work with bzr in ruby ...  i have seen some python wrapper for ruby so I would be able to import bzrlibs or to call system commands and parse the output from stdout .. or making a python application that makes xml or some others things that are easy to parse with bazaar as a backend
<beuno> orphe, you do have an xml plugin for bzr
<orphe> benuo : no but it would not be a problem to install... (such plugin exists) ?
<orphe> beuno: no but it would not be a problem to install... (such plugin exists) ?
<beuno> orphe, bzr-xmloutput
<beuno> I use it for PHP, Verterok uses it for Java  :)
<orphe> ow man , that will be alot easier than I tought. Thank you! this is really something interesting.
<orphe> with this i would still have to call bzr process but if I cache things until the repository is modified i would accelerate the process
<orphe> beuno, thanks that's a really good thing.
<beuno> orphe, no problem. Let me know if you need any more help on that, or if we can make your life easier with any feature
<beuno> the project's on Launchpad, so feel free to open bugs
<orphe> beuno, yes thank you again.
 * _moshez waves
<_moshez> a friend of mine sent a q to the ml (https://lists.ubuntu.com/archives/bazaar/2008q2/042391.html ) but got no answer :(
<_moshez> can anyone take a look and see if there's help?
<lifeless> hi _moshez
<lifeless> I'm travelling atm
<_moshez> lifeless: hello I squish your tummy
<liw> lifeless, 0 hours!
<lifeless> liw: excellent
<lifeless> _moshez: hello, I am squished!
<_moshez> lifeless: also, if you could take a look at the question, I would be happy
<_moshez> lifeless: though it would not stop the squishing :)
<lifeless> _moshez: short answer: you can register a dynamic hook which is a closure rather than a global
<lifeless> _moshez: closures are love
<lifeless> _moshez: or, you can refactor cmd_pull to better separation of UI and code, so that you can decorate the deeper guts rather than having to deal with the return value which is (deliberately) appropraite for shell evaluation
<_moshez> also dynamic hooks are strange
<_moshez> lifeless: yeah, we were kind of scared of actually touching bzr code
<lifeless> I think some refactoring and a patch to mainline would be best
<_moshez> lifeless: awesome I'll see what I can do about it :)
<lifeless> its pretty nice python I think, few people seem to have trouble doing cosmetic changes
<_moshez> lifeless: I think I'll get him to go on irc...
<_moshez> lifeless: not scared of the source, scared of the process :)
<lifeless> I will be flapping shortly
<lifeless> meh, its much lower entry cost than twists penultimate perfect quality thingy
<lifeless> a) write code. b) send patch via 'bzr send --mail-to bazaar@lists.canonical.com
<lifeless> c) profit!
<_moshez> lifeless: *hugs*
<_moshez> lifeless: so far, as a company, we have not written twisted patches either
<_moshez> lifeless: we don't have corporate experience contributing to free software :(
<lifeless> _moshez: ah!
<lifeless> Ve have vayz of making you kode!
<_moshez> lifeless: the problem is more between sending the patch and having it in a bzr version, we'd be afraid to use our own bzr
<lifeless> do you mean your own build?
<_moshez> lifeless: yeah
<_moshez> lifeless: we should probably wait for, ironically enough, moving to ubuntu from fc6 for that
<lifeless> so if you have a plugin, you'r running your own build :P
<lifeless> if you see what I mean
<_moshez> lifeless: distribution of plugins is easier
<lifeless> anyhow, fortunately bzr runs from a working tree trivially
<_moshez> lifeless: when we use ubuntu on developer desktops, it'll be easy to distribute custom builds
<lifeless> you only need one custom instance tho - the integration manager right ?
<_moshez> lifeless: probably
<lifeless> :P
<_moshez> lifeless: also the integration mgr actually already uses ubuntu
<lifeless> excellent
<_moshez> lifeless: so far, it looks like we'll be going for the dynamic hooks solution
<lifeless> patching pull would likely be better long term
<_moshez> lifeless: we intend to improve the integration mgr anyway, I'll possibly refactor pull then
<_moshez> lifeless: if we do it now, it would delay the move-to-bzr project
<_moshez> which I really really want to do ASAP
 * _moshez does the "yay bzr" dance
<lifeless> also,i fyou are doing non trivial business logic, consider working with the bzr domain objects directly
<lifeless> much richer scripting interface
 * lifeless does the yay adopters dance
<_moshez> lifeless: url for documentation of that?
<lifeless> pydoc bzrlib.branch.Branch etc
<lifeless> oror pydoctor
<lifeless> also doc/developers
<_moshez> lifeless: ah. we do that a little too in "surrounding bazaar" scripts
<_moshez> like our build downloader, which generates a mail after reading the bzr ci log :)
<lifeless> are you liking bzr?
<lifeless> liw: 0 hours -> done, or 'nearly'?
<lifeless> _moshez: did you see my 'scaling test' blog post?
<_moshez> lifeless: no :(
<_moshez> url me
<lifeless> http://planet.bazaar-vcs.org/
<liw> lifeless, when you check your e-mail, you'll find the location from which to copy :)
<liw> lifeless, (iow, done)
<lifeless> liw: most excellent
<lifeless> tell me now, I will start it coping in DC
<lifeless> is it the for-lifeless dir?
<lifeless> damn, tungestem only has 1.3G free!
<liw> lifeless, that's the dir, yes
<lifeless> cool
<lifeless> copying to manganese
<lifeless> _moshez: pretty cool if I do say so myself huh?
<Peng> I just ran bzr check for fun, and it says KnitCorrupt! :(
<Peng> An SHA-1 doesn't match.
<Peng> Some revision from bzr.dev from 2005, so it's not like I've lost data.
<lifeless> interesteing
<lifeless> what format repo?
<Peng> Packs.
<Peng> ...And wow, it sure floods .bzr.log.
<lifeless> plain, not rich root?
<Peng> Plain, AFAIK.
<lifeless> bzr info -v :)
<Peng> Yeah, plain.
<lifeless> ok, thats .. interesting
<lifeless> is it a mismatc on the inventory, or a file text?
<Peng> Inventory.
<lifeless> mumbe
<lifeless> mumble
<lifeless> we should track this down, but not from an airport lounge.
<lifeless> perhaps you could file a bug / ask a question in lp ?
<Peng> But tracking down version control consistency errors is what airports are for!
<Peng> Mailing list?
<lifeless> or that
<Peng> How active is the LP questions thingy vs. the list?
<lifeless> should be similar in terms of folkl witht he knolwdge needed to drill into this
<sabdfl> Peng: I see the same thing here, on bzr.dev
<sabdfl> KnitCorrupt: Knit inventory corrupt:
<sabdfl>   sha-1 a7b104d9ee824caed0e59a2989446419e230c4c2
<sabdfl>   of reconstructed text does not match
<sabdfl>   expected 873bfb499cc42b19241ac60c9736568abe2e4518
<sabdfl>   for version mbp@sourcefrog.net-20051027032619-323471e9b77bd69a
<sabdfl> Peng: you see the same one?
<Peng> sabdfl: Different revision for me, john@arbash-meinel.com-20051117204806-013b3027c63d642b
<sabdfl> iiiinteresting
<lifeless> ok, definitely file a bug on this
<lifeless> we have to identify whats going on here as a priority
<Peng> sabdfl: Wait a minute. How did your check not take half an hour to run?
<lifeless> if its statically bad, then there is already a bug open about why this is not detected outside of check; if its creeping bad find-and-fix
<Peng> lifeless: What do you mean? If it's not consistent which revision it claims is bad?
<sabdfl> Peng: as it happened, i started the same check an hour ago, on a whim :-)
<sabdfl> i was interested to see how long it would take
<Peng> sabdfl: Um, wow. That's a heck of a coincidence.
<lifeless> Peng: actually, he rooted your box and watched you doing check
<lifeless> Peng: but he'll never admit to it
<Peng> :)
<sabdfl> :-p
<lifeless> so I had a scare when I got to singapore
<liw> sabdfl = super-user accounts breaking daemon for lifeless?
<lifeless> at the transfer desk, when the agent mutters and mumbles
<lifeless> and you ask 'is there a problem', you don't want them to say 'you are not booked on that flight'
<Peng> ( https://answers.launchpad.net/bzr/+question/33093 is similar.)
<sabdfl> lifeless: and he said?
<lifeless> 'you are not booked on that flight'
<lifeless> I have a seat, and apparently luggage etc should be ok, and they haven't asked for a credit card, but something *whacky* is going on
<Peng> OK, it should die soon.
<Peng> (I'm running check again.)
<Peng> BTW, it was about the first versionedfile it was checking, according to the progress bar.
<fog> Hi, I have a serious problem with bzr 1.5 (and tool 1.5.0 as packaged in Debian): some commands, like commit, just hang indefinitely.
<fog> and if I break them with C-C then the tree is broken. even status reports an internal error.
<lifeless> fog: if you hit ctrl-\ it will drop you into pdb
<lifeless> there is obviously something wrong but I cna't help you right now - sorry.
<fog> lifeless: thanks, I'll try to debug it myself.
<Peng> Ok, "bzr checked" died again. Same revision.
<lifeless> if noone else can please gather what info you can and file a bug/post a message to the list
<lifeless> -> QF6 to sydney :)
<Peng> lifeless: Still want me to file a bug?
<lifeless> Peng: yes
<Peng> lifeless: Will do.
<Peng> lifeless: Have a good flight. :)
<_moshez> lifeless: so I was going to mention that it would be nice if people would get responses to mail
<_moshez> lifeless: it used to be the problem with twisted, btw, that you could only get the information if you were on irc :(
<lifeless> _moshez: most mails get answers; you can tell from the archives
<lifeless> _moshez: but most of the core devs are not volunteers, and tend to do other things in weekends
<lifeless> really gone
<Peng> Y'know, the spinner in the progress bar is kind of bad over ssh.
<Pilky> is anybody using a checkout for putting changes onto launchpad, but using a branch to do most of their dev work?
<Pilky> because I'm just thinking about how to do the merging and such... am I right in thinking that you can't push to a checkout
<Peng> Try it.
<Peng> If you push to a checkout, I think bzr will push to its parent.
<Pilky> hmm
<Peng> I don't use checkouts at all, except for the occasional lightweight checkout, but even then only rarely.
<Pilky> well I'm thinking of me and my friend each having personal branches, plus the checkout of the central repo
<Pilky> when we want to put something onto launchpad we merge into the checkout and then commit
<Peng> I'd use a branch and merge, commit, push. Shrug.
<Pilky> yeah, we're just finding some problems with that with us both working on the same branch
<Peng> What problems?
<Pilky> lots of conflicts and such, just seems to be a bit more awkward
<Pilky> I saw it mention using a checkout for putting stuff into launchpad and a separate personal branch for doing most of the editing in the launchpad docs and thought it sounded like it would work better
<emgent> heya
<gumpa> Howdy, I thought I could "bzr init-repository <myrepos>", do "bzr init <mybranch>" in <myrepos> and then bzr push bzr+ssh://..+junk/myrepos, guess not eh?
<gumpa> can only push a branch, not a repository?
<radix> gumpa: indeed
<gumpa> thanks
<Nyad> Hello, apparently bazaar only partially supports end of line conversion. isn't this bad if we have developers from different OS using bazaar for our project?
<bob2> depends
<bob2> if everyone uses an ok editor, it won't matter
<bob2> for source/text files, at least
<Nyad> so basically all our editors must use the same end of line ascii characters. but that would restrict us to not being able to use any editor
<bob2> no, not at all
<bob2> you just need an editor that ill sue whatever a file already uses
<bob2> er "will use"
<Nyad> why hasn't bazaar added this end of line conversion?
<bob2> but a cvs-esque feature for bzr is under development
<bob2> doing it cleanly is hard, and no one has done it yet (well, not had it merged into mainline)
<Nyad> so if we start our project with the windows ascii value for end of lines then kate and wordpad will keep it that way?
<bob2> never used kate, but I would be surprised if it didn't
<Nyad> ok tnx
<TheSheep> wordpad coul have problems
<Nyad> which would you say is easier to use, bazaar or SVK?
<bob2> with windows line endings?
<Nyad> yes
<TheSheep> bob2: ah, sorry
<bob2> bzr for sure
<bob2> svk will get upset if you move a checkout
<Peng> The only options are bzr or svk?
<Nyad> for us, we narrowed it down to those two
<bob2> why not hg as well?
<Nyad> never heard of it
<Peng> You should have.
<Nyad> how does it compare to bazaar and SVK?
<Nyad> or is it not really important which we use?
<Peng> I like both bzr and hg. They both have their upsides and downsides and IMO it's a toss-up. I've never used svk and don't plan to.
<Nyad> ok thanks. I have to go now
<Nyad> I will look into hg
<Peng> Oops.
<bob2> haha
<Peng> "Hello, welcome to #bzr. You should try out hg!".
<Peng> I got yelled at a bit for that once. :\
<Peng> I'm just not very brand-loyal.
<TheSheep> I think it's important to just be honest and to recommend whatever sems best in the situation
<TheSheep> seems
<fullermd> Which is obviously ClearCase.
<Peng> In this case, hg does have line ending conversions, based on globbing the file path.
<Pilky> not quite sure how the line endings are that big a problem unless you use a crap text editor
<Peng> It's nice to set that "just to be safe". When one developer uses a weird editor just once and doesn't notice, it makes a bit a mess of history.
<Pilky> true
<Kinnison> 3
<Kinnison> oops ,w/w sorry
<sabdfl> Peng: i saw you saying that bzr check is slow for you. it's fast for me. what are you comparing it to?
<Peng> sabdfl: I just mean vs. "hg verify".
<sabdfl> are you sure they do the same level of analysis?
<Peng> sabdfl: hg verify is so fast that I doubt it does much of anything.
<sabdfl> then it would seem unfair to criticize bzr for doing a rigorous job ;-)
<Peng> :)
<visik7> can I remove files from a repository ?
<Pilky> visik7: bzr remove [FILES...]
<Pilky> add --keep to the end if you don't want the files deleted on disk
<visik7> Pilky: from a shared repository not from a branch
<visik7> I've removed from a branch but the shared repository still contains the files
<Pilky> visik7: I think if you push to the shared repo it will remove it
<visik7> mmm no
<LeoNerd> Umm... it can't.
<visik7> I've erroneously versioned 200mb of jpeg
<LeoNerd> Half the point of revision control, is that you can check out an earlier point in history
<visik7> and now they are in the .bzr of the shared repo
<LeoNerd> So that data has to remain in the repo
<LeoNerd> What I suggest you do is create a new branch that cherrypicks the old one, and don't include the revision that added that file
<LeoNerd> Then you'll be left with a new branch that has "holes" in the history; that one file never existed. You can then push this new branch back over the old one
<Pilky> oh, you were wanting to remove the actual file
<LeoNerd> I imagine this is one of those usual "I want to pretend this file never existed" situations..
<LeoNerd> Usually they come up either by someone adding/commiting a file of secrets (keys, passwords, etc..) or from just adding really big junk files
<Rhamphoryncus> oww.. printing out the full tree is not a very useful debugging message
<grantgm> is it possible to get a 'bzr stat'-style difference between branches? 'bzr status -r ../../criss/' gave me this error: http://pastebin.ca/1029096
<Peng> grantgm: bzr help revisionspec
 * Peng leaves.
<grantgm> right. i meant bzr status -r branch:../../criss/
<grantgm> that should work, no?
<Pieter> what d=
<Pieter> output would you expect?
<grantgm> as i said, i was looking for a bzr stat between two different branches
<grantgm> but it errors out (full message in at http://pastebin.ca/1029096)
<Pieter> yes, but what should it show? what if both have changed a file? or just one?
<grantgm> well, i would expect it to use the directory given as the old one, and the current directory as the new. Thats the convention, right?
<grantgm> So if there was a difference between the files, it would be under 'changed', regardless of which branch made the change
<Pieter> not for stat
<Pieter> you can do a bzr diff between the two
<grantgm> I guess I don't understand what the -r arg does for stat, then.
<grantgm> Can I get diff to just show me which files have changed, rather than the actual changes?
<grantgm> thats really what I'm looking for. stat just seemed to be the most obvious way to do so
<grantgm> thanks for the help, btw
<grantgm> hmmm...looks like this is a known problem: https://bugs.launchpad.net/bzr/+bug/144421
<ubottu> Launchpad bug 144421 in bzr "Using branch: revspec in stat blows up" [Undecided,Confirmed]
<grantgm> bzr diff --old=../../criss  --using=diff --diff-options="--brief"
<grantgm> fwiw, that seems to do essentially what I'm looking for
<asabil> how can I resolve a directory conflict ?
<beuno> lifeless, when you deprecated get_revision_graph in 1.4, what would be the way to do it now?
<igc> morning
<poolie> hello
<igc> hi poolie
<poolie> hello
<spiv> Good morning.
<beuno> morning everyone
#bzr 2009-05-18
<igc> morning
<krisfremen> is there a way to get only one file from a revision?
<Peng_> krisfremen: "bzr cat -r 123 foo.py"
<krisfremen> awesome thanks
<AfC> krisfremen: which is also really handy when you have a forest of Branches that do not have Working Trees present with them
<Peng_> Indeed.
<AfC> krisfremen: and you need one or so files out of it
<krisfremen> yes, that's what i need it for
<jelmer> igc: hi
<jelmer> igc: I've just added http://bazaar-vcs.org/ConvertCommand
<jelmer> igc: it touches on upgrade a bit as well, since they might share common code
<igc> hi jelmer
<igc> jelmer: thanks for the rio stuff
<igc> jelmer: one thing that would help though ...
<igc> is to move the escape logic down somehow ...
<igc> so that knowing whether to xml_escape or not doesn't need to be handled at higher layers multiple times
<jelmer> igc: the problem is that we don't know if we're re-serializing an existing revision
<igc> I had to tweak fast-import to disable it and I imagine ...
<igc> that you'll need to do the same in svn-import, etc.
<jelmer> igc: we could always escape in the XML serializer
<igc> jelmer: or even the repo layer
<igc> I just want to get it out of commit.py, fast-import, etc.
<jelmer> igc: yeah, that would be really useful
<igc> jelmer: if nothing else, we might need a flag on the format saying whether to escape messages or not
<igc> jelmer: btw, I fast-import OOo over the weekend
<igc> 36 hours altogether, though only 1 hour for the first 50K so ...
<igc> there's room in there to improve things a lot I think
<jelmer> igc: into dev6 or into 1.9-rr ?
<igc> dev6-rr
<jelmer> igc: about the xml char escaping, do you think it would be acceptable to just push it into the serializer and not have commit print warnings about squashed characters?
<jelmer> alternatively, I guess we could propagate that number somehow
<igc> jelmer: I think the serialiser is the logical place for it but ...
<igc> I worry about backwards compatibility
<igc> that's why I suggested the repo layer
<jelmer> igc: backwards compatibility in what sense?
<jelmer> igc: we don't really escape special characters at the moment, we squash them (we don't escape "\" itself)
<igc> jelmer: if plugins assume the serialiser does or does not do it
<jelmer> igc: it's not a problem if plugins escape too
<igc> jelmer: I guess not
<igc> jelmer: hopefully our tests we tell us :-)
<h6w> Gday.  I have an existing svn+ssh repos, and I've installed bzr-svn.  What would the url be for the bzr exposure of the svn repos?
<jelmer> h6w: same URL you would use with svn
<h6w> bzr+ssh://.....?
<jelmer> h6w: no, svn+ssh://..
<h6w> Oh really?
<h6w> Sounds a bit confusing, but, oh well.
<jelmer> h6w: well, it's the svn+ssh:// protocol that you're using with bzr
<jelmer> h6w: bzr+ssh:// would be the bzr protocol
<h6w> oic.  I installed the bzr-svn plugin on the server, expecting it to do the translation server-side.
<h6w> So I'd just use bzr on my client.
<jelmer> h6w: that might work too (with bzr+ssh:// then, but I've never tried it)
<h6w> ok, will try that.
<jelmer> h6w: looks like that doesn't work for some reason
<jelmer> spiv: ping
<jelmer> h6w: so you'll need bzr-svn on the client instead and use svn+ssh://....
<h6w> ok.  Or else just shift the entire repos.
<h6w> The whole point was so that we could do a smooth migration from svn to bzr.
<jelmer> h6w: you can do such a smooth migration that way, it's just the URL that's different
<jelmer> h6w: if you later convert the repo on the server from svn to bzr using "bzr svn-import" you just adjust the URL and things will still work
<h6w> I think that's going to have to be the way to go.
<h6w> I was just hoping to have commits and updates work through both protocols while we tested it.
<h6w> We have one client (Launchpad) that doesn't do bzr-svn, only bzr.
<jelmer> h6w: it's probably an easy fix to support bzr+ssh:// for svn repositories, it's just that nobody has asked for it before
<jelmer> lifeless,spiv: ^
<lifeless> jelmer: huh?
<lifeless> jelmer: do you mean, bzr-svn running on the server?
<jelmer> lifeless: yeah
<h6w> Yes.
<jelmer> lifeless:  the smart server raises NotBranchError for some reason, any idea what could be causing that?
<lifeless> doesn't really make, sense that would be a site-to-site thing like 3rd-party ftp
<lifeless> or perhaps I don't understnad what you mean
<h6w> Serving bzr requests via bzr url and piping them to an existing svn repos on the same server.
<jelmer> lifeless: Using bzr+ssh:// to access a Subversion repo on the server
<lifeless> jelmer: bzr-svn would need to find an svn repository given a file url
<SamB> jelmer: why should that be needed?
<jelmer> lifeless: it can do that
<lifeless> jelmer: into the repo, not into a tree
<SamB> why not just use svn+ssh ?
<jelmer> SamB: see above
<jelmer> lifeless: yes
<lifeless> jelmer: then it should, in principle, just work
<jelmer> lifeless: What's the easiest way to debug if it doesn't?
<SamB> hmm, how do you break an ssh-started program into a debugger ...
<lifeless> jelmer: use raw bzr://
<lifeless> jelmer: start a server via bzr serve
<lifeless> and then use pdb and or ctrl-\ juidiciously
<SamB> oh, I guess that would work ...
<SamB> jelmer: why don't you just check ?
<lifeless> its exceedingly unlikely that ssh is part of the problem
<SamB> oh, you did
 * SamB wonders why he said "if"
<lifeless> did you?
<jelmer> lifeless: it loads the plugin but never even calls the probe function
<lifeless> jelmer: the smart server uses the standard interface
<lifeless> jelmer: break in bzrlib.smart.bzrdir .. OpenBranch
<SamB> lifeless: standard interface ... ?
<lifeless> SamB: as opposed to a nonstandard one
<SamB> lifeless: do you have a link to the documentation of this interface?
<jelmer> lifeless: found the problem
<jelmer> lifeless: it only tries to do an open with BzrDirMeta1
<jelmer> lifeless: bzrlib/smart/bzrdir.py:52
<lifeless> oh
<lifeless> fugly
<lifeless> iz bug
<jelmer> filed
<jelmer> lifeless: oh, and ChrootTransport doesn't provide local access?
<lifeless> jelmer: no
<lifeless> it provides whatever its back on, no more
 * SamB wonders what ChrootTransport is ...
<AfC> What's the bzr-svn URL now? I have http://people.samba.org/bzr/jelmer/bzr-svn/trunk/ but it's not redirecting anywhere.
<SamB> AfC: symlinks don't usually cause HTTP redirection ...
<AfC> SamB: apache configurations do, though
<SamB> AfC: well, I believe that's always going to be the trunk of bzr-svn, and I don't think it's ever redirected for me unless I left off the /
<AfC> SamB: oh; so you believe that URL to be correct?
<SamB> AfC: assuming you're not getting an error
<SamB> oh ... actually, I'm using http://people.samba.org/bzr/jelmer/bzr-svn/bzr.dev/
<AfC> SamB: ok, thanks
 * SamB was just confused by AfC's expecting it a redirect
 * igc lunch
<lifeless> -> spain
<poolie> lifeless: ping? still in sydney?
<bob2> 14:12:17 < lifeless> -> spain
<bob2> poolie: ^
<poolie> ah i thought so
<lifeless> poolie1: at the airport
<lifeless> poolie1: can I do something for you?
<lifeless> poolie1: you have a 10 minute window before I'm forcible un-wifi'd
<lifeless> ok, boarding call ;)
<lifeless> ciao
<Peng_> Bye. :)
<lifeless> actually, misheard :)
<lifeless> 16:30 I have to board
<Peng_> 14 minutes from now?
<Peng_> Well, enjoy your last 13.5 minutes of wifi. :)
<lifeless> yes
<lifeless> though pinging my home client could be wrong :)
<abeaumont> good luck with jet lag... since it's 8:17am here
<Peng_> So, um, why are you guys always flying all over the world?
<lifeless> we get together for sprints
<lifeless> different areas of the company do this at different times
<lifeless> this particular one is everyone in the company, which is way cool
<Peng_> Oh, okay.
<lifeless> and happens ~ once a year
<lifeless> wow, DCO's look evil
<poolie1> hello lifeless
<poolie1> no, nothing important
<poolie1> DCOs?
<lifeless> device configuration overlay
<lifeless> for vendors that want to sell '60 GB drives' but their supplier gives them 65GB drives.
<lifeless> apply a DCO and most everything sees it as 60
<lifeless> just reading up on HPA's due to finding the BIOS HPA support on my desktop flaky, I decided I should know more about it
<lifeless> and the best doc I've found so far is from the journal of investigative forensics :)
 * lifeless waves
<poolie1> fly well
<Peng_> Fly well? The airline industry is doing so badly that passengers have to flap their arms now?
<awilcox> Hi, is there a facility on Bazaar similar to subversion's tags?
<awilcox> I would ask my bzr repo's maintainer but he has been offline for quite a while so I cannot
<Peng_> awilcox: Bazaar supports tagging, but branches are more similar to svn tags.
<awilcox> Ah.
<fullermd> Peng_: Well, if you believe the version control/airlines thing...
<awilcox> My project is closing in on a release and I'd like to "branch" the tree I guess, so that this version can be out of trunk and be worked on separately
<Peng_> awilcox: Then use a branch.
<awilcox> That way, last-minute bug fixes can be done by the QA devs on the branch, and me and the rest of the team can be adding shiny new features to 2.0
<awilcox> Okay.
<fullermd> Have a branch for the release engineering, and tag the release on it, is SOP.
<awilcox> fullermd: is there a tutorial for doing this?  Because I looked on the wiki and it does not say how to make a branch
<awilcox> I am an utter n00b when it comes to bazaar.  I mean, my repo maintainer taught me how to use checkout and resolved and said "anything else read the manpage"
<awilcox> And the manpage doesn't seem to cover tags and just mentions what branches are, not how to to create one =/
<fullermd> `bzr branch foo bzr`
<fullermd> Aargh.  Dangit.  bar.  bAr.  With an A.
<Peng_> :D
<awilcox> Hah.
<awilcox> So it would be like bzr branch trunk release ?
<awilcox> Where do I run that from?  I have ssh to the server...
<fullermd> Well, one general way would be to put it right next to trunk.
<awilcox> Right.
<awilcox> It would be like foo.com/project/trunk  or foo.com/project/release
<Peng_> Unless you only want to make one release, it might be better to name the branch "1.2" or whatever.
<fullermd> Or better, since you're going on with 2.0, name the branch RELENG_1 or something.  Then you can add branches off that for 1.0.x or 1.1.x releases or whatever's needful later.
<awilcox> He said make a branch for releases and tag the release on it
<Peng_> Well, it's your choice. Some projects just have one "stable" branch for the current release.
<awilcox> Okay so we'll have a RELENG_1
<awilcox> Okay I am at /home/awos-bzr/repos/awos
<awilcox> I see: branches and trunk
<Peng_> This isn't CVS, you don't need to keep caps lock on. :P
<awilcox> Do I just cp trunk branches/1.0 ?
<Peng_> awilcox: "bzr branch".
<fullermd> Well, you maybe _could_, but using 'branch' would be better.
<awilcox> Okay
<awilcox> bzr branch trunk branches/1.0 ?
<Peng_> IMO it's silly to have a "branches" directory, but yes.
<fullermd> Users get offended when it's called "oldcrap" instead...
<awilcox> Branched 670 revision(s).
<awilcox> So now if I commit to the branch, it will have revision 671, and that will be separate from trunk revision 671, yes?
<nok4> hi, i don't want bzr to track the file mode/ownership changes, how to do that?
<Peng_> nok4: All it tracks is the exec bit. If you want to turn that off, um, I don't know how.
<Peng_> awilcox: Yes.
<awilcox> Peng_: Awesome
<Peng_> awilcox: Y'know, you can merge the release branch back into the trunk when you make changes.
<awilcox> Thank you Peng_ and fullermd for your help, it is much appreciated :D
<nok4> Peng_: ok, i'll try chmod the x bit to work around it.
<Peng_> Why does the index have to be probed to figure out that there's nothing to pull?
<thekorn> hi, I've got a question about using hooks: is it possible to ship a hook within a branch?
<thekorn> as far as I understand the docs a hook has to be in ~/.bazaar/plugins
<thekorn> but I'm looking for hooks on a per branch basis, so something like mybranch/.bzr/hooks
<awilcox> Peng_: How do I merge?
<Peng_> awilcox: "bzr merge". :D
<awilcox> ahhhhhh
<Peng_> awilcox: Read the tutorial and/or help.
<awilcox> That should have been obvious.
<awilcox> :P
 * igc dinner
<awilkins> thekorn: No, you can't ship hooks in a branch unless you do it and get the users to run a script that installs them
<awilkins> thekorn: Bazaar will by design not execute stuff in a branch automatically
<thekorn> awilkins, thanks, so it won't make sense to file a wishlist bug, as this is by design, correct?
<awilkins> thekorn: I'd agree with that
<fullermd> Well, it's probably something we'd like more mechanism for.  So it's wishlist in a sense.
<thekorn> it would be nice to have especially for hooks which don't do any harm, like commit_message_template
<thekorn> but I can live without it, just curious
<pygi> thekorn: plugin plugin plugin
<pygi> you can do almost anything in a plugin
<thekorn> pygi, I'm sure you can, so write me a plugin which allows me a define a commit_message_template hook within a branch ;)
<pygi> thekorn: w00t xD
<pygi> catch me during UDS, we might talk if its really something you need
<pygi> :p
 * pygi hides
<thekorn> pygi, ok, ok, I'm also not sure if I really need it
<pygi> ehhe
 * pygi shoots thekorn 
<fullermd> Well, it's kinda a bootstrap problem   :p
 * thekorn switches over to git
<fullermd> Making a plugin that forces somebody not having the problem to get the plugin has minor temporal difficulties.
<fullermd> s/problem/plugin/
<thekorn> right, I think I will just trust the contributors to the project to always use the template for commit messages we agreed on
<fullermd> Yah.  Social problems are best handled with a cattle prod   8-}
<Kinnison> Forcing a given template for commit messages seems a bit draconian. Is this a commercial project?
<Kinnison> But as fullermd says, cattle prods are useful.
<thekorn> no, I just want them to mention all files they changed
<Kinnison> In what sense?
<Kinnison> the change surely does that for you.
<pygi> thekorn: hm, whats the point if bzr can tell you that for every revision? o.O
<thekorn> pygi, I'm using bzr in a computer sience class, and I want the student to actually describe their changes in detail
<pygi> thekorn: ah, ok!
<thekorn> so just for teaching purposes
<Peng_> bzr-gtk has a nice commit UI, doesn't it?
<Peng_> I mean, for messages. It's the source of all of those really detailed messages in bzr.dev, isn't it?
 * Spaz tickles everyone
<Spaz> oops
<Spaz> wrong channel
<pygi> Spaz: :p
<pygi> lol
<Spaz> you don't deserve my tickling! >:(
<Kamping_Kaiser> :(
<fullermd> I always thought commit messages were meant for long rambling harangues about the stupid things the client made you do...
<Odd_Bloke> Bonus points for using profanity as shorthand.
<awilkins> Bonus points for writing comments that when they are acronymized are an insult to the irritating client that cause the patch to be necessary
<awilkins> thekorn: I remember a plugin that automatically listed all changed files in the comment
<awilkins> thekorn: Wouldn't be hard to write though
<awilkins> thekorn: I remember another one that parsed the --- below here --- part of the comment that was previously ignored and used it as a commit list, so you just deleted the line for any file you didn't want committed
<fullermd> I remember _discussion_ about that, but I'm not sure it really exists.
<bialix> hi, I have a question about English term. What is blueprint? Re: blueprints at launchpad
<fullermd> bialix: A set of plans for construction, as of a building.
<bialix> so it's more like "plan"?
<bialix> or "planned features"?
<bialix> or closer to "specification"?
<fullermd> Probably specification.
<bialix> I need this for Russian translations
<fullermd> "plan" can get too general; a blueprint is a plan for building a specific thing, whereas "plan" could also mean broader what things you want to build.
<fullermd> Only downside to 'specification' is that it could also mean a description of something that already exists, rather than the desired specifications for something to be made.
<fullermd> But I don't know whether that ambiguity would translate.
<bialix> so "blueprints @ launchpad" -- plans?
<fullermd> Yeah, that would probably get the right idea across.
<bialix> ok
<bialix> fullermd: is it somehow related to "request"?
<fullermd> bialix: No, it's more like "We've decided to do this (or at least explore it in-depth), here is the behavior the feature should have and something of how we'll implement it at the code-level"
<fullermd> So it's more of an "implementation plan", maybe.
<bialix> looks good
<knielsen> jam: I tried to use bzr merge-into to work-around bug 375898 as you suggested. Unfortunately using bzr merge-into gives the exact same problem :-(
<ubottu> Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Undecided,New] https://launchpad.net/bugs/375898
<knielsen> jam: I have added to the bug report the exact steps needed to get the error, including the merge-into step and subsequent patches applied.
<vila> jam: ping
<Peng_> jelmer: ping
<jelmer> Peng_: yo
<Peng_> Hi! :)
<Peng_> Oops, wait, never mind.
<beuno> vila!
<vila> beuno !
<vila> :)
<beuno> vila, I'm packing to go see you!
<Peng_> jelmer: Sorry. I wanted to mention a little error in bzr-svn, but you've already changed that code and fixed it. Oops, should've checked before pinging you.
<vila> beuno: I'll do the same very soon (still a couple of hours hacking while re-checking my survival kit :)
<beuno> vila, you've got a slightly shorter flight than I do  ;)
<vila> beuno: we should sit and talk again about bzr-upload, I'll took notes last time but I need more details to refresh my memory :-/
<vila> beuno: sure thing, the flight is shorter, yet I have to leave in the morning anyway because there isn't a lot of flights from here...
<beuno> vila, would be great
<beuno> there's that bzr sprint going on during UDS
<beuno> I haven'g signed up because I'm over-booked elsewhere
<beuno> BUT
<vila> yes, hopefully we'll find time in the two coming weeks
<beuno> I will run away occasionaly and hang out
<jelmer> hmm, bb is down again :-(
<vila> jam: ping
<jam> hi vila
<ph8> Hi all, i'm new to bazaar - am actually just trying to checkout a copy of the planet project (planetplanet.org)'s repo - i've used bzr branch http://www.gnome.org/~jdub/bzr/planet/devel/trunk/ ./ - but it seems to be sticking, does it take time to examine files or is it likely my http proxy isn't setup correctly?
<_amanica_> ph8, it can be your proxy settings
<Kinnison> Eww, planetplanet is using an old repo format
<Tak> what's the (practical) difference between default-rich-root and rich-root-pack?
<jam> Tak: in the future --default-rich-root may point to a different format
<jam> --rich-root-pack will always stay the same
<jam> as of *today* there is no difference
<Tak> hmm - which one would be a better default for a user who's unlikely to know the difference?
<jelmer> Tak: where are you using them for?
<Tak> I'm looking at adding "init" to md-bzr
<jelmer> Tak: --default-rich-root seems like the most sensible choice then
<Tak> ok
<las3r> Hello all.  I'm trying to get the bzr "svn" plugin working, but it tells me "No module named filters".  I'm using bzr-svn-0.5.4 w/ bzr 1.13.1 on Fedora.
<las3r> And indeed, there is no module bzrlib.filters.
<jelmer> las3r: for bzr 1.13.1 you need bzr-svn 0.5.3 (see the bzr-svn wiki page)
<las3r> Ah, I see.  I was looking in the "requirements" section, which wasn't so specific.  Now I understand what the release list was telling me.  Thanks!
<las3r> Okay.  Now I'm trying to import from an https:// subversion repository using a self-signed cert.  Curl is complaining ("Peer certificate cannot be authenticated...").  Is there any easy to way to pass the equivalent of 'curl --insecure' to this process?
<jelmer> las3r: try prefixing the URL with svn+
<las3r> jelmer: Huh, seems to work, but with the deprecated warning.  I had just finished patching the code to use connection.setopt(pycurl.SSL_VERIFYPEER,0) and then ran into authentication issues...
<las3r> jelmer: Other than using svn+https, is there any way to provide a username/password to svn-import?
<las3r> Well, I'll try the mailing list, because it's failed on the next step...
<ronny> jelmer: are you doing weird stuff to dulwich? every time try i pull the bzr branch, it tells me "branches diverged"
<davidstrauss> I'm getting "bzr: ERROR: Server sent an unexpected error: ('error', "ImportError instance has no attribute 'message'")" when checking out from my server over ssh
<Odd_Bloke> davidstrauss: Can you try running a similar operation locally on the server?
<jelmer> ronny: Shouldn't have happened recently, I mean, not in the last two weeks
<davidstrauss> Odd_Bloke: Works
<davidstrauss> (from local access)
<Odd_Bloke> davidstrauss: Hmm, that's the only debugging idea I had.
<Odd_Bloke> I know nothing about the smart server. :p
<Odd_Bloke> davidstrauss: Is this bzr+ssh or sftp?
<ronny> jelmer: im not very regular updating, since busy with other stuff
<davidstrauss> Odd_Bloke: bzr+ssh
<Odd_Bloke> davidstrauss: Try sftp.
<davidstrauss> works fine over sftp
<jelmer> ronny: So, the rebasing should've stopped by now
<jelmer> ronny: it was mainly caused by the fact that dulwich is maintained in both bzr and git
<Odd_Bloke> davidstrauss: Right, now I'm out of ideas. :p
<jelmer> ronny: and should stop now
#bzr 2009-05-19
<MTecknology> I have a patch file that was submitted to me - http://bzr.pastebin.com/m3b6d833a - I'm trying to use the patch command to apply the patch but it's saying only garbage was found
<MTecknology> oops... wrong order
<igc> morning all
<ronny> jelmer: k, thx
<jessicah> I'm getting lost in the website, so, how do I set up bzr to get through my proxy server?
<bob2> which OS?
<bob2> and http proxy for http urls?
<jessicah> debian
<jessicah> ahuh
<jessicah> bzr checkout http://some.repo.com/trunk just sits there doing nothing
<ryanakca> I manually copied file XY.py from branch A to B, and then bzr added in under B. Is there a way to show that the file XY.py originally came from branch A?
<bob2> set the http_proxy env var
<jessicah> hmm, ok
<bob2> export http_proxy=http://whatever:port/ ; bzr checkout http://...
<jessicah> thanks bob2
<bob2> did it work? :)
<jessicah> it's strange it not use setting somewhere else in debian
<jessicah> oh well
<bob2> most (non-gui) things will pick up http_proxy
<jessicah> well, svn/wget worked without setting, that why I confused
<jessicah> I set it up during debian install
<bob2> that is weird
<jessicah> yeah
<jessicah> anyways, it a workaround :) will bzr remember proxy used?
<jessicah> or I need to set http_proxy all the time now?
<bob2> it won't
<bob2> you can add the export line to ~/.bashrc
<jessicah> okies, thanks bob2 :)
 * igc out for a few hours - bbl
 * SamB wishes for the nth time that git kept branch nicks about ...
<AfC> SamB: Interesting that you say that. I've tended to feel that Bazaar's branch nick concept is superfluous. I freely admit, of course, that branch nicks haven't found their way into my workflow as such, so I haven't quite seen the need for them.
<AfC> [they're up there with revision messages in the "would be useful as history if you could fix typos", IMHO]
<AfC> but every so often I wonder what I'm missing as to their importance.
<Peng_> I like nicks. They help you get the basic idea of a branch from a glance.
<Peng_> Reading the commit messages takes more effort.
<SamB> AfC: well, yeah, there is that ...
<AfC> Peng_: that's fine, except that when you're collaborating with someone and you call the branch 'bug-strict-aliasing' and they call the branch 'myExcellentWorkingDirecotry' that's a nice bit of data that is,
<AfC> once again,
<AfC> forever more in bzr history and quite unhelpful.
<Peng_> AfC: Haha, good point. I do that on one branch I share between two machines.
<AfC> Peng_: if there was a mechanism (technical or social) to force people to be consistent about branch naming, then perhaps the nick thing would be useful.
<AfC> Peng_: but given that there isn't [and never was going to be]
<Peng_> People are usually consistent, though.
<AfC> I must admit that I find the fact that it is printed in the standard `bzr log` output ludicrous.
<AfC> No they aren't
<Peng_> Heh.
<AfC> Peng_: so consider this: http://rafb.net/p/QuFzGb68.html
<AfC> branch nicks | uniq
<AfC> now, admittedly, I am the author or the many of those branches, and *I* use a self-consistent naming scheme.
<AfC> at least recently. But you can readily see where I have collaborated with others, or reviewed and merged contributions, and there things are all over the map. Not to mention my own changing tastes.
<AfC> Overall, having this displayed prominently as history seems, as I said, somewhat ludicrous.
<AfC> The "myMainline" are always charming. "TreeStore implementation" merging to "treestore" illustrates the problem more clearly, I think.
<AfC> The only thing that makes the branches related is a) the fact they are branches at all, and b) their interconnections at head and tail with other branches [especially mainline].
<AfC> Branch nick, as such, seems to have nothing to do with this.
<AfC> So, like I said, I wonder what I am missing.
<Peng_> Looks like Loggerhead developers use "loggerhead", "trunk" and "trunk-rich" for the mainline. i hadn't really noticed.
<AfC> Peng_: that would count as a "social" mechanism for keeping it aligned (ie, people had agreed).
<AfC> ... except if that's 'mainline', then it seems to have more than one alias. Which would seem to be contrary to the purpose of the idea.
<AfC> Or, at least, contrary to what it might be.
<Peng_> AfC: s/mainline/trunk/, then. I didn't mean to use any term in particular.
<lifeless> ola
<davidstrauss> lifeless: hi!
<lifeless> Hi davidstrauss
<kfogel> "So, I used bzr to download the notification plugin for Sonata. All these SVN systems are a pain in the ass, but whatever."  (from http://smyte.wordpress.com/2009/05/18/mpd-sonata-notify-osd/)
<jml> haha
<amanica> is it just me or is bundlebuggy dead? are we supposed to exclusively use launchpad already?
<eMerzh> Hi, ...we are (at work) using http+webdav to psuh changes...we want to be notified for each push or commit ...
<eMerzh> Because of external commiters, we don't want to use bzr-email for each client....which other solutions does we have?
<eMerzh> thanks for your help
<amanica> eMerzh, you'd have to install a e-mail notification plugin on the server
<eMerzh> amanica, thanks.. but currently, i don't have a smart server... just an apache...this is not enough i gess?
<amanica> eMerzh, its not too hard to get a smartserver set up behind apache
<eMerzh> amanica, ok can we still commit by sftp too?
<amanica> mm.. you'd have to use bzr+https if you want the serverside hooks to fire
<eMerzh> ok, thanks for your help i will look for this :)
<NEBAP|work> hi guys, can someone help me out, IÂ´m not able to create a bundle with "bzr send -o ...". I always get a "bzr error not a branch" error. Any ideas what I can do?
<luks> are you running it in a branch?
<NEBAP|work> yes, IÂ´ve created a shared repository on the server with the option --notree. Then IÂ´ve done a checkout on another client (has only read rights). After finishing the work I just want to create a patch to send it to the computer with write access. But I always get the error, IÂ´ve still tried to unbind the checkout branch ...
<luks> what does bzr info says?
<NEBAP|work> just a second ..
<fullermd> BTW, "checkout branch" likely isn't a meaningful term...
<NEBAP|work> ok sorry
<NEBAP|work> IÂ´m just a beginner in using bazaar :(
<fullermd> Well, it's not a _sin_   :)
<NEBAP|work> ^^
<NEBAP|work> but seems like luks has found the error
<fullermd> It's just muddy.  Makes it harder to work out what's actually going on, and it can cloud your thinking about things.
<luks> NEBAP|work: if a program says X is wrong, the first thing to check should be X :)
<NEBAP|work> youÂ´re right, IÂ´ll try to learn the "vocabulary" and make things clearer ;)
<NEBAP|work> so, my repository has a similar structure to this: MyProject/Trunk/SubProjects(features)
<NEBAP|work> on the pc that throws the errors, "bzr info" tells me that "MyProject" and "Trunk" are standalone trees
<NEBAP|work> while "SubProject" is a branch related to "trunk"
<NEBAP|work> is that the right structure?
<NEBAP|work> or better a "good structure" to manage a project in bazaar
<NEBAP|work> but seems like something else is wrong .. bzr info tells me that the branch root is "C:\....\MyProject" which is correct. But it also tells me that the submit branch is "trunk" which causes him to search for it in "C:\....\MyProject\trunk\Feature\trunk\" not in "C:\....\MyProject\trunk"
<hexmode> I have a missing .bzr/repository/pack-names file on a repo I haven't touched in a while.  Is there anything I can do to recover?
<GaryvdM> hexmode: Can you elaborate a bit? Is there an error that you are getting?
<hexmode> GaryvdM: yes.... but it is a little late now... I decided I didn't care about the old revs.
<GaryvdM> ok
<GaryvdM> Hi jelmer - I'm trying to use bzr-colocated. bzr init --colocated BRANCHNAME seems to be broken.
<GaryvdM> If I do bzr init --colocated BRANCH; bzr switch BRANCH; bzr log - I get a Not a branch error.
<GaryvdM> If I check on the disk - it's created a folder for the branch (.bzr/branches/BRANCH), but it is empty.
<dash> hi.
<jelmer> hi
<dash> is there a way to check out a deleted branch at a specific revision using bzr-svn?
<dash> I suppose I could check out the branches dir and roll it back to that rev.... but there's a lot of branches in there. =/
<ryanakca> I manually copied file XY.py from branch A to B, and then bzr added in under B. Is there a way to show that the file XY.py originally came from branch A?
<GaryvdM> ryanakca: when you add the file, specify --file-ids-from=ARG
<GaryvdM> eg: bzr add XY.py --file-ids-from=A
<ryanakca> GaryvdM: and if its already added?
<ryanakca> half a dozen revisions ago?
<GaryvdM> are those revision public? if not, I think you can use rebase
<GaryvdM> I'm not 100% sure.
<ricardo> hi people. I was trying out bzr-rebase. and I am getting some weird conditions. I am doing a pull and I get 'No revisions to pull'. I do a rebase  and I get 'No revisions to rebase'. When I do a push I get 'Unable to push ... because it would change the ordering... Use rebase and try again or push to a non-root path'.
<ricardo> does this mean I have my repo broken?
<ricardo> btw.. I am trying to push to a svn repo (using bzr-svn)
<ricardo> I am using bzr 1.14 and bzr-svn 0.5.4
<servilio> hi all! is there a way to change the email recorded in the logs of a local branch?
<dash> servilio: "bzr whoami"
<servilio> dash: yep, but it doesn't change the authorship info of what is already committed
<dash> that's true
<servilio> dash: have any idea/pointer where can I find how to change the authorship (actually, only the e-mail I need to change) of past commits?
<GaryvdM> ricardo - lets look at one thing at a time. - Where are you pulling from? Have you tried bzr pull --overwrite?
<GaryvdM> servilio - Are these revision public yet?
<GaryvdM> If they are - it not recomended to do that.
<servilio> GaryvdM: not yet
<ricardo> GaryvdM, its a bit more complicated... I am trying out the feature for rewriting authors in svn
<ricardo> so I have one repo A that is a branch of svn
<ricardo> one repo B which is a branch of A
<ricardo> I made a change in B and pushed to A, and also made a change in A directly
<ricardo> and then tried to push to svn
<servilio> GaryvdM: and I'd like to set the proper authorship info before committing to the public repo
<GaryvdM> servilio: I think there may be a way to do it with rebase
 * servilio goes to read bzr help rebase
<GaryvdM> servilio - It seems not . Sorry
<GaryvdM> ricardo: where did the rebase come in?
<servilio> GaryvdM: can't find it either
<servilio> GaryvdM: thanks anyway!
<ricardo> GaryvdM, at some point between pulling/pushing between A and B, I tried to push to svn (from A)
<ricardo> and I got this error message (cannot push because....) and  so I tried to rebase in order to fix the commit order
<ricardo> but there is nothing to rebase apparently
<ricardo> so I am stuck with not being able to push
<GaryvdM> ricardo: what is the exact error that you get when you push?
<ricardo> GaryvdM, I was getting bzr: ERROR: Unable to push revision 'root@xxxx' because it would change the ordering of existing revisions on the Subversion repository root. Use rebase and try again or push to a non-root path
<ricardo> but never mind, as this is a test, I just uncommitted a few revisions, and tried again
<ricardo> it worked. in particular I had a merge revision , and it was this merge revision that was causing the problems
<GaryvdM> ricardo: ok - I think that is something specific to bzr-svn - which I am not to familiar with.
<ricardo> GaryvdM, np... as I said, since this is a test, I am not too worried
<ricardo> I will test it a bit further, and if I see no other issues, I'll go for it
<ricardo> thanks for the help
<Ddorda> hey. how do i download a specific version of a project?
<ryanakca> GaryvdM: rebase?
<ryanakca> (it isn't in bzr help commands)
<Ddorda> i'm not sure what's rebase
<GaryvdM> ryanakca: It's a plugin.
<Ddorda> i want to use a reversion of a project
<GaryvdM> ryanakca: disclamier: I've never done this. Recreate the revision that adds that file, then rebase the remainder if the revision on the new revision
<GaryvdM> I'm not sure though if rebase uses paths, or file-id. If the latter - It won't work.
<jelmer> it uses file ids
<Ddorda> well.. any idea?
<Ddorda> good night then
<servilio> jelmer: know of a way to take advantage of the fix for bug 372559 of bzr-svn?
<ubottu> Launchpad bug 372559 in bzr-svn "KeyError u'trunk3' on branch" [Undecided,Fix released] https://launchpad.net/bugs/372559
<jelmer> servilio: how do you mean?
<servilio> jelmer: I am using bzr 1.14 + bzr.svn 0.5.4 and I am being hit by that bug
<servilio> jelmer: already downloaded bzr.svn 0.6 but it depends on 1.15, which isn't released yet, and I have no idea how stable it is ATM with RC1
<jelmer> servilio: I'd recommend waiting for 1.15, which will be out in 3 days
<servilio> jelmer: so I was wondering what would be more reliable: backport the fix to 0.5.4 locally, or upgrade to 1.15rc1 altogether
<jelmer> servilio: in that case, I'd upgrade to 1.15rc1 altogether
<servilio> jelmer: so, it is production stable already?
<servilio> that'd be great
<jelmer> servilio: well, rcs are usually quite stable
<jelmer> servilio: and I haven't seen any brown bag issues with 1.15rc1
<servilio> jelmer: great!
<servilio> jelmer: what do you think of using bzr in a buildout sandbox? or a virtualenv?
<servilio> I'd like to wait for the packages for my distro to be available (Debian Lenny here)
<jelmer> servilio: I don't know, have never used it in that environment
<jelmer> servilio: I usually push packages to sid the day a release is out
<servilio> jelmer: great!
<servilio> jelmer: so, do you think it would be easy creating a 1.15rc1 .deb from the 1.14 deb-src?
 * servilio is checking packages.debian.org...
<servilio> no luck with p.D.o
<servilio> and FTP shows no packages for 1.15rc1
<jelmer> servilio: I haven't uploaded 1.15rc1 yet because there's no new bzrtools out yet
<jelmer> servilio: You can build a 1.15rc1 package from the bzr branch on bzr.debian.org though
<jelmer> http://bzr.debian.org/pkg-bazaar/bzr/unstable
<servilio> jelmer: how would I do that?
<jelmer> servilio: if you have bzr-builddeb installed, run:
<jelmer> bzr bd http://bzr.debian.org/pkg-bazaar/bzr/unstable
<jelmer> or check out that branch locally and run "bzr bd" there
<servilio> jelmer: will that build the corresponding bzrtools pkg?
<jelmer> servilio: no, it'll only build bzr itself
<servilio> ok
<jelmer> servilio: you will have to deinstall bzrtools if you upgrade to bzr 1.15rc1 now
<servilio> I am looking at gf.recipe.bzr [http://pypi.python.org/pypi/gf.recipe.bzr/1.0rc4]
<nevans> jelmer: encountering a cache bug on latest rev of bzr-svn 0.6
<nevans> jelmer: http://pastebin.com/m2ab5f3c2
<nevans> I can post a lp bug, if you'd like.  But I figured I'd ping you here first, because this isn't exactly a release.  :)
<jelmer> nevans: not sure what that's about from the top of my head, any chance you can file a bug?
<nevans> jelmer: sure thing.
<Necoro> hey - short question: why does the following not work as expected: bzrlib.branch.Branch.open("lp:some-project") (with bzr-1.14)
<Necoro> resulting exception: bzrlib.errors.NotBranchError: Not a branch: "/home/necoro/dev/portato/trunk/plugins/lp:some-project/"
<Necoro> so - it does not resolve the "lp:" URL
<jelmer> nevans: you need to do a directory service lookup
<jelmer> nevans: that will give you back a proper branch URL
<jelmer> s/nevans/Necoro/
<jelmer> Necoro: Try doing this before the branch open
<jelmer> Necoro: "from bzrlib.plugin import load_plugins; load_plugins()"
<Necoro> jelmer: ok - I _do_ load plugins (for exactly this feature) ... but in another thread ... (or more specific: I load the plugins, and then create a thread which looks up the branch)
<Necoro> seems like bzr changed the behavior there (because it used to work a couple of versions ago ;))
<jelmer> Necoro: strange, I don't think anything has changed in this area recently
<Necoro> hmm ... "Connection closed: please check connectivity and permissions" ... seems to have problems with ssh or sth similar ..
<Necoro> (it should not resolve the lp:-address to a bzr+ssh at all ... only to http://)
<jelmer> Necoro: it has always resolved to a bzr+ssh:// URL if there was a lp login username known
<Necoro> hmm ... if I do "bzr branch lp:bla", it tells me, that there is not launchpad-ID
<Necoro> if I do this via python-shell, it just returns the http:// address, w/o the "no ID"-warning
<Necoro> and in my programm ... well - it takes the bzr+ssh version ^^
<servilio> jelmer: gotta go now, thanks a lot! will try your suggestion as soon as I get back
<Necoro> jelmer: got it - the bug is on my side
<Necoro> switching to root-user in the program via a graphical su ... and this is not setting the environment - i.e. HOME still points to the original user
#bzr 2009-05-20
<a_c_m> humm
<a_c_m> i just tried out bzr-search and i think its corrupted my bzr folder, all operations seem to get stuck at Stage:Indexing...:Saving group 3/4
<a_c_m> is there any way to recover?
<igc> morning
<a_c_m> morning
<a_c_m> help :) i've seemed to have corrupted my .bzr folder? i ran a bzr check, which worked fine, but when i bzr up - it hangs at Indexing...:Saving group 3/4
<a_c_m> bah
<a_c_m> was the bzr-search module
<a_c_m> plugin eevn
<stefanlsd> Im trying to get a file back which was removed in a commit. Im doing bzr revert -r 14 '80-system-jpeg-png-sqlite.diff' and getting bzr: ERROR: Path(s) are not versioned: 80-system-jpeg-png-sqlite.diff.  I've tried full patch to the file also. Am i doing something wrong?
 * igc bbiab
<stefanlsd> *path
<igc> stefanlsd: that sounds like a bug. Maybe try 'bzr cat -r14 ...'. If that doesn't work, I'd create another branch, and try without the pathname. That should recreate the file and you can copy it from there. Having said that, we really want your use case working so please raise a bug.
<stefanlsd> igc: ok thanks. i did a bzr revert -r14   and got the file. then a bzr revert  and copied the file back in.. but yeah, sounds bug like
<igc> stefanlsd: cool. The main catch with re-adding the file is that it will get a new internal file-id (which can cause issues with merges crossing the delete/add boundary). I'm pretty sure add has a --with-ids flag (see bzr help add) but it's annoying to have to worry about that. Hence the need for a bug report so we don't forget to fix it!
<arjenAU> you lost buggerror
<AntoineLafontain> I have something that is puzzling me. I have a local shared repository with 3 branches into it. There's a main branch, a branch branched from the main called sub and the last branch, branched from sub called project.
<AntoineLafontain> The idea was to be able to commit changes to each branch and then merge the changes down to sub and then project
<AntoineLafontain> and if needed create other branches from the sub branch to start other 'projects' like the project branch
<AntoineLafontain> all this works well on my local setup
<AntoineLafontain> but I was wondering when I want to push things to share, I can push any branch with no problem, but I couldn't find a way to push a shared repo.
<AntoineLafontain> I guess it's not possible. And I'm possibly thinking this the wrong way...
<AntoineLafontain> Any one could give me her/his thoughts on this? Thanks
<Peng_> AntoineLafontain: There might be a plugin to make pushing an entire repo easier, but mostly you just push each branch one at a time.
<AntoineLafontain> and if I branch all the branches to say, another computer, will they keep their relational history... main being the parent of sub and so on?
<Peng_> AntoineLafontain: That's only a little bit of meta data; if it's wrong, you can do "bzr pull --remember" (parent) or "bzr push --remember" (push location) to fix it.
<AntoineLafontain> humm, I think I get most of what you say... Will need toexperiement to "grasp" thing for myself. But thx for confirming that there's a way and nothing wrong with my base setup.
<Peng_> AntoineLafontain: What were you referring to? The default "push", "pull", "merge", etc. paths/URLs?
<AntoineLafontain> well I did all this on my local machine, and using the default merge to propagate changes "down" my branch, using the hierarchy created by branching.
<AntoineLafontain> but when I considered pushing my setup to my server via sftp... I couldn't figure out how I would keep this relation between my branches...
<Peng_> AntoineLafontain: Do you have ssh access to the server? Then you could run "bzr pull --remember", like I said. Or you could manually edit .bzr/branch/branch.conf over ssh or sftp.
<AntoineLafontain> the --remember option isn't only for remebering the location of the parent branch?
<AntoineLafontain> sorry, I think my questions are a bit too basic... my experience with bazaar and versioning is quite limited...
<Peng_> AntoineLafontain: That is what it's for.
<AntoineLafontain> okey, so I get this part...
<AntoineLafontain> humm I guess that my explanation isn't clear... let me try again
<AntoineLafontain> I made a branch from a remote repo and I called that branch main
<AntoineLafontain> it is a local branch
<AntoineLafontain> I've then branched that main branch into a sub branch and made some additions to it... files, folders etc
<AntoineLafontain> then I made a branch of that sub branch called project
<AntoineLafontain> from this setup I can update main or sub and then propagate the changes to project as needed
<AntoineLafontain> using merge
<AntoineLafontain> this works quite well
<AntoineLafontain> but if I would like to move this setup on another machine... or share it with a co-worker...
<Peng_> OK, so push your branches somewhere.
<AntoineLafontain> I push all the branches to the server, but if I branch from the branch called sub from the server, the "relation" it had with main is broken
<Peng_> What "relation"?
<AntoineLafontain> eg, if I commit some changes to main
<AntoineLafontain> I can just move to sub and then do a bzr merge to get all the changes to my sub branch from main
<AntoineLafontain> I feel I just get some concepts wrong... not that bazaar can't do what I want actualy...
<Peng_> You can still merge or whatever you want to. You may have to run "bzr merge --remember /path/to/whatever" to fix up the stored URL once, but that's all.
<Peng_> If revisions lost their identities whenever you pushed, DVCSes would be kind of useless.
<Peng_> :P
<Peng_> Well, they just wouldn't be very "D".
<AntoineLafontain> haha
<AntoineLafontain> okey, I think I get it (somewhat). will just get my hands dirty and try it to make sure I do get it
<AntoineLafontain> thank you for listening to my ramblings ;)
<Peng_> :)
 * igc dinner
<adam7> Is it possible to copy a versioned file from branch A to branch B while retaining the version history?
<bob2> I think "copy" is the wrong word
<bob2> what are A and B?  are they related?
<adam7> well, I have A and B, and I'd like to put them in the same branch (currently in seperate branches)
<adam7> merge doesn't work because they didn't start from the same branch
<bob2> merge can work
<adam7> ok...
<adam7> I need a flag or something?
<bob2> I forget how to use it to merge unrelated branches, sorry
<adam7> --weave seems to do it
<adam7> oops
<adam7> or not
<bob2> I think it was -r0.., but I can't seem to find anything on google
<bob2> try asking on the list?
<adam7> bob2: got it
<adam7> bzr merge -r 0..-1 ../other-branch
<adam7> then bzr ci --unchanged
<bob2> you shouldn't need --unchanged
<adam7> I do, for whatever reason...
<adam7> otherwise bzr status doesn't work
<bob2> eh
<adam7> mkdir C
<adam7> cd C; bzr init
<adam7> bzr merge -r 0..-1
<adam7> +N blah blah blah
<adam7> bzr status
<adam7> working tree is out of date, run 'bzr update'
<adam7> bzr update
<adam7> -D blah blah blah
<adam7> maybe I'm doing something wrong?
<LeonBrussels> I have got a severe problem
<LeonBrussels> bzr: ERROR: Unknown record type: '\x02'  on commit
<LeonBrussels> is that bad :( ?
<Odd_Bloke> LeonBrussels: There should be a full traceback in ~/.bzr.log, putting that in a pastebin will help people diagnose the issue.
<LeonBrussels> Traceback: http://pastebin.com/f468824e6
<LeonBrussels> It's not a terribly large or complicated repo
<LeonBrussels> oh, and my bzr check doesn't look very positive either...
<Odd_Bloke> Well, I don't know.
<Odd_Bloke> But someone else who does will show up sometime soon. :)
 * LeonBrussels has decided he hates bzr
<Odd_Bloke> LeonBrussels: :(
<Odd_Bloke> LeonBrussels: I'm surprised there's no one else around to be able to help, the channel is normally much busier than this.
<Odd_Bloke> Actually, thinking about it, all the Canonical people are at their annual conference.
<Odd_Bloke> So that's probably not helping.
<Ddorda> hey. how do i download a specific revision of a project
<Peng_> Ddorda: "bzr branch -r 123 whatever"?
<Ddorda> so i can do "bzr branch -r 91" and it will download revision 91?
<Peng_> Uh-huh.
<Ddorda> ×¢×¨×§×©×
<Ddorda> great*
<Ddorda> many thanks :D
<Peng_> :)
<Peng_> Ddorda: You can also use "bzr revert -r 123" to make the working tree look like it's a certain revision.
<Ddorda> okay.. thanks
<Tak> is there a better way of checking whether a branch is bound than get_bound_location?
<exarkun> Just encountered this failure, http://rafb.net/p/CEC6g533.html
<servilio> hi!
<servilio> anyone knows where can I get a bzr-rebase compatible with bzr 1.15rc1?
<GaryvdM> servilo: lp:bzr-rebase?
<servilio> GaryvdM: hmmm, will try that...
<servilio> do you know how stable is it?
<GaryvdM> I'm running it - have no problems.
<servilio> GaryvdM: great! are you using bzr 1.15rc1 as well?
<GaryvdM> no
<GaryvdM> 1.14.1
<ricardokirkner> hi. I am playing with bzr-svn and dpush. I want to have a central bzr repo from which all my developers can branch off, and from which I can pull and push to a central svn repo (upstream). I configured the upstream svn repo to support pre-revprop-change hook in order to rewrite the author, and use dpush in order not to push metadata properties (as they are not wanted in upstream). The main idea here is to use bzr but try not to interfere with upstrea
<ricardokirkner> m (because normally we can't)
<ricardokirkner> now, I am getting this strange behaviour:
<ricardokirkner> I have repo A (from which I dpush), repo B (branch of A)
<ricardokirkner> when I dpush from A (to svn), and then (in B) pull (from A)
<ricardokirkner> I get a message that the branches have diverged
<jelmer> ricardokirkner: yes, that's the disadvantage of dpush
<jelmer> ricardokirkner: it doesn't retain all of the metadata, and so the revisions change slightly
<ricardokirkner> jelmer, is there any way around this? (as the branches aren't really different)
<ricardokirkner> maybe using rebase? some option?
<ricardokirkner> or, once I dpush I loose any chance to continue my branches?
<jelmer> ricardokirkner: bzr pull --overwrite in branch B should fix it, or using regular push
<ricardokirkner> jelmer, alright , I'll try using pull --overwrite
<jelmer> ricardokirkner: (--overwrite that'll remove any extra revisions you have in branch B)
<ricardokirkner> as direct push to svn is not what I want (my client has complained that a lot of properties appeared in the svn tree -- as they are using svn 1.4, its file props)
<jelmer> ricardokirkner: so, one of the things you can do is not pull from branch A until you've dpushed branch A into svn
<jelmer> ricardokirkner: as the revisions won't change after they have been dpushed
<ricardokirkner> jelmer, but thats what I've been doing
<ricardokirkner> that's what made me wonder
<ricardokirkner> I pushed from B to A , then dpushed from A to svn, then pulled from A to B
<ricardokirkner> and got the error
<jelmer> ricardokirkner: yes, because the revisions you pushed from B into A have been rebased by dpush
<servilio> GaryvdM: to install bzr-rebase local to my account is it enough to copy it under $HOME/.bazaar/plugins? no build necessary?
 * servilio answers himself: yes, just copying is enough
<servilio> though bzr checkout lp:bzr-rebase $HOME/.bazaar/plugins/rebase is even better
<servilio> jelmer!
<servilio> jelmer: got 1.15rc1 built and working, thanks again!
<ricardokirkner> jelmer, and is this not fixable somehow by rebasing B as A was rebased? (without having to overwrite B entirely)
<jelmer> servilio: np :)
<jelmer> ricardokirkner: not yet, for that dpush would have to store the information of how things were rebased so rebase could pick it up
<ricardokirkner> jelmer, and the problem with pull --overwrite is that I can't do anything in branch B until branch A has been dpushed to svn (in order to avoid any diverged message), right?
<ricardokirkner> so, if developer B pushes to A, and does nothing else on branch B until branch A has been dpushed, and after that pulls with overwrite from branch A , i should not have any issues, right?
<ricardokirkner> it's a workflow limitation, but it may work
<jelmer> ricardokirkner: yes
<jelmer> ricardokirkner: please file a wishlist bug about dpush saving a revid map if that bit seems useful
<servilio> is it possible to do a rebase from a subversion source? I am trying but get a "different rich-root support" error
<servilio> should I change the local branch format?
<SamB> servilio: that sounds unrelated to rebase
<ricardokirkner> jelmer, if dpush saves a revid map (locally I guess, as I don't want to push any metadata to the svn server), that would allow bzr to rebase branch B accordingly, and prevent the branches to be interpreted as diverged?
<SamB> servilio: you get that when you to pull, too, don't you ?
<jelmer> servilio: you need to upgrade the other branch to a rich root format
<servilio> jelmer: the other branch is a subversion repo
<jelmer> ricardokirkner: yes, you'd just have to specify the revidmap to dpush (so it can store it) and rebase (so it can load it)
 * SamB doesn't get the point of dpush
<jelmer> servilio: Sorry, I mean your local branch
<jelmer> SamB: doesn't set any bzr-specific svn data
<SamB> jelmer: that seems pretty useless to me!
<jelmer> SamB: some people get annoyed by the file properties bzr-svn sets if you're running against a svn < 1.5 server
<SamB> I guess if the repository doesn't allow revision properties, maybe it's useful ...
<ricardokirkner> jelmer, alright.. .I will try pull --overwrite to see if it works for my needs, and file a wishlist for dpush (adding the relevant information for this irc log if you agree)
<servilio> jelmer: what version should I upgrade it to? I tried bzr upgrade and it says it is already at the newest (I know you can override to an "experimental/devel" format forcibly, but just don't know which one is the right)
<jelmer> servilio: "bzr upgrade --default-rich-root"
<SamB> jelmer: do you know anything about why a repository that does allow revision properties would disallow mergeinfo ?
<jelmer> SamB: yes, mergeinfo was added later
<SamB> jelmer: does it also depend on something about the repository, in addition to the server ?
<servilio> jelmer: worked great! thanks!
<jelmer> SamB: not that I'm aware of
<SamB> jelmer: hmm, I wonder how sourceforge does this then
<SamB> since right now the dosemu SVN on sourceforge doesn't allow mergeinfo, but they say that a project admin can upgrade it to do so ...
 * SamB looks for the ticket ...
<SamB> jelmer: ah, here's the ticket where they told me this: https://apps.sourceforge.net/trac/sourceforge/ticket/317
<ubottu> Error: <Bugtracker.plugin.Sourceforge instance at 0x293d3b0> bug 317 not found
<SamB> ubottu: uh, it's definately there!
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
 * SamB was only teasing
<SamB> jelmer: can you make anything of that ?
<jelmer> SamB: that URL requires me to log in
<SamB> jelmer: it does ?
<SamB> that's wierd ...
<jelmer> SamB: ah
<jelmer> SamB: yeah, there's a format change required too for mergeinfo
<SamB> jelmer: are you going to write about that on the ticket ... or should I just reopen it and let the sf.net people do that ?
<jelmer> SamB: I don't see what there is to comment on
<jelmer> SamB: I mean, what is your question to me exactly?
<SamB> nevermind, I'll just reopen and see if they can answer ...
<jelmer> SamB: You'll have to dump and restore the repo as they say in order to use mergeinfo
<SamB> now, my question for you is: can bzr-svn, after a repository has been upgraded to support mergeinfo, go back and fill that in for bzr merges ?
<servilio> is svn:ignore supported "full-duplex" in bzr-svn? I can see in workingtree.py that it import it, but aside of the tests, can't see any other reference to svn:ignore in the code
<dash> SamB: it'll be a new repo, so you'd need a new bzr-svn import i think
<SamB> dash: wouldn't it just be a new representation of the same repo?
<jelmer> servilio: no, it's only supported in working trees
<dash> i don't know what 'representation' and 'same' mean there
<servilio> jelmer: thx!
<jelmer> SamB: that's not possible, you can't change the file properties in historic revisions
<SamB> jelmer: ouch :-(
 * SamB thinks bzr-svn ought to ask for confirmation before pushing to a repository that won't allow mergeinfo for the first time ...
<dash> how would that help?
<SamB> dash: well, that way you could maybe do something about getting the repository upgraded *first*
<jelmer> SamB: why? svn doesn't do anything like that either if the repo doesn't support mergeinfo
<dash> SamB: what's wrong with upgrading it later? just rebranch
<jelmer> SamB: and svn users benefit from bzr-svn setting svn:mergeinfo, bzr-svn users don't benefit from it (since bzr-svn doesn't look at svn:mergeinfo itself)
<SamB> jelmer: hmm.
<SamB> jelmer: is what dash says about having to re-import true?
<jelmer> SamB: yes, that's the only way you can get bzr-svn to set those svn:mergeinfo properties
<SamB> jelmer: I mean, after you do the dump/restore, does bzr-svn need to re-import the repository ?
<jelmer> SamB: depends on if the dump/restore retains the repository UUID
<jelmer> SamB: You can get it to retain the repository UUID
<jelmer> SamB: but I think you explicitly have to set the old UUID, otherwise it generates a new one
<SamB> jelmer: hmm, the help for "load" appears to indicate that if you load into an empty repo, it sets the UUID from the stream ...
<jelmer> SamB: ah, I might be wrong then
<SamB> and I just did a test dump, and "svnadmin dump" seems to dump the repository UUID
<SamB> jelmer: and are SVN revisions from repositories with different UUIDs considered distinct by bzr-svn ?
<jelmer> SamB: yes
<dash> one hopes so
 * SamB wonders why git-svn doesn't use the UUID instead of the URL
<dash> git was written by C programmers
<SamB> git-svn is in perl though
<dash> well, perl was written by C programmers too. ;)
<SamB> so was Python
<dash> disputable!
<dash> anyway
<servilio> isn't pull the command to get a local copy in sync with the remote subversion repository?
<SamB> are you saying that Python is written by wannabe C coders ?
<dash> git succeeds because it makes the same optimization tradeoffs as C
<dash> trading correctness for performance :)
<SamB> dash: are you talking about "git merge"?
<dash> servilio: right. it creates a bzr branch containing all the revisions of the remote svn branch
 * SamB wants a better "git merge"
<SamB> servilio: why do you ask?
<servilio> dash: I already have the local branch, but I need to get it in sync with the repo to be able to push the locally committed changes
<SamB> it sounds like you just tried it but it didn't work
<dash> oh, you did say pull, sorry. I did not read what you wrote :)
<servilio> SamB: I am getting an exception regarding mismatching revisions
<SamB> servilio: paste it somewhere?
<SamB> here, if it's short ...
<servilio> not short, any pastebin at hand?
<servilio> I know none
<SamB> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<servilio> SamB: nice :))
<SamB> servilio: I had no idea if that would actually work or not ;-)
<servilio> http://paste.ubuntu.com/176517/
<jelmer> servilio: that's a known bug in 0.5.4, fixed in 0.6.0
<servilio> jelmer: using 0.6dev
<servilio> with bzr 1.15rc1
<jelmer> servilio: which 0.6dev revision?
<jelmer> (I fixed that bug yesterday)
<servilio> how do I see the revision?
<jelmer> 'bzr revno'
<servilio> jelmer: 2993
<servilio> jelmer: is http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.6/ the proper URL to checkout from?
<jelmer> servilio: no, http://people.samba.org/bzr/jelmer/bzr-svn/0.6
<jelmer> 2993 should include the fix though..
 * servilio goes to switch to the new URL actually checking out to plugins dir directly...
<servilio> jelmer: @2997 now, trying again...
<servilio> jelmer: same result
<servilio> jelmer: want me to gather some more data beyond the traceback? run it in verbose mode?
<jelmer> servilio: please file a bug
<jelmer> servilio: is this a public repo?
<servilio> jelmer: no, local to the university I work
<servilio> but I have full access to that machine, could get some data on the repo
<servilio> maybe it is still in old format or something
<jelmer> no, that shouldn't be relevant. this very much looks like a bzr-svn bug
<SamB> servilio: is it local for a particular reason?
<servilio> SamB: for most of the code, just lack of time to move it out
<servilio> some other code is quite local to us
<SamB> servilio: as in, private ?
<servilio> though publishing it wouldn't do any harm
<servilio> SamB: as in only accessible from campus network
<SamB> ah, so as in, you don't think anyone else would want it ?
<servilio> SamB: at the beginning, yes
<SamB> so you could probably get permission to give jelmer a copy of the repository, then ?
<servilio> SamB: started with branding stuff, then just put there stuff that might have lived outside
<servilio> SamB: yes
<servilio> I can give it a try
<servilio> don't expect any trouble getting the OK from the stakeholders
<jelmer> servilio: Perhaps wait until that's really necessary
<servilio> jelmer: OK
<servilio> jelmer: should I file a new bug or put the new data under an existing one?
<SamB> jelmer: well, he seems to think it'd be mostly a matter of asking ...
<jelmer> servilio: new bug please
<jelmer> SamB: yes, but I was mainly asking so I can have a quick try to see if I can reproduce + fix it
<servilio> jelmer: I think I know what is happening
<SamB> whatever ;-)
 * servilio goes to do a short test...
<SamB> I just thought I'd ask about it, since I know people at universities often keep stuff private merely because they haven't bothered to make it public ...
<servilio> hmmm, there is really a mismatch
<jelmer> servilio: can you tell what it's doing wrong based on "svn log -v" ?
<servilio> the files at the svn repo are at revision 362, but somehow bzr-svn got its metadata at 387
<jelmer> servilio: is 387 mentioned anywhere in log?
<jelmer> servilio: is that particular path changed in 387 ?
<servilio> jelmer: will see, svn repo is at 427
<servilio> yes, I think I found the cause
<servilio> I changed the base URL of the repo
<servilio> it happened at revision 387
<servilio> :)
<jelmer> servilio: can you please mention this in the bug report ?
<servilio> yep
<jelmer> servilio: Possible with the changes as printed by "svn log -v" from that revno
<servilio> jelmer: no problem
<servilio> jelmer: what about doing a bzr switch on the local bzr branch?
<servilio> could it fix this?
<jelmer> servilio: no, this really is a bzr-svn bug
<servilio> ok
<servilio> filing new bug...
<servilio> jelmer: what about rebase? shouldn't that make the local branch sync with the remote svn? (just curious)
<jelmer> servilio: rebase basically replays your local commits on top of the remote ones
<jelmer> servilio: the extra revisions you have locally I mean
<servilio> jelmer: rebase just says: "No revisions to rebase."
<jelmer> servilio: if you don't have any extra revisions locally, that's correct
<servilio> jelmer: what is better: paste the outputs directly or attached as files?
<jelmer> servilio: paste directly please
<servilio> ok
<servilio> jelmer: just to confirm: I am including the output from svn log and bzr pull; am I leaving anything out?
<jelmer> servilio: "svn log -v" ?
<jelmer> servilio: other than that, that should be sufficient
<servilio> ok
<servilio> jelmer: is it possible to use markup in the bug information area?
<jelmer> servilio: don't know
<ricardokirkner> is there a way to have a bzr smart server with authentication and allow writes, that doesn't expose the full filesystem path? (like bzr+ssh does)
<LarstiQ> ricardokirkner: ClueBzr?
<ricardokirkner> is it stable enough? (I just saw a mention of it recently) have you any experience using it?
<LarstiQ> no idea, no.
<LarstiQ> ricardokirkner: barring Launchpad, it's the only server implementation I know that does that.
<ricardokirkner> LarstiQ: alright, I will take a look at it, thanks
<mib_thk4aclq> I'm having some permissions issues in bzr on a Linux box
<mib_thk4aclq> Anyone with any knowledge of this?
<LarstiQ> mib_thk4aclq: not enough information given to know yet.
<mib_thk4aclq> Here goes.
<mib_thk4aclq> I have a project that several users on the local box use
<mib_thk4aclq> I'd like all to have commit privileges from their local branches to the main branch.
<mib_thk4aclq> However, every time I run a push to merge my local branch with the main branch, ownership is set to me alone.
<mib_thk4aclq> None of the other devs are able to make commits.
<mib_thk4aclq> I'd rather not have to change permissions on the main branch location each time.
<mib_thk4aclq> Is there a better way to set it up, to avoid this issue?
<LarstiQ> mib_thk4aclq: yes, I personally make use of posix acls
<mib_thk4aclq> To what end?
<LarstiQ> mib_thk4aclq: to set the permissions on /srv/bzr
<mib_thk4aclq> I see. That seems reasonable. I'm rather surprised bzr isn't able to handle this on its own.
<mib_thk4aclq> I expected this scenario would be fairly common.
<LarstiQ> mib_thk4aclq: something like `setfacl -m group:bzr:rwx /srv/bzr/*'
<LarstiQ> mib_thk4aclq: bzr is not in the business of handling permissions
<mib_thk4aclq> I suppose that keeps everything nice and general, given its portability.
<mib_thk4aclq> Many thanks.
<LarstiQ> mib_thk4aclq: alternatively, if you're using a smartserver instead of dumb transports, you could handle it there
<mib_thk4aclq> Oh? Could you direct me to the proper documentation? I investigated the smartserver but couldn't find relevant info.
<LarstiQ> mib_thk4aclq: http://pypi.python.org/pypi/ClueBzrServer/0.2 or with Apache + mod_auth
<dash> LarstiQ: probably you can't use that if all the urls are file:// ones :)
<LarstiQ> dash: correct :)
<mib_thk4aclq> Well, using a smartserver or dumb transport makes no difference to me
<mib_thk4aclq> All users are local
<LarstiQ> mib_thk4aclq: if they use file:// urls, it is purely a filesystem permissions situation.
<LarstiQ> for which I recommend setfacl for more flexibility than traditional Unix permissions
<mib_thk4aclq> Well, I'd prefer to do the configuration with the smartserver then.
<mib_thk4aclq> Which I think I shall
<mib_thk4aclq> I'm just sick of having the other devs pissed at me for blocking commits
<mib_thk4aclq> :/
<LarstiQ> mib_thk4aclq: you can get partway to where you want to be with the setgid bit
<mib_thk4aclq> Mhmm
<LarstiQ> but that falls short in the area of new directories mainly
<LarstiQ>   $ setfacl -m group:developer:rwx /bzr
<LarstiQ>   $ setfacl -m default:group:developer:rwx /bzr
<LarstiQ> takes care of all that
<LarstiQ> mib_thk4aclq: I've set it up once on the server, and never look back
<mib_thk4aclq> Well, there's certainly no harm in trying it out, since the box is locked down tight
<jelmer> servilio: did you manage to file the bug?
<servilio> jelmer: I am trying to reproduce the bug locally, but can't get bzr to make the first commit before removing an element from the path
<servilio> I think I'll file the bug and later try to reproduce it
<servilio> also because I need to find a way to put my changes into the subversion repository (I mean, the ones from the real work, not the mock situation trying to reproduce the bug)
<servilio> jelmer: I am getting a "Not a branch" when checking out a local svn repo: http://paste.ubuntu.com/176633/
<jelmer> servilio: yeah, because the branch you're checking out is not a branch according to the layout you're specifying
<jelmer> servilio: it seems like you'd want to create l1/l2/trunk
<servilio> so, what should I do to have just a directory?
<jelmer> servilio: how do you mean?
<servilio> I tried bzr branch like you suggested here: http://www.nabble.com/My-experience-with-bzr-svn-td23606249.html
<servilio> but svn+file is not a recognized protocol
<jelmer> servilio: file:/// should work
<servilio> will try that...
<jelmer> servilio: I think I see what the problem is
<jelmer> anyway, time for groceries first, back later
<servilio> jelmer: got the branch properly created, now doing some local changes...
<servilio> see you later
<jelmer> servilio: if you end up with a script that can reproduce this, that would be very useful (for the regression testsutie in bzr-svn)
<servilio> jelmer: yep, I know
<servilio> jelmer: got it :)
<jelmer> servilio: w00t :-)
<servilio> found that it only happens with three levels of nesting
<servilio> two doesn't show up
<servilio> and bzr missing misses the changes in the remote svn repo on the 3 nesting case
<jelmer> interesting
<servilio> I am extending the script to automate the testing for different levels
<servilio> I'd like to see what happens at 4 levels
<jelmer> servilio: can you attach the script to the bug report?
<servilio> I'll do it
<servilio> I am finishing it, will test it in a minute
<servilio> jelmer: ready, attaching it now to ticket...
<servilio> done
<servilio> jelmer: is there a way I can push the changes I have in my local branch to the svn repo #378799 notwithstanding?
#bzr 2009-05-21
<_amanica_> were we supposed to stop using bundle-buggy already?
<_amanica_> nevermind, I need to sleep now. will ask again another time..
<brucekg> LUSERS
<brucekg> been a long time since I last used irc..  anyone here that might be able to answer a bazaar question?
<bob2> ...
<brucekg> I am trying to set up repository with multiple projects and traditional trunk, branches, tags, etc..  Documewntation has left me guessing twixt no-trees and conmtainers
<poolie> hello igc?
<awilcox> Is it possible to change an author name on old bzr revisions?
<awilcox> Like say one of my team members got married, and she wants her married name on her old bzr revisions.
<awilcox> How would I go about doing that?
<Kinnison> Was she married when she made those commits?
<awilcox> Is that a no?
<Kinnison> It's not.
<Kinnison> There are ways, but if anyone has done anything based on those revs (incl. merges etc) then it'll be a total and complete arse
<Kinnison> And basically involves replaying history
<Kinnison> IIRC
<awilcox> They haven't.
<awilcox> It's just commits in trunk
<Kinnison> And noone else has committed after her commits which need changing?
<awilcox> Uhhhhhhhhh
<awilcox> She committed r77
<awilcox> We're pushing 700 >_<
<Kinnison> Then there's stuff "based" on the commits
<Kinnison> Social problem.
<Kinnison> She needs to understand that the past is the past.
<awilcox> Well uhhh
<Kinnison> Same as I cope with the fact that some of the early commits in one project I never thought I'd publish have change comments like "feh, moosed."
<awilcox> She doesn't like her old last name for reasons I can't disclose on channel ._.
<awilcox> There's no way to change it?
<Kinnison> Not without replaying history entirely IIRC
<Kinnison> and that'll break any in-flight branches you might have, or any of your users might have
<awilcox> So I can just set my clock back to 2006 and redo it all? >_>
<awilcox> If we have users that would be news to me
<Kinnison> Is she wanting you to fix all the backups to not contain her old name too?
<awilcox> Backups?
<awilcox> Those get erased after they're old
<awilcox> Because bzr is incremental and includes all of history
<Kinnison> It truly sounds like she should just stop worrying, names are hardly a critical thing.
<awilcox> Maybe there's two backups?
<Kinnison> awilcox: Now, if only it were possible to *guarantee* that nothing else will corrupt historical data
<AnAnt> Hello, can I use bzr to maintain a package that I've merge from Ubuntu ?
<Peng_> Yes?
<AnAnt> it's gnome-games,
<AnAnt> I did bzr branch lp:~ubuntu-desktop/gnome-games/ubuntu
<AnAnt> then changed in the packaging
<AnAnt> so, if I do bzr push <some other repository>
<AnAnt> how can I maintain the diff for following versions ?
<AnAnt> just do bzr pull lp:~ubuntu-desktop/gnome-games/ubuntu for every new version or what ?
<Peng_> AnAnt: If you've committed new revisions, you'd have to use "bzr merge", but sure.
<Peng_> AnAnt: I don't know the best practices for packaging branches, though,
<scfe> How can I run the bazaar unit test suite?
<luks> bzr selftest
<luks> (and then go make lunch or something :))
<scfe> luks: How long does a test suite run normally take? I see that bzr has more than 19000 tests.
<luks> I don't remember
<luks> I used to be more than 30 minutes, but that was over a year ago
<scfe> is there a possibility to run only some tests? bzr selftest <filename> or something like that?
<luks> bzr selftest test_name_pattern
<luks> there is also an option to run only a specific module
<luks> see bzr help selftest
<scfe> luks: Thanks :-) (running the self-test after every generation of a new RPM packages seems to be a good way to ensure everything is still working)
<luks> not sure if the maintainers of the build machines will be happy about it :)
<scfe> luks: Probably I have to ask - given the current rate the full run will take ~ 1 1/2 hours...
<gioele> hello
<gioele> what is the intended purpose of bzr nick?
<jelmer> hi
<scfe> What is the expected key id for the signature of the bzr release tarballs? They seem to be signed by Robert Tanner but this is not mentioned in the installation FAQ..
<LarstiQ> scfe: signed by the RM, which differs per release.
<scfe> LarstiQ: But the InstallationFAQ does not mention the release manager for 1.14/1.15
<scfe> so who is the release manager for 1.14/1.15?
<jelmer> gioele: it's a nick name for a particular branch, e.g. "trunk", "fix-bug-42342", "jelmer", etc
<LarstiQ> scfe: 1.14 was Bob Tanner, 1.15 I haven't paid attention to
<LarstiQ> scfe: note that http://bazaar-vcs.org/InstallationFaq hasn't been updated since 0.13
 * LarstiQ doesn't know if they're mentioned somewhere else
<gioele> jelmer: I knew that. I just found the real use: nick are preserved no matter what arguments you use to clone a branch. A renamed dir keeps the original nick (unless set again after the clone)
<LarstiQ> gioele: right. It's more that in absence of an explicit nick it defaults to the basename of the branch root.
<scfe> LarstiQ: looks like. However I found a ml post (https://lists.ubuntu.com/archives/bazaar/2009q1/055151.html) for his nomination. And obviously he signed the 1.14 which ubuntu ships so I guess key id 0x0DDBE378 should be okay.
<gioele> OK, I've added another term to CategoryTerm: http://bazaar-vcs.org/Nick
<LarstiQ> scfe: if, given a released version, you want to know who the RM was, it's easier to check the -announce list: https://lists.ubuntu.com/archives/bazaar-announce/
<LarstiQ> scfe: the release announcement will be made by the RM
<LarstiQ> now Bob includes his gpg fingerprint in his mails *checks to see if other RMs mention the signature*
<LarstiQ> seems not
<LarstiQ> scfe: bzr/doc/developers/release.txt mentions to upload and link the sig from http://bazaar-vcs.org/Download , would also stating it to be explicitly mentioned in the announcement help your use case?
<scfe> LarstiQ: I needed to ensure that the signature is legitimate. Mentioning key id and/or checksums would definitely help (from a distro perspective you can't be paranoid enough ;-)
<LarstiQ> scfe: well, they're mentioned next to the release itself on http://bazaar-vcs.org/Download
<LarstiQ> someone could potentially change that, but they could also send mail
<LarstiQ> scfe: so I'm wondering which source you're willing to trust :)
<scfe> On that page I only fig the sig. But how can I verify that the key used for the sig is legitimate? (e.g. someone hacked the server and put his own binaries/sigs there)
 * LarstiQ nods
<LarstiQ> scfe: yes, how do you?
<scfe> LarstiQ: A release announcement on a mailing list which is mirrored by many web sites mentioning the key should be okay.
<LarstiQ> scfe: ok, then lets include that in the release policy.
<scfe> LarstiQ: Thanks :-)
<Tak> does it ever make sense to update an unbound branch, or to pull a bound branch?
<servilio> jelmer: hi!
<servilio> jelmer: just saw you the script didn't reproduce the bug for you
<LarstiQ> Tak: yes.
<LarstiQ> Tak: firstly, update makes sense in a working tree context. Now consider from remote `bzr push host/unbound`. The working tree will now be out of date wrt its branch.
<LarstiQ> Tak: hence the push-and-update plugin
<LarstiQ> Tak: pulling in a bound branch will pull to it's master.
<LarstiQ> Tak: so they do both make sense, but for different usage then what you had in mind I think.
<Tak> ok, that's fine
<Tak> I just want to make sure I shouldn't be hiding "Update" when the branch is unbound, and vice-versa
<LarstiQ> Tak: afaik those are the only usages, if you can provide that in a different way you might get away with it.
<LarstiQ> Tak: it's a balancing act between not confusing users and giving them the power to accomplish things.
<LarstiQ> Tak: in bzr too, it could be debated if this behaviour is what we want.
<LarstiQ> since I agree it isn't entirely obvious
<LarstiQ> Tak: so if you have a better workflow model, please share! :)
<Tak> heh
<ricardokirkner> hi. has anyone experience with clue-bzrserver? I cannot manage to get it running, and there is almost no documentation. Or can anyone recommend me the simplest way to have authentication on commit/push without having to expose the full path on the server? (the way bzr+ssh works).
<pickscrape> What would be the best way to search for commits by a particular user? I can't see anything in bzr log about it, and bzr search doesn't appear to either.
<jelmer> ricardokirkner: I think rocky or pygi are the people to talk to
<jelmer> servilio: hi
<servilio> jelmer: hi!
<ricardokirkner> jelmer: as usual, thanks for the help/info... I will ping them later then
<jelmer> servilio: Yeah, I couldn't reproduce it but then realized I was testing with an older version of bzr-svn
<jelmer> so I'll give it another try in a few minutes
<servilio> jelmer: ok, let me know
 * pickscrape resorts to bzr log -n0 | less
<C10uD> hello
<C10uD> i screwed up my repo on launchpad, i don't know why
<C10uD> how can i get it working again?
<C10uD> (link coming..)
<C10uD> https://code.launchpad.net/~c10ud/emesene/emesene-crazy
<C10uD> it shows two faulty revisions, it should show 1341
<Tak> is 1341 the revision at which you branched from somewhere else?
<C10uD> yes, i screwed up while trying to create another branch of this one
<Tak> so is it that you don't want those two revisions in the branch?
<C10uD> yep
<C10uD> i don't even know why they got 1 and two..
<Tak> if you click "all revisions" it shows them as 1342 and 1343
<C10uD> oh, right, but i tried reverting and didn't work...i'll try again
<C10uD> $   bzr branch lp:~c10ud/emesene/emesene-crazy
<C10uD> Branched 2 revision(s).
<C10uD> see?
<C10uD> $ bzr revert -r1341
<C10uD> bzr: ERROR: Requested revision: u'1341' does not exist in branch: BzrBranch6('file:///home/riky/msn/emesene-crazy/'
<Tak> from the branch's perspective, you want to revert to r0 (bzr log)
<Tak> hmm, no, that's notn right
<C10uD> :s
<C10uD> anyway fortunately there's another repo in there that contains exactly what i need.. if it can help
<C10uD> it's stopped exactly at rev 1341
<Tak> `bzr uncommit -r0` seems to do what you want
<Tak> or you could rebranch from the other
<C10uD> if i uncommit, then i must push directly or commit?
<C10uD> ok, i tried.. if i commit i get a newer revision: 1
<C10uD> pushing make no difference
<C10uD> maybe found
<C10uD> let's try
<C10uD> i was using revid's but seems i can't get to previous numeration, when i commit i still get 1 or two...mmm
 * maxb wonders if "bzr push --overwrite" is what C10uD wants?
<C10uD> after uncommit?
<C10uD> anyway, yes now i killed the latest two changes
<C10uD> but still, i get 1 as the latest commit id
<Tak> C10uD: is there some reason you're so concerned about the revision numbers?
<C10uD> just win the machine, i guess
 * LarstiQ looks at the branch
<C10uD> $ cat .bzr/branch/last-revision
<C10uD> 0 c10ud.dev@gmail.com-20090518152659-6p2z7bbujksrzjn5
<C10uD> what if i edit this?
<C10uD> i'll do it
<Tak> that seems like A Bad Idea
<C10uD> but, seems it worked (!)
<jelmer> C10uD: you can change it, but you generalyl shouldn't have to
<C10uD> let's see web interface
<C10uD> it worked ._.
<C10uD> so simple, wtf
<C10uD> brb food, thanks for your support guys
<C10uD> :)
<awilkins> Ok, I can pretty much guess what the answer is ; but... when editing branch metadata (like `.bzr/branch/location`) in vim, they become broken (because of vim's obstinate insistence of tacking a line ending to the end of every line). Workaround ; don't use an editor that follows this convention, or use the binary mode of vim (by passing -b). But would people be open to making Bazaar tolerant of this condition?
<jelmer> awilkins: I think so
<awilkins> Ooh, goody
<jelmer> awilkins: what is .bzr/branch/location used for though? I don't have that file
<awilkins> It's used in lightweight checkouts to point to the location of the branch
<awilkins> Mine appeared to have been orphaned so I was editing it to point to a new spot
<schmichael> so i haven't quite pinpointed the exact way to reproduce the bug, but using bzr+ssh to a remote host that i have ControlMaster configured for in my .ssh/config file seems to break that ssh connection semi-regularly
<schmichael> it seems bzr keeps the connection open
<schmichael> so if i started a shell session first, it freezes
<schmichael> if i used bzr first and try to connect via ssh, ssh never seems to connect (like the control pipe isn't responding)
<schmichael> i'd like to let bzr use ssh connection multiplexing, but as a workaround is there a way to tell bzr what options to pass to its ssh subprocess?
<mib_dbs1teqz> When running bzr checkout --lightweight, the control directory is not supposed to come along, correct?
<jelmer> mib_dbs1teqz: it is supposed to come along, but contain almost no data
<mib_dbs1teqz> Ah
<jelmer> mib_dbs1teqz: for no control directory at all, use "bzr export"
<mib_dbs1teqz> Excellent; it's for pulling onto a live web server, so that would be best
<jelmer> mib_dbs1teqz: if you need to keep a checkout without control directory on a web server up to date, use bzr upload
<mib_dbs1teqz> What is the difference between that and export?
<jelmer> mib_dbs1teqz: export doesn't work incrementally
<mib_dbs1teqz> For small projects, would there be any noticeable advantage?
<jelmer> I think export will complain if you use it incrementally
<mib_dbs1teqz> OK.
<nevans> jelmer: is there some way to just disable the whole "discovering tags" step in bzr-svn?
<nevans> it's always by far the longest part of push or pull to the repo, and I don't really care that much if bzr-svn knows about the svn tags dir.
<schmichael> hm, the wiki seems to advocate ssh multiplexing yet it seems awfully buggy to me: http://bazaar-vcs.org/Bzr_and_SSH
<jelmer> nevans: it should be very quick in newer versions
<jelmer> schmichael: I haven't ahd any trouble with it
<schmichael> jelmer: really?  damn, wonder whats going on for me.  ubuntu 9.04 locally and debian lenny remotely fwiw
<schmichael> hm, think bzr-avahi or dbus could be to blame?  i'll try disabling them
<MattCampbell> Does Bazaar have anything similar to externals in Subversion?
<jelmer> MattCampbell: not yet, but work is underway
<schmichael> how do i display the current rev # like "hg id"?
<schmichael> ah revno
<awilkins> Offtopic : does `top` have a problem reporting process memory allocation beyond 2GB (on a 64-bit kernel) ?
<awmcclain> Is there any way to take my uncommitted changes and apply them to another branch?
<awmcclain> Since the branch I have the changes in is bound...
<dash> awmcclain: you can use bzr merge --uncommitted
<awmcclain> dash: Perfect.
<Ddorda> how do i make a patch?
<jelmer> Ddorda: bzr diff > file.diff
<Ddorda> thanks
#bzr 2009-05-22
<igc> morning
<boscop_> how can I change the language of tortoisebzr?
<PacoBuntu> Hello, can someone help me please i just installed bazaar to download some sourcecode from launchpad, but i don't know where it download it to?
<johnf> What is the best way to work out if my parent branch has new revisions?
<johnf> bzr missing looks like what I need
<johnf> does anyone else think it's a bug that bzr missing returns 1 if there are missing revisions?
<bob2> I think it's deliberate
<abli> Hi! how can I set up an lp-style repository shortcut for some other repository? I.e. to allow checkout /branch with "bzr checkout myprefix:branchname"?
<NEBAP|work> is it possible to ignore a folder in bazaar?
<NEBAP|work> IÂ´ve ignored some binary files which are created in a folder called "bin". Bazaar ignores those files correctly, but always stores the empty "bin" order which I wonÂ´t have in the repository ...
<NEBAP|work> s/order/folder
<jpds> bzr ignore bin
<NEBAP|work> ah ok cool :)
<NEBAP|work> does it ignore all "bin" folders then?
<NEBAP|work> or just the bin folder in the root?
<jpds> Just ./bin I think.
<NEBAP|work> k
<NEBAP|work> thank you
<jpds> NEBAP|work: You can check by doing: bzr ignored.
<NEBAP|work> ah ok, cool :) thanks
<Mez> is there any easy way that I can setup my system so we have a local bzr repo that mirror's itself out to a remote host automagically.
<NEBAP|work> Mez: afaik itÂ´s possible if you use "bzr checkout" to get the remote host
<NEBAP|work> after that each "bzr commit" will commit remote and after success to local repo ..
<Mez> NEBAP|work: that didn't answer my question. We currently checkout from remote. We want to checkout from local, but have that push up to remote automagically.
<NEBAP|work> Mez: afaik you can bind a branch to a remote brunch. For that I think itÂ´s necessary to make "bzr push" to the remote location and then a "bzr bind" to the remote location. If a branch is bound to another one (like after using checkout) it will always first commit to the remote location and after success to the local location
<NEBAP|work> hope this will help ..
<NEBAP|work> sadly IÂ´m just a bazaar beginner ...
<Mez> NEBAP|work: I'm not
<NEBAP|work> ^^
<NEBAP|work> is "bzr bind" what you looking for?
<Mez> probably nor.
<Mez> not *
<Mez> I want to bind to a branch and have that bound to something else, if that makes sense
<NEBAP|work> ah ok
<NEBAP|work> no idea if that will work ..
<Mez> that's what testing is for
<NEBAP|work> yeah :)
<Mez> apparently not :(
<joschan> Sorry I am really blind or making some stupiod mistake. What is wrong about "bzr mv .\*.txt .\newdir"?
<Mez> joschan: windows?
<joschan> keeps telling me *.txt is not versioned but there are many *.txt files
<joschan> windwos yes
<Mez> joschan: you need to add the txt files
<Mez> bzr add *.txt
<joschan> Mez I add them again?
<Mez> joschan: if it's saying they're not versioned, then you need to add them
<Mez> or do a checkin before you move them I think
<joschan> let me try
<joschan> The issue here seems to be that the wildcard does not seem to work when mving. When I move the files single without wildcards it does not complain. They are all checked in and commited.
<joschan> there is only a short info on http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#mv - where is the full doc of mv?
<joschan> I removed the .bzr dir and started a new archive with the correct file locations for now. Thank you!
<joschan> (if you have any suggestion I am still in the room but it is no longer urgent)
<bob2> joschan: what's with the back slashes?
<abli> Hi! how can I set up an lp-style repository shortcut for some other repository? I.e. to allow checkout /branch with "bzr checkout myprefix:branchname"?
<luks> if you don't mind "bzr checkout bm:myprefix/branchname" you can use the bzr-bookmarks plugin
<LarstiQ> if you do, you could write a directory service provider for myprefix:
<LarstiQ> luks: could the bookmarks plugin maybe support that?
<Peng_> The lp: directory service is provided by a built-in plugin, in bzrlib/plugins/launchpad/.
<Peng_> You could write your own plugin if you wanted to.
<luks> LarstiQ: maybe, but I don't like that, so I'm not going to implement that :)
<LarstiQ> luks: ok :)
<luks> but I'm not going to stop anybody else :)
<abli> Thanks, guys!
<joschan> bob2: I tried both slashes   /   and \ both the same
<joschan> do you think it needs escaping?
<bob2> joschan: it needs to not be escaped
<joschan> but slashes and wildcards work when I "add"
<joschan> but not when i move
<joschan> i just tried adding something with wildcards and slahes and it works
<joschan> maybe my python and bzr is too old - i will just wait until i upgrade this machine the next time
<joschan> bzr uses the python installed on this windows machine, does it?
<Peng_> joschan: Depends on how you installed it.
<bob2> are they really dot files?
<bob2> I would be unsurprised if windows puked on that
<Peng_> joschan: "bzr version" will explain.
<joschan> Peng_ ok it uses it's own python 2.5.2 and bzr is 1.12
<joschan> bob2 I will try again and use dotfiles
<joschan> bob2: i made another add with a dotfile, with wildcard and slash and it works
<bob2> craaaaazy
<boscop_> how do I setup bazaar on my server so that I have a private repo?
<Peng_> boscop_: Set the file permissions so it's not world-readable?
<Peng_> boscop_: If you mean the smart server (bzr://, etc.), it does no auth itself; it leaves that to sshd, the web server, etc.
<boscop_> Peng_, can I have different users that have passwords, etc?
<xnox> I've screwed up a rebase (it did everything correct but it's not what I wanted) how do I get back where I started?
<SamB> xnox: it didn't tell you what the old commit was ?
<SamB> well ... "bzr heads" could be helpful
<SamB> (from the bzrtools plugin)
<LarstiQ> verterok: have you seen http://javierder.wordpress.com/2009/05/19/bzreclipse-unofficial-release/ ?
<Pegasus_RPG> hello
<Pegasus_RPG> We're using BZR on Launchpad and have created a release branch from our vcs-imports/trunk branch
<Pegasus_RPG> now we've merged vcs-imports with the main lp trunk branch
<LarstiQ> they share ancestry?
<Pegasus_RPG> we'd now like to merge the changes from the release branch to the now-current trunk but keep the release branch for future bug fixes
<Pegasus_RPG> LarstiQ: ultimately, yes
<LarstiQ> Pegasus_RPG: ok
<Pegasus_RPG> though bzr info doesn't suggest it
<Pegasus_RPG> though looking at the histories, it appears that the release branch was branched from vcs-imports
<Pegasus_RPG> though the revision numbers are off of course
<Pegasus_RPG> so how do we go about merging the changes from the release branch to trunk without removing or changing the release branch?
<Pegasus_RPG> (This might be a LP question as well...)
<LarstiQ> cd trunk; bzr merge release; bzr ci
<Pegasus_RPG> does that assume I have local branches of both, because I currently don't.
<Pegasus_RPG> (I have a checkout of the release and nothing for the trunk yet)
<LarstiQ> Pegasus_RPG: you need a working tree to perform a merge, but release need not be local
<LarstiQ> Pegasus_RPG: so yeah, you'll need to get a local trunk to work with
<Pegasus_RPG> so for the "bzr merge release" command, "release" could just be the URL to the server directly as well as the local dir (regardless of whether that's a checkout or a branch?)
<LarstiQ> Pegasus_RPG: yes
<Pegasus_RPG> ok...what's bzr ci?
<LarstiQ> Pegasus_RPG: shorthand for commit
<Pegasus_RPG> ok
<Pegasus_RPG> so that will leave the branch unaffected?
<Pegasus_RPG> er the release branch/
<LarstiQ> it will only read from release, yes
<Pegasus_RPG> awesome
<Pegasus_RPG> thank you
<LarstiQ> np :)
<Pegasus_RPG> (My only question now is if LP will see that I merged the changes and mark bug statuses accordingly)
<Pegasus_RPG> (And not mark the release branch merged. :) )
<LarstiQ> that is LP knowledge, which I don't have, sorry :)
<LarstiQ> (or well, no knowledge of that specific part in current LP)
<Pegasus_RPG> right...thanks though! :)
<Pegasus_RPG> oh one other question, LarstiQ
<Pegasus_RPG> I want to use kdiff3 if there are any conflicts but bzr extmerge complains of an unknown command
<Pegasus_RPG> I'm on Debian testing
<LarstiQ> `bzr diff --using=something-with-kdiff`?
<Pegasus_RPG> hm
<Pegasus_RPG> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#resolving-conflicts
<Pegasus_RPG> section 4.4.5
<Pegasus_RPG> sounds good but I don't know where or how to get that plugin
<Pegasus_RPG> oh wait I found it
<Pegasus_RPG> http://erik.bagfors.nu/bzr-plugins/extmerge/
<Pegasus_RPG> I'm doing a merge from a release branch back to trunk (bug fixes) and there's a file in the branch that isn't in trunk that I want to put there. What command would I use?
<bob2> if it was added in the branch, it will be merged into trunk by merge
<Pegasus_RPG> it isn't
<bob2> was it added in the branch?
<Pegasus_RPG> it just says <trunk path>/<filename> does not exist
<Pegasus_RPG> I think so
<bob2> what says that?
<Pegasus_RPG> oh crap, no
<Pegasus_RPG> I see Mixxx.nsi.BASE    Mixxx.nsi.OTHER in the trunk
<Pegasus_RPG> and Mixxx.nsi in the branch
<bob2> sounds like it existed in both, and bzr tried to merge
<Pegasus_RPG> yeah I think a new copy was written to the branch
<Pegasus_RPG> So I just want that version
<Pegasus_RPG> er no
<Pegasus_RPG> there were some changes made to the trunk version as well IIRC
<Pegasus_RPG> so how do I resolve this without messing up the accounting of the file?
<bob2> how do you want to resolve it?
<Pegasus_RPG> using kdiff3
<bob2> well, go for it
<Pegasus_RPG> But I mean, will bzr see it as a new file if I just drop it in trunk?
<Pegasus_RPG> and lose the history?
<bob2> when foo.bar is how you want it, 'bzr resolve foo.bar', 'bzr status' to make sure the merge looks ok, then commit
<bob2> what
<Pegasus_RPG> like, right now, trunk doesn't have the file at all, just the .BASE and .OTHER ones
<bob2> to resolve a conflict, put whatever you want the resolution to be in 'foo.bar', then 'bzr resolve foo.bar'
<Pegasus_RPG> that'll keep the commit history from the branch?
<Pegasus_RPG> (I don't need to do like a bzr copy or something?)
<bob2> yes, no
<Pegasus_RPG> ok cool. thanks
<bob2> just make sure it all looks ok with 'bzr status' before committing
<cyberixae> I merged a branch which removes directories.
<cyberixae> I had some binaries from builds left in those directories.
<cyberixae> and I got a conflict because the directories weren't empty after removing the revisioned files
<cyberixae> No matter what I do bzr tells me that the directories cannot be moved because they aren't empty
<cyberixae> even, if I remove them or empty them
<cyberixae> and say "bzr resolve" after that
<bob2> delete them, 'bzr resolve', check 'bzr status'
<cyberixae> I deleted the directory
<cyberixae> cyberix@eval:/tmp/winehack/src$ bzr resolve
<cyberixae> 0 conflict(s) auto-resolved.
<cyberixae> Remaining conflicts:
<cyberixae> Conflict: can't delete src/Listener because it is not empty.  Not deleting.
<cyberixae> Text conflict in src/lib/Sample.c
<cyberixae> Even, when the directory Listener does not exist
<bob2> bzr resolve src/Listener?
<g_s_g_s> hi all, newb question. In SVN, for personal software development I've used a "trunkless" development model, i.e. branches 1.0 -> 1.1 -> 1.2 etc with no need to use a trunk. Does this map onto bzr without problems?
<bob2> sure
<bob2> (few systems care what you call your branches)
<g_s_g_s> ok, I'll give it a try
<g_s_g_s> have just tried out Hg and have found the Eclipse plugin very immature so am looking at Bzr
<bob2> don't know what bzr's eclipse integration is like these days
<g_s_g_s> I checked the bug list and it didn't look too bad in comparison
<g_s_g_s> though still a fair way to go to reach svn levels
<g_s_g_s> http://bitbucket.org/mercurialeclipse/main/issues/ vs https://bugs.launchpad.net/bzr-eclipse/+bugs
<cyberixae> bob2: Thanks. That solved it.
<bob2> ah, cool
<bob2> it is a pain/bug that 'bzr resolve' didn't
<zand3r> g_s_g_s: I'd be interested to know how you think it compares when you've tried the Bzr Eclipse plugin as that's something I'm going to be looking at imminently.
<g_s_g_s> well the Hg/Eclipse is unusable for me coz it takes 30 secs to start http://bitbucket.org/mercurialeclipse/main/issue/156/eclipse-startup-error-checking-if-mercurial-is-correctly
<g_s_g_s> so anything is better than that
<g_s_g_s> however that problem I suspect may be due to an interaction between plugins, so as everyone has a differing set of plugins YMMV
#bzr 2009-05-23
<Kilroo> I really need to try to map out how I think we ought to use bzr where I work
<Kilroo> because otherwise I think we'll probably continue with our rather slow and problematic adoption of svn.
<amanica> what other tecnologies are you using?
<KhaZ> Hello!  Perhaps a silly question, but I'm used to Perforce, and not sure the equivalent in bzr.  Say I have a file and I want to make a 'copy' of it in bzr while retaining it's history.  This is typically called an 'integrate' for Perforce - is there something similar in bzr?
<Basic> Just 1 file?
<KhaZ> Yeah
<KhaZ> Basically I just want to 'copy' the file.
<KhaZ> There's a bzr mv, but not a cp, or at least nothing I can see that's equiv.
<Basic> like this?http://bazaar-vcs.org/BzrFileCopies
<Basic> looks like open issue, confirm issue, but unresolved
<Basic> https://bugs.launchpad.net/bzr/+bug/269095
<ubottu> Ubuntu bug 269095 in bzr "bzr missing "cp" command for forking files /w history" [Undecided,Confirmed]
<KhaZ> Ah.
<Basic> Perforce is specifically mentioned in the bug report
<KhaZ> That's too bad.
<KhaZ> I'll go read, but do you know if there's a bzr analogue?
<Basic> no, the bug report, is really a feature request
<Basic> functionally is "confirmed" missing, there was a blueprint created to address the missing functionality, but no one has picked it up to write the code
<KhaZ> Right.
<KhaZ> OK, well thanks for sending me the link.
<Basic> I'm just community memory, maybe one of the core dev will answer/followup with more details
<KhaZ> Heh; well either way it sounds like I can't accomplishw hat I need to do.  I guess revision history isn't super essential for this stuff yet.
<Basic> per repo it is
<BasicTheProgram> Is there a way to cancel a PQM submit?
* BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.15final released 22 May, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<BasicOSX> Anyone have privs to uncommit releases branches?
<BasicOSX> details on ML about my mistake :-(
<Peng_> Hey, there are tags in bzr.dev now? Cool!
<Peng_> Whoever said that bzr is pulling too much data is right. The main .pack for bzr.dev is ~125 MB, but my repo is ~185.
<Peng_> I do have some extra revisions in my repo, but not 60 MB of them!
<verterok> LarstiQ: apologize the delay, yes I saw the "unofficial" release
<verterok> LarstiQ: thanks for pointing it out
<lifeless> Peng_: well, clearly you do
<lifeless> Peng_: perhaps you have stale packs?
<Peng_> lifeless: Hmm, that's possible.
<Peng_> lifeless: None.
<Peng_> Hmm, I only have 167 MB of packs. Why did I think it was 185?
<LarstiQ> verterok: no problem
<zand3r> Does anyone know if the new storage format for bzr 2 will support a "bzr cp" command per bug #269095 - I'm deciding which vcs to opt for an whilst I don't see lack of a cp command as a show stopper I can see it being useful in the future.
<ubottu> Launchpad bug 269095 in bzr "bzr missing "cp" command for forking files /w history" [Undecided,Confirmed] https://launchpad.net/bugs/269095
<zand3r> How long after an official release does the Windows installer generally appear? The current download for Windows is 1.14.1
<Peng_> Ehh, it's supposed to be a few days, but I dunno what it usually is.
<zand3r> Thanks - I'll look out for it
<lifeless> zand3r: it won't; that may be a 3.0 goal.
<lifeless> Ã¡
<zand3r> lifeless: Thanks... I'm surprised that the cp command doesn't carry more weight but at the same time I can't immediately see why I'd need one so understand why it may not be a priority.
<zand3r> Actually mercurial's description of their copy command does show a good use case - its different to what bzr bug #269095 describes.
<ubottu> Launchpad bug 269095 in bzr "bzr missing "cp" command for forking files /w history" [Undecided,Confirmed] https://launchpad.net/bugs/269095
<Peng_> zand3r: It isn't necessarily just about weight; there would have to be design changes for copies to be possible, and it's not that high of a priority.
<zand3r> Peng_:  Sorry for my waffling... I'm currently deciding which vcs we should standardise on and for some reason felt the need to spew odd thoughts into the irc channel
<Peng_> Asking a few questions is nothin' to be sorry about.
<pygi> hi
<Peng_> Hello.
<lifeless> zand3r: we have some designs in mind, its a matter of making them good, not just takckin it on :)
<spirov92> I
<spirov92> I
<spirov92> I'm new to bzr. is it good for working in teams?
<spirov92> btw sorry, the quote key is close to return
<spirov92> btw, anyone here?
<nadavoid> He
<nadavoid> Hi
<nadavoid> I'm pretty new to bzr too.
<nadavoid> I've used it on a couple of projects, just solo though.
<spirov92> but I'll be working with other people
<nadavoid> I think it is supposed to be very good for teams.  One reason is that you can start off solo, then merge your changes with others if you want.
<spirov92> but is it easy to synchronize your work, checkout, etc?
<nadavoid> I believe so. As I understand it, that's the main point of using bzr.
<nadavoid> I'll pass you some links I've found that should address working with teams.
<spirov92> nadavoid: I'm listening
<nadavoid> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
<nadavoid> There's a section on "Sharing with peers" and one on "Team collaboration, central style"
<nadavoid> and on on "Team collaboration, distributed style"
<nadavoid> https://launchpad.net/ is an option for centrally hosting a bzr project
<nadavoid> http://bazaar-vcs.org/BazaarForWebDevs - more about just publishing to a server
<spirov92> for web devs? just what I need
<nadavoid> what sort of web dev are you doing? (I'm a drupal dev)
<spirov92> php, using the Kohana framework
<spirov92> the guys on #kohana told me about bzr in the first place
<nadavoid> cool
<nadavoid> I don't think I've heard of kohana before.
<nadavoid> it looks like the main commands you'd need to use are "bzr pull" or "bzr merge"
<nadavoid> ... for staying synced.
<nadavoid> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style <-- looks like a good chapter
<nadavoid> This is the only other site I have bookmarked: http://ubuntuswitch.wordpress.com/2009/03/26/version-control-bazaar-for-web-developers/
<nadavoid> oh, and this one too... http://925html.com/techniques/using-bazaar-on-a-mac/
<spirov92> mac is too expensive, I use Linux
<nadavoid> there still might possibly be some info you can use in that article.
<nadavoid> This would definitely be my starting point - http://bazaar-vcs.org/Documentation
<nadavoid> Hope that's all helpful to you. I've been really enjoying using bzr, and I hope to have an opportunity to try the merging/collaboration features soon.  But now, I must go outdoors and clean up the yard some.  See ya!
<spirov92> nadavoid: thanks a lot, I'll check these out
<Kissaki> how do I change bzrs timezone? It does commit with UTC+2 instead of +1
<Peng_> Kissaki: It uses the system timezone.
<Kissaki> mh, but it does not...
<Kissaki> it does say 23:00 +0200
<Kissaki> and on my pc it's 23:00 +1
<Peng_> Are you sure? Do other shell applications agree? Other Python applications?
<LarstiQ> date vs date -u
<LarstiQ> Kissaki: ^^
<Kissaki> I'm on xp
<LarstiQ> d'oh!
<Kissaki> I'm using bzr on a svn server
<Kissaki> (even worse)
<Kissaki> :P
<Kissaki> and on trac, it says +0200
<LarstiQ> note that trac may do some timezone manipulation too
<Kissaki> yeah
<LarstiQ> Kissaki: is there no `date` utility for windows?
<Kissaki> well, trac does list bazaars attributes on the commit log page
<LarstiQ> Kissaki: it is of course always possible that something might be wrong, but so far all the reported cases have been thinking their timezone was not what it was
<Kissaki> which is not there on svn
<Kissaki> and that one does have +0200
<LarstiQ> Kissaki: ok
<LarstiQ> Kissaki: I'm not sure which timestamp gets used with svn, the server or the local one.
<LarstiQ> Kissaki: could you check the time on the svn server?
<Kissaki> sure, that would be the linux server then?
<Kissaki> that has +1, my local time
<LarstiQ> hmm
<LarstiQ> Kissaki: which timezone are you in?
<LarstiQ> Kissaki: it's 23:13 here, and I'm in +2
<Kissaki> Germany, UTC+1
<LarstiQ> Kissaki: CEST to be specific.
<LarstiQ> Kissaki: no, you're in UTC+2 then :)
<LarstiQ> Kissaki: daylight saving time
<Kissaki> haha, well
<Kissaki> then I'm in +2, the server is on +2
<LarstiQ> which is why I always recommend comparing `date` and `date -u` output
<spirov92> yeah, dst is crazy
<LarstiQ> spirov92: it's fun!
<Kissaki> hmm
<LarstiQ> spirov92: but not as fun as leap seconds
<Kissaki> maybe one of those other svn users is wrong then?...
<LarstiQ> Kissaki: so, bzr shows +2, and you are in +2. Is there something else out of sync?
<Kissaki> well, I wondered when I did commit, and 35 mins later someone else did commit. In the end it was 25 mins earlier (and still is) in my bzr log
<Kissaki> when I saw the bzr attribute in the commit on trac, I thought that was the problem. But it seems I did mix that up
<LarstiQ> Kissaki: even when you account for different timezones?
<Kissaki> hm?
<LarstiQ> Kissaki: ie, looking at bzr.dev timestamps, you see  Sat 2009-05-23 07:40:24 +0100 and Fri 2009-05-22 23:55:52 -0500
<Kissaki> don't get what you mean or what you're trying to tell me
<LarstiQ> Kissaki: so, when you commit, it records the time that the local computer tells it to
<LarstiQ> Kissaki: if all the computers are configured, someone in Australia can commit, and then 5 minutes later someone in the US could commit
<LarstiQ> Kissaki: if you look at just the hours, it would seem like time was reversed
<LarstiQ> Kissaki: but if you normalize to UTC, you would see that in actual fact time is still going forward
<LarstiQ> Kissaki: of course, this is assuming that the computers are telling the correct time
<Kissaki> on trac it's all correct
<LarstiQ> Kissaki: you could set your clock to 1900 and do a commit, then that would show as a timestamp
<LarstiQ> (assuming the datetime structure handles that)
<Kissaki> well, it's just a problem with qlog it seems
<Kissaki> as trac on the svn server does display everything correctly
<LarstiQ> Kissaki: do you have a screenshot?
<LarstiQ> or two, to compare trac and qlog
<Kissaki> sure, one mom
<Kissaki> LarstiQ: http://www.abload.de/img/tmpoesu.png
<Kissaki> as you can see, bzr also does have different rev numbers from the svn server
<LarstiQ> Kissaki: svn revs not matching bzr revs will almost always be the case
<Kissaki> k
<LarstiQ> Kissaki: if you look at `bzr log` (with bzr-svn enabled) you'll see it reports the original svn rev
<LarstiQ> Kissaki: I'm a bit annoyed that both trac and qlog are not showing the utc offset.
<LarstiQ> Kissaki: could you check your trac preferences for the timezone setting?
<LarstiQ> Kissaki: if trac and qlog think they are working with the same offset, there is indeed a bug somewhere
<LarstiQ> Kissaki: if trac's offset is 1 higher than qlog's, there might still be a bug in that one of the two (probably qlog) is displaying time with the wrong timezone
<LarstiQ> but if they are genuinely showing time in different timezones, they are doing the correct thing
<Kissaki> hm, can't find a timezone setting in trac.ini
<LarstiQ> even if I dislike not having the timezone information provided
<Kissaki> on trac, on a changeset it does provide the commit time, as well as the bzr attribute: bzr:timestamp: 2009-05-23 00:27:59.858999968 +0200
<LarstiQ> hmm, there doesn't seem to be a timezone setting in 0.10
<Kissaki> while they're the same apart from the "+0200"
<Kissaki> if it would help, I could give you the rep url
<Kissaki> and/or trac
<LarstiQ> hmm, but it isn't 00:27 yet in 2009-05-23 +020
<Kissaki> that was yesterday
<Kissaki> or not
<Kissaki> today 00:27
<Kissaki> so 23 hours before now
<LarstiQ> oh, *slap*
<Kissaki> *= ago
<LarstiQ> yes, you're right
<Kissaki> :)
<LarstiQ> it is my bedtime, you see ;)
<LarstiQ> Kissaki: trac 0.11 (at my work at least), has a trac.cgi/preferences
<LarstiQ> wich has a 'Date & Time' tab
<LarstiQ> the only thing you can change is the timezone
<Kissaki> using it with wsgi on apache
<LarstiQ> Kissaki: point is, /preferences as a sibling of /wiki
<Kissaki> can't find a preferences, just conf/trac.ini
<LarstiQ> Kissaki: in the web view that is
<Kissaki> wiki is in attachements here..
<Kissaki> ah ok
<Kissaki> Example: The current time is 21:37:30Z (UTC).
<Kissaki> In the Default time zone , this would be displayed as 23:37:30+0200.
<Kissaki> but that's a user setting anyway, right?
<LarstiQ> it is, but it should have it's affect on the timeline
<LarstiQ> Kissaki: so it's timezone is correctly set to +0200, good
<LarstiQ> Kissaki: can you compare `bzr log` and `bzr qlog` time?
<Kissaki> hm does list the last svn commit as 12:51 +0000 on log, and 14:51 in qlog.
<Kissaki> but 15:51 on trac
<Kissaki> oO
<LarstiQ> sounds to me like there is a computer configured 1 hour off
<Kissaki> hm
<Kissaki> that would be 2 then
<Kissaki> as mine is correctly +2
<LarstiQ> could be
<Kissaki> ^^
<Kissaki> don't think so...
<LarstiQ> I'm out of ideas as to how debug it further atm
<Kissaki> it seems to loose 1hour when pulling svn commits from svn server
<LarstiQ> jelmer: ^^
<LarstiQ> Kissaki: might be a bzr-svn bug filed about that already
<Kissaki> you filed about that already?
<LarstiQ> no
<Kissaki> but strange that it doesn't lose 2 hours then...
<Kissaki> maybe it's the summer-savings time
<LarstiQ> Kissaki: true, not all systems switch that automatically
<Kissaki> well, I'll continue to travel through time then :) (well, it's not even me but them...)
<Kissaki> trac does have it correctly after all
<Kissaki> thanks anyway
<LarstiQ> Kissaki: if you do find bzr-svn is at fault, and no one else has filed a bug like it, I think jelmer would be rather interested in how to reproduce this situation
 * LarstiQ has to go to bed
<Peng_> LarstiQ: Good night.
<LarstiQ> Kissaki: I'd be interested in hearing how things fare for you. Good luck in any case!
<LarstiQ> Peng_: thanks, you too.
#bzr 2009-05-24
<zu22> hi, i need to convert import a darcs repo into a bzr branch so i can upload it to launchpad.net
<zu22> any idea how i can do this? i've never used bzr before but am familiar with darcs (that is what i normally use for dvc)
<bob2> maybe tailor can
<zu22> ok
<zu22> thanks i will try that
<dlumberg> anyone know how to stop bzr from opening in vista when you type cmd in the search box on the start menu?
<dlumberg> nevermind, I just pinned cmd.exe to the start menu and now it hits that instead
<mtaylor> jelmer: did you ever figure out what was up with this: "Unprintable exception MissingChangelogError" in bzr bd ?
<Kamping_Kaiser> can I use a template for my commit messages? I'd like them to look more like a changelog entry then a few hacked lines.
<krisfremen> Kamping_Kaiser: template as in? date-time?
<Kamping_Kaiser> krisfremen, yeah, and defaulting to entering bullet points for the entry, instead of just 'text'
<lifeless> someone type some unicode, I need a test :)
<beuno> Ã±
<beuno> lifeless, ^
<lifeless> beuno: thanks
<GaryvdM> Hi jelmer.
<GaryvdM> I'm checked in. Would you mind if we meet up? Where are you?
<GaryvdM> I'm going to take a walk. I'll see you later.
<Glenjamin> hey guys, i'm having some issues with renaming files
<Glenjamin> according to the help text, if i do rename old new, and the old file exists in the repo, but not on the filesystem, and vice versa for the new
<Glenjamin> then it should update the pointers
<Glenjamin> but this isnt working
<Glenjamin> i just get "could not move source => target, target not versioned"
<bob2> Glenjamin: you moved without bzr, and now you want it to know about it?  bzr help mv -> --after
<Glenjamin> yeah, it didnt like renaming a directory to directories
<Glenjamin> ie, dir1 => dir2/dir3
<bob2> didn't like?
<bob2> what exactly did you do (e.g. pastebin the commands and output)
<Glenjamin> i figured out that i had to create di2, then add it, then move dir1 => dir2/dir3
<bob2> yes
<Glenjamin> i'm reorganising some packages in a java app, its a tad fiddly :)
<jelmer> mtaylor: hi
<beuno> jelmer, are you at UDS yet?
<jelmer> mtaylor: I filed a bug in Debian, james_w knows how to fix it
<jelmer__> beuno: yep, I'm here
<jelmer__> I'm at the hotel at the moment
<LarstiQ> jelmer__: welcome!
<jelmer__> LarstiQ!
<jelmer__> LarstiQ: You were right about Barcelona, it's a very nice city.
 * LarstiQ thinks he has a <zonnesteek>
<LarstiQ> jelmer__: cool :)
<jelmer> Has anybody seen Gary yet?
<jelmer> I'm sharing a room with him, and he's dropped his stuff but I have no idea what he looks like
 * LarstiQ wagers a guess on his accent
<jelmer> Hmm, so I basically need to listen in on any conversation here that involves people with laptops..
<jelmer> Never mind
 * jelmer thanks lp for profile photos
<beuno> jelmer, at the lobby?
<beuno> haven't seen you
<jelmer> beuno: yep
 * beuno goes find jelmer 
<fullermd> Ooh, a scavenger hunt!
<mtaylor> jelmer: is it something wrong with my debian dir that I can work around? bzr bd works fine with my other ones...
<jelmer__> mtaylor: yeah, bzr-builddeb can't find your changelog file
<jelmer__> mtaylor: so you need to make sure that you have a debian/changelog file
<jelmer__> or that you have larstiq = true set if you have changelog in the top-level
<mtaylor> jelmer__: weird... cause I have a debian/changelog file and it's in the debian dir (top in top level)
<jelmer> mtaylor: is it versioned ?
<mtaylor> $ bzr log --short debian/changelog
<mtaylor>     1 Monty Taylor	2009-05-23
<mtaylor>       Imported packaging.
<jelmer> hmm, that's odd :-(
<mtaylor> oh.
<mtaylor> ok - I see the problem
 * mtaylor smacks self
<mtaylor> trunk wound up not being a branch, but rather a subdir of something else
<mtaylor> jelmer: thanks! that solves all of my problems... I was being reminded of how awful the world was before bzr bd...
<jelmer> mtaylor: :-)
<jelmer> mtaylor: We still need to get that ChangeLog error fixed at some point
<mtaylor> jelmer: what would be nice is an option ... bzr bd --package-my-code-for-me
<LarstiQ> jelmer__: what, I'm still around in bd?
<GaryvdM> Hi poolie
<poolie> hello!
<poolie> are you here?
<GaryvdM> Yes! I'm sitting in the lobby.
<GaryvdM> poolie: Yes - I'm sitting in the lobby.
<poolie> cool
<poolie> i'll probably come down in a bit
<pygi> hi from Barcelona :)
<jelmer> hey pygi
<jelmer> pygi: where are you?
<pygi> jelmer: in a room
<pygi> and you? :)
<jelmer> pygi: heh
<jelmer> we're in the lobby
<pygi> jelmer: oki, we'll come :)
<fullermd> There sure are downsides to scheduling releases when most of the devs are out and about...
<aeropi> Is this the right place to ask about a loggerhead error?
<LarstiQ> aeropi: sure
<aeropi> Okay, I'm using loggerhead to show my branches and it lists on one of my branches get this branch, use:
<aeropi> bzr branch http://aeropi.co.cc:1234/py-get.main
<aeropi> *To get this branch use:
<aeropi> but when I bzr branch http://aeropi.co.cc:1234/py-get.main
<aeropi> I get bzr: ERROR: Invalid http response for http://aeropi.co.cc:1234/py-get.main/.bzr/branch-format: Unable to handle http code 500: Internal Server Error
<LarstiQ> aeropi: does it show a traceback in the log?
<aeropi> yeah, AttributeError: 'LocalTransport' object has no attribute 'startswith'
<Peng_> Oooh.
 * LarstiQ hands over to Peng_ 
<Peng_> One exclamation and I suddenly inherit responsibility? Yikes. :P
<LarstiQ> also, you know loggerhead better than I do ;P
<Peng_> Anyway, hold on, I kinda just woke up.
<aeropi> the complete traceback is, Exception happened during processing of request from ('85.145.200.35', 34272)
<aeropi> Traceback (most recent call last):
<aeropi>   File "/usr/lib/python2.6/site-packages/Paste-1.7.2-py2.6.egg/paste/httpserver.py", line 1062, in process_request_in_thread
<aeropi>     self.finish_request(request, client_address)
<aeropi>   File "/usr/lib/python2.6/SocketServer.py", line 320, in finish_request
<aeropi>     self.RequestHandlerClass(request, client_address, self)
<aeropi>   File "/usr/lib/python2.6/SocketServer.py", line 615, in __init__
<aeropi>     self.handle()
<aeropi>   File "/usr/lib/python2.6/site-packages/Paste-1.7.2-py2.6.egg/paste/httpserver.py", line 436, in handle
<aeropi>     BaseHTTPRequestHandler.handle(self)
<LarstiQ> aeropi: please use a pastebin service when it's more than two lines
<LarstiQ> right
<LarstiQ> aeropi: please use a pastebin service when it's more than two lines
<aeropi> Oops.
<LarstiQ> aeropi: or the irc network will disconnect you, as you saw :)
<aeropi> Will do in the future :(
<Peng_> aeropi: I can confirm the bug.
<aeropi> Okay.
<Peng_> Although I'm not immediately sure what to do about it. Hm
<aeropi> should I file a bug report on launchpad?
<Peng_> aeropi: Sure.
<aeropi> do you know if it's a loggerhead or a bzr error?
<Peng_> aeropi: Loggerhead.
<Peng_> Actually -- I could file the bug. Okay?
<aeropi> That would be great :)
<Peng_> aeropi: Filed bug 380026.
<ubottu> Launchpad bug 380026 in loggerhead "Transport work broke serving over http" [Undecided,New] https://launchpad.net/bugs/380026
<Peng_> Not the best-written bug ever, but oh well.
<aeropi> Thanks :)
<meoblast001> hi
<meoblast001> my knowledge of bazaar always comes and goes
<meoblast001> can anyone remind me the command for setting my name?
<meoblast001> for Launchapd
<meoblast001> hm.. maybe the manual can help
<Peng_> meoblast001: bzr lp-login your_username
<meoblast001> Peng_: found it :)
<Peng_> What's the right way to check if a transport is local? isinstance(transport, LocalTransport)?
<meoblast001> bzr whoami
<Peng_> ok
<Peng_> Oh, that.
<meoblast001> is this the correct format "Braden Walters <meoblast@aol.com>"
<meoblast001> i can never remember
<Peng_> meoblast001: yes
<meoblast001> ok thanks
<LarstiQ> meoblast001: same syntax as email address
<meoblast001> ?
<meoblast001> that would just be meoblast@aol.com
<Peng_> meoblast001: "Braden Walters <meoblast@aol.com>" is the syntax you use in email headers.
<meoblast001> oh
<meoblast001> oh my.... this laptop is hard to use
<meoblast001> random windows start popping up
<meoblast001> this thing has a mind of it's own
<meoblast001> </offtopic>
<meoblast001> Peng_: remembering how to setup bzr-cia is hard
<meoblast001> the setup doesn't actually work so you have to copy a file
 * Peng_ doesn't use cia :D
<meoblast001> Peng_: this gets more stressful and more stressful
<meoblast001> i guess i'm going to do Ubuntu version mixing
<meoblast001> i need the new nano
<meoblast001> the old one adds linebreaks that CIA chokes on
<Peng_> What's the right way to check if a branch is using a local transport? branch.base.startswith('file://')?
<Youssef> hello
<majitel> any work on editable log messages aka versioned properties last months?
<pygi> hi
<mtaylor> hey all ... not sure if this is a launchpad or a bzr issue - but I'm having bzr break-lock FAIL on a lp branch
<mtaylor> bzr break-lock lp:drizzle/mordred
<mtaylor> running 1.14.1
<thumper> mtaylor: I think you need the expanded name :(
<mtaylor> thumper: I tried that too
<thumper> mtaylor: tried with nosmart+ ?
<mtaylor> thumper: and I tried nosmart+ prefix and sftp://
<thumper> that is very screwy
<mtaylor> thumper: all of them give me TypeError: a float is required
<thumper> that sounds bad
<mwhudson> mtaylor: don't use python 2.6
<thumper> mwhudson: is that gunna get fixed?
<mtaylor> heh... that, I think, would be hard on jaunty, no?
<mtaylor> seems that /usr/bin/python isn't managed by alternatives...
<mtaylor> mwhudson: python 2.5 also breaks in the same way
<mtaylor> http://rafb.net/p/Ob1LVA21.html
<mtaylor> fwiw
#bzr 2010-05-24
<igc> morning
<lifeless> poolie: thumper asked that we not use the queue feature for the moment
<lifeless> hi igc
<igc> hi lifeless
<lifeless> poolie: 'e' for email is the new command in hydrazine
<poolie> yeah
<poolie> you broke my muscle memory a bit there
<poolie> hello igc!
<igc> hi poolie!
<lifeless> poolie: sorry!
<lifeless> poolie: if you pull my hydrazine/cron, it will show you the last comment
<lifeless> so you can see if its been sent to pqm or whatever
<lifeless> ok, first pass reviews done
<lifeless> I'm going to see if I can finish a spike I started in the weekend to make completing proposed things easier.
<lifeless> losa - did something kill stuff on balleny ? I just got an interrupted test run...
<lifeless> spm: ^?
<AfC> bzr: ERROR: No such file: u'/home/andrew/vcs/java-gnome/.bzr/repository/obsolete_packs/': [Errno 2] No such file or directory: '/home/andrew/vcs/java-gnome/.bzr/repository/obsolete_packs/'
<AfC> is that normal?
<lifeless> you've deleted that directory.
<lifeless> Don't do that.
<lifeless> and you should recreate it.
<lifeless> jam: thnaks
<AfC> lifeless: maybe bzr could create the directory if it's missing?
<lifeless> AfC: we felt it was better not to
<AfC> lifeless: hm
<lifeless> directories going missing is a pretty nasty event for the filesystem to do to us
<AfC> lifeless: and that error saying the same thing twice is better?
<AfC> lifeless: yes, I can understand that
<AfC> although we've been telling people to "delete the obscelete_packs directory" and if you're saying the nuance is to delete it's *contents* perhaps it's not uncommon to lose the directory?
<GaryvdM> Morning all
 * GaryvdM having a sleep fail :-(
<lifeless> :<
<GaryvdM> Reading bug reports - sleep fail over :-)
<lifeless> AfC: we've not been telling people to do that. Some folk have said it, I certainly never havwe.
<AfC> lifeless: oh
<AfC> I must have misread what I found in the list archive then
<lifeless> there are people that run pack, for no particularly good reason
<lifeless> except that you had to in git to get performance, at one point
<lifeless> and pack keeps the old files around because some fs's (NFS, ext4) are shonky
<AfC> it must have been from when I had a 5GB .bzr directory for a 20 MB project.
<lifeless> if people want to *immediately* gc, they can delete the contents of that dir
<lifeless> but bzr will gc it after a few commits anyway
<lifeless> (5 on average)
 * igc dinner
<kostja_osipov> hello. How do I find out the current format of my bzr repo?
<kostja_osipov> I seem to be unable to find anything in the docs...
<spiv> "bzr info -v"
<kostja_osipov> thanks!
<bialix> heya
<quicksilver> bzr doesn't deal very elegantly with the case where a directory is removed in one branch and some of the files inside are modified in the other
<quicksilver> it deals *correctly* just not very elegantly
<quicksilver> the messages you get don't immediately tell you what's happened.
<lifeless> please file a bug saying that
<lifeless> gnight
<Spyzer>  due to interruptions in my internet connection my downloading from bazaar "bzr branch lp:inkscape" is interrupted. How do i resume the downloading from the interrupted point???
<Spyzer> please help
<Spyzer> ??
<Spyzer> is there no possible way of what i ask??
<sebi`> hi, is there a command to blacklist a file (read: preventing a file to appear in the branch)?
<sebi`> since I have a bunch of gen*.sh files, which are mostly useless to the enduser
<Spyzer> how to ab\void downloading history in a bzr branch ??
<Spyzer> *ab\void avoid
<hno> Spyzer: currently only by having the history locally already...
<hno> been discussions about supporting shallow branches / history horizons, but not sure what the current status of that is.
<Spyzer> hno: if i do a bzr branch lp:inkscape and it interrupts in middle and if later on i use the option --use-existing-dir later on. Shall that resume the donwload the branch form the point it was terminated
<Spyzer> ?
<Spyzer> pls don't mind the typos
<Spyzer> its saying bzr: ERROR: Already a branch: "inkscape"
<hno> Spyzer: No idea, but I guess not.
<Spyzer> how do is\relove this
<Spyzer> oh man, is there no way to resume a download
<Spyzer> ?
<hno> It's only initial branch creation which is this heavy. If you already have branched some branch of the same project before then no need to download much again.
<sebi`> anyone? ):
<Kohlrabi> sebi`: bzr ignore?
<sebi`> Right, thanks.
<mkanat> spm: Did codebrowse get updated to trunk after I mentioned I fixed the fix better, the other day? (A few weeks ago.)
<lifeless> moin
<lifeless> jam: would like to talk network fetch efficiency if you're around
 * hno wonders if bzr wouldn't benefit from a general cache...
<GaryvdM> vila: ping
<TresEquis> hno:  you have a cache lying around ;)?
<jam> lifeless: morning. I'm trying to get reviews done, but otherwise I'd appreciate the discussion
<lifeless> jam: code or peers ?
<lifeless> peers we have until june 11 I think
<jam> peers
<lifeless> so tell me when you have a break
<jam> lifeless: did you make the peer requests, or was it done for you?
<lifeless> you make them yourself - on the left bottom there is 'add peer'
<lifeless> or something to that effect
<lifeless> we had to have the mgr review sent in monday, then there is a gap
<hno> TresEquis: Non-obvious how to make a cache to bzr with all the smartcalls around..
<jam> lifeless: so what's up?
<lifeless> well
<lifeless> we seem to be sending 2-3 times the repo size on smart push of a full branch
<lifeless> 200MB to push bzr.dev to launchpad when its not stacked
<lifeless> I struggle to believe that its the encoding overhead
<lifeless> and, possibly related, we're not saturing the network at all effectively
<lifeless> I'm patch pilot this week, so not all that well placed to just nose down and drill into this.
<lifeless> s/uring/urating/
<lifeless> I'm hoping that you or spiv will be between patches and able to look deeply into it
<mkanat> lifeless: I think a smart pull of a full branch is the same, as well.
<jam> lifeless: I'm 75% confident that it is the "split to organize 'properly'" code, and dependent on how the sort order turns up. If you want a quick and dirty test, just change the fetch order to 'unordered' and see if it doesn't drop the bytes transferred.
<lifeless> mkanat: yes, I'd expect that
<mkanat> lifeless: Oh, yeah, I suppose because of the indexes and all.
<jam> mkanat: no indices for smart pull, but push should transfer ~ the same as pull
<lifeless> mkanat: just because push and pull on the smart server are symmetrical, its just which end does the work
<lifeless> jam: so I can do quick tests
<lifeless> jam: what I want, is to know that someone else is going to run it down to ground ;)
<jam> lifeless: I've looked at this a few times, and mentioned it, and didn't get much traction anywhere...
<lifeless> jam: traction with people or code ?
<jam> people
<jam> If we really want minimal transfer then we need to compress on the server isde
<jam> side
<lifeless> ok
<jam> IMO
<lifeless> makes sense to me
<lifeless> I've been saying lp needs to scale with multiple front-end CPU boxes for a while, so it won't be a total suprise there ;)
<jam> I think we were avoiding it because of wanting to avoid load on a central location
<jam> though still a question as to whether push or pull is more common :)
<jam> most likely fetching from lp is the most common.
<lifeless> I don't recall any decision to avoid it
<jam> lifeless: we've certainly discussed wanting clients to do a bit more work than a server, since you usually have N clients and 1 server.
<lifeless> thats true
<lifeless> but, if wishes were horses ;)
<lifeless> are there any stats we should be gathering from the server to tell if this is the case ?
<jam> lifeless: the "split group" comments would be a likely point
<lifeless> ok
<jam> since it is taking existing groups, and splitting them into less efficient ones
<mkanat> jam: If there are no indices for smart pull, then what makes the pull so large?
<jam> the big thing that I've seen
<lifeless> well something I can follow through is getting some better logging and stats
<lifeless> mkanat: bugs ! :P
<mkanat> lifeless: Hahaha, okay. :-)
<jam> is when it cycles between 2 groups over and over
<jam> taking some bits from A, then B, then A, then B
<jam> those are definitely going to put a lot more data on the wire, as each split == fulltext
<lifeless> so, CHKRepo format is 'unordered' already
<lifeless> and StreamSource is groupcompress
<jam> bzrlib/repo_fmt/groupcompress_repo.py line 1025
<jam> set that to 'unordered'
<lifeless> yeah
<lifeless> vila: thanks - Working tree "/home/robertc/source/baz/bzr-test-fixes/" has uncommitted changes (See bzr status). Uncommitted changes will not be pushed. - much better.
<lifeless> ok, finding revisions taking a bit
<jam> lifeless: so I just pushed on the local network, and saw 101.5MB to transfer a random bzr branch.
<jam> size on disk when finished was 36MB
<lifeless> 3x
<jam> well, size in 'upload'
<jam> no indices written yet
<lifeless> yes
<jam> still spinning on the 'commit_write_group' I think
<lifeless> yes, we need to address that too
<jam> lifeless: one other thing to 'address' is that I think the 'should this be rebuilt' heuristic is wrong for chk pages. As it checks to see if a group is 'full enough' and if not, it rebuilds it. But chk groups got better compression by logical grouping than trying to make the groups max size
<lifeless> ok
<jam> hmm... I just waited maybe 5-10 min after pushing, and now it is on Missing Keys. Is it going to be doing the check *yet again* ...
<lifeless> would that affect the A<->B<->A behaviour you mentin abve ?
<jam> lifeless: I don't think so
<jam> I'm guessing the A B A stuff is more because of inexact sorting
<jam> The sort is stable if you have the same set of revisions
<lifeless> ok, streaming @ 70KB
<jam> but I don't know how stable it is when new stuff is added.
<lifeless> I'm on adsl, so thats maybe 1/3 of my available b/w
<jam> lifeless: well, I'm testing on the home network, and certainly not saturated.
<jam> though I'm in the basement with the WAP 2 stories up
<jam> lifeless: sending from a freshly populated repo, which only has the content in question
<jam> and I see 52.9MB transferred
<jam> note that size on disk post indicies is 50MB
<jam> 12M in indices, 39M in packs
<jam> lifeless: in the latter case, I see 18: "creating new compressed block" lines in .bzr.log, in the former, it is closer to 3,300
<jam> lifeless: case 3, push from unorganized repo, using 'unordered' texts, shows about 73.2MB transferred
<lifeless> I see many pages
<lifeless> not 3.3K worth
<lifeless> 12 pages
<lifeless> 25 per page - 300
<lifeless> 1082.823  Transferred: 68957kB (63.8kB/s r:2368kB w:66588kB)
<lifeless> that was with unordered
<lifeless> so I image it would be considerably worse without
<lifeless> I can sftp upload a file at roughly the same speed
<lifeless> +- < 10%
<GaryvdM> vila: I've merge lp:~garyvdm/qbzr/annotate_find into lp:qbzr
<jam> lifeless: @64kB?
<jam> lifeless: so your unordered and my unordered seem on par
<guijemont> GaryvdM: hi, i have a qlog question
<lifeless> yeah, 68, 71, etc
<GaryvdM> Hi guijemont.
<lifeless> jam: no, unordered is ~= SFTP
<lifeless> using lftp to upload a single pack
<jam> lifeless: I mean that uploading via lftp you get 64kB/s
<guijemont> GaryvdM: when expanding a node, some other nodes (with links to the expanded stuff) are expanded
<lifeless> so, I'm getting wire speed with unordered
<lifeless> or at least, wire + latency to london
<jam> ... Transferred ... (63.8kB/s ...)
<guijemont> but there seems to be a limit on the quantity of branches that is expanded
<guijemont> but I don't get what that limit is nor how/where it is implemented
<lifeless> `../.bzr/repository/packs/2fc2a401beb2fd09d041842e3c27ebb7.pack' at 101785571 (76%) 61.4K/s eta:7m [Sending data]
<GaryvdM> guijemont: ah - let me have a look at the code.
<guijemont> what I was looking at is colapse_expand_rev(), but I'm not sure it's the right place
<GaryvdM> guijemont: That is the right place
<guijemont> esp. since it seems ot be called with visible=True, which results to  a quite simple codepath
<GaryvdM> guijemont: It starts by looking at rev.twisty_branch_ids
<GaryvdM> guijemont: rev.twisty_branch_ids gets updated each time compute_graph_lines runs
<guijemont> hmm, and does that explain how some parents get expanded, and some other not (apparently, with lines drawn with dots)
<guijemont> ?
<GaryvdM> guijemont: It remebers what caused a branch to expand.
<GaryvdM> guijemont: e.g.: http://pastebin.org/276155
<guijemont> oh, ok, and it doesn't go more than a given number of recursions into that?
<GaryvdM> guijemont: if you expand 4, and then 3 and then collapse 3, branch line 1.1 will stay open, because 4 expanded it
<guijemont> yeah, i noticed that
<GaryvdM> guijemont: but if you expand 3 and then 2.1.1, then collapse 3, branch line 1.1 will collapse
<GaryvdM> guijemont: This is what self.branch_lines[branch_id].expanded_by is for
<GaryvdM> guijemont: If collapsing, the we 'recurse' into branch_line.merges
<guijemont> ok
<guijemont> not exactly my issue though
<guijemont> hold on
<guijemont> making a screenshot
<GaryvdM> guijemont: processed_branch_ids is to track what we have looked at so that we don't do a branch more than once, which prevents a infinite 'recursion'/loop.
<guijemont> GaryvdM: http://emont.org/dots.png
<guijemont> there, some lines are drawn with dots
<guijemont> and some of them go to the "merge level 0 ancestor" of the bzr parent
<guijemont> without expanding happening
<GaryvdM> guijemont: hmm...
<GaryvdM> guijemont: the dots indicate that the line is going to a non intimidate ancestor.
<GaryvdM> guijemont: what happens if you click on say 2972.4.2, and then click on the other parent in the lower plane?
<guijemont> hold on, i closed the window...
<guijemont> and what's a "non intimidate ancestor"?
<GaryvdM> guijemont: The line layout algorithm I use dose not suit the mysql dags well. :-(
<guijemont> well, I guess mysql is a good test
<guijemont> since I have that bug with it with my change to viz
<guijemont> because my method to expand to the parents
<guijemont> is to do it one level at a time
<guijemont> in a callback that gets called when a row is expanded
<guijemont> so, for each new row that I expand, the callback gets called again
<guijemont> but in the case of mysql, the depdth at which you go with that is too big
<guijemont> and I end up with a maximum recursion exception
<guijemont> so i wanna try to do that iteratively instead
<GaryvdM> guijemont: e.g.: http://pastebin.org/276155 - if branch line (bl) 1.1 is visible, and bl 2.1 was hidden, we would show a dotted line from 3 to 1.1.1. 1.1.1 is not a parent of 3, but rather a distant ancestor...
<GaryvdM> =  "non intimidate ancestor"
<guijemont> GaryvdM: do you know of a document that explains that kind of vocabulary?
<fullermd> It's not polite to intimidate your ancestors.
<GaryvdM> guijemont: no sorry, these are things that I've kind of made up. I'm sure there are definition of these things in formal graph theory, which I have unfortunately not studied.
<guijemont> ok
<fullermd> ITYM "immediate"...
<GaryvdM> fullermd: yes - thanks
<guijemont> ahh
<guijemont> oh
<guijemont> ok
<guijemont> might be clearer with "immediate"
<GaryvdM> jam is seems very knowledgeable about graph theory. Maybe he can give us the correct terms.
 * fullermd thinks there need to be more terms like "weird uncle".
<GaryvdM> guijemont: In the code, I refer to non immediate ancestor as direct = False
<fullermd> How about 'indirect'.
<GaryvdM> direct = False / indirect = True
<fullermd> I mean as a term.
<guijemont> I'm sure I *knew* all this graph theory vocabulary well
<fullermd> Makes sense as the opposite of direct.
<guijemont> though I knew it in french...
<GaryvdM> guijemont: It also does not help that I'm terrible at spelling :-(
<guijemont> hu
<guijemont> btw, I think colapse_expand_rev() should be called collapse_expand_rev() ;)
<lifeless> yes
<GaryvdM> yes - that is one of my spelling mistakes....
<guijemont> anyway, I think I get how the dotted lines work now
<guijemont> at least the idea, which is what interests me now
<guijemont> GaryvdM: thanks!
<GaryvdM> guijemont: Pleasure.
<GaryvdM> Spelling of 'collapse' fixed. :-)
<guijemont> cool, so I did something useful today, i reported a bug that got fixed :)
<guijemont> now I feel productive
<guijemont> I can go to bed
<lifeless> mwhudson: hi
<mwhudson> lifeless: hello
<lifeless> mwhudson: I'd like to get stats on bzr smart server stuff on production
<lifeless> I'm sure you've considered this.
<lifeless> care to tell me the shortest path ? :)
<mwhudson> lifeless: 'stats' ?
<lifeless> how many split groups per push/pull
<lifeless> vs unsplit groups
<lifeless> total bytes sents
<lifeless> possibly drilling in further
<mwhudson> lifeless: i guess something like:
 * mwhudson thinks a bit more
<lifeless> like
<lifeless> I'm not scared if you say 'change bzr, change bzr-lp-serve, change oops, and change this odd crnoscript
<mwhudson> lifeless: i guess something like: arrange for the bzr serve processes to log somewhere more obvious than ~/.bzr.log
<mwhudson> lifeless: then make sure that the bzr serve processes log the information you want to see (possibly with a -D style flag i guess?  maybe this already exists)
<mwhudson> lifeless: arrange with sysadmins to copy log files somewhere you can see them
<mwhudson> lifeless: write scripts to parse said log files
<mwhudson> lifeless: none of these steps seems particularly hard
<lifeless> ok
<lifeless> whats unobvious about ~/.bzr.log ?
<mwhudson> i got a bit frustrated at one point because i wanted to have the bzr serve process log to a file like bzr-serve-$PID.log but by the time you know the pid it's too late to set $BZR_LOG_FILE (or whatever that's called)
<mwhudson> lifeless: well, perhaps 'obvious' was the wrong word
<lifeless> ok
<lifeless> what would a better word be?
<mwhudson> lifeless: it has the output of all the bzr serve processes jumbled up in it, it's not synced anywhere, and it gets rotated by bzr's policy not the sysadmin's
<lifeless> ok, the first point is fine (we put pids in), the sync issue we can fix, the rotation however - we should fix that in bzr.
<lifeless> log_rotation = None in ~/.bazaar.conf ?
<lifeless> .bazaar/bazaar.conf, I mean
<mwhudson> i guess that works
<lifeless> We can work up to other things
<lifeless> alternatively
<lifeless> perhaps
<lifeless> log_file = ~/.bazaar/logs/$time-$pid.log
<lifeless> in bazaar.conf
#bzr 2010-05-25
<lifeless> that would permit doing what you wanted, no ?
<lifeless> mwhudson: ^
<mwhudson> lifeless: that would be great, yes
<mwhudson> (although it would be /srv/bazaar.launchpad.net/production-logs/bzr-$time-$pid.log or something for us i guess)
<lifeless> wel sure
<lifeless> I wouldn't care at that point :P
<lifeless> ok, nose down on this patch
<poolie> jam, still here?
<poolie> hi lifeless, mwhudson
<lifeless> hi poolie
<mwhudson> hello poolie
<spiv> lifeless, mwhudson: for lp, including $lpuser in the filename would be ideal
<spiv> Well, maybe.
<mwhudson> spiv: it would be in the command line arguments that are logged to the file, would that be enough?
<spiv> Harder to do, though.
<spiv> mwhudson: yeah
<lifeless> I think the criteria are:
<lifeless>  - unique file name
<spiv> If I'm e.g. debugging a user issue from IRC, or just testing something myself, I'm more likely to know the lpuser name than the pid or exact timestamp on the server.
<lifeless>  - easy to do date trimming
<lifeless> spiv: right, but thats l osa ping to get it rsynced immediately anyway
<spiv> If I can grep for the username from a bunch of log files, then that's adequate, but not ideal.
<lifeless> well
<lifeless> step 1) do the core
<mwhudson> spiv: it would be user id anyway
<spiv> mwhudson: heh, ok
<mwhudson> another option is to have the lpserve plugin change the log file
<spiv> mwhudson: that's ok for me, I think I know my user id ;)
<mwhudson> i don't know how fixed it is by the time the run() method gets control
<spiv> Hmm, the classic "want to start logging as soon as the code starts, but can't actually log to a file until we have read the config" problem.
<lifeless> spiv: oh, are you looking into this?
<spiv> lifeless: no, just musing
<poolie> so this remember_remote bug - should we mark this as a dupe and then create a SRU bug against 2.1?
<spiv> lifeless: the "lpserve command might like to inform where logging goes" just struck me as another instance of that general issue.
<lifeless> poolie: its a bug in ubuntu, not in upstream, so nothing to dup it against;
<lifeless> poolie: we can use it for the SRU when 2.1.2 is released
<spiv> I'm not sure if marking as a dupe has much practical benefit.
<poolie> isn't it the same bug as 528041?
<lifeless> bug 528041
<ubot5> Launchpad bug 528041 in Bazaar "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 16, heat: 0)" [High,Fix released] https://launchpad.net/bugs/528041
<poolie> this seems like just an Ubuntu task on that bug
<lifeless> we could, but I think it would just add noise to the closed bug
<lifeless> with an upstream bug it would reduce the bugs found in searches etc, but it won't do that here because the other task will stay open, but doesn't influence results in searches on /b zr
<lifeless> ok, bbiab
<igc> hi all
<mgz> hey.
<mgz> ...a sign I should be asleep
<spiv> Heh.
 * igc lunch
<echo-area> spiv: I finally solved the problem using bzr-svn.  It was because the subversion client I used did not support http protocol
<spiv> echo-area: huh, weird
<thumper> poolie: bug 585126
<ubot5> Launchpad bug 585126 in Launchpad Bazaar Integration "sendbranchmail is eating memory (affected: 1, heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/585126
<poolie> hi
<thumper> poolie: I'm trying to get more info
<thumper> poolie: but since this process just calls into bzr
<thumper> well, bzrlib
<thumper> I'm guessing there is some memory issues
<poolie> ok
<thumper> I was going to add a bzr tag
<thumper> not tag
<thumper> task
<thumper> but wanted more info first
<poolie> ok i'm just trying to help with loggerhead first
<lifeless> back for the afternoon shift ;)
<bialix> hi igc
<igc> hi bialix!
<bialix> hi :-)
<bialix> I always was curious about what is going on on the sprints. so this time I've written too much detailed report. I hope you like it
<lifeless> in principle I can suspend and resume now
<spiv> lifeless: That must be very handy, in principle.
 * igc bbiab
<echo-area> I see this in branch.conf after execute bzr join: submit_branch = file:///home/xgp/rank/trunk
<echo-area> does this mean when I do bzr ci, the repository in file:///home/xgp/rank/trunk will also be updated?
<lifeless> no
<lifeless> it has to do with the 'bzr submit' command
<lifeless> you can read about it in bzr help configuration
<StevenK> I'm having trouble with bzrlib.transport -- it's a contrived example, but I'd like to connect, cd and then disconnect. I then check if the directory was created out-of-band, but I can't get that working by itself -- if I put in a few mkdir calls, it works.
<echo-area> which plugin does submit belong to?  There seems no such command by default
<StevenK> echo-area: pqm, I think
<lifeless> sorry
<lifeless> 'send'
<lifeless> StevenK: so, transports don't 'cd'
<lifeless> StevenK: ever
<lifeless> if a protocol requires a cd operation, it will do that transparently as needed
<lifeless> whats the protocol you are testing?
<poolie> lifeless, is work on fetch performance still ongoing or is that now done?
<lifeless> poolie: ongoing, network fetch is highly problematic
<lifeless> I was talking with John about it this morning
<lifeless> oh, about 5am your time
<poolie> lifeless, http://sourcefrog.net/tmp/1w/kanban.png
<poolie> i'm going to try keeping this up to date
<StevenK> lifeless: Both FTP and SFTP
<poolie> so is it still an active task, or just something we need to come back to as an ongoing issue?
<lifeless> poolie: current critical bug
<lifeless> which is approximately equal to 'active task'
<echo-area> lifeless: ah I see, it is used as a position to be compared with
<echo-area> StevenK: thanks
<lifeless> poolie: I think you should add to the udd thing a 'dsc-import branch to loom converter'
<lifeless> which spiv was interested in doing
<poolie> as something we're working on now, or something we want to do?
<lifeless> but I think its currently behind the sigwinch fallout
<lifeless> and addressing network clone
<lifeless> which is for udd too
<lifeless> because initial clone is what they hit a lot
<poolie> spiv, i agree, news merge is most interesting as an example of writing generic hooks
<lifeless> poolie: I think there is a lower bound of branch size we should track in kanban; I'm not sure where that bound is.
<lifeless> I mention that because of the sigwinch task; I feel its kindof close to the boundary
<spiv> It's a bit of a question of "if we build it will they come", but so far there's just the debian/changelog hook and that seems to be Good Enough for current purposes.
<poolie> lifeless, i agree on both points :)
<lifeless> \o/
<lifeless> now
<lifeless> I need to do the I'm great review
<lifeless> and then tickets
<poolie> i plan to grope around until i find something that feels about right
<lifeless> and *then* I get back into stuff
<poolie> so are there any updates i should make for you?
<lifeless> well this week is patch pilot
<lifeless> I think thats kanban noteworthy
<poolie> it's on there
<lifeless> even though its roughly steadystate
<lifeless> oh sorry, perhaps I should look and thing, not just engage fingers
<poolie> i think we can get a couple of things out of this
<poolie> np :)
<poolie> one is making sure we don't unintentionally stall things
<poolie> and the flip side also, which is not taking on too many things at once
<poolie> the tool is a bit slow
<poolie> and clumsy
<poolie> so i'm not 100% sure it's worth mantaining, but it might be
<lifeless> so this week I'm
<lifeless> pp
<lifeless> hopefully landing a spike I spent the weekend on to review stuff locally - process improvement for pp for any bzr+lp project
<lifeless> reviewing/discussion test stuff with you - that spike has some factory objects for us to discuss how it feels
<lifeless> beyond that its network performance
<poolie> fixture factories?
<poolie> i was thinking about that
<lifeless> yeah
<lifeless> just in the launchpad plugin
<poolie> perhaps i will try to do it first by documenting the pattern and adding any hooks just in testtools
<lifeless> for testing launchpadlib using code
<lifeless> oh
<lifeless> and waiting for the NZD to fall again
<poolie> unlikely
<poolie> imo
<lifeless> heh
<poolie> well, compared to aud, or something else?
<lifeless> aud
<lifeless> its much higher than usual
<poolie> i wonder
<lifeless> shrug
<StevenK> lifeless: Like I said, it was a contrived example.
<poolie> i think both au and nz look good compared to other places atm, and au just had the super profits tax
<lifeless> StevenK: sorry, was checking code and poolie distracted me :)
<lifeless> StevenK: in FTP, stat triggers a chdir
<lifeless> StevenK: because thats how we check if its a dir - yes, sad but true.
<lifeless> StevenK: is it chdir you specifically need to receieve on the backend server? What if someone doesn't chdir but just writes to 'thedir/afile'
<StevenK> lifeless: So, this is a test for poppy -- it's a explicit test to see that CWD (ie, the FTP command) creates the directory.
<lifeless> ok, in bzrlib, do stat(thedir)
<lifeless> that will do a chdir
<lifeless> fot FTP
<lifeless> I'm checking SFTP protocol now
<StevenK> So transport.stat() ?
<lifeless> yes
<lifeless> see line 69 in bzrlib/transport/ftp/__init__.py for the gore
<StevenK> I'm not sure I want to. :-)
<lifeless> SFTP does not have a CWD
<lifeless> so I don't know how you'll write that test for sftp :)
<StevenK> I just got IOError for SFTP
<StevenK> Which, given what you just said, is expected
<StevenK> lifeless: However, it does work great with FTP
<lifeless> SFTP has REALPATH and the client uses absolute paths for everything
<lifeless> http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13
<lifeless> section 8.9.1
<StevenK> Well, ... bugger
<spiv> StevenK: perhaps this is a silly question, but if you are testing FTP behaviours directly perhaps you should use ftplib directly?  (Perhaps in addition to a test that "bzrtransport.put_bytes('somedir/foo', 'bytes')" triggers the auto-creation of 'somedir' in your server, if that's what this aiming to achieve?)
<lifeless> StevenK: what I'm interested in is why you care that 'cwd' makes the directory
<lifeless> StevenK: because in FTP its possible - and efficient clients do this - to not cwd *at all*
<lifeless> I would expect one of two things here
<lifeless> a) client X needs to work and it cd's
<lifeless> b) I've put the mkdir code behind the cwd trigger and ... oops
<lifeless> if its A, I'd say you want *a* smoke test for it, because even if you rearrange things you want to be sure it still works
<lifeless> if its B, I think the code is likely in the wrong place, and you really want to trigger it on all of cwd / put / list where that dir is included
<StevenK> spiv: The tests in question did use ftplib, I'm changing it to test both FTP and SFTP, and would like to use the same test code.
<spiv> StevenK: hmm, well given that neither SFTP or bzrlib.transport has the concept of chdir, it seems you need to rethink the constraints.
<lifeless> I'd reuse the same test code for things that are common
<StevenK> Yes, I'm thinking so. Given I create missing directories in the chain before mkdir and openFile, it should be fine ...
<lifeless> your backend could just do 't.create_prefix
<lifeless> ()' :)
<StevenK> And, as you say, SFTP doesn't even have the concept of it
<spiv> If you decide that what you want is to support automatically creating the directory on any sort of access, then perhaps changing the specific operation you use in the test from chdir to stat/mkdir/open would do.
<lifeless> silly question
<lifeless> but why isn't it the same code for both sftp and ftp ?
<lifeless> single daemon, per-protocol glue back to a common engine ?
<StevenK> lifeless: As in, server-side?
<lifeless> yes
<spiv> I think lifeless's remark about "reuse the same test code for things that are common" is key, all you have to do is redefine what you're doing to make as much as possible common ;)
<lifeless> then you'd not need to care about all this details
<StevenK> lifeless: Because I didn't want to rewrite poppy
<lifeless> isn't poppy hugely unreliable ? :)
<StevenK> And bigjools said not to :-)
<lifeless> I think that that may be a mistake, unless you're turning FTP off in 6 months
<StevenK> lifeless: I'm not sure what the timeline is.
<lifeless> if its not trivially short
<lifeless> you're going to be maintaining dual stacks
<lifeless> that is rather painful. Just saying.
<StevenK> Actually, I've got the SFTP code hooking into much of the guts of the FTP support code
<StevenK> But yes, I agree
<lifeless> *I* don't need to maintain it, though I may need to let you cry on my shoulder.
<vila> hmm, looks like I didn't say hi... Hello bzr world !
<poolie> hello vila
<GaryvdM> Hi vila
<GaryvdM> I fixed some bugs with annotate_find, and merged it in to trunk.
<GaryvdM> One bug I could not reproduce, is that you could not type numbers in the goto line text box.
<GaryvdM> http://irclogs.ubuntu.com/2010/03/17/%23bzr.txt
<GaryvdM> vila: Please let me know if that still affects you.
<vila> GaryvdM: great ! I will switch my qbzr branch back to trunk and let you know
<GaryvdM> vila: Thanks
<vila> GaryvdM: indeed, can't type numbers :-/
<vila> GaryvdM: can't type anything for that matter...
<vila> GaryvdM: well, except return which gives me a traceback with: ValueError: invalid literal for int() with base 10: '', but that's expected I suspect
<GaryvdM> vila: Ok - I'm using a qt class to make sure that you can only type numbers in. I'll reimplement my own
<igc> night all
<GaryvdM> vila: Please could you run this and tell me what it outputs: http://paste.ubuntu.com/439248/
<vila> GaryvdM: Acceptable
<vila> GaryvdM: but why do you need *me* to test it ? Suspecting a weird qt version ?
<GaryvdM> vila: yes - You are the only person that experiences the bug
<GaryvdM> vila: Thanks
<GaryvdM> the only person that I know of...
<vila> ok, it may come from my X/keyboard combo though...
<vila> GaryvdM: Is there a way to echo the characters typed on the console ?
<GaryvdM> vila: Yes - I'm going to write another example.
<GaryvdM> vila: http://paste.ubuntu.com/439258/
<vila> GaryvdM: http://paste.ubuntu.com/439261/
<GaryvdM> vila: Thanks
<GaryvdM> vila: for me: http://paste.ubuntu.com/439262/
<poolie> ok so that was pretty fun, but now that's enough
<poolie> good night all
<vila> g'night poolie
<GaryvdM> Night poolie
<vila> GaryvdM: weird
<GaryvdM> Hey bialix
<bialix> hey Gary!
<vila> bialix: das vidania Sacha
<vila> (not sure about spelling...)
<bialix> da svadanya
<bialix> da svidanya
<bialix> vila: you left us?
 * bialix even does not have a chance to say bonjour
<vila> bialix: rats, spelling and meaning wrong, I thought it was hello :)
<bialix> then: privet
<bialix> vila: ring a bell!
 * vila had to check with Valentine :)
<vila> bialix: :-P
<bialix> GaryvdM: how's your mac?
<bialix> ;-)
<GaryvdM> Non existent. I need to ping poolie
<GaryvdM> bialix: I'm not sure what the process would be.
<lifeless> GaryvdM: neither are we
<lifeless> but we can figure it out
<lifeless> email him
<GaryvdM> lifeless: Ok
<lifeless> GaryvdM: 20 hours to the crabatron for me :>
<bialix> crabatron??? %-/
<lifeless> the flash game jam introduced us to, in facebook
<GaryvdM> bialix: backyard monsters
 * bialix nods
<GaryvdM> bialix: I'll invite you - but proceed with caution - highly addictive
<bialix> no, thanks!
<GaryvdM> ok
<GaryvdM> vila: Please will you try http://paste.ubuntu.com/439276/
<GaryvdM> vila: No output, please just check behavior.
<vila> GaryvdM: works fine, output nothing :)
<GaryvdM> vila: Great - Thanks
<vila> GaryvdM: by the way, avoid variable names that are also basic python types (str)
<GaryvdM> vila: Ah - thanks - good point
<vila> GaryvdM: so you found a workaround, but do you understand what was happening ?
<vila> just curious
<GaryvdM> vila: no
<ricotz> hello, is there something like "git format-patch"? Which does "bzr diff -r1320..1321 > ...diff" automatically for multiple revision starting with a specified one?
<MvG> lifeless: Wrt https://code.launchpad.net/~gagern/bzr/bash_completion-ExecutableFeature/+merge/24951 is http://paste.ubuntu.com/439278/ more to your taste?
<GaryvdM> ricotz: maybe bzr bundle. It's not what you are asking for, but may solve you problem.
<GaryvdM> *your
<lifeless> MvG: yes. I'd still just make path an attribute, I don't see where you depend on the None value
<MvG> lifeless: I don't depend on the None value, but as I wrote, I want to impose no order constraints.
<lifeless> MvG: but there *is* one
<MvG> lifeless: In other words, it should be OK to first save the path in a local var, and then check the feature, and then use the path.
<lifeless> you don't need to impose it, it exists a priori
<ricotz> GaryvdM, i need a plain diff for every commit, i think this doesnt do it
<MvG> lifeless: But the property ensures the check gets performed before a path is returned.
<lifeless> I'm totally confused
<lifeless> why would someone save the path in a variable
<MvG> Why not?
<lifeless> why
<lifeless> gnar gnar gnar :P
<GaryvdM> ricotz: Ok - I don't think we have something like that. You could script it.
<ricotz> GaryvdM, yeah i wanted to avoid that ;-)
<lifeless> MvG: I think its ok to land in this form. I'm saying though that I think its still more complex than needed due to how we use features
<lifeless> MvG: it is ok for us to disagree
<MvG> lifeless: I don't think it is too complex to understand, and it ensures that nobody will have to worry about the internals to use this thing, even if people do crazy stuff like save the path in a local var.
<lifeless> the use of _probe has made me happy
<lifeless> IME you can tie yourself in knots catching crazy stuff that never happens ;)
<GaryvdM> ricotz: "bzr log -r-2..-1 -p" is close, but includes the revision info above each diff.
<MvG> OK, then I'll commit and push, so you can approve, and we can get this merged one day.
<lifeless> oh
<lifeless> one more thing
<lifeless> def path(self):
<lifeless>     self.available()
<lifeless>     return self._path
<lifeless> self._path is inited to None
<MvG> If you prefer.
<lifeless> just a thought
<lifeless> less code
<lifeless> up to you
<ricotz> GaryvdM, thanks, i will make a script
<lifeless> doesn't seem much point initing self._path if you're going to never access it until after _probe
<lifeless> I may be overanalysing :P
<MvG> lifeless: pushed.
<idnar> bzr info is telling me "ERROR: No repository present"
<idnar> has my branch gotten corrupted or something?
<idnar> oh, nevermind, I think I know what happened
<MvG> lifeless: Do you want to approve https://code.launchpad.net/~gagern/bzr/bash_completion-ExecutableFeature/+merge/24951 ?
<lifeless> MvG: bb:tweak
<MvG> lifeless: Tweaking already. I assume the same holds for bash_feature.
<lifeless> naturally
<ia> hello. could anyone tell me, please, does exist some way to edit text of (not last) commit, which has been done?
<maxb> Not without rewriting all history after the point of the change
<maxb> So mostly, "no"
<GaryvdM> vila: qannotate find bug fixed in trunk :-)
<GaryvdM> sorry goto line
<vila> GaryvdM: yeah !
<vila> GaryvdM: I understood :)
<MvG> lifeless: Tweak pushed and ready for approval. :-)
<bialix> GaryvdM: is it intended change in qbzr that throbber now shown in the middle of the window and without label "Loading"?
<GaryvdM> bialix: No.
<GaryvdM> bialix: I fixed that a little while ago :-)
<bialix> hmm, I've just updated to latest revno in trunk and its gone, or... lemme check
<bialix> it seems ok now
<GaryvdM> bialix: rev 1268 broke it, rev 1270 fixed
<GaryvdM> Specifically 1166.1.14
<bialix> yep, I had 1269, and just updated to 1270. ok, thanks!
<GaryvdM> bialix: bug 485236 fixed \o/
<ubot5> Launchpad bug 485236 in QBzr "qlog branch1 branch2: should show me branch labels even if both branches equal (affected: 1, heat: 6)" [Medium,Fix released] https://launchpad.net/bugs/485236
<bialix> aaaa! \o/ -o- \o/
<bialix> cool!
<GaryvdM> bialix: are you working on bug 485236 or can I tackle it?
<ubot5> Launchpad bug 485236 in QBzr "qlog branch1 branch2: should show me branch labels even if both branches equal (affected: 1, heat: 6)" [Medium,Fix released] https://launchpad.net/bugs/485236
<GaryvdM> sorry Bug 585309
<ubot5> Launchpad bug 585309 in QBzr "qlog for multiple branches: use unique tail of branch URL for label, not the nick (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/585309
<bialix> oh
<bialix> anyway
<bialix> cool
<GaryvdM> bialix: were you looking at it?
<jam> lifeless, GaryvdM: 23hrs to D.A.V.E. :)
<jam> morning all
<GaryvdM> jam: Morning - I don't like the sound of that :-(
 * GaryvdM upgrades towers....
<jam> well, honestly I'm also goo capped (about 8.6M), so I need to start rampaging a bit :)
<GaryvdM> lucky I'm under protection for another few days.
<GaryvdM> lifeless and I may need to team up...
<bialix> what it means: GaryvdM>	bialix: were you looking at it?
<GaryvdM> bialix: Were you looking at (working on) Bug 585309
<ubot5> Launchpad bug 585309 in QBzr "qlog for multiple branches: use unique tail of branch URL for label, not the nick (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/585309
<bialix> no, I'm not working on that bug
<bialix> GaryvdM: you can tackle it. please!
<GaryvdM> bialix: Ok - I'm going to takkle it. I want it for https://code.launchpad.net/~craighewetson/qbzr/qlog-revert-multi-tree/+merge/25724
<GaryvdM> bialix: I was thinking we could do "path (nick)"
<GaryvdM> bialix: "long path... (long nick...)"
<GaryvdM> bialix: I wonder if I can see if the nick is explicitly set, or if it is getting it from the path.
<bialix> I think we can use url schemes as well, so for local trunk and remote trunk we can show: file://trunk bzr://trunk
<bialix> just an idea
<bialix> do we really want to show a nick?
<GaryvdM> biailx: If the nick is set - yes
 * bialix shrugs
<GaryvdM> bialix: re url schemes - I think it's too long - rather show the full url in the tooltip.
<GaryvdM> bialix: So most of the time, you don't set the nick, but if you do, you want it to show.
<bialix>  dunno
<GaryvdM> jam: I was wondering if it would be possible to do char level annotate. (I'm dreaming up a gobby like app with bzr as the back end.)
<jam> GaryvdM: certainly, the most common thing to do is to use line-level comparison, and then do char level / word level matching afterwards
<jam> It isn't exposed via our internals, but it is *possible* to do.
<GaryvdM> jam: ok - cool
<jam> GaryvdM: I guess one of the big things is to determine how you would represent that information as a dataset
<jam> having an annotation per char would be expensive
<jam> but you could probably do something with annotation ranges, etc.
<GaryvdM> jam: represent in memory, or represent to the user?
<GaryvdM> oh nvm - in memory
<jam> ultimately, probably both, but yeah, figuring out how to represent the info efficiently would be a reasonable starting point
<jam> and then figuring out how to break up ranges, etc.
<MTecknology> any ideas what would cause this error? bzr: ERROR: Permission denied: "/bidding_system/": [Errno 13] Permission denied: '/bidding_system/'
<jam> MTecknology: you don't have perms on '/bigging_system' ?
<jam> :)
<MTecknology> jam: i checked the guys permission on the server and client... it's fine :S
<jam> MTecknology: what command are you using, and can you run with -Derror to get a traceback?
<MTecknology> jam: bzr branch bzr+ssh://user@user.code.kalliki.com/home/user/project/branch
<jam> MTecknology: and 'bidding_system' isn't involved at all?
<MTecknology> jam: s/branch/bidding_system/
<GaryvdM> Is it possible to hide the log and tracebacks when runing selftest, and only see the exception message?
<GaryvdM> I only want to see :
<GaryvdM> AssertionError: not equal:
<GaryvdM> a = 'a'
<GaryvdM> b = 'b'
<mgz> yup, go back to r4919 :)
<GaryvdM> mgz: :-(
<mgz> not sure if I've filed a testtools regression bug for that one yet
<mgz> but yeah, now you get everything printed in full, twice
<mgz> there's no easy way just to get the exception instance string either, as testtools throws away the context and just stores the full traceback
<mgz> (it used to just be print str(exc_info[1]) basically)
<GaryvdM> MTecknology: Have you checked that the user running the bzr server has permissions to the path?
<GaryvdM> MTecknology: I'm not sure if that would affect it.
<MTecknology> GaryvdM: ya, we all use the same user account (teams) - i m\told him to delete his local branch and he never got back to me so i'm assuming it's working now..
<GaryvdM> ok
<MTecknology> thanks
<mgz> would be nice to throw prettier permission denied errors
<mgz> on nix you could at least get the user/group/bits of the problem file or directory
 * bialix waves on mgz
<mgz> hey alexander!
<mgz> ...I need to comment on your diff thread
<mgz> have three or four things to catch up with, have been concentrating bzr time on finishing off one scary bug
<mgz> ugh, if Robert wants me to add news to this old branch, I'm gonna have to merge trunk
<mgz> meh, will do it later.
<bialix> mgz: if you will use my nick bialix I'll get aggressive notifications from Chatzilla wen you talking to me ;-)
<bialix> but I don't have such nice bell as vila. heh
<vila> bialix: grr :)
<mgz> ehhehee
<GaryvdM> vila: lol
<bialix> GaryvdM: I'm still want a cookie^W visible square for checkbox "Word wrap" in the new qannotate toolbar. I forgot: is it possible?
<GaryvdM> bialix: That would be good. We could do that if the options show in a popup widget, and not a menu.
<bialix> and what we should do for this? we talked about this "word wrap" at uds, but I don't remember conclusion
<GaryvdM> bialix:  It may make more senses if the other things in the menu are actually menu items.
<GaryvdM> I like the idea of it being a menu, because then on macs, we put it in the menu
<GaryvdM> bialix^
<bialix> I thought you have in mind to avoid menu on all platfroms
<GaryvdM> bialix: macs are special...
<bialix> grrr
<GaryvdM> bialix: I just noticed that other apps have boxes for checkable menu items, so it must be possible.
<GaryvdM> biailx: Please tell me if there are boxes next to the options in the view menu in chatzilla on windows
<mgz> boxes? there's a space for ticks to go, but no box in view menus here
<GaryvdM> mgz, bialix: I have boxes... http://imagebin.ca/view/FW5LTMT.html
 * GaryvdM going to get food.
<mgz> ugh, that white thing by Show Timestamps isn't right, surely?
<GaryvdM> mgz: yes
<GaryvdM> let me see how it is on other themes
<GaryvdM> mgz, bialix: http://imagebin.ca/view/w5d20MMc.html
 * GaryvdM really goes now :-)
<mgz> okay, that way is less offensive to the eye
<bialix> GaryvdM: no boxes on Windows
<bialix> that's why I'm complaining
<bialix> GaryvdM: http://imagebin.ca/view/62EWypp.html
<bialix> it looks incomplete this way on Windows
<bialix> you make me cry
 * bialix going home in sadness
<bialix> ~~~
<GaryvdM> bailix:
<GaryvdM> dam - just got back
<mgz> you killed him!
<cody-somerville> Why is the commit method undocumented? :P
<james_w> it's not an important one
<james_w> why would anyone ever want to commit?
<cody-somerville> good point
<cody-somerville> :P
<cody-somerville> Using bzrlib, how can I set the committer field?
<GaryvdM> cody-somerville: tree.commit('first  post', committer="Joe Soap <joe@acme.com>",
<GaryvdM>                             authors=["Foo Baa <foo@example.com>"])
<cody-somerville> cool.
<cody-somerville> And how do I create a new remote branch to push to?
<mgz> meh? launchpad doesn't like me specifying multiple reviewers in a merge proposal? I swear I did that before
<mgz> I thought just comma seperating names in the reviewer input field worked...
<cody-somerville> GaryvdM, I figured I could just open a remote branch that doesn't exist and then push a local branch to it but opening the non-existent remote branch results in a NotBranchError.
<GaryvdM> cody-somerville: Looking at the code for push, you can use branch.create_clone_on_transport
<cody-somerville> I was thinking the same thing but was hoping it was going to be easier then that as it appears I need to construct a transport and everything myself using that function.
<james_w> cody-somerville: there's not really a convenience function for doing that
<mgz> argh. interrupted a launchpad push, and it's now got a lingering lock. can I break lp server side locks and resume the push?
<mgz> okay, seems to have worked, let's hope I didn't screw anything up too badly
<LeoNerd> bzr: ERROR: Can't export tree to non-empty directory.   <== This is somewhat awkward. I want to  bzr export  to a directory that already contains, among other things, a debian/ subdirectory...
<LeoNerd> Any useful workarounds?
<jam> LeoNerd: export to an empty dir and then mv debian on top of it?
<lifeless> moin
<jam> lifeless: /wave
<lifeless> wow the fb profile change is bold
<mgz> lifeless: if I want to have a prelim look at my testtools branch, would you prefer a merge proposal saying "not ready, just want this looked at", or... being told on IRC?
<lifeless> either
<mgz> +you
<lifeless> a merge proposal is harder to forget
<lifeless> and there are other testtools committers - its not even 'my' project
<mgz> I didn't jump on j lange about it at the sprint though, so you're a better bet for starts.
<lifeless> sure; just saying my slight lean it towards a mp
<mgz> will poke a bit more then submit.
<lifeless> ok, time to bring my computer system in from the car :)
<lifeless> got it picked up from the movers last night
<mgz> I am currently imagining you sitting in your car with a long power extension lead
<lifeless> lol
<lifeless> no
<lifeless> my monitor, home server, desktop workstation, wifi point, home gateway :- I hope.
<lifeless> and printer
<lifeless> I suspect they will have missed some bits and we'll get them in 3 months or so when we have bought a home
<jam> lifeless: I see you are now out of starter protection, shame I still have 15hrs on D.A.V.E. :)
<jam> care for a test of your defenses?
<lifeless> jam: I have 8 minutes till I need to pop into a car and go look at a house
<lifeless> so sure
<lifeless> I've signed out
<lifeless> jam: ^
<lifeless> ok
<lifeless> we're off, back in 3 hours more-or-less
<jbowtie> OK, I branch into a new repository. The branch is interrupted. Is the repository recoverable, or do I need to delete and re-branch?
<jelmer> jbowtie: the repository should be resumable
<jbowtie> jelmer: How do I resume? Try the branch operation again, or is there a flag I should be passing/
<jbowtie> ?
<jbowtie> jelmer: I'm asking because I have a flaky connection to a large repository and branch operations frequently lose the connection before they finish.
<beuno> jbowtie, I think you then start pulling in, instead of branching
<beuno> if you do it in a shared repo, then branching may still work
<beuno> maybe that's what you meant by "branching into a repostory"
<beuno> it should save the incomming revisions as they come
<beuno> and just ask the remaining ones on each branch/merge/pull
<jbowtie> beuno: Well, no, I mean the repository gets created as a result of the branch operation.
<beuno> right, so then you'd either have to pull
<beuno> or, use a shared repo
<beuno> at least AFAIK
<beuno> pulling may or may not work
<jbowtie> beuno: I'll give that a try. From memory it says there's no branch, just a repository.
<beuno> yeah, that sounds possible
<beuno> maybe jelmer knows other magic for that
<jbowtie> What happens is that a repository is created, populated with revisions, then a branch gets created in the repository, then a working copy is produced on disk.
<beuno> right
<jbowtie> It's the "populated with revisions" step that gets interrupted when the connection goes down.
<beuno> a shared repo is what you want
<beuno> re-branching will resume
<jbowtie> beuno: so if only 10 of 20 revisions have been populated, re-branching will pull down the other 10 revisions from the parent?
<beuno> correct
<jbowtie> beuno: All right, I'll give that a shot.
<jbowtie> beuno: Writing foreign VCS plugins is hard. :)
<beuno> jbowtie, jelmer wrote like 3 of them, we've all seen him suffer!
<beuno> he's also the guy to talk to if you need help
<beuno> he's super nice and super smart
<jbowtie> Don't worry, I'll pester him as soon as I have the green light from legal to publish the source for my plugin.
<jbowtie> Hard to get things right when you can't show people the source code yet.
<beuno> jbowtie, may I as what foreign VCS this is?
<jbowtie> Sure - I've been working on a Team Foundation Server plugin for the last few weeks.
<jbowtie> I've got read-only access pretty much rock solid and been working on round-tripping the last week or so.
<beuno> interesting
<beuno> what prompted you to work on it?
<jbowtie> I work for a company that mandates use of TFS. So I am doing an end run around the policy by writing a plugin so I can actually use Bazaar.
<beuno> heh
<beuno> smart man
<beuno> I see a lot of people doing that with SVN
<jbowtie> That's what prompted me to take that route. Spent a lot of time studying the bzr-svn and bzr-hg plugins.
<jbowtie> Problem I'm seeing though is that sometimes I "lose" revisions if a pull from TFS gets interrupted - they don't show up in a "bzr missing" and aren't re-pulled.
#bzr 2010-05-26
<jbowtie> So I have to assume that I'm not leaving the branch in a consistent state in my plugin, trying to understand what's resumable.
<beuno> ah, with bzrlib you surely can resume properly
<poolie> hi beuno, all
<beuno> if that's what your previous question was about
<beuno> I was referring to jsut using the cli
<beuno> hey hey poolie!
<jbowtie> Well, I need to understand what the cli is supposed to do so I can use that in my scenario and see what gets called.
<beuno> jbowtie, I'd suggest emailing the list about this
<beuno> or getting poolie's attention  ;)
<poolie> jbowtie, that'that sounds great
<poolie> jbowtie, so just at a guess you need to make sure the fetch finishes before updating the branch pointer
<poolie> ah, and perhaps check that you've released the write lock on the repository too
<poolie> which should serve to flush out pending state
<poolie> hth
<poolie> spiv, are you here?
<spiv> Good morning!
<poolie> hey there, isn't it impressively damp in sydney today
<jbowtie> poolie: Well, if an exception gets thrown that's what should be happening.
<jbowtie> poolie: I call target.unlock in the exception handler; I also wrap the creation of inventory and revision in a write_group and call abort_write_group if something goes wrong.
<jbowtie> poolie: So when I lose the connection in the middle of building a revision, I expect the repository is in a consistent state.
<jbowtie> poolie: But no branch is created since the repository hasn't finished populating yet.
<jbowtie> poolie: So I'm sitting there with a partially populated repository, no branch, no working copy.
<jbowtie> poolie: I'm just not sure how I'm supposed to resume from the command line, or if that's even possible.
<poolie> you should be able to just branch again into the same repository?
<beuno> poolie, but only if he has a shared repo
<jbowtie> poolie: I get an error about the directory already existing.
<beuno> not sure if --use-existing helps there or not
<poolie> ah ok, so the half-created branch is getting in the way?
<poolie> there's a bug open for this
<poolie> for now unfortunately you have to just delete it
<jbowtie> poolie: I expect so, yes.
<jbowtie> poolie: That's what I've been doing.
<jbowtie> poolie: I was just hoping there was a better way, TFS is so slooooooow.
<jbowtie> poolie: Branching 1000 revisions is an overnight job.
<jbowtie> Is there a way via bzrlib to get rid of the half-created branch and resume fetching the revisions into the repository?
<jbowtie> poolie: Do you know the bug number?
<beuno> jbowtie, from bzrlib, resuming should be easy-ish
<beuno> that said, I'm going afk to walk the dog and dinner with the inlaws  :)
<jbowtie> beuno: It's morning for me, so I'll still be here if you want to illuminate me later.
<Lor> Will anything break if I have a bzrdir that has neither repository, branch nor checkout?
<Lor> ah, bzr-colo does it already
<poolie> jbowtie, it's something like https://bugs.edge.launchpad.net/bzr/+bug/125067 or bug 116148
<ubot5> Launchpad bug 116148 in Bazaar "bzr branch should be resumable if interrupted (affected: 4, heat: 13)" [Wishlist,Confirmed] https://launchpad.net/bugs/116148
<ubot5> Launchpad bug 125067 in Bazaar "allow 'bzr checkout' to resume (affected: 1, heat: 14)" [Wishlist,Confirmed]
<lifeless> jam: had fun ?
<zerd> How do I enable colors in bzr diff's output?
<nDuff> zerd, consider bzr cdiff; you may need bzrtools installed
<zerd> ah. nice.
<zerd> Is it any way to automatically use a pager (less) to paginate long output?
 * nDuff doesn't know.
<spiv> There's a bzr-pager plugin, not sure how up to date it is.
<zerd> hmm.. cdiff didn't act nice with less
<nDuff> zerd, less -r
<lifeless> poolie: I propose we give mgz landing rights
<poolie> +1
 * igc lunch
<parthm> mgz: ping ... gz .. is that you. the irc denizen formerly known as a[0-9]+ :)
<jbowtie> Argh!  TFS says a label can't be more than 64 characters!
<jbowtie> That means I have no way to store a bzr-revid for roundtripping of commits.
<poolie> maybe you can stash it in a hidden file in the branch
<jbowtie> poolie: Sorry, I'm being dense, how would that work?
<poolie> jbowtie, is this pullying from tfs into bzr, or vice versa, or both?
<jbowtie> poolie: This was pushing a commit from bzr into tfs, then pulling back to bzr.
<jbowtie> poolie: TFS requires the admin to create metadata fields on a per-project basis, so there's no reliable place to store the revid.
<jbowtie> However, I have just worked out a clever solution - hide the revid at the bottom of the comment when I push to TFS, strip it off when I pull.
<jbowtie> A little uglier than I would like but it's pretty foolproof as far as round-tripping goes.
<jbowtie> I'll just need to create an actual foreign VCS mapping class (which I'd managed to avoid to date).
<vila> spiv: Don't land lp:~spiv/bzr/no-sigwinch-583941 into lp:bzr/2.1 yet, I'd like to discuss it first which requires a bit of investigation
<vila> hi all, oops, first things first
<spiv> vila: Sure
<spiv> vila: I imagine if it works in emacs then it's probably close enough ;)
<vila> spiv: that's the point, look at 4747.4.3
<spiv> vila: ah, and I see there's a test in test_osutils that that patch will trip up on.
<vila> spiv: haaaaa, I'm so glad about this :)
<vila> spiv: comment sent, basically COLUMNS *can* differ from _terminal_size and be right
<spiv> I was wondering where relevant tests were; I did run some blackbox tests as a smoke test.
<spiv> But running the full suite just takes too long for me now :(
<vila> apart from the emacs case, I think resizing a window so that a scrollbar appears may be another one
<vila> and then there is.... let me find that bash setting
<vila> checkwinsize
<vila> spiv: try to play a bit with 'checkwinsize' ... you'll live interesting times
<spiv> I'll do that.
<lifeless> spiv: I'd like to fix the test suite
<lifeless> but thats another story
<spiv> There is definitely something screwy about the code as it is in 2.1 today, though.
<spiv> lifeless: me too!
<vila> spiv: apart from the EINTR fallouts you mean ?
<spiv> Because the SIGWINCH handler will happily reset os.environ['COLUMNS']
<spiv> Using the value from _terminal_size
<vila> spiv: see comment, that's a shortcut
<vila> spiv: once you respect COLUMNS, you should continue :)
<vila> spiv: even by tricking yourself :)
<lifeless> holy cow
<lifeless> tripit is good
<lifeless> it combined two separate bookings into one trip
<lifeless> poolie: ^ :)
<spiv> vila: which comment?
<spiv> vila: the code + comments as they are at the moment don't make sense to me
<vila> spiv: I think I didn't realize that when I wrote the code but that desserve a comment in the code about it
<vila> spiv: I was referring to the mp comment
<vila> spiv: don't make sense doesn't mean incorrect :)
<vila> the root is that COLUMNS and _terminal_size can disagree, the rest follows from that
<spiv> vila: well, I changed the comment to match the change to the code, not because I disagreed :)
<vila> spiv: but you didn't change the docstring ! :-p
<spiv> Yes, but what precisely should happen when they disagree?
<spiv> vila: well, I'm not perfect :)
<vila> no worries, just kidding
<vila> spiv: good question, the actual answer was giving me a correct behavior in all configs I tried
<lifeless> so
<spiv> At the moment the policy *seems* to be "trust $COLUMNS until SIGWINCH happens (then trust _terminal_size)"
<lifeless> what happens if we just revert everything
<lifeless> what would break
<vila> spiv: yup
<spiv> Which doesn't seem to make much sense to me, because if we can trust _terminal_size after SIGWINCH, why not before?
<vila> spiv: because there are known cases where it's wrong, try 'checkwinsize'
<vila> spiv: that's what I try to explain in the mp comment
<spiv> (My sigwinch-without-signalmodule-583941 can preserve that behaviour without causing EINTR)
 * spiv looks at checkwinsize
<vila> spiv: ECONTEXT, why the new proposal then ?
<spiv> Because that proposal added a new C module
<vila> lifeless: I'm pretty sure we will end up with terminal_width defaulting to None instead of 80 before the patchES
<vila> i.e. blowing up buildbot with flog files full of spaces or something
<vila> hehe, yeah flog
<spiv> checkwinsize means bash promises that COLUMNS will be up-to-date when it invokes bzr, AIUI?
<vila> spiv: yes
<spiv> So _terminal_size would == $COLUMNS, then?
<vila> spiv: no
<vila> that's the point
<vila> COLUMNS can be set by the application controlling the terminal
<vila> think scrollbars, split (sp?) screens, etc
<spiv> Which is bash, if we're talking about checkwinsize
<vila> At the time I researched, COLUMN and _terminal_size could differ, bash's chekwinsize was just the easiest way I found to demonstrate it
<spiv> So here's what I don't understand.
<spiv> I think perhaps you are talking about emacs-running-bash-running-bzr?
<spiv> Or, actually, that doesn't matter.
<vila> no, doesn't matter, yes that's my *daily* env
<vila> spiv: http://www.ohse.de/uwe/software/resize.c.html for some background (but note that he doesn't respect COLUMNS knowingly)
<spiv> You're saying somehow there's a situation in which a) $COLUMNS is different to and more correct than _terminal_size, but also b) that after a SIGWINCH _terminal_size is better than COLUMNS
<vila> spiv: roughly yes,
<vila> after SIGWINCH, it's not "better" but... the best we have IMHO
<poolie> hi vila
<spiv> Because we know that the size must have changed, and _terminal_size is the only thing that indicates how?
<vila> poolie: hey !
<poolie> spiv i can't remember if i voted but i like the approach much better
<spiv> So, if that's the case:
<vila> spiv: ... did I make a such poor job to explain myself in that mp's comment or what ? :)
<spiv> a) we can do that without SIGWINCH; just ask for _terminal_size every time but prefer $COLUMNS until we observe a change in _terminal_size
<vila> spiv: sure
<vila> spiv: my point was to respect COLUMNS at the first try
<spiv> b) I'm skeptical that this tradeoff is working well in practice, because if _terminal_size is initially wrong due to the issues you mention then it will always be wrong.
<vila> spiv: on the performance front, remember that before handling SIGWINCH some parts of the code were caching a value, now we'll call ioctl() for *each* output line produced
<spiv> vila: _terminal_size takes 11 microseconds on my slowish laptop.
<vila> cool
<spiv> Can you give me a precise recipe to observe COLUMNS being more accurate than _terminal_size?
<vila> Ha, the tricky one :-/
<vila> not from memory but I can try to find it back
<vila> spiv: http://www.zsh.org/mla/workers/1999/msg01597.html seem to contain an analysis of various softwares behaviors
<vila> spiv: while not giving a recipe to reproduce, it demonstrate that in many cases people chose to respect COLUMNS first, then TIOCGWINSZ when the terminal is resized
<vila> spiv: hehe, see http://old.nabble.com/Unable-to-see-os.environ-%27COLUMNS%27--td19487200.html for additional fun :)
<vila> spiv: perl does it too: http://cpansearch.perl.org/src/AMBS/Lingua-Jspell-1.63/src/term.c (not sure if you will buy that though :)
<spiv> The only example situation that I see in those links so far is using a terminal over a crummy protocol that can't report window size changes (except by moving the cursor via ANSI sequences and then asking via another ANSI sequence where the terminal thinks it is).
<spiv> But you've had trouble yourself?
<vila> yes, emacs + bash + bzr
<vila> but the discussion about zsh is very close to the one we're having here
<spiv> The python-list link didn't tell me anything new, just that shells may or may not export $COLUMNS, and of course the shell can't reach into a subprocess to update its $COLUMNS after it starts.
<vila> spiv: forget that one, was just for fun about a non-exported variable, but yes once python is started there is no way to get back at the env variable, even if it's updated which is not always the case
<spiv> The zsh discussion was mainly about when to update and when to export the shell-internal COLUMNS/LINES values.
<vila> spiv: but mentions that COLUMNS should be respected at start
<vila> spiv: the fact that I can't find a recipe shouldn't invalidate the fact that many people refer implicitly to such recipes :)
<spiv> vila: the perl link has comment that doesn't match the code!
<vila> spiv: really ? It calls TICOCGWINSZ and *then* overrides with COLUMNS is set, what doesn't match ?
<vila> s/is set/if set/
<spiv> vila: the comment says the env variables override the *termcap* info, but the code actually overrides the termios (TIOCGWINSZ) values with env variables as well.
<spiv> So it's very unclear to me whether it does that by accident or on purpose.
<spiv> vila: so my concern at this point is that "use COLUMNS until WINCH happens" is sounding more and more like a superstition without solid evidence the more links I read!
<spiv> It's entirely possible there's a solid justification for it, but no-one seems to know what it is :)
<vila> spiv: and based on that you're going to consider that it's false ?
<spiv> Well, "lots of other people do it" is an argument for us doing it too.
<spiv> But it feel pretty nervous and unconvinced, which is why I'd like to be able to reproduce a scenario where I can see the difference.
<vila> apart from the emacs one I'm sure I encountered another one but I can't remember what was involved
 * StevenK grumbles. bzr add-pipe died with a NoneType has no attribute get_config
<spiv> StevenK: upgrade your bzr
<vila> some terminal emulator or even vim or less or...
<spiv> vila: tell me more about the emacs case.  This is emacs running in a terminal, not in its own GUI window?
<vila> own GUI window, shell as a subprocess
<spiv> Huh, so why isn't the TIOCGWINSZ going to be correct in a tty emacs created?  emacs bug?
<StevenK> spiv: But 2.1.2 isn't out yet? :-)
<vila> spiv: TIOCGWINSZ when WINCH is more correct because emacs can't change the bash env variable when the window is resized
<igc> hi vila
<spiv> vila: right, but TIOCGWINSZ should also be totally correct before WINCH too
<spiv> vila: i.e. in that situation it seems to me the best thing to do would be to ignore COLUMNS entirely
<vila> spiv: In fact, I can even find cases where both COLUMNS and TIOCGWINSZ are wrong (for the user: me) when python starts and changing the window size *after* that can only be accessed via TIOCGWINSZ
<spiv> vila: ooh, tell me more!
<vila> spiv: ok, I resign, I tried to explain that there are cases where COLUMNS *must* be respected, if you want to ignore that, just fo it
<vila> spiv: start emacs, start a shell, resize windows, echo $COLUMNS, python -c 'from bzrlib import osutils; print "COL: [%r]" % (osutils.terminal_width(),)' will both disaply the *old* value
<lifeless> StevenK: you're on the lp team now, add the bzr ppa :)
<vila> spiv: start bzr log, resize window, osutils.terminal_width() got the good value
<lifeless> StevenK: and no, not the releases one. The *other* one :P
<spiv> vila: ah, a recipe, thanks!  Time to dust of my memory of emacs...
<StevenK> lifeless: There's another one? :-)
<lifeless> nightlies
<spiv> vila: while I'm waiting for apt, what does python -c 'from bzrlib import osutils; print osutils._terminal_size(None, None)' report in that case?
 * vila use history since the command is already there :)
<StevenK> lifeless: Which team does that one hide under, since it isn't ~bzr?
<lifeless> statik, I think
<lifeless> hey, use the vaunted ppa search
<lifeless> or look on our downloads page ;)
<vila> spiv: the value set when the bash subprocess was started, and my recipe is wrong because SIGWINCH is not propagated anyway :(
<lifeless> wiki page I mean
<lifeless> vila: so perhaps its 'emacs is broken, gnar gnar gnar ?
<vila> spiv: no wait
<vila> lifeless: :)
<vila> grr, what was the application that was able to split the screen damnit, I didn't mention it out of thin air....
<spiv> screen?
<lifeless> terminator?
<vila> maybe, I used neither of them :(
<lifeless> or its new version, hate
<lifeless> Ng: ^ :P
<StevenK> lifeless: I find it odd that the nightly-ppa hasn't been updated in two months
<lifeless> haha
<lifeless> statik: ^
<lifeless> ok, I give, run trunk.
<lifeless> igc: would love it if you could start setting commit messages in your merge proposals
<igc> lifeless: ah - ok. Will do
<lifeless> also
<spiv> vila: so for me, in M-x shell, COLUMNS is 80 regardless of window size, and _terminal_size is 0,0 regardless of window size
<lifeless> when you send something to pqm please say so on the mp
<lifeless> so that I don't double submit :)
<lifeless> hydrazine will do this for you
<igc> ok
<spiv> vila: so it seems to me that an equally good policy for you would be "try BZR_COLUMNS, then TIOCGWINSZ then COLUMNS, until you find one that is not missing and not zero.  If all else fails, guess 80."
<lifeless> igc: the result of automation: - http://pqm.bazaar-vcs.org/
<igc> lifeless: nice
<vila> spiv: this is equally superstitious about TIOCGWINSZ returning wrong values and COLUMNS being right in that case
<spiv> vila: (to be more precise, COLUMNS is accurate when emacs starts the M-x shell, and the termios size is never set)
<vila> spiv: and where is the recipe for termios size never set ? :-P
<spiv> vila: I don't think it's particularly superstitious.
<vila> spiv: then go for it, both solutions need to be tested in the field, I wasn't entirely clear with my solution, I don't think yours is worse or better, just different, the interweb doesn't seem to agree on either one anyway and BZR_COLUMNS is there to address obscure cases
<spiv> The logic is simply: BZR_COLUMNS first, because it's an explicit user-knows-best override.  Then ask the OS directly if it thinks it knows the terminal size (and if the terminal creator is good enough, it will be correct -- I don't know of any reason why emacs couldn't issue TIOCSWINSZ to set the size), because the OS ought to know best and can update it for window resizes.
<spiv> Then fallback to COLUMNS, which if set is likely to be better than nothing, then fallback to 80 as the default everyone expects.
<vila> spiv: yeah, I did that *first* and then I switched
<vila> but don't force 80 either, some callers expect None for no defined width
<spiv> Ah, sure.
<spiv> Why did you switch?
<vila> shudder
 * igc dinner
<vila> because I encountered a case where it was needed, found some evidence for it reading the web and...
<vila> fail to note the recipe (I should have known better :)
<spiv> :)
<spiv> Perhaps we should just let users with broken terminals write a plugin to override osutils.terminal_width as they need :P
<vila> now, did I reproduce it or was I so convinced by some explanation that I didn't reproduce it in fact ?
<vila> spiv: That's why I added BZR_COLUMNS: this terminal size stuff is messy, let's punt
<vila> :)
<spiv> vila: you should have made it be a python expression, for maximum flexibility ;)
<vila> spiv: see, you use emacs for a minute and already you're starting to put hooks everywhere :-)
<spiv> vila: don't worry, my evil overload laugh was well-honed already ;)
<vila> spiv: bzr selftest -v | less :-(
<vila> spiv: whatever, the lesson for me is once again: 'untested code is broken code', change that failing test to match your implementation, unless bugs are filed for specific cases I don't see how to address all possible cases without recipes :)
<bialix> ~~~~
<joh> Hi, I get two strange messages when comitting to my branch: Unrecognized interpretation: SOURCE_CODE, Unrecognized manifestation: FILE_DATA_OBJECT
<joh> What do they mean?
<lifeless> could use a second reviewer on https://code.launchpad.net/~parthm/bzr/584650-incorrect-alias-info-in-help/+merge/26018
<lifeless> poolie: ^ if you're around, its trivial
<poolie> ok maybe very quickly
<poolie> then i need to go
<poolie> bzrlib.help.help the comedian's a bear!
<poolie> done
<poolie> thanks lotzman
<poolie> and good night
<speakman> gmorning!
<speakman> Is there any way to "rewrite" some old commit messages (due to character encoding change)?
<bialix> only if you're ok to the fact all your history after that commit will be rewritten too.
<bialix> GaryvdM: ping
<speakman> how come I can't modify the author name and/or message of a single commit?
<mgz> oh man, lots of exciting log to read this morning
<mgz> there appears to be a good hour's worth just on signals and terminal size detection, now that is my idea of a good time.
<mgz> the sad thing is... I should be being sarcastic, but am not.
<spiv> vila: yeah, "bzr ... | less" or even just "| cat" is basically doomed as far as I can tell
<spiv> vila: at least in my environment, in that situation COLUMNS is not set and _ioctl_terminal_size returns None,None
<bialix> speakman: because DVCS insist on the immutability of the history
<vila> COLUMNS is specific to some setups, that was my big problem with it, so no need to  mention it if it's not set :) The problematic cases are when it *is* set :)
<speakman> bialix: Yes I know, but in this case it doesn't matter.
<spiv> (At least if the other end of the pipe is less then arbitrarily long lines don't matter much, unless we want to right-justify text at some point.)
<bialix> speakman: if you change past commit, all commits after it should be changed too (at least their revids)
<spiv> vila: right.  So I'm thinking I'll make two patches:
<speakman> bialix: is the revid connected to the author/commit message?
<vila> spiv: I think the consensus for that was that bzr use None when the output is not a terminal, BZR_COLUMNS can rescue specific cases here
<bialix> speakman: then I'd say you can branch that commit, uncommit, commit again with correct data. then replay all other commits on top of it
<mgz> ack! if y'all keep talking, I'll never catch up
<bialix> revid is revision id. it's unique
<spiv> 1) for 2.1, a minimal patch that removes SIGWINCH by tries to preserve the existing behaviour (initially use COLUMNS then use termios width once we observe a change), including the rather odd part where os.environ['COLUMNS'] is mutated
<bialix> yes, revid based on the author, commit message and all previous history
<speakman> bialix: I can't possibly retain revid when changing message/committer?
<vila> 1) adding the comment I forgot about why COLUMNS is mutated this way, yes, sounds good, minimal risk for 2.1
<spiv> 2) for trunk, a patch to use the implementation I outlined earlier, and see how that works out for people.  I'll try to include an explicit list of relevant cases, e.g. M-x shell, and "bzr | less".
<bialix> speakman: you should not
<spiv> vila: Well, I can't add that comment, because I still don't know why it is mutated
<vila> spiv: yup, behavior change for 2.2 , sounds good too
<vila> spiv: because it masks the ioctl call()
<spiv> vila: I mean, I know it is one way to get the "initially COLUMNS until WINCH" behaviour, but at the cost of mutating global state as a side-effect, state that subprocesses inherit!
<vila> spiv: good, we want subprocesses to inherit the most current value :-)
<spiv> Oh, so that part was intentional?  Ok, that was totally unclear to me :)
<spiv> I'm... unsure that it's a good idea, especially how we set it even if it wasn't set, but ok.  I'm not too worried about subprocesses :)
<vila> since it
<vila> meh
<spiv> After all, if this discussion has taught me anything, it's that random programs might do all sorts of things to determine the terminal size! :)
<vila> since it's taken into account once set, WINCH blindly set it with the up-to-date value so that all subsequent callers get it, but the WINCH handler doesn't *respect* it of course
<spiv> (To be clear, I'm not sure that it is a bad idea to set either)
<spiv> Nothing in bzrlib/ looks at COLUMNS other than osutils
<vila> spiv: good, that was my experience too when I worked on it (and boy did I not anticipate the can of worms it will open with other signals... I had enough with the term size...)
<vila> spiv: well, at least we got that right: a single place where term size is determined :)
<spiv> Yeah, that was a great relief to see :)
<vila> but as the discussion with bialix at UDS revealed, the definition of what we do with that is still a bit unclear
<vila> I don't remember if there are still places where we subtract one from that value for terms that include '\n' in that count
<vila> spiv: but you're free to ignore this bit for your current submission :-O
<vila> spiv: bzrlib.status.show_pending_merge() for one  :-/
<bialix> vila: what?
<vila> bialix: is terminal_width() the number of characters that could be displayed or should we subtract 1 because some terminals (including... the one you use on windows) requires it
<bialix> yep
<vila> bah, looking at the code it seems we *always* subtract 1, the progress bar stuff is a bit less clear about that so I'm only 50% sure there, but in all other cases it seems to be done unconditionally
<bialix> vila: you broke this in selftest :-P
<spiv> vila: ugh, yes, I fully intend to ignore that :P
<spiv> vila: thanks for your patience
 * spiv -> dinner
 * bialix -> lunch
<spiv> (Someone should have breakfast to complete the set... any takers?)
<jelmer> I've just had breakfast
<vila> here we are...
<jelmer> well, s/just/one-and-a-half-hours ago
<vila> too late, now we know
<jelmer> :-)
<vila> spiv: you're welcome, I should have discussed this when I was working on it...
<mgz> okay, caught up. think I understand all of that.
<vila> but, well, it sounds so inocuous :)
<lifeless> mgz: not sure we do :P
<vila> mgz: Do you have recipes ? :-P
<mgz> how about this as a simple way for handling the case where the terminal size the kernel returns is not what the terminal emulator actually uses in the window:
<mgz> if COLUMNS is valid, and kernel width is valid, but they differ, use COLUMNS
<mgz> (keeping BZR_COLUMNS overriding both of those, of course)
<mgz> given the huge number of different setup possibilities, never going to get this right for everything
<thumper> bzr backed wiki: 0.1 now out the door: http://how-bazaar.blogspot.com/2010/05/wikkid-wiki.html
<vila> mgz: So, the problem is two-fold (at least): 1) COLUMNS being an env variable it doesn't play well with subprocesses, 2) Whether COLUMNS is more or less right than the kernel is unclear (and when)
<mgz> well, it clearly depends on the application, of which there are many :)
<bialix> thumper: \o/
<vila> thumper: nice !
 * thumper puts down laptop for the night
<vila> mgz: the case at point is to find a recipe where COLUMNS and ioctl(1, termios.TIOCGWINSZ...) disagree and see which is right
<lifeless> gnight
<mgz> night!
<vila> mgz: I swear I encountered one in the past but couldn't find it back, so the bets are open :)
<vila> lifeless: gnight
<bialix> why switch between qbzr trunk and qbzr 0.18 produce conflicts??? there is no uncommitted changes
<bialix> this operation should not merge
<bialix> why??? grrr
<mgz> well, you and spiv covered pretty much all the possible options in that discussion
<bialix> is it worth a bug report?
<lifeless> bialix: dir with unversioned contents?
<lifeless> I think there is a bug already
<lifeless> and a workaround
<lifeless> bzr resolve --take-other or something
<bialix> no, conflict in the versioned file
<lifeless> ah, please file a bug for that then
 * lifeless really goes
<mgz> (re)finding real world cases seems reasonable
<mgz> all this makes the windows terminal start to look sane, you know.
<vila> bialix: ^ :-P
<bialix> :-P
<mgz> you know what I haven't made you worry about yet: knowing how wide what you're actually printing is
<mgz> because an 80 codepoint string sure isn't always 80 spaces wide :D
<vila> mgz: :)
<vila> mgz: let's get the signal mess out of the way first :)
<mgz> :D
<mgz> I think bzr largely avoids the issue, no critical word wrapping code
<mwhudson> ah, terminal hacking
 * mwhudson remembers that
<vila> mgz: we thought about reusing the nice TeX implementation but the dependency was considered too much :)
<mgz> hey parth, thanks for looking over my filelifetimes branch
<mgz> (and yes, to your query from earlier)
<vila> mgz: I read the mail so I didn't have the context, what is this ',,bogus-inv' thing ?
<mgz> will you be sad if I say "notaclue"?
<vila> yeah, terribly :-(
<vila> ;)
<vila> I suspect we never realize the consequences since it has never conflicted in real like...
<mgz> I just use a file tracking script to detect file objects that didn't get closed, and then added a bunch of close calls :)
<mgz> in a couple of places I actually considered the surrounding context, but not many
<mgz> (you may well be right that just using a tempfile there would make more sense... but it'd still need closing!
<mgz> )
<vila> certainly
<mgz> parthm: that also answers your query about why I added comments saying "should use try/finally" rather than just doing it
<mgz> reindenting a twenty lines of code I didn't really understand seemed a bad idea to address a problem no one using cpython encounters
<parthm> mgz: makes sense :)
<sili> is it possible to show the logs of a branch since it was branched?
<vila> sili: 'bzr missing --mine-only ' ?
<sili> aha. I think that will work. Thanks vila
<Leonidas> is there any roadmap on when 2.1.2 will be released?
<awilkins> Is there a loggerhead of the bzr trunk?
<jelmer> awilkins: yeah, lp:~bzr-pqm/bzr/bzr.dev
<awilkins> jelmer, Thanks
<Phoenixz> I have two projects that share a large part (some 90%) of the same code base.. When adding functions / fixes to project 1 I want to share those with project two, but there are various directories from which I do not want to share changes.. How do I do this?
<Phoenixz> share changes as in, when I merge / push to other repos, I want those directories filtered..
<rsvp> for some reason ".bzrignore" does not seem be excluding intended files -- where does it have to be placed? -- what are some gotchas???
<jelmer> rsvp: it has to be in the root of the tree
<jelmer> rsvp: what sort of files is it not ignoring and when?
<rsvp> I think I found the gotcha: "The ignore pattern only applies to non-added (ie unknown) files.  Once a file is added, it remains versioned regardless of whether it matches an ignore pattern or not." -- can we can confirmation of this, please? -- it's not mentioned in the manual by the way.
<rsvp> if so, how does one remove versioning but NOT the file itself ???
<jelmer> rsvp: yes, that's correct
<jelmer> rsvp: iirc "bzr remove --keep NAME"
<rsvp> what's iirc
<rsvp> ?
<jelmer> if I remember correctly
<rsvp> ah, OK... thanks very much, jelmer
<rsvp> it appears that the correct syntax is "bzr rm --keep NAME" -- per https://answers.launchpad.net/bzr/+question/28805 which uncovers our mystery.
<jelmer> rsvp: that's what I said :-)
<rsvp> jelmer, is rm bzr's shorthand for remove?
<jelmer> rsvp: yep
<rsvp> ok, superb, thanks again.
<rsvp> using "bzr ignored" to verify which files will be ignored -- this has indeed confirmed our discussion.
<C-S> I have the following error with 'bzr qlog': bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'style'
<C-S> any ideas?
<C-S> traceback is: Traceback (most recent call last):
<C-S>   File "/usr/local/lib/python2.6/site-packages/bzrlib/plugins/qbzr/lib/revtreeview.py", line 193, in paint
<C-S>     style = widget.style()
<C-S> AttributeError: 'NoneType' object has no attribute 'style'
<luks> I think that was fixed in new version sof qbzr
<C-S> which version do you mean?
<C-S> I use the newest published version of qbzr
<luks> maybe I was wrong
<C-S> maybe it is not published yet.
<luks> which version do you have?
<luks> according to the changelog, it was fixed in 0.18.5
<luks> https://bugs.launchpad.net/qbzr/+bug/544928
<ubot5> Launchpad bug 544928 in QBzr 0.18 "qlog fails with a special combination of PyQt4 and Qt (affected: 19, heat: 0)" [Critical,Fix released]
<C-S> bzr version 2.1.1 and I am working on 0.19 qbzr
<C-S> that is weird indeed
<C-S> actually I have 019~b1
<C-S> and still get this error?
<luks> seems 0.18.5 was released after 0.19beta
<luks> so the fix is probably not there
<C-S> ah. maybe
<C-S> let me check
<C-S> you seem to be right.
<C-S> luks: thank you very very much. it works now :-)
<luks> no problem :)
<rsvp> the command "bzr remove --keep" at first sight is ambiguous, and users may hestitate for the fear of losing their files; would recommend creating "bzr unversion" instead.  Your thoughts ??
<poolie> rsvp, that would be a reasonable name for it
<poolie> however remember that when this change is merged somewhere else, it actually will cause deletions
<rsvp> poolie, deletion of the versions, or the actual files themselves?
<poolie> the files themselves
<poolie> we don't record "was unversioned" vs "was deleted"
<rsvp> that might be a problem then...
<rsvp> but then why the distinction from this another option: "bzr remove --force" ; so once again the means and the end results are not crystal clear to the user.
<maxb> What is unclear?
<maxb> I think "bzr unversion" would be unwise, because it implies there is more difference in the operation that there actually is
<itistoday> how do I byte-compile the files in a plugin folder?
<rsvp> I think what the typical user will want is to stop versions of a certain file, yet to have it remain on disk, without manually editing .bzrignore
<rsvp> so "bzr unversion" will do just that, including adding an entry to .bzrignore automatically -- just a suggestion.
<itistoday> i.e., I've done this: bzr get http://people.samba.org/bzr/jelmer/bzr-rewrite/trunk ~/.bazaar/plugins/rewrite
<itistoday> normally when you run setup.py install it byte-compiles the stuff in there
<itistoday> but it installs it into the system location
<itistoday> i'd like to leave it there in my user folder, but byte-compile the files
<poolie> itistoday, if you can write to the directory it will be automatically bytecompiled when you first use it
<itistoday> poolie: ah neat, didn't know that
<itistoday> thanks!
<rsvp> so I just created two aliases in my bazaar.conf : "unversion = remove --keep" and "destroy = remove --force"
<poolie> ok
<rsvp> functionally more clear, no?
<bamarob> Greetings...  is this the place for a newbie to get some help?
<poolie> sure
<bamarob> Actually, as I posted that, I continued to read through https://answers.launchpad.net/bzr and *may* have found some answers...  If not, I'll be back... :)  Thanks.
<awmcclain> Hi friendly bzr'ers. I've been updating bzr via easy_install for years and I just downloaded the DMG to get explorer... and now I'm getting a bzrlib version doesn't match error -- even though the bzrlib.__version__ matches the bzr version (2.1.0)
<poolie> awmcclain, i'd guess you have an old bzr or bzrlib hanging around somewhere
<lifeless> mkanat: hi
<mkanat> Hey lifeless.
<mkanat> lifeless: Did you find out if the pygments fix and the latest hang fix had actually been deployed?
<lifeless> I found out how to find out
<lifeless> and found out
<lifeless> the way to find out is to look at lp:~launchpad-pqm/loggerhead/devel
<mkanat> lifeless: Ahh, okay. :-)
<lifeless> that branch is rolled out in cron
<lifeless> at a 24 hour frequency
<lifeless> it contains the pygments size cap
<lifeless> so 'yes' to the pygments thing being rolled out
<lifeless> did we file a bug on pygments about its 'most excellent scaling characteristics' ?  :)
<mkanat> lifeless: Hahaha. No, I don't think I did.
<lifeless> I think we should
<mkanat> lifeless: Yeah, agreed.
<mkanat> Okay, and the rolled-out branch also contains the lru fix.
<lifeless> for two reasons - the open source quid pro quo of feedback, and also so that when its fixed we can remove the size limit
<mkanat> lifeless: BTW, I can't access that pastebin that's linked in the bug description.
<lifeless> I can, let me grab it
<mkanat> lifeless: I don't know that it will be resolved--the problem is that pygments is slow. "Make pygments fast" would be the solution. Perhaps via pyrex or something.
<lifeless> right
<lifeless> I understood it to be nonlinear though
<mkanat> lifeless: I'll go find their bug tracker.
<mkanat> lifeless: No, it's linear. It's just really bad.
<lifeless> ok
<mkanat> Oh lovely, they use Trac.
<lifeless> no wonder they are patient on performance
<mkanat> Hahaha.
<lifeless> pasted to you
<lifeless> it wasn't very large
<mkanat> lifeless: Cool, thanks.
<lifeless> so we have an internal process gap
<mkanat> lifeless: Okay, so that looks like a similar problem to the pygments problem. I'm guessing Locations.xml.in is a large file.
<lifeless> pull the branch, should be easy to check :)
<mkanat> lifeless: Yeah, I will.
<mkanat> lifeless: I'll do some testing, see what takes so long.
<Phoenixz> How can I merge 2 branches but filter certain directories?  I have two projects that share a large part (some 90%) of the same code base.. When adding functions / fixes to project 1 I want to share those with project two, but there are various directories from which I do not want to share changes.. How do I do this?
<lifeless> Phoenixz: sounds like you have three project
<lifeless> mkanat: anyhow
<Phoenixz> lifeless: three projects?
<lifeless> mkanat: all the hangs we're seeing - peaking at 1/hour - were getting internally logged on the pygments bug, in may
<lifeless> Phoenixz: common code, proj 1, proj 2
<Phoenixz> well, I have multiple projects, yes, but for the ease of it, I limited it to two..
<Phoenixz> lifeless: pretty much that yeah, common, prj 1, prj2, prjn...
<lifeless> mkanat: I'm learning about how they get assigned and so on now, so that we can try to get better communication to you
<Phoenixz> lifeless: so how could I merge in between these projects but filtering out a few directories so that I will not have those changes intermix?
<lifeless> Phoenixz: the easiest way is not to filter stuff out
<lifeless> but to have the common code as a source project
<lifeless> that you merge - completely - into both proj1 and proj2
<mkanat> lifeless: Okay, awesome.
<mkanat> lifeless: Only hangs after May 10 are significant, though, because that's when the system was updated.
<lifeless> you're sure ? Looked like the merge was 24th april to me
<lifeless> http://bazaar.launchpad.net/~launchpad-pqm/loggerhead/devel/revision/175
<mkanat> lifeless: https://bazaar.launchpad.net/~launchpad-pqm/loggerhead/devel/changes
<mkanat> lifeless: It's revision 177 that matters.
<lifeless> ah, for both the pygments fix and the hang bug
<mkanat> Yeah.
<Phoenixz> lifeless: meaning, I should make framework edits ONLY in the codebase, not in prj1, prj2, etc so that I never have to merge back, right?
<lifeless> Phoenixz: yes
<lifeless> mkanat: right, I see
<Phoenixz> lifeless: problem is.. on various occasions its much easier to make those changes directly in the projects.. Like, I find a bug in the codebase while working on prj1, I fix it there, test it, its okay, etc.. then merge back to codebase...
<lifeless> Phoenixz: so, make it where you want to; shelve the other changes, bzr switch to the framework, commit, bzr switch back, merge from the framework and you have your fix ready
<Phoenixz> Having to make changes only in codebase... would make it hard to test.. find bug in codebase while working on prj1, fix in codebase, commit, push, merge, pull into prj1, test, shit, forgot detail X, do it all again..
<lifeless> well you're going to need tests for the framework anyway
<mkanat> lifeless: You actually have stats that say that the machine starts to swap during that hang and other similar hangs?
<lifeless> spm: are you perhaps up, in ye place of monsoon ?
<Phoenixz> lifeless: shelve.. seen that option, haven't used it yet.. Gotta do some reading on it first then..
<Phoenixz> shelve is like.. temporarily storing the changes you currently have so that you can work on somehting else, commit that, and return to the changes you had before?
<lifeless> yes
<Phoenixz> sweet
<Phoenixz> BZR rocks.. :P
<jpds> It sure does!
<Phoenixz> lifeless: anyway.. still there are some problems.. So I find a bug, I shelve, switch, fix... But there are functions that only really show when used in projects..
<Phoenixz> lifeless: I don't suppose its possible to filter directories on merges?
<lifeless> it is, but with various sideeffects you may not like
<Phoenixz> lifeless: like?
<lifeless> depending on how you do it - including only some, or excluding ones you don't like after the merge.
<Phoenixz> Nobody likes sideeffects, but sometimes it may be worth it..
<lifeless> If you include only some, there's no record of whats merged, and you'll have unneeded conflicts.
<lifeless> if you exclude ones you didn't want after the merge, you'll have both proj1 and proj2 in your history.
<lifeless> bzr, just like git and hg, is a *full tree* vcs, so it records things in terms of trees, not individual files.
<Phoenixz> lifeless: basically, I have separated directories for programs, libraries, configuration, etc.. all I want is to merge the library directories..
<lifeless> sure
<Phoenixz> lifeless: so what would options be?
<lifeless> I've outlined them all now
<lifeless> my recommended one is to have a dedicated libraries project.
<Phoenixz> ah, sorry, thought there was another one
<gdoubleu> I've got a branch of a svn repo (let's call it trunk), and then a feature branch from that.  Now, I want to get my changes from the feature branch into the svn repo, while preserving the individual commits.
<gdoubleu> As I understand things, a push to trunk is needed (instead of merge) so that the individual changes are reflected instead of one large merge commit
<gdoubleu> Problem is, what if my feature branch has been long-running and I've already done a few merges from trunk along the way?
<lifeless> gdoubleu: dpush is what you want, AIUI
<gdoubleu> dpush directly from the feature branch?
<Phoenixz> lifeless: shelve does not store changes in between a switch, I suppose?
<lifeless> Phoenixz: the changes are stored in the tree, so yes it does store them
<gdoubleu> I've normally merged completed features back to trunk and then dpush from there.  In that case only one commit gets pushed to the svn repo, the merge commit.
<gdoubleu> In this case I would like to push all of the individual commits and not just the merge commit.
<lifeless> sure
<lifeless> my understanding is that dpush is the tool for that
<Phoenixz> lifeless: because then I could make the changes in project1, test them, if all is ok, shelve, switch, unshelve, commit.. no?
<gdoubleu> lifeless, trying to dpush from the feature branch straight to the svn repo complains that it would change mainline history
<gdoubleu> I'm assuming this is because along the way in my feature branch, I've merged in updates from trunk
<gdoubleu> Any ideas as to how I could clean those merge commits out of the feature branch so it's clean and doesn't change mainline history when trying to push back to the svn repo?
<lifeless> mkanat: so on the 20th it was using too much swap and the losas restarted it
<mkanat> lifeless: Okay. And it was also using a lot of threads at that time?
<mkanat> lifeless: I want to make sure that there's not just one runaway thread using a ton of memory.
<lifeless> can't tell
<lifeless> there isn't a dump attached, its just a simple text log file
<lifeless> saying date, fault description, qa info
<mkanat> lifeless: Okay. Are there still logs around from that time?
<mkanat> lifeless: mwhudson or spm should be able to get them.
<lifeless> mwhudson: ^
<lifeless> 2010-05-20 12:10 UTC
<mkanat> lifeless: I have a crazy codebrowse log analyzer that I can use to see what was going on.
<mwhudson> mkanat: could that be adapted to something that could grab logs for a particular time range?
<mwhudson> it's a horribly manual process for me at the moment
<mkanat> mwhudson: I don't know--I don't know how the logs are stored, or what you do to grab them.
<mkanat> mwhudson: If you just want to send me the whole log, I can break it down.
<mkanat> lifeless: Okay, yes, Locations.xml.in is 1.5MB.
<lifeless> mwhudson: are there docs on getting the logs at the moment, or is it black magic?
<mwhudson> lifeless: it's not exactly black magic, it's just grotty
<mwhudson> and no docs
<mkanat> lifeless: Okay, also, loading that file causes a TREMENDOUS MEMORY LEAK.
<mkanat> We leak almost 100MB every time that file is loaded.
<lifeless> \o/
<lifeless> poolie: ^ see what I mean
<poolie> yay max
<mkanat> Hahaha, thanks poolie. :-)
<mkanat> Maybe it's time to learn how to use meliae. :-)
<lifeless> its pretty nice
<poolie> jam, hi?
<poolie> mkanat, i filed a bug asking that we should dump memory usage when we get eg SIGUSR1
<poolie> you might like to implement that ;-)
<poolie> oh and there's another asking for a memory dump when we run out of memory
<mkanat> poolie: :-D
<poolie> if we had the latter and we put a ulimit on loggerhead, we'd potentially get useful data semi automaticalyl
<lifeless> poolie: that latter one wouldn't help loggerhead so much ... machine has lots of swap configured
<mwhudson> mkanat: http://people.canonical.com/~mwh/debug.log.2-sub.gz <- logs from around 2010-05-20 12:10 UTC
<lifeless> ah yes
<lifeless> ulimit ftw
<mkanat> mwhudson: Thank you! :-)
<mkanat> poolie: Well, lemme figure out meliae, first. :-)
<poolie> lifeless, in other words "a credit card limit is not a challenge"
<poolie> we can spend less :)
<lifeless> what, sensible home accounts? nooo
<mkanat> Is there any actual documentation on how to use meliae?
<lifeless> yes
<lifeless> http://jam-bazaar.blogspot.com/2009/11/memory-debugging-with-meliae.html
<mkanat> lifeless: Thanks.
<lifeless> jam: ow, zing
<mkanat> jam: python: Objects/typeobject.c:2672: type_traverse: Assertion `type->tp_flags & (1L<<9)' failed.
<mkanat> Aborted (core dumped)
<lifeless> rotfl
<lifeless> its never easy
<mkanat> jam: I got that using meliae on loggerhead.
<mkanat> I'll try meliae trunk.
<mkanat> Yeah, same assertion and core dump.
<mkanat> I'll file a bug with the core attached, if it's not too huge.
<lifeless> does loggerhead have custom types in use
<lifeless> special ones I mean, not the bzr stock ones
<mkanat> lifeless: Not sure.
<mwhudson> no c ones
<mwhudson> i guess maybe it's something from sqlite?
<lifeless> it has the ctype stuff for killing threads
<mkanat> I'm still trying to get enough debuginfo packages installed to get a reasonable backtrace from the core.
<mwhudson> mkanat: use this: https://code.edge.launchpad.net/~pygdb-hackers/pygdb/trunk
<lifeless> if you're on ubuntu, apport-retrace can grab them for you, I think.
<mkanat> lifeless: I'm on Fedora.
<lifeless> oh, sorry :)
<mkanat> lifeless: Hahaha. :-)
<mkanat> mwhudson: Awesome, thank you.
<mwhudson> mkanat: are you on 64 bit?
#bzr 2010-05-27
<mkanat> mwhudson: I am.
<mwhudson> good
<mkanat> mwhudson: pygdb gives me a backtrace.
<mwhudson> mkanat: that's what it's supposed to do but i guess you mean the other kind :-)
<mkanat> mwhudson: Hahaha, yeah. :-)
<mkanat> mwhudson: http://pastie.org/979056
<mwhudson> mkanat: huh bizarre
<mwhudson> mkanat: what version of python are you using?
<mkanat> mwhudson: 2.6.2
<mwhudson> i've only used it with 2.5, i think
<mkanat> mwhudson: Might be related to g.file('/usr/bin/python2.5')
<mwhudson> mkanat: :)
<mkanat> Nope, that doesn't fix it.
<mwhudson> oh darn
<mwhudson> mkanat: well, i guess you could poke around in gdb manually
<mwhudson> i.e. gdb python2.6 $core
<mwhudson> up a few times, see what
<mwhudson> p co->co_file_name
<mwhudson> says
<mkanat> (gdb) p co->co_file_name
<mkanat> No symbol "co" in current context.
<mkanat> Okay, I at least have a reasonable gdb backtrace now.
<mwhudson> type up until you're in PyEval_EvalCodeEx
<mwhudson> or whatever
<spiv> Good morning.
<mkanat> mwhudson: Okay, will do. One sec.
<mkanat> mwhudson:
<mkanat> (gdb) p co->co_file_name
<mkanat> There is no member named co_file_name.
<mkanat> (gdb) p co
<mkanat> $1 = <value optimized out>
<mwhudson> mkanat: co_filename sorry
<mkanat> (gdb) p co->co_filename
<mkanat> Cannot access memory at address 0x50
<mwhudson> mkanat: bing!
<mwhudson> mkanat: maybe you need to be using a less aggressively optimized python interpreter?
<mkanat> mwhudson: It's the gcc options for compiling python itself, you think?
<mwhudson> mkanat: would be my guess, don't really know though
<mkanat> mwhudson: It looks like the meliae problem is all in C anyhow, though.
<mwhudson> mkanat: ok
<lifeless> jam: poolie: spiv: this is the sort of thing I think we should also be looking at - https://bugs.launchpad.net/bugs/586139
<ubot5> Launchpad bug 586139 in Ubuntu Distributed Development "bzr branches for ubuntu packages are not reliably updated (ex. aria2) (affected: 1, heat: 6)" [Undecided,New]
<Chipaca> hiya
<Chipaca> is there a way to tell bzr to not check a certificate? I'm suspecting the answer is "no", which means I'm stuck using svn directly :(
 * Chipaca has gotten too used to the bzr goodness
<spiv> Chipaca: an HTTP certificate?
<spiv> Er, HTTPS, I mean, of course :)
<poolie> Chipaca, it rings a bell but maybe there's just still a bug open for it
<spiv> If you uninstall pycurl I think bzr won't check
<spiv> (because it will use urllib, which doesn't have that facility)
<poolie> spiv presumably the actual https is done inside libsvn
<mwhudson> Chipaca: what are you trying to do and what problems are you having?
<spiv> Ah, I was assuming that if "using svn directly" worked then libsvn doesn't check, but maybe it's that it can check but the svn command has config that can turn that off?
<lifeless> the cli prompts
<lifeless> and you can ok it
<lifeless> igc: ping
<Chipaca> right, it says "dude, this cert is, like, way off!" and you say "yeah, whatev"
<lifeless> spiv: ping
<lifeless> spiv: https://code.edge.launchpad.net/~amanica/bzr/find_bzrdirs-ignore-PermissionDenied-dirs/+merge/24979 has conflicts; is newsmerge able to use branch.conf settings? if so, do you want to request a losa change to set it up for pqm, or do you want me to do that?
<lifeless> s/pqm/launchpad
<poolie> lifeless, thanks for all the landings
<poolie> did i tell you about my wish for xbox-style achievements in launchpad
<poolie> "land 20 branches with no rejections"
<lifeless> lol
<lifeless> have you seen unittest achievements?
<poolie> nose achievemnts
<poolie> yeah
<poolie> this would be a bit less artificial i think
<lifeless> pop quiz
<lifeless> you've seen aarons change to bzr to cleanup the ui on exit
<lifeless> yes?
<poolie> yes
<lifeless> would you prefer a cleanup global function
<lifeless> or initialise() to return a cleanup function to be called
<poolie> heh
<lifeless> the latter is what I've suggested, and seems to me to be a step towards less globals
<poolie> that's a reasonable idea
<poolie> lifeless, is pqm working properly?
<poolie> it seems suspiciously fast today
<poolie> unless they upgraded the hardware and didn't tell me?
<poolie> specifically my last commit succeded in 3 minutes elapsed
<lifeless> that would be surprising
<lifeless> I haven't changed anything
<lifeless> poolie: it is running suspiciously quickly
<lifeless> last change to Makefile was 6th april
<lifeless> losa ping - has anything been changed on balleny vis-a-vis bzr-pqm.conf or related stuff in the last couple of days ?
<MWinther> I thought bzr mv --after fromfile tofile would update the repo pointers correctly, even though I stupidly went ahead and moved stuff around... Anyone got a better suggestion? It tells me the new file is already versioned.
<lifeless> spiv: ping
<lifeless> MWinther: you've probably already added tofile
<lifeless> MWinther: so check bzr st and make sure tofile shows as added; if so then 'bzr revert tofile' and then 'bzr move --after fromfile tofile'
<MWinther> and that will not change the tofile, but just remove it and then add it again, but as the right file, so to speak?
<lifeless> yes, revert of an added file just unadds it
<lifeless> but check status first
<MWinther> yep, it's added there. thanks!
<lifeless> poolie: selftest hole, looking into it
<lifeless> poolie: a syntax error in gio_transport led it to just bypass everything; a subunit-glue bug I'll address
<MWinther> well, that worked for every file except one... That one says 'File id already exists in inventory as InventoryFile...'
<lifeless> check bzr st for oldfile and newfile
<MWinther> oldfile is removed, newfile is unknown.
<lifeless> spiv: ping?
<lifeless> poolie: https://bugs.edge.launchpad.net/subunit/+bug/586176
<ubot5> Launchpad bug 586176 in subunit "want to be able to make a 0-test stream a failure (affected: 1, heat: 0)" [Wishlist,Triaged]
<poolie> sheesh
<lifeless> yes, mea culpa
<lifeless> I'll do it shortly, probably not today.
<poolie> i see this as evidence for having bzr emit a return code, even if subunit pipelines want to ignore it
<lifeless> perhaps
<lifeless> I don't mean to be equivocal here
<lifeless> in hudson there is a 'build' vs 'test' separation
<lifeless> where you can succeed at one and fail at the other; in hudson, this would be a failure because hudson looks at the test count
<poolie> what should we do in the interim?
<lifeless> well, I think the risk of doing nothing until say tuesday (to let spm get back here) is pretty low
<lifeless> python 2.4 specific syntax errors are going to be about the only thing pqm will notice that we won't.
<lifeless> and I can have a patch for subunit + a patch for bzr to use that prepped early next week
<poolie> so things we land but not be tested?
<lifeless> no, with the python2.4 syntax error fixed pqm is running tests again
<lifeless> http://pqm.bazaar-vcs.org/
<poolie> but my patch just slipped in while it wasn't running them?
<poolie> hm
<spiv> lifeless: pong
<lifeless> yes, because the one right before was the gio patch which had the python2.4-breaking thing
<poolie> ok
<lifeless> spiv: poolie suggests and I agree that we should release 2.1.2 tomorrow
<lifeless> spiv: you were working on sigwinch stuff; is 2.1.2 *currently* good-to-go, or do you need to do $something about it ?
<spiv> lifeless: re earlier question, news_merge can't use branch.conf yet (although the better-news-merge branch is headed that way)
<spiv> I need to do $something.  I just finished lunch, I'll finish that $something now.
<lifeless> ok
<lifeless> please assertively tell me when its done, I won't do a release tomorrow if I haven't heard from you. And I have a slightly offset-to-be-earlier day tomorrow.
<lifeless> which reminds me... goes to mail
<poolie> ah right
<poolie> if your day is going to be too chopped up to do it, you can bail out
<lifeless> poolie: if we're good to go this evening then it should be no trouble at all
<lifeless> and I think it will be fine, sigwinch is the only gotcha I know of
<spiv> lifeless: ok, will do
<poolie> spiv, and you're basically going to take that patch that makes it poll, and put in the logic to use COLUMNS until the size changes
<poolie> is that correct?
<lifeless> poolie: if, when I go to sleep, 2.1.2 isn't good, I'll mail the list saying that its not copacetic and that I'm bailing :)
<spiv> poolie: correct
<lifeless> so, fires fought
<lifeless> ok
<lifeless> I'm putting nose down into this patch
<lifeless> its been lingering all week
<lifeless> and I wants to be able to use it.
<lifeless> if you need me, ring me on skype or something :)
<parthm> mgz: ping
<lifeless> parthm: its 4am for him
<parthm> lifeless: oh :P ... wrong time :) thanks for letting me know.
<parthm> lifeless: i was thinking that the try/finally use for opening-read/write of file that mgz did in his recent patch should go into coding-style. is that something we want to follow normally?
<lifeless> its there already, i think
<parthm> lifeless: i cant seem to find it in doc/developers/code-style.txt .. i mean the explicit closing of file in finally rather chaining open.read/write than leaving it to gc
<lifeless> please do add it
<lifeless> it may be in developers/*.txt
<lifeless> so have a search around
<parthm> lifeless: will do. thanks.
<parthm> lifeless: i sent the doc patch to pqm and got a mail that its queued. however it doesn't show up in http://pqm.bazaar-vcs.org/ or in feed-pqm. is this normal?
<parthm> lifeless: status on https://code.launchpad.net/~parthm/bzr/doc-explicit-file-close/+merge/26121 shows queued and the queue is empty right now.
<spiv> parthm: use the queue-by-email option in feed-pqm, rather than the other option ('e' rather than 's')
<rsvp> Q: what happens after "bzr rm --keep foo" is executed? Do the all the diff versions of foo kept internally disappear? And so is there a reduction in the size of bzr files? Finally, is there an undo after such execution?
<spiv> parthm: the queue-by-launchpadlib (the 's' option) isn't quite ready for use, Launchpad needs a little more work
<spiv> It's a bit confusing because 's' used to be the queue-by-email option :/
<spiv> rsvp: 'bzr rm' removes the file from the current version of the tree, but the old history is still there
<spiv> So it doesn't cause any reduction in size
<spiv> You can undo it with "bzr revert foo"
<parthm> spiv: thanks for clarifying that. i will set it back to approved and use e.
<spiv> parthm: yep, that should fix it
<rsvp> spiv, thanks for your response -- so is there another command which will wipe out the old history?
<spiv> rsvp: not builtin.  You have to rewrite the history to achieve that.  Possibly the bzr-rewrite plugin can help, otherwise I'd use the bzr-fastimport plugin to export a dump, filter that dump, and import that into a new repository
<spiv> rsvp: note that rewriting history like that will make it hard to merge changes from other branches made from the old history :(
<rsvp> spiv, sounds a bit hazardous ;-)
<parthm> spiv: that worked. thanks :)
<rsvp> spiv, thank you very much again for your help.
<spiv> rsvp, parthm: you're both welcome :)
<vila> hi all
<spiv> vila: good morning
<spiv> vila: https://code.edge.launchpad.net/~spiv/bzr/no-sigwinch-583941/+merge/26118
<vila> spiv: Hopefully the day will continue better than it started, I've just been able to reboot my main mac which refused to do so for almost an hour....
<vila> I haven't finished checking the basis stuff, just came here to warm
<spiv> vila: ouch :(
<vila> spiv: yeah, nightmare, never saw a mac refuse to boot.... not even the Apple logo on grey background.... and finally, hey I'm back, don't worry, nothing happened, yeah sure
<vila> spiv: approved (web browser was a low risk try :), I'm less inclined to try to land though
<vila> urgh, hidden ff window whining about not recovering session :(
 * vila kills more chickens
<fullermd> It's a mac; you better just go straight to goats.
<spiv> vila: ok, thanks, I'll kick off the landing then
 * vila add some goats
<vila> err, wait, I don't have goats, rats
<vila> hmm, did anybody ever see procmail crashing repeatedly (like hundreds of time in the same second) and filling system log ? (Well the later is OSX reporting crashes, but still)
<spiv> vila: ouch, happily (for me), no.
<spiv> lifeless: have sent SIGWINCH patch to PQM
<vila> *** process 15666 exceeded 500 log message per second limit  -  remaining messages this second discarded ***
<vila> don't you love that ? >-}
<vila> of course it began at 7pm when I stopped working and crashed... around 5AM ?
<vila> Did anybody has a log of this channel and can tell me when I disappeared ?
<vila> May 27 05:03:23 bigmamac kernel[0]: hfs: Runtime corruption detected on osx, fsck will be forced on next mount.
<vila> here we are, I've got my culprit, may also explain the unusual long time to boot, time for more thorough cheks, cu later
<fullermd> 18:59 -!- vila [~vila@lec67-4-82-230-53-244.fbx.proxad.net] has quit [Remote host closed the connection]
<fullermd> That would be, what, 7 hours ago?
<spiv> parthm: I see your PQM request landed :)
<parthm> spiv: yay :) ... i wasn't sure if email would work. haven't tried that before.
<spiv> parthm: btw, with the current version of hydrazine, don't add the names of the proposer or lander to the commit message
<spiv> parthm: hydrazine now does that for you, so if you do it too you get some redundancy
<spiv> parthm: so the latest commit has an amusing message :)
<parthm> spiv: yes. i noticed that ... but it was too late by then ... the message has more parthm than actual content :P
<spiv> parthm: well, you do deserve some credit after all ;)
<parthm> i noticed that diff for the mp https://code.launchpad.net/~snaggen/bzr/gio-transport/+merge/24664 is out of date. setting it from merged->needs review doesn't seem to rescan it.
<parthm> are merged mps treated differently for rescan?
<spiv> Not sure.
<spiv> But probably making a new submission would make a little more sense anyway, if the original proposal has been merged
<spiv> If you do it via the Resubmit status it'll even show the original conversation in the new proposal.
<parthm> spiv: resubmit did the trick. thanks.
<lifeless> merged proposals don't update
<lifeless> simple reason, they would be empty
<parthm> lifeless: in this case some new revisions were pushed. so setting it back to 'needs review' should probably have worked. but 'resubmit' seems better.
<lifeless> perhaps file a bug
 * StevenK wonders how to push a 4 pipe branch to lp properly
<StevenK> The docs don't read clearly
<StevenK> (Or I'm a muppet, which is possible)
<YaManicKill> how do i overwrite files on my computer from a bzr branch without removing the old folder?
<YaManicKill> cause "bzr branch lp:heybuddy" moans that the folder already exists, but i don't wanna have to delete it everytime i update the files
<jpds> YaManicKill: cd heybuddy; bzr pull ?
<YaManicKill> jpds: ahhh nice :-) works. thanks
<lifeless> night y'all
<alex-weej> o hai, i want to review revisions on someone else's branch. i've 'pulled' their branch into my repo but i screwed up because i had my 'trunk' branch in there and now all of their branch is inside that directory
<alex-weej> any ideas what i should do?
<alex-weej> also it went to the trouble of pulling the whole history which took ages, both my 'trunk' branch and their branch share most of the history
<alex-weej> so what did i do wrong there?
<parthm> alex-weej: are you using a shared-repo?
<cnd> Can someone help me figure out how to do the following in bzr:
<cnd> 1. make edit with typo
<cnd> 2. make more commits on top of typo
<cnd> 3. in git, I do a rebase -i and edit that one commit where I introduced the typo, and the rest of the commits magically are rebased on top of it
<cnd> how can I do 3 in bzr?
<parthm> cnd: bzr has a rewrite plugin for rebaseing. https://launchpad.net/bzr-rewrite
<LeoNerd> Personally I'd branch it. branch the revision with the typo, uncommit, edit, recommit, then replay the rest on top. However, be aware that if you do that, all the later revisions now have a different revid, so other people's branches will now be broken
<LeoNerd> so that's a really rude thing to do if anyone else has seen the branch since you made that commit
<parthm> cnd: but generally rebasing isn't recommended in bzr. bzr anyway hides merge history by default.
<cnd> my use case is that I'm editing multiple commits privately
<cnd> and I realized before I went to push that I had a typo
<cnd> I want to clean up the history
<LeoNerd> See my suggestion then
<alex-weej> parthm, i don't know, how do i check?
<LeoNerd> (well, it's what I usually do anyway.. perhaps there's a neater solution somewhere)
<cnd> LeoNerd: thanks, I'll look at that and bzr-rewrite
<alex-weej> parthm, it's ok i just did init-repo on a new directory and branched both of them, it seemed to be more efficient that way
<parthm> alex-weej: do you have a directory .bzr/branch
<parthm> alex-weej: yes. shared-repo is the suggested way if its a long term project.
<alex-weej> parthm, no not in my new one
<parthm> alex-weej: yes. so init-repo creates the shared branch. you would typically do.
<alex-weej> i want my working tree on another test machine (well a VM actually) -- i'm currently using NFS on my trunk branch folder but obviously if i want to switch to another branch lke with git then i need to update all my NFS stuff
<alex-weej> can i use remove-tree on my 3 branches and somehow create a working tree that i can just switch between branches?
<parthm> alex-weej: 'bzr init-repo foo && cd foo && bzr branch path-to-trunk'
<parthm> alex-weej: so if i get your right you want to do in place switching between branches?
<alex-weej> parthm, yeah i think so, like i used to do with git
<parthm> alex-weej: so you would start off with a shared repo .. so if we have foo like what was created above. that will save all the history.
<parthm> then you have branches 'foo/trunk', 'foo/bar', 'foo/bar' which all share history.
<parthm> inside foo you can do 'bzr checkout --lightweight trunk edge'
<parthm> you would use foo/edge as a bound branch ... so in the above command edge is bound to trunk.
<parthm> once you are done hacking inside edge. you can do say 'bzr switch ../bar' this will bind edge to ../bar branch
<parthm> personally i just work inside foo/trunk or foo/bar or foo/baz... as they all share history pull etc. are fast as only little history needs to be gotten.
<alex-weej> parthm, ok thanks, my test deployment just wants the code to be in one folder -- i guess i'll use a lightweight checkout
<alex-weej> is there anything like git stash? where i can commit my unsaved changes to a temporary branch so that i can switch to another branch?
<parthm> alex-weej: bzr has a shelve command. i think it does something similar though i don't know git much.
<parthm> and unshelve.
<alex-weej> parthm, ok thanks
<csgeek> hi all
<cnd> I tried doing a bzr rebase --dry-run, but it seems to have made changes to my tree anyways! how do I go back?
<cnd> is there something like git reflog?
<csgeek> is there a guide to setting up a self hosted version of launchpad?  or is there some hosted version of bzr?  Looking for a nice little web frontend to read history, tickets, code review (would be nice), wiki.. usual tidbits
<lifeless> cnd: bzr heads --dead
<cnd> lifeless: ok, now how do I get one of them back?
<cnd> I tried bzr pull . -r <revid>
<cnd> but it complained that I've diverged
<lifeless> yes, because rebase
<lifeless> so --overwrite
<cnd> ahhh, ok, thanks
<csgeek> is there something like gitosis/gitolite for bzr?  Something that relies on RSA/DSA ssh key authentications rather then having a system user for each person needing to access that location?
<lifeless> csgeek: the launchpad ssh hosting server does that
<lifeless> you could adapt that to whatever backend you have
<csgeek> lifeless: okay.  Is there a proper guide on how to setup/configure the launchpad hosting server? I found the project.. but can't find any decent guides
<lifeless> well, for a test environment, see e.g. https://dev.launchpad.net/Running/VirtualMachine + https://dev.launchpad.net/Getting + https://dev.launchpad.net/Code/HowToUseCodehostingLocally
<csgeek> lifeless: thank you very much.
<lifeless> jam: ping
<csgeek> I know that I can can an individual file from a bzr repo.  ie.  bzr cat http://foobar/path/readme.txt  is it possible to checkout only a certain file from a particular tag/revision
<lifeless> can can ?
<mgz> it's a little bit of a dance.
<csgeek> s/can can/can/   the extra can is for extra superior ability
<lifeless> csgeek: missing a verb then, I think :)
 * lifeless is yak shaving at 3:37am. Not a good sign.
<mgz> csgeek, what's the practical difference between cat -r 45 ..../file > ..../file and "checkout only a certain file"?
<jelmer> lifeless: :-) What are you working on?
<lifeless> jelmer: release process
<mgz> you want a bzrdir with.. what?
<lifeless> it was rather jumbled up
<jelmer> lifeless: ah
 * jelmer is looking forward to 2.2.0 - are you doing another beta?
<lifeless> 2.1.2 and b3
<mgz> jelmer, any insight on how bug 393038 can be reproduced? bzr-git seems to be in the traceback
<ubot5> Launchpad bug 393038 in Bazaar "UnicodeDecodeError in _inaccessible_normalized_filename (affected: 3, heat: 14)" [Medium,Confirmed] https://launchpad.net/bugs/393038
<mgz> the code in osutils is clearly bogus (anything doing `unicode(path)` is much the same as saying "make this look like it works on my machine but break for everyone else"), but could do with a test case
<mgz> at a guess, checking out a git branch with latin-1 filename on a utf-8 filesystem?
<jelmer> mgz: yeah, I suspect that would trigger it
<csgeek> mgz: well.. I want to specify which branch/tag the file comes from ...
<csgeek> not sure if cat will let me do that
<csgeek> oh.. though -r 45 I would guess it does.
<lifeless> :)
<mgz> bzr help cat
<lifeless> miao
<jam> lifeless: pong, what are you doing up?
<csgeek> and I presume I can specify -r N , with N being a tag name?
<mgz> bzr help revisionspec
<lifeless> jam: releasing
<lifeless> couldn't sleep @ 3am - hating the bed in this rental place - and I was going to start work @5am anyhow.
<lifeless> jam: I wanted to know if releasing.txt was up to date, but its all over the shop, so clearly not.
<lifeless> jam: so, I want to know whats *not* documented :)
<jam> lifeless: also check 'cycle.txt'
<lifeless> oh!
<jam> and ppa.txt
<jam> I certainly think releasing.txt needs to be brought up to date
<jam> but I think stuff like "update freshmeat" etc are all still correct
<lifeless> sure
<lifeless> I went to execute the algorithm and raised an exception up front :P
<csgeek> thank you mgz.. that works.
<lifeless> jam: when you do releases
<lifeless> jam: do you tag locally, or let pqm merge the version change and *then* do a tag?
<jam> lifeless: I *now* do the former
<jam> the latter seemed more correct to me
<jam> but it is a much larger PITA
<lifeless> hmm
<jam> especially since the branch itself won't end up with the tag
<lifeless> we should work on that
<jam> jml did the former, I'm not sure what poolie did, but somewhere in the release process I think poolie and I decided to switch to tagging locally
<skeledrew> hello.  i'm getting an error in bzr in downloading wubi "ERROR: Unable to create symlink 'bin' on this platform". any fix for this?
<jam> lifeless: for example, if you could feed-pqm and tell it 'tag this bzr-2.1.2 when it succeeds' that would simplify the process and switch to what I consider the "correct" way.
<jam> skeledrew: I assume you are on Windows?
<skeledrew> yes
<jam> ATM, we don't have a workaround for checking out projects that have symlinks on platforms that don't have symlinks
<jam> aside from having the upstream remove the symlink...
<jam> the other option is to use the cygwin version of bzr
<jam> which fakes symlink support
<skeledrew> ok
<mgz> file a bug with upstream, symlinks aren't portable, and "bin" should be created by the build process, not be part of the revision history
<lifeless> jam: it says to 'upload the source tarball on the milestone'
<lifeless> jam: but I can't see how to do that without doing a release; is that right ?
<jam> lifeless: you have to do the release, and upload to that, yes
 * lifeless bugginates
<jam> but you upload to 2.1/2.1.2/
<lifeless> yes, I was just cross-checking
<jam> lifeless: IIRC, if you don't do a release then "lp.net/bzr/2.1/2.1.2" doesn't *exist* yet, since you only have "../bzr/2.1/+milestone/2.1.2"
<lifeless> sure
<lifeless> I was clarifying an ambiguity between the docs, intent, and lp
<lifeless> the intent is not to announce the release
<jam> I was just working through the logic to make sure I remembered correctly :)
<lifeless> lp announces releases when you do the release thing on the milestone
<lifeless> and our docs weren't clear that doing the release was ok
<jam> lifeless: last I checked, lp didn't announce until you manually announced, that changed?
<lifeless> theres a feed
<jam> (it was partially why many of our releases were never announced)
<lifeless> and announcements separately
<lifeless> https://bugs.edge.launchpad.net/launchpad/+bug/586445
<ubot5> Launchpad bug 586445 in Launchpad Bugs "OOPS on +bugs-text page (affected: 1, heat: 6)" [High,Triaged]
<lifeless> huh bah
<lifeless> thats not what bug 586445 is
<ubot5> Launchpad bug 586445 in Launchpad itself "would like to be able to upload files to a milestone *or* delay release announcements in feeds (affected: 1, heat: 0)" [Undecided,New] https://launchpad.net/bugs/586445
<lifeless> Wow
<lifeless> I'm not going to try and explain that right now.
<jam> lifeless: now that is pretty fun. Wonder if it is was an edg vs normal problem
<jam> lifeless:  seems to be bug 583385
<ubot5> Launchpad bug 583385 in Launchpad Bugs "OOPS on +bugs-text page (affected: 1, heat: 6)" [High,Triaged] https://launchpad.net/bugs/583385
<lifeless> hmm
<lifeless> I probably should have done 2.0.6 first
<lifeless> ah well
<lifeless> hmm
<lifeless> Using default stacking branch /~ubuntu-branches/ubuntu/maverick/bzr/maverick at lp-69641680:///~lifeless/ubuntu/lucid/bzr
<lifeless> -   4216kB    26kB/s | Finding revisions
<lifeless> little high
<lifeless> james_w: oh hahah - merge-upstream in lucid's bzr from tarball + bzr upstream branch ==== fun
<lifeless> james_w: it works, which is nice, but it also joins the previously unjoined history, and thats one hellof a lot of merged-revisions :)
<james_w> lifeless: \o/
<lifeless> jam: do you know, does igc still manually update the pretty docs
<lifeless> jam: or is the cron script working ? (see releasing.txt for context)
<lifeless> james_w: yeah, fallout from my otherwise perfect patch a while back
<lifeless> james_w: I'll file a bug once I finish 2.2b3
<lifeless> james_w: the SRU reviewer for 2.1.2 will get a surprise :)
<lifeless> 'here, have 35 MB of new history`
<lifeless> brekkie time I think
<lifeless> ok, that was more painful than I expected.
<lifeless> abentley: I'm really liking lp-propose.
<lifeless> I wish API's were faster though.
<abentley> lifeless, cool.  I wish the APIs were faster too.
<Spajderix> Hi
<lifeless> hi
<Spajderix> when using bzr with bzr+ssh paths it invokes bzr server with parameter --directory=/, directory is always / is there a way to force bzr to send path from given url, eg. when i use bzr+ssh://user@host[/path/to/something] bzr serve will be invoked with --directory=[/path/to/something]?
<lifeless> not from the client side
<lifeless> you can use a restriction tool on the server side to force that by ssh key or whatever - hum, I think 'rsh' (confusing name, its not the remote shell tool) is one such restriction thing
<Spajderix> lifeless: restricting path to given ssh key is no option, because I want one key to access multiple paths on server, is there any way, from environment variable or anything else, to see /path/to/something or even whole bzr+ssh://user@host/path string?
<lifeless> the two things are rather disconnected
<lifeless> is something actually going wrong in your environment?
<lifeless> are you getting an error? I have the feeling you're debugging something and we don't have the whole story to be able to help you properly
<Spajderix> here's the thing: I wanted to rewrite bzr_access script in a way that i will be able to assign list of premissions to a given key, eg. give rw permission to branch1 in repository1 and r permission to branch2 and so on, but I don't know how to find a path that a key is trying to access
<jam> lifeless: sorry, I think mbp might know more about doc gen. I never worked on it.
<AfC> bzr check is the first thing to do if Bazaar crashes, right?
<lifeless> jam: no worries
<lifeless> AfC: ask here is usally the thing to do
<lifeless> check only considers known data issues, bzr can crash due to bugs as well
<AfC> bzr: ERROR: exceptions.IndexError: list index out of range
<AfC> 2.1.1, lucid
<lifeless> more of the backtrace would be uesful
<lifeless> that could be just about anything
<AfC> yup
<AfC> working on it
<AfC> (so, multiparent)
<AfC> lifeless: http://paste.pocoo.org/show/219107/
<AfC> bzr crash dump (nice)
<lifeless> that looks like a bug to me
<lifeless> rather than data corruption
<AfC> shit
<AfC> hooray for me.
<AfC> I will file
<lifeless> IMBVW
<lifeless> hmmm, caffeination I think
<AfC> meanwhile I need to figure out how to accept this person's contributed revisions :(
<lifeless> also I need to reboot to make usb work :(
<lifeless> brb
<poolie> jam, hi?
<jelmer> moin lifeless
<poolie> hi jelmer
<jelmer> hey poolie
<AfC> lifeless: it appears I hit https://bugs.launchpad.net/bzr/+bug/514369 so I attached my crash dump there.
<ubot5> Launchpad bug 514369 in Bazaar "IndexError in multiparent _reconstruct reading bundle (affected: 2, heat: 14)" [Medium,Confirmed]
#bzr 2010-05-28
<lifeless> AfC: thanks
<lifeless> AfC: one possible cause
<lifeless> AfC: they may have run send with strange parameters
<lifeless> people do the oddest things
<AfC> yeah
<lifeless> jelmer: you're using git too much "bzr add .
<lifeless> "
<lifeless> whyforthedot!
<jelmer> lifeless: :-)
<jelmer> lifeless: btw, I've pushed an updated version of my split-subsegment branch for your reviewing pleasure.
<lifeless> jelmer: I'll look at it now
<lifeless> poolie: thanks for approving my branch; a small request - click on 'approved' at the top too, next time ;) - or 'merge: approved' if doing by mail
<jelmer> lifeless: thanks for the review
<poolie> lifeless, the dkim yak looks at me with big sad eyes
<lifeless> poolie: lol
<lifeless> poolie: it is whinging slightly
<poolie> 'it'?
<lifeless> the dkim yak
<lifeless> its saying 'shave me', 'shave me'
<poolie> ah yes
<lifeless> to the music 'I need to break free', 'I need to be shaved'
<lifeless> hmm, speaking of which, I should do that too
<lifeless> poolie: igc's sphinx doc branch can't land until we get some deps on pqm sorted out
<lifeless> I've queried him unsuccessfully about what they are
<lifeless> perhaps you can do so with more luck and either let me know, or jsut file an RT directly about it.
<poolie> we can't reproduce the failure?
<lifeless> poolie: its just the sphinx toolchain missing
<lifeless> I don't know what that consists of
<poolie> lifeless, hm bzr-loom, at least as it is in lucid, seems a bit broken by the named branch changes
<lifeless> poolie: we could/should SRU the trunk fixes for that
<lifeless> hmm, actually, I know I fixed it for 2.x, I don't know if I fixed it for named branch foo.
<poolie> hm
<jelmer> lifeless: are you landing the split-subsegment branch?
<poolie> https://bugs.edge.launchpad.net/bzr-loom/+bug/586602
<ubot5> Launchpad bug 586602 in Loom "open() got an unexpected keyword argument 'name' running 'info -v' (affected: 1, heat: 0)" [Undecided,New]
<lifeless> jelmer: I'm not sure, I did a feed-bzr run, so if it was pending to land, then yes :)
<lifeless> poolie: looks like not fixed yet
<poolie> lifeless, how would you feel about asking people to always tag bugs' regression'
<poolie> then we can get some stats
<lifeless> I'd be delighted to ask people to do that
<poolie> or softly prioritize them
<lifeless> please sire, may I have another?
<lifeless> jelmer: does the bzr packaging in debian have pristine-tar info yet ?
<lifeless> jelmer: and is it history-joined?
<jelmer> lifeless: no, it's got manual merges
<lifeless> jelmer: how would you feel about dumping the history and switching
<lifeless> sorry
<lifeless> was that 'not pristine tar'
<jelmer> lifeless: yes, not pristine tar
<lifeless> or 'not connected in history'
<jelmer> it's connected with bzr.dev in history
<jelmer> lifeless: I basically ran "bzr merge -rtag:bzr-2.1.2 lp:bzr/2.1; dch -v 2.1.2-1 New\ upstream\ release."
<lifeless> jelmer: ok, so you should do 'bzr import-upstream --version=2.1.2 TARBALL branch-of-2.1 at rev -2'
<jelmer> import upstream rather than merge upstream?
<lifeless> right
<lifeless> that will import 2.1.2's tarball
<lifeless> e.g. bzr branch lp:bzr/2.1 -r -2 temp
<lifeless> cd packaging
<lifeless> bzr import-upstream --version=2.1.2 tarball ../temp
<jelmer> bzr import-upstream really should support -r then :-)
<lifeless> iterative development
<lifeless> I don't know if james_w has merged it or not yet  even :)
<jelmer> lifeless: Branching first makes my life more complex, I'll see if I can provide a patch.
<lifeless> jelmer: you'll tear your eyes out.
<poolie> lifeless, branching a loom from launchpad (with tip of the plugin) gives me a loom with no thraeds
<poolie> is that a known problem?
<lifeless> poolie: no, and very unexpected
<lifeless> what does revert-loom do ?
<lifeless> poolie: the most likely explanation btw, is that the loom on launchpad has never had 'record' called
<poolie> ok probably
<poolie> perhaps we should have an optional warning to do it
<spiv> Good morning.
<poolie> hi there spivvo
<lifeless> poolie: I haven't done PPA uploads for the releases
<lifeless> I was going to, but I think I'm going to be out of time.
<lifeless> -sorry
<poolie> np
<jelmer> it looks like http://wiki.bazaar.canonical.com/SourceDownloads is out of date, should that perhaps just point at the launchpad download page?
<poolie> yep
<poolie> done
<lifeless> abentley: the fix to the command stuff - to not raise - is at 96% in PQM
<lifeless> abentley: so should land in a minute or two
<lifeless> ciao
<spiv> lifeless: hello again.  Did you see the post to the list about the bad .sig for the 2.2b3 tarball (it seems to have the 2.1.2 sig by mistake)?
<lifeless> no
<lifeless> fark
<lifeless> I should be able to fix now
<lifeless> I should have just used my automated toolchain, but its not polished yet
<lifeless> poolie: spiv just told me about the sig issue
<lifeless> am fixing
<poolie> ok
<poolie> shouldn't you be flitting?
<lifeless> yes, in the waiting area
<lifeless> boring not boardin
<lifeless> g
<lifeless> spiv: should be fixed shortly - 4% uploaded
<lifeless> spiv: ifxed
<spiv> lifeless: thanks!
<lifeless> de nada
<lifeless> is there anything else? 500 seconds to go :P
<spiv> lifeless: not that I know of
<spiv> lifeless: have a good flight!
<lifeless> thanks
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.1 is out
<humphreybc> hi
<humphreybc> could someone please tell me why I'm getting this error when I try to download a fresh branch in a fresh project?
<humphreybc> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~humphreybc/about-ubuntu/main/".
<humphreybc> I'm trying to start work in this branch, https://code.launchpad.net/about-ubuntu
<humphreybc> Do I need to do a push first?
<poolie> hi humphreybc
<poolie> yes, make a branch locally then push there
<humphreybc> benjamin@benjamin-laptop:~/Projects/about-ubuntu/main$ bzr push lp:about-ubuntu
<humphreybc> bzr: ERROR: Not a branch: "/home/benjamin/Projects/about-ubuntu/.bzr/branch/": location is a repository.
<poolie> i guess you need to cd into your trunk directory
<humphreybc> benjamin@benjamin-laptop:~/Projects/about-ubuntu$ bzr push lp:about-ubuntu
<humphreybc> bzr: ERROR: Not a branch: "/home/benjamin/Projects/about-ubuntu/.bzr/branch/": location is a repository.
<humphreybc> benjamin@benjamin-laptop:~/Project
<humphreybc> is it because I've used ground control to pull the project first?
<poolie> where did you pull it from?
<humphreybc> what do you mean?
<poolie> hm
<poolie> i was asking what you did with ground control
<poolie> but let me ask instead
<poolie> so you're trying to start a new project called 'about-ubuntu'?
<humphreybc> yepo
<poolie> and there's no code for it anywhere yet?
<humphreybc> nope
<poolie> except maybe on your laptop?
<humphreybc> none on my laptop yet
<poolie> ok so what does 'bzr info' show?
<humphreybc> bzr info where?
<cody-somerville> lol
<humphreybc> I got rid of my ground control folder
<poolie> ok
<humphreybc> and just started from scratch
<poolie> so to get started you should do
<poolie> "cd"
<poolie> "bzr init-repo about-ubunut"
<poolie> *ubuntu
<poolie> "cd ubuntu"
<poolie> "bzr init trunk"
<poolie> "cd trunk"
<poolie> "bzr push lp:about-ubuntu"
<poolie> mm
<humphreybc> oh really? I can't just pull down the branch?
<poolie> perhaps before doing this you want to make an ~about-ubuntu-dev team?
<humphreybc> and I'm doing all this inside ~/Projects/about-ubuntu
<poolie> it sounds like there's no branch to pull yet
<humphreybc> I'll probably be the only person developing for it at the moment
<humphreybc> so can I push say a plain txt file to just initiate the branch?
<poolie> sure, so let's change those instructions to
<poolie> bzr init-repo ~/Projects/about-ubuntu; cd ~/Projects/about-ubuntu
<poolie> bzr init trunk; cd trunk; gedit README; (type something):
<poolie> bzr add; bzr commit; bzr push lp:about-ubuntu
<poolie> that'd be a nice project btw
<poolie> it's not a great window at the moment
<humphreybc> yeah, it's part of the revitalization of the Ubuntu first use stuff
<humphreybc> committed okay, but when I went to push, "bzr: ERROR: Target directory lp:about-ubuntu already exists, but does not have a .bzr directory. Supply --use-existing-dir to push there anyway."
<poolie> i wonder how you got that
<humphreybc> and Ground Control is kindly informing me it's a read only branch
<poolie> anyhow, yes, add that option
<humphreybc> so Ground Control can't initiate branches?
<humphreybc> yay, that seemed to have worked
<humphreybc> now I wonder if I can pull the project and branch using ground control
<humphreybc> every time I try to use GC it never works, i'm so eager to actually use it!
<poolie> sorry, i'm not expert with gc
<humphreybc> so howcome the URL for the branch is "https://code.launchpad.net/~humphreybc/about-ubuntu/main" instead of "https://code.launchpad.net/about-ubuntu
<thumper> humphreybc: any LP code questions I should be able to answer
<humphreybc> thumper: Okay, i'll hassle you in the future then :)
<humphreybc> thumper: Brendon sent that email out to everyone too
<humphreybc> are you the only speaker on Monday?
<humphreybc> great, ground control pulled down the branch fine now. thankyou for your help poolie
<thumper> humphreybc: https://code.launchpad.net/about-ubuntu points to branches for the project
<thumper> humphreybc: all branches have an owner and a name
<thumper> humphreybc: they have short cuts, but they don't always translate to a branch location
<thumper> humphreybc: although https://code.launchpad.net/+branch/about-ubuntu should redirect
<humphreybc> okay, groovy
<thumper> humphreybc: I saw the email, and I think we might convince ajmitch to talk about quickly
<thumper> humphreybc: you can always join #nzpug :)
<humphreybc> I'm hopeless at joining channels
<humphreybc> I use Pidgin, you see :P
<thumper> humphreybc: try /join #nzpug
<humphreybc> oh yeah, I know how to join channels
<thumper> to know and not to do is not to know
<thumper> :)
<humphreybc> but pidgin doesn't have an auto-join thing, so every time I start it up, I have to manually join them - hence why I'm only ever in one or two
<thumper> well that sucks
<humphreybc> pretty much
<humphreybc> where should I go to talk about python/gtk/glade and all that?
<poolie> humphreybc, hm #ubuntu-motu maybe?
<poolie> humphreybc, i think it does have auto join
<poolie> but i use xchat now
<humphreybc> poolie: really? hmm. I've looked through all the settings and plugins but never found anything
<mwhudson> does pidgin actually work well for irc?  i've always had a hard time imagining that
<poolie> join the room, then right-click it in the buddy list and choose auto-join
<humphreybc> how do you get rooms to show in the buddy list?
<poolie> mwhudson, it's kind of ok but not great
<humphreybc> ohh
<humphreybc> I see!
<poolie> mwhudson, i don't think it shows who's in the channel
<poolie> you can't ignore joins/parts
<poolie> oh and you can't ignore stupid freenode bots
<humphreybc> yeah, the bots are annoying
<poolie> so i went back to using empathy for xmpp and xchat for irc
<mwhudson> yeah, i use xchat
<mwhudson> i used to use erc, but i'm gradually getting over the "use emacs for everything" thing :-)
<humphreybc> emacs = bad
<humphreybc> What's that opportunistic developers channel?
<mwhudson> pff
<ara> hello!
<ara> can anyone remind me what was the option in bzr commit to close a lp bug, please?
<bialix> --fixes
<bialix> but it does not close, just add mark
<ara> bialix, ok, thanks!
<poolie> ara, --fixes lp:00000
<ara> poolie, yes, thanks :)
<ara> poolie, how is it going? about to finish the week for you, isn't it?
<poolie> hi ara, bialix
<poolie> yes
<poolie> just ask stephanie :)
<bialix> hi poolie !
<spiv> Ok, I have a rough implementation of 'bzr merge-into' that passes some blackbox tests and has a fairly clean core implementation.
<spiv> Just in time for beer o'clock ;)
<spiv> All that remains is decrufting...
<spiv> Have a happy weekend everyone!
<fullermd> Harumph.  All you smug people over there, chasing the Date Line...
<poolie> nice one spiv, have a good weekend
<awilkins> jelmer, I have some problems with bzr-svn finding tags on a particular repository ; it tries once for each new branch, fails, then doesn't try again. Would you like a stack trace?
<jelmer> awilkins: please file a bug
<awilkins> jelmer, Clearing out the metadata cache may have fixed it.. on another note, why are tags a per-branch thing and not shared in a shared repository?
<awilkins> (not that this is a bzr-svn thing)
<awilkins> Since tags are on revisions not branches, and revisions are fundamentally stored in a repository, should tags not also be stored in the repository?
<jelmer> awilkins: tags are like a dictionary though
<jelmer> awilkins: you can't have a tag set on more than one revision
<jelmer> awilkins: unlike your normal web2.0-ish tags
<jelmer> awilkins: so if you have multiple unrelated projects in a repo you might get conflicts
<awilkins> Heh, it was just affecting me after this tag discovery thing because it only does it once the first time it pulls the branch - so the branches that were suffering from it don't have the older tags... repulling them fixes that though
<awilkins> Just occured to me that if they were a repo-level thing I'd only have to do it once.
<awilkins> I suppose you could use the same tag on multiple diverged branches and only run into trouble when you wanted to merge them
<millun> hi
<millun> i've created a branch in /var/www/. but when i try to do anything to update the branch (bzr merge, right?) i get error that /var/www is not a branch
<spiv> millun: how did you create the branch?  What does "bzr info -v" report?
<ronny_> hi
<jelmer> hey ronny_
<ronny_> easy_install/pip install bzr=={2.0,2.1,2.1.1} fails for me - can anyone fix that?
<ronny_> ok, wait, easy_install actually finds 2.1
<iamlouis> Hello! I was wondering if anyone could help me - I'm trying to set up bzr to keep track of a uni project - I want to be able to work on it on my desktop and my netbook and keep a master repo on my desktop. My problem is that I can't figure out how to do it, despite googling for ages! Any suggestions?
<nailuj24> iamlouis: do you want to also have a repo online?
<iamlouis> nailuj24: not just now, I'd rather get it to work before putting it online, and as it's for my course I wouldn't be able to accept any code contributions anyway! I thought I'd set up ssh on my desktop and then log in every now and then and commit changes from my netbook
<mgz> that's kinda too broad a question to be able to usefully answer.
<nailuj24> that would work indeed
<mgz> I take it you've read <http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/tutorial.html>
<nailuj24> iamlouis: in general, there's no thing like "master repo". in bazaar, all branches are equal
<nailuj24> yes, the tutorial is a very good place to start
<mgz> once you have the basics working on one machine, all you need to do it be able to address the other machine (by ssh as you said, or just see the filesystem over the network)
<mgz> and create a new branch from the main one, so you can pull/push between them
<mgz> probably don't need to worry about merging as it's only you working on it
<iamlouis> I've looked at the tutorial, but a lot of it went over my head, I haven't really used a version control system before which probably doesn't help! I added a new user, created a branch and have a bzr server running, but I can't seem to commit changes to it, I'll go away and read the tutorial again, then maybe come back when I get totally stuck/confused! :-D
<nailuj24> iamlouis: you don't need a server with bazaar :)
<nailuj24> iamlouis: that's the good thing about it
<nailuj24> iamlouis: basically, you commit to a normal directory
<iamlouis> nailuj24: so how would I sync commits on my netbook and my desktop?
<iamlouis> (sorry for asking idiotic questions btw!)
<nailuj24> no problem. in theory, you just have two directories and keep them in sync
<nailuj24> i found this very helpful when i started with bzr http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html
<iamlouis> thanks :-)
<vila> iamlouis: if you can connect to your desktop via ssh and bzr is in your path, you can 'bzr push bzr+ssh://iamlouis@desktop/~/uni_project'
<vila> iamlouis: and be done
<vila> iamlouis: do some tests to understand when you need to 'bzr update'
<vila> iamlouis: later, you can also look at 'bzr bind :push' on your laptop and 'bzr bind' when your desktop is not reachable (aka you're not connected to internet)
<iamlouis> vila: thanks, I think I'm slowly getting there - just trying to set up the ssh server now on my desktop. I've got the local repo on the desktop working nicely, that mini-tutorial is brilliant
<iamlouis> vila: cool, I'll look at bind once I get the basics sorted, thanks
<vila> iamlouis: oh, and after the first push you can just 'bzr push' (search for the --remember option)
<iamlouis> vila: great, thanks
<vila> iamlouis: start without bind, you'll use it better once you're a bit more familiar with push and update
<iamlouis> vila: will do, thanks
<mgz> vila, your computer survived then?
<vila> mgz: no
<mgz> ack.
<vila> mgz: but I think I've got all the needed services restored: web, mail, ssh and gpg auth
<vila> mgz: the HD died and since it wasn't serviceable (I swear I tried, but I resigned at step 3 when the DIY had 20 steps + 20 backwards of course)
<mgz> may it live happily in machine heaven.
<vila> I had to find a repair store, the best I found will give me my mac back with a new HD next wednesday (yes, tuesday at best(
<vila> You live and learn :)
<vila> The hard part that I was also running my "main" host as a vm there... So I lost not one but two machines
<vila> Most of the backups were already in place on the laptop, and I had a 95% backup of the dead HD, but getting the last 5%...
<vila> Ever heard about putting an HD in the freeze to make it work just that more minute to get this file pretty please nothing else fullpath given no cd I swear ?
<mgz> heh, yeah, that trick is famous, no idea how reliable it actually is
<vila> Well, I couldn't use it because my freeze is too small or a 24", but yes, waiting even for 20 minutes that the HD cool down, even at room temp, helped
<vila> s/or a 24/for a 24/
<rockstar> vila, it worked for me, but not for long.
<vila> But I used it on an old HD with good results some years ago
<mgz> the only hdd I've had trouble with refuses to actually die, it just got less and less reliable until I got fed up with it making my computer hang
<vila> rockstar: yeah, I'm not suprised
<guijemont> vila: you mean you can't get your HD out?
<vila> mgz: I stopped playing with that long ago, a dieing HD is worse than any other hardware failure I can think of (on the other hand bluetooth these days...)
<vila> guijemont: 20 steps+20 backwards ^
<guijemont> mac ?
<mgz> it's a mac, guijemont
<vila> guijemont: The HD is *behind* the LCD
<mgz> they don't make it easy.
<guijemont> ok :)
<guijemont> that's soooo simple on a thinkpad
<guijemont> 1/ remove one screw
<guijemont> 2/ take the hard drive
<vila> mgz: that's a bit exaggerated, but this model is reputedly the worse, in fact the DIY was for a 20" and some guy had left comments about... well has left a patch
<guijemont> really cool when I had to send imne for repair for sucky usb ports
<guijemont> they let me the choice to *not* send my hard drive with all my data
<vila> guijemont: the LCD itself couldn't be bought at that time, trust me that was a bargain
<vila> I've only seen HD died three times, but this last one was the most aggressive and devastating one
<guijemont> makes me think I should back up my stuff more
<vila> guijemont: Hehe, be honest, when was the last one ?
<guijemont> so far I've been lucky with HDs, but I don't believe this is always gonna be the case
<guijemont> vila: well, err, ...kinda
<guijemont> I did that when I installed karmic on my laptop
<guijemont> since I changed from reiserfs to ext4
<ronny_> who do i need to bug to fix easy_installablilty of older bzr releases that may still be in the wild
<guijemont> I copied all my stuff on an external HD, and didn't delete it from there afterwards
<mgz> not me, easy_install is the devil.
<vila> rockstar: wow, that's kinda vague... versions ? OSes ?
<mgz> wrock r-tab?
<mgz> *wrong.
<mgz> dammit.
 * rockstar looks up
<vila> errr, sorry rockstar, that was for ronny_ bad xhat, no sugar
<vila> ronny_: wow, that's kinda vague... versions ? OSes ?
<ronny_> vila: anything older than 2.1.1 cant be installed with pip/easy_install
<ronny_> vila: and well, i really could use that for my build process for the anyvc ci server
<vila> rockstar: that leaves only 2.0.6 for which we will gladly accept patches I think :)
<vila> ronny_: but we recommand 2.1 over 2.0 anyway, the former has received optimizations and bug fixes and there is no good reason to *not* upgrade
<mgz> bah, so much for testing that.
<mgz> bzr-git needs dulwich needs a C compiler.
<ronny_> vila: well, this is just for having backward-compatibility tests in my ci
<mgz> I'm not launching on upgrading this box from lenny right now, or deleting enough stuff to fit gcc on there
<mgz> ...I guess I can always remove gcc after... okay then.
<vila> ronny_: I don't get it, I'm all for automated tests, but backward comp of what with what ?
<vila> mgz: You have a lenny setup ???
<mgz> ...which... still failsm, errors in dulwich/_objects.c
<mgz> ^yup, on my old box
<mgz> 's a K6-III and not a big HDD.
<vila> If you need a bigger HD and have a fridge I may make you an offer you could not resist in a couple of days...
<mgz> ehehhe
<vila> mgz: oh, and I should have a fix for most of the thread leaks RSN, I'm sorry it took so long to get some progress on the indows32 stuff
<ronny_> vila: bzr versions that are still in the wild?
<mgz> it's not an easy fix, if you'd have done it in a day I'd have almost been offended :)
<vila> mgz: The main source of thread is now SocketListener
<vila> ronny_: if that's for automatic installs, can't you just 'bzr pull --overwrite -rtag:xxx ; make ' and run from source ?
<vila> ronny_: I mean installs in the ci context (hudson ?)
<vila> mgz: I'm around 50 tests leaking and most of them come from this single point
 * vila off, may pass around later
<mgzmini> ah, now I see, don't have Python headers on here for some reason
<ronny_> vila: i'd have to script that, and only for bzr, wouldnt be worth it
<mgzmini> later vila, good news on thread leaks, if not hard drives.
<iamlouis> vila: cheers for your help earlier, got it working now, thanks!
<ronny_> i wouldnt have any issues if the bzr guys would actually upload their releases to pypi :(
<mgz> using setuptools is asking for issues.
<ronny_> mgz: im using pip install, works fine, caches after the first install, and generates no issues
<ronny_> mgz: however that needs the releases to be findable somehow
<ronny_> and older bzr releases arent findable
<mgz> scraping webpages for binary code isn't a great way of doing things.
<ronny_> mgz: scraping the pypi index for source packages is reasonable enough
<bitdancer> I've got a simple quesiton whose answer I couldn't find in the docs: how do I get bzr to display its currently remembered locations?
<exarkun> Can I expect "bzr revert; bzr update; bzr clean-tree --force --ignored --unknown --detritus" to give me a working tree that's exactly the same as one I'd get from a clean "bzr checkout"?
<maxb> I would certainly think so. I can't see how there would be any difference left after that
<maxb> bitdancer: bzr info
<exarkun> Darn it, it turns out I want one difference to remain :/
<bitdancer> maxb: ah, so simple.  Thank you.
<bitdancer> maxb: except that it doesn't tell me what I want to know.
<bitdancer> :(
<maxb> Does it not? What did you want to know?
<maxb> bitdancer: ?
<bitdancer> maxb: I figured it out.  It said 'parent branch' and I was expecting 'pull branch' or something like that.
<bitdancer> what I want is to know what branch is going to be used if I omit the branch on any given command.
<bitdancer> so I'm still not sure what that will be in all cases, but I'm sure I'll learn soon enough.
<rockstar> bitdancer, bzr info will give you that information on a branch
#bzr 2010-05-29
<mtaylor> bzr: ERROR: bzrlib.errors.ShortReadvError: readv() read 72 bytes rather than 805 bytes at 0 for "edc52d2d94b242f1cd3a2ccac6e0dad5.tix"
<sili> Is there a clever way to show a diff of changes since the branch was created?
<sili> doing a diff against the parent branch works, but doesn't offer the results I want after the branch has already been merged, so I usually have to specify the revision it was branched at
<spiv> sili: bzr diff -rancestor::parent
<spiv> (If the parent branch is also the submit branch, then "bzr diff -r submit:" is a shorter way to do the same thing)
<sili> spiv: what does it mean if that doesn't show any diff?
<spiv> sili__: that there's no change in the tree contents between the revision you branched from and the current revision
<spiv> sili__: perhaps look at the output of "bzr missing --mine", or perhaps look at the locations listed in "bzr info" if that isn't what you expect
<spiv> If this is a branch intended for merging into another, perhaps see what 'bzr merge --preview YOUR_BRANCH' in a checkout/branch of the target branch is.
<sili__> hmmm
<damd> what is the difference between "bzr update" and "bzr pull"?
<damd> the former takes several megabytes more than the latter when performed on emacs trunk
<mtaylor> anybody have any idea what bzr: ERROR: bzrlib.errors.ShortReadvError: readv() read 72 bytes rather than 805 bytes at 0 for "edc52d2d94b242f1cd3a2ccac6e0dad5.tix" is about?
<mtaylor> oh - nevermind... wft?
<timClicks> noob q: is it possible to delay committing some changes to the next commit? I have changed two files and would like to spread the changes between two commits because they don't have much to do with each other
#bzr 2010-05-30
<nilg> accessing launchpad bzr server from China is nearly impossible, anyone knows how to fix that?
<beuno> timClicks, you can commit one of the files
<beuno> bzr commit FILENAME
<nilg> I found the solution: using http://code.launchpad.net/ instead of lp:, I don't know why it works now but it does, any idea why?
<fullermd> C-S: Hey.  Nice job on those new ports.  I'm not sure about the dependancies though; you're hardcoding the python version in a few places   :|
<lifeless> evening all
<shikhark> where can i get bzr 2.1.1?
<bialix> in which sense?
<bialix> on launchpad.net/bzr click on All downloads and scroll down to 2.1.1
<shikhark> ya, it isnt working...getting an error
<shikhark> gcc exits with status 1
<bialix> what OS?
<shikhark> ubuntu....never mind now, it installed :)
<shikhark> i was trying tar.gz initially, but i switched to the i386 deb file, it worked
<C-S> fullermd: Hi fullermd. Thanks for the feedback. Do we really hardcode it? I am not aware of that.
<C-S> fullermd: Right, I remember that I did that. But I posted new versions now. Should be fine.
<C-S> fullermd: By then way. Thanks for updating to bazaar 2.1.2
<fullermd> C-S: Well, we certainly shouldn't   :)
<fullermd> But I looked at the qbzr one; note the encoding of the py2.6 version in the name of the pygments/pyenchant paths.
<C-S> fullermd: let me check that quickly
<C-S> fullermd: you are right. I did not notice that one
<C-S> fullermd: do you have a quick suggestion?
<fullermd> Not offhand, no   :(
<C-S> fullermd: I am sure there is some placeholder. Have to check for that one.
<fullermd> May want to ask on ports@ or python@ (that latter exists, doesn't it?); I presume there's some solution.
<C-S> good point
<C-S> anyway, did you check the ports?
<fullermd> Or ask wen@; I notice he grabbed that PR.
<C-S> do they work?
<C-S> I'll do that
<fullermd> I didn't, no.  I don't really use any of those plugins, except maybe firing up qlog once in a while for kicks (and I use a branch of the plugin anyway, since I run bzr.dev)
<fullermd> 'course, having a port of subvertpy will make it much more likely I'll fiddle with bzr-svn sometime   8-}
<C-S> :-) anyway, thanks for telling me about the issue with the dependencies.
<lifeless> moin moin
<jelmer> 'morning lifeless
<lifeless> hey jelmer
<exarkun> Sometimes 'bzr version-info' hangs forever
<exarkun> This seems like a bug to me
<lifeless> it does
<lifeless> next time
<lifeless> ctrl-\ should drop you into pdb
<lifeless> and you can look at where you are
<exarkun> It's running on a buildslave
<lifeless> ah
<exarkun> I can tell it's in a read(4
<exarkun> Presumably the underlying tcp connection has flaked out and the read will never complete
<lifeless> possibly
<lifeless> please file a bug, to track the issue
<lifeless> and gather as much data as you can easily
<lifeless> I'm popping out to lunch now, or I'd discuss more with you.
#bzr 2011-05-23
<gour> morning
<gour> jelmer: i'd like to contribute to github project (cython) using bzr-git...forked repo, pulled it with bzr to my localhost, created new branch and dpushed it to github but it's not available there...tried another route...imported project at LP, pulled to my localhost, created new doc-branch and create 'bzr send --format=git' bundle and send, for testing, to upstream...is the 2nd route better/recommended over
<gour> the 1st one?
<sepidev> hi guys, I'm having trouble with bzr, I cannot connect to launchpad, I get this error:
<sepidev>  https://answers.launchpad.net/launchpad
<sepidev> sorry, this error:
<sepidev> bzr: ERROR: Connection error: curl connection error (couldn't connect to host)
<sepidev> on https://code.launchpad.net/~sikon/steadyflow/trunk/.bzr/smart
<AfC> sepidev: I assume you can use bzr to talk remotely to other things?
<sepidev> yes, but even when I type bzr lp-login I cannot connect to launchpad server!
<gour> wil lco-located branches become part of 2.4?
<sepidev> bzr: ERROR: Connection error: curl connection error (couldn't connect to host)
<sepidev> anyone?
<vila> bialix: never :)
<bialix> vila _o/
<bialix> never have I ever?
<vila> bialix: 3.2.2 :)
<AuroraBorealis> TIL bzr has a smart server
<bialix> vila: why not?
<vila> bialix: why ?
<bialix> vila: poolie said about bzr 3
<vila> errrr. 2.3.2 I meant
<AuroraBorealis> and today i learned there is almost no documentation for it
<bialix> so, in theory it will be... one day?
<bialix> vila: I know what you mean, I'm trying to make jokes from what you have written
<vila> oh crap, typo while explaining typo....
<vila> bialix: which I didn't realize until a few seconds ago :-}
<bialix> don't explain jokes... yeah
<bialix> there is too hot today, maybe my mind has started to melting
<bialix> definitely
<gour> vila: have you considered waf/bento for packaging win installer?
<bialix> gour: I'd prefer scons
<bialix> what is bento?
<vila> gour: I've never tried to package the windows installer myself... but you're already talking to a far knowledgeable person
<gour> bialix: http://cournape.github.com/Bento/
<gour> bialix: isn't scons much slower than waf?
<bialix> gour: it does not matter if it works
<gour> ...and, afaict, development is quite stalled
<vila> bialix: are we using scons ?
<bialix> vila: yes, I am
<gour> bialix: samba, ardour..are using waf...even heard that it's used by google with v8
<vila> bialix: in the installer toolchain ?
<bialix> vila, gour: currently windows installer is built with zc.buildout
<bialix> vila: no, for my own stuff
<vila> ok
<bialix> I'm unhappy with zc.buildout
<bialix> very unhappy
<bialix> I can't tell how much I'm unhappy
<gour> bialix: i see...i plan to use waf/bento for py+qt+cython project...it seems distutils2 won't address packaging (win & mac installers)
<bialix> gour: actually I'd like to try waf in action, just haven't enough time to learn it
<bialix> how waf will help you with packaging installer?
<gour> bialix: for standard things, pretty much everything is ready
<gour> bialix: that's duty of bento which can use was as build back-end
<bialix> I don't see there a real support for py2exe and creating installer with MSI or Inno Setup
<gour> and bento has (experimental) support for win msi & mac mpkg or how it's called
<bialix> maybe we talk about different installers?
<bialix> because pure python-based installers are not problem at all even with distutils1
<gour> bialix: https://github.com/cournape/Bento#readme
<bialix> gour: no metion of py2exe
<bialix> gour: this page bentomaker build_wininst talks about bentomaker build_wininst -> this is just plain python-based installer
<bialix> sorry this page http://cournape.github.com/Bento/
<gour> bialix: see http://cournape.github.com/Bento/html/TODO.html
<bialix> no py2exe either
<bialix> sorry, I hope that tool will grow into something really useful. I just don't see how it will help me right now
<bialix> sorry, no offense
 * bialix bbl
<gour> bialix: bento dev wrote me: "Both .exe and .mpkg installers have a preliminary implementation, but
<gour> they are not mature yet "
<vila> gour: I kind if agree with bialix, we already suffer delays, jumping on a preliminary implementation to release a *stable* installer doesn't sound like a good fit :-/
<vila> gour: now, if you wanted to try it for the next bzr beta release, that would be awesome
<gour> vila: of course, my suggestion is for 'tomorrow', not 'today'
<gour> vila: btw, are colocated branches going to appear in 2.4?
<vila> my crystal ball is still a bit blurry on this topic, but bzr-colo is highly recommended anyway
<gour> it's not killer-feature for me, but i remember i read somewhere that git/hg users were complaining that there is no support for it
<gour> for me, it's more important that LP gets support for wiki
<gour> bzr-colo plugin is useful today?
<bialix> gour: very much useful
<vila> I don't use myself but yes, from what I've heard it is very useful and used
<gour> despite of lacking wiki support, i believe i'll move from fossil to bzr & LP
<gour> difftools plugin is obsolete now?
<jam> jelmer: did you ever connect to the Windows ec2 instance? I figured I'd give a poke at building the windows installers, but I'm not able to connect to the ec2 machine.
<jam> nm, I'm in now
<bialix> jam: lp:bzr-windows-installers is not updated with bzr 2.3.3 and tbzr 0.6.3 yet
<jam> bialix: thanks for the heads up
<jam> I did see a location from you
<jam> though I have to get the machine up and running and current first
<bialix> I can't translate: "I did see a location from you"
<jam> bialix: you sent an email mentioning an LP: branch that you had updated the installers
<jam> or were trying to
<jam> I was planning on looking at it
<jam> once I got things up and running.
<bialix> jam: ok
<bialix> I'll update trunk then
<bialix> jam: that branch is planned for 2.4b2
<bialix> it does not have 2.3.3 yet
<jam> bialix: is there a separate branch for the 2.3 series?
<bialix> no
<jam> I thought that was the original intention, but ISTR gary was trying to put it into the same branch
<bialix> gary kept everything in trunk
<bialix> jam: wait a sec
<bialix> I'll push
<bialix> jam: done, versions were updated
<jam> bialix: you committed to trunk?
<bialix> yes
<bialix> jam: I can update my 2.4 branch if you'll build 2.4b2
<jam> bialix: Let me make sure I can build *something* first :)
<bialix> yes-yes, you're right
<bialix> I've pushed in the mean time anyway
<bialix> jam: if you will say after that what version of Windows SDK you have on ec2 it will be great
<jam> bialix: we have the full version of visual studio, so we don't need the sdk
<bialix> ah
<jam> naoki was building the installers using Express + and SDK
<jam> I thought it wsa 7
<bialix> good for you
<jam> was 7, but that was a while ago
<jam> AIUI, you only need it to build the 64-bit extension
<bialix> naoki has suggested using win7 sdk, but it requires vs2010, and I'm a little short in space on this machine
<jam> bialix: http://msdn.microsoft.com/en-us/windows/ff851942
<jam> it says the Win7 archive was released in Aug 2009
<jam> which predates vs 2010 (I would assume)
<jelmer> 'morning jam
<jelmer> jam: no, I've never used the EC2 instance
<jam> jelmer: I guess you have 6 more min :)
<jam> bialix: it is looking for "hhc" do you know what that is?
<jam> I probably have to at least add it to PATH
<bialix> hhc -- Html Help Compiler
<bialix> jam: http://www.microsoft.com/downloads/details.aspx?familyid=00535334-c8a6-452f-9aa0-d597d16580cc&displaylang=en htmlhelp.exe
<jam> bialix: yeah, it is already on the machine, but the code all assumes it is in PATH
<jam> and it certainly isn't for my user
<bialix> it should be in the PATH, installed to PF\HTML Help Workshop
 * jam doesn't really like updating PATH on windows unless I have to
 * bialix too
<jam> it needs C:\Python26\Scripts as well, for sphinx-build
<bialix> jam: make a batch wrapper?
<bialix> jam: make a batch wrapper for hhc
<bialix> for sphinx-build you can avoid adding scripts to path
<bialix> I'va managed to avoid it by copying 3 files of sphinx-build.* to my Utils directory that in path
<bialix> jam: C:\Utils>dir /b sphinx*
<bialix> sphinx-build-script.py
<bialix> sphinx-build.exe
<bialix> sphinx-build.exe.manifest
<bialix> that works
<bialix> batch wrapper for sphinx does not work
<jam> bialix: I also am thinking we should be updating our svn bindings at some point. We're using 1.6.6, and they're on 1.6.16
<jam> but since I still haven't finished building anything
<jam> I'll get that first
<jam> dang, I have bzr-2.3.3 installers, but I'd like to test them out first...
<jam> mgz: if you're around, I'd like to try to understand: https://code.launchpad.net/~gz/bzr/lazy_hook_test_cleanup_785054/+merge/61586
* jam 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: jelmer
<mgz> jam: I am now
<mgz> also, I don't know whether you saw in the log, I had some trouble getting the test case collection branch working against trunk
<jam> mgz: bzr merge --weave
<jam> I think the issue is that the code landed direct to trunk, multiple branches, so now there isn't a clear single ancestor
<mgz> weave did seem a little better, but still... not right
<mgz> if I do diff -r7900..7901 and diff -r7901..7902 they seem to be the inverse of each other
<mgz> *59
<LeoNerd> You do know, also, that  -r7900..7901  is better written  -c7901
<LeoNerd> I.e. the changeset introduced at -r7901
<mgz> it's even better written as the right revno
<mgz> :)
<LeoNerd> Well indeed
<mgz> but... -c5901 -c5902 seem to do and then undo the changes to some tests
<mgz> and not the _get_log removal which the second branch should have been
<mgz> which might have something to do with why merging the remainder now loses the main changes
<mgz> I think maybe the way I merged bzr.dev back into the branch earlier may have messed up your normal way of doing things jam?
<mgz> I'll reply on the review of the other branch in the mean time
<bigjools> I'm getting a ReadOnlyError when updating a checkout: https://bugs.launchpad.net/bzr/+bug/786980
<ubot5> Ubuntu bug 786980 in Bazaar "bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction" [Undecided,New]
<jam> mgz: if we split out 2 extra branches from yours, and then land both independently
<jam> both of those tips are in your ancestry
<jam> but both do not supersede eachother
<jam> its a known issue with splitting out and landing multiple feature branches
<mgz> okay, but that doesn't explain why I don't see the _get_log change on trunk when that branch landed
<mgz> the diff is an exact backout, not a backout plus a new set of changes
<mrevell> o!2o729ofourtwotwo
<mrevell> Damn, that's another password ruined
<mgz> bigjools: try `bzr up lp:lp-source-dependencies`?
<mgz> mrevell: that's an pretty strong password for nickserv :)
<mrevell> mgz, I s'ppose so :)
<bigjools> mgz: ok, that errors with: bzr: ERROR: No WorkingTree exists for "bzr+ssh://bazaar.launchpad.net/%2Bbranch/lp-source-dependencies/"
<mgz> whoops, my error, forgot the right spelling.
<mgz> use switch rather than update, I just wanted to see if the path returned changing to the ~branch form made any difference
<bigjools> mgz: the spelling is correct
<bigjools> mgz: ok that seems to be working ...
<mgz> it doesn't mean what I intended. I wanted you to try changing the branch to be based on the new URL, the command I gave you tells it to update that URL, not the cwd
<bigjools> did the branch urls change recently?
<mgz> bigjools: great. so, there's a bug somewhere with stacking or launchpad moves or... something
<bigjools> this was checked out ages ago
<mgz> that's what I'm guessing.
<bigjools> something :)
<bigjools> thanks muchly
<cheater__> hi!
<cheater__> how can i find out what diff was committed in a specific revno?
<jam> cheater__: 'bzr diff -c REVNO"
<cheater__> ah, -c
<cheater__> thanks a lot jam!
<millun> hey guys
<millun> i have a  little question. i've made a colocated repo on my localhost, pushed the branch to an FTP. i want the other guy to test my app. is it ok for him to just write "bzr checkout <dest_dir>" in a repo dir, then just keep executing "bzr update" in a destination dir?
<HelloWorld321> Is it possible to directly mount a git or bzr repository as a volume (in Linux or Windows)?  So that reading/writing to the repository is transparent?
<gour> HelloWorld321: i used bzr-git to fetch git repo and it works, but have problems with using github
<santagada> sidnei, hi :)
<sidnei> santagada, ohai!
<santagada> using bzr again
<sidnei> santagada, nice!
<santagada> not by choice, I'm working with openerp... but I'm liking it
<sidnei> that's... progress :)
<vanguard> how can I overwrite a commit --strict option?
<luks> --no-strict ?
<luks> (all boolean options can have a no- prefix)
<vanguard> luks: thanks!
#bzr 2011-05-24
<mwhudson> how do you resurrect files in bzr?
<lifeless> mwhudson: holy water
<lifeless> mwhudson: or, revert -r X Y
<mwhudson> ah right
<mwhudson> hm
<mwhudson> that gives "paths not versioned"
<lifeless> was Y in rev X ?
<mwhudson> yes
<mwhudson> ah
<mwhudson> no
<mwhudson> confusing myself with intermixed renames
<lifeless> this is a single valued answer
<mwhudson> lifeless: thanks
<lifeless> :)
<mwhudson> it was there, but not with the name "Y" :)
<lifeless> :)
<mwhudson> so it was revert a directory out of oblivion, delete some files, move some files out of the directory over previous files, remove directory again and commit
<mwhudson> i'm sure this sort of thing used to corrupt your dirstate occasionally :)
<lifeless> yeah
<lifeless> we should be beyond that
<mwhudson> seems like it
<lifeless> jams new stuff has the risk of reintroducing it, but like it was worth it for commit, it will be worth it for revert etc
<bignose> How do I spell âthe latest revision on branch fooâ as a revspec?
<AfC> bignose: -r branch:../path/to/branch ?
<bignose> AfC: okay. but how do I use the âlast:Nâ on that branch?
<AfC> bignose: no idea. Anytime I tried to use branch: it crashed. :/
<AfC> I'm Sure They've Fixed That Nowtm
<spiv> bignose: revno:-N:/path/to/branch
<AfC> ':' ?
<AfC> really?
<spiv> Which colon are you questioning?
<AfC> spiv: 2nd
<AfC> (not questioning. Is that shorthand for "the branch at path"?
<spiv> AfC: I'm not sure what you mean by shorthand; it's part of the syntax supported by the "revno:" revspec.
<lifeless> AfC: its short for 'the tip rev of the branch at path'
<AfC> lifeless: good to know! Thanks
<leo2007> In my branch, I have 2 extra revision(s) and are missing 10 revision(s).
<leo2007> What's the best way to sync the missing 10 revisions.
<spiv> Usually with "bzr merge"
<spiv> (followed by resolving any conflicts and committing)
<leo2007> Is it difficult to resolve conflicts?
<leo2007> I am mostly a git user.
<spiv> Depends on the conflicts :)
 * gour is moving (back) to bzr from fossil
<spiv> The conflicts are unlikely to be much different to the sort you'd get with git.
<leo2007> but after bzr merge, the extra 2 revisions will not be on top of the history, right?
<spiv> merge by itself doesn't do anything to history
<spiv> It's when you commit that a new revision is, well, committed to the history.
<leo2007> OK, I am doing 'b merge' now.
<spiv> If you commit a merge, the revision will have two parents (or more if you did multiple merges before committing).
<leo2007> 2 conflicts encountered.
<spiv> So both your 2 extra revisions and the other 10 previously missing revisions will be immediately connected off the new revision that is now the tip of your history.  "bzr qlog" (from qbzr) and "bzr log -n0" give you some ways to see that.
<leo2007> Now I edited the two conflicts and they seem to contain the intended changes.
<leo2007> What to do next?
<spiv> Use "bzr resolve" to inform bzr that the conflicts have been resolved, and commit.
<leo2007> I am screwed.
<spiv> What's up?
<leo2007> How can I go back to a previous status: 104334
<spiv> Do you mean undo the commit?  "bzr uncommit"
<kiranmurari> I'm trying push code to a branch created for my project... but bzr push always fails
<kiranmurari> bzr push --use-existing lp:~kiranmurari/proj_name/branch
<spiv> (And then possibly "bzr revert" as well, depending on what you want)
<spiv> kiranmurari: what's the error?
<kiranmurari> gives me..
<kiranmurari> ssh_exchange_identification: read: Connection reset by peer
<kiranmurari> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist
<spiv> kiranmurari: any other lines before that?
<kiranmurari> nothing
<awilkins> kiranmurari, Can you open just a normal SSH shell on that server (if you have the rights?)
<spiv> Then it's a firewall most likely.
<leo2007> spiv: after the merge, the first commit seems to contain all the changes from the missing 10 revisions: http://paste.pocoo.org/show/394134
<spiv> what happens if you try "telnet bazaar.launchpad.net 22"?
<spiv> kiranmurari: (regarding your pm), no, I really mean telnet
<kiranmurari> ohh ok
<spiv> I want to know if you get connection closed by peer even then
<kiranmurari> it doesn't succeed.. says connection closed by foreign host
<spiv> Or if you successfully get the SSH banner from that host.
<kiranmurari> i don't see the banner
<awilkins> You should see "SSH-2.0-Twisted"
<kiranmurari> is it my corporate FW blocking me....
<spiv> Ok, so it's a firewall blocking your access to bazaar.launchpad.net's SSH service
<leo2007> spiv: after uncommit, there are lots of changes in the work dir, is there a way to discard those changes too?
<awilkins> leo2007, `bzr revert`
<spiv> leo2007: "bzr revert", but why do you think that "bzr log -r -1" output is wrong?
<awilkins> leo2007, Those changes are the ones from the revisions you uncommitted
<kiranmurari> ohh.. need to talk to my sysadmin guys to give that access...
<kiranmurari> thx.. spiv
<leo2007> spiv: I am new to this so I am going to do it the stupidest way. Backout my commits and then sync and then reapply them.
<spiv> leo2007: Isn't what you want a branch that includes the changes from your 2 revisions combined with the changes from other 10 revisions?  With the original history of all those revisions intact?
<spiv> leo2007: if so, then the merge you did and committed should be exactly what you want.
<kiranmurari> spiv, thanks...
<spiv> Perhaps you're more used to rebasing rather than merging, and the bzr-rewrite plugin provides a rebase command, but if you just want to a) record the history of your changes and b) share your changes with others, then there's no need to rebase when a simple merge will do.
<spiv> kiranmurari: you're welcome
<spiv> leo2007: but I'm just guessing, because you haven't explained what your problem actually is :(
<spiv> Hi Riddell
<Riddell> morning
<spiv> I guess you're going to be my cue to be done for the day ;)
<spiv> Especially when the toddler's new trick is pulling his shirt over his face and then, entirely predictably, walking into things!
<spiv> Well, predictable if you're not a toddler at least.
<leo2007> spiv: I need to read up on bzr but I am only using it occasionally so I am not confident.
<gour> leo2007: what's your 'other' dvcs which you (mostly) use?
<leo2007> gour: mostly git.
<leo2007> gour: and mostly from emacs via magit.el.
<gour> leo2007: ineresting...i'm just switching from emacs to vim...and simply cannot grok git...used darcs for a long time, then monotone & fossil, but now i'm back to bzr which i find the most intuitive (after darcs) where i do not need to think about the tool, but just using it...fossil is nice idea due to integrated tracker, wiki, but let's hope there will be wiki at LP at some time
<leo2007> gour: Somehow git grows on me. I am most productive with it.
<gour> leo2007: good luck. ;) i believe my feet would be destroyed very soon :-)
<leo2007> I eventually get my 2 commits upstream.
<leo2007> spiv: many thanks for your help. Really appreciated.
<spiv> leo2007: you're welcome
<spiv> leo2007: FWIW, usually if upstream wants to incorporate your changes they just "bzr merge" from your branch.
<leo2007> spiv: usually they just ask me to commit directly.
<spiv> leo2007: ah, in that case you're upstream, so you can do the merge of your branch into the upstream branch yourself :)
<leo2007> spiv: yeah, but my repo setup might have some problems so I need to find time to fix it first. Hopefully tonight.
<leo2007> Have to go, run out of battery soon. Talk later.
<spiv> leo2007: good luck.  Feel free to ask in here for help if you get stuck; I'm done for the night but there should be plenty of other folk here that can help.
<leo2007> spiv: thanks a lot.
<leo2007> I will do so.
<Pegasus_RPG> hey spiv. Thought I'd come in here rather than clutter up the bug report with troubleshooting info. (referring to https://bugs.launchpad.net/bzr/+bug/772935 0
<ubot5> Ubuntu bug 772935 in Bazaar "ErrorFromSmartServer: Absent factory for StaticTuple" [High,Confirmed]
<spiv> Pegasus_RPG: I'm mostly not here atm, but try prefixing the URL with nosmart+
<Pegasus_RPG> k
<Pegasus_RPG> that seems to have helped. It's working for much longer now, thanks.
<cheater_> hi!
<cheater_> how can i remove a file from disk, without it getting removed from bzr?
<cheater_> is this possible?
<maxb> You want a file not not exist on disk, but that deletion to never be committed? Why?
<cheater_> i need to give access to this machine to someone else. i don't want them to be able to see the file - the guy is too stupid to know what bzr is, though
<soren> cheater_: Just delete it and "bzr revert" when you get the box back?
<cheater_> yeah but the thing is, it's just one of the checkouts i'm on. i want to be able to do "bzr ci" without having to cherry-pick the file
<cheater_> the files
<cheater_> and they get access to the pc all the time
<soren> Maybe you could "bzr ignore" it.
<soren> Not sure if that would work.
<cheater_> hmhmhm.
<maxb> It seems very wrong to me that you are trying to rely on the absence of this file from disk in the working tree as a form of security, yet are happy for the data to remain on disk inside the bazaar repository
<soren> Nope, doesn't work :(
<cheater_> maxb: exactly.
<maxb> So, don't do that.
<cheater_> maxb: thanks, i can also think for myself :-)
<cheater_> maxb: but i'll let you know when it's time to go potty
<cheater_> :p
<kiranmurari> i don't know what went wrong.... i'm unable to push code to launchpad
<kiranmurari> neither "bzr branch" nor "bzr checkout" succeed...
<kiranmurari> i doubted it to be a firewall issue... but from a different machine in the same network, i'm able to branch and checkout the code
<kiranmurari> does it have to do something with the SSH keys
<kiranmurari> i keep getting this error message... for both "bzr push" and "bzr branch"
<kiranmurari> ssh_exchange_identification: read: Connection reset by peer
<kiranmurari> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<kiranmurari> any help is appreciated...
<LeoNerd> Sounds like SSH is upset
<maxb> You should attempt to run "ssh your-launchpad-id@bazaar.launchpad.net" to test SSH connectivity outside of bazaar
<maxb> If working correctly it prints "No shells on server"
<kiranmurari> maxb: it says ssh_exchange_identification: read: Connection reset by peer
<maxb> I'm inclined to blame connectivity or firewalling within your network
<kiranmurari> but from a different machine in same network, i'm able "bzr branch"
<kiranmurari> on this machine even "bzr branch" doesn't work.. resulting in the same error
<ironcamel> anyone got bzr bisect installed?
<ironcamel> https://launchpad.net/bzr-bisect
<cr3> is there a way to be verbose about the ssh connection being attempted by bzr pull?
<soren> cr3: For bzr+ssh or for sftp?
<cr3> soren: bzr+ssh, I just ran ssh -vvv on the same host used by bzr which does the trick, I was wondering though if there might be a debug environment variable that might come in handy in the future
<spyzer> hello everyone, is there any method to resume an interrupted bzr checkout
<spyzer> please help
<spyzer> please i can't afford more downloading it costs me too much money :(
<spyzer> please help
<gour> spyzer: lightweight checkout?
<spyzer> gour is that a command
<gour> spyzer: bzr checkout --lightweight url...check help
<spyzer> ohhkk thanks a lot :)
<mgz> ...that could be exactly the wrong thing, unless he's running a very recent version
<mgz> bug 737234
<ubot5> Launchpad bug 737234 in Bazaar 2.3 "too much data transferred making a new stacked branch" [High,Fix released] https://launchpad.net/bugs/737234
<mgz> let's hope he had at least 2.3.2 :)
<gour> ahh, that was too much for me to know
<mgz> indeed, it was a reasonable answer otherwise.
<mgz> bug 116148 is also relevent.
<ubot5> Launchpad bug 116148 in Bazaar "bzr branch should be resumable if interrupted" [Wishlist,Confirmed] https://launchpad.net/bugs/116148
<gour> i wonder why after i decided to become serious with bzr (again), fossil shows some unexplainable problems like inability to launch ui for every repo i have
<mgz> it doesn't like your infidelity?
<gour> he he...or it's simply time to say goodbye, although not like zed shaw did :-)
<etenil> Hi there
<etenil> I'm programming a forge in python for bzr (with bzrlib), I've managed to retrieve the commits log for a project, but I get some Revision objects. Unfortunately, they don't seem to contain all information I want, like their revision ID or the date they were commited. I looked at the API reference, but it's quite overwhelming and I can't find what I need. Could someone point me in the right direction please?
<cody-somerville> How do I specify the revision before a revision?
<james_w> cody-somerville, before:
 * cody-somerville nods.
<cody-somerville> james_w, thanks.
<vila> mgz: ping, still around ? I lost track of your no-pseudo-cycles work but the test on windows won't be able to pass again until you land some parts of your patch no /
<vila> grrr
<vila> ?
<mgz> hey vila
<vila> mgz: hey !
<mgz> I'm a bit stuck at the moment as the trunk state seems unmergable with my branch
<vila> huh ? Nothing a good pitchfork can't fix no ?
<mgz> rev 5901 and rev 5902 seem to invert each other rather than being two bits of the branch split out
<mgz> if you know how to get bzr.dev back into a state I can merge into, that would be great
<vila> meh, better to prepare a branch that solve the issue and merge that
<vila> but bzr qlog is quite... clear about what happened no ?
<mgz> ...not to me?
<vila> it looks like jam merged your work twice with two variants the later merging an older version of your work...
<vila> so the result is that all of your work up to 'Clear extra lists with test instances in fork_for_tests' has already been merged with some amendments
<mgz> this is not in fact the case.
<mgz> the merges did not result in any code changing on trunk.
<vila> urgh, really ?
<mgz> and I don't know how to fix it.
<vila> wow,  bzr diff -r5900..5902
<vila> now that's censoring :)
<mgz> right.
<vila> weirdo, jam landed a revid:john@arbash-meinel.com-20110519185007-yzrct57glwjip8co *after* revid:john@arbash-meinel.com-20110519185931-9xcxj2ow2v1y4xvv
<vila> but the former was created *before* the later
<vila> mgz: did you discuss the issue with him ?
<mgz> I did, but I'm not sure he gathered that I was stuck unless something gets fixed.
<mgz> I need to update a few things, so I think I take the superceding revision off my branch, continue working, then worry about what's needed to get this landed later.
<vila> mgz: I think showing him that `bzr diff -r5900.5902` outputs *nothing* should give him a hint that something went wrong
<jam> mgz: can you link the branches that are an issue?
<jam> mgz: I can probably just give you a branch tip
<jam> vila: I landed the one after the former, because the first landed had a test fix, that the other one needed because it removed _get_log
<jam> but it is possible that ones diff confused things
<mgz> jam: lp:bzr doesn't contain any of the changesets from lp:~gz/bzr/cleanup_testcases_by_collection_613247
<mgz> and if I now try to merge lp:~gz/bzr/cleanup_testcases_by_collection_613247 into lp:bzr no changes from bzrlib/tests/__init__.py are included
<vila> jam: but have a look at `bzr diff -r5900.5902', it outputs nothing
<vila> jam: and if the later needed the former shouldn't it be based on it ?
<jam> vila: I determined it ad-hoc after the branches had been created.
<vila> jam: but how do you explain the empty diff ?
<jam> vila: that confuses me. I could see how one would supersede the other, and revert some content, but not how it would revert itself
<jam> perhaps the criss-cross got things really confused, and both sides saw the other side revert its change..
<vila> jam: indeed, I'm sure you wanted to land *something*
<jam> I can see how it could have happened
<whitley> I'm about to use bzr rebase to burn out some bad (as in massive, binary "nuke 'em from orbit") commits from old history on a purely private repo.
<whitley> With the current rebase UI, it looks like I'll have to run rebase roughly once for each contiguous span of bad commits... is there a more straightforward way than re-running rebase (ala git rebase --interactive, for example)?
<AuroraBorealis> i have no idea how rebase works, sowwy :<
<lamont> oh hai.
<lamont> http://paste.ubuntu.com/612467/  <--  wtf?
<lamont> hardy with bzr 2.3.1-0.0.ISPATCHED.8.04
<lamont> the patch, specifically, is to do a bzr whoami --branch if /etc/ doesn't already know who it is.
<lamont> in postinst
<lamont> this machine alone in my experience of hating bzr with this much passion
<lamont> purging and reinstalling bzr and python-bzrlib has no effect
<lamont> lifeless: ^^ when you see that
<KombuchaKip> How do I commit just locally for now, and not to my launchpad account?
<KombuchaKip> nm, --local is what I need, but what is a "bound branch"
<lifeless> lamont: fun
<lifeless> KombuchaKip: if you have a local branch, just commit and don't push
<lifeless> KombuchaKip: if you started with 'bzr checkout' then you have a bound branch
<lamont> lifeless: I'll happily delve into wtf happend on that box with you
<KombuchaKip> lifeless: Right, so how do I make it so when I commit, it just goes local for now?
<lamont> all I know history-wise is "it ain't happy now"
<lifeless> lamont: File "/usr/lib/python2.5/site-packages/bzrlib/osutils.py", line 972, in failed_to_load_extension
<lifeless> lamont: I think you've found a regression
<lifeless> lamont: could you file a bug ?
<lifeless> KombuchaKip: did you start with 'bzr checkout' ?
<KombuchaKip> lifeless: How do I know what a branch is "plugged into".
<lifeless> KombuchaKip: or 'bzr branch' ?
<lifeless> KombuchaKip: 'bzr info
<KombuchaKip> lifeless: Yes, I started with a checkout.
<lifeless> '
<KombuchaKip> lifeless: Ok, so now I just want to commit local for now. When I commit, what happens to the server's revision numbers when I finally plug back into the server's branch on LP?
<lifeless> KombuchaKip: http://doc.bazaar.canonical.com/bzr.2.3/en/user-guide/using_checkouts.html may be helpful
<KombuchaKip> lifeless: Thank you.
<lifeless> KombuchaKip: if noone use has committed to the server, then your local ones will be used
<KombuchaKip> lifeless: I'm reading the guide now, but still curious what happens to revision numbers.
<lifeless> KombuchaKip: if someone else has committed, you'll need to do a bzr update; bzr commit - and their revision numbers will be used.
<KombuchaKip> lifeless: Right. So if I make 5 local commits and server is at r6, after I rebind, server will be at r11?
<lifeless> once you push yes
<KombuchaKip> lifeless: Can you explain the difference between push and commit?
<KombuchaKip> lifeless: I still don't get it.
<lifeless> so commit creates a new commit object
<lifeless> push shoves commit objects between branches
<lifeless> a 'checkout' creates a bound branch which is a regular branch that has an automatic push to the other branch when a commit is done
<AuroraBorealis> checkout also requires an internet connection.
<AuroraBorealis> which sux.
<KombuchaKip> lifeless: Right. So when you checkout, a commit and push are the same thing. A commit implies a push.
<AuroraBorealis> or connection to the branch you checked out from :o
<KombuchaKip> lifeless: Ok, I think I totally understand this bind / unbind / commit / push stuff now. Thanks
 * KombuchaKip jumps and clicks his heels at the epiphany
<AuroraBorealis> so if you have a branch
<AuroraBorealis> and you kinda make a 'fork' of that branch and do stuff so you don't fuck up the original one, what happens if the original one updates
<KombuchaKip> You really don't understand bzr until you've had to do something random like actually take your work on the road without a connection and where you have more than one machine you need to do something in private on.
<AuroraBorealis> does the 'fork' have to update too?
<KombuchaKip> AuroraBorealis: I think you don't have to deal with that until you push back into the main branch.
<KombuchaKip> AuroraBorealis: And even then, you should be prompted to merge, I believe.
<AuroraBorealis> yeah.
<AuroraBorealis> ive never done multiple branches / merges before
<KombuchaKip> AuroraBorealis: Me neither, just learning now.
<AuroraBorealis> woo and yay!
#bzr 2011-05-25
<ls3_> Hello. If a branch diverges, all I need to do a bzr merge; bzr commit; and accept the commit, right? That applies changes to my local setup only?
<ls3_> Too scared to accept the commit because it's for work :)
<AuroraBorealis> backup the branches before you do it :o
<ls3_> It's just one completely unrelated file and my unrelated file.. Last time it happened I just checked out the branch and re-applied my change. But would like to know the correct way
<AuroraBorealis> that seems right
<AuroraBorealis> just merge them
<KombuchaKip> What are the last two numbers in this? Stage:Fetching revisions:Inserti.. 6664/961
<AuroraBorealis> probably 'chunks'  of data or something
<KombuchaKip> AuroraBorealis: Yeah, just not sure what the units are.
<lifeless> objects
<AuroraBorealis> SERIES OF TUBES
<KombuchaKip> lifeless: So why is the numerator larger than the denominator?
<lifeless> KombuchaKip: its not a fraction
<KombuchaKip> lifeless: What's it mean?
<AuroraBorealis> yeah haha
<AuroraBorealis> seems like random mnumbers
<lifeless> total-needed / received[or sent if pushing]
<KombuchaKip> lifeless: Shouldn't they have flipped it to make it more intuitive?
<lifeless> KombuchaKip: feel free to file a bug
<KombuchaKip> lifeless: heh
<KombuchaKip> lifeless: It's not really important.
<lifeless> sure, its still changable though :)
<AuroraBorealis> yeah i feel like they should add units at least
<KombuchaKip> mm
<fullermd> Actually, I think the units are there, sorta.  There's in the continuation of "Inserti...".
<fullermd> All you need is a 300 char wide term.
<_thumper_> poolie: ping
<bignose> I have a branch âbarâ branched from âtrunkâ. no additional revisions have yet been committed to âbarâ.
<bignose> now I realise that âtrunkâ needs some more revisions from upstream; âcd ../trunk/ && bzr updateâ
<bignose> at this point, is there a difference between:
<bignose> âcd ../ && rm -r bar/ && bzr branch trunk/ bar/â
<bignose> âcd ../bar/ && bzr pull ../trunk/â
<spiv> No.
<AuroraBorealis> nope.
<bignose> okay. so at what point, and how, does âbarâ have its own history?
<AuroraBorealis> i would think bar would have its own history.
<AuroraBorealis> you updated trunk but bar didn't recieve that update
<AuroraBorealis> so trunk and bar are the same up to the point where you branched it
<spiv> Define "own"?  It has its own history, it just happens to (currently) be identical to trunk's.
<AuroraBorealis> except for the latest update
<bignose> so if âbarâ gains additional revisions, then âtrunkâ merges from âbarâ
<bignose> at that point âbarâ and âtrunkâ will contain the same revisions but different history, yes?
<spiv> (Where "currently" refers to "after you 'bzr pull' as described above.  Before that it obviously has its own history that happens to be a subset of current trunk/upstream.)
<bignose> (âtrunkâ will of course contain a merge commit)
<AuroraBorealis> if you commit anything to bar, trunk wont get it unless you merge it back into trunk
<spiv> Right, so trunk contains all the same revisions *plus* that one merge revision.
<AuroraBorealis> yeah, once you merge it back
<AuroraBorealis> it will gain all the revisions that bar had
<bignose> it contains them. is that identical to saying they have the same history? I thought not.
<AuroraBorealis> and then if you visualize it you will see the bar branch diverting
<AuroraBorealis> to the side then merging back
<bignose> I almost never use âbzr pullâ and I'm trying to understand what effect it has, in terms of the above story.
<spiv> bignose: no, I'd say the history is different, but not in an important way for many purposes.  (Different people have different expectations about the word "history", hence my qualified answer)
<AuroraBorealis> pull clones
<spiv> bignose: ah, now for 'bzr pull' I can give an unqualified answer :)
<spiv> bignose: it never generates a new revision, whereas merge+commit does
<AuroraBorealis> cause pull just clones whatever you are pulling
<spiv> bignose: its primary use case is for when you have a branch you are maintaining as a mirror of another branch.
<bignose> okay, so what will it do in the story above? i.e., âcd ../bar/ && bzr pullâ will do what to the history?
<AuroraBorealis> it will mirror the history of whatever you are pulling
<bignose> and is it different if âbarâ is already divergent from âtrunkâ?
<AuroraBorealis> bar will still be diverged
<AuroraBorealis> wont effect it
<spiv> bignose: a) check that bar and trunk haven't diverged (if they have it stops with an error)
<bignose> spiv: so if âtrunkâ has merged all revisions from âbarâ, then âbarâ still won't be able to pull from âtrunkâ?
<spiv> bignose: b) add the newer revisions from trunk to bar (copy the missing revs into its repository, then set bar's tip to trunk's tip)
<bignose> another way of asking: is a branch still âdiverged from trunkî if trunk has merged from that other branch?
<AuroraBorealis> they are different but they have the same revisions
<spiv> bignose: actually, it can, that case isn't divergence: trunk's tip includes all of bar's tip's history.
<AuroraBorealis> if oyu visualize it, it will be a different line
<AuroraBorealis> like when you first branched it, bar will go off to the side, when you merge it, the lines will merge
<bignose> AuroraBorealis: so you're saying âpullâ *doesn't* mirror the history?
<spiv> bignose: but that pull would change the mainline revnos on bar.  If you have append_revisions_only set in the branch.conf that would disallow that pull.
<AuroraBorealis> i dunno what pull would do if you have already made changes. i would just update :>
<bignose> AuroraBorealis: neither âtrunkâ nor âbarâ are checkous from each other, so update would not transfer anything between them.
<AuroraBorealis> no but trunk is a checkout from like upstream right
<AuroraBorealis> if you made changes in trunk, then tried pulling from upstream again, i dunno what would happen
<AuroraBorealis> i thought pull and push make it an exact mirror of whatever.
<spiv> bignose: perhaps I should have phrased step a as: a) check all of bar's history is included in trunk.
<bignose> AuroraBorealis: that contradicts your âbar will still be diverged, wont effect itâ
<bignose> or I'm not understanding you.
<AuroraBorealis> uhhh
<AuroraBorealis> you branch from upstream
<bignose> no
<bignose> trunk is bound to upstream
<bignose> not branched
<AuroraBorealis> well
<AuroraBorealis> it can be branched from upstream and bound
<AuroraBorealis> so same thing
<AuroraBorealis> so anyway, trunk is bound to upstream
<AuroraBorealis> you branch trunk
<AuroraBorealis> so now trunk upstream and bar are the same
<AuroraBorealis> but they are 3 seperate branches
<spiv> bignose: it's pretty easy to make a couple of toy branches and experiment with what happens.
<AuroraBorealis> then you start making changes to bar
<AuroraBorealis> then it becomes its own thing
<AuroraBorealis> and then you merge it back into trunk
<spiv> bignose: although I hope my description is adequately clear.
<AuroraBorealis> i dont know if they are the SAME now, but trunk will now have the revisions of bar
<AuroraBorealis> and if you visualize it in bazaar explorer, you will see where you branched and created bar, and when bar merged back into trunk
<spiv> Although I see I've basically just restated the contents of "bzr help pull" :)
<AuroraBorealis> xD
<spiv> As far as "the same": if two branches have the same last revision, then by definition they have the same revision history.
<AuroraBorealis> so here is another question :o
<bignose> spiv: I think your explanation is clear
<AuroraBorealis> taken his example, you have a trunk branch, you branch it off into bar, do stuff to bar then merge it back into trunk
<AuroraBorealis> can you just delete bar now?
<spiv> AuroraBorealis: you can always delete it ;)
<bignose> AuroraBorealis: I think perhaps you're implying âtheir revisions are the sameâ is somehow an answer to my question; it's not
<AuroraBorealis> of course.
<spiv> AuroraBorealis: but in that case you can delete it and not lose any revision history
<AuroraBorealis> but after you merge it you can get rid of the second branch and trunk will have everything?
<AuroraBorealis> kay
<bignose> I know where the revisions go; I'm asking about how *else* the branches can differ :-)
<bignose> and I think the answer is âtheir histories can differ even if they contain the same revisionsâ
<spiv> AuroraBorealis: the only thing you lose is the association of "branch bar is at revision R"
<AuroraBorealis> i'm confused now :<
<spiv> bignose: no
<bignose> and (spiv, here's the crucial point) a âpullâ or âpushâ will *alter* the history to be identical to the other branch.
<bignose> yes?
<spiv> bignose: a branch's history is (in modern formats) defined by the last revision
<spiv> bignose: because revisions reference their list of parents, that single revision transitively includes the whole history.  And because revisions are immutable and globally unique that means if two branches have the same last revision, they have the same history.
<bignose> umkay.
<bignose> so my âalter the history to be identical to the other branchâ is reduced to just âmove the tipâ
<bignose> yes?
<spiv> bignose: so, âtheir histories can differ even if they contain the same revisionsâ is not true unless you mean something different by one or more of those words than what we usually mean
<spiv> bignose: yes.  And, without using --overwrite, push and pull only allow the tip to move to include a superset of what's already there.
<bignose> I'm not clear on the DAG new world order :-)  so I'm trying to fit it into my learned-DVCS-from-GNU-Arch brain.
<spiv> bignose: and with append_revisions_only=True set in the config, it also restricts the move of tip to only allow moves that keep existing left-hand revisions where they are (i.e. so mainline revnos are preserved)
<spiv> bignose: well, Arch had an essentially similar DAG :)
<spiv> AuroraBorealis: to clarify, a branch is basically just: a pointer to its last revision, plus some other bits (maybe some tags, maybe some branch.conf settings, maybe a colocated repository for holding a copy of the actual revision data)
<AuroraBorealis> so branches are independent of the actual revisions?
<spiv> By âactual revisionsâ you mean the bytes on disk holding the commit messages and changes to files, that sort of stuff?  If so, yes.
<AuroraBorealis> ah ok
<AuroraBorealis> so like if you merge a branch to a trunk branch, you can delete the branch you merged because you don't need that 'pointer' anymore, and the revision data is still there
<spiv> Look up the docs on shared repositories (e.g. bzr init-repo).  âSharedâ in the sense of shared between multiple branches.  We call the bit that holds the actual revisions a repository.
<spiv> AuroraBorealis: Right, it'll be copied into trunk's repository (assuming it's not sharing one with the other branch, in which case it'd already have them of course).
<AuroraBorealis> kay
<spiv> AuroraBorealis: so you'll still be able to examine old revisions with bzr explorer etc.
<AuroraBorealis> cool. just been using bzr linerally so far =P
<AuroraBorealis> haven't done any branching stuffs
<bignose> AuroraBorealis: I'll note that when listening to future advice from you about operations between branches :-)
<bignose> (seriously, thank you both for your help)
<AuroraBorealis> ive read the docs just haven't done any of it :>
<vila> hi guys !
<AuroraBorealis> greetings.
<jam> morning vila
<vila> hey jam !
<vila> jam: thanks for the windows installers !!
<jam> vila: well, not done yet. Looks like the last round lost paramiko ...
<vila> jam: and the bzr.dev stitching for mgz
<jam> *sigh*
<jam> thats why I was happy to offload the installers
<vila> I know
<vila> an installer specific test suite would be nice :-}
<jam> vila: yeah, I tried spinning up a base Windows vm, and seeing if it would install into that
<jam> but ran into troubles trying to get the admin password of a new install
<jam> I think I figured it out today
<jam> so I'll try that again
<vila> I thought jelmer said he was on vacations this week but he was still active yesterday and the day before...
<vila> he's not there anymore so maybe I got that right though
<jam> vila: I remember *poolie* saying he was away
<jam> not jelmer, but certainly could be
<jam> and not all of us are particularly good at staying away during "vacation" :)
<vila> hehe
<vila> right, poolie is on a bike AIUI, hard to have useful irc discussions from there ;)
<jam> vila: he has a smart phone
<vila> yeah, but one hand to hold the phone plus one hand to swipe/type don't leave enough hands to drive :)
<jam> vila: that's why you swype with your thumb
<jam> come-on-man get it together
<jam> and plus, don't you steer with your knees anyway?
<vila> hehe
 * maxb has written a small essay about various UDD failures of the NoSuchTag class on https://bugs.launchpad.net/udd/+bug/494481 - thoughts on how best to proceeed from there welcome
<ubot5> Ubuntu bug 494481 in Ubuntu Distributed Development "Too easy for people to not use merge-upstream" [High,Triaged]
<jam> vila: do you still want to do the standup today?
<jam> we can just chat in IRC if that will be easier
<vila> either is fine by me, spiv ?
<Riddell> good morning Bazaars
<spiv> vila: hi, unfortunately I need to skip it this week (I've got to go pick up V)
<jam> spiv: have a nice evening, then
<vila> spiv: no worries, say hi to V ;)
<elmo> are bzr commits atomic?
<elmo> i.e. if I rsync bzr trees around and happen to catch one mid-commit, what happens?  time/space implosion?
<AuroraBorealis> time space implosion, definitely.
<lifeless> so they are atomic, but not safe for rsync
<lifeless> elmo: because rsync isn't atomic
<elmo> well
<elmo> bother
<lifeless> elmo: more precisely the bzr commit does one action to make the commit visible and all its actions leading up to that are safe to be lost
<AuroraBorealis> well why do you need rsync
<AuroraBorealis> use bzr itself to sync itself between locations
<elmo> we are at the moment
<elmo> but we're looking at going from 3 trees to 25 trees
<lifeless> elmo: the problem is that rsync doesn't guarantee that it get either all / none of those changes, and can thus either grab the core metadata file without new referenced files
<elmo> and I'm worried about the speed of bzr pulling 25 trees over http
<elmo> when most are no change
<elmo> (we pull these every minute)
<AuroraBorealis> o.o
<lifeless> elmo: are they related tree or totally different ?
<elmo> (I haven't done any benchmarks, my worried may be misplaced)
<lifeless> elmo: anyhow, if they are mostly no-change, I suggest benching
<elmo> lifeless: very much related - I suspect you're going to tell me to use LWC
<lifeless> I'd expect ~0.7seconds each
<lifeless> elmo: LWC ?
<elmo> I'm making terms up - too tired; the light weight host lots of branches cheaply thing
<lifeless> well you could
<elmo> host lots of related branches, that is
<AuroraBorealis> light weight checkout
<lifeless> but in-dc, the 5 http requests to do a plain-http no-change pull should be pretty fast
<elmo> lifeless: hmm, ok
<lifeless> that is root format, repo format, branch format, branch last-revision, done
<elmo>         Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.35
<elmo> ok, I should probably have done that first ;-)
<soren> *chuckle*
<lifeless> hmm, a little slow
<lifeless> :P
 * soren prefers "thorough"
<vila> maxb: why is python 2.6.6-*3* required for bzr on maverick ? Or where do I find that ?
<vila> maxb: hmm, apt-get build-dep bzr would be more precise
<maxb> vila: In which package version exactly are you seeing this?
<vila> maxb: sorry, the stable ppa one
<maxb> 2.6.6-3 is the version of python-defaults in which dh_python2 was first considered ready for general use
<maxb> It is thus the recommended Build-Depends for a package utilising dh_python2
<vila> and this isn't blocking the package build ?
<vila> maxb: note that it's not blocking me to install a chroot but it seems weird
<maxb> No, see https://launchpad.net/~bzr/+archive/builddeps/+packages
<vila> maxb: Ha !
<vila> So I need to add this ppa to my chroots then right ?
<htorque> hello everyone! what happened to bzr bisect? i remember installing it using apt-get some time ago, but i cannot find it anymore
<vila> maxb: almost, I got: dpkg: error processing /var/cache/apt/archives/python-backport-helper_1_all.deb (--unpack):
<vila>  trying to overwrite '/usr/share/perl5/Debian/Debhelper/Sequence/python2.pm', which is also in package python 2.6.6-2ubuntu2
<maxb> Huh, guess it works fine in a clean chroot because the older python is never installed
<vila> ha, ok, I can do that :)
<vila> maxb: but you confirm I should add this ppa right ?
<maxb> Depends, what are you trying to do?
<vila> maxb: build a chroot where I can run the test suite
<vila> I needed to add the bzr/ppa to get python-testtools
<maxb> Then, no, I don't think you should be needing any of that stuff - you should only need python-backport-helper if you are trying to redo the debian package build as the ppa does it
<maxb> Oh, wait, you're doing "apt-get build-dep bzr" with the bzr/ppa PPA involved?
<maxb> Right, that'll give you false builddeps that you don't really want
<vila> yes, that's the trigger
<maxb> They're special, and there just to facilitate PPA backports of unmodified Debian sources
<vila> so ? Should I just ignore the the Build-Depends error for 'apt-get build-dep bzr' ?
<maxb> I think you should not use 'apt-get build-dep bzr'
<vila> :-/
<vila> what should I use then ?
<maxb> apt-get install some list of packages
<vila> makes my life harder, but anyway, where will I find an up-to-date python-testtools ?
<maxb> The Build-Depends header in the package is a reasonable guide, but you only want the upstream packages, not the debian package building infrastructure packages
<lifeless> maxb: breaking apt-get build-dep bzr seems really unpleasant
<maxb> There's an up to date python-testtools in the bzr/ppa
<vila> hmm, so I keep the bzr-ppa and just install the dependencies without mentioning the additional constraints on the versions (like build-dep does) ?
<maxb> lifeless: It's not broken, per se. Those are the packages you need to build the bzr source package in the PPA. But vila is trying to build a testsuite chroot, so only needs stuff to do with the upstream build system
<vila> maxb: well, if I could use it to build the packages for the paa I wouldn't mind you know ;)
<maxb> OK, so to recap:
<maxb> The ~bzr PPAs use a bit of interesting hackery to permit no-source-change backports of unmodified Debian source packages even to distroseries that do not have dh_python2
<maxb> This saves a lot of work in maintaining small source modifications to every plugin package
<maxb> I sent an email to the bazaar mailing list explaining some more of the details a while ago
<maxb> You probably don't want the modified packages that facilitate this build approach in any other scenario that the PPA build itself, which is why they are in the bzr/builddeps PPA, which is not intended for use outside of special build environments
<vila> right, so I'll try to re-recreate from scratch installing bzr and python-testtools with the bzr/ppa but without bzr/builddeps and let you know
<vila> but I'll probably come back later (not today) to the point where I want to also use the same chroots to test ppa builds...
<vila> maxb: I'm fine with interesting hackery as long as it doesn't blow up at the most inconvenient time ;) So it may be worth investigating the issue anyway no ? Unless you already know it's too much work
<maxb> I'm not entirely convinced there *is* an issue
<vila> maxb: hehe, there is at least one: *I* don't understand why I can't just use 'apt-get build-dep bzr' (I mean, I understand it doesn't work, but not the fine points nor whether this could be addressed to make it work for me ;)
<vila> maxb: chroot rebuilt from scratch, seems to be working
<vila> maxb: so thanks for that already ;)
<maxb> I think the process should be:
<maxb> 1) Create chroot
<maxb> 2) Add bzr/ppa to sources.list
<maxb> 3) apt-get install python-{docutils,lzma,medusa,meliae,subunit,testtools}
<maxb> done
<maxb> Oh, python-dev too
<vila> hmm, bzr python-testtools seemed enough (so far)
<maxb> If we need something more organized, we should probably use bzr-landing-dependencies
<vila> mwhahahah: make: command not found :)
<maxb> apt-get install build-essential
<vila> maxb: how come I didn't need that for the natty chroot ?
<vila> maxb: and how could I find why a package has been installed /
<vila> ?
<maxb> Did use use debootstrap --variant=buildd on natty but not maverick?
<vila> nope, no variant at all
<maxb> There's no way to find out why a package was installed. You can ask aptitude what dependencies are currently keeping it installed. aptitude why pkgname
<vila> debhelper, triggered by the apt-get build-dep bzr in the natty chroot (where it worked)
<maxb> right - well, there's no particular reason why you would want debhelper installed in a babune chroot afaik
<vila> well, I just installed aptitude so I'm not that strict about keeping them as minimal as possible
<vila> jam: I just saw python-roman being installed, didn't you encounter a related issue on windows ? (As in a missing file which may be exactly what this package provides)
<jam> vila: docutils no longer provides roman, you install it separately.
<jam> I filed a bug against sphinx and they pointed me in that direction
<jam> the real bug is that docutils should depend on roman, or sphinx should
<vila> oh, right, it's a python-docutils dep here
<vila> i.e. on maverick (and natty too)
<didrocks> hey
<didrocks> I have a very stupid questionâ¦ is it possible to have some kind of graphical file history (like bzr visualise), but just for one file?
<vila> didrocks: try bzr qblame
<vila> didrocks: oh wait, hmm, nothing purely gnome (before you mention it ;)
<didrocks> vila: ok, I'll install the qt bindings then
<didrocks> well, no worry, I can install them :-)
<vila> didrocks: note that gary is very keen about sharing code between qbzr and bzr-gtk so we should get there at one point
<maxb> "bzr qlog filename" works
<didrocks> vila: maxb: excellent, will use qbzr waiting for the gnome equivalent if gary wants to work on it :-)
<didrocks> vila: maxb: thanks!
<vila> maxb: wow... they never stop to surprise me ;)
<didrocks> yeah, bzr qlog was exactly what I was looking for :)
<vila> didrocks: so qblame will display the same graph history than qlog <file> but only it (which may be exactly what you wanted)
<didrocks> vila: you mean, only history where there is still a line from a displayed revision?
<vila> the so-called per-file graph
<didrocks> but bzr qlog will show me the full history of the file, even if the revision is not present anymore at all (there is no more line from that revision remaining)
<didrocks> well, some kind of it, yeah :-)
<vila> qblame shows you that, below the annotations
<vila> bah, it's hard to describe a gui :)
<didrocks> vila: ok, so it's the full per-file graph! perfect then :-)
<didrocks> right, it's not that easy to describe
<didrocks> thanks
<Riddell> what's the machine called that does the UDD imports?  I need to file the "install xz" rt ticket
<vila> jubany
<Riddell> vila: is there somewhere specific I need to tell them to install it?  like in a chroot?
<maxb> Riddell: You might want to wait on filing that RT.
<Riddell> uh oh
<maxb> The importer codebase is sadly lacking in XZ support.
<maxb> We might want to check that it won't do something stupid if the tooling is present
<Riddell> maxb: is it specific to the importer?  does it just use dpkg-source -x ?
<maxb> Ish. There's some interesting code in bzr-builddeb import_dsc.py (I think) that needs fixing
<vila> Riddell: no chroot there (bbiab, lunch time)
<maxb> So, I'm a bit annoyed by the volume of Launchpad code review email that ~bzr gets
<maxb> I'm contemplating sending an email to bazaar@ suggesting that ~bzr and ~bzr-core be unsubscribe from all branches
<maxb> Does that sound silly to anyone?
<Riddell> by Launchpad code review e-mail you mean merge requests for bzr?
<maxb> yes
<maxb> (and all comments on all merge proposals)
<Riddell> I seem to remember we had a conversation on Friday about unsubscribing ~bzr from that and having people just subscribe themselves
<maxb> That sounds like a sensible arrangement to me
<vila> didn't lp provides a mean to unsubscribe from such inherited subscriptions ?
<maxb> I thought it did, but it doesn't seem to be working. And, in any case, I'm not convinced that it makes sense to email everyone about everything by default.
<maxb> Well, it seems sufficiently plausible that it's worth me sending a proposal email.
<lamont> lifeless: bug 788072
<ubot5> Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Undecided,New] https://launchpad.net/bugs/788072
<vila> lamont: eeerk, sounds like a weird packaging issue, there is no way we can even run tests without bzrlib.trace and we run the tests while building the package AFAIK (slight doubt for 2.3 but I'm pretty sure we started to do that for 2.2)
<lamont> vila: and it's only on that one machine
<lamont> personally, I'm more interested in making it stop doing that
<lamont> than in actually isolating the bug
<lamont> purging and reinstalling bzr and python-bzrlib does nothing
<vila> wow
<james_w> circular import issue?
<vila> let's try to achieve the former (which should give us some data to fix the bug anyway)
<vila> lamont: can you try 'bzr -Derror <whatever command you used>' to get a pdb prompt ?
<vila> james_w: occurring on a single machine ?
<james_w> my guess is some other package in the namespace messing it up on that machine
<vila> lamont: oh, failed_to_load_extension in the traceback
<lamont> bzr -Derror help
<lamont> Traceback (most recent call last):
<lamont>   File "/usr/bin/bzr", line 102, in <module>
<lamont>     import bzrlib
<vila> ok, trying to load bzrlib._chunks_to_lines_pyx, so you have two issues, the root one being that we don't find the extension
<vila> lamont: the missing file is therefore  bzrlib/_chunks_to_lines_pyx.so under... wherever bzr has been installed
<lamont> find /usr -name _chunks_to_lines_pyx.so
<lamont> /usr/lib/python-support/python-bzrlib/python2.5/bzrlib/_chunks_to_lines_pyx.so
<lamont> /usr/lib/python-support/python-bzrlib/python2.4/bzrlib/_chunks_to_lines_pyx.so
<vila> lamont: but your traceback says usr/lib/python2.5/site-packages/bzrlib/__init__.py
<vila> missing/broken symlinks ?
<lamont> interestingly, the same 2 files are the only output on a working machine
<vila> lamont: any symlink in /s usr/lib/python2.5/site-packages/bzrlib ? (or in any sub path) ?
<vila> grr
<vila> lamont: any symlink in /usr/lib/python2.5/site-packages/bzrlib ? (or in any sub path) ?
<lamont> find /usr/lib/python2.5/site-packages/bzrlib/| wc -l
<lamont> ^^ 33 lines where broken, 111 where working
<lamont> sounds like a smoking gun
<vila> wow, smoking shotgun even
<lamont> both machines are current on their packagelist
 * vila scratches head
<vila> lamont: my local hardy uses 2.3.3 and python-bzrlib is installed under s usr/lib/python2.5/site-packages/bzrlib there
<vila> there is an almost empty /usr/lib/python2.5/site-packages/bzrlib containing only an empty benchmarks dir
<caravel> Hello everybody
<vila> lamont: that seems to rules out bzr itself (and points to a packaging issue) no ? (Happy to continue to help otherwise)
<vila> caravel: _0/
<lamont> vila: except that the very same package works quite well on EVERY OTHER MACHINE I HAVE
<lamont> and "reinstall the machine" seems a trifle drastically overkill
<vila> lamont: different install history for *this* machine maybe ?
<lamont> in the end, it could be that python-support is b0rked in ways we don't yet understand
<caravel> What's the recommended permission setup, for any ssh-based host ? Is the only choice, to use ACL ?
<vila> lamont: I didn't mention upgrading to 2.3.3. Not what you want right ? (Just checking)
<vila> caravel: using authorized_keys with a dedicated user on the server is far better
<lamont> I was kind of thinking of making 2.4.0 the next upgrade
<lamont> though if 2.3.3 is out, i suppose that's actually my next upgrade
<vila> it is
<caravel> vila: key or password is not the issue here I believe, and each bzr client user, has a dedicated user already. This is my point : I failed to obtain something that works : I tried the sticky bis without success
<vila> lamont: but I can't guarantee it will fix the issue if something else is already broken there :-/
<lamont> vila: so sounds like "moreinfo, try 2.3.3" is the appropriate status for the bug
<lamont> vila: I'm 99% sure it won't fix the issue
<vila> lamont: right, so no need to add noise by upgrading then
<vila> caravel: you lost me here, are you using bzr+ssh ? What kind of sharing are you trying to achieve ?
<vila> by 'bzr+ssh:' I mean as opposed to 'sftp:' in the URLs you use with bzr
<lamont> thanks
<caravel> vila: we have two groups of users, two branches and need different permissions (one brach is trunk essentially, the other is for contribs, the second user group must read.only the truck and write to contrib). So far we are using sftp://and will eventually use bzr+ssh but to my understanding this makes no difference on the server side (each user can connect over ssh also)
<caravel> ( server in a Standard Ubuntu maverick )
<vila> caravel: the main difference is that the sftp server filters the mode bits while bzr+ssh executes locally and should better deal with that
<caravel> vila: hah! :)
<caravel> vila: thanks, I'll give it a go - but what do you mean by "the sftp server filters the mode bits" ? sftp server is standard openssh module here
<vila> caravel: yup, that's the one I'm referring to (I don't remember the details though so I may be slightly wrong)
<caravel> vila: ok thanks
<vila> but at one point in the past that was the shared belief
<vila> jam: Where do we lose the chmod bits with sftp ? ^
<caravel> My second question is : is this possible to push a repo to a remote eg. sftp area, in such a way that the latest version of all files exist *not only* within the .bzr folder ? We want to (read-only) access the pushed repo using either bzr client, but *also* over sftp when no access to history is requred
<caravel> (bzr client might not be avail/installed everywhere, purpose is code review)
<vila> caravel: either bzr-push-and-update or bzr-upload would satisfy that (check their docs for your exact needs)
<caravel> vila: thanks, I knew I had missed something :)
<vila> caravel: the former will maintain the working tree up-to-date while the later will upload *only* the working tree but not the .bzr directory
<caravel> vila: but these aren't avail in tortoise interface, only cli, right ?
 * caravel hasn't got a windoz to check
<vila> caravel: no idea, I don't use tortoise (and only rarely windows)
<vila> caravel: should be pretty easy to add support for them to tortoise though, file a bug /
<vila> ?
<caravel> vila: when I was vnc'ing their workstations, I didn't see these options
<caravel> vila: well, ok but they need something that works... last week :)
<vila> oh cool, we can think a bit about it before replying then :)
<caravel> tortoisebzr context menu isn't hackable, besides editing source code and recompiling ?
<vila> no idea
<caravel> hmmmm - thanks a lot for your help vila, much appreciated
<vila> bzr-upload can be configured to trigger automatically though
<caravel> vila: not bzr-push-and-update ?
<vila> may be even both of them can be installed and configured on the server (I never did that myself though)
<vila> hmm, not sure, but it seems to me that just installing the plugin will just do the right thing if the remote branch can be accessed with either sftp or bzr+ssh, worth a try
<jam> vila: setgid gets stripped by openssh IIRC
<vila> jam: thanks, that was my guess too, so on the server side
<jam> vila: yes
<jam> so it has setgid, we then issue chmod(2775) or whatever, and then it gets stripped of setgid
<jam> so, for example, we are trying to change 2777 to 2755 or whatever, it ends up 755
<vila> jam: http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/ the last two failures should be obvious for you ?
<jam> vila: obvious as in blame vila?
<vila> really ?
<jam> vila: for running an old windows, I think
<vila> xp ?
<jam> no, I'm just harassing you.
<vila> isn't it a "can't open a file already opened" ?
<vila> ha :)
<jam> I could have sworn I wrote and tested those on windows
<jam> vila: can't open because we locked it in another instance
<vila> but the third one is for me ;)
<jam> you can open a file twice, but not if it has been locked, I think
<vila> jam: so just skip on windows or fix the test ?
<jam> vila: I'm seeing if I can fix it
<vila> jam: so, I've blacklisted one more test on babune and now we're seeing failures that occurred in the last... ~month
<vila> jam: first and second failures seems weird too: permission denied on a .pack file ? huh ?
<jam> vila: I have an update for "worth_saving_limit" which passes here
<vila> jam: do you have a public branch for that ? (And do you want a bug # for it ? (I'm filing bugs for the other))
<jam> vila: no need for a bug, I'm proposing it now
<vila> k
<vila> I've filed bug #788130 for the .pack file
<ubot5> Launchpad bug 788130 in Bazaar "test_branch_local_remote failure on windows: permission denied on .pack file" [High,Confirmed] https://launchpad.net/bugs/788130
<jam> vila: https://code.launchpad.net/~jameinel/bzr/2.4-dirstate-test-on-win32/+merge/62298
<jam> vila: for this http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/bzrlib.tests.test_config/TestLocationMatcher/test_file_urls_are_normalized/
<jam> /dir/subdir is, indeed, illegal on windows
<jam> so probably just change the test to add "C:" or whatever
<vila> probably shallow, yeah
<jam> http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/bzrlib.tests.commands.test_commit/TestCommitWithBoundBranch/test_commit_mine_modified/ seems more complex
<jam> in the first code path, we are getting an abort
<jam> because we thought we had a write stream that we are closing.
<jam> but maybe that is just fallout from the other failure
<vila> jam: filed bug #788131 as I'm already in the middle of mole whacking/yak shaving
<ubot5> Launchpad bug 788131 in Bazaar "TestLocationMatcher.test_file_urls_are_normalized failure on windows" [Medium,Confirmed] https://launchpad.net/bugs/788131
<jam> vila: commit_mine_modified passes here
<jam> so it could be a timing thing
<vila> <shudder>
<jam> vila: running 10 times in a row all the tests in that module, no failures
<vila> jam: I can confirm there is no virus scanner on this slave ;)
<vila> jam: approved
<jam> Riddell: did you need a review for "unescaped-backslash" that seems trivial enough to land
<Riddell> jam: I self approved, but I feed-pqm tells me that launchpad staging is getting a code update so I can't submit it yet
<jam> Riddell: I think you need a newer hydrazine
<vila> eeerk, why would staging be involved  there ?
<jam> launchpadlib changed the signature of their connection
<jam> and that caused hydrazine to start connecting to staging
<Riddell> it's a bug that maxb was looking at last week
<jam> Riddell: are you using packaged hydrazine or a branch?
<jam> If you pull the latest hydrazine trunk, it should work correctly.
<Riddell> packaged
<Riddell> ok I'll do that
<jam> but I went ahead and submitted it, since I was there
<Riddell> thanks
<maxb> Where is hydrazine packaged?
<Riddell> maxb: it's in a ppa
<Riddell> @hydrazine-core
<Riddell> ~hydrazine-core
<Riddell> but it's out of date, there's only packages for maverick
<maxb> Hm
<maxb> Hydrazine feels like the kind of thing that everyone should just run from the branch all the time
<maxb> But if we have the PPA, it should be kept up to date
<Riddell> packaged by elliot murphy back in June 2010
<jam> maxb: daily builds!
<Riddell> ooh, good idea
<maxb> Tempting
<caravel> jam: thanks for the setgid explanation (that one was for me) -- is it only while using its sftp mod ? or just any ssh use of openssh ?
<vila> jam: AFAIK https tests are passing fine on babune, I'm not sure I understand the context were you see them failing, is it with bzr.exe from the installer ?
<vila> jam: in this case you may be running into an old bug where the ssl certs should be taken into account by setup, so may be it's the same bug under a different use case
<vila> jam: see PKG_DATA in setup.py
<vila> jam: otherwise some other piece is missing like telling... whatever server/client to use the right path to access them (but I fail to see how that could be compatible with the tests passing on babune ;)
<lifeless> vila: I think its a lazy import race reporting extension loading fail
<caravel> jam: what you mentioned about openssh, is this applicable to sftp only or also to bzr+ssh ?
<jam> caravel: sftp only
<workthrick> hiya
<workthrick> $ bzr dpush git+ssh://git@github.com/mathrick/cl-cairo2.git
<workthrick> Permission denied (publickey).
<workthrick> bzr: ERROR: The remote server unexpectedly closed the connection.
<workthrick> I checked, and the key I'm using is properly setup, I can login using putty
<AuroraBorealis> i had this problem where it was using a bad version of ssh.
<workthrick> I also know that bzr uses paramiko + pageant properly for other connections
<workthrick> (ie. sftp://)
<workthrick> is there a possibility that dpush and/or git+ssh:// are somehow not using paramiko?
<workthrick> hmm, actually I can see they aren't, since paramiko is very noise on connecting
<caravel> jam: thanks alot. And using sftp, is the only way around, to use ACL, then ?
<workthrick> but why?
<AuroraBorealis> i installed git on windows
<AuroraBorealis> and it put like a weird version of ssh.exe in its folder
<workthrick> I don't want to touch git, especially on windows
<AuroraBorealis> and that was in the path, so bzr was using that instead of its own
<workthrick> ah, ok
<AuroraBorealis> so suddenly bzr wasn't working with ssh stuff
<AuroraBorealis> so see if there is any other ssh'es in your path? :o
<workthrick> AuroraBorealis: I can still connect over sftp://, it just doesn't respect BZR_SSH for dpush somehow
<AuroraBorealis> hmm. ive never used dpush so i dunno :<
<workthrick> you have to if you want to push to git
<jam> workthrick: bug #670035
<ubot5> Launchpad bug 670035 in Dulwich "git+ssh doesn't work on Windows" [Medium,Triaged] https://launchpad.net/bugs/670035
<jam> caravel: I believe if the permissions are already correct, we don't chmod
<jam> so if you set umask, etc, it might just work for you
<AuroraBorealis> hmm =/
<jam> which you can do in an sftp wrapper
<jam> caravel: http://jeff.robbins.ws/articles/setting-the-umask-for-sftp-transactions
<caravel> jam: thanks (umask isn't an option here, it's only for a given space)
<caravel> jam: ok - I see (reading)
<caravel> jam: well no, we can't do that :( unless defining distinct users just for bzr -- and we don't want this. I'm a bit surprised since I was expectig that to be a very common need, but found it hard to find some info
<caravel> so I'll try the acl route -- but that one is fine, right jam ?
<workthrick> jam: ah, I see
<jam> caravel: I haven't tried it
<jam> http://doc.bazaar.canonical.com/bzr.2.3/en/admin-guide/index.html
<workthrick> that's a pity, but I can probably work around it
<jam> generally we recommend away from sftp once you can, because it really doesn't scale well
<jam> once the project is big, the performance goes way down
<jam> it is better than ftp, but that isn't saying much
<AuroraBorealis> there is also little to no documentation on the smart server =/
<workthrick> jam: any idea why paramiko doesn't get used here? I don't know how the transport stacking works in bzr
<jam> workthrick: I don't know. Presumably the low levels of dulwich don't use bzr transports
<workthrick> ok, so I solved it by transplanting ~/.ssh from linux, only to hit bug #626341
<ubot5> Launchpad bug 626341 in Bazaar Git Plugin ""ValueError: too many values to unpack" when pushing to github" [High,Fix released] https://launchpad.net/bugs/626341
 * workthrick sighs
<AuroraBorealis> well it says fix released?
<workthrick> yes, but I need to update, which probably means upgrading bzr, which is a royal PITA on windows
<workthrick> because I'm running the non-standalone version
<caravel> jam: ok, I understand. But say that one want to setup, as well as the bzr thing, a functional sftp *anyway* on the same machine (for basic file sharing), with multiple groups etc. Then ACL is a must, then sftp might be used okay, right ? Or would you do that differently ?
<AuroraBorealis> cant you just use the installer?
<caravel> (I meant : then sftp might be used okay for bzr also, right ?)
 * caravel wonders if *anyone* is using bzr and sftp with the same openssh instance (??)
 * fullermd killed off using sftp with bzr with great glee when bzr+ssh became a possibility...
<LeoNerd> I only did that when it was actually faster to do so :P
<LeoNerd> My Celeron 333 server was -waaaaay- faster at running sftp, that it didn't matter the extra roundtrips and bandwidth
 * caravel meant : is *anyone* using bzr+ssh as well as standard sftp, using the same openssh instance ? :)
<caravel> (i.e. standard sftp client)
<fullermd> I don't use sftp much; easier to scp or rsync mostly.  But I've used it occasionally.  Not sure what cross-impact it might have on bzr+ssh though.
<caravel> I mean, if standard sftp requires acl for multiple user groups, and if acl permits the use of bzr over sftp also, THEN, yes, bzr+ssh is still better, but not strictly mandatory (or do I get this entirely wrong ?)
 * fullermd suspects there's background in scrollback he hasn't read.
<fullermd> I always just assume bzr+ssh is mandatory, really.  sftp is an available emergency fallback, whose use means "something is wrong".
<caravel> Defining this thing to the opposite : with multiple branches on the same "ssh space", without acl THEN sftp is simply not an option, right ?
<fullermd> Of course, the setgid issue with sftp-server wouldn't affect me anyway.
<LeoNerd> I found that on a slow server, sftp is faster, generally, because the server's sftp server is nicely C code, whereas having to spin up python and bzr to run the server, slowed it down
<fullermd> Well, the load isn't spinning up python, it's that the server is doing something other than "read from disk; write to network".
<maxb> It needs to be a pretty slow server and a pretty fast network connection for sftp to win out
<workthrick> AuroraBorealis: no, since I wanted to use bzr-git, and that needs dulwhich
 * caravel hasn't found any hint in the documentation about such limitation : I understand this is not really a bzr issue, but still : one -- like me :-) might have thought Â« okay, we need sftp anyway, so the quickest way to get that bzr running will be that one Â». [...]
<AuroraBorealis> ah.
<workthrick> I have since learnt you can use _lib inside the plugin's dir for that, so I might try that next time
<workthrick> but now I just switched to linux, upgraded its bzr, and pushed from there
 * workthrick hugs the VM
<mgz> vila: saying bb:tweak to riddell is a little perverse even if you explain what you mean by it
<vila> hmm, why ? I thought he needed to learn the acronym as I don't think we;ll stop using it. No ?
<vila> mgz: by the way, I was about to switch back to lazy_hook_test_cleanup_785054 which made my eyes bleed earlier today ;-D
<mgz> it seems mostly useful to people who've actually used bundle buggy in the past.
<vila> mgz: right.
<mgz> ^yeah... I think I just need to step through in a debugger or something to work out what the hell is going on
<vila> I'll ask him here tomorrow to make sure he understand what  I meant
<mgz> testtools is a pain to follow in pdb though, it's got so many layers of helpers calling helpers
<vila> but why not just use overrideAttr and forget about _restoreHooks ?
<mgz> changing the hook cleanup method completely is a good idea.
<vila> oh, and what makes it hard to review is that tests are failing so I don't know which failures I should really expect 8-)
<mgz> I'm just not sure what the current code is actually doing, which makes me a little scared of replacing it.
<vila> AFAIK it removes all hooks for the duration of the test,
<vila> except for the ones that should really be left there :D
<mgz> the tests are nicely commented as to which ones are failing, the why is the hard bit.
<vila> ok, let me try again
<vila> ./bzr selftest -s bt.test_selftest.TestHookIsolation -> 6 tests, 3 failures
<vila> expected ?
<mgz> yup, though I don't know why for the test_*_artificial cases
<mgz> the hooks.known_hooks logic is saving the locks hooks even when the lazy restoration code is doing the wrong thing.
<vila> starting with test_dict__lazy_hooks_restored
<vila> you're already protected there so the failure doesn't surprise me
<vila> err, wait
<vila> :)
<mgz> that one fails because the cleanup added for lazy hooks is wrong, but the confusing aspect is test_lazy_hooks_unregistered_lock does *not* fail
<mgz> even though the cleanup for lazy hooks is wrong
<mgz> because the hooks in the known_hooks list are covered by the old hooks cleanup code anyway
<vila> why and where should test_lazy_hooks_unregistered_lock fail ?
<mgz> because the code added in _restoreHooks for lazy hooks doesn't set self._preserved_lazy_hooks back to the correct place
<vila> because it should call the hook that you think should still be there ?
<mgz> what's the reasoning for the way the current hooks test isolation code is written?
<mgz> why not just blow them all away for the context of a test?
<mgz> (and optionally re-add the essential ones)
<vila> 1) no idea
<vila> 2) that's what I was aking you :)
<vila> well for 1), I think it predates overrideAttr and was not recognized as a possible call site that could use it
<vila> err, wait a minute, why is iter_parent_objects() used twice ??
<mgz> first is to get the current hooks, then to set a blank factory on the hook point
<mgz> if I have the terminology right
<mgz> also, it's somewhat confused by the behaviour changing with the adding of lazy hooks
<mgz> I'm still not certain what's stored as attributes on Hook classes and what's in that _lazy_hooks dict
<mgz> I think the intention is everything's now in the one dict.
<mgz> which should mean it's safe to simplify the test isolation
<vila> what's blank factory ?
<mgz> but I don't understand why the two failing tests aren't working
<mgz> ^a hook class by the look of it
<vila> but why do you say blank ? Looks like the real thing to me
<mgz> as in, with no callbacks set
<mgz> though this is complicated by the api change, I really don't know what's going on now
<vila> ha, right, yes, blank factory, ok got it
<vila> so in effect, this reset all the hooks indeed
<vila> this guarantees that you will always get a result when querying the registry, but start afresh without any hook points
<vila> a two-level dict if you prefer so we can't just do self.overrideAttr(hooks, 'known_hooks', KnownHooksRegistry())
<mgz> right.
<mgz> and I'm not clear on what 'known_hooks' consitutes. are all usabled hooks nessersarily found there?
<mgz> because otherwise it looks like we're only protecting the basic bzrlib hooks and not any added by plugins etc
<vila> err, plugins we are getting rid of the hook points, only bzrlib defines hooks AFAIK (and if I get the names right ;)
<vila> meh s/plugins//
<vila> so there is a single hook point that is preserved: the smart request one to check the server jail
<mgz> okay then, if _builtin_known_hooks is intended to be exhastive, I think I can just delete the _lazy_hooks dictionary overriding, and the two *_artificial tests
<vila> I'm pretty sure _builtin_known_hooks is exhaustive
<vila> at least as far as testing bzrlib goes
<vila> and I always considered that to test a hook point you *had* to install it during the test
<mgz> so what I'm doing with _TestingHooks in those tests is just bogus because it's not named in _builtin_known_hooks?
<vila> haaa, could be, you don't even register it no ?
<mgz> I call install_named_hook or install_lazy_named_hook
<vila> ghaa, right, I think a lot of confusion is coming from hook/hookpoint and not even respecting that in all method names
<vila> but that's one level below
<vila> you've just defined a Hook that is not protected and inside that you add hookpoints
<vila> it's not a two-level dict, it's a two-level registry
<vila> this may be worth refactoring for clarity but the compatibility issues might be... interesting
<vila> mgz: I'm crashing :-/
<mgz> sleep!
<vila> mgz: did this discussion clarify things a bit ? (It did for me at least but I'm not fresh enough to explain it properly I fear)
<mgz> I think so.
<vila> the lazy_hooks are really hookpoints I think and don't require as much care (single level)
 * vila off
#bzr 2011-05-26
<poolie> hi all
<poolie> hi spiv?
<spiv> poolie: hi
<poolie> hi there
<lifeless> hi
<vila> hello poolie !
<jam> morning poolie, good to have you back around
<poolie> hi jam, it's good to be back
<poolie> i had a great trip
<vila> poolie: I was a bit worried you get stuck in Europe due to this other volcano ;)
<jam> poolie: I'm curious why you're online at this time, though. Just finishing up your day?
<poolie> jam it's 17:40 here, not so late
<poolie> i will finish up now though
<poolie> vila, no, i came back on my scheduled flight
<poolie> good night
<jam> poolie: sure, you just didn't say "hi there" until 2 hours ago, and I didn't see you chatting earlier
<jam> so I thought that you might have been in a different TZ
<jam> I now see that you said high 8 hours ago
<jam> hi
<vila> poolie: cool, enjoy your evening !
<poolie> glad we got that straight :)
<temporarytao> hi, can anyone tell me how i can generate a .diff file using bzr and then apply a patch using the diff file?
<Kamping_Kaiser> temporarytao: 'bzr diff' and 'patch'?
<temporarytao> Kamping_Kaiser, i think that's what i need but just to clarify...
<temporarytao> i use diff to create the .diff file by piping the output of 'bzr diff' to a file, right
<temporarytao> and then use patch to apply the changes in the file
<vila> that should work (expect for binary files, renames and so on)
<Kamping_Kaiser> yes. or use merge requests. , bzr help send
 * vila nods at Kamping_Kaiser 
<Kamping_Kaiser> vila: gday
<vila> \o_
<temporarytao> thanks!
<Kamping_Kaiser> np :)
<maxb> poolie: Hello. I was wondering if you happened to know the rationale in lp:~bzr-core/bzr/devnotes being owned by ~bzr-core rather than ~bzr ?
<Lo-lan-do> Hi all.  Is it possible to ship a shelve?
<Lo-lan-do> Or do a bzr send --uncommitted or so
<vila> Lo-lan-do: shelves are supposed to be used locally, there are many different available and well supported ways to ship revisions ;)
<Lo-lan-do> The point was not to ship a set of revisions, but an uncommitted patch.
<Lo-lan-do> (To a remote box, so bzr merge --uncommitted wouldn't work)
<vila> I got that, I'm pointing out that, no, shelves are not meant to be shipped, you can try copying the file under ./bzr/checkout/shelf
<vila> but there are cases where you won't be able to use it because it's not *meant* to be used this way
<Lo-lan-do> I understand.  I'll do with a simple bzr diff then.
<santagada> is there a way to associate two repositories with the same project on launchpad?
<gour> santagada: group?
<santagada> gour, I wanted to do it with a project
<santagada> gour, or do I have to have one project for each repository?
<maxb> Sorry to bounce you around, but this question is more rightly discussed on #launchpad
<maxb> (I know you were just pointed in this direction)
<santagada> I am going to guess this is impossible, it is 1 project 1 repo because there is no docs about this
<vila> lamont: ping, did you find a solution for your "AttributeError: 'module' object has no attribute 'trace' " ? (aka bug #788072)
<ubot5> Launchpad bug 788072 in Bazaar "AttributeError: 'module' object has no attribute 'trace'" [Undecided,Incomplete] https://launchpad.net/bugs/788072
<lamont> vila: I did not
<vila> :-/
<lamont> it's one of those "busy with other things, this is only mildly  annoying so far" things
<vila> I see
<smoser> hi, i wonder if i can have some help...
<smoser> i've got a branch at lp:ubuntu/python-boto
<smoser> bzr diff -r tag:1.9b-1..tag:1.9b-1ubuntu5
<smoser> shows a bunch of adds and removes or renames
<smoser> and the net is that nothing changed
<smoser> it was probably user error that created that, but
<smoser> (on my part)
<smoser> but a.) is there a way to ignore those in a 'bzr diff'
<smoser> b.) is there a way that i can get that to happen by default
<smoser> i'm willing to muck around with things now to get that fixed in the future
<maxb> I don't believe there's any way to get bzr diff to do what you want
<maxb> In similar situations I have bzr export-ed both trees and diffed the result.
 * maxb grabs the branch to inspect how it arose
<maxb> Ah, right. Yes, it was the manner in which you brought in the debian version which has caused this
<maxb> smoser: Hmm. I'm tempted to say that the most expedient way to fix it would be to erase the ubuntu branches and have the importer reimport them
<maxb> Unless you can think of any other branches which might have history built on top of these
<smoser> maxb, probably not.
<smoser> at least not that couldn't be ignored.
<maxb> smoser: How much to you know about Bazaar file ids?
<maxb> s/to/do/
<smoser> i know that you just said "Bazaar file ids" and not much more :)
<maxb> Hah
<maxb> OK, the very quick summary:
<maxb> Bazaar tracks the identity of files via an id that is generated when you add it
<maxb> This works great most of the time and allows sensible handling of moved files
<maxb> However, if the "same" tree is separately imported in two different branches, odd stuff like you can see tends to result
<maxb> This is known as a "parallel import"
<maxb> There are ways to mitigate this quite a lot, but they are best applied when first merging the two parallel imports - so applying them after 5 ubuntu releases have happened since that merge isn't optimal
<maxb> As the only revisions on the branches which are not generated by the importer anyway, are the ones causing the problem, I'm suggesting a reset and reimport
<maxb> People who can make this happen are a subset of ~canonical-bazaar folks
 * maxb wonders if vila or spiv is around
<maxb> or james_w
<smoser> yeah, i think that sounds like the best course of action.
<james_w> hi maxb
<smoser> i'd rather have the tree look sane
<james_w> "bzr diff | filterdiff" might hide them :-)
<maxb> james_w: Hi. Would you agree with my assessment that if the only non-importer revisions in some UDD branches are a slightly botched parallel import, it's best to delete the branches and restart the import?
<james_w> maxb, sounds about right, but today isn't a good day to ask me anything unfortunately
<maxb> OK, fair enough. LP question against udd?
<vila> I'm busy freezing bzr-2.4b3 but I can run a command on the importer
<james_w> maxb, I'm not sure if I receive those or not, so a bug might be better
<maxb> ok
 * maxb checks delete_branches_from_lp.py syntax
<vila> hmm, if this involve running *that* script, yeah a bug to track the process sounds better
<maxb> hmm, that could really do with an --ubuntu-only option
<maxb> vila: During the sprint, I observed that delete_branches_from_lp.py had local modifications on jubany. Could you have a look at them and commit them if there is nothing confidential involved?
<maxb> That way I can put up a MP adding an --ubuntu-only flag without worrying about conflicts
 * vila shudders
<vila> yeah, I asked for this changes to be committed with the intent triggering them but... never happened
<james_w> IIRC the intent was that the current script is completely broken :-)
<vila> argh and branches diverged :(
<vila> and whoami not set :(
<vila> why did I pop up here !
<vila> :)
<vila> ok,committed
<james_w> heh
<james_w> thanks vila
<maxb> Could I get a requeue_package.py sysvinit too?
<maxb> I expect it to fail, but I want to see if the failure reason has changed
<vila> no options ?
<maxb> no options
<mgz> it seems to have been a cyclic day in my absense.
<vila> requeued
<vila> ha ha ha
<mgz> oh, is 2.4b3 being release today?
<vila> frozen, not released ;) Don't start rumors will you ?
<mgz> ehhee
<smoser> maxb, so do you or vila need me to open a bug ?
<smoser> sorry, i was away a bit.
<vila> hmm, I understood that maxb will open it but I may be wrong
<maxb> I was going to open one once I'd had a look at the existing scripts and figured what needs to be done in detail
<maxb> However, if you'd like to open one (under launchpad.net/udd) and subscribe me, that works too, and I'll fill in the details later
<maxb> Hmm
<maxb> Actually, I wonder if we could do it less brutally
<maxb> Yes, we don't need to delete all the branches, we could just remove a few revisions
<smoser> so you still want a bug ?
<mgz> vila: ouch on bug 785098 I wondered why I couldn't repo that
<ubot5> Launchpad bug 785098 in Bazaar "bzrlib.tests.test_utextwrap.TestWrap.test_umlaut_followed_by_dash (from ) " [Medium,Confirmed] https://launchpad.net/bugs/785098
<vila> see my last comment ? Got sphinx ? Got python test files ?
<mgz> yeah, reading it. not having sphinx is why.
<smoser> bug 788747 opened
<ubot5> Launchpad bug 788747 in bzr (Ubuntu) "requesting diff of one file gives output of all changes" [Undecided,New] https://launchpad.net/bugs/788747
<mgz> sphinx are being very naughty.
<vila> I've got a fix for them
<mgz> are you filing an upstream bug?
<vila> yup, in progress, patch missing
<fbond> Hi, I just got hit by https://bugs.launchpad.net/bzr/+bug/641330 .
<ubot5> Ubuntu bug 641330 in Bazaar "unable to unshelve shelved root-id change" [Low,Confirmed]
<fbond> Is there any way to get my shelved content back?
<fbond> Maybe I can edit the shelf pack file by hand to remove the root?
<fbond> nm, no time for bzr bugs today...
<mgz> doh.
<mgz> confused by core count detection again.
<vila> hmm, wasn't there a patch to rely on python to do that ?
<mgz> unless I lie the fork code never gets run on my machine
<mgz> because it thinks it knows best based on the fact I only have one cpu
<vila> multi-core ? OS ?
<mgz> I still need to test that fork works, even on my old machine
<mgz> otherwise all you people with fancy new computers will yell at me when my code breaks when you run it
<vila> hehe
<mgz> bah, this nearly works, there's just an api gap.
<maxb> Could I have a "./requeue_package.py --all-of-type xwax" please?
<vila> maxb: done
<maxb> thanks
<maxb> I expect them all to fail, but with new and different tracebacks
 * vila returns the thanks ;)
<vila> that's a good game
<__monty__> How do I start solving a bug, how do I know where to look for the code that's responsible?
 * vila blinks
<vila> __monty__: in bzr ?
<__monty__> Yes.
<vila> depends on the bug :) Is it one you encounter yourself or just heard about ?
<__monty__> Something I would find on the bug tracker, I don't have a specific bug in mind yet.
<vila> ha, hmm
<vila> There is no generic answer to such a wide question, there are bugs tagged 'easy' you may want to try first
<JFo> or bitesize
<vila> https://bugs.launchpad.net/bzr/+bugs?field.tag=easy
<vila> hmm, I. not sure we started using bitesize, that's a good idea
<JFo> https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=bitesize&field.tags_combinator=ALL
<vila> mgz: do you expect more feedback on https://code.launchpad.net/~gz/bzr/lazy_hook_test_cleanup_785054/+merge/61586 or should we mark it WIP ?
<JFo> lots of packages are using it from the look :)
<poolie>  /back
<poolie> hi jfo, vila, mgz, maxb
<maxb> Hello poolie
<maxb> I had a question for you - why is ~bzr-core/bzr/devnotes owned by ~bzr-core rather than ~bzr ?
<poolie> the short answer is i don't know
<poolie> is ~bzr in ~bzr-core or is it vice versa?
<maxb> ~bzr is in ~bzr-core
<mgz> vila: well, I probably do need some more input, but it can wip till I have some of these other branches landed
<mgz> hey poolie!
<maxb> So ~bzr-core does mean more people can write - though the vast majority of branches appear to be on ~bzr anyway
<maxb> It's all a bit messy
<vila> mgz: no, if you need more feedback just put an additional comment
<maxb> Ah well. I think I'll get the code review subscriptions issue sorted first, then attack bugmail
<vila> poolie: hey !
<vila> poolie: my god, you fall from your bed ?
 * vila shuckles poor poolie getting remarks at all hours :)
<JFo> hi poolie  :)
 * JFo was looking at another computer for a bit :)
<poolie> i am a bit
<vila> hehe
<poolie> what's worse is i've been up for a couple of hours
<poolie> how are things here?
<JFo> not bad
 * JFo has a dinner meeting in a few, so will be away
<JFo> better get moving now I've looked at the time :-/
<poolie> i bet i've already filed a bug asking for a way to subscribe to all code reviews
<poolie> vila, how  have you been?
<vila> busy ? :D
<vila> 2.4b3 frozen, some chroots configured, some bugs fixed, more filed, some PPing (jelmer is away AIUI)
<poolie> ah
<poolie> yes, we should have rescheduled that
<poolie> he is on holidays
<vila> .. and still hoping for some reviews on config :-D
<poolie> could you officially take it on for tomorrow?
<__monty__> I think this is a good bug to start working on: https://bugs.launchpad.net/bzr/+bug/712922
<ubot5> Ubuntu bug 712922 in Bazaar "standard way to warn about deprecated parameters" [Medium,Confirmed]
<__monty__> However I don't know how to begin.
<vila> __monty__: 1) look into bzrlib/symbol_versioning.py and search for the corresponding tests and use cases
<vila> 2) start playing with 'bzr selftest -s bt.symbol_versioning'
<poolie> hi __monty__
<__monty__> hi
<poolie> i will try to give you some reviews
<vila> 3) write a failing test in bzrlib/tests/test_symbol_versioning.py that will exercise the code you're planning to write
<poolie> (you=vila)
<poolie> __monty__: are you just looking for some bug to fix?
<poolie> there are some tagged easy
<poolie> that one should be fairly easy, but involves a bit of metaprogramming
<vila> poolie: yeah, np, I was more or less doing it ~officially already
<poolie> so depends a bit how much you know python
<vila> poolie: great !
* poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila
<poolie> vila, jam, do you think https://bugs.launchpad.net/bzr/+bug/602614 is really conclusively fixed?
<ubot5> Ubuntu bug 602614 in Bazaar "Out of memory error in _ensure_content on auto repacking" [High,Fix released]
<vila> No idea, it was mentioned in the news so I marked it fix released, if there are pending issues, it may be worth filing a new one
<vila> new bugs are easier to track for all parties involved (we have bugs opened for too long otherwise)
<__monty__> Hmm, I don't know about metaprogramming, maybe I should look for another bug?
<poolie> well, yes
<poolie> but that's a pretty popular bug
<poolie> so i think it would be a bit pedantic to mark it closed and ask people to move to another
<poolie> i will comment
<vila> poolie: I see. Sorry, I was a bit rushed while I cut the release (maxb is doing wonders on the package importer and needed a proxy ;)
<poolie> np
<poolie> really no problem
<poolie> it's good to have multiple eyes
<poolie> it's just good on hot bugs like this (especially) not to say it's closed when it's not
<poolie> but in this case it seems it may well be
<vila> hmm, I add a --browser option to checknewsbug.py, in which section should I mention that ? Internals ?
<vila> not a major change but interesting for *some* bzr devs :)
<__monty__> Maybe this is a better bug to begin with? https://bugs.launchpad.net/bzr/+bug/54624
<ubot5> Ubuntu bug 54624 in Bazaar "warn when committing large (binary) files" [Medium,Confirmed]
<__monty__> It doesn't sound hard if a file is binary, check the size, if it's bigger than some variable limit, give a warning?
<poolie> vila, internals
<poolie> or, perhaps better, past to the list
<poolie> __monty__: that sounds good
<poolie> i wouldn't even bother checking if it's binary
<poolie> just if it's more than say 10MB by default, warn
<poolie> and ideally take that from a config variable
<vila> poolie: the proposal is almost ready, I'll see what reviewers say, no big deal anway
<__monty__> poolie: Where should a check like this be? Somewhere in commit.py? And how do I add a config variable?
<poolie> __monty__: probably yes, in commit.py
<poolie> you should get the wt configuration object
<poolie> and then i think just get_user_configuration passing it the name you want
<poolie> if you want a really easy one to start https://bugs.launchpad.net/bzr/+bug/364462 would be good
<ubot5> Ubuntu bug 364462 in bzr email commit hook "smtp "connection timed out" causes full stack trace to be dumped" [Medium,Confirmed]
<jam> poolie: it is not conclusively fixed, but we have more headroom.
<jam> I think the ultimate fix is to not read whole files into memory
<jam> without that, we'll always have a case where we fail
<__monty__> poolie: Looking at the traceback (in the bug you suggested) it seems the error should be handled in bzrlib/plugins/email/smtp_connection.py However I don't have the email directory, should I install a certain plugin or is it located somewhere else?
<poolie> __monty__: it would be in lp:bzr-email
<poolie> however
<poolie> there are smtp sending wrappers in bzrlib itself
<poolie> i think that's where it should be handled
<__monty__> poolie: in smtp_connection.py?
<poolie> sounds right
<poolie> or possibly in crash.py, just to say this error is never an internal error
<__monty__> How can I catch the error from within smtp_connection.py or crash.py?
<poolie> _
<poolie> __monty__: crash.py has a concept of errors that don't indicate bugs
<__monty__> So this should go in crash.py? But how does crash.py know this error occurs?
<poolie> hm maybe not crash.py
<__monty__> smtp_connection.py then?
<poolie> ok, it's report_exception in trace.py
<poolie> that has the policy about whether something is a bug (and should get a traceback) or just an environmental or user error
<poolie> socket.error is normally an environmental error and should be treated as such
<__monty__> Is there a prefered pastebin for this channel?
<__monty__> poolie: Would this be enough for a fix? http://pastebin.com/uxh5u0ag
<poolie> that's almost it
<poolie> but socket.error can mean many other things than just a timeout
<poolie> you need to get a string about the particular error
<ironcamel> anybody got bzr bisect installed and got it to work?
<poolie> yes, i have
<poolie> what's wrong?
<poolie> __monty__: how's it going?
<poolie> probably just printing the str form of the excepiton would be a good start
<poolie> ideally we would also include something about just which host we were failing to connect to
<poolie> i don't know if socket.error includes that
<__monty__> I'm still trying to find out how to get the string :s
<poolie> str(e) should do it
<poolie> the default exception-reporting thing should print that probably
<poolie> so you may notneed to specify anything special
<__monty__> What do you mean by the default exception-reporting thing, report_user_error()?
<poolie> yes
<__monty__> Should I pass an advice parameter to report_user_error() or is this fix meant to handle every socket.error?
#bzr 2011-05-27
<__monty__> Mmm, socket.error is a child class of IOError, so should the test for socket.error happen before the test for IOError?
<poolie> i wonder why it isn't being handled by the existing code that tries to treat IOError as a user error?
<mgz> in python 2.6 and later.
<poolie> hi mgz
<poolie> ah, perfect
<__monty__> Ah, yes the user was using 2.5
<poolie> in that case you could just list it in the same exception clause, and perhaps add a comment why it's being caught separately
<__monty__> What do you mean by listing it in the same exception clause?
<mgz> having it before with a special note about connectivity would also be reasonable
<poolie> i meant having (OSError, IOError, socket.error)
<poolie> you should also add a test
<poolie> i think this is pretty well covered in test_trace so you can go from those examples
<__monty__> What would be the best solution, testing it first with a specific message about connectivity or making the message for IOError more general and including OSError and socket.error?
<poolie> can you explain the second alternative more?
<__monty__> The second alternative is what I understood you were proposing.
<poolie> add a test that raises socket.errer
<poolie> *error
<poolie> check it does not print a traceback
<poolie> the easiest way to make this test pass is probably to just also catch that exception in the same way as for IOError
<poolie> hm
<poolie> actually, on trunk, since we need py2.6 now, this bug may be obsolete
<poolie> you could just interactively test that it works
<__monty__> How exactly do I test it? How do I try to get a socket.error?
<poolie> look at eg test_format_io_error
<poolie> probably a good way to get a realistic one is to try to connect to some unlikely port on localhost
<poolie> like tcp port 2
<mgz> it's safe to just construct your own socket.error
<poolie> it is
<__monty__> Yes, but how?
<poolie> i feel if you do it yourself, you may miss quirks in how python constructs them
<poolie> for instance there have been some bugs along the lines of actual python not setting named attributes on errors the way we expected, iirc
<poolie> so if it's easy i'd lean towards generating a real owne
<poolie> *one
<__monty__> I should write a new method in test_trace.py to test if this is no longer a problem in python 2.6, right?
<poolie> yes
<mgz> so, for instance, in bzrlib.tests.test_trace use test_format_pywintypes_error as a template but raise a likely looking socket.error instead
<mgz> ...and I note there I did do what poolie said rather than what I suggested
<mgz> in that I called a function that will raise a real error rather than constructing my own
<poolie> this will probably cover bug 598158
<ubot5> Launchpad bug 598158 in Bazaar "Socket is closed errors are not caught/wrapped." [Medium,Confirmed] https://launchpad.net/bugs/598158
<poolie> well, it's probably a dupe
<poolie> in fact both are probably dupes of bug 393173
<ubot5> Launchpad bug 393173 in amarok (Ubuntu) "Amarok does not transfer album art to iPod (dup-of: 260091)" [Undecided,New] https://launchpad.net/bugs/393173
<ubot5> Launchpad bug 260091 in amarok (Ubuntu) "Amarok does not correctly re-format cover art when transferring to Ipod" [Undecided,Won't fix] https://launchpad.net/bugs/260091
<poolie> sorry bug 393713
<ubot5> Launchpad bug 393713 in Bazaar "[master] socket.error causes a traceback" [Medium,Confirmed] https://launchpad.net/bugs/393713
<mgz> some socket errors are deeply unhelpful so some extra text in the advice param is probably a good idea
<__monty__> As extra text just point to bzr.log or something more helpful?
<mgz> socket.socket(0) gives me a nice fast error, but that's probably a bad idea
<mgz> depends if the constants are standardised at all I guess
<poolie> i think there probably the thing is to catch them close to the point they're raised and rethrow something more meaningful
<poolie> like try: socketblah: except socket.error:
<poolie> raise something("failed to connect to smtp server %s:%d: %s" % (host, port, e))
<mgz> ehehe, funny mail from jam about the 2.4b3 release
<poolie> :)
<poolie> that was such a fun sprint
<__monty__> So, the error should be caught before we have to handle it in trace.py? Or did you mean something else poolie?
<mgz> poolie, I've got half a thing written trying to convey that sense of fun, if I mail it to you will you proof read?
<poolie> sure
<poolie> i'd kind of like to consciously understand what we (or i) did right
<poolie> to reproduce it
<poolie> it seemed like there was just enough focus on having a hit list, but it wasn't overstructured
<__monty__> How does the test method work, I make sure an error is raised in the try block, then 'pass' the except block, then 'msg = _format_exception()', then self.assertContainsRe(msg, r"The string for the error here")?
<poolie> that sounds right
<__monty__> Still how do I raise a socket.error that's realistic?
<poolie> like mgz said just a socket.socket(0) could be a good start
<spiv> __monty__: hmm, perhaps try to call sock.accept without first calling sock.listen?
<poolie> o/ spiv
<mgz> or socket.socket() then socket.send("something") yells at you for not being connected
<mgz> really realistic ones like timeouts are probably not something we want in the test suite :)
<spiv> mgz's idea sounds good too.
<spiv> Hi poolie
<__monty__> Which one of these is least likely not to fail?
<mgz> they should all fail! :)
<poolie> either of those last two should be reliable
<poolie> if it turns out they're not we can fix it
<__monty__> What would the error string look like for the socket.socket() socket.send("string") scenario?
<poolie> just try it :)
<spiv> python -c "import socket; s = socket.socket(); s.send('string')"   :)
<__monty__> Is this correct for the string? Are the backslashes necessary since it's a raw string?
<__monty__> r"^bzr: ERROR: \[Errno .*\] Socket is not connected"
<poolie> the backslashes are needed if you're trying to match it as a regexp
<__monty__> so it's not really necessary in this case since the error will always be: socket.error: [Errno 57] Socket is not connected
<poolie> i don't think it's guaranteed to be error 57 on all platforms
<poolie> spiv could i mumble at you about bug 220464?
<ubot5> Launchpad bug 220464 in Bazaar "Bazaar doesn't detect its own stale locks" [High,In progress] https://launchpad.net/bugs/220464
<__monty__> Then this is good? r"^bzr: ERROR: \[Errno .*\] Socket is not connected"
<poolie> yup
<poolie> does it pass?
<poolie> try running ./bzr selftest -s bt.test_trace
<__monty__> I get this: bzr: ERROR: No module named testtools
<__monty__> You may need to install this Python library separately.
<__monty__> bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
<poolie> yes, you'll need testtools to run the tests
<poolie> on ubuntu or debian, apt-get install python-testtools
<__monty__> This is the output:
<__monty__> bzr selftest: /Users/toon/src/bzr/connection-timed-out-364462/bzr
<__monty__>    /Users/toon/src/bzr/connection-timed-out-364462/bzrlib
<__monty__>    bzr-2.4.0dev4 python-2.6.5 Darwin-9.8.0-i386-32bit
<spiv> poolie: sure; via which medium?
<__monty__> ----------------------------------------------------------------------
<__monty__> Ran 25 tests in 0.577s
<__monty__> OK
<__monty__> Missing feature 'meliae' skipped 1 tests.
<__monty__> Missing feature 'pywintypes' skipped 1 tests.
<__monty__> bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
<__monty__> Sorry for the excessive pasting.
<poolie> rockin
<poolie> spiv, here, or mumble, or the phone
<poolie> mostly it's been a while since i touched it so i can't recall if i meant to do anything else before proposing it
<poolie> actually if you could just review it now that would be nice
<__monty__> Should I submit the change now?
<poolie> yes please
<spiv> poolie: sure, already started reading
<spiv> poolie: So far it looks very nice!
<poolie> there's another thing connected but just out of scope
<poolie> which is to do with trying to release locks as we terminate
<poolie> and there was some discussion at the sprint
<poolie> which leaned me a bit closer towards a crash-only design
<poolie> iow better to just pretty much terminate when something unexpected happens and then pick up next time
<poolie> __monty__: all ok?
<__monty__> Yes, I'm composing the cover letter(?) I should mention all three of the bugs right?
<poolie> since they're all dupes only the master is enough
<poolie> thanks for fixing thins!
<poolie> *this
<mgz> poolie: I've emailed you a thingy.
<poolie> ta
<poolie> that's really nice, thanks!
<poolie> i didn't know about bialix's shirt
<poolie> i don't have any particular corrections or suggestions
<poolie> i'd like to put it on the blog too
<poolie> which will make it easy to add links
<poolie> do you have access?
<mgz> not currently.
<poolie> ok sent
<__monty__> Merge proposed. Thank you for all the help poolie, mgz. :)
<mgz> thanks poolie, and thanks monty :)
<poolie> np, thanks for your contribution
<__monty__> See you later!
<mgz> okay, gzlist on wordpress is now me.
<mgz> darn minimum four character username restrictions :)
<spiv> mgz: your nick is too compressed :)
<spiv> poolie: branch reviewed, very nice
<poolie> thanks spiv
<mgz> okay, I think the post should be in the review queue on the blog
<mgz> feel free to edit or change if anyone spots something that could do with improving
<james_w> mgz, it looks like it is published
<james_w> "Someone even" in the second sentence a mistake?
<mgz> *how
<mgz> dammit, I thought I'd changed that :)
<poolie> i published it
<poolie> well spotted
<poolie> you should still be able to edit it?
<poolie> spiv interesting question about reraising incidental errors
<poolie> hm
<mgz> hm I don't see the edit button
<poolie> i'll fix it
<mgz> I've got some fixes for your lock breaking branch in return :)
<poolie> :)
<poolie> mgz are you going to comment on the mp - should i wait for you?
<mgz> yes please.
<mgz> will try and be fast.
<poolie> np
<poolie> just didn't want to stand around looking silly
<mgz> okay, nearly there
<mgz> I don't really need to implement this twice...
<mgz> requiring 2.6 means has_ctypes should always be true
<mgz> okay, tests pass
<poolie> i wonder if i should change this to cast to unicode to get the human form, rather than to str
<poolie> to make it safer for py3 and indeed also for unicode values
<mgz> it's generally the right thing to do
<mgz> but it's a little annoying in Python 2 because it can be dangerous to pass somethings unicode rather than str
<mgz> it can break exceptions and such like
<mgz> okay, posted branch poolie
<poolie> thanks mgz
<mgz> I'm a bit past a coherant review, hopefully the changes make sense, otherwise it'll have to wait till tomorrow :)
<poolie> sure
<poolie> i have some other things to fix in it anyhow
<poolie> have a good night
<mgz> I got a few of them in the branch I think. Night poolie!
<vila> woohoo, nice blog post mgz !
<poolie> it is isn't it
<poolie> hi vila
<poolie> i might call it a day though
<vila> poolie: heya
<poolie> thanks for the release
<poolie> vila i don't know if you saw the mail from https://bugs.launchpad.net/bzr-cvsps-import/+bug/788914
<ubot5> Ubuntu bug 788914 in CVS to Bazaar importer "unexpected keyword argument 'pb'" [Critical,Confirmed]
<poolie> but it would be nice to review and merge his patch
<poolie> *yawn*
<vila> hmm, never touch this code so far :-/
<poolie> they should be shallow fixes
<poolie> or maybe we can get lifeless to review them
<poolie> anyhow i should really go
<poolie> have a good day
<poolie> will try to be online later next week
<vila> have a nice weekend
<poolie> you too
<spiv> vila: you might enjoy https://code.launchpad.net/~spiv/bzr/subprocess-log-in-test-details/+merge/62612
<spiv> It might help demystify some babune failures.
<vila> spiv: amazingly, I just found a trick to avoid the hangs...
<spiv> Heh.
<spiv> What's the trick?
<vila> redirecting *selftest* stderr at the invocation seems to be enough (how that's inherited is yet unclear, but probably works for all cases where we don't explicitly handle stderr)
<vila> so, what did I collect there ?
<vila> I'm glad you asked: http://paste.ubuntu.com/613637/
<vila> *2* deprecation warnings... sound very small to block a pipe no ?
<spiv> Well, depends on what the pipe's buffer size is
<vila> hmm, 277 chars...
<vila> awfully close to 256 :)
<spiv> And how close we were to hitting the buffer limit without the extra noise :)
<spiv> Yeah.
<spiv> That worryingly suggests that jenkins or whatever is driving selftest in the slave isn't draining both stdout and stderr concurrently.
<vila> my head spins a bit trying to understand the ramifications...
<vila> dosen't clearly explain why your patch for osx/windows didn't work, I should retry that now
<spiv> It also appears to disprove my optimism in saying âIt's hopefully safe to assume that the terminal or whatever is draining both our stdout and stderr reliably!â :(
<vila> yup, that remark triggered my trick test
<vila> on the other hand, selftest is not supposed to output anything on stderr other than potential issues that needs to be addressed
<vila> does that sound correct ?
<spiv> vila: well, deprecation warnings sound like fair game for stderr to me
<vila> yes, as things that should be addressed
<spiv> And it's always possible to have lots of them
<vila> hmm
<vila> let me clarify
<vila> we seem to encounter various issues with anything that appears on stderr
<spiv> And there's some value in testing that we work in environments that do emit deprecation warnings.
<spiv> i.e. with older libraries
<vila> jenkins and subunit being brittle there
<vila> so diverting stderr at the top level and investigating issues found there separately may help us reach a more robust babune
<spiv> And in extreme situations (i.e. sufficiently bad bugs) we might even get subprocesses exploding with tracebacks on stderr
<vila> I agree there is valuable information there, I don't mean to redirect to dev/null !
<spiv> Sure I didn't take it to mean that.
<vila> right, my guess is that this should trigger test failures nevertheless
<spiv> I'm just saying we can't rely on driving stderr output in babune down to zero either
<spiv> We have to be able to cope with it (even if we do manage to get it down to zero normally, bugs happen)
<vila> oh, right, may be not in the short term, but that's still a good target ;)
<vila> I don't feel especially at ease with this deprecation warnings
<spiv> It's probably a good target, but we can't depend on it. :)
<vila> indeed
<vila> so 2>selftest.stderr and cat selftest.stderr may be a useful trick
<spiv> In the extreme case imagine someone introduces a syntax error in lazy loaded code that is only hit by a test subprocess
<spiv> vila: +1
<spiv> buildbot gets this right :/
<vila> ?
<vila> oh, you mean by handling it by default ?
<spiv> It reads stdout and stderr from the subprocess just fine (and even shows stderr in red in the default console output display)
<spiv> Right
<vila> I can't believe (yet) the solution to so many babune problems could be that simple...
<vila> time for more coffee :)
<vila> hmm, by the way...
<vila> OMG !
<vila> fullermd is not there !
<vila> Hell must be frozen !
<vila> ok, so plan: 1) more coffee, 2) look at spiv's stderr handling patch..... 4) profit !
<spiv> vila: given the state of http://webnumbr.com/.join%28bzr-active-reviews,bzr-pqm-queue-length,bzr-merged-reviews.derivative%29 you have quite a challenge as patch pilot today :)
<spiv> Hangover from the sprint I guess!
<vila> well, I backuped jelmer so I have a bit of lag, but I'm also waiting for reviews for my own proposals...
<vila> may be I should just land them pretexting a user error while landing and approved one without realizing some pre-requisites weren't approved ;-D
<vila> spiv: still hanging on OSX :-/
<spiv> vila: :/
<spiv> vila: does subprocess-log-in-details help at all?
<vila> not tried that one yet
<spiv> (Obviously it won't help the hang, but maybe it'll give better info if you interrupt the hang)
<spiv> vila: I just did a couple of very quick reviews for you
<spiv> And now I'm off!
<vila> great !
<vila> have a nice week-end !
<spiv> Happy hacking, piloting, and babune-wrangling.
<spiv> And have a nice weekend when you finally get there :)
<vila> Riddell: hello there !
<vila> Riddell: I realized my comment on your https://code.launchpad.net/~jr/bzr/330063-merge-non-existing/+merge/61728 may need explanations about bb:tweak
<vila> Riddell: or do you understand the meaning already ?
<Riddell> it means tweaking the blackbox tests?
<vila> hehe no
<vila> BB == bundle buggy, that's what we used before reviews were available on lp
<vila> different votes were available there and we still miss the 'tweak' one on lp
<Riddell> ah
<vila> we use it to convey: your patch looks good, you can land it without an additional review as long as you agree with the modifications asked by the reviewer and implement them
<vila> but shorter ;)
<vila> since this doesn't exist on lp, we use an idiom which is: review: needsfixing, status: approved
<vila> Riddell: do you need further help with this proposal ?
<Riddell> hopefully not, I'll get to it shortly once I've looked at my e-mail (I was taking a swap day yesterday)
<Riddell> but I'll let you know if i do :)
<vila> Riddell: ok, cool, welcome back :)
<spiv> vila: heh, TestImportTariffs.start_bzr_subprocess_with_import_check explicitly uses the real $HOME!
<spiv> vila: so you could argue that including ~/.bzr.log in the details is therefore appropriate ;)
<vila> oh my, I routinely have Megs there !
<vila> I just didn't look at the result of my first run even if it was limited to ~10 tests, imagine what it will contain for a whole test suite !
<spiv> vila: it's just TestImportTariffs
<vila> Megs * ~20.000, we will end up with GOs !
<vila> ha right, still we will end up with gOs :)
<spiv> It shouldn't be much:
<spiv> * details are discarded for passing tests
<spiv> * only TestImportTariffs uses start_bzr_subprocess with a real $HOME
<spiv> Worth checking my assumptions are right, of course.
<vila> why not make them use a temp home then ?
<spiv> But they should be ;)
<spiv> â        # Normally we want test isolation from the real $HOME but here we
<spiv>         # explicitly do want to test against things installed there, therefore
<spiv>         # we pass it through.
<spiv> â
<vila> argh
<spiv> i.e. test_import_tariffs wants to make use ~/.bazaar/plugins
<spiv> There's probably a better way to do that
<vila> we rotate at 4M I think
<spiv> Maybe set BZR_PLUGIN_PATH for the subprocess to explicitly be exactly what the parent uses
<vila> that's 2M of noise on average ;-/
<Riddell> vila: should I be on the patch pilot schedule?
<spiv> vila: I don't follow
<spiv> vila: it only keeps the log contents if the test fails
<spiv> vila: so normal cost: 0
<spiv> vila: no matter how large ~/.bzr.log is for that one test
<vila> Riddell: up to you, feeel free to insert yourself, probably at the end of the cycle so you get some time to accomodate
<vila> spiv: meh, maybe I misread your patch but I thought your were installing some automatic trigger for all subprocess calls ?
<spiv> vila: for all start_bzr_subprocess calls
<spiv> vila: but for all tests *except* TestImportTariff $HOME is some temporary directory
<spiv> vila: and all in-process logging goes to an in-memory log during selftest
<spiv> vila: so the only contents it will find are from test subprocesses, with the exception of TestImportTariff
<spiv> (Ok, the doctests use real bzr $HOME too, but I don't think they use start_bzr_subprocess)
<vila> spiv: right, worth adding as comments then, I'll look into it again later (I thought I said that in the review no ?)
<vila> anyway, thanks for the explanations, will avoid useless roundtrips
<spiv> vila: sure, just some drive by info as I was peeking at my mail :)
 * Riddell blogs http://www.kdedevelopers.org/node/4435
<Morbus> here's an odd question: is there anyways, from bzr command line, to "know" if someone has proposed a merge request?
<maxb> Riddell: 1) Nice. 2) I'm confused by your user icon. 3) s/zx/xz/
<Morbus> i have a private lp account, and I need to integrate it with some CI tools, and it requires me knowing merge requests.
<maxb> Not via the bzr command line, no
<Morbus> damn. ok.
<Morbus> so i instead need to figure out some way of automating a browser request to the LP MR page.
<Morbus> which would normally be easy if it were public, but it's private.
<Riddell> maxb: the user icon comes from Umbrello which was my university project back in the day
<Riddell> Morbus: can't you use launchpad APIs?
<Morbus> Riddell: didn't even know LP had APIs :)
<Riddell> take a look at https://help.launchpad.net/API/launchpadlib
<Riddell> I'm not sure if merges have APIs, but they ought to if there's any justice in the world
<Morbus> heh, heh.
<Riddell> ask in #launchpad to find out
<maxb> Morbus: You probably want to look at the Launchpad Web Services API, and in particular, if you use python and launchpadlib, lp.branches.getByUrl(url="lp:.......").getMergeProposals(...)
<Morbus> of course, i don't know any python, but i could figure it outl, I suspect.
<Morbus> maxb: thanks!
<Morbus> Riddell: you too :D
<Morbus> hrm. if it's just a webservice that seems to export JSON, I shouldn't have to use python lib...
<maxb> Python is not the only integration possibility, but it is the one with the most advanced client libraries
<Morbus> sure.
<Morbus> i don't necessarily need a whole shebang - i /just/ need the list of branches that have a merge request in.
<Morbus> everything else i can handle from the command line locally.
<maxb> Morbus: Try hitting this URL, then: https://api.launchpad.net/1.0/~bzr-pqm/bzr/bzr.dev?ws.op=getMergeProposals&status=Approved
<Morbus> maxb: right. i presume that's protected by the same cookie auth as a private project is?
<Morbus> cookie/session auth?
<maxb> If it works, that's accidental.
<Morbus> how do you mean?
<Morbus> private thingies aren't supposed to be in the API?
<maxb> The api.launchpad.net vhost is supposed to be accessed via OAuth tokens for authorization
<Morbus> ah.
<Morbus> does the pythonlib handle that too?
<maxb> yes
<maxb> Launchpad.login_with is the main entry point for authenticated access
<Morbus> hrm. i think i tweaked this wrong: https://api.launchpad.net/1.0/~morbusiff/examiner/trunk?ws.op=getMergeProposals&status=Approved
 * maxb disappears for lunch, back ~15mins
 * Morbus heads off to try the pythonlib.
<maxb> or 5mins as the case may be
<maxb> Morbus: Try hitting https://launchpad.net/api/1.0/~morbusiff/examiner/trunk?ws.op=getMergeProposals&status=Approved with your cookie
<Morbus> same error.
<Morbus> Object: <lp.registry.model.personproduct.PersonProduct object at 0x12fd1fd0>, name: u'trunk'
<maxb> Hm
<maxb> No idea then, sorry
<Morbus> i woudln't worry too much about it now. got launchpadlib installed and i'm gonna fiddle with that for a bit.
<maxb> Probably time to hop over to #launchpad for any further questions
<__monty__> If I want to rename a branch can I just rename the directory?
<__monty__> Or can I use bzr mv oldbranch/* newbranch/   ?
<maxb> just rename the directory
<__monty__> ty
<Morbus> hrm. where does this launchpadlib store the OAuth details I'm abotu to put in?
<Morbus> the script will be running as a different (non-Unix) user than my current Unix user, so I don't want it to overwrite my own data.
<Morbus> wrong chan.
<Riddell> ug, I keep using the broken "s" for submit option on feed-pqm
<Riddell> lifeless: is it true you have a good reason for keeping that around?
<vila> Riddell: hehe, was just reading such emails :)
<Riddell> poolie: if you add me to ~hydrazine-core I'll set up daily builds so the packaging is no longer a year out of date
<Riddell> I might also get rid of the broken "s" option on feed-pqm while nobody is looking :)
<vila> Riddell: Propose a branch for merge, I run from sources ;)
<lifeless> Riddell: nope
 * lifeless disappears
<Riddell> oh good
<vila> spiv: wake up ! wake up ! I have good news !
<vila> spiv: what ? Not even 1AM and you're not there... Sheesh
<vila> For the rest of the crowd: one source of selftest hanging on babune shut got a head-shot, thanks to spiv ;)
<vila> For the rest of the crowd: one source of selftest hanging on babune just got a head-shot, thanks to spiv ;)
<vila> just not shut... tyops are back
<vila> I blame fullermd
<mgz> it's generally his fault.
<mgz> vila: can you run a branch of mine on one of your forking babune slaves?
<mgz> I think I fixed the remaining pain, just want to double check before proposing
<vila> mgz: sure
<vila> which branch and which subset ?
<mgz> lp:~gz/bzr/cleanup_testcases_by_collection_613247 as always hang fix before r
<mgz> ...interesting edit
<mgz> that branch, but merge in whatever you need to make a full run work too.
<vila> say that again ?
<mgz> so, the import tariff hang fix if that was an issue on the slae
<mgz> *slave
<vila> I'd prefer a significant subset, not *all* hangs are fixed, I have a couple of pretty good silver bullets now tough
 * mgz blames vila's infectious typos
<vila> hehe
<vila> justasec, a couple of zombies to kill first
<mgz> `-s bb. -s bt.test_` isn't bad, but I want a full run to compare resource usage really
<mgz> I got it through a complete selftest on the laptop (after stopping X, had som OOMs trying to fork otherwise), so it should run inside 240MB or so
<vila> hmm, a full run will be more complex *right now*, let's try with the subset and ping me again if I forget the full one
<mgz> okay
<vila> but how will you check resources usage on babune ?
<mgz> but parallel=fork please, and optionally -Euncollected_cases
<mgz> ^...it doesn't give metrics? er... speed I guess then.
<vila> hmm, you know what ? File a bug on lp against babune so I can better track that
<vila> yeah, speed could be a good indirect indicator
<vila> hmm, bt.test_ will include tariff, no good, can *you* merge lp:~vila/bzr/import-tariff-test-subprocess-deadlock  instead ?
<vila> can we start with -s bb instead ?
<mgz> okay, -s bb. then
<vila> or is it not good enough ?
<mgz> that should be clean though.
<vila> mgz: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/109/aggregatedTestReport/
<vila> crap typo in the branch name ;)
<mgz> ehhee
<mgz> add -s bt.test_selftest to the subset if you've not restarted yet
<mgz> that should give some output
<vila> I did, but it' soon enough to cancel
<vila> hmm, 3 slaves running concurrently, if bad things happen, don't take the blame...
<vila> ...or not too fast ;)
<vila> http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/111/aggregatedTestReport/
<vila> mgz: gentoo failures already available, shallow ?
<mgz> hm, that's the hard test case.
<vila> mgz: same number on freebsd, karmic, osx (macadam is osx)
<vila> Oh, I didn't specify -Exxx
<vila> if that helps...
<mgz> should work anyway, but those failures are from trying to exercise the parallel=fork code
<mgz> which is... tricky
<vila> unexplored territory.. unfortunately
<vila> mgz: which makes me believe you're not splitting your proposal enough :-D
<mgz> the code needs to work...
<mgz> I can continue landing things that don't actually fix the issue for ever
<mgz> but maybe I'll split fixing parallel=fork from the rest.
<vila> mgz: well, -Euncollected_cases as a first step would be good to start with no ?
<vila> mgz:  if it requires *not* using --parallel, I'll still buy it
<mgz> not if it prints every single test case when you run selftest with --parallel=fork :)
<vila> mgz: I can live with such a limitation as long as it doesn't break --parallel=fork when I *don't* use it !
<vila> mgz: if we reach the point where the test suite can fully run without OOMing that would make me extremely happy
<mgz> what's the subunit version on those slaves?
<vila> hmm, close to trunk I think, except for the osx one maybe
<vila> oh no, even the osx one mounts my source dir
<mgz> and testtools?
<vila> so, trunk for subunit
<vila> hey, let me type :)
<vila> trunk too
<mgz> hum hum.
<vila> but that's not true for the chroots (but you don't care at that point (OMG this is becoming complex again :-/)))
<mgz> I'll have to boot the laptop again, darn 2.6 requirement
<vila> ha
<vila> I updated this week after months of using very old versions...
<mgz> hm, passes here. wonder if it's something about being a real multicore machine.
<vila> not passing here
<vila> just a note:
<vila> have a look at my last --exclude ORed proposal for a trick to use short names for tests, you will then be able to use assertEquals instead of assertContains
<vila> no big deal but I feel better not using regexps when I can avoid them
<mgz> yeah, saw that.
<mgz> still need contains, because it looks at the whole output
<mgz> which is good here, because it tells me no tests are being run under fork
<mgz> ...not sure why though
<mgz> anyway, problem with the test not the case cleanup code
<vila> http://paste.ubuntu.com/613816/
<vila> after running ./bzr selftest -s bt.test_selftest
<vila> I'll ignore the two errors blaming some weird merge
<mgz> ...and there it's the reverse problem
<mgz> all the cases are leaking
<mgz> but the test works.
<vila> ha crap, forgot =-site
<vila> ok single error, s/<above>/&/ :)
<mgz> ...does that help? if not, I'd check bzrlib.tests.fork_for_tests and make sure the two list emptying statements survived the merge
<vila> what ? You pushed ?
<mgz> nope.
<mgz> I'm just trying to understand your results
<mgz> ...I'm not sure I have ssh to any machines with python 2.6
<vila> oooh, I love "notify = "uncollected_cases" in selftest_debug_flags" :D
<vila> mgz: lol, reading your patch, tu quoque mi fili ! using test_suite_factory :)
<vila> mgz: but you don't support the arguments, a bit more risky but good enough here
<vila> mgz: come to think of it, the conditional code in sefltest for test_suite_factory may be better *outside* of tests.selftest
<mgz> there are quite a lot of oddities with how code is arranged for selftest
<vila> or rather, always called in the same way
<vila> yeah, history
<mgz> even having taken an axe to decorators, they're still a pain in the bum
<mgz> I can't get a simple param from run_suite down to the code that does the forking
<mgz> so have to monkey patch subunit
<mgz> I'm still none the wiser about why the slaves didn't manage to run the forking test correctly
<vila> only 3 failures on windows
<vila> can't you just override the forking code ?
<mgz> no fork! ... and they look very familiar failures I thought we'd fixed in the past.
<mgz> basically about trying to read a locked pack file.
<vila> huh ? Those are new to me... may be I didn't notice them earlier ? Worth investigating
<vila> but right, not now, indeed, different failures
<mgz> ^I want to test the actual code that selftest uses to do the test splitting and forking, because it has issues now
<mgz> I don't like fixing problems if I'm not testing that they won't regress
<vila> I was suggesting wrapping them to address your params passing issue
<mgz> the problem is there are already too many wrappers :)
<vila> nah... the functions you're after are not *yet* wrapped ;D
<mgz> can you re-run the subset with the flag on?
<mgz> ...I don't think it'll help me understand why the fork tests aren't happy on babune, but I'm out of ideas
<vila> fired
<vila> mgz: I wonder if your overrides survives the fork...
<mgz> ooh, interesting
<vila> ...or something
<vila> may be silly but since you ran out of ideas, I'm trying to help :D
<mgz> of course I've not been running the whole suite under --parallel=fork here
<mgz> I'll see if I can get the failure by forcing that
<mgz> yeay!
<mgz> I can repo.
<mgz> okay, will fix.
<mgz> ...also, annoying, you don't get a full test count with --parallel=fork just a running total of completed tests
<mgz> thanks vila!
<vila> me ? Thank my daemon, he send me stupid ideas all day !
<vila> mgz: seriously, I have no idea why you're thanking me... any hint ?
<mgz> your suggestion was enough to tell me how to reproduce the failures babune got locally
<mgz> if I can reproduce, I can fix.
<vila> haa, great !
<mgz> so, the why might be wrong, but the wondering was useful
<smoser> vila, or maxb, could someone handle bug 788736 for me ? if its not a terribly painful thing.
<ubot5> Launchpad bug 788736 in Ubuntu Distributed Development "python-boto parallel import repair" [Undecided,New] https://launchpad.net/bugs/788736
<__monty__> u
<vila> smoser: justasec, just found it the mail in my backlog (and this has been a busy day...)
<__monty__> vila are you online
<vila> __monty__: yes, but expect lag, I should have stopped working already ;)
<__monty__> vila: About the error for which I'm trying to add a test, do you have any idea why the result differs for you and me?
<vila> __monty__: I don't know *what* result you get, but search for socket.error in the code base, there are plenty of cases where the same pattern occurs (EPIPE among others)
<vila> smoser: on it
<vila> smoser: branches overwritten, deleting tags
<vila> smoser: expectedly getting No such tag errors :)
<vila> maxb rocks...
<Daviey> vila: Whilst looking at that one, fancy actioning maxb's suggestion for sysvinit :) ?
<__monty__> vila: Could you glance at the results I get for selftest? https://code.launchpad.net/~toonn/bzr/socket.error-traceback-393713/+merge/62585
<vila> smoser: requeued
<vila> smoser: running
<vila> Daviey: meh, which one ? I think I requeue that recently
<Daviey> vila: https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2011-May/000807.html :)
<vila> Daviey: :-/ I don't know enough there to act without maxb
 * maxb waves
<vila> rejoice !
<vila> maxb: sudo what ? :D
<maxb> I guess the first thing we need to do is decide which of my proposed options w.r.t. sysvinit we are going to go with
<maxb> Daviey: How anxious are you to get this sorted?
<Daviey> maxb: today doesn't matter
<maxb> I would quite like to get james_w's opinion on my email
<vila> smoser: comment on the bug when you get some results. Thanks in advance
<Daviey> maxb: Throwing away the trivial merge doesn't seem to matter, but it's not a really a good generic fix IMO.  As it's not ideal for other situations
<vila> __monty__: just a sec
<Daviey> vila: thanks for looking into it
<maxb> Daviey: Agreed. Though, the situation that sysvinit is in on Launchpad, with some Ubuntu branches existing but no Debian branches existing, should never occur naturally anyway
<vila> Daviey: np, thank maxb ;)
<Daviey> maxb: I blame smoser.
<maxb> So I'm guessing that someone has been doing some manual fiddling there anyway
<maxb> eh?
<maxb> Have we crossed sysvinit and python-boto?
<Daviey> no, i just enjoy blaming smoser for generic things.
<smoser> i probably did it.  i am constantly fighting with bzr. it sees things differently than i do.
<vila> __monty__: ok, so what OS are you on ?
<vila> Oh, oSX
<__monty__> vila: os X.6
<smoser> and since i don't have a 'smoser' to blame like Daviey does, i usually just blame bzr.
<__monty__> vila: no os X.5.8 (sry)
<vila> __monty__: ha ha, an OSX 10.5 user using python2.6...
<vila> __monty__: you know what ? We may have more interesting bugs for you :) But let's focus on that one first
<__monty__> vila: Sure.
<vila> sockets can raise different kind of execptions depending on the platform so you need to be ready for that
<__monty__> vila: Anywhere I can find what exception they raise on what platform? Or how do I handle this?
<vila> __monty__: we care more about catching all the relevant ones that tracking which platform track which kind, so try grepping the sources for socket.error
<vila> __monty__: more concretely, what you should check is not the *message* but rather the class of the exception and then the associated args
<vila> you should find plenty of examples in the code
<__monty__> Indeed, they are plentiful.
<vila> __monty__: so, if you start working again, it's better to put your mp into the 'Work In Progress' state
<vila> __monty__: because it will pop up in the list again once you put it back to 'NeedsReview'
<__monty__> Ah yes, hadn't thought of that.
<maxb> Argh, what?! The python-boto reimport has somehow retained the revisions that were not supposed to be there?!
<__monty__> vila: Care to give me another clue? I don't really understand what to learn from the examples in the code.
<vila> __monty__: sorry, was afk
<vila> so, what are you trying to test exactly ?
<__monty__> vila: I'm working on the test for the socket.error which apparently behaves different on linux(?) and on os X.
<vila> right, I got that, but why are you doing that ? What is your final goal ?
<__monty__> Proving that the socket.error is allready caught? Because it's a subclass of IOError.
<smoser> maxb, so any ideas?
<smoser> it looks like the score is still :  smoser's stupidity: 1, bzr: 0
<poolie> hi all
<vila> __monty__: then you want a test that succeeds at catching IOError but fails at catching socket.error ?
<vila> poolie: wow, hey !
<vila> poolie: is it late for me, early for you or both ?
<poolie> :) early for me
<vila> rats, I thought I could stop and enjoy my week-end ;-D
<poolie> :) well, you can
<poolie> isn't it something like 9pm there anyhow?
<poolie> i just thought i'd poke at some discretionary lp patches since i'm up so early
<vila> one last bug !
<vila> :)
<__monty__> vila: No I don't think so. Because IOError is allready handled by test_trace.py and socket.error is a subclass thereof (since python 2.6) the cause of bug 393713 no longer produces a traceback. I am now trying to add a test that proves this. So the bug can be closed.
<ubot5> Launchpad bug 393713 in Bazaar "[master] socket.error causes a traceback" [Medium,Confirmed] https://launchpad.net/bugs/393713
<vila> __monty__: if you raise a socket.error and have two exception handlers, one for IOError and one socket.error, if socket.error is a subclass, the IOError handler will trigger, if not, the socket.error handler will trigger, which one triggers tells you if your proof is correct
<__monty__> Ah, like so. So I try catching IOError first?
<vila> __monty__: just try ! That's what tests are for ! Experimenting with your understanding of the code !
<__monty__> Still, I don't really understand how the tests work. Is there someplace I can read up on them? My main difficulty with them is that the except blocks are just 'pass'ed and then the error string is checked.
<vila> __monty__: try adding a self.debug() at the first line of your test and execute it step-by-step under pdb, that should help you understand how it works
<__monty__> vila: How do I run it in pdb? import pdb; import bzrlib.tests.test_trace; pdb.run('test_format_sockets_error()')    ?
<vila> __monty__: try adding a self.debug() at the first line of your test
<vila> __monty__: and just re-run ./bzr selfest
<__monty__> vila: Can I go on step by step? Because now it just stops, then I type continue and the results for selftest are shown.
<poolie> vila, tests using threading seem highly likely to be flakey
<poolie>  except KeyboardInterrupt, e:
<poolie>             out, err = e.args
<poolie> wow that's quite creative
<vila> __monty__: you don't know how to use pdb ?
<poolie> well, good luck to you
<poolie> __monty__: to step, use 's' or 'n'
<poolie> the latter steps over function calls
<__monty__> vila: No, but 'step' seems to do the trick.
<vila> doh, I'm tired, that was a silly question :(
<vila> __monty__: http://docs.python.org/library/pdb.html?highlight=pdb#module-pdb
<vila> poolie: I disagree
<__monty__> vila: I allready have that open, it's just I don't really see what's the point in using pdb. I can go over the code just reading it no? It doesn't seem to give me extra information.
<vila> poolie: they are flaky only when they are buggy, at least that's my experience based on debugging the thread leaks
<vila> poolie: most of the bugs where bad synchronization
<vila> __monty__: you said you didn't understand how the tests worked, the best way to understand them is to see them run, just reading them reading doesn't have the same taste ;)
<vila> poolie: s/where/were/
<vila> poolie: and unsurprisingly here, that's still a race, involving processes instead of threads but still a race
<__monty__> vila: What I meant was, why is(are) there except blocks if they don't do anything?
<vila> __monty__: try removing them and you'll soon realize they *do* something
<poolie> monty, where?
<vila> __monty__: probably swallowing an execption
<__monty__> Ah, didn't realise that a trp
<__monty__> *Ah, didn't realise that a try block still raises the error if it's not handled.
<poolie> it's not so much it still raises it, it just doesn't stop it propagating
<__monty__> vila: I'm still not sure about what you said earlier, 'the handler that's triggered will proof socket.error is a subclass'. Why should I proof that, it is true(since python 2.6). I think what I need to proof is that the socket.error is allready handled in test_trace.py, no?
<__monty__> poolie: Thank you for correcting.
<vila> __monty__: I don't know, does test_trace catch IOError ?
<__monty__> Yes.
<vila> that's not what your test is showing
<__monty__> vila: That's true but how do I show that?
<vila> we're running into cycles, where did you start ? What was failing ?
<vila> __monty__: the bug report says: "I think that on python2.6 (which is required for bzr2.4) this bug will be implicitly fixed because socket.error has become a subclass of IOError, which does not generate a traceback. We should test that though."
<__monty__> nvm what I was typing. In short that's the reason for the test ^.
<vila> __monty__: that's what I described above: proof that IOError is a subclass of socket.error, this can be as simple as assertIsInstance(socket.error(), IOError) or assertTrue(issubclass(socket.error, IOError)) or a bit more detailed as I explained above
<vila> if you want to go further then you need to find a case which indeed raise a socket.error, explore the call stack, remove the now useless socket.error handlers and check (with tests) that the behavior is still the same
<__monty__> vila: What socket.error handlers are you talking about?
<pl0sh> hey guys, how can I publish my branches on my own server?
<vila> any try block with a except socket.error clause
<vila> pl0sh: by allowing people to connect to your server with any protocol supported by bzr: ftp/http/ssh/bzr
<vila> pl0sh: the setup ranges from none to quite sophisticated depending on the protocol
<pl0sh> let's say http, because my dev's uses winsucks, but my server is a freebsd box
<poolie> pl0sh: do they need read write or readonly access?
<poolie> if they're developers i guess rw?
<poolie> the easiest thing then is to let them ssh in and run bzr over ssh
<poolie> the bzr windows client includes ssh support
<__monty__> vila: I think I don't really understand the problem then. I thought what I was trying to solve was the fact that people got a traceback when a socket.error occured. Bug 364462 is what I started on but poolie(I think) pointed out it's a dupe of 393713.
<ubot5> Launchpad bug 364462 in bzr email commit hook "smtp "connection timed out" causes full stack trace to be dumped (dup-of: 393713)" [Medium,Confirmed] https://launchpad.net/bugs/364462
<ubot5> Launchpad bug 393713 in Bazaar "[master] socket.error causes a traceback" [Medium,Confirmed] https://launchpad.net/bugs/393713
<pl0sh> poolie well, they have to be able to commit and merge the changes
<poolie> monty, where are you with it now?
<poolie> ok, so bzr+ssh is the way to go
<pl0sh> Ok, where can I find some info?
<__monty__> poolie: Still nowhere pretty much.
<pl0sh> I have installed bzr on my freebsd and on my windows boxes
<poolie> pl0sh: there's an admin guide
<poolie> but, basically, start an ssh server on the bsd box
<poolie> then just from a windows box run eg
<poolie> 'bzr init bzr+ssh://bsd/~/test'
<pl0sh> great
<pl0sh> and bzr push bzr+ssh://bsd/~/test right?
<pl0sh> to push changes to the repo
<flacoste> is there an easy API in bzrlib available to get the LP API branch URL from a working tree?
<flacoste> i have a working tree of a branch on lp and want to make API call on its LP representation
<poolie> hi flacoste
<flacoste> hi poolie
<flacoste> i was about to try
<poolie> pl0sh: correct
<poolie> i think there is one in plugins/launchpad
<flacoste> from bzrlib.plugins.launchpad import lp_api
<flacoste> lp_api.from_bzr(lp, branch)
<__monty__> poolie: I'm trying to write a test for 393713 but I'm not sure what to write in it. (Doing this because you say in comment #4: 'We should test that though.')
<poolie> flacoste: so is that ok
<flacoste> poolie: still writing the script :-)
<flacoste> from the look of it, it seems like it's exactly what i need
<poolie> flacoste: separately i was wondering if you could nudge lp reviewers to land more approved 3rd party patches
<poolie> not me, other peolpe
<poolie> if you want to add a tip to the api guide docs or wiki page that would be welcome
<poolie> what are you writing, just for curiouisyt?
<vila> g'night all, have fun !
<__monty__> vila: gn, thanks for helping.
<flacoste> poolie: a script to make a principia package branch official
<poolie> monty, have you pushed your current code?
<flacoste> poolie: inspired by set_official.py in udd but less coupled to the package-importer implementation
<poolie> i'll have a look at the review
<poolie> cool
 * __monty__ nudges poolie to stop ignoring his question? :)
<flacoste> poolie: people approving a third party branch are supposed to take care of landing it, isn't that happening?
<poolie> apparently not
<flacoste> poolie: remember that it's not visiale if they have submitted it to ec2test and it will take some time to update
<poolie> just sliping through the cracks i think
<flacoste> well, i'm seeing 3rd party branches merged
<flacoste> nigelb and chris' one
<flacoste> which one haven't landed?
<poolie> like https://code.launchpad.net/~james-w/launchpad/more-matchers/+merge/32057
<flacoste> it's lifeless here that needs nudging
<poolie> 3 from chrisjohnson
<flacoste> he might not be aware of it
<poolie> oh to rereview it?
<flacoste> he approved it
<poolie> i've just put one of chris's up for ec2
<pl0sh> poolie thanks
<poolie> i'm not saying it never happens, just it apparently doesn't always happen
<poolie> i am very happy chris & others got prompt reviews
<flacoste> i can send a reminder
<poolie> vila, you just need a couple of tweaks to the utextwrap thing
<poolie> __monty__: sorry, not trying to ignore you
<poolie> show me the test you have currently?
<poolie> if any
<__monty__> poolie: It's worthless currently.
<poolie> i thought yesterday we got up to having a test based on the other error-reporting tests
<poolie> that raised a socket error and then checked it was printed in a reasonable way
<poolie> did that break?
<__monty__> Well, turns out the error message is different on different platforms.
<poolie> oh, that's too be expected, yeah
<ironcamel> has anyone got bzr bisect to work http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html ?
<poolie> the main thing we want to assert in the test is just that it does not give a stack trace
<poolie> ironcamel: what specifically is going wrong?
<ironcamel> poolie: i installed it, but bzr bisect doen't do anything
<ironcamel> bzr: ERROR: unknown command "bisect"
<__monty__> poolie: Agreed, so just test the string for not containing 'traceback' ?
<poolie> how about 'bzr plugins -v'
<poolie> __monty__: i think it's "Traceback" but yes
<ironcamel> poolie: it's not listed
<poolie> how did you install it?
<ironcamel> poolie: python setup.py install
<ironcamel> got the source from https://launchpad.net/bzr-bisect
<poolie> hm, i wonder where that installed it to?
<poolie> perhaps something that's not on your bzr plugin path
<ironcamel> not sure
<poolie> typically you'd install from source with just eg
<poolie> bzr branch lp:bzr-bisect ~/.bazaar/plugins/bisect
<ironcamel> oh really
<ironcamel> it comes with a setup.py, so that's why i did that
<ironcamel> poolie: i think that did it :)
<ironcamel> a little documentation would have made this easier
<poolie> please file a bug against it about the setup.py not doing the right thing
<ironcamel> sure
<ironcamel> done
<__monty__> poolie: This is what the test should look like right? https://code.launchpad.net/~toonn/bzr/socket.error-traceback-393713/+merge/62585
<poolie> looks pretty good
<__monty__> Ok, then I'm off, thanks for the help. Hope I can work on a different bug tomorrow. :)
<smoser> hm... lp:ubuntu/nagios-plugins seems to be screwed up the same way python-boto is.
<smoser> opened bug 789342 to address that.
<ubot5> Launchpad bug 789342 in Ubuntu Distributed Development " lp:ubuntu/nagios-plugins gives strange diffs" [Undecided,New] https://launchpad.net/bugs/789342
<poolie> thanks smoser
<mgz> poolie, did you get a chance to look at my additions to your stale locks branch?
<mgz> I... was slightly losing track last night but I think the code makes sense
<poolie> mgz i did merge it in
<poolie> thanks for that
<poolie> i have some more items from spiv still to fix
<poolie> at the moment i'm just finishing off some pending lp work
<mgz> in unrelated bookkeeping, do I need to bug someone for an expenses form for last week?
<poolie> yes, marianna
<mgz> will email.
#bzr 2011-05-28
<mgz> hm, spotted more things that need fixing in blog post from cross-eyed late night editing
<mgz> where's the edit button for your poolie?
<mgz> I can see the post on edit.php but no way to... actually alter the content
<poolie> hm maybe you don't have permission
<poolie> i'll check
<poolie> mgz try now?
<mgz> that looks better, thanks!
<mgz> ...while I'm bugging you, I pushed an extra change to the stale locks branch after I'd gone, because I got the error code wrong
<mgz> you may have pulled after that anyway
 * mgz stops being a bother now
<poolie> no bother at all
<poolie> thakns
<poolie> we should put up a photo or something too...
<mgz> did any of your phone ones come out okay?
<poolie> yeah, a bit
<poolie> they're a bit blurry
<poolie> i will upload them and have a look
<mgz> or does having a big impressive camera normally make you picky about quality... :)
<mgz> riddell put up the group one from the end of the sprint in his post
<poolie> mm i just saw it
<poolie> hm
<poolie> i might go for a ride
<mgz> sounds like a plan. what's the weather like?
<pl0sh> poolie just a question,  in what path do I have to place my repos?
<pl0sh> *on my freebsd box*
<spiv> vila: glad to hear it!
<gypsymauro> hi
<gypsymauro> I've created a new local repository, how can I move it to a centralized one?
<Kamping_Kaiser> i know iv'e asked this "in the past", but i'm wondering if things have changed. is the 'correct' way to commit only part of the hunks in a file to shelve those you don't want then commit?
<vila> Kamping_Kaiser: AFAIK, yes
<Kamping_Kaiser> vila: thanks
<vila> Kamping_Kaiser: I'd love to have a better way to do that from my $editor
<vila> Kamping_Kaiser: the ability to commit to a different branch than the one I'm currently working on won't hurt either ;)
<Kamping_Kaiser> vila: a --selected switch to only commit hunks found in $editor would be rather nice (i won't be offering the patch though :/)
<Kamping_Kaiser> vila: i can see the use, thankfully i  don't deal with code enough to need it :)
<vila> :D
<Kamping_Kaiser> :}
<vila> Kamping_Kaiser: filing a bug (or searching for dupes and metoo'ing) would be a good start
<vila> it helps to have real use cases to define the feature and have a rough idea of who is interested
<Kamping_Kaiser> vila: hadn't thought to look for existing bugs, i'll have a go now
<vila> Kamping_Kaiser: thanks
<Kamping_Kaiser> ftr, i found bug 307285 which mentions an interative plugin. i'm going to try and find that
<ubot5> Launchpad bug 307285 in Bazaar "Support interactive commit" [Medium,Confirmed] https://launchpad.net/bugs/307285
<Kamping_Kaiser> ftr, lp:bzr-interactive
<vila> ... the last time I heard about that I ended up with shelve --interactive being available in core...
<vila> Kamping_Kaiser: tell me about your findings so I can upgrade my brain ;)
<Kamping_Kaiser> vila: thats about it. last commit to bzr-interactive was 2009-03-24
<Kamping_Kaiser> i might comment on the bug above
<vila> hmm, I remember that one the key feature is the ability to split hunk, which shelve --interactive supports, I wonder what bzr-interactive was exactly
 * vila will read bug #307285
<ubot5> Launchpad bug 307285 in Bazaar "Support interactive commit" [Medium,Confirmed] https://launchpad.net/bugs/307285
<Kamping_Kaiser> interactive still seems to work on bzr in debian stable. throws some deprecation warmings on bzr trunk
<Kamping_Kaiser> 'seems to work' means i ran bzr ci -i and its ofering me hunks (i dont want to commit any changes atm though)
<vila> Kamping_Kaiser: so the plugin adds an option to the commit command ?
<Kamping_Kaiser> vila: yep, adds -i/--interactive to commit, and from teh description other builtins too
<vila> Kamping_Kaiser: ok, thanks
 * vila upgrades brain
<__monty__> vila: Are you online?
<pl0sh> hey guys
<pl0sh> poolie I forgot to ask you yesterday where should I place my repo's folder? -- at my freebsd box --
#bzr 2011-05-29
<vila> pl0sh: branches will automatically find a repo above them in the file system hierarchy, if the repo is on a server, readers/writers client need to be able to access it on the server
<vila> pl0sh: this is valid for all protocols between the client and server. bzr+ssh is the most efficient implementation these days and as such the preferred one if bzr is available on the server
<vila> pl0sh: which is true for freebsd
<masklinn> using fast-export/fast-import to convert a repo from hg to bzr seems to flip around a number of merge commits, resulting from a "mainline" (log withou -n0) composed of the commits of the merged branches, rather than the commits from trunk/default/whatever. Is this a known issue? Is there a way to fix it?
<masklinn> the repository looks correct on the hg side, with the "trunk" being the straight mainline and the rest branching from/merging into it.
<maxb> masklinn: That seems pretty weird. You should probably begin by finding out if the flipping has occurred in the export or the import - i.e. is the fastimport data stream correct
<masklinn> maxb yep, checked further (by trying to trip through git as well), the issue is at the export from hg (I'm guessing bzr's hg export script and the hg-fast-export one for git floating around have the same origin, they yield the same flipped merge commits)
<masklinn> So I tripped through git via hg-git before importing back into bazaar, and that worked
<lode> Hi
<lode> Anyone here knowing where to suggest a new translation / report a translatopn bug in the bzr explorer diff tool?
<poolie> hi lode, hi vila
<jam> hi poolie, good early morning to you
<lifeless> hi jam
<mathrick> hiya
<mathrick> mathrick@hatsumi:[...]/BMB/tools/lib-overrides$ bzr join cl-gtk2/
<mathrick> bzr: ERROR: File id {TREE_ROOT} already exists in inventory as InventoryDirectory('TREE_ROOT', u'cl-cairo2', parent_id='toolsliboverrides-20110525170907-q1x2hf7rrxb0i21i-1', revision=None)
<poolie> hi there
<poolie> jam, do you want to have a chat now
<mathrick> I get that when I try to join a repo after having previously joined another one
<poolie> mathrick: hi, this is a bug
<mathrick> is there anything I can do to work around this?
<poolie> i recognize it; I don't know a good workaround
<poolie> do you, jam?
<poolie> hm
<mathrick> poolie: ah, pity. Is it known and recorded somewhere?
<mathrick> somewhere being lpad of course :)
<poolie> https://bugs.launchpad.net/bzr/+bug/370710
<ubot5> Ubuntu bug 370710 in Bazaar "bzr: ERROR: File id {TREE_ROOT} already exists" [Medium,Fix released]
<mathrick> thanks
<poolie> so there is a workaround there, though not an ideal one
<mathrick> poolie: hmm, the repo is pulled from github, is it expected then that it'll have a {TREE_ROOT} id?
<poolie> through bzr-git/
<mathrick> yes
<jam> hey poolie. I'm around a bit, but getting close to midnight here. So if it isn't too involved, certainly
<poolie> is it imported by launchpad, or by you?
<poolie> oh, hi
<poolie> i was confused
<poolie> i think i momentarily forgot you weren't still in Chicago
<jam> :)
<poolie> can we set a time for this week, maybe your Tuesday morning?
<jam> poolie: whatever time works for you. Tues AM is good I think
<mathrick> poolie: me, I did bzr clone git://...
<poolie> is 8 too early?
<poolie> mathrick: hm i would have thought if you did that into a format 2a repository it would get a unique root id
<poolie> is it a very old import?
<mathrick> poolie: yes and no, I first imported my old github branch which was made using bzr-git quite some time ago
<poolie> hm actually that'd be 9am
<mathrick> but since I don't need that (I can grab the upstream directly and not pull on top of my own github branch), I'm trying that now
<mathrick> poolie: hmm, no, I still get it
<mathrick> mathrick@hatsumi:[...]/BMB/tools/lib-overrides$ bzr info cl-gtk2
<mathrick> Standalone tree (format: 2a)
<jam> poolie: 9am should work, I usually get back around then after taking K to school. I'm off to bed for now, have a good day
<mathrick> poolie: any idea how I could look into the tree root not getting a proper id?
<poolie> mathrick: so normally the initial add will give it a unique id
<poolie> in bzr 2a formats and onwards
<mathrick> poolie: initial add?
<poolie> the first 'bzr add' after 'bzr init'
<poolie> i don't know if bzr-git is perhaps overriding that
<mathrick> hmm
<poolie> or if it's just that you first made this branch earlier
<mathrick> has jelmer disappeared? I haven't seen him in a long time
<poolie> hm, it may well be overriding it to get deterministic imports
<mathrick> poolie: I retried on a fresh clone and the same happens
<poolie> he was on holiday last week and today (monday)
<poolie> and the week before that we were sprintig
<poolie> he would be the person to ask
<mathrick> poolie: right, but I didn't know about the holiday (though I kinda suspected that)
#bzr 2012-05-21
<wolter> how do I set the source branch of a directory?
<wolter> I have been trying to with bzr switch, bzr pull and I still dont get the current revision
<wolter> I get some merge tips when I run bzr status
<wolter> When I pull it tells me that the branches have diverged and thus I have to merge, I merge and try again but nothing changes
<bob2> bpaste.net output of 'bzr status'
<wolter> bob2, http://bpaste.net/show/2XVKrJcfFLSFgeDA4lxp/
<bob2> you need to either commit the merge or abort it
<wolter> ok, but if I commit wouldn't I keep on having divergent branches?
<wolter> bob2, ^
<bob2> ?
<jam1> morning all
<mgz> morning!
<jam> morning mgz
<vila> morning .gzS
<mgz> S?
<jelmer> mgz: you and your army ? :)
<vila> mgz and wgz :)
<vila> The 'S' was for non-native regexps speakers ;)
<caravel> hello all o/
<jelmer> hi caravel
<caravel> I've introduced bzr for a while in one of my projects, and got windoz users to use it w/ Tortoise, Here I use Fedora 16 KDE, cli works great :)
<caravel> I've acivated Bazaar KDE service as avail under 4.8.3, but it doesn't seem to work :
<caravel> all I get, when I enter one of the repo folders in Dolphin, is a statusbar message : Update of version information failed."
<caravel> nb, this is a local shared repo with bzr+ssh branched trees inside, and ssh is configured fine w/keys (i.e. no pwd needed while using the cli)
<caravel> (I also use Bazaar explorer and QBazaar, these worked fine the few times I tried them)
 * caravel wouldn't mind getting the same level of visual comfort as in the past with tortoise/cvs/svn under windoz, that's pretty efficient "when it works", even thou it costs a few resources :)
<mgz> caravel: is there anything with that message in your .bzr.log file? `bzr version` will tell you where to find it
<vila> jelmer: did you notice bug #1001270
<ubot5> Launchpad bug 1001270 in bzr email commit hook "recent refactoring removed send_text_and_attachment_email" [Critical,Confirmed] https://launchpad.net/bugs/1001270
<jelmer> vila: ah, didn't see that
<jelmer> I guess there's no tests for that bit of the code :(
<vila> there was :)
<vila> but not at blacbox level
<vila> k
<jelmer> vila: I don't see anything in bzr-email that tests it?
<vila> so yeah, not *enough* tests
<vila> tests/test_smpt_connection.py
<vila> tp
<vila> the one you removed ;)
<jelmer> vila: I've merged Bob's fix
<vila> I had no idea, your the only committer there
<vila> (revno 56)
<vila> jelmer: ha, completely misread your remark about Bob, where did you merge the fix ?
<vila> jelmer: lp:bzr-email is still at revno57, no fix there
<jelmer> vila: sorry, pushed now
<vila> jelmer: works \o/
<caravel> mgz: thanks for your answer (just seen it) well, bzr version tells me the log file is /home/myuser/.bzr.log however there is no such file here (?) Using bzr-2.4.2-1.fc16.x86_64 (latest stable in fedora @updates repo)
 * caravel found it .... kate won't open it for some reason, nano does
 * caravel hmm, can open it with kate from cli or using xdg-open, it's just the kate file selector that refuses to open it (?)
<caravel> mgz: ok, so when entering the folder which holds the shared repo, the log complains that there is no checkout subdir - which makes sense. I guess it shouldn't, since it's a shared repo ? http://www.fpaste.org/W1kS/
<caravel> shouldn't *search for a working tree, I mean
<caravel> besides, entering any of the subfolders in dolphin - each holding a branched working tree - does not complain any more. I will check the log next time (thanks)
<caravel> however it spits 6 identical "opening working tree" stanzas in the log, that sounds much ?
<caravel> sorry, they're not identical, u'root'  u'ignored' u'status'  then again u'root'  u'ignored' u'status'
<mgz> caravel: glad that's working now, extra stuff in the log is likely just the dolphin extension doing a bit more work than it needs to
<caravel> mgz: indeed. Well, it's nice to see the folder colour changing to green :)
<caravel> (folder name)
<caravel> mgz: I suppose the behavior on the shared repo is a bug, right ?
<caravel> I'd have another question for today : is that an issue to use 2.4.2.1/Fedora and 2.5.0/Windoz clients simulatneously (from different hosts) to push commits to the same remote branches ?
<mgz> caravel: no, there shouldn't be.
<caravel> mgz: thanks. And how about using both clients to manipulate the same local shared repository, i.e. alternatively from a Fedora host and an XP guest (as running in a VM) ?
<caravel> I mean, not performing actions at the same time, but one after each other
<mgz> that's a little more suspect, mostly due to ntfs/nfs issues
<mgz> depends how exactly you're sharing the filesystem basically
<caravel> mgz: XP guest accessed the folders as network share, so that's vboxfs not ntfs
<caravel> accesses*
<caravel> well, I can't express myself today :)
<caravel> I mean, not a net share, a vbox share -- xp sees it as a network share, but it is not really
<caravel> mgz: as a matter of fact I did init and branch using 2.5.0/xp guest, then pulled using 2.4.2.1/fedora host, and that seem to work transparently :) just fearing some mess if going back and forth
<mgz> provided access really is serialised, and you stick you the subset of filesystem features both xp and nix support, it should be fine
<caravel> right
<caravel> I just need to keep guiding windoz users i.e. screen caps and things sometimes, but wish to to be bound to windoz myself, and 2.5.0 isn't there yet in fedora repo
<caravel> wish *not
<caravel> ok, thanks mgz
<caravel> thanks everyone for the nice progress cf. kde service client, and good day o/
 * caravel will come back with more log if error ever come back :)
<hrw> hi
<hrw> can someone remind me easiest way to cherry-pick commits from one bzr branch to another? something like "git format-patch" + "git am" would be lovely as this also keeps commit message. Now I am doing "bzr diff -cREV" + "patch -p0" but have to commit after it and provide commit message
<jimis> hrw: I've used "bzr merge -r 122..123", you can combine it with -rbranch and get from any branch?
<bj0> what would cause bzr to not use '.bzrignore'
<jelmer> bj0: is it versioned?
<bj0> the .bzrignore file is versioned yes
<bj0> there are 'unknown' files in the directory, if i add them to .bzrignore, they are still listed as unknown.
<jelmer> bj0: can you give an example?
<bj0> you mean like this? http://pastebin.com/Umbhi4CV
<jelmer> hmm, that seems wrong indeed
<jelmer> bj0: what version of bzr are you using?
<bj0> 2.5b6
<bj0> it works for some of my bzr branches
<bj0> most of them actually
<bj0> not sure why this one doesn't work
#bzr 2012-05-22
<gotwig> hey
<gotwig> can you tell me how I can make a bzr commit and push online?
<lifeless> bzr commit; bzr push ?
<gotwig> lifeless: yeah, but on the web.
<gotwig> lifeless: I dont have bzr installed here
<gotwig> lifeless: you know
<lifeless> you could use wikkid
<gotwig> lifeless: whats that
<bob2> a wiki thing that uses bzr
<bob2> likely you just want to isntall bzr though
<gotwig> bob2: -..-
<gotwig> I can't
<gotwig> with git i can use something like koding.com or c9.io
<gotwig> for bzr I dont found anything like that
<mgz> morning all
<gotwig> mgz: jo
<gotwig> I'd really like to use bzr somehow online
<gotwig> so I dont need it on my pc
<mgz> gotwig: I sympathise with that
<gotwig> mgz: like you already can do it with mercurial and git
<gotwig> becouse they are way more popular
<gotwig> at c9.io
<gotwig> or kodingen.com or koding.com
<gotwig> etc., etc.
<vila> then bug the web sites admin to support bzr :)
<vila> the issue is to edit remote files
<gotwig> vila: its not easy for them, too.
<gotwig> and the interesst has to be great
<gotwig> vila: ^, right?
<vila> imho, editing remote files will consume far more bandwidth and suffer latency than the push which is supposed to transfer only the resulting diff (and some overhead)
<mgz> okay, branch proposed with those backports
<mgz> will land and merge up after it gets checked
<vila> mgz: great, waiting for your ping
<mgz> vila: do we want jelmer to look at that mp?
<vila> mgz: wouldn't hurt
<jelmer> are new translation strings ok in a minor release?
<vila> especially given he's credited as author ;)
<vila> I'd say no on principle but the benefit outweight the issue in this case imho
<jelmer> works for me
<mgz> jelmer: sometimes not, but given our translations are pretty incomplete anyway and we're not removing an already translated string, should be fine
<jelmer> I guess it's also not really an issue since we don't have full coverage for any language (except English) atm
<mgz> trivial edits to translatable strings in a minor release would certainly be bad manners.
<vila> jelmer: so, except for the translation bits, do you approve the mp ? ;)
<jelmer> vila: dÃÂ¸ne :)
<vila> hmm, I missed the joke but that's probably because the font I use can't display it correctly ;)
<vila> kernel upgrade, reboot needed, bbl
<jelmer> I'm just using fancy characters. Because I can.
<mgz> approve (code)?
<mgz> I hope you'd approve the code, you wrote it :D
<vila> it renders as d\~A,ne with the comma looking a bit fancy
<vila> and the \~A is a the ~ above the A
<jelmer> hmm
<jelmer> it should be a combination of / and o
<vila> hehe, yeah, o should be slashed not the 0 as late comers to the game thought in last century ;)
<mgz> Ã¸ you mean?
<jelmer> mgz: that's just a question mark ;)
<jelmer> ah, the joys of character encoding..
<mgz> hm, worrying, pqm doesn't have merge up.
<mgz> okay, what is pqm trying to tell me
<mgz> got a failure back with just this in the output:
<mgz> Could not determine branch type for 'http://bazaar.launchpad.net/~gz/bzr/2.5_backport_rmbranch_fixes'
<vila> :-/
<mgz> ...and indeed that's not a branch
<mgz> what the hey
<mgz> exists over bzr+ssh but not over http
<vila> mgz: reproduce with lp:~vila/bzr/stats-config, freshly created/pushed on lp ;-/
<vila> reproduceD
<mgz> from #launchpad is a db lag issue with http url rewrite rules
<mgz> so, good part is should just be able to wait till can see the branch over http then pqm merge will work
<mgz> bad part is jumping up and down won't make that happen faster.
<vila> yeah, better stay up after the first jump
<vila> mgz: alternatively you can use another existing branch no ?
<mgz> vila: you mean push over an existing branch I happen to have, put up an mp for that, approve and merge it?
<vila> yup
<mgz> I guess, though I'd prefer not to.
<vila> it would validate that nothing else is broken before I start cutting the release ;)
<vila> and the end result should be the same (minus the branch nick maybe)
<hrw> bye
<vila> mgz: lp seems to breath better
<vila> mgz: ha, 1/2 hour late I can see ;)
<vila> mgz: on the other hand, I was awaiting your ping. You don't intend to land anything else right ?
<mgz> I sent it then went to lunch
<mgz> that's all that should land I think,
<mgz> just the merge up to do (which doesn't get in your way)
<vila> I'll do it (I need to do one anyway)
<vila> Unless you expect tricky conflicts in which case I'm happy to merge up only the release ;)
<mgz> well, apart from news I don't expect anything too bad provided it works out the same changes have happened on both branches
<vila> ok, don't bother then ;)
<vila> bummer, lp:bzr/2.4 doesn't merge cleanly into 2.5 :-(
<fullermd> It does if you push hard enough.
<vila> ghaa, so do 2.1, 2.2, 2.3 :-(
<vila> jelmer: you didn't merged up after landing your feature flags proposals, would you mind looking into it once 2.5.1 is released ?
<jelmer> vila: do you mean in general? merging up isn't necessary for the feature flags proposals themselves
<vila> I mean I try to merge lp:bzr/2.x branches into lp:bzr/2.x+1 to ensure all bug fixes bubble up, this is expected to always merge cleanly
<vila> for the feature flags, I know each branch got a specific fix but I assumed you merged up to avoid bad resolutions
<jelmer> I did for everything except 2.4 -> 2.5 I believe
<vila> doesn't look like it, every merge --preview raises conflicts
 * jelmer tries
<jelmer> vila: 2.1 -> 2.2 seems fine here
<vila> >-/ fine here too now, wth
<mgz> vila: sorry, I think I did some of that merge up, but not all
<vila> but 2.2 -> 2.3 still broken
<jelmer> vila: 2.2 -> 2.3 has conflicts in bzrdir.py, but those changes from 2.2 can just be discarded
<vila> sure, but that's not part of doing a release :)
<vila> doing the release includes a *check* that things are clean, that's how I found the issue ;)
<vila> bzr lock lp:bzr/2.5
<vila> 6 new translations: cs, he, my, nb, sv and vi (where is emacs ?)
<fullermd> bzr ran out of memory trying to repack it.
<vila> ha, silly me, I shouldn't have attempted that *under* emacs itself...
 * fullermd thinks of that as good general advice for pretty much everything   ;p
<vila> kids these days...
<mgz> what's the sftp trick again to get the conf of a branch on launchpad?
<mgz> does it block you from getting ones with branches you don't own...
<vila> mgz: use bzr+ssh as lp spprt is broken ?
<vila> support
<mgz> vila: this is related to working out what's up with borked branches, if you could just branch it there wouldn't be an issue
<vila> I miss the context, when you said 'conf of branches' I understood 'bzr config -d <url>'
<vila> what kind of borking are you referring to ?
<mgz> see #launchpad
<mgz> ending up at a location that doesn't exist basically
<vila> ha, no way to get a conf there indeed ;)
<mgz> after some slightly bogus renaming of branches with the lp api.
<vila> .bzr/branch/location tricks involved ?
<vila> bzr unlock lp:bzr/2.5
<vila> 2.5.1 is frozen, packagers of the bzr world unite !
<vila> cunning way to avoid test failures (i.e. ensure your test suite is passing): call sys.exit() in the system under test... unsuspecting devs passing after you won't notice
<lifeless> vila: ?!??
<vila> lifeless: explore lp:udd running selftest.py, will be clearer (EODed)
<dobey> hi all
<dobey> what does the LockNotHeld error mean exactly?
<dobey> as in: 17:02:01 E: bzrlib.errors.LockNotHeld: Lock not held: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%2Bbranch/u1db/.bzr/)
<exarkun> How do I add a file with a ":" in its name to a bzr branch?
<exarkun> Using "bzr add <name>" fails: bzr: ERROR: Unsupported protocol for url "015. Yurt II: The Yurt Returns.html"
<maxb> exarkun: refer to it as ./015... would be a way
<exarkun> maxb: thanks
<thumper> hey folks
<thumper> is there a way in bzrlib that I can override the need for signed commits?
<thumper> in particular I have a situation where my standard bazaar config specifies the need for them
<thumper> however I have some scripts that I'm writing where I can't have it
<thumper> right now I have an override in the locations.conf to specify create_signatures = never
<thumper> but I need to be able to specify that when I open the branch
<thumper> any ideas?
<mwhudson> thumper: are you committing from the command line or with bzrlib?
<jelmer> thumper: not easily AFAIK
<thumper> mwhudson: from withing bzrlib
<thumper> this is for the wiki stuff
<jelmer> thumper: the only way I can think of is to either modify the command line overrides to set "create_signatures=never"
<jelmer> thumper: or alternatively (cleaner but more complex) to add a dummy ConfigStore that sets create_signatures=never and add that to the config stack that you pass in when you commit
<thumper> jelmer: the second sounds promising
<thumper> jelmer: is there any help on how to do that?
<jelmer> thumper: You want to call IniFileStore() to create a new store
<jelmer> thumper: then store._load_from_striong("create_signatures=never")
<jelmer> urgh, except we seem to've made it pretty hard to actually override the config stack when you commit from a working tree
<thumper> :(
<jelmer> thumper: maybe vila has some clever ideas tomorrow
<thumper> jelmer: what about committing from a revision tree?
<jelmer> thumper: do you mean from a MemoryTree of some sort?
<jelmer> revision trees are immutable, so committing them is usually pretty pointless
<jelmer> thumper: or do you perhaps mean committing using the commit builder?
<thumper> yeah, so working directly with the branch, not a working tree
<jelmer> thumper: in that case you can pass in a custom config stack easily
<thumper> not entirely sure what I'm referring to :)
<jelmer> thumper: Branch.get_commit_builder and Repository.get_commit_builder allow you to pass in a custom stack.
<jelmer> so presumably you'd take the branch config (Branch.get_config_stack), make a copy of it and add your custom store in front of the other stores
<jelmer> and then pass that custom stack to Branch.get_config_stack
<jelmer> euhm
<jelmer> and then pass that custom stack to Branch.get_commit_builder
<thumper> interesting
#bzr 2012-05-23
<vila> thumper: still around ?
<vila> hi all
<mgrandi> hihi
<mgz> morning
<vila> morning mgz
<thumper> vila: yeah
<vila> thumper: regarding create_signatures, what value do you want and under which conditions ?
<thumper> hi vila
<thumper> I want wikkid to not ask for signatures even if the main bazaar conf specifies it when committing changes
<vila> which conditions ?
<thumper> all conditions
<vila> don' t set it in the conf then :)
<vila> you're asking bzr to do something, it does, why are you complaining ?
<vila> if the actual behavior does not suit your needs there are ways to use it differently, hence my question: under which conditions do you want a different configuration ?
<vila> thumper: ?
<thumper> vila: I don't want someone to have to think about what sigs they may have set in their normal bazaar conf when using wikkid
<thumper> wikkid should just never ask for signing
<vila> bzr wikkid -Ocreate_signatures=never
<thumper> ?
<thumper> what if using bin/wikkid-serve ?
<thumper> in order to have a more complicated setup?
<vila> branch.get_config_stack().set('create_signatures', 'never') ?
<vila> for all branches used by wikkid ?
<thumper> will that work?
<vila> why wouldn't it ?
<thumper> I don't know... that is why I'm asking :)
<thumper> is there a way to query the create_signatures value?
<thumper> get('create_signatures')?
<vila> yup
<vila> but the value may come from somewhere else than branch.conf
<vila> so a vicious user can still set it in locations.conf. In this case I'd blame the user though
<thumper> that's fine
<vila> cool
<thumper> if I call set
<thumper> that'll override locations?
<vila> no
<thumper> really?
<vila> locations *is* the way to override
<thumper> so if I call the set method, where does it set it?
<thumper> in the local branch config?
<vila> yes
<thumper> so if I call get, find it is true, then call set
<thumper> if I call get again
<vila> a stack defines a list of config to query and a *single* config to modify
<thumper> and it is true
<thumper> it means set in locations?
<vila> no, you need a different stack to set in locations (and one tailored to set in whatever section you specify)
<thumper> ah...
<thumper> no, i  think you are misunderstanding me
<vila> good, we're making progress ;)
<thumper> if i call get, and it is true
<thumper> then it could be set in one of three places right?
<thumper> bazaar.conf, locations.conf, or the branch config
<vila> no, that's not designed this way
<thumper> oh?
<thumper> that seems to be how it is working
<thumper> to my untrained eye
<vila> no, a stack defines only a *single* place for modifications
<vila> optional even
<vila> so you can have read-only stacks
<thumper> sure, but I'm not specifing modifiction
<thumper> I'm asking if I call "get(...)" and it returns true
<vila> the value can come from several different places
<thumper> then if i call ".set(...)" it changes the branch config (as in the one in the local .bzr)
<vila> yes
<vila> doesn't matter where the 'true' value came from
<thumper> and then if I call .get(...) again, it may be true if specified in locations.conf?
<thumper> if I specified .set(..., false)
<vila> yes
<thumper> right
<thumper> that's all I need to know
<vila> that's the 'vicious' user I was mentioning
<vila> and you said that's fine
<vila> (which I agree with ;)
<jelmer> vila: wouldn't it be easier to just add a memory store as the first store in the stack, one which just sets create_signatures=never ?
<vila> jelmer: how will a user be able to control that ?
<vila> if he can't, it looks like a bad idea to me
<jelmer> vila: why should the user be able to control it? This is running inside of wikkid.
<jelmer> prompting for GPG passphrases in a non-interactive process is a bad idea.
<vila> a user may come up with a solution for that and will be annoyed by being blocked trying to make it work
<jelmer> vila: wikkid is essentially a web server - how can that ever properly prompt for a GPG signature if it does so on the server side?
<vila> fine, if it's a server it can be configured to not ask for gpg sigs, don't make a simple problem more complicated than it needs
<jelmer> vila: this discussion is how wikkid can properly configure it to not ask for gpg sigs
<jelmer> having to edit your configuration each time before running wikkid would be annoying
<vila> jelmer: the *user* decides how to configure, code should not remove this ability if there are ways to keep the user in control
<jelmer> vila: code can also decide what the author or revision properties of a new commit is going to be, there is no way for the user to override that
<vila> jelmer: do we have config options for that ?
<jelmer> vila: if an API user wants to create a commit without a signature (and it's got a good reason), I don't particularly see why we shouldn't accomodate that
<vila> -Ooption=value
<vila> the fact that the API (bzrlib/library_state) doesn't (yet) allow that is a known bug
<jelmer> vila: it doesn't make sense for *any* commits from wikkid to be signed, why should the user have to know or care about mandatory config options?
<vila> jelmer: famous last words
<jelmer> vila: the committer email comes from the config, and API users can override that
<vila> which is a bad idea given that there are ways to do that while still respecting what the user is asking for
<vila> jelmer: what's the point of pretending that an option can be configured if the code ignores what the user is saying ?
<vila> the code can be as smart as you want as long as it provides a *default* value. Once the user asks for a specific value though, the code must comply.
<vila> If the code cannot handle what the user is asking, an error is appropriate
<jelmer> vila: the point is that any value but "never" doesn't make sense in this case
<vila> If the code cannot handle what the user is asking, an error is appropriate
<jelmer> vila: an error may be appropriate if "create_signatures" is set to always
<jelmer> but it can also be set to when-required
<vila> does that address wikkid case ?
<jelmer> vila: that's still not particularly useful though
<jelmer> vila: I have create_signatures=always set; I do want bzr to always create signatures, but I never want wikkid to
<vila> 'always' doesn't match your use case then
<vila> but setting it in bazaar.conf while overriding it in specific branches does
<jelmer> vila: what does match my use case then?
<vila> setting it to 'always' in bazaar.conf while overriding it to 'never' in wikkid branches
<vila> no code needed
<vila> if you want to be fancy do create_signatures={wikkid.create_signatures} and set wikkid.create_signatures to an appropriate value when wikkid is running
<jelmer> vila: I run wikkid often in the same branches where I run bzr from the cli
<vila> see above
<jelmer> vila: anyway, perhaps we should abandon this discussion
<vila> well, that's the second time we have it :)
<jelmer> vila: that adds a bunch of extra setup for when I want to run wikkid?
<vila> setting an optin in bazaar.conf == 'a bunch of extra setup' ???
<jelmer> vila: and for every other wikkid user too
<jelmer> vila: wikkid not working out of the box, but requiring editing of bazaar.conf is annoying
<vila> what's the out-of-the-box value for create_signatures ?
<lifeless> wikkid wants to not sign its commits
<lifeless> I'm not saying that makes sense (it doesn't to me), but there it is.
<lifeless> thumper: have you considered having wikkid sign its commits as itself ?
<lifeless> still needs to inject some behaviour, but it wouldn't lead to partially-signed trees
<jelmer> lifeless: it would have to take care of creating a password-less GPG key etc in that case
<lifeless> jelmer: something like that, and package install scripts are pretty good at that sort of thing
<lifeless> jelmer: also need a port to listen on, firewall holes etc
<jelmer> lifeless: I've usually run it as an ordinary user (myself), not as a system-wide daemon
<thumper> lifeless: no... actually I have not considered that
<thumper> lifeless: is it easy?
<thumper> lifeless: wikkid may be running on a box where there isn't someone to sign :)
<thumper> lifeless: but I guess there could be a GPG key that doesn't have a password
<mgz> I've done that in the past (the passwordless gpg signing thing)
<mgz> and then felt bad because it seemed like gpg 2 solved the same problem in a better way
<mgz> but simplest thing etc.
 * jelmer lunches
<eagleon> hi
<eagleon> is it possible to run basic bzr commands using php?
<beuno> eagleon, only by executing the commands
<beuno> you can use xmloutput to parse the output
<beuno> 4 or 5 years ago I wrote php code to do exactly that
<beuno> eagleon, so something like: $command = 'bzr log '.$path_to_bzr.' -vv --xml --show-ids -r -1 '
<beuno> with xmloutput installed
<beuno> and then parse the xml output with something like simplexml
#bzr 2012-05-24
<glyph> Is there any way to rebase without actually referring to history?
<glyph> Just spit out a pile of patch files, then re-apply them?
<glyph> I ask because I'm still wrestling with https://bugs.launchpad.net/bzr-svn/+bug/485601 and I need to rescue some branches in a repository with that disease
<ubot5> Ubuntu bug 485601 in Bazaar Subversion Plugin "missing chk node(s) for id_to_entry maps" [Critical,Fix released]
<eagleon1> bueno thank you for the response, much appreciated
<eagleon1> for bzr, do I always need to type the filename after? is it possible to auto add a whole bunch of files atuomatically (detected) if not already added?
<lifeless> 'bzr add'
<lifeless> just like that, will add everything in the tree that isn't ignored or already added
<eagleon1> thanks, thats excellent! appreciate it
<eagleon1> are there any known downsides to running off cygwin by the way?
<lifeless> it will be a bit slower than a native build, due to the cygwin path translation overheads
<eagleon1> ah, ok if thats all it is it should be ok. My projects aren't huge (less than 50 mb) avg...
<lifeless> As far as I know we handle text/binary etc all correctly.
<lifeless> so no reason not to use it
<eagleon1> thats true, but I am creating a bash script to automate a few things as I develop, and I want the script to be as portable as possible
<eagleon1> i dont use windows much, just when I need something that only runs on windows will I use (like photoshop for example)...
<eagleon1> bash script will only contain paths and stuff so that I don't need to type all that manually every time
<eagleon1> or make mistakes using a gui
<lifeless> cool
<mgz> morning
<mgrandi> hi
<eagleon1> hi, does anyone know how I can get bzr-upload plugin instlled on a cygwin setup?
<jelmer> eagleon1: like any other bzr plugin I suspect - 'bzr branch lp:bzr-upload ~/.bazaar/plugins/upload'
<eagleon1> thanks, will try that out :) appreicate it
<eagleon1> hmm.. I get an SSL error msg when attempting that: Value "/etc/ssl/certs/ca-certificates.crt" is not valid for "ssl.ca_certs"
<eagleon1> No valid trusted SSL CA certificates file set. See 'bzr help ssl.ca_certs' for more information on setting trusted CAs.
<eagleon1> See `bzr help ssl.ca_certs` for how to specify trusted CAcertificates.
<eagleon1> Pass -Ossl.cert_reqs=none to disable certificate verification entirely.
<eagleon1> bzr: ERROR: _ssl.c:323: No root certificates specified for verification of other-side certificates.
<eagleon1> ok, read the help file.. added 'ssl.cert_reqs=none' to my config and it works now :)
<mgz> that's a win for the error message clarity.
<eagleon1> yep, indeed :)
<eagleon1> there was more info on adding an SSL cert, but I don't really need that
<eagleon1> hmm.. this installs the plugin on my user account, is there a similar way to put it system wide?
<mgz> hm, I don't recall exactly with cygwin
<mgz> but basically putting in the plugins dir of where bzrlib is installed will do
<eagleon1> ah ok, that helps
<mgz> if there's a setup.py script, running that should do.
<mgz> ...I can't even remember if you need to elevate to root for cygwin when doing that
<eagleon1> any idea where this is installed on cygwin by default?
<eagleon1> root does not exist on cygwin by default
<mgz> `python -c "import bzrlib;print bzrlib"`
<eagleon1> ah, excellent.. thank you :)
<eagleon1> <module 'bzrlib' from '/usr/lib/python2.6/site-packages/bzrlib/__init__.pyc'>
<eagleon1> cd /usr/lib/python2.6/site-packages/bzrlib/
<eagleon1> oops
<eagleon1> sorry
<mgz> cd plugins
<eagleon1> actually this path does not exist... hmm
<mgz> probably a symlink at the python2.6 level?
<eagleon1> possible.. but shouldnt that still cd
<mgz> cygwin is a bit funky with directories
<eagleon1> yeah, its funny.. i went to: /usr/lib/python2.6/site-packages/
<eagleon1> and that worked and I can se bzrlib right there
<mgz> try branching bzr-upload then running `python setup.py` inside that branch?
<eagleon1> now cd bzrlib/plugins worked :)
<mgz> ...silliness
 * mgz bops cygwin
<eagleon1> indeed.... :P
<eagleon1> will try your suggestion
<eagleon1> actually, just one question crosses my mind... when I read the manual/ref regarding bzr push, it mentioned that the working tree is uploaded for supported formats... but it didn't mention what protocol that was... I use bzr+ssh:// shouldn't that push the tree?
<eagleon1> if it does I wont need bzr-upload right?
<mgz> think of push as not creating a tree on the destination, as that's true for all the cases you're likely to care about
<eagleon1> hmm.. in my case I want to update a live web demo of the app that I am working on... so push wont be sufficient then right?
<mgz> it will update a tree only if it has a local filesystem, not over http/sftp/bzr+ssh
<eagleon1> bit confused, what do you mean by local file system?
<mgz> something that can be addressed with a file: url
<eagleon1> ah ok, so file://
<mgz> so, it could be network filsystem mounted locally
<eagleon1> oh I see
<eagleon1> this makes sense :)
<eagleon1> thanks
<mgz> but for deploying your branch on a server, bzr-upload is probably what you want
<eagleon1> yes, looks like it. :)
<eagleon1> as per your suggestion, ive 'bzr branch lp:bzr-upload' ... and now inside bzr-upload, attempting to run the setup.py
<eagleon1> i get error: no commands supplied
<eagleon1> does this have something to fo with cmds.py I wonder (?)
<eagleon1> *do with
<mgz> install is what you want to do, so `python setup.py install`
<eagleon1> ah got it, thanks
<mgz> bad example by me before
<eagleon1> no problem, it worked wonderfully (it seems)
<eagleon1> looks like i need t rename that from bzr-upload to upload
<eagleon1> that got it working...
<eagleon1> now to document all of this for next time. Thanks for all the help, it's much appreciated :)
<eagleon1> in bzr upload, is there a way to define a .bzignore just for this plugin? for example, there is a folder that I want to version control so it can't be ignored, but I dont' want this folder uploaded every time I run bzr upload... I couldn't find a solution in the docs
<eagleon1> not sure if I got a response to this question, my client crashed: in bzr upload, is there a way to define a .bzignore just for this plugin? for example, there is a folder that I want to version control so it can't be ignored, but I dont' want this folder uploaded every time I run bzr upload... I couldn't find a solution in the docs
<mgz> not that I know of.
<eagleon1> :(
<eagleon1> I will probably have to maintain that other dir separately, but I guess if it was nested this would be basically impossible
<eagleon1> ...unless... I modify the .bzignore just before the bzr upload... would that work?
<eagleon1> and then put it back right after..
<fullermd> I don't think upload knows or cares much about .bzrignore...
<eagleon1> it does, says so in the docs
<eagleon1> havent tested yet tho
<mgz> I take it back, there's a .bzrignore-upload in the code at least
<mgz> try that.
<eagleon1> ah, thats interesting
<eagleon1> thanks, ill give it a shot
<mgz> needs to be versioned
<eagleon1> yeah, this is great...
<eagleon1> this solves my problem
 * eagleon1 slaps himself for not reading the documentation properly
<davmor2> Hey guys just throwing out a thanks for the people behind bzr explorer it's meant that I could see what bzr was doing.  It also meant I was able to ask some sensible questions about how the other devs on my team did local branches (I surprisingly had it all wrong)
<davmor2> So thanks for making things so easy to see
<pindonga> hi, I have an issue starting today. whenever I try to push a branch I get a Permission denied error from LP, saying 'You cannot create branches in "~username/project"
<pindonga> any ideas?
<eagleon> anyone around? :)
<youlysses> Of course.
<eagleon> cool, I was hoping I could get a bit of help on a small error msg im dealing with ..
<youlysses> Never ask to ask, just ask. If I can't handle it, someone else will eventually . :-)
<eagleon> sounds good :) one sec, will paste the error here...
<eagleon> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://eagleon@domain.com:22/~eagleon/domains/public_html/test1": URLs must be properly escaped
<eagleon> i changed only the domain name, that's exactly how I have everything else tho
<eagleon> what have I got wrong?
<eagleon> was trying diff variations for a while with no avail
<eagleon> thats on a bzr push command btw
<fullermd> Where's it getting the URL from?
<eagleon> the command is invoked from a python script, which is getting it from a csv file
<eagleon> bzr push bzr+ssh://eagleon@domain.com:22/~eagleon/domains/public_html/test1
<eagleon> thats the command
<eagleon> it also worked fine with a bzr upload just earlier
<eagleon> very confusing
<eagleon> (but that was without the python invocation)
<fullermd> Check .bzr.log to be sure the command is coming in right, and see if it says anything more illuminating about where the error happens.
<eagleon> good idea, checking now
<eagleon> where is the log? this is on cygwin... :-S
<fullermd> `bzr version` says I think.
<eagleon> indeed it does, found and checking now
<eagleon> in the log, it looks like this: InvalidURL: Invalid url supplied to transport: "^Ãbz+ssh://
<eagleon> this could be the problem, and cygwin the culprit
<fullermd> Does sound a little unhelp   ;p
<eagleon> yeah... are those strange chars at the end normal?
<eagleon> ^Ãbz
<fullermd> I wouldn't think so.  I've never seen such a thing.
<eagleon> yeah... i think its caused by the new cygwin terminal
<eagleon> I wasn't able to cd to a dir that I knew for sure that existed (when I put the full path)...
<eagleon> i could cd to it dir by dir...
<eagleon> this may be a related problem
#bzr 2012-05-25
<eagleon1> hi guys, I was just wondering if you can help me figure out if my workflow is well thought out, or flawed... might anyone be around to help? :)
<eagleon1> anyone?
<vila> eagleon1: just ask your question or nobody knows if he/she can answer ;)
<eagleon1> ah ok, thank you vila :) ... well my current situation is this: I am a single developer who works on multiple machines (varying OSes and locations).... and my main line of work is web dev
<eagleon1> so the goal is to (1) local dev (offline if no connection, like when I am on a flight) .. (2) upload all changes to the remote test server when done in working condition
<eagleon1> and before starting work on an project, I want to make sure that the machine that I am working on at the time has the latest version
<eagleon1> so in order to accomplish this I am doing the following:
<eagleon1> 1) bzr pull
<eagleon1> 2) bzr update
<eagleon1> then I work on the project and make changes (being confident that I have the latest version on this machine)
<eagleon1> 3) after making changes (online or offline) I make local commits along the way...
<eagleon1> 4) when I am ready to test it on the test server, I do a bzr upload
<eagleon1> 5) then a bzr push
<eagleon1> thats it!
<vila> That sounds correct.
<eagleon1> at this point, I assume the remote test server (e.dg www.example.com/test) is the latest version
<eagleon1> so the next time I do a pull, it will also be from here...
<eagleon1> :) correct! yay!
<eagleon1> in the docs, I was reading about 'bzr checkout' ... this is not necessary then right?
<vila> A couple of questions though: where are your branches, do you have one on the test server (and/or the production server)
<eagleon1> when ever I create a new project, I will create a branch for that project on the test server... then get it locall using the step #1 above...
<eagleon1> for that, I will only do bzr init, bzr add znd bzr commit
<vila> ok, so you have a bzr branch on the test server. Is bzr installed there ?
<eagleon1> yep installed and ready :)
<vila> so you can use the bzr-push-and-update plugin instead of bzr-upload
<eagleon1> ah, excellent! whats the difference in this case?
<vila> If you haven't (yet) read http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief you can ;)
<vila> working trees and branches are especially relevant here
<eagleon1> havent, but will do right now! thanks :)
<vila> you have to understand that a working tree can be in sync or not with its associated branch (they generally are)
<eagleon1> im still new to versioning ... terms like branches and tress can be a little confusing in terms of application (vague)... but this link might help understand ...
<vila> In some cases, one can push to a branch but the working tree is not updated
<eagleon1> oh I see
<vila> roughly, the working tree is the files you're editing, when you do a commit, a revision is created and becomes the branch's new tip
<eagleon1> I understood everything up to the point where the revision is created...
<eagleon1> so a branches new tip is the version history data?
<vila> so, a branch is a directed graph of revisions (the history of your work, the tip being the most recent revision and the graph entry point)
<eagleon1> oh got it, that makes sense
<vila> so, back to your workflow,
<vila> most of the time, (bzr branch, bzr init, bzr pull), your WT is updated automatically so your step (2) is probably not required
<eagleon1> ok, thats good to know
<eagleon1> so that would be a redundant step
<eagleon1> but I didn't have bzr branch in my workflow before,
<vila> if you install and configure bzr-push-and-update (requires ssh access to the server), your step (4) becomes useless too
<eagleon1> ssh access is ready
<eagleon1> thats good!
<vila> and if in (5) you're pushing to the same place that you're uploading in step (4), you're on thin ice
<vila> ,,,
<vila> ...
<eagleon1> in what sense (and yes, it is the same place) ...
<vila> I thought bzr-upload will refuse to upload to an existing branch... am I wrong ?
<eagleon1> no it uploads
<eagleon1> ive been testing this workflow for a bit now, but I dont know when I am really working on a project what sort of variables might mess things up
<vila> and you then push to the exact same url ?
<eagleon1> yes
<vila> hmm, anyway, that's still risky :)
<eagleon1> how come? :)
<eagleon1> just asking to know... i believe you tho, I want to understand this better
<vila> so, if you have ssh access *and* you already maintain a branch there, better use push-and-update
<vila> well, bzr-upload is targetted at uploading a tree relying on a local branch
<eagleon1> yes, the branch will always be created on the remote test server first
<eagleon1> (in some cases i may create it locally and send it to the remote server) then sync back... if I want to do that, will push-and-upload have any conflict?
<vila> bzr-upload needs to upload the whole files, whereas 'bzr update' running remotely (via push-and-update) deals with local files
<vila> push-and-update :)
<vila> no, it's fine
<eagleon1> cool
<eagleon1> this is great, I am so glad I asked... your help is invaluable :)
<vila> in a nutshell: if you have bzr installed where you want to push, use bzr-push-and-update,
<vila> if you don't have bzr installed OR don't want your bzr branch to be readable (think production servers), use bzr-upload
<vila> happy to help ;)
<eagleon1> oh, right~ I was thinking on putting things manually to production servers without bzr involved (but perhaps knowing this may make a difference, once I am vry comfortable with bzr) ...
<eagleon1> one last question if you dont mind vila... what about "checkouts" they are not necessary right?
<eagleon1> checkins and checkouts?
<vila> well, no, they aren't
<eagleon1> in the docs, I read that I would use a checkout if I am a single dev working on multiple machines
<eagleon1> just out of curiosity, in what situation would a checkout be appliable over this workflow that I have (with the changes you recommended)
<eagleon1> *applicable
<vila> it would make sense if you're working on the same project from multiple machines
<eagleon1> I am though, that's the thing
<vila> by same project, I mean a 'master' branch on a central server
<eagleon1> oh...
<vila> and it works really well if you're always online and the server is always accessible too
<eagleon1> hmm... no my setup is more "distributed" than centralized, if that correct?
<eagleon1> *is
<eagleon1> i may not always have access to the net, as I travel a lot
<vila> outside of these constraints... you need to be more careful and rigorous about committing (locally) when you've been offline and run 'bzr update' before starting edits again
<fullermd> When you're push'ing and pull'ing stuff around, you basically have 2 (or 3, or 4, or more) independent branches, that you opportunistically sync up.
<vila> eagleon1: what have you done !!! You said 'checkout' !!!
<fullermd> With checkouts, you conceptually have _one_ branch, and 2 (or 3, or 4, or...) different working trees you work on it from.
<eagleon1> hmmm
<eagleon1> again, slightly confused ... let me go over this for a second
<fullermd> And you never ever use commit --local, because it's the devil.  See those two l's at the ends of the word?  Those are its horns.
<vila> hehe
<eagleon1> ah :p
<vila> so, basically, avoid checkouts until they *really* make your life easier :)
<eagleon1> thats' a great way to remember never to do it, thanks fullermd
<eagleon1> will do vila... right now, they dont seem to apply to me
<vila> even bound branches are clearer to use when you're offline from time to time
<fullermd> And if you don't immediately see how they make your life easier, they probably don't at this point.
<eagleon1> yeah, my priorities are to always have the latest version on the local machine that I am working on when I begin coding, then when I finish that latest version needs to be on the test server (which acts as my source if I start working on another machine later)
<eagleon1> my biggest concern is losing any work by forgetting a step.. :-S ...
<eagleon1> is that possible?
<vila> well, pull before your start, push before you end
<eagleon1> by push you mean push-and-update right?
<fullermd> Or after you end   ;p
<eagleon1> haha
<vila> oh no, *before*, you're not finished until you do that :)
<eagleon1> thats true indeed
<vila> eagleon1: oh, and 'bzr missing' is your friend when you don't remember if you did
<vila> (pull or push)
<eagleon1> excellent, ill read up on missing as well
<fullermd> If you make some changes in one place, and don't push them before you start working in another, you'll wind up with two branches that have diverged (both have changes the other doesn't).
<vila> 'bzr config' and 'bzr info' will also remind you of which branches you're dealing with
<eagleon1> also I suspect 'bzr add' and 'bzr remove' are crucial
<fullermd> But that's not any sort of problem; you can just merge them later.  You just won't have the changes from one place in the other until you do.
<vila> they're pre-requisites of 'bzr commit' IMHO
<vila> 'bzr add/remove' are pre-requisites of 'bzr commit' IMHO
<vila> so yeah, 'bzr st' is the moral equivalent of 'bzr missing'
<eagleon1> moral equivalent meaning?
<fullermd> Yes, there are basically two different sets of commands you work with.  One is the "I'm making new stuff" set, where you have add/rm/mv/stat/commit/etc.
<fullermd> The other is the "I'm getting the stuff I've made where it needs to be to deploy/continue deving", where you have push/pull/missing/etc.
<eagleon1> hmm, this new info completely upgrades my workflow from what I had in mind initially
<vila> so, 'bzr st/bzr diff' is the last command before 'bzr commit', where 'bzr missing' is the last command before 'bzr pull/push'
<eagleon1> got it, I hadn't even thought of those previously... thanks vila and fullermd
<vila> you're welcome
<vila> fullermd: thanks to you too ;)
<eagleon1> :)
<fullermd> vila: 'k.  Now let's find someone new to confuse!
<eagleon1> haha
<eagleon1> wow, I just realized... being on the #python chat room has truly deciplined me to no lol
<eagleon1> cos their bot keeps bugging you whenever you type lol there :p
<eagleon1> so now I keep typing haha by habbit :-S ...equally bad or worse
 * vila checks #bzr bot, you slacker
<eagleon1> by the way, what is the lp: stand for... like in bzr branch lp:bzr-push-and-pull
<eagleon1> I mean push-and-update... :/
<vila> hehe
<vila> it's a shorcut for launchpad branches
<eagleon1> ah cool :D
<eagleon1> moving a branch if ever necessary (using the file system itself) should be safe right? I just pulled the push-and-update plugin into the bzrlib dir insited of inside the plugins dir... so doing a mv to where it belongs, should not break anything right?
<eagleon1> hmm, there is no setup.py for this plugin... so I assume it will work as long as it is in the plugin dir?
<fullermd> Except in the case where it was made in a shared repo (init-repo), and you mv it out of the repo.
<eagleon1> oh, got it!
<mgz> morning
<fullermd> I don't remember authorizing that.
<eagleon1> morning :)
<eagleon1> authorizing what?
<fullermd> Mornings.  They're bad news.
<eagleon1> oh ... sorry to hear that, did I miss something.. your comment seemed random ... :/
<fullermd> You say that as if it's something unusual...
<mgz> it's fulldermd's normal greeting :)
<eagleon1> ah! :P
<eagleon1> im new here, so its good to know that now :D
<mgz> in fact, these days I'm not convinced it's actually random
<mgz> I think he's just pseudo-random
<eagleon1> lol
<fullermd> Being completely unpredictable was getting predictable.  I had to switch to pre-planned things so it didn't look pre-planned.
<eagleon1> oh darn, you just gave it away...
<fullermd> Or DID I??
<eagleon1> :-O
<eagleon1> hi guys, I am wondering what I am doign wrong here...
<eagleon1> $ bzr push-and-update
<eagleon1> bzr: ERROR: Not a branch: "/usr/lib/python2.6/site-packages/bzrlib/plugins/".
<mgz> run `bzr info` in the same location?
<eagleon1> oh right, im not inside a branch... :( silly me
<eagleon1> :)
<eagleon1> thanks mgz
<vila> hmm, I thought push-and-update could be configured to trigger automatically when one do push...
<vila> hi mgz (sry for the delay ;)
<eagleon1> is that possible?
<vila> according to the code, it's the default behavior, as long as the url used hints that ssh is involved
<vila> give it a try
<vila> i.e. no configuration needed
<eagleon1> will do, im stil documenting what we discussed earlier before I forget :D
<vila> good choice :)
<eagleon1> all while watching hacker attempting to breach my production server
<vila> yeah, always entertaining
<eagleon1> indeed
<eagleon1> hi guys, when limiting the ssh account that I use to connect to the remote server (when doing a pull) ... what commands should I supply?
<eagleon1> what arguments should be there for example
<vila> I never remember the details for that as I rely on using only keys to connect to ssh servers
<eagleon1> yeah, even with the keys its better to limit the ssh user i think...
<vila> note that having ssh access is enough to use the bzr smart server, the bzr client will execute the right command remotely
<eagleon1> i never connect with a previledged account
<eagleon1> hmm
<vila> and if you use bzr-push-and-update, you need to allow a different command for that too
<vila> it's certainly doable but I've never done it myself
<eagleon1> I guess I will have to allow some freedom to this user then...
<eagleon1> will definitely have to limit bzr to the test server, and update production manually for now..
<vila> you can use a dedicated key on the test server and pull from the production server
<mgz> probably don't need to be too paranoid
<vila> hehe, all paranoids will disagree with that I think :)
<eagleon1> well im getting hacker attempts daily, but the hour.. so a bit paranoid ... :-s
<eagleon1> *by the hour
<fullermd> What?!  How did you know I'd disagree???
<vila> . o O (Damn it, damn it, quick, the dried frog pills)
<eagleon1> im actually extra paranoid today because they are trying to brute force a specific user account that I created recently... how did the know it exists!?!
<eagleon1> although the brute force wont work, im still worried about how they got that specific user name
<eagleon1> made up of random letters
<vila> wow
<fullermd> Well, I certainly didn't tell them via a scrawled note I dropped in a basket outside the local Burger King between 2200 and 2230 last night.
<fullermd> That would be suspicious after all.
<eagleon1> lol
<vila> eagleon1: still, they are trying passwords, if you disallow that on your ssh server allowing only keys, you're done
<fullermd> Nono, everybody knows you're supposed to run sshd on a different port.  Then you're totally safe forever.
<eagleon1> yeah, im already doing that so safe there... but still wondering how they got that username
<eagleon1> (last comment was in response to vila :p)
<eagleon1> can they sniff an user name during connect time, even if I was attempting via ssh?
<eagleon1> i wonder
<fullermd> Obviously what you thought was random was really only pseudo-random.  We know how that turns out.
<eagleon1> indeed :P
<vila> if they were able to sniff user names, I'd call that a very big security hole
<eagleon1> exactly :-S
<vila> eagleon1: are you really saying you see hack attempts on a non-standard port with a random user name ?
<vila> I'm curious about which of your assumptions is wrong...
<vila> because if they are all true, you're in trouble :)
<eagleon1> no, they are attempting on a standard port with a known username...
<eagleon1> (as well as random ones)
<eagleon1> but they only get past 3 attempts with each IP... after that they need to go find more proxies from china :p
<vila> eagleon1: fail2ban for the win ?
<eagleon1> yes indeed :)
<eagleon1> by the way, does bzr commands need to always be run withing the working dir of the branch? is it possible to provide the path of the branch to other commands, like bzr push [host] [branch?] ... unlikely right?
<mgz> all commands should either take a path as a param, or -d to tell them where to operate
<eagleon1> so bzr push -d /home/user/file/ bzr+ssh://.... is good?
<eagleon1> i dont see -d in the help files..
<eagleon1> i think bzr bind is what I was looking for,
<mgz> I... doubt it?
<eagleon1> really?
<mgz> what are you actually trying to do?
 * fullermd is pretty sure "not bind" is the answer too   :p
<fullermd> -d is right there in push's help, frex...
<eagleon1> hmm.. well what im trying to do... lets say im in /home/user
<eagleon1> i have a branch in /home/user/test
<eagleon1> without going inside 'test', while being in /home/user, i want to perform the bzr push (or any bzr command)
<eagleon1> i couldn't see the -d in my push's help ... let me check again
<mgz> (cd test && bzr anything)
<mgz> magic, you've not changed location :)
<mgz> otherwise -d is what you want for many commands
<eagleon1> ah, nevermind.. looks like i was looking at bzr update's help ... which dosen't have it... my bad, but still missing for this command
<eagleon1> mgz, i think you magic command is what im going to use :D thx
<eagleon1> nevermind :P
<eagleon1> that changes location..
<eagleon1> the problem is that I need to execute this as a python subprocess.call
<mgz> that's not a problem surely
<eagleon1> yea, actualy its not lol
<mgz> that has a param to set the cwd of the process you're spawning
<eagleon1> really? :-o I didnt know that...
<eagleon1> thanks mgs, that helps
<eagleon1> *mgz (sorry)
<Merwin> hi !
<jelmer> hi Merwin
<vila> jelmer: what needs to be done for 2.5.1  ? An SRU for precise ? Something for quantal (or should that be some 2.6bx there) ?
<jelmer> vila: an SRU for precise
<vila> jelmer: ok, can you take care of that ?
<jelmer> vila: sure
<vila> cool, thanks
<eagleon1> hi
<eagleon1> i keep getting this strange error: This transport does not update the working tree of: bzr+ssh://
<fullermd> That's not an error, just a notice.  Thought it does get old pretty quick.
<eagleon1> bzr+ssh is supposed to be a supported transport, right?
<fullermd> It's just telling you it doesn't update remote working trees.
<eagleon> i keep getting this strange error: This transport does not update the working tree of: bzr+ssh://
<eagleon> bzr+ssh is supposed to be a supported transport, right?
<eagleon> for the push-and-upload plugin?
<fullermd> I dunno if push-and-upload can or bothers suppressing the message from push.
<eagleon> hmm... either way, its not working :(
<fullermd> push-and-update I think it's called, rather.
<eagleon> yeah.. thats what i meant, sorry
<eagleon> it works with just doing a bzr push
<eagleon> after its installed
<eagleon> im tempted to go back to the bzr upload solution like I wanted to originally... but also cant rest until i can figure out why this is broken... :-S
<fullermd> What's broken?  I thought you said it works.
<eagleon> nope :( ... basically the push-and-update dosen't work... let me show you, one sec
<fullermd> 13:57 <eagleon> it works with just doing a bzr push
<fullermd> I presume "it" means the WT gets updated.
<eagleon> oh... what I meant by that is that doing a bzr push actaully calls the push-and-update plugin when it is installed ... sorry for the lack of clarity, but the WT does not update
<eagleon> i get the following error: This transport does not update the working tree of: bzr+ssh://user@domain...
<fullermd> That's coming from push.  Unrelated to whatever the problem is.
<eagleon> hmm
<eagleon> let me show you the whole error, it might make more sense
<fullermd> push-and-update basically just adds a hook into things so that when you run "bzr push bzr+ssh://server/some/path", it goes in afterward and runs "ssh server ; cd /some/path && bzr up"
<fullermd> It doesn't change the push process itself to do anything to the WT.
<eagleon> http://dpaste.com/752205/
<eagleon> hmm
<fullermd> 'k, well that seems reasonably self-explanatory.
<eagleon> you mean the host name?
<fullermd> Yah.
<eagleon> the funny thing about that, is that it connects to the server.. then I even get authenticated (password request pops up) I enter the pass and then this happens
<fullermd> ssh takes a hostname as an arg, not something like a URL fragment.  The plugin apparently doesn't do necessary translations.
<eagleon> ah
<fullermd> That password prompt is probably from the push, not the update.
<eagleon> got it,that makes sense
<fullermd> I doubt there's an in-bzr workaround short of extending the plugin's capabilities.
<eagleon> i guess a simple work around would be to just run the update myself without the plugin
<fullermd> Me, I'd avoid the issue entirely by just using sshconfig.
<fullermd> Saves worrying with usernames too.
<eagleon> whats that? im not familair with it
<fullermd> Add an entry into your ssh config setting the port and the username; then you don't need to specify any of it.
<eagleon> hmm
<eagleon> within my user's ssh config right?
<fullermd> Yeah.
<eagleon> not related to bzr?
<fullermd> Something like
<eagleon> oh ok..
<fullermd> http://dpaste.com/752206/
<fullermd> Then you could just 'bzr push bzr+ssh://bzr.example/where/ever'
<eagleon> ah yes, this shoud work nicely
<fullermd> (my config has tabs for the following lines; I don't know if spaces work or not, but I didn't feel like trying to sneak them into bpaste)
<eagleon> yeah, the probably do work... but I prefer tabs myself
<eagleon> *they
<eagleon> thanks so much for the tip
<fullermd> I got sick of remembering all the usernames I have to deal with a good while back, and started accumulating lines in .ssh/config   ;p
<eagleon> ah yes :)
<eagleon> this is definitely helpful
<eagleon> only problem that I see however, is that since I work on multiple machines...
<eagleon> ill have to update each of them :-S
 * fullermd . o O ( cd ~/.ssh ; bzr init ; bzr add ; bzr ci -m 'Version one copy of this I can share' ; bzr push ....  )
<fullermd> A little recursion is good for the soul   :p
<eagleon> ha! :D
<eagleon> never thought of that... good solution! and it keeps things versioned too :D
<fullermd> Oh, yes, I've got a lot of little bzr branches like that around, just to have a little history on configs.
<fullermd> (.ssh/config being one; a little branch with nothing in it but .bzrignore and config...)
<eagleon> actually... this would even work nicely on some /etc/...
<fullermd> Also a branch on all my systems   :p
<eagleon> :D
<fullermd> As is /usr/local/etc.  /usr/local/etc/apache22 is usually another one.
<eagleon> I never saw bzr this way until now, this is going to make my life so much easier :D
<fullermd> One for postfix config, on the boxes where it matters.  nginx one or two places.
<eagleon> thank you x ~
<fullermd> I've even got a ~/.rc-files for the handful of little rc files that don't have anything else to justify a branch by themselves.
<eagleon> nice
<fullermd> (files symlinked to ~.  e.g., "/home/fullermd/.vimrc@ -> .rc-files/.vimrc")
<eagleon> do you backup the branches somewhere also or just on the local machine?
<eagleon> or server
<fullermd> None of those branches ever get pushed anywhere, or deal with merges or any of that.  They're mostly just so I have a history of what's been done, and a backup if I accidentally rm the file or dd too many lines, or need to backout changes, etc.
<fullermd> Most of 'em don't get explicitly backed up themselves, though they get caught in sweeping backups of the surrounding FSen.
<eagleon> yeah, very cool!
<eagleon> FSen?
<fullermd> Well, how else would you pluralize "FS"?
<eagleon> FSes? :D
<fullermd> That doesn't sound nearly as cool.
<eagleon> i disagree... :P
<eagleon> then again, maybe ur right
<fullermd> Of course I am.  It's one of the rules.
<eagleon> lol
<eagleon> besides, confusing is cool and it just happens to be your style from what i've been gathering lately :D
<fullermd> Am I that predictable?  Good.
<eagleon> how come you are always online? :p its awesome
<fullermd> Well, the alternative would be to get a life.  And who has time for that?
<eagleon> indeed!..
<eagleon> thats what I always say
 * fullermd shrugs.
<fullermd> I work a lot.  And my IRC window is always sitting there anyway.
<eagleon> yes, thats what I tell everyone as well.. they never beieve
<fullermd> Infidel defilers.  They shall all drown in lakes of blood.
<eagleon> :-O
#bzr 2012-05-26
<a7x> after bzr launchpad-login i get this warning WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-xxxx/pkcs11: Connection refused
<a7x> should i mind?
<bitonic> this is probably an uncommon question, but: is it possible to check the files of the local copy of a repo to have the same permission as the remote one?
<bob2> probably want etckeeper
<bob2> but metastore is a thing too
<bitonic> bob2: is that a reply to my question?
<bob2> sure
<bitonic> bob2: http://joeyh.name/code/etckeeper/ this? it doesn't look like what I want
<bob2> ok!
<bitonic> my problem is that I copied a bzr repo on a fat drive, and then copied it somewhere else, now I lost the original permissions
<bitonic> so I'd like to restore those of the original repo without recloning it
<bob2> rsync
<bob2> -a
<bitonic> bob2: yeah too late, I don't have access to the drive with the original repo now :P
<bob2> then you're screwed?
<bob2> bzr didn't write it down anywhere
<bitonic> ? I have a copy of the repo, but the permissions are messed up
<bitonic> (that's the emacs repo btw)
<bitonic> I'd like to restore the permissions of the files to what they are on the remote repo, without redownloading the whole thing
<bob2> bzr does not version things aside from a+x or not
<bob2> and oyu've lost access to the original repo
<bob2> so where do you want to 'restore' the information from?
<bitonic> bob2: no I haven't lost access to the original repo
<bob2> then rsync -a
<bitonic> I have lost access to the copy of the repo with the right permission (so I can't do rsync -a)
<bitonic> wait I can use rsync on a bzr repo?
<bob2> oh man
<bob2> good luck
<bitonic> it doesn't look like I can...
<bob2> i think you need to think about the above a bit more
<bob2> a) bzr doesn't version permissions
<bob2> b) rsync -a will restore perms from one tree to another
<bob2> c) if you have "lost access to the copy of the repo with the right permission" then you have lost access to the thing you're askign for, so you're boned
<bitonic> bob2: bzr versions a+x or not as you said, which is what I did
<bob2> good luck
<bitonic> bob2: ok wait. here is the situation. I clone bzr branch bzr://bzr.savannah.gnu.org/emacs/branch
<bitonic> on machine A. then I put the clone on a FAT drive and I put it on machine B. Now I've lost the permissions, but I can't access to machine A anymore.
<bitonic> I want to restore the permissions from the original bzr repo
<bitonic> is that possible with rsync or otherwise?
<eagleon> cygwin is so annoying
<hypnocat> when i try to emerge kicad on gentoo, bzr tries to read a launchpad respository and reports an internal error:
<hypnocat> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'HTTPSConnection'
<hypnocat> full emerge log here:  http://pastie.org/3971540
<hypnocat> hmm.. according to this thread:  http://us.generation-nt.com/answer/gentoo-user-cannot-import-http-client-help-199938861.html
<hypnocat> the error is caused by "an openssl problem introduced by the recent dev-libs/openss-1.0.0a-r2 which disables ssl support in Python itself."
<hypnocat> doesn't say how to fix it, though
<bob2> heh gentoo
<bob2> probably just have to wait for  someone to fix their python
<hypnocat> or i could try updating python
<hypnocat> haven't done that in a while..
<hypnocat> i hate updating python, perl, kde, and libreoffice on gentoo
<hypnocat> it takes forever.. and updating perl and python will mean i'll have to update tons of other packages too.. a huge pain
<hypnocat> but i guess it has to be done sometime..
<bob2> well you chose gentoo
<bob2> so presumably you like contributing to the heat death of the universe
<hypnocat> well, looks like updating python helped
<hypnocat> no more HTTPSConnection error from bzr when building kicad
#bzr 2012-05-27
<AfC> jelmer: ping; I just hit http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644193 ; you suggest it is a bug in dpkg-source but I'm not clear on what to do about it. I'm just building packages as I always did, only now on Precise builddeb is failing
<ubot5> Debian bug 644193 in bzr-builddeb "dpkg-source: error: aborting due to unexpected upstream changes" [Normal,Open]
<AfC> jelmer: is it now obligatory to commit your work-in-progress changes before calling builddeb?
<AfC> Ok, so it works when invoked:
<AfC> $ bzr builddeb --quick
<AfC> but not when
<AfC> $ bzr builddeb
<AfC> (wtf)
<AfC> weird
<jelmer> AfC: hi
<jelmer> AfC: you can no longer have changes in your working tree against upstream, all changes have to be in debian/patches
<jelmer> AfC: you don't have to commit, as previously
<jelmer> AfC: note that this is enforced by dpkg-source, not really related to bzr-builddeb
<AfC> jelmer: that kinda really breaks the model we were using bzr builddeb under until now.
<AfC> jelmer: we have a lot of code in our bzr branches :(
<AfC> I wonder what the point of this change was. To force people to stop storing code in bzr?
<jelmer> AfC: this has nothing to do with bzr
<jelmer> AfC: it's a change in dpkg
<AfC> jelmer: I realize it's dpkg-source that changed, but
<AfC> jelmer: since it *completely screws* people using bzr-builddeb, it's perhaps a
<AfC> jelmer: slight touch disingenuous for us to wash our hands of it.
<jelmer> AfC: I think "completely screws" is an exaggeration
<jelmer> AfC: you can either set an option in debian/source/local-options to force dpkg-source to not complain
<AfC> jelmer: why? None of my packaging branches are building now. That counts as "blocker" in most bug trackers I've used.
<jelmer> or manually put your patches in debian/patches (which you should be doing anyway)
<AfC> [ok, good to know]
<AfC> but why would we want to force people to put the changesets in debian/patches?
<jelmer> AfC: I agree this isn't ideal, but anybody using dpkg-source in one way or another is hitting this
<AfC> I mean, .debian.tar.gz contains the diff against upstream when packaged
<AfC> so what's the harm [against enormous demonstrable benefit of using bzr{,-builddeb} to track code]
<jelmer> AfC: ideally the changes against upstream should be split out in multiple quilt patches in "3.0 (quilt)"
<AfC> [[I realize it wasn't you who changed dpkg-source]]
<AfC> hm
<AfC> (as far as I can tell, this has totally borked the importer on launchpad, too)
<jelmer> AfC: which importer?
<AfC> jelmer: http://package-import.ubuntu.com/status/ that importer
<jelmer> AfC: previously dpkg-source would implicitly add a patch in debian/patches with the changes against the upstream source that were included in your working tree
<AfC> (I could be wrong, of course, but virtually every package I care about is miles behind there, now)
<AfC> jelmer: oh, didn't know that
<AfC> jelmer: still, pretty annoying. I use bzr to manage changes to the code tree; the last thing I want to do is mess with quilt patches. If I was doing that, I might as well not be using ... bzr
<jelmer> AfC: it was a conscious decision by the dpkg maintainers to stop doing that and to error out if there were changes in the working dir that weren't in upstream.
<AfC> jelmer: fair enough;
<jelmer> AfC: ideally we'd use bzr-loom and convert loom threads to quilt patches; that's still yet to emerge though
<AfC> jelmer: but given that bzr-builddeb is a different (and novel, and [c.f. lifeless â sabdfl] the whole point of "branches are the fundamental object")
<AfC> jelmer: I'm a bit unclear why builddeb can't just do whatever it needs to do to trick out dpkg-whatever to get on with building the package.
<jelmer> AfC: creating an implicit patch with the changes between upstream and your working tree, you mean?
<AfC> jelmer: sure, why not
<AfC> jelmer: implementation detail as far as I [the bzr-builddeb user who is happily managing deltas in bzr packaging branches] can see
<AfC> jelmer: would have expected builddeb to take care of such minor details. After all, it takes care of about 15 other similar issues
<AfC> jelmer: but instead, a *major* behaviour change has been imposed on the user base.
<AfC> jelmer: I'm not saying its wrong
<AfC> (after all, Debian policy decides such things)
<AfC> but for your users
<AfC> [ok, me]
<AfC> you have just committed a *massive* API break
<AfC> {shrug}
<jelmer> AfC: right, but I really think you should take that up with the dpkg maintainers
<AfC> in my world, if we did that to our clients we'd be fired
<AfC> jelmer: but *bzr-builddeb* is the build chain we use. What goes on under the hood has (delightfully until now) been an implementation detail.
<AfC> [and it's builddeb that just "broke" on us]
<AfC> anyway, I appreciate you filling me in.
<jelmer> AfC: so if you disagree with something in debian policy you would take it up with us too? That seems odd
<AfC> is there a document somewhere that explains how we're supposed to migrate off using bzr-builddeb?
<AfC> to be honest, I hadn't realized it was deprecated.
<jelmer> AfC: huh, in what way is it deprecated?
<AfC> jelmer: uh
<AfC> jelmer: it doesn't work anymore
<AfC> jelmer: in the way that we were taught to use it
<jelmer> AfC: migrating away shouldn't require any special action - you can either convert the repository to a different format (such as git) or just remove the .bzr directory
<AfC> jelmer: when a tool stops working
<AfC> jelmer: we generally try to help people get through the migration
<AfC> jelmer: [and we were taught to record changes to source trees in bzr]
<AfC> jelmer: I have in turn taught numerous clients this practice. They're all screaming at me now.
<jelmer> AfC: that makes sense for the 1.0 format perhaps, but certainly not for 3.0(quilt)
<AfC> jelmer: I realize it's my problem for having convinced them to work in bzr, but still
<jelmer> AfC: either way, you're doing Debian packaging and you're not just using bzr-builddeb but the entire set of debian packaging tools
<AfC> a behaviour break like this was unexpected
<jelmer> AfC: this has nothing to do with bzr
<AfC> hence my asking if there's a document about how to migrate to new practices. I didn't see anything in bzr-builddeb's documentation
<jelmer> AfC: the bzr-builddeb documentation documents bzr-builddeb itself, not debian packaging in general
<AfC> jelmer: I get that; I've been packaging for Debian since 1997
<AfC> jelmer: what I'm saying is that until now, bzr-builddeb allowed you to use bzr as the mechanism for tracking changes to upstream code trees.
<AfC> jelmer: as far as I can tell, a fair number of people thought we were supposed to be using it that way. Apparently we were wrong. Fine.
<jelmer> AfC: that still works for the "1.0" format I believe
<AfC> jelmer: though, at this point, I'm now vague on how you are supposed to use it. You um... dpkg-source --commit first, then bzr commit, then, um ?
<jelmer> AfC: there's no need to bzr commit
<AfC> jelmer: so you're not allowed to make *any* changes in bzr?
<AfC> jelmer: they all have to be done outside Bazaar?
<jelmer> AfC: you're not allowed to make any changes in the working copy, dpkg-source barfs if there are changes not in debian/patches
<AfC> Does it work like bzr or git? ie, does it have status and diff and commit?
<jelmer> AfC: I don't think it does
<jelmer> AfC: some of the git packaging tools have ways of converting these quilt patches to and fro branches
<jelmer> which can make them a bit more convenient to work with
<AfC> jelmer: so, what is bzr-builddeb used for now that you can't manage source changes with it? Just migrating existing packages between distro/releases?
<AfC> jelmer: [I'd hate to be giving out wrong information anymore]
<jelmer> AfC: FWIW I've personally never had local changes in the working tree with bzr-builddeb
<AfC> jelmer: ah. That explains it
<jelmer> AfC: that isn't to say that's not a valid way of working with it
<AfC> jelmer: there's nothing like NOT using the tool like its authors do to really set you up for a total goat-screw.
<jelmer> AfC: Sorry, but how have we set you up for that?
<AfC> jelmer: because those current and former #bzr employees who taught me how to use builddeb included that practice in what they showed me.
<AfC> jelmer: anyway, I'm willing to accept that I've been completely in the wrong
<jelmer> AfC: And I've not said you're using it wrong, just that I'm not using it that way.
<AfC> jelmer: and clearly need to mend my ways.
<jelmer> AfC: I have no idea how lifeless, james_w, etc use it.
<AfC> jelmer: certainly worth a very bitter blog post, though.
<jelmer> AfC: if you were doing the same thing in git you would be hitting the same issue
<jelmer> AfC: I still don't quite see how this is on bzr-builddeb rather than dpkg
<AfC> Oh, wow. Now it's failing with "no such file or directory" on the patch I just committed with dpkg-source. Fun.
<jelmer> AfC: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643037
<ubot5> Debian bug 643037 in dpkg-dev ""dpkg-source --commit" fails if there are no patches yet: No such file or directory" [Normal,Fixed]
<AfC> jelmer: {shrug} I said already. Either a) we were using the tool in a legal way, in which case we've had a major user experience break, or b) we were using the tool in an illegal way, in which case it would have been nice if we'd had some warning that we were about to get in trouble.
<jelmer> AfC: I agree with that, but $tool in this case is dpkg-source, not bzr-builddeb
<AfC> jelmer: well, obviously I think you're wrong about that, but we can move on.
<jelmer> AfC: I'd really like to understand why you think that's wrong
<AfC> that doesn't seem to be the ubg
<AfC> jelmer: if the scrollback doesn't do it, I'll send you a link to the blog when I write about it.
<AfC> anyway, dpkg-source --commit succeeeded
<jelmer> AfC: http://lists.debian.org/debian-devel-announce/2011/09/msg00001.html is the background of this
<AfC> it's bzr-builddeb that's again failing, this time with a different error. I'll see what happens with a fresh build
<jelmer> AfC: you can also go back to the 1.0 format, for which dpkg considers this an appropriate way of building
<jelmer> AfC: if there is only one diff file, why are you using "3.0 (quilt)" in the first place?
<AfC> jelmer: think about it, mate. *I* didn't pick that. I'm branching off an existing package. If they are using 3.0, then I am too
<AfC> {shrug} this is the first package I hit this on, [it's gedit]
<AfC> but this is the first packaging I've done since Precise came out
<jelmer> AfC: right, so if they picked 3.0 (quilt) that has an effect on the workflow you have to use
<AfC> so I see
<jelmer> AfC: if bzr would simply be creating a single patch for all the changes in the working tree, then that would defeat the purpose of 3.0 quilt, which is used to split the diff up into separate logical chunks.
<jelmer> I also believe that's why the dpkg maintainers changed the default to no longer generate a diff but to error out
<AfC> jelmer: yeah I understand
<AfC> jelmer: seems like a regression though
<AfC> for the past year I've been using bzr to manage changes to packages
<jelmer> AfC: you still can manage your existing packages with "1.0" source format
<AfC> Now apparently I'll have to throw those branches out and go back to not using a VCS.
<jelmer> AfC: what would you have us do for "3.0 (quilt)" ?
<AfC> jelmer: yeah, most of our branches are of packages that are existing Debian packages, and most of them have migrated to 3.0
<AfC> jelmer: {shrug} I'd have you force in a single diff
<jelmer> AfC: so you would want bzr-builddeb to alter the behaviour in existing tools?
<AfC> jelmer: I'm not submitting this packages to anyone. I'm just trying to build .debs
<jelmer> AfC: looking through dpkg-source, it seems adding "auto-commit" to debian/source/options would prevent this error
<AfC> jelmer: if that's a "bad" idea, then fine, we'll learn to get with the new way of doing it. Far be it for me to fight Debian policy. I'm just glad you were here tonight to explain to me that what we've been doing the last couple years isn't going to work anymore.
<AfC> jelmer: to be honest, I've never used `dpkg-source` before, but then, I haven't used `dpkg-builddeb` directly in years either.
<AfC> {shrug} builddeb was taking care of all that for us. It was delightful.
<AfC> (er, -buildpackage. You know what I mean)
<jelmer> AfC: yeah, debuild/dpkg-buildpackage/etc :)
<AfC> so, like I said, it feels like a 5+ year regression.
<AfC> jelmer: so, since I'm clearly so far off base using Bazaar to manage working trees, can I ask what you use bzr-builddeb for?
<AfC> jelmer: and where you do your actual packaging work?
<jelmer> AfC: Again, you weren't off base. "3.0 (quilt)" is incompatible with working-directory changes against upstream.
<jelmer> AfC: I use it as an easy way to build, mostly as an alias for "debuild"
<jelmer> AfC: occasionally to build historical revisions, and to get the orig source out of the packaging branch.
<jelmer> AfC: http://raphaelhertzog.com/2010/11/18/4-tips-to-maintain-a-3-0-quilt-debian-source-package-in-a-vcs/ might also be of help
<AfC> Hm. So I committed a patch with dpkg-source, but the build is still failing.
<AfC> Back to the drawing board.
<jelmer> AfC: how did it fail, are there any unknown files reported by 'bzr st'?
<AfC> I haven't used Quilt since running Gentoo in about 2003
<AfC> jelmer:
<AfC> modified:
<AfC>   .pc/applied-patches
<AfC>   debian/patches/series
<AfC> unknown:
<AfC>   .pc/99-change-redo-accelerator.patch/
<AfC>   debian/patches/99-change-redo-accelerator.patch
<AfC> the failure is weird, though:
<AfC> dpkg-source: error: cannot read gedit-3.4.1.orig.vU2NEG/debian/patches/99-change-redo-accelerator.patch: No such file or directory
<AfC> what a strange filename
<jelmer> AfC: you'll need to 'bzr add' the new files in debian/patches
<jelmer> AfC: and either add the .pc directory or undo the changes from the working tree
<jelmer> "QUILT_PATCHES=debian/patches quilt pop -a" should do the latter for you
<jelmer> there might be a shorter way, but my 3.0-quilt-foo is kindof limited
<AfC> jelmer: does bzr-builddeb do a `bzr export` under the hood, or just a copy of the current working tree [with changes]?
<AfC> I thought the latter
<jelmer> AfC: it does an export of the working tree
<AfC> so I have to bzr commit the .pc stuff, *then* build?
<jelmer> AfC: so unversioned files won't be included in the export, but modifications will be
<AfC> oh, ok
<AfC> [weird corner case]
<AfC> you said "add"
<jelmer> AfC: yes, you'll have to add them so they're versioned
<jelmer> AfC: but they don't have to be committed - bzr just has to know about them
<AfC> yeah
<AfC> ok, so this is just charming :/
<AfC> a) I used `dpkg-source --commit` to create a patch
<AfC> b) I reverted the change in my working tree
<AfC> c) added the aforementioned .patch
<AfC> [`bzr add` that is]
<AfC> which got me past the previous crash
<AfC> and now I have a crash which is identical to that which started the whole conversation: aborting due to unexpected upstream changes
<AfC> freaky :)
<jelmer> AfC: which files does it claim have changed?
<AfC> [I must admit I don't understand what the .pc files are doing, and seeing patches in diffs is always horrid to try and read]
<AfC> jelmer: it doesn't say...
<AfC> (reading the .build file)
<AfC> jelmer: ok
<AfC> jelmer: so it said
<AfC>    .pc/applied-patches
<AfC> jelmer: was modified
<AfC> jelmer: I reverted that file
<AfC> and now it's building
<jelmer> AfC: the .pc directory contains the quilt state, so which patches are applied, which unapplied, etc
<AfC> jelmer: I couldn't believe it had an entire copy of the original [unmodified] file in there.
<AfC> jelmer: I mean, I thought we got away from that after Subversion :)
<AfC> talk about primative.
<jelmer> heh, yeah :)
<AfC> and this is the brand new shiny Debian packaging format? Jeesh
<AfC> jelmer: well, thank you for your help
<AfC> jelmer: there's no way I would have navigated that by myself.
<AfC> Major conceptual mismatch, to be sure
<jelmer> AfC: anytime :)
<AfC> I'll have to sit my team down and have a review of this, because we were planning to ramp up our use of the "old" way of doing things quite substantially.
<AfC> They were quite enthusiastic about bzr as a result of what I'd showed them about comparing different branches
<jelmer> I guess in a way it's indeed like a primitive version control system, and that's one of the reasons it's so hard to deal with it /and/ bzr, git or hg.
<AfC> Seeing patches in VCS diffs is not exciting in the sightest.
<jelmer> I've been meaning to play with some of the git debian tools (there are three equivalents to bzr-builddeb for git), apparently they do some smarter stuff than we do, like maintaining separate branches for each patch and automatically generating debian/patches from that.
<AfC> Interesting
<AfC> jelmer: I have no Git skills at all, which is becoming harder and harder to admit to people.
<AfC> Bah
<AfC> I can't believe I am about to commit a *patch* to a version control system.
<AfC> Next they'll be telling me to commit binaries :/
<jelmer> AfC: Git's UI is significantly better than what it used to be 5 years ago, it's really not too bad. I'm sure you could learn most of it in a couple of hours.
<AfC> jelmer: well, I'm about to have to do a bunch of work against a git repo. I'm hoping I can get by using bzr to shuttle patches to my git clone. It's not clear to me yet whether bzr-git will let me push from there safely or not. Hard to experiment without [risking] making a big mess
<AfC> we'll see
<AfC> [I dog fooded Git for 6 months circa 2006. Ick. Oh well :)]
<AfC> [back to packaging]
<AfC> Wow, this is a horrid regression
<AfC> so before when upstream released a new version and that code propegated to us via import-dsc and friends,
<AfC> we would get those changes into our working tree and then could resolve conflicts and carry on.
<AfC> Now my changes are *not* in the working tree, but instead in unapplied patches.
<AfC> God, I hope I'm missing something obvious about all this.
<jelmer> AfC: yep
<jelmer> AfC: you can use quilt to try and fix up the patches afterwards
<AfC> This is awful
<AfC> Are you sure we can't just take our working tree and blat it down as a single patch before building binaries?
<jelmer> it would be really nice if we could represent patches as branches here (and just "up-merge" the new upstream release)
<jelmer> AfC: you can, but I'm not sure if your comaintainers will appreciate that, since they changed to 3.0(quilt)
<AfC> jelmer: {shrug}
<jelmer> AfC: I think "echo auto-commit > debian/source/options" will do that
<jelmer> (and bzr adding that file)
<AfC> jelmer: I differentiate pretty significantly between what we have to do to maintain *our* packages, and then shifting frame-of-reference and doing whatever is necessary to submit a patch upstream (or to downstream peer)
<AfC> jelmer: ok, I'll look at that
<AfC> jelmer: I'm just reading the man page for dpkg-source now
<AfC> jelmer: there's a useful discussion under --single-debian-patch
<jelmer> AfC: hmm, indeed
<AfC> jelmer: so I'm starting to get it now. I see the difference between 3.0 ({native,quilt,git,bzr})
<jelmer> AfC: (note that 3.0 (git) and 3.0 (bzr) aren't actually used in practice)
<AfC> jelmer: right; I need to adapt to whatever is going on in the original package I've forked from
<jelmer> I don't think I've actually seen a package that used either "3.0 (git)" or "3.0 (bzr)"
<AfC> jelmer: though now that I understand, I think auto-commit would be the least disruptive. Have to test it. Certainly be more sensible locally.
<AfC> [in the event of a 3.0 (quilt)
<AfC> format package[
<jelmer> AfC: yeah, looks like it
<AfC> jelmer: I will definitely write this up
<AfC> jelmer: thanks for your help
<AfC> [trying that experiment now, while everything is open]
<AfC> Build running
<AfC> Nice. So I suspended the build, and looked in ../build-area/
<AfC> There is indeed a new patch added to the end of debian/patches/series
<AfC> along with a new patch file there
<AfC> filename
<AfC> debian/patches/debian-changes-3.4.1-0ubuntu2~afcowie2~precise2
<jelmer> ah, cool :)
<AfC> Raises an interesting issue, of course
<AfC> Are the debian/patches applied in the bzr[-builddeb] working tree, or not?
<AfC> Huh. It seems they *are* applied.
<AfC> [great!]
<AfC> jelmer: did you know that?
<jelmer> AfC: yeah, they would have to be
<jelmer> bzr exports the tree including the working tree changes
<AfC> [and then dpkg-source unapplies them before building where it ... applies them? Head hurts]
<jelmer> and then calls dpkg-source in the working tree. dpkg-source then generates a matching patch in debian/patches and makes sure the other patches are all applied
<jelmer> AfC: I think dpkg-source unapplied all patches first so it can generate your auto-commit patches without including the changes from the other patches.
<AfC> Remind me to use 3.0 (native) for my own work :)
<AfC> jelmer: maybe
<AfC> jelmer: I'm just pleased that bzr-builddeb's working tree includes the debian/patch series applied
<AfC> jelmer: 01:30 local, time for me to pack it in. Business calls first thing tomorrow.
<AfC> jelmer: Thanks for your patience.
<AfC> jelmer: we definitely need to write this up. I'll show you the post once I've got it drafted; please feel free to offer critique or corrections.
<jelmer> AfC: sure, it would be great to document this better
<jelmer> AfC: good night!
<hmmh> hi guys - was wondering if anyone can lend a helping hand - i have the bazaar "daily" builds going for our pkg, but when i install them, there is no binary?!
<hmmh> what am i doing wwrong?
<jelmer> hmmh: hi
<jelmer> hmmh: does building the package on your local machine work?
<hmmh> yes (i have not confirmed the last recepie - will check that now, thanks) but I have no err during build and so on .... hmm
<hmmh> yes it does build/install no problem
<hmmh> if tested locally
<hmmh> .....but there is no binary as well in the local install ....this is definitely a wrong recipe - any help?
<jelmer> hmmh: have you tried the recipe locally?
<jelmer> hmmh: this kind of issue is generally just a bug in the packaging
<hmmh> jemler: yes i tried it locally - but i have the same result - makes and installs a pkg ..but with no binaries..
<hmmh> jelmer: my recepie has "nest-part packaging lp:~our/+junk/ourpkg debian debian" - is this correct?
<jelmer> hmmh: that seems right
<jelmer> hmmh: have you tried creating just the source package and seeing if that has the right contents?
<hmmh> jelmer: when i create regular pkgs (not for daily builds, not using the "code brunch") - there is no problem installing and creating the pkg
<jelmer> hmmh: recipe builds only create source packages, the binaries that are created afterwards are built from those source packages and are not in any way special
<jelmer> so if this is a problem with the recipe, you should be able to find the issue in the source packages that are created by "bzr dailydeb"
<hmmh> jelmer: which source pkgs? it creates the sources dirs and nests the debian dir under...... what just noticed is that in my control file i have " (1.3beta1-4ubuntu4) maverick; urgency=low"
<hmmh> jelmer: could "maverick" be the issue
<hmmh> hi, does anybody know how can i upload to my "code" from Git?
<lifeless> what do you mean by your "code" ?
<hmmh> well ... i would like to make a bazaar branch FROM a git repo..
<hmmh> and then build daily pkg based on a receipt
<hmmh> i meant recipie
<lifeless> In Launchpad, or separately ?
<hmmh> in launchpad
<hmmh> I have a launchpad , I would like to clone a git repo, import that into bazaar and make daily builds based on it and continue to import new revsisions from the git master - is that possible ?
<lifeless> you can use an import branch to get your code into bazaar
<lifeless> https://help.launchpad.net/Code/Imports
<hmmh> yep I saw that - so this is the only way - I have to request an official import?
<lifeless> that or manage it yourself
<lifeless> e.g. use git-bzr or bzr-git and cron and so on
<hmmh> thank you for the answer - how do i use bzr-git? ant example?
<jelmer> hmmh: 'bzr branch git://some/git/url bzr-import', if you have bzr-git installed
<lifeless> hmmh: most folk wanting recipe builds do it all in Launchpad
<lifeless> hmmh: as its easier
<hmmh> jelmer: is that the preferred way, or you can use that as well - bzr git-import git://some/git/url  ?
<jelmer> hmmh: bzr git-import imports all branches, 'bzr branch' just the current one
<hmmh> jelmer: the current one , you mean the current revision of git?
<hmmh> the last commit ?
<jelmer> hmmh: the active branch
<jelmer> hmmh: IOW, HEAD
<hmmh> k, thanks
<hmmh> jelmer: after i do "'bzr branch git://some/git/url" , can i import that directly - "bzr push lp:~ourlaunchpad" ?
<hmmh> jelmer: and use it as a base, then get the pkging info from a different LP id? would that be ok to do? or not supposed to do it that way?
<jelmer> hmmh: you can push to lp:~ourlaunchpad after you've imported, yes
<jelmer> hmmh: a recipe can use branches owned by different users
<lifeless> hmmh: the way you're meant to do it is use an LP code import + an LP hosted packaging branch, the owners of the two things can be different
<hmmh> thank you guys
<jelmer> hmmh: have you tried downloading the source package and seeing if that is correct?
<hmmh> jelmer: this is the problem that we have - https://code.launchpad.net/~oisf/+recipe/testing-daily-2 - everything builds fine ... but when installed , there are no binaries - sorry to bother, much appreciated if you can share an oppinion.
<jelmer> hmmh: have you tried downloading the source package and seeing if that is correct?
<hmmh> yes ... when i get the source pkg , i get the tar.gz the .dsc everything is there...
<jelmer> hmmh: in that case the recipe is unrelated - the recipe is only used to build the source package
<jelmer> hmmh: after that, it's just the regular build process for source packages
#bzr 2013-05-20
 * jelmer wonders if w7z is the upgraded version of mgz
<w7z> a different model, at least :)
<jelmer> :)
<jaalto> How can I wrap changes in REV..REV into individual patch sets, like in git 001-* 002-* ?
<thomi> Hi everyone, I'm trying to get the timestamp of the last revision in a bzr branch using bzrlib. I've found Branch.last_revision_info(), but I can't seem to get from there to a timestamp.
<thomi> I've been trawling the log command code, since that does it, but it's.. complicated to say the least. I wonder if anyone here has some hints?
<jelmer> thomi: hi
<jelmer> thomi: branch.repository.get_revision(branch.last_revision()).timestamp
<thomi> jelmer: hey, I actualy figured it out in the end, sorry, I should have posted here
<jelmer> thomi: no worries, glad you found it :)
<thomi> jelmer: one thing I'm not sure about though - the revision's timezone attribute, is that in minutes offset?
<jelmer> thomi: yes, minutes delta to UTC
<thomi> awesme
#bzr 2013-05-22
<Wiz_KeeD> hey guys!
<mgz> hey
<Wiz_KeeD> i have a question, if i have commited and push-and-update
<Wiz_KeeD> there's no way i an uncommit that right?
<Wiz_KeeD> i just forgot to change 1 line or something liek that, the other changes are perfect, but that 1 line could halt the code and i wanted to have working commits
<Wiz_KeeD> i test before i commit but shit somethimes happens :)
<mgz> you canm but it's generally better to just fix in a new commit
<mgz> otherwise anyone else who has pulled the branch needs to know you've changed history
<Wiz_KeeD> It's just me on localhost and deployment server that's it
<Wiz_KeeD> otherwise if i made a bad commit it's normal to commit and do a "[FIX]" so everyone knows
<Wiz_KeeD> but in this case...
<ccxCZ> ImportError: cannot import name shlex_split_unicode
<ccxCZ> bzr-2.5.1
<ccxCZ> nvm
<mgz> probably an out of date plugin? bug 997229 say
<ubot5> bug 997229 in svncreate "cannot import name shlex_split_unicode" [Undecided,New] https://launchpad.net/bugs/997229
<ccxCZ> yup, old version of externals
<ccxCZ> thnxbye :-)
#bzr 2013-05-23
<KombuchaKip> Off topic, but how do I set the default language of my LP project so that the message catalog template isn't marked as "0%" translated when it's already in the native language?
<vila> KombuchaKip: Sorry, no idea about that but may be #launchpad is more appropriate ?
#bzr 2013-05-24
<mahendra> is there anything i forgot to use bzr with no proxy ?
<mahendra> its working now when i used https://launchpad.net/mailman instead of lp:mailman. any clue why ?
<SonikkuAmerica> I'm having a problem getting Bazaar to recognize my SSH pubkey...
<SonikkuAmerica> It's registered on Launchpad and everything...
<SonikkuAmerica> I should also mention this is Ubuntu 13.04
<SonikkuAmerica> I'm having a problem getting Bazaar to recognize my SSH pubkey... It's registered on Launchpad and everything... I should also mention this is Ubuntu 13.04
<mgz> SonikkuAmerica: pastebin `ssh -vv YOURLPUSERNAME@bazaar.launchpad.net` swapping out the bit in caps obviously
<SonikkuAmerica> http://paste.ubuntu.com/5697008/
<SonikkuAmerica> It appears to be looking exclusively for id_rsa.pub or id_dsa.pub, but my key is not named as either... does it need to?
<mgz> either tha... come back!
<fullermd> Great, you broke him.
<SonikkuAmerica> Oops
<SonikkuAmerica> Killed the wrong window
<mgz> ...or add it in ~/.ssh/config
<mgz> as IdentityFile for host bazaar.launchpad.net
<SonikkuAmerica> OK...
<w7z> see <https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Using_a_custom_SSH_key_for_Launchpad>
<mgz> SonikkuAmerica: ^example
<SonikkuAmerica> OK
<SonikkuAmerica> Let me give that a shot...
<SonikkuAmerica> No such luck
<mgz> run the same debug ssh command again
<mgz> and paste
<SonikkuAmerica> http://paste.ubuntu.com/5697038/
<mgz> you set the private key as IdentityFile, not the .pub
<SonikkuAmerica> Oops
<mgz> *you *should*...
<SonikkuAmerica> Wait... I specified the .pub, it says so
<SonikkuAmerica> (Check line 9 of the paste)
<mgz> right, you should not, omit the '.pub' suffix in the config
<SonikkuAmerica> Oh. (That's confusiong.
<SonikkuAmerica> )
<mgz> yeah, realised what I said was ambigous. do the other one from what you have :)
<SonikkuAmerica> mgz: So delete the .pub extension and then paste the resulting [ ssh -vv ] output?
<mgz> yeah, though if it works it'll end "no shells available" or similar and you can just try bzr after
<SonikkuAmerica> Unfortunately, it didn't: http://paste.ubuntu.com/5697055/
<SonikkuAmerica> It seems that it sent one and then didn't
<mgz> what does `ls -l ~/.ssh/superkey` say?
<SonikkuAmerica> It returned "No such file or directory." Odd.
<mgz> so, make sure you specify a key that actually exists and has the .pub that corresponds to what you uploaded to launchpad :)
<SonikkuAmerica> I do have an id_rsa and id_rsa.pub in there from another shot though. Should I send that to Launchpad and try it instead...?
<mgz> you can
<SonikkuAmerica> OK
<mgz> remember it's the .pub that you upload
<SonikkuAmerica> Yep
<SonikkuAmerica> Here's the result: http://paste.ubuntu.com/5697076/
<mgz> okay, you're good to go
<SonikkuAmerica> Looks like it worked because it prompted me for the key's passphrase
<SonikkuAmerica> All right! Now on to build Unity Next (that's why I needed it)
<SonikkuAmerica> Thanks guys!
#bzr 2014-05-21
<matkor> Hi! How can I get list of all deleted files in given branch?
<matkor> All deleted since creating branch.
<matkor> bzr status -r REV  seems be answer ;)
#bzr 2014-05-23
<SamB> hmm, I guess I can't push to launchpad's Debian branches, not least of which because how the heck is launchpad supposed to know if I'm allowed to mess with a given Debian package ...
<jelmer> SamB: nobody but the importer can push to the "official" branches
<jelmer> SamB: but you can create other branches in the same namespace
<SamB> any advantage to that rathe than just using the normal namespace either on launchpad or alioth?
<jelmer> SamB: I don't think alioth would appreciate mass pushing of bzr mirror branches :)
<SamB> I mean, I'm looking to get pkg-create-dbgsym uploaded to Debian for people to play with
<jelmer> SamB: also, predictability and integration with the rest of launchpad
<SamB> I figure branching from the ubuntu branch is the way to go there
<SamB> but I'm not sure where I should host my branch
<SamB> or what name it should have
<jelmer> SamB: personally, I'd host it on alioth if it was a debian branch
<SamB> hmm, can bzr automatically rewrite URLs for pushing to?
<SamB> like, I have this for git:
<SamB> [url "git+ssh://git.debian.org/git/"]
<SamB> pushInsteadOf = "git://anonscm.debian.org/"
<SamB> pushInsteadOf = "git://git.debian.org/"
<SamB> hmm, looks like no
<jelmer> not in that way
<jelmer> though it supports different push and pull urlds
 * SamB grumps about how they only did a half-assed implementation for lp: URLs
<SamB> (plus the authentication config stuff, which lets you skip a lot of URL parts but doesn't handle the scheme or anything)
<SamB> (and anyway I do that part in my SSH config)
<jelmer> SamB: how do you mean?
<SamB> jelmer: I set the default username for alioth's hostnames in my SSH config file
<SamB> so it seems like there is nothing in "bzr help authentication" for me to do
<jelmer> SamB: I don't understand how this is related to lp:?
<jelmer> I can just push to bzr+ssh://bzr.alioth.debian.org/bzr/pkg-bazaar/bzr/unstable for example
<jelmer> no further config necessary
<SamB> oh, the lp: thing? I'm just figuring they'd be more likely to have bothered to add a general feature like git has if they hadn't already got the "lp:" scheme that allows both authenticated and unauthenticated users to work with the same URLs
<jelmer> SamB: there are some other things you can do, like have the remote URL be derived from your local URL - and that can be different for push and pull URLs
<jelmer> I don't know from the top of my head what the syntax is
<jelmer> and a rewrite thing like git has is probably more powerful in some situations
<jelmer> but lp: URLs are a relatively late addition, and there are/were lots of people working with non-lp URLs (including devs)
<mgrandi> can anyone enlighten me on the correct behavior of MutableTree.smart_add() ? It says its supposed to take a relative path but its defenitly not working correctly
#bzr 2014-05-24
<jelmer> mgrandi: relative to the working tree rather than os.getcwd() I think
<mgrandi> there is a comment in the code saying its "interpreted relative to the process cwd, not relative to the tree"
<mgrandi> but even then, i'm giving it the correct relative url, but its stuck saying that the directory the script is running in is not a child of the tree
<mgrandi> i have to os.chdir() to the tree and then just smart_add(".") to get it to work =/
<Peng> smart indeed
<SamB> is http://anonscm.debian.org/bzr/users/naesten-guest/pkg-create-dbgsym a terrible choice for my branch of lp:ubuntu/pkg-create-dbgsym ?
#bzr 2014-05-25
<SamB> % bzr register-branch --dry-run http://anonscm.debian.org/bzr/users/naesten-guest/pkg-create-dbgsym/
<SamB> Branch registered.
<SamB> this seems a bit ... confused
#bzr 2015-05-19
<ychaouche> Hello #bzr
<ychaouche> I have checkouted a branch from my machine to a distant machine. My machine had the IP 192.168.100.109.
<ychaouche> Then I changed the IP of my machine to 192.168.100.131, and now I can no longer commit from the distant machine, probably because it still keeps the old IP in its config.
<ychaouche> https://gist.githubusercontent.com/ychaouche/956d225727817d82ea3f/raw/f7c5e852a2533030b4c0a6bb52e8bd93ab0b3460/gistfile1.txt
<ychaouche> I can't even do a switch now : I tried a bzr switch but it also times out.I
<ychaouche> oops, wrong paste : https://gist.githubusercontent.com/ychaouche/b723dc782d28f795795b/raw/119c324711ede412ce1895f3b640862b899ac5fc/gistfile1.txt
<ychaouche> Had to checkout to another directory, manually copy modified files to that directory, commit.
<ychaouche> If there's a shortcut for this I think I would benefit from it.
#bzr 2015-05-21
<shawnwang> :q
#bzr 2016-05-28
<GyrosGeier> hi
<GyrosGeier> I have an automated build using Jenkins, where I use bzr merge to add a stack of patches from a separate branch
<GyrosGeier> I have to back these out before updating the tree, or I get conflicts in a way that Jenkins notices
<GyrosGeier> currently, I do
<GyrosGeier> $ bzr clean-tree --quiet --ignored --unknown --detritus --force
<GyrosGeier> $ bzr pull --overwrite ...
<GyrosGeier> $ bzr revert
<GyrosGeier> and then merge my branch again
<GyrosGeier> is there a way to do the same without cleaning the tree?
<GyrosGeier> in a way that still works if files are added or removed in the merged branch
<GyrosGeier> new files from the merged branch get left behind otherwise, and the second time the branch is merged, the merge fails
<GyrosGeier> oh wait
<GyrosGeier> another clean-tree after the revert
<GyrosGeier> to make it actually work
<GyrosGeier> is there a "merge --overwrite" or similar?
<GyrosGeier> i.e. if the merge adds a file, that takes precedence over workspace files
<GyrosGeier> example log of a build: http://ci.kicad-pcb.org/job/windows-kicad-msvc-head/cpu=x86,label=windows/979/consoleText
<GyrosGeier> the merged branch changed, as it was rebased, and a file changed in both sides
#bzr 2018-05-23
<Pharaoh_Atem> hmm
<Pharaoh_Atem> hello!
<Pharaoh_Atem> I just read about breezy
<Pharaoh_Atem> it looks interesting, and ambitious
<Pharaoh_Atem> I'm interested in bringing breezy to Fedora, but it doesn't seem like there's anything to ship?
<Pharaoh_Atem> but there appears to be Ubuntu packages :/
<jelmer> hi Pharaoh_Atem
<jelmer> Pharaoh_Atem: we haven't done any proper releases yet
#bzr 2018-05-25
<Lucifer_arma> ok, so, I have a subdirectory in a bzr branch that I need to spin off as its own separate branch by itself, with none of the history from the project it came from
<Lucifer_arma> how do I do that?
<Lucifer_arma> keeping the history isn't terribly important, so I could just delete the .bzr directories and go from there, but I'd rather keep the history if I could
<fullermd> There's a 'split' command, that I believe creates a new branch with the subdir's history.
<fullermd> (obviously all the revs are different, but...)
<Lucifer_arma> maybe I've done something wrong, then?  I tried that.  :)
<Lucifer_arma> $ bzr branch dswc/src davecrm
<Lucifer_arma> bzr: ERROR: Not a branch: "/home/dave/Projects/dswc/src/.bzr/branch/": location is a repository.
<Lucifer_arma> and this:
<Lucifer_arma> $ bzr status
<Lucifer_arma> bzr: ERROR: No WorkingTree exists for "file:///home/dave/Projects/dswc/src/.bzr/checkout/".
<Lucifer_arma> bzr info tells me it's an unshared repository
<fullermd> Well, you're doing at least two things wrong then   :)
<fullermd> I blame Friday.
<Lucifer_arma> heh, ok.  So what am I doing wrong?
<fullermd> First you'd need a branch with a WT to do the split in.  Probably a scratch copy, not your main one.
<Lucifer_arma> ok, there actually is a working tree in this branch.  I made a copy by branching in the first place :)
<fullermd> 'k.  So see what you get from running split on the subdir.
#bzr 2018-05-26
<Lucifer_arma> this is what I got when I ran it:
<Lucifer_arma> $ bzr split src
<Lucifer_arma> bzr: ERROR: No WorkingTree exists for "file:///home/dave/Projects/dswc/src/.bzr/checkout/".
<fullermd> Where are you when you do that?
<Lucifer_arma> also, it's a 9 year old repository, so I had to upgrade the format to be able to do the split in the first place
<Lucifer_arma> I'm in the project root
<Lucifer_arma> so, home/dave/Projects/dswc
<fullermd> What's bzr info tell you?
<Lucifer_arma> Unshared repository with trees (format: pack-0.92)
<Lucifer_arma> Location:
<Lucifer_arma>   repository: .
<fullermd> 'k, so you're not in a branch.
<fullermd> Gotta be in the branch/WT in question.
<Lucifer_arma> wait, that was inside src
<Lucifer_arma> bzr info in dswc says standalone tree and gives the expected information
<fullermd> Mmph.  So you've got a repo _underneath_ a branch?  That sounds like a recipe for surprises...
<Lucifer_arma> that's what happened after I did the split, afaik
<fullermd> Mmm.  Well, that would be a little more expected...
<fullermd> Sounds like you've got some halfway stuff around.
<Lucifer_arma> halfway stuff?  like uncommitted changes?
<fullermd> More like part of a split, or part of an init/init-repo, or whatnot...
<fullermd> Though, actually, I'm not sure pack-0.92 is even rich root, so that might cause weird failure too.
<fullermd> I'd make a fresh scratch branch nowhere near anything extant (in /tmp or the like, say), make sure it's 2a format, and try from scratch there.
<Lucifer_arma> ah, ok, I figured out what I did wrong :)
<Lucifer_arma> I should have done "bzr split ." from inside src
<Lucifer_arma> I did it all over again with that change and it appears to be working now
<Lucifer_arma> so, am I guaranteed not to have the ability to access commits from the rest of the project now?
<Lucifer_arma> it's a website that's has private sources, but I'm spinning off the scripts I use to generate it so I can release those publicly
<fullermd> Pretty sure none of the content will be in the new branch, no.
<fullermd> The commit messages would be the same, so stuff touching both inside and out may have stuff in the logs you want to hide.  Or not, depending on your commit messages.
<Lucifer_arma> don't care about that.  It's also not that big of a deal if old stuff gets out, but it's better to start with a fresh repo and no history than to have other people digging through my website sources ;)
<Lucifer_arma> ok, so I get something like this after the split (I'm only including a couple of lines of output)
<Lucifer_arma> $ bzr status
<Lucifer_arma> removed:
<Lucifer_arma>   .bzrignore
<Lucifer_arma>   .dswc_data/
<Lucifer_arma> where .dswc_data is part of the original project, and there's a list of all the files that are gone now.
<Lucifer_arma> ok, last question.
<Lucifer_arma> Is this the expected behavior if I try to revert to a revision number from before the split?
<Lucifer_arma> $ bzr revert -r 257
<Lucifer_arma> bzr: ERROR: Key src-20090728034756-vx3lt2pqch83qh4t-1 is already present in map
 * fullermd frowns.
<fullermd> Well.  I thought split made a new history, but I guess it doesn.t
<fullermd> So, let's agree I never said anything in the first place, so I look smarter.
<Lucifer_arma> well, it didn't actually do the revert
<fullermd> That's pretty likely a bug, from the somewhat weird post-split state.
<fullermd> Apparently all split does is rm a bunch of stuff and pivot the root.  That root state is probably an edge case revert doesn't grok.
<fullermd> Maybe there's someting in the rewrite plugin that'll do the job?  I don't really know it...
<Lucifer_arma> well, the .bzr directory is 54MB, which is consistent with it actually having all the other files in it
<Lucifer_arma> so, I guess I'll just export from bzr and start with a brand new repository?
<fullermd> Yeah, simplest.
<Lucifer_arma> well, thanks for the help.  Have a good weekend.  ;)
