#bzr 2007-12-10
<Peng> Nice, I think that push is stuck again.
<ubotu> New bug: #175207 in bzr "Fix Makefile rules for doc generation" [Medium,In progress] https://launchpad.net/bugs/175207
 * igc lunch
<zerok> morning :)
<Peng> Indeed it is.
<Peng> Except for you weirdos in the Pacific ocean.
<Peng> :P
<zerok> ^_^
<spiv> vila: I've partially diagnosed my squid problem (bug 172701)
<ubotu> Launchpad bug 172701 in bzr "Large readv requests can fail if there is a squid proxy" [High,Fix released] https://launchpad.net/bugs/172701
<vila> spiv: I'm all ears
<spiv> vila: the extreme slowness appears to be because squid will sometimes fetch entire files even if the client asks for just a range -- even if the client also sets Pragma: no-cache & Cache-control: max-age=0.
<vila> And even with that we manage to get a *short* read...
<vila> you're sure it's not triggered by bzr issuing a new request after a short read instead ?
<spiv> vila: So the client sends requests to fetch a small amount of a large pack file, and squid fetches the whole thing and then forgets it.  Then the client asks for a different part of the same file, and squid fetches the whole thing over again, etc.
<spiv> vila: So I haven't reproduced the shortv since you claimed to have fixed it
<spiv> vila: but this explains why it's ridiculously slow :)
<spiv> s/shortv/short readv/
<vila> the way I fixed it is to issue a larger request (single range encompassing all the offsets or if that fails too the whole file) when a short read is encountered
<vila> if you still can reproduce it try with -Dhttp, that will log all the requests and mention the retries
<spiv> Well, I can't reproduce the ShortReadvError anymore, so that particular bug is fixed.  (Thanks!)
<spiv> But I thought you'd be interested to know about some of the other strange behaviour (extreme slowness) I saw while experiencing that bug :)
<vila> my fix for 173010 has landed, it will produce still another behavior (pycurl will not emit requests bigger than 4M) so be sure to check what version you're using
<spiv> I'm testing with your fix for 173010
<vila> spiv: ha, good
<spiv> I thought trying to reproduce 172701 might be a good stress test to make sure your patch really didn't break anything :)
<spiv> vila: heh
<spiv> vila: it's bug 1337 in squid's bug tracker :)
<ubotu> Launchpad bug 1337 in malone "Distro release tasks should include name of distro" [Low,Invalid] https://launchpad.net/bugs/1337
<spiv> ubotu: no, http://www.squid-cache.org/bugs/show_bug.cgi?id=1337 :P
<vila> lol, did you noticed that mac distro related bug waws leeeeet too ? :)
<vila> spiv: so that squid bug is really bad for us or you can tune the range_offset_limit ?
<vila> hmmm, thinking more about it, at the time of 172701 we were issuing far too much ranges , so maybe this bug has been fixed in two different ways
<spiv> vila: well, when using http+urllib I still see "http readv of a3069b4df97462558e8666ff0cc72386.pack  offsets => 705 collapsed 161
<spiv> "
<spiv> vila: the fetch completes though.
<spiv> vila: it takes about 16m now (with both urllib or pycurl) to do the pull in 172701 through my squid proxy.
<vila> spiv: it may still occurs for valid reasons (fragmented repo), before the patch more ranges can be emitted for not so valid reasons
<spiv> vila: which is better than in 172701 (where it was failing, and taking longer to do so!)
<spiv> So I'm pretty happy.
<vila> happy to help jam's(TM)
<vila> yet 16m for an update... is that a bound branch ?
<spiv> vila: nope
<spiv> vila: just "bzr branch -r 2977 bzr.dev /tmp/foo; cd /tmp/foo; bzr pull http://bazaar-vcs.org/bzr/bzr.dev/"
<spiv> vila: if I bypass my squid proxy, it takes 9m 43s to do the same pull.
<spiv> vila: (versus 16m 5s with squid)
<vila> hmm, bad proxy :-/
<spiv> vila: yup :(
<spiv> I'm going to try tweaking range_offset_limit
<vila> ha, let me know, if you succeeds that will be worth mentioning it in bug #172701 at least
<ubotu> Launchpad bug 172701 in bzr "Large readv requests can fail if there is a squid proxy" [High,Fix released] https://launchpad.net/bugs/172701
<spiv> vila: curiously, my squid.conf claims that range_offset_limit is already 0 (i.e. never fetch more than client requested).
<vila> hmm, try setting it to 250 (our max is 200)
<vila> we  issue several range requests on the same file, squid may have some problem with that
<vila> ouch forget that, range_offset_limit is not a number of ranges it's a true offset possible value
<dato> vila: <weasel> how do I tell bzr to use a different ca-certificates file (for https), or tell it to accept cert with fingerprint $fpr for a host?
<dato> vila: I guess you're the right person to ask that to :)
<vila> dato: you can't... yet ;-)
<dato> vila: ok, thanks. (not even with pycurl, I guess, right?)
<vila> dato: oops, checking code, it seems you can use CURL_CA_BUNDLE to indicate a different ca-certificates file (I thought only win32 can do that) but I never tested it myself
<vila> I'm currently working on a https test server, once that's done, I plan to add these capabilities to urllib and be in position to deprecate pycurl
<dato> aha. CURL_CA_BUNDLE, environment variable?
<vila> dato: yes
<dato> thanks
<vila> dato: if you test it let me know
<dato> certainly not me, maybe weasel .9
<dato> er, :)
<vila> bialix added it for win32 so I don't know that code very well
<vila> oh, I see, being unsure about the meaning of <weasel> I thought it applied to the question not the originator ;-0
<dato> phanatic: out of interest, why bzr-gtk 0.93 instead of 1.0?
<phanatic> dato: see the release announcement Q&A :)
<dato> phanatic: d'oh, sorry!
<dato> very well
<dato> phanatic: but
<dato> phanatic: should I still enforce at packaging level that 0.93 needs 1.0, and can't work with e.g. 1.1?
<phanatic> dato: i suppose the bzrlib API should be backwards compatible throughout the whole 1.x series...
<radix> I sure hope so, maybe I will actually be able to use bzr-gtk if the bzrlib API stabilizes :)
<dato> I haven't seen any mention that API changes will be handled any different in 1.x than they were in 0.x
<dato> but alas, I don't read every post in the list :)
<jelmer> bzr-gtk uses some of the most common API's exported by bzr
<jelmer> I bet 0.93 is compatible with even 0.18
<jelmer> some of the other plugins like bzrtools and bzr-svn use more obscure API's that are more prone to changes
<radix> so there's no need for the restrictive dependency in the .deb?
<jelmer> not imho
<dato> let's drop it then
<radix> that would be fantastic
<radix> I haven't been able to use bzr-gtk in quite a while because of it
<dato> why?
<radix> dato: because I keep track of the bazaar repository and every time I try to install bzr-gtk I don't have an old enough version of bzr
<radix> unless this has recently changed, I don't think bzr-gtk is updated at the same time as bzr
<jelmer> that's still the case
<jelmer> bzr-gtk releass some time after bzr releases a rc usually
<dato> radix: what repository? bazaar-vcs.org/releases/debs ?
<jelmer> dato: Debian Sid as well
<radix> the bazaar-vcs.org repository, yeah, wherever it is
<jelmer> dato: simply because upstream is behind and hasn't released a compatible version yet
<dato> yes, but... he should be able to install bzr-gtk in a couple days (or, ok, a week)
<dato> jelmer: yes, I know that. only, that I'm very surprised to hear radix say that he hasn't been able to use bzr-gtk for a long while because of that
<radix> dato: bzr releases pretty regularly
<jelmer> well, 1.0rc1 is two weeks or so old now?
<radix> as I'm sure you're aware
<jelmer> not sure what qualifies as "a long while" in radix' opinion :-)
<radix> so maybe there are some windows in which I could install bzr-gtk
<radix> jelmer: 6 months maybe?
<radix> every time I try I seem to either get a dependency error, or it's soon uninstalled the next time I upgrade bzr
<dato> anyway, I just think that if you care about bzr-gtk, you shouldn't dist-upgrade bzr until both become available
<dato> if you're blingly dist-upgrading, otoh...
<radix> I use stable Ubuntu releases, augmented with the bazaar-vcs.org repository.
<radix> I'm not tracking debian unstable or something like that
<dato> well, bazaar-vcs.org has bzr-gtk 0.90 ...
<dato> radix: without needing to track unstable, you could just grab bzr-gtk from there
<dato> if you care enough, that is :)
<radix> dato: right, and that version of bzr-gtk depends on bzr << 0.91~, but the version of bzr it has is 1.0~rc1-3bazaar1
<ndim> radix: That is bzr-gtk's and bzr's way of telling you to go take a 3 week vacation until the thing is sorted out.
<radix> ndim: more like a 6 month vacation :)
<radix> which I'd be happy to do ;-)
<dato> radix: if you'd like, http://incoming.debian.org/bzr-gtk_0.93.0-1_all.deb ought to install with your current bzr
<radix> sweet! with fixed dependencies and everything! you're my hero :-)
<dennda> hi
<dennda> what's wrong here? http://pastebin.ca/811148
<dennda> and how do I fix it?
<dato> dennda: you made a checkout of a read-only transport
<dato> dennda: if you run `bzr checkout`, you should use a sftp:// url, instead of an http:// one
<dato> dennda: try this:
<dato>   bzr unbind
<dato>   bzr bind sftp://bazaar.launchpad.net/~dennda/memaker/motor
<dato> dennda: and commit again
<dennda> takes looong
<dennda> ok, works. thank you
<dato> you're welcome
<dennda> :)
<ubotu> New bug: #175337 in bzr "bzr bind should not check for divergence" [Medium,Triaged] https://launchpad.net/bugs/175337
<sabdfl> hi folks
<sabdfl> are there deb's for 1.0rcx?
<jam> sabdfl: I see debs for 1.0rc1 available in http://bazaar-vcs.org/releases/debs/gutsy/
<jam> I don't see 1.0rc2 yet
<dato> hardy also has them, via sid
<jam> dato: What about for debian itself?
<dato> and sid has rc2
<dato> (but hardy does not have rc2 yet)
<dato> jam: ^
<jam> dato: well, I also don't see a "hardy" in http://bazaar-vcs.org/releases/debs/
<dato> jam: I mean proper hardy, as in packages.ubuntu.com
<jam> we should probably update that, unless we are just using 'sid' for that.
<jam> ah
<fbond> Hey, is this a known issue?  I removed a file, and now bzr diff halts with "no such file or directory"
<fbond> === removed file 'debian/dirs'
<fbond> bzr: ERROR: No such file: u'/home/fab/work/debs/pytagsfs/pytagsfs/debian/dirs'
<fbond> This is new behavior, from what I can tell, on 1.0.0 rc1, using dirstate-tags.
<jam> fbond: I don't see that here, did you use "bzr rm debian/dirs" or just plain "rm debian/dirs" ?
<fbond> Just "rm debian/dirs"
<jam> I see "=== removed file 'generate_docs.py'"
<fbond> That used to work.  Does it no longer?
<jam> and then a patch
<jam> with everything in the "removed" field
<jam> fbond: if you can reproduce it, I'll try to debug
<jam> but my simple test here just works
<fbond> It is happening consistently for me.
<jam> fbond: can you reproduce it in a test script?
<jam> or alternatively, is the stuff something that you could tar up and send to me?
<fbond> Probably.
<fbond> Well, it's actually on LP, anyway.
<jam> hmm... I think I reproduced it with 1.0rc1
<jam> it doesn't reproduce in bzr.dev
<fbond> Yeah, I'd never seen it before.
<fbond> I actually blamed it on bzr-builddeb.
<jam> I think I remember Aaron doing something with .kind() for diff
<jam> let me see if it is in 1.0rc2
<fbond> Okay.
<jam> fbond: bzr.dev revno 3088: Diff handles missing files correctly, with no tracebacks
<jam> I'm getting 1.0rc2 now to see if it has that fix
<jam> fbond: it does
<jam> So it looks to be fixed for 1.0rc23
<jam> So it looks to be fixed for 1.0rc2
<fbond> jam: Okay, so I just need to upgrade.
<fbond> Which brings us back to ...
<fbond> .debs for rc2 !
<fbond> :)
<jam> lifeless was the one making .debs, but I know he is on vacation for the rest of the month, I'm not sure, but I think poolie was going to take over
<jam> I'll ask him when he comes online later tonight
<jam> In the mean-time you probably can "bzr rm filename" and have it stop failing
<fbond> Wow, nice vacation.  Okay, no big deal.
<fbond> jam: Thanks!
<jam> Yeah, lifeless tends to not take any vacation during the whole year
<jam> we always take the last week off anyway, so it is just 2-weeks just before the last week off
<fbond> Gotcha.
<fbond> No need to justify to me.  If he can swing it, good for him!
<fbond> With PPA in place now, you guys should think about just building on LP.
<fbond> It's really nice.
<fbond> Using bzr-builddeb, upgrading to a new upstream version is little more than a 30 second operation.
<fbond> But I guess I'll stop evangelizing :)
<hexmode> does anyone have an easy-to-follow pqm setup manual?
<hexmode> I'd like to use it but it looks like I'd need to learn a lot before I attack it.
<ubotu> New bug: #175373 in bzr "Cannot merge -r 0..-1 in an empty branch" [Undecided,New] https://launchpad.net/bugs/175373
<ubotu> New bug: #175390 in bzr "SSL Client Cert support in the auth ring" [Undecided,New] https://launchpad.net/bugs/175390
<poolie> jam, statik, hi
<poolie> yes, i was going to make debs
<statik> poolie: hi!
<poolie> shall we talk
<statik> talking would be fabluous
<poolie> wait for jam?
<statik> poolie: sure thing, I'll be around for a bit
<poolie> statik, i'll ping him
<jam> hi
<igc> morning
<abentley> Hey gang.
<phanatic> morning guys
<jam> morning igc
<thumper> morning people
<abentley> thumper: morning.
<spiv> jam: when do you want to talk about the set memory consumption strangeness?
<jam> spiv: would it be fine after a couple hours?
<jam> (I assume you are just starting your day)
<jam> basically, the sets are consuming more memory than I thought they would
<spiv> jam: sure, a couple of hours is fine
<jam> k
 * jam => family time
<mwhudson> jam: it seems https://code.edge.launchpad.net/~jameinel/bzr/extra-range-collapse-165061 mirrored at long last
#bzr 2007-12-11
<jdstrand> is there a bzr 1.0 backport for gutsy available?  (I tried myself, but it doesn't seem to be working right)
<spiv> jdstrand: http://bazaar-vcs.org/DistroDownloads
<jdstrand> I just ran dpkg-buildpackage on bzr 1.0~rc2-2, but am getting errors against a 1.0.0.candidate.1 tree
<jdstrand> spiv: thanks!
<abentley> jam: I was going to review your Graph.heads optimization, but things seem to be a bit messy-- e.g. it adds preload_parents, which your "Fixes for find_differences()" then takes away.
<igc> hi abentley
<abentley> igc: Hi.
<igc> abentley: re pkg_resources, is it easy to include in our code?
<igc> seems to be part of setuptools
<abentley> Yes, it is part of setuptools.
<igc> and the pep adding it to python is a future thing I gather
<igc> s/is/in/
<abentley> Yes.
<igc> it looks the right idea ...
<abentley> Considering we want bazaar to be installable as an egg, using setuptools doesn't seem too crazy.
<igc> I'm just not overly comfortable making setuptools a dependency just the sake of this
<abentley> Well, it may make more sense to reinvent the wheel.
<abentley> But I thought it was worth discussing at least.
<igc> I'm pleased you mentioned it
<igc> I wasn't aware of it
<abentley> I have no idea how hard or easy it would be to include by itself.
<igc> I can't find anything along those lines after a brief search
<igc> it probably isn't a big deal ...
<igc> but it feels a little like a huge hammer to smash a small nut in this case (to me at least)
<igc> I just want to load doc from files and not python strings :-)
<abentley> What it does give you is location-independence for resources.
<igc> I was happy with leaving the docs where they were but it doesn't work with the Windows installer apparently
<abentley> If your file is in a zip, getting a python string is better than getting a faile.
<abentley> s/faile/file
<igc> true
<abentley> pkg_resources is 82k, 2.5k lines.
<abentley> So it would be a lot to manage ourselves.
<abentley> What we could do is strive for api compatibility.
<abentley> Or we could just solve it a simpler way for this case.
<igc> Hmm
<igc> I would like to get ref material out of the UG for 1.0 so ...
<igc> how about I raise an issue about making an api ...
<igc> that is compatible with pkg_resources
<abentley> Sounds good to me.
<igc> for 1.0, I'll make the files py ones with big strings in them
<igc> so things don't break in zip files
<abentley> Eh?
<igc> well ...
<abentley> you can just have an API that returns the contents of a file as a string.
<igc> your point about loading from files will break
<igc> ok
<abentley> pkg_resources can give you filenames if you must have them, but this will mean extracting the files from the zip first.
<abentley> So IIRC, it's encouraged to retrieve file-like objects or strings.
<igc> I don't need filenames really
<igc> help_topics._load_from_file() currently takes a topic and returns a string
<igc> that's all I care about at the high level
<igc> internally, I get that content via deriving a filename but ...
<abentley> Right.  So the resource API should return strings or file-like objects, rather than paths.  That's all I meant about zips.
<igc> I could derive a string in py module instead say
<abentley> You mean stuffing our existing text into py files?
<abentley> Doesn't that defeat the purpose of keeping them in doc/en?
<igc> doc/en is no good for alex
<igc> my orginal patch had them there and he wanted them moved
<igc> the windows installer doesn't package doc/*, just the generated files I believe
<abentley> I don't think that's a good tradeoff.
<igc> ok ...
<igc> so if we leave the files in doc/en ...
<abentley> I don't know enough about the windows installer.
<igc> and mark them as User Reference only topics ...
<igc> then the runtime system doesn't need to find them
<abentley> But it must have a way of accessing resources.
<igc> and alex's problem goes away
<abentley> Probably pkg_resources, in fact.
<igc> actually, only generate.doc.py needs them -to build bzr_man.txt during make
<poolie> igc, interesting mail about including batteries on windows
<poolie> is it really unavoidable that there are two somewhat incompatible windows environments?
<poolie> that kinda suck
<poolie> s
<igc> poolie: yeah - we have some work to do I think
<igc> I saw a complaint yesterday re hg
<igc> the grumble was that it bundled a dozen plugins but people had to turn them on :-(
<igc> in comparison, git has bisect etc enabled by default
<igc> so, in other words ...
<igc> git was deemed low admin because it just worked out of the box
<igc> we shouldn't try to satisfy everyone but ...
<igc> I'm beginning to think we ought to at least be bundling more, perhaps via meta-packages
<igc> disk space is cheap :-)
<igc> it's bandwidth in downloading the stuff that I think people get concerned about
<poolie> i think we should too
<poolie> even then, that's pretty small
<poolie> except perhaps for dependent libraries like qt
<poolie> maybe we could offer a "standard" and "minimal" install
<igc> yes
<fullermd> Compile time and general system dirtiness are concerns too.
<poolie> how do you mean?
<igc> particularly on Windows and OS X
<fullermd> qt, to take your example, takes AGES to build.  Longer than Firefox even, last I looked.
<poolie> oh, on BSD or Gentoo?
<poolie> ("you build qt?" :-)
<poolie> i wouldn't expect most people would build it from source
<fullermd> Well, I don't, no.  And I don't want to start because of some third-level dependancy of a package for a VCS I'm going to use the CLI of  ;)
<poolie> not to neglect those who do have to, but it's probably a minority cas
<poolie> e
<poolie> but you wouldn't install a binary of it?
<igc> fullermd: I'm good with qbzr, bzr-gtk and bzr-svn being separate installers
<fullermd> Well, no.  But even if so, that falls into the 'system cleanliness' side; I don't like installing extra stuff I'm not going to use, particularly big bunches of extra stuff.
<fullermd> I mean, just installing bzrtools needs graphviz.
<abentley> So I'm looking at py2exe, and there are recipes for including data files.
<igc> it's more about what we bundle as "standard" plugins to match the expectations of functionality people have
<fullermd> And that pulls in half of X.
<abentley> http://www.py2exe.org/index.cgi/AddingConfigFiles
<igc> abentley: I'll take a look
<abentley> So I really think this is not a tool limitation.
<ndim> Hmm. If I get bzr.dev using rsync, the first thing I receive is bzr.dev/.bzr.backup/?
<abentley> fullermd: graphviz is supposted to be optional.  Please smack anyone who makes it mandatory.
<fullermd> abentley: I maintain the port; what sort of masochist do you take me for?   ;)
<fullermd> I could OPTIONS-ify it I s'pose.
<abentley> hehe
<abentley> I think Bazaar is the only hard dependency of bzrtools.
<abentley> The rest are used by one command or another.
<fullermd> The deps in the port are currently bzr, rsync, and dot.  I think I'd just leave rsync; it's not too big, and it's self-contained.
<abentley> So you're not supporting baz-import?
<fullermd> Well, I haven't really done much with the port except update the versions; lulf created it originally.
<abentley> Ah.
<fullermd> I just inherited it and bzr from him.
<abentley> Do I know lulf?
<fullermd> Ulf Lilleengen.
<fullermd> Think he's still listed as maintainer of the baz port.  There's a relaxing job   ;)
<abentley> Lol.
<ndim> Is there a good reason for bzr.dev to contain both .bzr and .bzr.backup?
<ndim> Uhm. Make that "Is it on purpose that bzr.dev contains both .bzr and .bzr.backup?"
<abentley> Sounds like an accident to me, but not a harmful one.
<ndim> It just doubles the download volume.
<ndim> :)
<poolie> ndim, downloaded using what method?
<poolie> rsync?
<poolie> igc, i'd like to talk more about batteries-included, but we should do the release first
<igc> poolie: it's a 1.1 thing IMO
<poolie> igc, on the movement into the user reference
<ndim> poolie: rsync, yes. my local bzr is a little too old.
<poolie> (which i know is a different topic)
<poolie> ndim, i'll move the backup
<poolie> hm, i can't move it myself
<poolie> igc, i share jam's view about the desirability of keeping docs in text files rather than inside py files
<poolie> if possible
<igc> poolie: I'd prefer that too
<abentley> poolie: Have you considered how to un-merge using annotations?
<abentley> i.e. given revisions x and y, where y is descended from x, remove all the changes introduced by x?
<poolie> abentley, i have not, but it's an interesting idea
<abentley> I've been thinking about it as an approach to reverse-cherrypicking, but it seems complicated.
<abentley> reverse-cherrypicking is about the only thing that merge3 can do that annotate cannot.
<jam> spiv: ping
<spiv> jam: pong
<jam> spiv:  do you know what the per-node overhead is for a set() ?
<spiv> jam: very similar to a dict
<jam> which is?
<spiv> jam: standard PyObject overhead (the PyObject_HEAD fields) plus a couple more fields, plus a "smalltable"
<spiv> jam: depending on the number of entries in the set, it'll put all the entries in the PySetObject if they are under a certain threshold
<spiv> jam: otherwise it'll malloc separate space for the set items.
<jam> well, I'm doing a set() of the ancestry of nodes in bzr.dev
<jam> so I have 7.3k sets
<spiv> (the threshold seems to be 8)
<jam> and 63M nodes inside those sets
<spiv> (gdb) p sizeof(PySetObject)
<spiv> $1 = 100
<jam> I'm seeing 29 bytes per entry in the set
<jam> well, lets try it a different wy
<jam> way
<spiv> So is just holding the sets in memory the problem, or is it when you try to do an operation on the sets?
<jam> 7.3k * 100 = 730KB
<jam> Well, I just loaded them, and it takes 1.8GB of Ram
<jam> so the PySetObject overhead doesn't seem to be the expense
<jam> But the 28 bytes per entry *in* the set is
<jam> spiv: shouldn't it be something like 10 bytes per node? Something to give you a pointer to the real PyObject
<spiv> What are the objects?  Strings?
<jam> or am I triggering something funny in the "smalltable" code
<jam> spiv: yes
<jam> but they are bzr.dev revision ids
<jam> so ~60 bytes each
<jam> 15k total
<spiv> The "smalltable" code is basically just "if len(set) < 8: store in the struct directly for cache coherence/memory fragmentation goodness"
<jam> hmm... maybe that is 900MB, seems a bit big
<jam> ah, 900 KB
<jam> that makes more sense
<spiv> Also, (gdb) p sizeof(PyStringObject)
<spiv> $5 = 24
<jam> spiv: sure, but aren't the PyStringObjects re-used?
<jam> If I have 1 set with 15000 entries
<jam> set1 = set(...15kentries...)
<jam> set2 = set()
<jam> set2.update(set)
<jam> set2.add('a')
<spiv> jam: they might be reused, depending on how you construct them.
<spiv> jam: there's an easy way to find out
<spiv> jam: do a set(id(x) for x in ...) :)
<spiv> But if you're building new sets by "set2.update(set1)" like in your example there, then it'd just reference already existing objects, yeah.
<jam> spiv: If I do you set(id(x) ...) and then do a set difference
<jam> I get the same number of nodes
<jam> as just doing a direct set difference
<spiv> So "len(my_set)" should always be the same as "len(set(id(x) for x in my_set)))" (assuming the __eq__ of the setitems behave normally).
<jam> spiv: so doing: all = set()
<jam> for rev, nodes in self.ancestries.iteritems(): all.add(id(rev)); all.update(id(r) for r in nodes)
<spiv> But what's more interesting is "ids = set(id(x) for x in my_set); ids.update(id(x) for x in my_set2); len(ids)"
<jam> (build up a set of the id of every piece I can find)
<jam> (Pdb) len(all)
<jam> 15499
<jam> So all of the revision id strings seem to be properly shared
<spiv> Ok.
<spiv> Next question: are you sure it's these sets that are the problem?
<jam> spiv: well, I can say that it is during creation of these sets that my memory bloats
<jam> spiv: the code is here: http://bzr.arbash-meinel.com/plugins/test_graph/
<spiv> Because it sounds to me like 15k strings of ~60 bytes + 7.3k sets isn't adding up...
<spiv> jam: http://www.twistedmatrix.com/users/spiv/countrefs.py
<jam> spiv: I completely agree, that is why I'm confused
<spiv> jam: use that or something like it to get a count of the number of instances of various types.
<jam> (Pdb) countrefs.mostRefs(10)
<jam> [(152841, <type 'tuple'>), (8158, <type 'function'>), (7411, <type 'set'>), (3030, <type 'dict'>), (1499, <type 'list'>), (1156, <type 'weakref'>), (985, <type 'type'>), (779, <type 'builtin_function_or_method'>), (625, <type 'wrapper_descriptor'>), (566, <type 'getset_descriptor'>)]
<jam> 152k tuples is a bit
<jam> but still not 1.8GB worth of data, IMO
<spiv> Well, it depends on how big the tuples are...
<spiv> You can find out :)
<spiv> all_tuples = [t for t in gc.get_objects() if type(t) is tuple]
<spiv> Then you can try e.g. max(len(t) for t in all_tuples)
<spiv> Pity there's no "histogram" builtin ;)
<jam> spiv: sum(len(obj) for obj in gc.get_objects() if type(obj) == tuple)
<jam> 379583
<jam> with 152k tuples
<jam> that puts most of them at 2
<spiv> You can get the median with print sorted(all_tuples, key=len)[len(all_tuples)//2] ;)
<spiv> Hmm, so no smoking gun there either.
<spiv> It's possible the leak is in a type not tracked by gc (not a "heaptype" or whatever the jargon is).
<jam> print sorted(all_tuples, key=len)[len(all_tuples)//2]
<jam> (None, False)
<jam> weird
<spiv> Oh, that printed the median tuple, rather than the length of the median tuple.  Heh.
<spiv> Still, that supports your "most of them are len 2" calculation :)
<jam> but it is still 2
<spiv> Ok, so the space isn't consumed by the sets, the strings, or the tuples.
<jam> 1500 lists, of total length 10k
<jam> again, not super long
<jam> spiv: can you try the code and see if you get the same effect?
<jam> (it is a bzr plugin, put it in ~/.bazaar/plugins and just run: "bzr test-graph bzr.dev")
<spiv> So, at this point I'd try running without the optional C extensions (in case there's a leak there), and without plugins (in case e.g. the svn plugin is getting involved and thus getting its known memory leaks involved).
<spiv> Ok, will do.
<jam> Well, I can do that, but the code is generally really simple
<spiv> jam: I don't think I want to run that command :)
<jam> why?
<spiv> jam: I only have 1G of RAM on this laptop :)
<jam> don't want to use the ram?
<jam> spiv: you could try it on something smaller
<spiv> I will :)
<jam> bzrtools works for me
<jam> but doesn't bloat nearly as much
<jam> spiv: on my machine I have definitely tracked it down to the get_ancestry_for_interesting()
<jam> before the loop I'm at 25MB (with the revision graph loaded)
<jam> after the function, I'm at 1.8GB
<jam> spiv: also, python spends a long time during close, I assume doing garbage cleanup
<abentley> Strange.  I just "fixed" the BB performance issues by rebooting.
<abentley> It was at 45% IO wait with nothing running.
<Talden> How do you handle shared code in projects? We have a CVS project where some source is shared between us and another organisation.
<jam> spiv: it seems that sets simply wrap a dict in python2.4...
<jam> *     data is a dictionary whose values are all True.
<spiv> jam: oh, I was assuming you were using 2.5
<abentley> Talden: Generally, you package the shared code separately.
<spiv> jam: which has a dedicated set type (based on the dict type's code, but a little leaner)
<jam> spiv: I am, I just have the 2.4 code available :)
<abentley> Talden: libraries lend themselves to this treatment especially well.
<jam> spiv: downloading the 2.5 source now
<Talden> abentley: We both contribute to the shared components code.  Many of our developers would simply end up having to handle two separate projects and shipping code into the dependent project (with a general understanding that it's not maintained there).
<Talden> This is acheived in CVS with a little backend hackery to mount the shared code in an appropriate path in the CVS backend.
<spiv> jam: I have a bzr-svn import of python trunk and the py3k branch on my laptop :)
<jam> spiv: oooh
<jam> it won't matter for this code
<jam> as it only focuses on merge nodes
<Talden> I am NOT promoting backend hackery and am fully aware that this isn't going to fly in DVCS land.
<abentley> Talden: okay, I don't understand your requirements yet.
<Talden> (1) Neither org can see the others non-shared code.
<Talden> (2) We both contribute to the code on HEAD and frequently make contributions on our own branches that make their way to HEAD via merges.
<Talden> (3) History of shared content is visible to all (to help make sense of changes originating from two orgs with very different core-business).
<abentley> Why would having a separate tree lead to stuff not being maintained?
<Talden> abentley: Maybe I've misunderstood your suggestion
<jam> spiv: so if I'm looking at it correctly, the overhead of a set entry should be just 8 bytes, right?
<jam> a 'long' for the hash, and a PyObject* for the key
<abentley> So for the shared code, I'm suggesting that should be one branch, and your non-shared code should be another branch.
<Talden> Branches or separate ancestry?
<abentley> Totally separate ancestry.
<Talden> Right... so a developer can't 'mount' the shared code inside the path of their branch of main code right? Or does bzr know to handle nested branches somehow?
<spiv> jam: that sounds right to me
<jam> so still, something weird is happening
<jam> 63M keys *8bytes is only 500 MB
<jam> A lot, but I'm seeing almost 4x that
<spiv> It's possibly just python's memory management.
<spiv> Creating/resizing lots of sets might be leading to memory fragmentation.
<abentley> Talden: There has been work on that, but it's not complete.
<abentley> There are packages that let you set up a nested tree, but don't keep things up-to-date.
<jam> spiv: well, doing "set1.copy().update(set2)" doesn't seem to improve things
<abentley> Talden: if by "mount", you just mean sticking one tree inside the other, that's easy.
 * igc lunch - bbl
<jam> and that hits on 5.6k of 7.3k nodes
<jam> I guess it is actually "s = set1.copy(); s.update(set2); s.add(r)"
<jam> but I guess that involves 2 resizes, and I don't know what sort of internal grow algorithms are used
<jam> spiv: I think you are right about the malloc() issues
<jam> If I change the calls to do:
<spiv> jam: so, one interesting point is that sets' internal tables are larger than the number of entries, btw.
<jam> ancestries[revision_id] = ancestry.copy()
<jam> Then it drops to 1.4G
<jam> from 1.8G
<jam> spiv: all of the "dummy" nodes?
<spiv> jam: they can be twice to four times larger than the number of entries after a resize, I think; obviously you want some sparseness to avoid too many hash collisions, and provide space for new entries, etc.
<spiv> (maybe frozensets are more compact?)
<jam> spiv: they seem to always be powers of 2
<jam> newsize <<= 1
<jam> mask = newsize - 1;
<jam> So probably when we trip past 8k revisions
<jam> it jumps to 16k for each revision
<jam> and once we get past 16k (in a few revisions) it will jump to 32k
<spiv> jam: well, see also "set_table_resize(so, so->used>50000 ? so->used*2 : so->used*4);" that e.g. set_add_key does.
<jam> so grow by 4x if < 50k nodes
<jam> oh, actually have the hash be 1/4 full if < 50k used nodes
<jam> and 2k full otherwise
<jam> so with 8k nodes, we have 32k tables
<jam> and above that it goes to 64k tables
<jam> and 4:1 is about what I'm seeing
<jam> 8 bytes per node, but an average overhead of 3 blank nodes per real node
<spiv> jam: what about "ancestries[revision_id] = frozenset(ancestry)"?  I don't think it's any more compact than set.copy, but maybe...
<jam> spiv: just finished that one
<jam> still 1.3G
<jam> so the same as .copy()
<jam> but better than not doing it (1.8G)
<jam> spiv: thanks for helping me track this down
<spiv> jam: you're welcome.
<spiv> jam: I'll get back to other stuff now I think
<jam> sorry for distracting you for so long
<spiv> jam: It's been fun poking at this stuff
<spiv> Even if it is hard to get good answers about python memory consumption!
<jam> spiv: yeah, I wish part of the PyObject protocol was to have a "mem_size" variable
<jam> or function for objects
<jam> so you could loop and figure out what was consuming your ram
<spiv> I think a "mem_size" method would be helpful, but also deceptive.
<spiv> A bit like how looking at the memory stats for processes in "top" is deceptive.
<spiv> Because accounting shared memory is hard, if three processes share the same pages, should you say that each process "costs" 1/3 of that memory?  That's often a bit too simplistic an analysis.
<spiv> jam: so one idea for you: http://rafb.net/p/SRFLNW38.html
<spiv> jam: trading memory for time, basically
<lifeless> jam: 'area'.
<Talden> abentley: Thanks for the feedback... I went and looked into the support for nested branches and there doesn't look like much there yet.  It looks like some developer handholding will be needed for us to maintain similar code-sharing workflow to what we have now.  I guess I'll soon see how much impact this might have on my chances of moving us to bzr.
<spiv> jam: (what's this plugin checking, anyway?)
<lifeless> i386: back in syd ?
<i386> lifeless: yep
<i386> Got back this morning
<i386> Feeling pretty good for jetlag
<lifeless> cool
<i386> etc
<i386> hows things?
<lifeless> good
<lifeless> relaxing :)
<i386> Yeah me too
<i386> Im attempting to quit smoking
<i386> so im chewing this special gum
<i386_> lifeless: james unplugged the router :/
<lifeless> i386_: lol
<fullermd> See what happens when you quit smoking?  :p
<i386_> Yeah
<i386_> Actually this gum does the trick so far
<i386_> except I want to vomit
<lifeless> eek
<lifeless> when Lynne quit she just cold-turkeyed
<fullermd> I didn't exactly _quit_.  I just ran out, and haven't bothered to buy another pack in the last 7 years?  Something like that...
<fullermd> I have a friend who advocates a different system.  Don't fight it; every time you want a cigarette, just eat one.
<lifeless> rofl
<RichElswick> hi all
<lifeless> jam: I mailed poolies details to get the canonical commercial packaging folk to do it for my vacation
<RichElswick> when pushing a new branch up to a server in a new location, (via sftp) should the files transfer as well as the .bzr files?
<poolie> lifeless, hi
<poolie> RichElswick, no, only the .bzr directory is transferred over sftp atm
<RichElswick> so I would need to transfer the files as well?
<RichElswick> then others would be able to download the version controlled files?
<poolie> if others download from that directory, they'll get the whole lot
<poolie> igc, re your chapter 7
<poolie> it's good, but it seems a bit out of place in this manual
<RichElswick> ok, which is what I sort of figured.
<RichElswick> must be my ftp account setup then.
<poolie> what's going wrong?
<lifeless> hi poolie
<RichElswick> you can test it out if you have a sec...
<RichElswick> http://detroitcreativetalent.com/SSD/RandomGen/
<RichElswick> is the location I uploaded the files ot.
<RichElswick> to as a test.
<poolie> hm, the problem seems to be with your web server
<poolie> bzr info http://detroitcreativetalent.com/SSD/RandomGen/
<poolie> bzr: ERROR: Unknown branch format: '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
<poolie> ...
<poolie> it's redirecting to an error page or something
<poolie> lifeless, can you tell me what arch.ubuntu.com is still used for, if anything?
<RichElswick> ok, thanks
<lifeless> poolie: in jan if thats ok, I don't really want to page work in
<lifeless> or should I say, I really don't want to page work in
<poolie> yeah, totally fine
<poolie> i should have said that
<RichElswick> poolie: thanks for the help... looks like my upload via bzr push sftp... didn't work out as I thought it would, so I uploaded the .bzr directory manually and it works now, thanks!
<Peng> Hm, my repo for bzr has fifteen different packs.
<Peng> Haha, on my very next pull, it repacked down to three.
<lifeless> :)
<Peng> Why three? It's the old 58 MB one, plus a new 2 MB one and new 360 KB one.
<Peng> Does auto-packing do any optimization like "bzr pack" does/will?
<lifeless> no
<thumper> hi lifeless
<lifeless> autopack tries to minimise the amount of work it does
<lifeless> pack tries to perform global performance optimisations (well, if the patch I put up the day I went on leave has been merged :))
<lifeless> hi thumper
<Peng> lifeless: Ordering revision texts in topological order? That just went in.
<spiv> lifeless: yep, jam merged it I think.
<spiv> lifeless: (just bzr.dev, not 1.0)
<Peng> lifeless: Does it do enough that it could be worth running "bzr pack"? What about on a server where the repo is just used for push/pull?
<lifeless> Peng: if you have tens of thousands of revisions, it'll make log a bit faster
<lifeless> Peng: so autopack exists to prevent latency growing without bounds
<Peng> lifeless: Right.
<Peng> lifeless: Why did it create two small packs instead of one?
<lifeless> Peng: thats why 3 packs - it left your largest alone because it wouldn't make any substantial difference to latency to rewrite the big one; but it would take a lot more time to rewrite it.
<lifeless> (imagine you were pushing into a sftp repo; you don't want that to download and upload the entire repo on a autopack, because auto pack is quite common)
<Peng> lifeless: Yeah. I understand why it left the largest one, but why create two smaller ones instead of one?
<Peng> Hypothetical situation: In chronological order, I have 1 100 MB pack, 10 100 KB packs, 1 50 MB pack, and 10 more 100 KB packs. Is auto-pack smart enough to leave the 50 and 100 MB packs alone but repack the others?
<lifeless> Peng: there is a bug open
<lifeless> Peng: autopack is fairly smart. at the moment its a bit 'clever' too but that should go.
* Peng changed the topic of #bzr to: Bazaar Version Control System | http://bazaar-vcs.org/ | please test http://bazaar-vcs.org/releases/src/bzr-1.0rc3.tar.gz
<Peng> Hey, 174 KB/sec.
<Peng> Wait, that's still only 1400 Kbit/sec. That sucks.
<fullermd> You realize, of course, that the topic is a hot potato.  Having once touched it, you're now responsible for it forever more   :p
<Peng> Well.
<Peng> I'll just change my nick to lifeless_ and everyone will think he did it.
<Peng> WTF?
<Peng> If I try to push this branch over bzr+ssh, the local bzr freezes sucking 100% of the CPU forever.
<Peng> I just tried pushing over sftp, and it finished after 20 seconds. There is a *lot* of data to push.
<Peng> Even weirder is that it seems to be intact.
<Peng> Now, when I uncommitted and recommitted something, it's been pushing for a few minutes now with lots of network activity!
<Peng> Oh. Last time I tried to push when I gave it a few minutes, almost all of hte CPU time was sys.
<Peng> Maybe it wasn't frozen, or something.
<Peng> Pushing over SFTP now, it's not using much CPU, but it's using 250 MB of RAM..
<Peng> (Actually, it's using about zero CPU.)
<Peng> It's gaining maybe a MB of RAM a second.
 * Peng wanders off.
<dato> abentley: I barely understand the public_branch stuff for `bzr send`, but do you think it could make sense to use as public_branch the parent_branch of the submit_branch, maybe recursively, until it's not local?
<Peng> Okay, good, now it's not using so much RAM.
<Peng> dato: public_branch is simple: it's the public URL of the branch (http://bazaar-vcs.org/bzr/bzr.dev/ or whatever).
<dato> yes, that'd be included in the "barely"
<Peng> Heh.
<Peng> Right.
<Peng> Hello hello.
<Peng> Hello.
<Peng> So apparently it's uploading a very large pack.
<Peng> The progress bar is completely useless.
<Peng> It has 22 packs, so it might be repacking.
<Peng> Erk, this would work better over bzr+ssh.
<Peng> After this much has been uploaded, I'm not going to kill it and switch, though...
 * fullermd blinks.
<fullermd> What happened to the ability to 'log' historic files?
<fullermd> I could swear that worked at one time.
<Peng> Whee test coverage!
<Peng> Wow, now the uploaded pack is almost 100 MB. Now I think I'm glad I'm not using bzr+ssh..
<Peng> It probably would've gotten killed by now.
<Peng> Or is bzr+ssh good at RAM usage?
<fullermd> Would you expect it to use more than the sftp server-side?
<Peng> Yes.
<Peng> sftp-server is currently using 3 MB.
<Peng> I'd be shocked if I ever caught bzr using less than 15.
<fullermd> Well, yeah, the constant factor is higher.
<Peng> Yeah.
<fullermd> But writing the file shouldn't add much.
<Peng> And, of course, it has to actually calculate stuff.
<Peng> fullermd: Does it just write the file verbatim or process it?
<Peng> Oh my god.
<fullermd> TTBOMK, push just uses all vfs functionality still.
<Peng> It took it 55 minutes and a 120 MB upload for it to realize the branches had diverged.
<Peng> Wait.
<Peng> I don't know if it was 120 MB. I was misreading another old file in upload/ that's 12 MB.
<Peng> But it was definitely over 100 MB.
<Peng> Brilliant, bzr.
<Peng> Oh, good. It didn't delete it. It's in packs/.
<Peng> I guess it updates the repo, then tries to update the branch.
<Peng> It repacked the remote side down to 7 packs.
<Peng> From 22.
<Peng> It still left a couple small old ones.
<Peng> While combining a couple new huge ones.
<ubotu> New bug: #175520 in bzr "log can't see historic filenames" [Undecided,New] https://launchpad.net/bugs/175520
<ubotu> New bug: #175524 in bzr "http test server is not 1.1 compliant" [High,Confirmed] https://launchpad.net/bugs/175524
<zerok> hi :-)
<zerok> probably a really stupid slightly off topic question, but would i violate the gpl if i write a bsd-licensed application that imports the bzrlib?
<luks> I can't speak for bzrlib specifically, but generally importing gpl code into bsd code is against the gpl
<zerok> also importing in the sense of just having somewhere in your code "import otherlib"?
<luks> that is no different than dynamic linking in c applications
<zerok> :-( i guess this means i can dump 20% of my application and remove scm altogether with bzr and hg being under gpl v2 :-( thanks for the info :)
<Peng> Just out of curiosity, what's your application?
<zerok> Peng, it's a simple docutils wrapper that combines docutils with stuff like the jinja template engine and pygments and also simply allows to process multiple documents at a time (and also generates a index for those documents). and to get the mtime of a document i wanted to use the last mtime as seen from a scm
<luks> you can write a gpl plugin for bzrlib and run bzr in a separate process :)
<zerok> which would defeat the purpose for wrting that tool in python in the first place ;-)
<Peng> You could do something sucky like running 'python -c "import bzrlib; ..." in a separate process.
<zerok> true, but i guess i will just remove that code :-( would have been a neat feature though ;)
<zerok> cd
<zerok> wrong window ^_^
<luks> I don't suppose canonical would sue you for importing bzrlib, though :)
<zerok> luks, :) i still prefer to be on the safe side :) so perhaps i will just write some kind of plugin infrastructure for that code and post a plugin thta does what i want on my homepage as "example" :P
<luks> :)
<luks> that's how gstreamer does it
<zerok> so far only mercurial is affected anyway ^_^
<zerok> http://codebrowse.launchpad.net/~zerok/rstsuite/main/annotate/zerok%40zerokspot.com-20071211113206-rnyh73s36xuw7dxr?file_id=__init__.py-20071027132757-ow0jgpc6iiwc1buy-2 ^_^
<abentley> dato: That would be a wild guess.  I don't think it's unreasonable to ask people to set public branches for their local mirrors.
<abentley> dato: The other thing you can do is just not use a local mirror for "send": bzr send http://bazaar-vcs.org/bzr/bzr.1.0/
<Peng> That would waste some bandwidth though, right?
<kwwii> hi all
<kwwii> anyone know who made these t-shirts: http://sinecera.de/DSC03480.JPG ???
<jam> canonical brought them to pycon last year, but I don't know what company they used
<mwhudson> we should get some more of them...
<abentley> I would like one...
<zerok> same here :)
<jam> yeah, so would I
<jam> the funny thing is that none of the real developers got one
<zerok> lol
<jam> we were talking about possibly slogans at the last all-hands meeting
<jam> So a new one may be on the way
 * mwhudson dances a smug little dance
<kwwii> jam, mwhudson: hehehe, canonical is trying to figure who made them so that we can make more :-)
<jam> I thought I recognized your name, but /whois didn't show me anything interesting
<kwwii> ;-)
<kwwii> btw, I am making an eps version of the bzr logo for the new advertising agency
<kwwii> so if anyone knows the pantone colors for the logo, let me know :-)
<mwhudson> oh, duh
<jelmer> zerok: you could provide a plugin that adds bzr or hg support
<jelmer> zerok: and distribute that separately
<zerok> jelmer, yes, will do that the moment i have a idea how to handle plugins in my little tool :)
<jelmer> ah, k :-)
<zerok> jelmer, it just feels like such an overkill for such a simple tool ;)
<zerok> but eventually i will end up doing it anyway since i want to extend rst in the same way
<ndim> kwwii: I like that T-Shirt. Can I get one with "bazaar/git/everything-but-SVN-or-CVS" written on it?
<ndim> :)
<kwwii> ndim: hehe, if you point me to the person with the original artwork, I could try :p
<jam> spiv: Just to reply to your comment, the code is just stress testing our graph ancestry code, to make sure that I'm giving correct answers before we finally approve it.
<jam> spiv: So basically I find all of the merge nodes in an ancestry (such as bzr.dev), and then test that find_difference() gives the same results as set operations, and that heads() gives reasonable results.
<sabdfl> whats the syntax for bzr commit --fixes with multiple lp bug numbers?
<LarstiQ> sabdfl: iirc, --fixes lp:# --fixes lp:# --fixes lp:#
<sabdfl> thanks LarstiQ
<sabdfl> is there a command to show the properties on a revision?
<mwhudson> sabdfl: i've resorted to python2.4 -c 'from bzrlib import branch; b=branch.Branch.open("."); print b.revno(), b.repository.get_revision(b.last_revision()).properties' in the past
<LarstiQ> sabdfl: cat-revision may also do it, but perhaps not in a format that you prefer
<Peng> Apparently when git packs, it can store deltas between any revision, not just related ones. Interesting, no?
<dato> abentley: ok, thanks. I've set up public_branch now.
<ubotu> New bug: #175569 in bzr "cat-revision gives backtrace when invalid revid is specified" [Undecided,New] https://launchpad.net/bugs/175569
<jam> Peng: yes, that is something we are looking at. It can also store deltas between arbitrary file texts
<jam> Using a heuristic to determine that these file texts should be similar to those
<luks> wouldn't that make extraction slower? (since you usually need those left-hand parent texts together)
<jam> Peng: IIRC it uses the basename of the file to find similar names
<jam> which works well for the Kernel
<jam> because they have lots of Makefile and other repeated files
<ubotu> New bug: #175570 in bzr "bzr cat over bzr protocol fails" [Undecided,New] https://launchpad.net/bugs/175570
<jam> a quick search through bzrlib shows 2 Makefiles (not very similar)
<jam> and a bunch of __init__.py files
<jam> which might compress well because of common Copyright headers
<jam> and no other repeated filenames
<jam> luks: It uses some other heuristics, too
<jam> Specifically, it also sorts by text size
<jam> and tends to put the largest text as a fulltext
<jam> which is often the most recent
<jam> (because people usually *add* and rarely remove)
<jam> luks: anyway, I found a few sub-optimal cases for git's algorithm
<jam> at least, if I was implementing it the way they did
<jam> going by ancestry did a *lot* better than going purely by file size
<jam> especially for merge nodes
<jam> since merge nodes tend to have a diff to one parent of the sum of changes on the other side
<jam> anyway, the #1 thing we want to get is arbitrary compression parents
<luks> but that's also size vs. extraction speed, IMO
<jam> so that we can experiment and find out what works best
<luks> because using the right parent would give you smaller diffs, but for extraction is better if texts have the same base, no?
<ubotu> New bug: #175572 in bzr "smart server emits traceback while get log via bzr protocol" [Undecided,New] https://launchpad.net/bugs/175572
<jam> luks: well, at the very least the fewest number of bytes to read to reconstruct all the texts you want
<jam> but some of that gets really hand-wavy
<jam> oh, I also found that for *generating* them, usually the base that makes the smallest diff
<jam> also makes for the *fastest* diff
<jam> luks: the other problem with using right parent is more when you use both parents
<jam> because then you have to extract 2 histories for the file
<jam> rather than just along one direction
<luks> but you rarely do that, especially in bzr
<jam> luks: compare against the non-left parent? Probably true
<luks> yep
<jam> but "build_tree" performance is probably a bigger deal than "diff"
<jam> since you usually only diff a small number of files
<jam> build_tree touches every file
<luks> hmm, actually even if you use non-left parent you usually get the same base, because not many branches have over 100 commits before they get merged (or whatever is the max delta chain constant)
<ubotu> New bug: #175589 in bzr "suggested update when bound branch is out of date does confusing things" [Undecided,New] https://launchpad.net/bugs/175589
<Qhestion> does bazaar run under jython?
<beuno> Qhestion, I'm pretty sure it doesn't
<Qhestion> any reason for that?
<Qhestion> i mean, i would like to build something on bazaar, and i am pretty sure i will use java
<beuno> Qhestion, I don't know the specifics, Verterok does, but he usually isn't here at this hour. I think it has something to do with the OS calls, but I might be wrong. It's the lack of Jython's support for some features
<jam> Qhestion: jython was stuck in python <=2.3 ?? and we require 2.4
<Qhestion> dammit
<jam> I thought Verterok mentioned that jython would be updating to 2.5 compatibility
<jam> Real Soon Now
<beuno> there you go, a much nicer explanation  :D
<Qhestion> one day bazaar will get me to switch to python...
<jam> As far as running the test-suite on jython
<jam> We use os.chdir() as part of the test-suite
<jam> to ensure that tests have sanitized directories to work in
<jam> (basic sandboxing of each test)
<jam> but AFAIK Java doesn't support chdir()
<beuno> Qhestion, Verterok does interact with bzr from Java (eclipse, specifically) using a plugin he wrote to output XML and parse it
<dato> jam: really? </java-ignorant>
<jam> dato: last I knew, it was part of the java security model
<jam> to sort of hide anything like cwd
<Qhestion> java-ignorant? what is so bad about java?
<jam> I *do* know that jython with python2.3 does not implement os.chdir()
<dato> Qhestion: I was stating that I don't know much myself about java intrinsics
<Qhestion> oh ok
<jam> Qhestion: I can also say that for commandline apps, java's startup overhead is pretty prohibitive
<jam> but for something like an IDE which stays up for a while
<jam> it isn't something you pay for every command
<jam> Anyway, I haven't tried bzrlib in jython for >1 year
<Qhestion> well, java needs only ONE startup
<Qhestion> anyway, this is the only negative thing i see about java...
<ubotu> New bug: #175594 in bzr "UnicodeDecodeError after commiting" [Undecided,New] https://launchpad.net/bugs/175594
<jam> Things could certainly have changed since then
<jam> Qhestion: if you are using a program which starts and stops a lot
<jam> does java leave the interpreter running in the background?
<Qhestion> thats not what i mean
<Qhestion> jam, its what windows does for you
<Qhestion> of course it needs startup
<Qhestion> but thats within 0.05 seconds
<Qhestion> the REALLY slow thing is applets, but thats not really java
<Qhestion> lets see. i just ran "ant" twice.
<beuno> the only Java apps I use take forever to start (eclipse, azureus and openoffice)
<Qhestion> 'ant' is the 'make' of java
<beuno> and openoffice rarely uses java
<jam> beuno: is OOo actually java?
<Qhestion> beuno, that has NOTHING todo with java
<Qhestion> NOTHING.
<beuno> jam, in some bits, yes
<Qhestion> ok results: first ant run (since computer restart): ca. 1 second
<Qhestion> second run: cant count that fast
<beuno> jam, if you disable java in OOo, you lack some features, but it starts up 12x faster
<jam> Qhestion: so there are 2 bits... you can keep the interpreter running, which means all java processes re-use the interpreter. AKA one crashes they all die
<Qhestion> no, jam, no
<jam> Qhestion: or you can spawn new ones and pay for it
<jam> Qhestion: it has to kill the interpreter
<jam> not just a simple exception
<Qhestion> jam, its what all programs do
<Qhestion> they get cached
<jam> anyway, I'm happy to hear that java got better, though
<Qhestion> ok another stupid thing of java: Swing
<Qhestion> the standard user interface
<Qhestion> it looks ugly, feels ugly, and is slow
<Qhestion> on any platform!
<beuno> Qhestion, I've heard the java > python migration is pretty painless...   :p
<Qhestion> anyway, dont want to start a language war here, especially since bazaar is written in python, which means i am on the wrong side...
<Qhestion> beuno, actually i use python pretty much
<Qhestion> for SMALL scripts
<Qhestion> (everything less 5kB)
<Qhestion> but i definitely love the features eclipse offers me - especially code completion
<beuno> ah, I tend to use bash in those scenarios
<dato> .oO(so if it grows more than 5kB, you rewrite in java? :-P)
<beuno> btw, what do you bzr guys use to code in python?  jam?
<Qhestion> since there is no code completion / intellisense stuff for pyhon anyway, i just use Vim
<jam> beuno: vim
<Qhestion> dato: head of planning? ;)
 * dato vim too.
<Qhestion> oh good.
<Qhestion> so, what about code completion?
<jam> ^P
<jam> ^X ^L
<Qhestion> cheater!
<Qhestion> errm in english please?
<jam>  Vim has code completion
<jam> using Ctrl+P
<beuno> Qhestion, ^ == control
<jam> for single word completion
<jam> and Ctrl+X Ctrl+L for whole-line completion
<Qhestion> beuno yes, realized that too late
<jam> A bit emacs-ish for my taste, but it generally works
<jam> I tried eclipse...
<jam> The problem is that it really didn't want to work on files that were not in an Eclipse project
<jam> which was okay, I can create on and add them
<Qhestion> oh not THAT sort of code completion
<jam> But then an Eclipse project was fixed
<Qhestion> i meant intelligent code completion
<jam> based on Absolute path
<jam> Rather than saying "the files underneath this directory"
<jam> which means that having 100 different branches of bzr.dev (which I do)
<jam> is out of the question
<Qhestion> like, showing what is in namespace xyz and showing api docs in a popup when selecting one item
<jam> I wasn't going to go through the Eclipse overhead every time I wanted to work on a feature branch
<jam> Qhestion: ctags -R .
<jam> And then in vim
<jam> ^]
<Qhestion> is that a command?
<Qhestion> i am just too new in vim...
<jam> Will follow the tags to the definition under the current position
<Qhestion> how do i enable that?
<jam> Qhestion: ctags is a program which reads code and builds up a "tags" file of where there definitions are located
<jam> I don't know if it is bundled into gvim for windows or not
<Qhestion> gvim?
<Qhestion> huh?
<Qhestion> ahh yes i remember
<jam> On Mac, I see a Tools/Build Tags file
<jam> in the menu
<Qhestion> "(18:03:01) jam: in the menu" --> for that you need a menu :/
<Qhestion> we are talking about vim right?
<beuno> Qhestion, gvim, it's a GUI for vim
<Qhestion> "(18:02:52) Qhestion: ahh yes i remember", but i dont use it...
<Qhestion> maybe i should
<beuno> Qhestion, in the end, it's whatever you're comfortable with I guess
 * dato idly wonders if he'll still use vim, or at least some modal editor, in 2030.
<beuno> although vim seems to win over people eventually
<Qhestion> its not that i dislike vim. its just... well, i am only half through the manual
<jam> Qhestion: if you go through the tutorial, it does a decent job of warming you up to it
<jam> Oh, the other eclipse issue... no proper vim integration for its editor :)
<jam> It had some sort of vim plugin
<jam> but the only good one was like $20
<jam> And the limited teaser they had was broken
<Qhestion> jam, there is eclipse-vim...
<jam> So I couldn't evaluate whether it would be worth anything
<Qhestion> not that i checked it...
<jam> Qhestion: I'm guessing that is the one I was looking at
<jam> I had similar issues with the W IDE
<Qhestion> on the other hand, there is something that integrates eclipse (headless, no gui, just lib) into vim (ui)
<jam> Wingware
<jam> It *had* a Vim mode, but it didn't support the best Vim command
<jam> '.'
<jam> (To redo the last action, which I use *all* the time)
<jam> And is, IMO, one of the strongest reasons to use vim
<Qhestion> just another question: how often do you use your browser (!) to look at apidocs?
<jam> One you get used to the idea of applying commands to a movement range
<jam> Qhestion: pretty much never
<Qhestion> ???!?!?!?
<dato> jam: now that you mention "."
<dato> jam: http://chistera.yi.org/~adeodato/blog/uuu, in case it can amuse you
<jam> Qhestion: I find jumping around source code just a ":e bzrlib/foo.py" away
<jam> dato: interesting
<jam> Yeah, ViM uses "uuu"
<jam> "U" is the confusing one for me :)
<jam> Qhestion: the other thing you have to watch out for with vim.... Getting the Capslock turned on
<jam> Suddenly your editor nukes itself
<Qhestion> hehe
<Qhestion> or missing the right key with the finger...
<jam> k == scroll one line down, K == lookup this function in the man pages
<Qhestion> and suddenly doing something dangerous...
<dato> just make CapsLock an additional control key
<dato> be done with it :)
<jam> j == scroll one line up, J == wrap the next line onto this one
<Qhestion> btw how can i use copy/paste with vim?
<jam> Qhestion: on the plus side ViM has "uuuu" when you really need it :)
<jam> Qhestion: y == "yank"
<jam> p == paste
<jam> P == paste before this location, p == paste after this location
<jam> Qhestion: the other thing you need to get used to, is that Vim has commands that take movement keys
<jam> so "yj" is copy from this to the line above
<jam> "yk" is yank from this to the line below
<jam> "yw" is yank from this word to the next
<dato> jam: backwards
<dato> (above/below)
<Qhestion> yes
<jam> dato: my fingers know the difference
<jam> my mind does not
<dato> hehe
<Qhestion> well, having played nethack a lot, same goes for me
<jam> Qhestion: when you get *used* to it. It is very intuitive and powerful
<Qhestion> although nethack was *before* vim for me
<jam> "yt)" copy all characters until you get to an end parenthesis
<jam> "c%" change all of the characters between the current parenthesis and its matching one
<Qhestion> hjkl is intuitive for me, second-class code completion isnt
<jam> I use "c%" a lot to change the arguments to a function
<dato> jam: "t" and "f" are teh awesome, yet many vim users do not know about them
<jam> Also, you can configure both bash and zsh to use "set -o vi"
<dato> ct" anyone?
<jam> and you get to edit your command line
<jam> dato: yep
<jam> Qhestion: also, readline supports vim mode
<Qhestion> the command i like most in vim DEFINITELY is
<Qhestion> "help!"
<jam> so you can put into ~/.inputrc:
<jam> set editing-mode vi
<jam> $if mode=vi
<jam>     set editing-mode vi
<jam>         set keymap vi
<jam> $endif
<dato> Qhestion: nice
<jam> And then in python
<jam> you get vim mode as well
<jam> (in interactive python shell)
<jam> as well as any other apps that use INPUTRC and readline
<jam> The only problem is it doesn't always support all of the 'c%' craziness
<jam> so once you've been spoiled by ViM, some of the Vi-like implementations fall a bit flat
<Qhestion> hmm if there is no .inputrc in my ~, shall i just create one?
<jam> Qhestion: yeah
<jam> You may also need to set the environment variable INPUTRC
<jam> export INPUTRC=~/.inputrc
<jam> works for me
<jam> (I put it in both ~/.bashrc, and ~/.zshrc)
<Qhestion> on windows! :/
<jam> Qhestion: I'm not sure there, you could set INPUTRC in environment variables
<Qhestion> i know windows is ugly. i just wait for kde 4 to be released and then switch back
<jam> I can't walk you through the specific dialogs
<Qhestion> to the home path or to the file?
<jam> Qhestion: file
<Qhestion> dialogs? there is SET for that ;)
<jam> Qhestion: but SET is only for the current command
<jam> cmd.exe
<jam> Setting it by dialogs sets it from there onward
<jam> Something like Right-click on My Computer, Settings, One page is Environment Variables and Virtual Memory settings
<jam> and you have to click a button to pop up another dialog
<jam> which lets you set All-user env vars
<jam> as well as just env vars for your user
<Qhestion> jam: for current console session, you mean. anyway, i want to test it first
<Qhestion> so now that i have that command
<Qhestion> erm file i meant
<Qhestion> how do i trigger the auto completion?
<jam> Qhestion: for what program?
<Qhestion> vim :)
<jam> Vim has completion inside it
<Qhestion> i made that .inputrc file
<Qhestion> which you told me to make
<Qhestion> now what do i do now?
<jam> AFAIK windows cmd.exe doesn't handle vim-style completion
<jam> you need to be running bash or zsh
<jam> Qhestion: if you are just running vim
<jam> then it should already have it
<Qhestion> yes, but what is the key for it?
<jam> To complete a word? ^p for "previous existing" and "^n" for next
<jam> so you type something like "get_fo^p^p^p" until it completes like you want it to
<Qhestion> if i try for example "raw_in^p" it says not found
<Qhestion> although THIS sort of autocompletion is what i want
<jam> Qhestion: I don't believe Vim has Intellisense yet, though I think it is high in priority
<jam> It has "matching string" completion
<Qhestion> same goes for "os.^p", which i would LIKE to display every thing in os
<jam> so if you have a file open with "raw_input" then it will find it
<jam> Qhestion: vim doesn't do that
<jam> (I haven't really needed it)
<Qhestion> yet? so vim is young? :/
<jam> It is hard to do that for python, because it is a bit dynamic, so systems which try are at best approximating
<dato> jam: I think vim 7 got something, omnicompletion I think they call it
<dato> :help new-omni-completion
<dato> (never tried it)
<Qhestion> oh yeah there was a funny comment: "High dynamic means you dont know what it will do until you run it."
<Qhestion> oh i just remembered one more stupid thing about java: ram usage
<Qhestion> i just thought about using my VERY old notebook for programming... but definitly not with java
<jam> dato: so new-omni-completion is not supported for python??
<jam> At least, that seems to be what it is saying
<jam> Well, it says it is supported
<jam> but doesn't give you a link to more details
<jam> And doing "^X ^O" gives me "omnifunc not set"
<Qhestion> hmm C can call Python functions right?
<dato> jam: try :set omnifunc=pythoncomplete#Complete
<jam> Qhestion: yes, at least you can embed the python interpreter into a C program
<dato> jam: the distributed ftplugin/python.vim does that, and it... works
<dato> O M G
<dato> with help in the top
<Qhestion> jam: and Java can call C. so Java should be able to call python...
<jam> Qhestion: sure, but that doesn't mean you get nice-to-use objects in Java
<Qhestion> i dont care for that
<Qhestion> all i want is to call the bazaar functions
<Qhestion> as if would call em from the command line
<beuno> Qhestion, Verterok does that from eclipse
<beuno> for the bzr-eclipse plugin
<Qhestion> problem: the returned data should be easily parsable
<Qhestion> and easy = programming_effort + cpu_effort
<beuno> Qhestion, parsing XML seems to fall into the category, doesn't it?
<jam> Qhestion: well, you can do "bzrlib.commands.main()" but otherwise you probably want to deal in real objects
<Qhestion> why oh why is bazaar written in python? i understand that python is the better language, but javas tools are waaaaaaay more comfortable...
<LeoNerd> Because most languages are chosen for their suitability to the problem, not because someone happens to have a little IDE widget they prefer
<Qhestion> that was a rhetorical question.
<Qhestion> ("why do they always answer my rhetorical questions?" -- "i know!")
<Qhestion> oh nice, i will write it in python then. damned.
<thatch> bzr question (0.91 and 0.92) -- is 'bzr diff' supposed to show file timestamps in utc?
<Peng> Hey, you're right, it does.
<jelmer> hmm, there appears to be overlap betwene bzr-cpick and replay in bzr-rebase
<dato> oh, I never heard of -cpick
<thatch> Peng: do you think the utc-ness is intentional so I should get used to it, or patch/file bug?
<lifeless> thatch: I think we want to accept any timestamp and then show them consistently
<lifeless> so we should change log & diff and others at the same time; I thought there was a bug around this
<thatch> lifeless: you know I'm awful at coming up with good search terms for bzr bugs and/or docs...
<thatch> I find bug 121313
<ubotu> Launchpad bug 121313 in bzr "bzr info shows me times in unuseful timezones" [Low,Confirmed] https://launchpad.net/bugs/121313
<lifeless> thats probably it
<thatch> I should just get used to knowing when it is in UTC, eh? :)
<lifeless> lol no -
<zerok> hi :)
<dato> lifeless, thatch: relatedly, bzr log time zone is configurable via --timezone (local, original, or utc)
<dato> d'oh, of course it says that in the bug that thatch pasted :)
<AfC> Frustrating: because the current releases are called 1.0rcX, Gentoo is waiting until the next "real" release to package it, and not bothering with the rc's. I tried pointing out that 1.0rc1 == 0.93, but they didn't buy it.
<dato> go debian! :-P
<Kamping_Kaiser> theres me thinking gentoo packaged everything with source *grin*
<poolie> hello
<poolie> hi andrew - that's a bit annoying
<poolie> it would be good to get it in at least behind a mask (if i recall the term correctly)
<AfC> poolie: yeah, that's what I was trying to convince them to do, but they sat on it. Alas.
<AfC> Did those problems with the bzr:// functionality not working with packs get resolved?
<poolie> afc, yes, i believe they are
<AfC> That's encouraging to hear.
<AfC> [it is faintly disturbing to me that the Bazaar project doesn't use bzr:// in publishing itself]
<poolie> we should really set that up
<poolie> in fact, i think it either is live on launchpad now, or will be soon
<Peng> Seriously? Gentoo won't package it?
<poolie> i'll check
<AfC> Peng: they _could_ package it, but they didn't feel like it, waiting for an "actual" release instead.
<Peng> Well, you *have* been releasing a lot of RCs.
<AfC> Peng: (I'm sure if a Gentoo packager had been actively using it, then it'd be a different story, but for a package a person isn't using & testing & caring about, it's not entirely unreasonable)
<AfC> Peng: (you mean "they"; I'm not one of the Bazaar hackers)
<Peng> Okay, they.
<Peng> It's not unreasonable. It's just unfortunate, especially since bzr.dev is almost as good as releases.
<poolie> it would be nice someday to get a gentoo ebuild that installs from trunk
<poolie> as i believe they do with emacs
<poolie> but, let's get debs of that at least, first
<poolie> igc, could you add me as a pypi admin for bzr sometime?
<poolie> username 'mbp'
<igc> poolie: sure
<poolie> thanks
<poolie> jam, it varies between compilers on 64 bit platforms whether a long is 32 or 64 bits
<abentley>  Gentoo not giving users the latest & greatest?  How very un-Gentooish.
<poolie> iirc, for gcc it's 64 bits, for ms only 32
<jam> hmm... I don't know that dot will gracefully handle 2068 nodes with text, what do you guys think?
<dennda> Hey there. I have a patchfile (output from bzr diff). How do I apply those patches?
<jam> bzr diff | patch -p0 ?
<dennda> patch patchfile.patch didn't do anything
<jam> dennda: I think you need -p0
<jam> and usually you pass it in on stdin
<jam> patch -p0 < patchfile.patch
<dennda> ah yes
<dennda> it seems not to take a file as argument
<dennda> good. worked. thank you
 * jam => family time
<lifeless> dennda: also, bzrtools has 'bzr patch'
#bzr 2007-12-12
<beuno> if I cancel a reconcile in the middle and start it back again, will it "resume" it?   I've got a ~1gb repo, and it's been 4hs+ already
<spiv> beuno: no, it won't really resume.
<beuno> aaaaaw...
<beuno> it's going to be painful to upgrade all my branches...
<spiv> beuno: any knits that have already been rewritten won't need to be rewritten again, so it'll be fractionally quicker, but most of the time is spent calculating whether or not it needs to do that.
<spiv> beuno: what version of bzr?
<beuno> spiv, 1.0rc1
<spiv> Hmm, that's as good as it gets atm :(
<Peng> (You should still upgrade to rc3 though.)
<beuno> Peng, right, it's just the latest .deb I found for feisty
<spiv> There should be an rc3 deb later today.
<jml> how come bzr puts files named actual_file_name.~1~ in my working tree?
<LeoNerd> That's from 'revert'
<jml> ahh
<beuno> will try again with rc3 then
<LeoNerd> I find them useful; since you can them vimdiff it back into the real file
<spiv> jml: see also "bzr help revert" ;)
<spiv> beuno: yeah, rc3 won't be any quicker for reconcile I think, but we still fixed a few bugs :)
<jml> spiv: well, I had to be told it was from 'revert' before I could look up the help.
<spiv> jml: I winked for a reason
<spiv> jml: And you mean you don't memorise the help text of a command before running it? ;)
<beuno> spiv, thanks anyway  :D
<spiv> There's some work from jam that should land in bzr.dev soon that might speed up reconcile a bit as a side-effect.
<beuno> great, if packs are going to be default, having reconcile take 10hs on a core 2 duo is going to be a pain
<beuno> I have ~100 branches at this point, plus the ones from each user to upgrade
<beuno> and many are >1gb
<ubotu> New bug: #175764 in bzr "Improve bug tracker integration documentation" [Medium,In progress] https://launchpad.net/bugs/175764
<ubotu> New bug: #175771 in bzr-eclipse ""Widget is disposed" error" [Undecided,New] https://launchpad.net/bugs/175771
<spiv> Ok, I can do "bzr log -r bzr+http://localhost/code/foo" now, even though the server maps /code to a completely different path locally.  (And even with a shared repo at /code)
<spiv> So bug 124089 will soon be fixed in bzr.dev.  Finally.
<ubotu> Launchpad bug 124089 in bzr "wsgi smart server chrooting does not manage additional paths" [High,In progress] https://launchpad.net/bugs/124089
<abentley> spiv: Any thoughts on ParentsProvider.get_parent_map?
<spiv> abentley: I haven't thought much about it
<lifeless> abentley: FWIW I think get_parent_map is better than get_parents.
<spiv> abentley: Although I like how the ParentsProvider API at the moment is a single method.
<spiv> It makes the contract dead simple to describe and implement.
<lifeless> spiv: so change it all over - still a single method ;). e.g. a base class that implements get_parents in terms of get_parent_map which is abstract.
<abentley> My concern is about what happens when parents can't be found for a revision.
<spiv> lifeless: right, that's where I was heading :)
<abentley> That's rare enough that I think people won't consider it or design for it.
<spiv> lifeless: or just do without get_parents entirely, perhaps...
<lifeless> abentley: that's handled in john's proposal by having no entry for that revision
<spiv> lifeless: (like I say, I haven't thought much about it)
<abentley> lifeless: Right.  Which is a silent failure.
<spiv> I think having no entry in the returned map is fine.
<spiv> I don't think it's particularly surprising.
<abentley> So people will be oblivious that it happened.
<lifeless> so there are two sides; producer and consumer
<lifeless> on the producer side it's obvious whne it happens, you have to catch an exception.
<lifeless> on the consumer side, the current api you have to zip your input to the output.
<lifeless> abentley: I'd be happy with key:None to represent missing keys
<abentley> I'm not arguing for my current API.
<spiv> I'm not sure it's a "failure", exactly.
<lifeless> abentley: I don't think it's *needed*, but it will make foo.iteritems() behave badly if the consumer isn't ready to handle ghosts
<spiv> lifeless: using "zip" on two sequences of a different length is a silent failure, though...
<lifeless> spiv: the current api returns len(inputs) always
<abentley> I'm just trying to design the best API for getting dicts of parents.
<lifeless> spiv: and in fact the current api supports [foo, foo, foo]
<lifeless> abentley: sure; this is my 2c. We can either aim for KeyError, or for a key that is some illegal value.
<lifeless> abentley: and I don't object to either; or prefer either. I do prefer a dict as a return value though, because IO constraints mean that we really can't lookup in a specific order easily and efficiently anyhow.
<spiv> lifeless: right, I'm just thinking out loud about potential risks in possible APIs.
<lifeless> I will say that revid:None is *slightly* harder to implement down at the GraphIndex lever.
<abentley> KeyError from get_parent_map or from using the returned dict?
<lifeless> *level*
<lifeless> abentley: from the returned dict
<lifeless> (having a key with value None is slightly harder to implement because you have to track more closely what keys were missing in the graph index logic, so you don't replace a valid entry with None when delegating to a concrete index)
<lifeless> anyhow, either is sufficiently nicer than a list that I'll leave it up to you to decide :)(
<lifeless> s/(//
 * spiv -> lunch
<jkakar> I'm writing a simple plugin, to get a feel for Bazaar.  'bzr touch FILE [FILE ...]' will touch and 'bzr add' the files in the list.
<jkakar> I want to do this with TDD so I'm looking at tests in bzrlib.  Should I be using bzrlib.tests.TestCaseInTempDir and then creating branches and such to test the functionality of the plugin?
<lifeless> TestCaseWithTransport
<jkakar> Ah, thanks.
<lifeless> or possibly ExternalBase; if you are only writing a command ExternalBase is probably what you want
<lifeless> look at bzrlib.tests.blackbox
<jkakar> Cool, thanks.
<igc> poolie: patch for better bug tracker doc send to the ML now
 * igc lunch
<jml> hey guys. looks like there's a strange thinko in CommitBuilder.finish_inventory
<jml> http://rafb.net/p/VPYYzg59.html
<jml> AssertionError doesn't take 'stacklevel' as a keyword argument ;)
<abadger1999> I have a question on smart server operation.
<abadger1999> If the server is running in read-only mode does it still have to create a lock file or is there some way to run it with a user that is unable to write to the repository?
<lifeless> read only operations do not take out disk locks
<lifeless> for branches and or repositories
<abadger1999> lifeless: Ah.  Thanks, I think I misdiagnosed my problem.
<abadger1999> Looks like I'm running into bug #129030
<ubotu> Launchpad bug 129030 in bzr "Bzr inetd smart server requires write access on the user's home directory" [High,Confirmed] https://launchpad.net/bugs/129030
<poolie> hm, the index in the doc.b.o site seems to be broken
<igc> poolie: which url? it's working for me I think
<poolie> maybe my browser is just grossly confused, this is very strange
<poolie> igc, what do you see at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
<fullermd> It's preaching at me about annotate...
<igc> poolie: I see a bad UG generated by an out-of-date bzr.dev
<poolie> ok
<poolie> i'll log in to escudero and check it out
<igc> the bzr.dev doc was last generated on the 7th
<poolie> btw are you able to log in to escudero now?
<igc> I'm pretty sure I can
<poolie> wow, what is it with my cron job there? :-/
<igc> if you look in latest instead of bzr.dev, you get good docs
<poolie> btw i was just asking about escudero to check the IS job was done
<poolie> you don't have to login now
<igc> poolie: mbp added as an owner for bzr in pypi now
<poolie> when you say the bad user guide is caused by an out of date bzr.dev
<poolie> do you mean there used to be a bug that caused this but you fixed it??
<poolie> oh, i think i realized what it is: there are not enough makefile dependencies, so the docs did not always rebulid
<igc> poolie: yes, there was a bug in the Makefile and I fixed it
<igc> poolie: in bzr.dev, 3097 introduced the bug and 3098 fixed it
<poolie> good for you :)
<poolie> i made it always clean the directory first
<poolie> arguably we should actually check out to a new directory
<poolie> then it'll be even less likely to get wedged...
<igc> I checked the rc3 build last night and you correctly took across both
<poolie> ok, that looks good now
<poolie> thanks for checking
<igc> well I was panicking a little that the whole uG would be broken for everyone so I *had* to check
<igc> just knowing how to annotate doesn't quite do it :-)
<igc> poolie, jml: can someone review my bug tracker doc patch? I'll like to get it through soon so we don't miss it
<poolie> i'll do that next
<jml> igc: ok
<jml> igc: but I don't count as a reviewer :)
<igc> jml: I'd like your input on the Bazaar-with-Launchpad tutorial as well, though I'm not so concerned about whether that makes it into 1.0 or not - no rush on it
<jml> igc: you misspell "Launchpad" in the line above the "Making corrections" heading in the user guide
<jml> (grep for "Lauchpad")
<igc> yikes :-(
<igc> fixed
<jml> igc: apart from that I very much approve of the changes.
<igc> jml: thanks
<jml> igc: for reviewing your bzr with LP tutorial, what's the easiest way for me to get it and generate it into something a bit more readable?
<jml> igc: (rather than blue monotyped text with '+' at the start of each line)
<igc> jml: hmm, one moment
<igc> jml: http://people.ubuntu.com/~ianc/doc/en/tutorials/using_bazaar_with_lp.html
<jml> thanks
<jml> igc: I'm doing reviews all of tomorrow, I'll use my spare time to review that doc.
<jml> (it looks good enough that it's worth spending a fair bit of time on)
<hacklberry> pre-commit hooks are not implemented yet (if ever) in bzr, is that right? (i m using 0.92.0))
<thumper> hacklberry: I think there are
<thumper> hacklberry: but I don't know where or how
<thumper> poolie, spiv: pre-commit hooks?
<spiv> hacklberry: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-hooks
<spiv> hacklberry: also, http://doc.bazaar-vcs.org/latest/en/user-reference/hooks.html
<hacklberry> thanks, i m going to read it
<spiv> hacklberry: but it may depend on what you mean by "pre-commit" hook.  What we have today is something individual users can set up, but maybe you're looking for a hook that always runs before a change can be made to a particular central repository/branch?
<hacklberry> well i know this may sound a bit braindamaged, but i m trying to update a version number on my little C project, I need "keyword expansion ($Revision$)" or to register a hook that would run on every ci (something like: bzr version-info | sed -n '/^revno: \(.*\)/s//\1/p')
<spiv> You're not the first person to want keyword expansion :)
<spiv> We'd like to support it directly, but it's pretty low on the todo list at the moment.
<spiv> hacklberry: (http://bazaar-vcs.org/KeywordExpansion is a brief wiki page with a few of our thoughts on the topic and a link to some mailing list discussion)
<hacklberry> spiv: thanks, i read that
<igc> night all
<zerok> morning :)
<Riddell> jelmer: how do I branch svn://anonsvn.kde.org/home/kde/trunk/extragear/multimedia/amarok/ ?
<Riddell> it just says "not a valid Subversion branch path"
<Riddell> but I don't want the whole KDE repository
<alwyn> Hi everyone
<alwyn> I'm getting bug 153749 on my system.  bzr status gives MemoryError.  Anyone know how I can create a new clean branch including my uncommitted changes?
<ubotu> Launchpad bug 153749 in bzr "dirstate C helper MemoryError on bad dirstate file" [Undecided,New] https://launchpad.net/bugs/153749
<alwyn> must be my lucky day
<alwyn> mtaylor: Hi, I think I'm having a similar problem to what you discussed on this channel before.  Its about the MemoryErrors...
<mtaylor> alwyn: oh good
<fullermd> alwyn: I think the usual trick is to make a new branch, then copy the dirstate file over.  You'll have to re-add any added files, but...
<mtaylor> alwyn: that's what I had to do
<mtaylor> alwyn: actually - I was able to branch from my b0rked branch
<mtaylor> I think
<alwyn> ok, so make new branch, copy dirstate file to new branch and manually copy all changed files...
<fullermd> Should be able to.  branch doesn't need to fiddle with the WT, so a b0rked up dirstate file wouldn't affect it.
<alwyn> I could branch, but it doesn't have the uncommited data of course
<fullermd> Nono, other way around.
<fullermd> Copy the new branch's dirstate file into your main branch.
<alwyn> oh....
<alwyn> let me try that
<fullermd> Then all your changes are still in place; it's just got a clean slate to compare them against, instead of a cranked up one.
<mtaylor> and then just had to reapply outstanding patches
<alwyn> dumb question, where do I get the dirstate file?
<fullermd> .bzr/branch/dirstate, I thin.
<fullermd> k
<dato> is it not .bzr/checkout/dirstate ?
<fullermd> Somewhere in .bzr/branch/ at any rate.
<fullermd> Oh.  Dur.  That's what I mean.
 * fullermd pours another cup of coffee.
<alwyn> looks like .bzr/checkokut/dirstate
<alwyn> sorry, could just have done a find
<alwyn> ok, thanks a million!  Do you lose any information by doing this? history etc?
<fullermd> The only think you should lose would be info about files you might have 'add'd since the last commit.
<alwyn> ok, thats fine
<alwyn> btw. I also used the eclipse bzr plugin, maybe it has something to do with it...
<mtaylor> alwyn: I have had the problem without the eclipse bzr plugin
<kiko> hello there
<kiko> https://edge.launchpad.net/bzr-doc-russian
<kiko> is this a reasonable project?
<ubotu> New bug: #175839 in bzr "`python setup.py bdist_rpm` fails" [Undecided,New] https://launchpad.net/bugs/175839
<zerok> Any idea when the whole translation process ( https://blueprints.launchpad.net/bzr/+spec/i18n ) will be started?
<jam> kiko: it is a genuine desire from Alexander Belchenko (bialix)
<kiko> jam, and is having the project the right way to address it? I'm fine with keeping it, just wanted to validte.
<jam> what alternative would you propose?
<jam> I think it is mostly focused on translating the tutorials, etc.
<jam> I suppose we could move some of that into core bzr, but certainly the rest of us aren't qualified
<jam> to evaluate Russian documentation
<kiko> no, I also think it's fine. it's just that if it's just a translation project it's better addressed somehow else, but this is the case where it's actual original content
<jam> sure, if it was just doing i18n for bzr core, then it would be done through Translations/Rosetta
<jelmer> Riddell: try removing ~/.bazaar/subversion.conf
<Riddell> jelmer: that seems to help, thanks
<Riddell> although it might take a while to branch all 747585 revisions
<luks> Riddell: yep, my svn-cache sqlite database for the KDE SVN is ~2GB :)
<luks> (I needed it for a project with about 400 revisions)
<Riddell> luks: was that made with bzr-svn ?
<jelmer> Riddell: it won't branch them all, will just fetch revision metadata
<jelmer> Riddell: but the memory leak in the python subversion bindings may cause it to use a lot of memory
<jelmer> bug 54253
<ubotu> Launchpad bug 54253 in bzr-svn "Excessive memory usage in bzr-svn" [Undecided,Confirmed] https://launchpad.net/bugs/54253
<mtaylor> jelmer: do the subversion folks know about the memory leak?
<ubotu> New bug: #175886 in bzr "dumb http servers make packs perform very badly" [High,Confirmed] https://launchpad.net/bugs/175886
<theSoftMan> Hello all, does somebody try to make the mantis bug tracker integration with bzr ?
<elmo> +Depends: ${python:Depends}, bzr (>= 0.92~rc1), bzr (<< 0.93~), patch
<elmo> ^-- from http://bazaar-vcs.org/releases/debs/edgy/bzrtools_1.0.0-0bazaar1.diff.gz
<elmo> makes the resulting binaries a little less than useful..
<dato> I thought lifeless used sid packages as a start.
<dato> elmo: anyway you could temporarily install sid's, if you're anxious ;)
<X0d_of_N0d> anyone using tortoisebzr?
 * X0d_of_N0d hates windows and how much it sucks.......
<X0d_of_N0d> nm... I figured it out
<beuno> does the new pack format compress the repo?  the branches I've converted up to know don't get smaller
<vila> beuno: you  get far less files for now, more compression will come later
<beuno> vila, sounds about what's happening then, thanks  :D
<lifeless> beuno: be sure to remove the .bzr.backup though :)
<lifeless> beuno: or be doing du on .bzr only :)
<beuno> lifeless, yeap yeap, removing .bzr.backup every time
<beuno> just had the idea in my head packs compressed data
<beuno> (and the pack commands actually says it does)
<beuno> s/commands/command
<beuno> so I just wanted to make sure I wasn't missing something
<beuno> now, I just have to get a benchmark in place to compare kints <> packs performance, and find a way to reconcile those 1gb+ repos without them taking ~10hs
<beuno> 100+ branches of all kinds of shapes and sizes are waiting to be upgraded and compared  :D
<lifeless> beuno: future editions will approximately 1/2 the current storage size
<lifeless> beuno: and packs do compress data; so do knits :)
<beuno> lifeless, sounds promising. And, on the "already compressing bit", you know, you spoil us, so we tend to give some things for granted  :p
<beuno> any ideas on the reconcile bit?
<beuno> 10hs for 1gb branch doesn't seem like a fair tradeoff
<lifeless> beuno: where you reconciling it in knit or pack form?
<lifeless> beuno: is it 1gb because of iso's, or just many many files and many many commits ?
<beuno> lifeless, knit, so I can upgrade to pack
<beuno> lifeless, big files mainly (~50mb)
<beuno> I don't think it has more than 100 commits
<lifeless> beuno: try this (in a copy) - upgrade, reconcile.
<lifeless> it may be a tad faster
<lifeless> also make sure you have the C extensions.
<beuno> I installed from .deb, so I assume that should be taken care of, right?
<dato> yes
<beuno> (trying right now, didn't know I could reconcile after upgrade, thought it was a pre-requisite)
<lifeless> beuno: it should be yes.
<lifeless> beuno: it used to be a pre-req, until we got a native reconcile for packs (reconcile is right down low-level, it is hard to reuse across formats)
<dato> so, if it's not a prerequisite, what happens if you don't reconcile after upgrading?
<dato> lifeless: also, NEWS.Debian recommends `bzr reconcile && bzr upgrade`. should I change that in anyway for 1.0, or maybe retroactively edit for 1.1?
<lifeless> when you push it may error
<dato> ok
<lifeless> or when you branch
<lifeless> thats if the 'check for missing parents' patch has gone in,I haven't been following recently.
<dato> oh, right :)
<lifeless> if that patch hasn't landed, then it will silently discard your data
 * beuno is upgrading
<jelmer> 'evening dato, lifeless
<lifeless> hi jelmer
<dato> hey jelmer
<beuno> upgrades, reconciling
<beuno> s/upgrades/upgraded
<beuno> (seems a trillion times faster)
<beuno> yeap, took < 1 minute
<beuno> vs ~10 hours estimated
<beuno> you rock lifeless   :D
<beuno> that should be documented somewhere
 * beuno runs out for a while
<dato> lifeless: I don't seem able to find the patch in the list
<dato> if the speedup is as great as beuno says, we should really change NEWS.Debian
<lifeless> dato: pqm@pqm.ubuntu.com-20071201001053-zi6k6s2817c1p97s
<igc> morning all
<dato> lifeless: thanks a lot. since it is in 1.0, I'll recommend upgrade & reconcile instead of reconcile & upgrade
<toed> I've checked out some code from a remote location, changed a few things, and commited, but how do I send my changes back to said original location?
<jml> toed: 'bzr push'
<jml> toed: or 'bzr push <remote_location>'
<toed> it says 'ERROR: No push location known or specified.', but it does have the url when I do bzr info (under the heading related branches, parent branch)
<radix> toed: if you actually used "bzr checkout", then the changes should've been automatically pushed back when you committed. Is that what you did?
<toed> I'm not entirely certain if it was, it's been a while
<seb_kuzminsky> toed: copy & paste the output of 'bzr info'
<toed> http://rafb.net/p/fkmlyu84.html
<bombcar> When one user does a remote sftp commit of the project, other users cannot remotely checkout the project (or update) via sftp - it gives an error 13 permission denied. I can solve the problem by doing a chgrp -hR bzr ProjectDir (bzr being a group that all are members of). The error is usually in a file in the knits directory being owned by user with group user (default group for Ubuntu is the user's group). Is this normal?
<seb_kuzminsky> toed: try "bzr push <url-to-parent-branch>"
<toed> seb_kuzminsky: alright, thnaks
<seb_kuzminsky> toed: good!  also, try "bzr push --remember <url-to-parent>" and it will remember, then you can just say "bzr push" in the future
<toed> perfect
<lifeless> bombcar: there is a bug open on this about openssh's sftpo server msking out setgid
<bombcar> I found that one (50568) and I'm trying the workarounds.
#bzr 2007-12-13
<elmo> lifeless: did you see my whining earlier about the bzrtools edgy+ packaging being broken?
<elmo> dato: (and thanks for the suggestion of sid, I can fix it easily enough myself, I just want the bazaar-vcs.org repos to be installable :)
<elmo> lifeless: and/or is launchpad bugs an appropriate place for that kind of problem?
<poolie> spiv, does this error about "remote server did not return a token" mean anything to you?
<spiv> Sounds like a locking issue?  Where did this occur?
<poolie> new mail to the list
<poolie> if it's not familiar off hand i'll check launchpad and file a bug
<spiv> Not familiar off-hand, no.
<spiv> I'd be interested in the -Dhpss log for that.
<ubotu> New bug: #176020 in bzr ""remote server did not return a token" assertion error" [Undecided,New] https://launchpad.net/bugs/176020
<igc> poolie: re "Branch 6 options" in the User Guide, the intro text looks wrong
<igc> I assume these options all apply to new formats and perhaps to dirstate as well, not just dirstate-tags
<igc> how should I word that and can anyone suggest a better heading? I don't think "Banch 6" will mean much to most users
<abentley> igc: the branch 6 options do not apply to dirstate.  Branch 6 introduced tags.
<igc> abentley: but doesn't dirstate support the 5 settings listed:
<igc> append_revisions_only
<igc> parent_location
<igc> bound_location
<igc> bound
<abentley> No.
<igc> push_location?
<igc> wow
<abentley> Those were not part of the config file for branch format 5.
<abentley> They were in separate files.
<igc> ah
<abentley> And there was no strict equivalent for "bound" or "append_revisions_only".
<igc> abentley: so should I just say "dirstate-tags or later" formats?
<abentley> Sure.
<igc> thanks
<abentley> Actually, I guess push location was in use for format 5, but it was typically stored in locations.conf instead of branch.conf
 * igc lunch
<lifeless> spiv: poolie_: that token bug - bet you its a knit local branch, pack remote branch, or some such.
<spiv> lifeless: hmm, interesting thought.
<lifeless> note - I haven't read the bt or anything
<lifeless> just a guess
 * spiv nods
<luislavena> hello guys, anyone awake?
<Peng> I am, but I'm not very useful.
<pattern> what's the proper way to go about deleting a branch from a repository?
<lifeless> pattern: rm -rf the branch
<pattern> nice
<pattern> thanks, lifeless
<Peng> pattern: The revisions unique to that branch won't be removed, but it shouldn't be wasting enough space to be worried about.
<luislavena> Peng: me neither, just wanted to get some "best practices" recommendations of using bzr... being very annoyed by all the git mambo...
<poolie_> reading the user guide patch
<Peng> luislavena: Git mambo?
<luislavena> Peng: yeah, all the "fuzz" around the -powerful- git, but couldn't get the picture of the unique checkout/mirror and their use of branch/feature and switch...
<luislavena> still don't get it, and reading the user guide have a question :P
<Peng> I didn't understand any of the terms in that sentence, but I'm kind of overloaded right now.
<luislavena> Peng: no problem, I'm kind of tired too...
<Peng> I'm not tired, I'm overloaded.
<Peng> Argh, I'm about to explode.
<luislavena> what the hell, I'll re-read the user guide for nth time and try to compare some of the functionality...
<luislavena> Peng: oh, sorry :|
<fullermd> luislavena: If you have a question, just ask it   :)
 * fullermd wraps some duct tape around Peng for safety.
<luislavena> will be a best practice use a checkout to mirror a dev trunk?
<luislavena> I mean, I don't plan to work directly on it, but create my branch of it (feature-NN)
 * luislavena think bzr have so many options that is overwhelming
<fullermd> Yes, a checkout would work.  So would a branch that you just never commit in; the major difference would be whether you "update" or "pull" to keep it caught up.
<fullermd> (at least, the checkout _should_ work.  There've been occasional hiccups in the past where checkout wanted to be able to write to the upstream for locking)
<luislavena> fullermd: ok, then a branch on a treeless repo will do the trick.
 * fullermd nods.
<Peng> FWIW, I don't use checkouts. I don't see the point, and since they aren't bzr's main functionality, I don't expect them to work as well.
<Peng> (I do occasionally use a lightweight checkout to save downloading the history, though.)
<luislavena> I see, thank you Peng
<luislavena> I'll try to get used to the workflow, being a svn guy for quite long :P
<fullermd> I use checkouts with some regularity, especially for work (as opposed to personal) projects.  For all the uber-distributed disdain for it, the shared-branch workflow does very well if it fits what you're doing.
<luislavena> fullermd: that's the problem, found something that 'fit' whatever I'm trying to do.
<luislavena> couldn't get a clear picture of the workflow that will fit better with my development.
<fullermd> Yeah, it can be tricky.  Once you digest it, though, the choice is great, since there's so many different problems that need different solutions.
<fullermd> And even the same problem at different times.  bzr's been great for me at allowing that adaptability.
<luislavena> Peng: thank you.
<luislavena> fullermd: thank you too for your comments
<fullermd> luislavena: Any time  :)
<luislavena> a last (for now) question:
<luislavena> lets say I have one share repo and my "dev" branch on it, all locally.
<luislavena> I can push it remotely, but I need it to be inside another shared repo? or can stand by itself?
<spiv> luislavena: it can stand by itself.
<spiv> luislavena: if you have a shared repo on the remote side, pushing a new branch to that repo will automatically use that shared repo, but if there isn't it'll just make a standalone branhc.
<Peng> It's a good idea to use a shared repo, though.
<fullermd> If you use 'push' to send it around, it will go into another repo, or by itself, whichever fits at the other end.
<fullermd> You can't, e.g., just tar it up and move it around though, unless it's standalone (or you tar and move the whole repo)
<luislavena> I didn't tried the remote stuff, being using bazaar quite some time (but not full due work) but didn't make pushing yet :-$
<spiv> luislavena: basically, push will work either way.  Just like locally, bzr can copy less data if there's a shared repo that already has some of the revisions you're pushing, though.
<luislavena> thank you guys again, I'll try to find what fits best my workflow (trunk, production and staging with local features that will be merged on these 'stages')
<luislavena> spiv: if there is already data, push should only require to add the missing data, not remove and start all over, right? :|
<spiv> luislavena: right.
<Peng> luislavena: But if you aren't using a shared repo, it will send all of the data again.
<spiv> Peng: well, if you push a new branch it will
<spiv> Peng: If you're just pushing new revisions to a branch you've already pushed, it won't.
<Peng> Oh, right.
<luislavena> what if I "diverge" the branch and try to push it to the original branch location?
<luislavena> nevermind, will try wtih some dummy data :D
<encompass> hey guys, think I made a mistake... I canceled a push... and now I am getting this...
<encompass> No handlers could be found for logger "bzr"
<encompass> when ever I try to push.  How can I fix this issue?
<encompass> just found the work around... it is a bug in both launchpad and bzr
<igc> poolie: can I merge the bug tracking doc changes? jml said they were ok with him
<AfC> I just created a branch called 'hope', where I was hoping that a massive merge bringing in some changes from a different upstream project would work.
<AfC> It didn't
<AfC> rm -r hope/
<AfC> Clearly, I have no hope.
 * igc dinner
<Riddell> at 16:30 we have a half hour tutorial on bzr in #kubuntu-devel for https://wiki.kubuntu.org/KubuntuTutorialsDay, if there's a knowledgeable bzr person who could hang around and answer the questions I don't know that would be good
<spiv> Riddell: That's UTC?
<Riddell> spiv: yes
<Riddell> possibly not ideal for .au
<Riddell> or that side of the world
<spiv> Yeah.  There's likely to someone around at that time, though.
<mwhudson> i'll be around if you can't get somone more qualified
<mwhudson> jelmer or vila maybe?
<mrevell> Good morning Bazaaros!
<jelmer> Riddell,mwhudson: I just joined there as well
<jelmer> hi Matt
<Riddell> thanks
<gsuveg> re
<gsuveg> smart server run good ?
<Peng> Good?
<gsuveg> can i use as production?
<Peng> Sure.
<gsuveg> now use this via simple ssh
<Peng> bzr+ssh?
<gsuveg> yes
<Peng> What do you mean?
<gsuveg> now bzr run not as smart-server
<Peng> What do you mean?
<gsuveg> nevermind, sry, i need run
<gsuveg> i read the website, thanks Peng
<Peng> Ok.
<zerok> hi :)
<jelmer> Riddell: just curious, what is the biggest issue with the KDE repository when using it with bzr-svn?
<jelmer> Riddell: The memory usage when it's caching all revision metadata?
<luks> jelmer, the memory usage makes is almost unusable
<luks> jelmer, you have to restart it about every 1000 revisions, which gets boring for 700k revisions
<luks> (and people who are not aware of the bug will be very surprised)
<Riddell> jelmer: yes, caching the metadata is just unworkable unfortunately
 * quicksilver cries
<quicksilver> why do so many blog postings about VCSes not even mention bzr?
<quicksilver> http://blog.moertel.com/articles/2007/12/10/how-i-stopped-missing-darcs-and-started-loving-git
<LeoNerd> Because people don't know it exists?
<LeoNerd> SVN has all the limelight. And Git.
<LeoNerd> Git was in news lots because of the bitkeeper/kernel stuff
<zerok> and mercurial currently has some little hype thanks to opensolaris and openjdk. perhaps canonical should also do some little advertising ;)
<Peng> I wonder how I found bzr?
<Peng> There were those Mozilla comparisons, but I think I knew about it before them.
<zerok> i think i found it through some darcs-to-* comparison ...
<ricardokirkner> hi there.. I am trying to migrate some svn project to bzr. I am working on a fedora core 7 machine, and I cannot get the bzr-svn plugin to work, due to the subversion bindings version mismatch... has anyone managed to get this working on a fedora core machine ?
<mwhudson> ricardokirkner: my tongue-in-cheek answer for getting this working is installing ubuntu in a chroot/vmware/xen :)
<mwhudson> but once upon a time i did manage to build the right version of the bindings on os x
<jelmer> luks, Riddell: Thanks for the feedback.
<jelmer> I'll see if I can spend some time fixing that memory leak in the next couple of days.
<jelmer> ricardokirkner: I'm not aware of anybody providing pre-built rpms of a patched subversion, but there is a link on the bzr-svn wiki page to a howto that explains how to patch subversion on fedora
<Daviey> Hey, I'm having a problem with bzr-email.  i have a branch that i want a linux user group to be able to commit to (locally) - that works fine, but the bzr-email only seems to work if it's the owner
<jam> Daviey: do you have a specific traceback we can see?
<jam> !paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<jam> ubotu: paste
<Daviey> jam: eek, i'm not sure where logs for bzr-email are kept
<jam> Daviey: well, mostly I'm interested in seeing what you saw on the terminal
<jam> Either that
<jam> or you can give me the tail of ~/.bzr.log
<Daviey> $ bzr commit
<Daviey> added test
<Daviey> Committed revision 1.
<Daviey> thats all on a working one
<jam> Daviey: you may want to use paste.ubuntu-nl.org since it won't throttle you for a big message
<Daviey> i will
<jam> I'm also not sure what you mean by "only works if it is the owner".
<jam> I'm not sure if you realize that each user needs to have bzr-email installed
<jam> and configured
<Daviey> yeah, i do
<Daviey> just my own user testing atm
<jam> It doesn't seem like the branch permissions should effect it, but I'm happy to help you debug what is going on
<Daviey> http://pastebin.com/m1f1da47f
<Daviey> thats if i commit to a folder where i'm in the same group, and have rw perms
<Daviey> http://pastebin.com/m7a54f32a and thats if i commit from a branch in ~ (hence i'm the owner)
<Daviey> jam: ^
<jam> Daviey: I don't see much of a difference there
<jam> (only the revision_id and timestamps seem to change)
<Daviey> jam: there isn't!  :( .. but the second works and the first doesn't
<jam> Daviey: define "works" :)
<jam> Sends an email versus not sending an email?
<Daviey> ie, sends an email
<Daviey> yes
<Daviey> I'm guessing it still looks for $HOME/.bzr/ of current user, and not the group user?
<jam> Daviey: Do you mean $HOME/.bazaar/bazaar.conf ?
<Daviey> yes
<Daviey> (sorry)
<jam> I'm sure we don't ever look in a group .bazaar
<jam> Config file is always per-user
<jam> I don't think we have a "group config"
<jam> You could probably set things in the branch itself
<jam> via $BRANCH/.bzr/branch/branch.conf (for --dirstate-tags or newer branches)
<Daviey> oww, i'll try that
<jam> Daviey: is there even a normal way to say "give me the home directory for this group" ?
<jam> You could have all users override BZR_HOME
<jam> to have it look in a different place for ~/.bazaar/bazaar.conf (and locations.conf)
<jam> But then it wouldn't really be per-branch
<Daviey> (only want one branch atm)
<Daviey> Can post_commit_to & post_commit be in bazaar under default?  Or should the wildcard [*] be used in locations.conf?
<Daviey> hmmf, doesn't work with $BRANCH/.bzr/branch/ either
<jam> Daviey: I think you can put it in [DEFAULT], but only do that if you want all commits to send email
<jam> I know I have some branches I consider "private"
<jam> Daviey: what does "bzr info" give in the group branch?
<jam> I'm wondering if it is an older format that only uses ~/.bazaar/locations.conf
<jam> Branch format 6 (and above) uses .bzr/branch/branch.conf
<jam> also ~/.bazaar/locations.conf takes precedence over .bzr/branch.conf just in case
<glyph> How does one install bzr plugins?
<glyph> I have grabbed the push-and-update plugin's source, but there aren't any docs associated with it.
<Peng> glyph: Drop it in bzrlib/plugins or ~/.bazaar/plugins.
<Daviey> jam: i'm using Bazaar (bzr) 0.15.0, but Gutsy package of bzr-email
<jam> ouch... that's an old Bazaar.
<jam> I would recommend upgrading if possible
<glyph> bleh.
<jam> Some known minor bugs with how it handles renames
<glyph> and does anyone have a suggested replacement for transport.split_url?
<glyph> I see it is a "@deprecated_function(zero_ninety)" but no suggestion of a replacement
<jam> glyph: for what we need, I believe you can just grab items off of the transport itself
<jam> transport._user
<jam> transport._scheme
<jam> transport._password
<jam> etc
<jam> glyph: if you are interested in updating push-and-update, I'm happy to merge any patches
<jam> By the way, it would be nice to change it to work as a post-push hook
<jam> rather than a separate command
<glyph> jam: Yeah, I was thinking the same thing
<jam> So it could install a branch hook
<jam> and then if it sees that the URL is ssh/sft
<jam> sftp
<jam> it could check if there is a remote working directory
<glyph> jam: I don't think I understand the workings of bzr well enough to actually patch this though :)
<jam> and then trigger the rest of the code
<jam> glyph: ok, I'll take a few minutes and put something together
<glyph> jam: <3
<jam> I wrote it originally, but just haven't really needed it since
<glyph> jam: I don't really "need" it, but it makes an awesome demo
<glyph> jam: I was just showing bzr to a guy I know who maintains a stereotypically absurd apache configuration
<Peng> Why does diff need a working tree?
<glyph> "bzr init" in /var/www kind of blew him away ;)
<jam> Peng: it theoretically doesn't
<jam> Peng: igc has a patch on the ML which gets rid of that
<glyph> but it would have been nice for "push" to just update the working tree on the server (since that's really his main use-case anyway)
<dato> that reminds me my discussion with lifeless the other day about a possible `push -u`, and that I still have to mail the list
<Peng> jam: Oh, cool.
<Peng> Just out of curiosity, why does it currently need one?
<jam> I think it changes the basic flow of the command, but it means you don't need WT
<jam> Peng: because it is a DWIM command, and it is complicated to get all of the edge cases working
<jam> For example, you can diff a working tree file that doesn't exist in the branch
<Peng> jam: Oh, that makes sense.
<hexmode> Can anyone help with pqm?  Here's where I am currently: http://rafb.net/p/lSPpmX40.html
<ricardokirkner> hi. I managed to branch from my svn repository to a bzr repository, but in order to do that, I had to create a repository with the dirstate-with-subtree format. My problem now is that I cannot make a branch from this last branch into a repository with another format, or even convert the repository format
<ricardokirkner> any ideas on what I should try?
<dato> ricardokirkner: they are incompatible repository formats
<dato> ricardokirkner: my recommendation is that you keep your bzr-svn branches in a separate shared repository. why do you want to use an existing one, since they are separate projects, anyway?
<ricardokirkner> dato: maybe what I am doing makes no sense.. what I want to do is to migrate a project completely to bzr.
<ricardokirkner> for that I branched from the svn repo
<dato> ok, very well
<dato> (what version of bzr do you have?)
<ricardokirkner> but then, since the repository format is not the default one (it requires dirstate-with-subtree format), I wanted to branch to another repository, in the new format
<ricardokirkner> I am using bzr 0.92
<ricardokirkner> is there a better way to do that?
<dato> you cannot go back from dirstate-with-subtree to dirstate
<dato> that is, branches originally created with bzr-svn are not compatible with the default format
<dato> but that should not be a very big problem, I think
<ricardokirkner> but if I want to stay in bzr from now on... that means I will have to stay frozen on that repository format forever?
<dato> bzr 1.0-rc1 introduces a couple new, non-experimental repository formats, rich-root and rich-root-pack, to which you can upgrade from dirstate-with-subtree
<dato> any of those two is very safe to use
<dato> (the upgrade maybe slow, though)
<xif> do centralized version control systems offer particular advantages to commercial companies?
<ricardokirkner> so, what you are saying is.. I should stay with the current format -- dirstate with subtrees -- until bzr 1.0 is out, and then I will be able to upgrade the repository format.. correct?
<xif> is it harder to keep your code closed / secret with a distributed VCS?
<Peng> xif: Yes, but not inherently.
<xif> Peng: what do you mean?
<dato> ricardokirkner: yeah. but if you don't upgrade, you'll make people with older bzrs able to branch. why do you seem so anxious to upgrade, though? :)
<Peng> xif: Well, with a centralized VCS, it's still possible to extract the entire history and wind up with just as much information as with a DVCS.
<Peng> xif: The DVCSes currently aren't really focused on commercial environment so they don't have as good access-control features.
<ricardokirkner> because I think... (here I might be wrong) that new repository formats should be more efficiente (performance wise) and eventually, I will want to switch
<Peng> ricardokirkner: Well, the developers aren't trying to make new repo formats that are slower!
 * Peng notices the backlog and scratches that last line.
<xif> Peng: so you claim CVCSes are more oriented for commercial / closed environments, so - incidentally to them being centralized - they're also a bit easier to protect than the DVCSes?
<Peng> Haven't packs been pushed much more rapidly than previous backwards-incompatible changes were?
<Peng> xif: Well, I'm just talking about Subversion here.
<dato> ricardokirkner: there is always a way to upgrade to newer repository formats, for example in 0.92 you already have pack-0.92-subtree
<xif> Peng: so SVN specifically has more evolved access-controls than most DVCSes?
<dato> ricardokirkner: and that upgrade is pretty straightforward. the full details of this story is that -subtree is an experimental format, and a new format was created a bit for bzr-svn use case, the rich-root one.
<ricardokirkner> dato: ok... but currently there is no way to move the repository to the currently default format. actually that is no issue as long as the dirstate with trees format is efficiente enough
<Peng> xif: I'm saying that svn has better access-control than the DVCSes I have experience with (bzr and hg), and that, while that is one thing that's being worked on, I've never seen commercial environments discussed.
<ricardokirkner> dato: what would you recommend me to do?
<Peng> I crafted that sentence too carefully.
<dato> ricardokirkner: oh. maybe it would help for you to think that, given that 0.92's default format is "dirstate",  dirstate-with-subtree is actually an addition to it :)
<xif> Peng: I see
<xif> Peng: I'm asking because I'm wondering why a certain company is using Subversion instead of bazaar / git / hg
<ricardokirkner> oh... ok. :-$ I hadn't though of it that way
<xif> they have some very smart people there, many of the Python knowledgeable - people likely to prefer bazaar or hg
<dato> ricardokirkner: what to do, depends on how much concerned are you about having the latest and the greatest, and about maintaining compatibility with older bzrs for other people for branch from you.
<xif> so I guess that the codebase being top-secret has something to do with it...
<Peng> xif: Well, even if companies have some smart people, they're generally insane. :)
<xif> Peng: nah, this company's ok, I think :-)
<Peng> xif: When you have gigabytes of history, it sucks that DVCSes copy the whole thing to every developer's computer.
<xif> their CEO / CTO is a former hacker.
<xif> ah, that might make sense as well
<xif> Peng: what's the common solution for such a problem?
<jam> xif: http://jam-bazaar.blogspot.com/2007/10/bazaar-vs-subversion.html
<xif> I believe the Linux codebase has it, right
<Peng> xif: Solution?
<xif> Peng: certainly there are some projects - e.g. the Linux kernel project - requiring  said "gigabytes of history" while using a DVCS
<Peng> xif: Meh.
<jam> xif: Linus doesn't care if it hurts you, as long as it works for him
<Peng> xif: 10+ GB seems to be common in corporate environments, but not so much with FOSS.
<xif> oic
<Peng> xif: I don't know of any FOSS stuff over 2 GB.
<jam> xif: Bazaar has "lightweight checkouts" and we are working on "shallow/stacked branches" to avoid some of it
<jam> Peng: Moz was >3 GB in CVS
<jam> Peng: OOo is about 20GB in CVS
<jam> but not all of that is code
<jam> they have stuff like mp3's of people's interviews in their CVS repo
<Peng> jam: Moz may be 3 GB in CVS, but one can assume it would be a lot smaller in git.
<Peng> jam: But OOo, oh.
<jam> Peng: sure, it dropped to ~1GB in Bazaar
<Peng> s/git/anything else/, then. :P
<jam> Still, 1GB is non-trivial for most download
<xif> jam: "to avoid some of it" -> what's "it"?
<jam> xif: downloading the full set of history
<jam> Lightweight Checkouts store 0 history locally
<Peng> (They don't even store copies of the files like in svn, do they?)
<jam> Stacked/Shallow branches would store a few commits
<xif> jam: I see, thanks. I'm reading your blog now
<jam> Peng: correct
<Peng> :X
<jam> Peng: but we do keep the inventory locally, so "bzr status" works
<xif> why should I use bazaar over git or mercurial?
<jam> but "bzr diff" has to hit the remote
<jam> xif: http://bazaar-vcs.org/BzrVsGit
<jam> xif: http://bazaar-vcs.org/BzrVsHg
<xif> thanks :-)
<jam> and http://bazaar-vcs.org/BzrVsSvn, but mostly it just points to my blog
<xif> yeah, and I don't think many people who actually know either (or even understand CVCS vs. DVCS) would need help deciding between SVN and BZR
<Riddell> ropiku: you're trying to push to launchpad?
<ropiku> Riddell, yes and it says that I don't have a registered SSH key
<ropiku> Riddell, and I pasted my .ssh/id_rsa.pub onto launchpad
<Riddell> ropiku: what's your LP id?
<ropiku> Riddell, I think the weird stuff is that I push to sftp://bazaar.launchpad.net/~ropiku/kubuntu-tutorial/ropiku-branch
<ropiku> Riddell, ~ropiku (and name Mihai)
<Riddell> that all looka fine
<ropiku> Riddell, and it says "Launchpad user 'mihai' doesn't have a registered SSH key." that's my local username
<Riddell> oh, different user name
<Riddell> sftp://<lp-user>@bazaar...
<Riddell> so bzr push sftp://ropiku@bazaar.launchpad.net/~ropiku/kubuntu-tutorial/ropiku-branch
<ropiku> pushing...
<ropiku> Created new branch. ;)
<Peng> Blehh, BzrVsHg was written by a marketer, wasn't it?
<ropiku> Riddell, ssh was connecting to my local username, that was it ?
<Riddell> ropiku: yes, which is the wrong username for launchpad
<Peng> At first glance when it was first created, I thought that article was garbage, but now it looks kinda-OK, except that it sounds like marketing trash.
<ropiku> what's the difference in using sftp:// instead of bzr+ssh, isn't bzr more efficient ?
<dato> yes
<dato> for bzr+ssh, bzr has to be installed in the remote end
<xif> I'm leaning towards bazaar because:
<xif> 1) it's pure Python. I like pure Python
<xif> 2) I like Ubuntu and Canonical.
<Peng> xif: Psst, bzr has some Pyrex (combines Python and C) and C bits. :P
<xif> Peng: oh shoot
<dato> Peng: errr
<dato> xif: those are optimizations and the same functionality is provided by pure bzr
<dato> pure python, I mean
<Peng> Right. I was trying to think of how to say that.
<Peng> Anyway, bubble-bursting over.
<jam> xif: you don't *have* to compile them, we have pure-python fallbacks
<xif> Wikipedia says bazaar is Python:
<xif> http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Technical_information
<jam> But they are a bit faster if you do
<xif> Mercurial OTOH is listed as "Python, C"
<xif> jam: yeah, it's still cool though
<xif> also, Pyrex is better than plain C.
<Peng> Yeah, Mercurial has four C modules.
<Peng> Bzr has parts of modules written in Pyrex or C with alternate Python versions.
<Peng> What about Cython?
<xif> what about it? :-)
<jam> vila: ping
<xif> it's a nicer Pyrex afaik, but less people use it
<xif> jam: btw, how do create "Python fallbacks" for C code?
<xif> just rewrite the whole thing in Python, then make sure it passes the same tests?
<Peng> Cython is pretty new.
<jam> xif: correct
<jam> Except the other way
<xif> jam: cool, good to know
<jam> we had it written in Python
<jam> and then we implemented it in C/Pyrex
<xif> yeah, I assume so: Python is better for prototyping
<jam> and made sure that all the tests pass with both ways
<Peng> A couple months ago Cython's website said it was only experimental, but I can't find that now.
<jam> So when we run "make check" it tests both implementations
<jam> vila: I'm getting a "500 Too many spams from your IP" when trying to send email to you, but the page it sends me to is in french
<xif> jam: what's the deciding factor between using C or Pyrex for the optimized rewrite?
<jam> vila: http://postmaster.free.fr/
<jam> xif: Generally we prefer Pyrex
<jam> we had 1 person rewrite something in C
<jam> and it was good enough we weren't going to rewrite it again in Pyrex
<jam> I personally always use pyrex
<jam> for things I've rewritten
<vila> jam: WTF ?
<jam> I really like how it handles exception handling without me needing to worry about it all the time
<jam> vila: I *think* my ISP somehow got blacklisted
<jam> I stopped sending directly from my home machine
<jam> because of blacklist sites that block whole ranges
<xif> jam: OK, so there's no technical reason to ever prefer C over Pyrex, but some people (at least one person) had a personal taste preference for C extensions, which is the only reason there are pure C extensions in Bazaar's codebase
<jam> xif: correct
<jam> There is only 1 pure C extension
<xif> jam: thanks, I'm a Python developer myself, so it's quite interesting.
<xif> Peng: afaik Cython was blessed as "production ready" only very recently.
<Peng> xif: Pure C is faster than Pyrex.
<xif> Peng: as fast or faster :P
<vila> jam: *your* actual IP is not blacklisted
<xif> I'm not an expert, but in many situations Pyrex should perform just as well as native C.
<Peng> xif: The number I've seen touted is that Pyrex is 75% as fast as C. Of course that will vary, but it'll always be faster. Pyrex will have extra ugly glue code, and pure C can be more carefully optimized.
<vila> they say the maximum block time is 24h. but you will get blacklisted again if you spam again ;-/
<Peng> So *that's* how bzr is funded!
<xif> Peng: yeah, basically Pyrex is a compromise between "down to the metal" C and "very high level" Python.
<Peng> xif: Right.
<xif> it's more high level than C, and sacrifices some performance for that.
<Peng> It's not just that it's more high level, but that it's a translator.
<xif> anyways, eventually PyPy would implement some cutting-edge JIT, and we'd all get pure-C performance with pure Python ;-)
<Peng> Well, I guess it is that it's high-level.
<Peng> xif: Will that be after PyPy stops being way more complex than CPython?
<jam> xif, Peng : well I hand-optimized my Pyrex work by looking at the generated C code
<xif> no, that would never happen :-)
<jam> so you can see places where you are being silly
<jam> and making it go through getattr() when it doesn't need to
<vila> jam: they say they don't use any public RBL, only internal data, does your provider give you dynamic IPs ?
<xif> jam: interesting. btw have you considered taking advantage of Pysco?
<vila> jam: hey, lazy guy try that: http://postmaster.free.fr/index_en.html
<jam> vila: my IP is static, but I send through my ISP, because apparently there are blacklists that block the whole range of MediaCom client IPs
<jam> xif: One issue with Psyco is that it doesn't save any state
<jam> so it has to JIT every time you run 'bzr'
<jam> rather than doing it in advance
<jam> so JIT in general isn't great for short-lived programs
 * xif nods
<xif> which is sort of what something like bzr is about.
<xif> frequent, short runs.
<jam> vila: so probably someone else behind my ISP is spamming, and it makes us all look bad
<vila> jam: sounds like your neighbours are either spammers or zombies :-/
<jam> vila: the relay host seems to be: 207.115.20.71
<jam> But that isn't listed in the RBL either
<jam> vila: I just forwarded the message through smtp.google.com hopefully that gets through
<vila> jam: still nothing, what I did get was through the mailing list though
<vila> jam: err, no, I did get your mail about #175866 directly, not though the ML
<vila> so the one you sent Date: Thu, 13 Dec 2007 10:07:21 -0600 didn't get blocked
<jam> vila: did you get the BB:approve one?
<vila> jam: no
<jam> that must have been the blocked one
<jam> I guess free.fr doesn't want your patch merged
<vila> lol, I can see the vote on BB anyway ;-)
<jam> Maybe they don't support range requests
<jam> and they don't want Bazaar to reveal that
<vila> I replied to your email, if you think pycurl should emit the warning too, I'll file another bug, there is a fix that is 1.0 worth IMHO, let's bikeshed on the warning without blocking it ;-)
<vila> jam: the one via google just arrived
<jam> vila: well, you have to get approval from poolie to get it into 1.0
<jam> But I'm happy with it for bzr.dev
<vila> jam: that's how I understood it, thanks for confirming
<vila> jam: did you notice you have a bunch a branches in error: https://code.edge.launchpad.net/~jameinel
<Peng> vila: His net connection was too slow for a while, or something.
<jam> vila: no I didn't I blame mwhudson
<jam> On the plus side, I think 1.0rc3 has been merged into LP now
<jam> so it should have vila's readv fixes
<vila> Peng: mwhudson ate his bandwidth but I think it was only once ;-)
<vila> jam: I pushing a new pack branch with bzr+ssh and my network perfmeter is quite flat, may be a similar fix should be applied there too :-/
<vila> LP still doesn't use shared repos isn't it ?
<jam> vila: it is for any newly registered branches
<vila> bzr push trigger the registration ?
<jam> inventory.knit is too big for my bandwidth
<jam> versus the LP timeout
<jam> vila: I use my "bzr-register" plugin, which is a wrapper around bzr register-branch
<vila> argh, they lied to us, gollum, I'm pushing at ~100KO/s damn perfmeter
<jam> So doing a bugfix branch is
<jam> bzr cbranch ../bzr.dev foo_XXXXX
<jam> cd foo_XXXXX
<jam> bzr reg --bug XXXXX
<jam> vila: 100 Knock Outs per second? Damn you're good
<jam> It means Launchpad periodically destroys my upstream bandwidth
<jam> but usually it doesn't have a horrible amount to upload after the first time
<jam> vila: LP does *not* use shared repositories yet, I believe that and/or shallow branches are marked as to-be-done by the March/April timeframe
<vila> ho, so LP pull from you ? What not using just bound branches then ?
<vila> hehe, you scared him ;-)
<jam> vila: LP pulls from me because I don't want to pay the cost of uploading every time I "bzr commit"
<jam> And I certainly don't want to have to wait for "bzr branch" to finish before I start working on a bug
<jam> So I use a bound branch to my local server
<jam> and let LP know about it
<jam> While it may be slower than some other possibilites
<jam> it takes less of *my* time
<jam> (The fastest being ssh foo.canonical.com, bzr push bazaar.lp.net/~jameinel/, and then doing a checkout or something from there)
<jam> The other problem is that you can't turn a hosted branch into a mirror
<jam> So I can't go pre-seed the branch I'm about to have mirrored.
<vila> jam: stop, you scare them all !
<vila> jam: joking, interesting setup
 * jam => tries to get real work done :)
<jam> It is funny, I pretty much never use "bzr push"
<jam> I keep forgetting I have a "dummy" post-push plugin that I was using to debug writing one
<jam> So when I finally do use "bzr push" it chatters on my terminal
<vila> hehe
<vila> I use push to create branches on launchpad, for my other uses I use bound branches and just commit/update
<jam> vila: weird... it seems that if I use smtp.google.com as my SMTP server, it rewrites the From address
<jam> so that it comes from my gmail account
<jam> rather than the account I'm claiming to send it from
<jam> So my post gets blocked to the ML
<jam> and you replied to my gmail account.
<jam> I suppose that is their anti-spam measure
<jam> mwhudson: I understand why LP was failing to mirror my newly registered branches, but do you know why it is failing to update branches I already had?
<jam> I suppose I upgraded from Branch5 to Branch6 for a lot of them
<jam> Maybe that triggers them to be newly copied from scratch.... :(
<jam> maybe that is why my pings have become so bad lately
<mwhudson> jam: that might do it
<mwhudson> jam: it should be better now
<jam> mwhudson: https://code.launchpad.net/~jameinel/ shows an awful lot of failed branches
<jam> But I did try to refresh them all
<mwhudson> yes, that would probably trigger complete re-mirroring
<mwhudson> 'refresh' ?
<jam> Well the "Try Again" button
<mwhudson> oh right
<mwhudson> when did you try that?
<jam> about 2 minutes ago
<jam> maybe 30
<mwhudson> probably still running then :)
<mwhudson> excuse slow responses, i'm on a damp-string internet connection here
<mwhudson> (in a pub :)
<jam> mwhudson: it won't try to re-mirror all of them at the same time, right? Just more of a sequential pwnage of my upstream bandwidth?
<jam> My ISP is probably going to ban me... :)
<mwhudson> jam: it can try up to 4 at once
<jam> hmm...
<mwhudson> jam: and indeed, seems to be trying 3 right now
<jam> I wonder if that will trigger the failures
<jam> Just thinking that my bandwidth is barely enough for 1-at-a-time
<mwhudson> would be surprised if it helped :)
<jam> But I guess if it has the progress updates
<mwhudson> it's still running 0.92 i think
<jam> mwhudson: well if it was smart enough to know it was requesting the *exact same* data 3 times
<mwhudson> jam: yeah, yeah, we know about that one
<jam> mwhudson: can you put a squid proxy in front of my URLs :)
<jam> *and* tell it to ignore the Pragma:no-cache
<mwhudson> jam: do all your work in checkouts bound to branches on rookery? :)
<jam> a) I sort of like knowing that all of my work is on my server
<jam> b) 100ms ping to rookery is still a little bit more painful than I want to pay for 'bzr commit'
<jam> I do direct checkouts for plugins to bazaar.lp.net
<jam> just not for bzr branches
<jam> glyph: it has been done
<jam> glyph: if you update your 'push-and-update' it should just trigger for any "bzr push"
<jam> Well, as long as the remote has a WorkingTree, and the remote is bzr+ssh or sftp
<Peng> Without doing any research myself, how consistent are revnos? When one, say, merges some-branch into bzr.dev, it'll get a new, dotted revno, but what happens when someone merges bzr.dev into some-other-branch? Does it change again? Sometimes, but not always?
<mwhudson_> jam: so sorry, didn't see anything after "(a)"
<jam> a) I sort of like knowing that all of my work is on my server
<jam> b) 100ms ping to rookery is still a little bit more painful than I want to pay for 'bzr commit'
<jam> Peng: merging won't change your local revnos
<jam> Peng: pull will
<jam> revno's are stable from the viewpoint of a branch
<Peng> jam: Err?
<Peng> (I am talking about over three different branches, not just 1)
<luks> well, revnos are relative to one branch, so it doesn't make much sense for 3 different branches
<jam> Peng: within 1 branch, revnos will stay fixed as long as you "merge" and not "pull"
<jam> The revnos you merge will change
<jam> so if it is 10 in branch A, merging that into B will give it a different number
<jam> (like 9.1.1)
<luks> speaking of revnos, is it intentional that some revisions ("tails") in e.g. bzr.dev don't have revnos?
<jam> luks: I'm not sure what you mean by tails
<glyph> jam: Awesome!
<jam> But the way the algorithm works, only revisions in the ancestry of a branch get numbers
<jam> It would probably be possible to pretend, but you have issues when multiple 'tails' descend from the same node
<jam> which one gets the '.1.' and which one gets '.2.'
<jam> We resolve that by which one is merged first
<jam> and if they have never been merged ....
<luks> jam, for graph like http://pastebin.org/11479
<luks> B won't be even mentioned in either bzr log or viz (not sure which one)
<glyph> jam: How do I enable it?
<luks> but it doesn't have a revno at all
<jam> glyph: You should just need to update it. If it is installed it will check on every push
<glyph> jam: Hmm.
<luks> because merge_sort won't include it in the resulting list
<jam> It does a quick check to see if the target is valid
<jam> luks: it won't be listed in log or viz
<jam> because it isn't in the ancestry of the branch
<glyph> jam: Aah, the UI is a tad confusing.
<jam> so it isn't "log" worthy
<jam> glyph: how so?
<luks> it's a parent of C, isn't it?
<jam> (you don't need to use push-and-update)
<jam> luks: it is a *child* of C
<glyph> http://pastebin.org/11481
<jam> well, depending on how you are graphing time
<glyph> "This transport does not update the working tree...", and then a message telling me it just updated the working tree :)
<jam> glyph: yeah, suppressing the "This transport" is hard
<jam> because that is being done inside "bzr push"
<jam> And I'm hooking after that
<luks> jam, in python tuple speak [(C, (A, B))]
<glyph> jam: OK, understood
<jam> luks: In that case B should get "0.1.1"
<glyph> jam: is there a way to turn this *off*?  There are definitely a lot of places I might want to push that would not take kindly to having a working copy created / updated
<luks> jam, but it doesn't
<jam> glyph: it won't create a WT
<glyph> jam: oh, okay.  It just updates it if it happens to be there?
<luks> jam, because merge_sort won't generate more than one revno for 0.something
<jam> glyph: right, you need to do your own "bzr checkout" if you want to enable it somewhere
<jam> luks: when Robert implemented it, you could have multiple from null:, and they would each get
<jam> 0.1.1 and then 0.1.2
<jam> or something like that
<jam> wait
<jam> 0.1.1 for the second branch, 0.2.1 for the third, etc
<luks> I think it's even mentioned in the docstring of merge_sort
<luks> that it won't be included
<jam> (the primary branch gets 1)
<jam> I'll check
<jam> luks: "Revisions not reachable from the tip" are not included
<jam> correct
<jam> You were saying "B" was a parent
<jam> not a child
<jam> luks: http://pastebin.org/11482
<jam> (When I draw graphs the first commit is at the top)
<luks> jam, one moment, I'll give you a real-world example from bzr.dev
<luks> it's actually your commit, if I remember correctly :)
<luks> jam, as an example - john@arbash-meinel.com-20051228204947-2fd81543e866350a
<luks> it's in the revision graph, but not in log
<luks> most of these http://pastebin.org/11483
<luks> well, except one
<Daviey> jam: I've just come back to it, upgraded bzr - same result!
<jam> luks: I think that is actually because they are ghosts
<jam> aka, revisions which are mentioned but not actually present
<Peng> How do you get ghosts?
<luks> no, they are present
<luks> and it's also in the ancestry of the tip
<luks> but not mentioned in the log, because merge sort won't generate 0.2.x
<luks> Peng, I don't think you can with the current version of bzr
<jam> glyph: I went ahead and created a monkey-patch, try updating again and testing it
<jam> Now it should suppress that ugly warning message
<jam> and just give you an update
<jam> glyph: http://pastebin.org/11485
<jam> luks: it works here
<jam> http://pastebin.org/11486
<jam> That actually isn't a ghost
<glyph> jam: ...
<jam> it is a plugin that got merged into bzr core
<jam> glyph: ???
<glyph> jam: I am in awe.
<jam> glyph: the power of python monkey patching
<glyph> jam: OK now that you ruined the trick I'm a tiny bit less in awe.
<glyph> jam: but your responsiveness is still legendary :)
<jam> luks: so is it a problem with "bzr viz" ?
<jam> Because "bzr log" seems to display it without any problems
<jam> Peng: it is really hard to get ghosts in current bzr
<luks> jam, umm, sorry, I was probably the old viz
<jam> The converter from Arch => bzr can generate them
<luks> I was just playing with a new graph view for qlog, and some revisions were missing
<jam> because Arch could reference nodes that it didn't actually copy locally
<luks> but I can't seem to reproduce it now
<jam> The nodes in Bazaar which are actual ghosts
<jam> are because our original merge code
<jam> would reference them
<jam> but not fetch them into the local repository
<jam> I think there are about 2 of them
<jam> both with my name on them
<jam> because I nuked my copy once Martin had merged it
<jam> (i haven't done that since :)
<ricardokirkner> hi again. I have created two bzr branches from a svn repository, 1 for the trunk and 1 for a branch. now I want to merge my bzr trunk (corresponding to the svn trunk) with my bzr branch (corresponding to the svn branch) , but I get an error that 'branches have no common aancestor'. Even if I specify a revision with the -r flag, it doesnt work. is there anything I can do to work around this?
<luks> are these created using bzr-svn?
<ricardokirkner> yes
<jam> ricardokirkner: you *can* use "bzr merge -r 0..-1", but I have the feeling it might be sub-optimal for what you want
<jam> The '0' is the secret way of telling Bazaar that you really do want to merge 2 projects together
<luks> hm, it's weird that bzr-svn created them without a common ancestor
<ricardokirkner> although, I think I just found out how... it apparently merged with -r 0..n (last revision)
<jam> But it sounds it is going to do things you don't like
<luks> maybe you had your svn branching scheme wrong?
<luks> (I mean the branching scheme set in bzr-svn)
<ricardokirkner> no idea... what do you mean?
<dato> luks: are you positive that bzr-svn is able to detect merges when importing?
<jam> dato: it should be able to detect *branches*
<jam> which gives you a common ancestor
<dato> er, right
<dato> I got confused
<luks> ricardokirkner, see bzr help svn-branching-scheme
<dato> jam: btw, I think a NEWS file in push-and-update could be helpful for people to notice this important change (cheers for it, too)
<jam> I've never been big on that sort of thing
<jam> "bzr log" if you want to know what has happened :)
<jam> I suppose next you'll be asking me to create a setup.py so it can be bilt
<jam> built
<jam> and installed
<LarstiQ> why, what an excellent idea :)
<jam> As always.... Patches welcome
<jam> And if you are going to do it, I suppose a README is in order, too
<dato> heh. well, it was just a suggestion :)
<ubotu> New bug: #176184 in bzr-eclipse "check in the whole branch and not just the current selected file" [Medium,Confirmed] https://launchpad.net/bugs/176184
<Daviey> jam: regarding the earlier problem - if i rm a "-" from the path it works fine, but with it there no mail?  any ideas
<jam> "with it there no mail" ?
<jam> Why is there a '-' in the path?
<jam> Anyway, something sounds fishy.. Daviey, can you send me your .conf files?
<Daviey> jam: v. basic conf files
<jam> well, I can say that *I* haven't had any problems with bzr-email not sending in directories I have configured it to send from
<Daviey> pm them?
<jam> So I'm trying to see what the difference would be
<jam> Daviey: pm or email
<Qhestion> hi. i can import bazaar classes via for example: "from bzrlib import workingtree". there is a file named workingtree.py. but how does Bazaar do this? i mean, i thought workingtree.py means i have to write "from bzrlib.workingtree impor workingtree" ??
<Qhestion> i am trying to do the same in my program, but i just dont get it to work. how does bazaar do this?
<jam> Qhestion: "from bzrlib import workingtree" imports the "workingtree" module
<jam> to get the class you need either
<jam> "from bzrlib import workingtree; workingtree.WorkingTree"
<jam> or
<jam> "from bzrlib.workingtree import WorkingTree"
<Qhestion> the thing is, "from bzrlib import workingtree" works.
<jam> (note that we capitalize classes, but tend to use lowercase for modules)
<Qhestion> dont know how, it just works
<jam> Qhestion: you have a valid module
<Qhestion> ?
<jam> python -c "from bzrlib import workingtree; print workingtree"
<jam> <module 'bzrlib.workingtree' from 'bzrlib/workingtree.py'>
<jam> python -c "from bzrlib import workingtree; print workingtree.WorkingTree"
<jam> <class 'bzrlib.workingtree.WorkingTree'>
<Qhestion> <module 'bzrlib.workingtree' from 'C:\Python25\lib\site-packages\bzrlib\workingt
<Qhestion> ree.pyc'>
<jam> Qhestion: right, that is a *module* not a class
<Qhestion> (output for first command)
<Qhestion> oh wait
<Qhestion> i am stupid
<radix> Qhestion: there is a class named WorkingTree inside the bzrlib.workingtree module
<Qhestion> i should have read the next line more carefully
<Qhestion> all my fault
<Qhestion>    1 from bzrlib import workingtree    2 wt = workingtree.WorkingTree.open('/home/jebw/bzrtest')
<Qhestion> http://bazaar-vcs.org/Integrating_with_Bazaar
<radix> hooray documentation :)
<Qhestion> i think i overlooked the "workingtree." part...
<Qhestion> i think i just saw what i WANTED to see
<Qhestion> hmm.. anyway, i think pythons module system is crap. i think it would be better if all the modules  in a package would get accumulated and... one big module
<jam> Qhestion: when you get used to it... the namespaces are *wonderful*
<Qhestion> nothing against namespaces
<jam> Something I actually miss a lot with C/C++
<Qhestion> but i dont like 5kLine source files...
<Qhestion> anyway. hmm i remember reading your name somewhere...
<Qhestion> radix, jam, any chance you are also active in the storm channels?
<Qhestion> i think i read some chatlog on that website...
<jam> Qhestion: radix might be, I'm not
<jam> Qhestion: you might be thinking jamesh
<radix> Qhestion: yeah, that's me :)
<jam> radix: you work on Landscape, and thus storm, right?
<radix> jam: yep.
<jam> twisted little man
<jam> :)
<jam> Well, you aren't *that* little
<jam> but shorter than I
<jam> I think
<radix> Qhestion: You can put a bunch of names in one place if you want to, even without having 5klines of source file. Python's module system isn't crap for the reason you think it is, anyway :)
<radix> jam: Yeah, and Twisted ;-)
<radix> jam: probably :-)
<Qhestion> radix: well, this is just what you think after using python for half a year. i think i still have to learn a lot...
<Qhestion> anyway, it is MUCH better than java
<Qhestion> although until yesterday i said otherwise
<radix> heh :)
<Qhestion> i used java in a contest
<Qhestion> yesterday.
<Qhestion> crap.
<radix> sorry. :)
<Qhestion> ?
<Daviey> jam: hmmpf, i've upgraded, same problem! :(
<jam> Daviey: care to do some manual debugging?
<jam> You can look at bzrlib/config.py
<jam> Around line 506
<Daviey> will do
<jam> there is "_get_matching_sections"
<jam> which is the part that should match the path for the branch
<jam> with the config entry
<Daviey> I guess: /usr/share/pycentral/bzr/site-packages/bzrlib/config.py
<jam> Daviey: sounds correct to me
<Daviey> def _get_matching_sections(self): -- nothing looks bad
<dennda> hey there
<dennda> I have a branch 'experimental' from 'trunk'. I did bzr merge $trunkurl and it says my experimental branch is up to revision 63. trunk, however, is 70. what's the problem there? how can I fix it?
<Peng> dennda: Look at bzr log. Is everything there?
<dennda> https://code.launchpad.net/memaker/ <-- the projects branches
<jam> dennda: 'bzr merge' will create a  new revision at the tip.
<jam> Which is likely to be '64'
<Peng> dennda: Did you commit after the merge?
<jam> "bzr pull" will pull over and change your history
<jam> to look like the source branch
<lifeless> moin
<jam> which will make it "70"
<jam> morning lifeless, I thought you were on vacation
<jam> just can't stay away, can you?
<Peng> Will it merge when it's not necessary?
<lifeless> jam: I am :)
<dennda> Peng: bzr log shows me 63 as latest revno
<Peng> dennda: Did you commit after the merge?
<lifeless> jam: I'm grabbing a drink an dlogging into WoW :). Level 64 now.
<Peng> dennda: What is revision 63?
<jam> lifeless: congrats
<Peng> dennda: Not a merge?
<dennda> yes
<jam> lifeless: enjoying outland?
<dennda> yes, i committed
<dennda> to 64
<dennda> just now
<Peng> dennda: You committed the merge?
<Peng> dennda: Then everything's there.
<Peng> dennda: It's all listed under revision 64.
<dennda> ok
<Peng> (That is, the merged revisions are all listed under revision 64.)
<dennda> so rev numbers don't have to be identical?
<Peng> They do not.
<dennda> ok
<dennda> thank you
<Peng> (FWIW, bzr internally uses much longer, less readable IDs. The simple numbers are just for user convenience.)
<lifeless> jam: yah, starting zangarmarsh today, finished hfp last night. I'm about 70% to 65 :).
<lifeless> ANd with that, ciao :)
<Peng> Me too.
 * Peng wanders off.
<dennda> bye
<jam> everyone is leaving me
<jam> lifeless: I forgot to ask, what class is your main? (obviously it can wait :)
<ubotu> New bug: #176191 in bzr-eclipse "Change "Username" field to "Email"." [Undecided,New] https://launchpad.net/bugs/176191
<newz2000> I have a web application I work on with someone else. What's the best way for me to publish my application to the webserver from my development workstation?
<newz2000> My first attempt was to bzr push it, but that just copied the trunk/.bzr stuff.
<newz2000> Is rsync the right tool, or is there a way to do it with bzr?
<jam> newz2000: install my plugin
<Odd_Bloke> newz2000: Check out the push-and-update plugin.
<jam> https://launchpad.net/bzr-push-and-update
<jam> after you do "bzr checkout" on the server
<jam> from then on when you do
<jam> bzr push
<jam> it should make sure the target is updated
<jam> Odd to have you mention this about 2 hours after I finally got around to cleaning up that plugin.
<newz2000> ok. Now, the one problem is that the server can't do a bzr checkout, because it can't see the place where I normally push to.
<newz2000> well, I could push twice I guess
<jam> newz2000: once you have done a "bzr push"
<jam> then you do
<jam> ssh server
<jam> cd path
<jam> bzr checkout .
<newz2000> oh, interesting
<jam> newz2000: from then on, 'bzr push' should do the "ssh server bzr update path" for you
<jam> (with the plugin installed)
<newz2000> so where do I install the plugin, on my local pc?
<jam> newz2000: correct
<jam> newz2000: are you on linux?
<jam> cd ~/.bazaar/plugins
<jam> bzr checkout lp://bzr-push-and-update push_and_update
<jam> bzr checkout lp:bzr-push-and-update push_and_update
<jam> sorry, I get used to typing 2 //
<jam> you either need 0 or 3
<newz2000> fascinating. So I'm working on a tmp checkout... if I kill this and later push to the same location from another checkout, does it remember to update the server?
<jam> newz2000: it just hooks into the "bzr push" code. And if the target has a working tree
<jam> it will update it
<jam> So by doing "bzr checkout" you tell my plugin that you want to keep it updated
<newz2000> cool. Giving it a shot now.
<newz2000> ok. Everything seems to have worked, but I won't know until I have some code to change. :-)
<newz2000> thanks jam. Your my hero. If you're in IA between xmas and nye you can come to my hackfest.
<jam> newz2000: it should say: running command "ssh ..."
<jam> If it says that, then I think it is working
<jam> newz2000: what hackfest?
<jam> I will be in IA, though I may not be close to Des Moines
<newz2000> I'm going to be nostalgic and try to have a programming party at my house
<newz2000> like the good ol' days. Coding for sheer pleasure
<newz2000> your plugin worked. It ran ssh.
<igc> morning all
<devinus> how do i set up ignore options for bzr?
<jam> devinus: "bzr ignore PATTERN" ?
<jam> or what do you mean by "options" ?
<devinus> it takes globs?
<devinus> i want to ignore all *.pyc
<Odd_Bloke> devinus: bzr ignore "*.pyc"
<Odd_Bloke> Note the quotes. :)
<devinus> oh wow
<devinus> i see i could of just done
<devinus> bzr help ignore too
<devinus> thanks!
<jam> devinus: I thought .pyc was in our default global ignores...
<jam> Anyway you may want
<jam> bzr ignore "*.py[co]"
<jam> Since you really want both to be ignored
<jam> Though you may not run "python -O" very often
<SmileyChris> i'm always getting the error "bzr: warning: unsupported locale setting (...)"
<Odd_Bloke> SmileyChris: Are you on Windows or GNU/Linux?
<SmileyChris> Odd_Bloke: sorry, clarification - always getting when using sftp/bzr+ssh
<SmileyChris> Odd_Bloke: linux
<jam> SmileyChris: sounds like LANG on your other side is set in a funny way
<jam> LANG=C
<jam> or LANG=en.UTF-8 should be decent
<jam> I don't know why you would get it when using sftp
<jam> bzr+ssh is spawning a remote process
<jam> which could certainly be having troubles with the LANG on the remote side
<SmileyChris> jam: seems like it can't pick up en_NZ.UTF-8
<jam> SmileyChris: well, that should be valid, but you may need to have the right locale files installed
<SmileyChris> jam: on the remote side?
<jam> SmileyChris: if it is only happening when you use bzr+ssh then I think it is the remote side which has the problem
<jam> can you just do
<jam> ssh host locale
<jam> ?
<SmileyChris> from local or remote?
<jam> ssh remote locale
<SmileyChris> ah :)
<jam> If running "bzr rocks" doesn't give you a locale warning
<jam> then it is the bazaar on the remote machine which is giving the warning
<SmileyChris> it's the remote giving the warning
<SmileyChris> just tested
<SmileyChris> jam: you want the output of locale?
<igc> poolie: can I please tweak 1.0 with abentley's changes to 'avanced merging'?
<jam> SmileyChris: I don't specifically need it, but I'm just trying to help you track down the problem
<jam> it sounds like the *remote* machine doesn't have the lang set
<jam> properly
<jam> interesting
<jam> if I do "ssh host locale"
<jam> I get a different result than
<jam> ssh host <enter> locale
<jam> is "ssh host COMMAND" passing through the local LANG?
<SmileyChris> jam: it seems to be using my local $LANG setting
<SmileyChris> running locale.getpreferredencoding() on remote python raises error
<SmileyChris> (local is fine)
<SmileyChris> this is really only a minor annoyance - it's only a warning (and falling back to use ascii instead of unicode), but still ;)
<jam> SmileyChris: you might try doing something with SendEnv in ~/.ssh/config
<jam> but I haven't figured out why it would be triggering yet
<SmileyChris> jam: is there just some way to make my en_NZ locale work on remote? :P
<jam> SmileyChris: well, you could just install the same package
<jam> I see a "language-pack-en-base"
<jam> But I don't know if that installs en_NZ
<jam> I'm guessing it does, since it seems to exist here
<jam> and I don't have much extra installed
<SmileyChris> jam: holy moly that's a lot of dependencies though
<SmileyChris> bah
<SmileyChris> maybe i'll just live with the warning
<SmileyChris> wants to install firefox and open office on the server
<jam> A lot of dependencies for "language-pack-en-base" ?
<jam> weird
<jam> Let me check something
<jam> dang
<jam> % dpkg -S /var/lib/locales/supported.d/en
<jam> language-pack-en-base: /var/lib/locales/supported.d/en
<jam> I'm guessing it provides the language translations for things like openoffice and firefox
<jam> but it seems like it should be more of:
<jam> If program X is installed, provide the language pack for it
<jam> Not "when providing *any* language support, install all programs which might use it."
<Odd_Bloke> SmileyChris: Are you using 'apt-get' or 'aptitude'?  If the latter, it may be trying to install things on which it does not depend...
<Odd_Bloke> Assuming you're using a Debian-based system at all. :p
<radix> I thought you just had to build the en_NZ locale, not install the language-pack.
<jam> recommends versus depends?
<jam> radix: well my  /var/lib/locales/supported.d/en has en_NZ
<jam> and I don't see a separate package for it
<SmileyChris> Odd_Bloke: i was using latter... (ubuntu)
<radix> lthough, yeah, language-pack-en-base does not depend on firefox or openoffice or anything like that, on my system.
<jam> anyone better at parsing the output of "apt-cache showpkg" ?
<Odd_Bloke> SmileyChris: http://packages.ubuntu.com/gutsy/translations/language-pack-en-base suggests that it _recommends_ language-support-en, which then depends on the Firefox and OO stuff.
<radix> jam: uh, yeah, if you're using showpkg you're probably looking at *Reverse* Depends.
<Odd_Bloke> So I suggest trying again with 'apt-get'. :)
<jam> http://rafb.net/p/cAOXar16.html
<SmileyChris> Odd_Bloke: ah...
<jam> Reverse Depens
<jam> Depends, seems to list -pack-kde-en and -pack-gnome-en
<SmileyChris> Odd_Bloke: it's a depends on mine
<radix> jam: yeah, I guess that's what it looks like here, but nowhere do I see dependencies on actual software like firefox or openoffice or any gnome apps
<bccomm> is en_NZ checked if you do dpkg-reconfigure locales ?
<SmileyChris> Odd_Bloke: I was wrong. It was the language-support-en *recommends* causing the bloat :P
<SmileyChris> all working now, thanks for your help guys
<SmileyChris> (specially since it wasn't really a bzr problem)
<igc> poolie: those doc tweaks sent to pqm now
<igc> (for 1.0, not bzr.dev)
 * igc breakfast
<igc> poolie: 3105 needs to be cherrypicked from bzr.dev into 1.0
<igc> it's definitely not there yet
<igc> just confirming you're going to do that
<poolie_> igc, thanks, doing that now
<igc> great. thanks
#bzr 2007-12-14
<abadger1999> hmmm... is there a common misconfiguration that can cause bzr push bzr+ssh://[..] to start up a bzr smart server listed in inetd?
<jam> abadger1999: IIRC, bzr+ssh:// spawns a "bzr serve --inet ..." to tell the bzr serve process to communicate on stdin/out rather than starting a TCP server.
<jam> It is just a flag.
<abadger1999> ah.  Okay.
<jam> Otherwise you would have to have inetd configured to connect to port 22 or so.
<abadger1999> So I'm seeing something else.
<abadger1999> Right now when I do bzr push, I am told that there's a lock already on the repo.
<abadger1999> If I stop the request, kill the bzr server, and bzr break-lock on the remote repo and try again I get an exception: TooManyConcurrentRequests:
<jam> hmm... I'm not sure about the TooMany...
<jam> but it is a known bug for having to run "bzr break-lock" 2 times
<abadger1999> Okay.  So I should try running break-lock twice in the repo and see if it works?
<jam> abadger1999: yeah
<jam> the service that is still running is waiting to grab the lock
<jam> so you want to break the lock, let it grab it, and then break it again
<abadger1999> If I check and make sure that bzr serve isn't running on the server, that should be good too, correct?
<jam> it *should*
<jam> But you may need to break the lock after you ensure that
<abadger1999> Okay.
<abadger1999> So that takes care of the locks but I get the exception again: TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x2aaab23b8790>'
<jam> abadger1999: first, make sure sftp:// still works
<jam> bzr log sftp://... is usually what I use
<jam> (I wonder if you aren't mis-typing the host)
<abadger1999> sftp won't work.
<abadger1999> We have ssh access but not sftp.
<jam> really, that is uncommon
<abadger1999> Here's the full traceback: http://pastebin.ca/815408
<abadger1999> It's for security reasons on this host.
<abadger1999> ssh is locked down to only allow certain SCMs to be run on certain directories.
<jam> abadger1999: well 0.91, I believe, didn't have the fixes to get better errors
<jam> but it sure looks like the connection is closing down too quickly
<abadger1999> Will the bzr on the repository leave better information?  Or do I need to update the clientside to get better errors?
<jam> actually, it looks like the server side is dying
<jam> #
<jam>   File "/usr/bin/bzr", line 117, in ?
<jam> #
<jam>     sys.stdout.flush()
<jam> #
<jam> ValueError: I/O operation on closed file
<jam> ^- That looks like the server side is trying to flush
<jam> (flush stdout)
<jam> but it has already closed
<jam> I could be wrong.
<jam> abadger1999: the client is generating the local traceback which is confusing because you aren't getting ConnectionClosed
<jam> (instead you are getting TooMany...)
<abadger1999> jam: here's the .bzr.log from the server: http://pastebin.ca/815414
<abadger1999> jam: Interesting.  So it's something about the particular set of changes that I'm attempting to push that's causing this.  I made a new branch of the repo and was able to make a trivial change and push that back to the server.
<jam> that is strange
<jam> I'm afraid I'm not really sure what is going on off-hand
<jam> I can come back to it tomorrow if you are still running into it
<abadger1999> Should I make copies of my local and remote repositories for you guys before I try harder to fix this?
<spiv> abadger1999: Perhaps try running the client with "-Dhpss", to put more debugging in the .bzr.log.
<spiv> abadger1999: although I'm not sure it'll reveal much in this case
<jam> you can, it seems more like just upgrading to something newer than 0.91 would also be a good step
<spiv> I'd definitely try upgrading, yeah.
<abadger1999> spiv: hpss shows the same thing.
<abadger1999> Interestingly, the remote repo has now diverged from my local one so whatever is happening happened before that check is performed.
<abadger1999> Creating a 1.0rc3 package for this box now.
<abadger1999> spiv, jam: More output but same error with 1.0rc3:  http://pastebin.ca/815439
<spiv> abadger1999: could you try "bzr -Dhpss push", and pastebin the relevant ~/.bzr.log excerpt that it generates?
<abadger1999> spiv: http://pastebin.ca/815446
<spiv> abadger1999: Hmm, so it successfully takes a lock on the repository, but fails on the first operation that actually tries to write to the repo.
<Peng> What's with the TooManyConcurrentConnections exceptions? It happens a lot, when it doesn't make sense.
<spiv> Peng: the smart client is a bit too easily confused when something unexpected happens.
<Peng> Like the TooMany... exception is in an "else:" or something.
<spiv> Peng: not quite
<spiv> Peng: for instance, what's happening here I think may be an error response to the 'append' call that the client doesn't expect.  The relevant function raises an error, and that triggers a "finally: foo.unlock()" somewhere.  But the previous request/response pair hasn't been fully read from the wire.
<spiv> Peng: so TooManyConcurrentRequests gets raised.
<abadger1999> Another data point -- I created a fresh branch in a non-repository location and merged the changes from the old local branch to the new local branch.  bzr commit and then bzr push.... the push fails in the same way.
<Peng> spiv: Oh. Requests. As in trying to do things at once. Ok.
<Peng> s/do/do two.
<Peng> /
 * Peng can't type.
<spiv> abadger1999: hmm!
<spiv> abadger1999: the permissions on the server-side seem normal?]
<abadger1999> spiv: Yes and I have pushed a small change from a fresh branch since the problem started.
<spiv> So it's something weird about that data.  Hmm.
<abadger1999> Let me try a small change to the particular file that seems to be failing.
<abadger1999> spiv: Ah ha!  it is a permissions problem.
<spiv> abadger1999: oh ho!
<abadger1999> It looks like the smart server doesn't set the sticky group when it creates a fresh directory in .bzr/repository/knits
<abadger1999> So I suppose the question is whether it's supposed to or not.  I know sftp was broken in this regard but thought the smart server was supposed to fix this.
<spiv> The smart server doesn't explicitly set a umask.
<spiv> So it will be inheriting whatever the default is I guess.  If the mkdir from the client side specifies a mode it should respect that though...
<abadger1999> Well, umask should be 0002
<spiv> abadger1999: http://pastebin.ca/815459 is the logic that should be used to choose the mode it uses
<abadger1999> Well, that should find the correct mode.
<spiv> Yeah, I think so too.
<spiv> abadger1999: could you run a "bzr -Dhpss ..." that tries to create the .bzr/repository/knits directory, so we can see what mode the client asks for?
<spiv> e.g. push to a new location outside of a repo should do it.
<abadger1999> spiv: http://pastebin.ca/815470
<abadger1999> We have to setup our repos with the sticky bit ordinarily though.
<abadger1999> Want me to also push to an empty repo with the sticky group bit set?
<spiv> Hmm!
<spiv> For reference, the modes are sent in decimal over the wire for some reason.
<spiv> 'mkdir', '/var/tmp/python-fedora-devel/.bzr/repository/knits', '509'
<spiv> That's 0775
<spiv> So the client is choosing the wrong mode it seems.
<poolie> igc, hi
<igc> hi poolie
<poolie> someone pointed out that many links in http://bazaar-vcs.org/BzrUserGuide
<poolie> are broken
<poolie> can i just remove it now?
<poolie> and redirect to the doc site?
<igc> yes please
<poolie> hm
<abadger1999> spiv: Hmm.... but don't I need to have a directory or repository on the server that has the sticky group bit already set?
<spiv> abadger1999: yes
<poolie> spiv,  do you know anything about pqm
<poolie> just for the guy asking on the list?
<poolie> it's older than i am
<poolie> at least, at canonical
<abadger1999> I just set up a repository with permissions the way we set them up on the server and pushed to that.  That created a pack branch on the server instead of dirstate-tags but it set the sticky bit correctly.
<spiv> abadger1999: Oh right, I see in that log the directories that bzr stat'ed didn't have sticky bits either.
<abadger1999> Can I force it to use dirstate instead of pack when pushing to the remote repo?
<abadger1999> Actually... I should be able to test this by creating a file and committing to the old repository right?  It'll create a new knit for the new file?
<spiv> That's right.
<abadger1999> spiv: Well... that was successful too.  I wonder if the person that committed the file is using a version of bzr with a bug (since fixed)
<abadger1999> by successful I mean the new knit has the sticky group bit set.
<spiv> abadger1999: yeah, I wonder that too.
<abadger1999> Looks like that dev has gone home for the day.  I'll play around and see if I can find the problem version.  Hopefully it's something truly ancient :-)
<spiv> poolie: Hmm, I don't know much about the nitty gritty of configuring it
<poolie> igc, is there anything else to merge for 1.0?
<igc> rst2html?
<poolie> i have your cherrypicked fix for the download location
<igc> it was from data actually
<igc> s/data/dato/
<poolie> well, rather the one you reminded me about
<ubotu> New bug: #176263 in bzr "bzr rm \\ crashes with IndexError" [Medium,Confirmed] https://launchpad.net/bugs/176263
<igc> poolie: looks like the rst2html fix is in 1.0 but not bzr.dev yet
<poolie> ok
<poolie> right, i'll merge back to dev soon
<poolie> after the final
<igc> sure
 * igc lunch
<poolie> ok, starting on the release now
<MattCampbell> Is it feasible with Bazaar to combine the contents of multiple repositories into one, or split into multiple repositories?
<MattCampbell> It doesn't seem possible to do this kind of reorganization with SVN without losing history.
<poolie> can you explain more about what you want to do?
<Peng> If they're two related branches, absolutely.
<MattCampbell> I have two scenarios in mind.  First, suppose that I'm working on a large project, and I've developed a module as part of that project that is more widely useful, so I want to split it off without losing history thus far.
<MattCampbell> Perhaps the larger project is proprietary, but I want to release the module as open source.
<poolie> ok
<poolie> so, bzr split helps with this
<poolie> however, it'll still have a link back to the previous history
<fullermd> Splitting is harder than combining.
<poolie> and often if it was previously proprietary, people will want to make sure that's not exposed
<MattCampbell> So if I think it might be desirable to release a piece of code as open source, then I should develop it in its own branch from the start.
<poolie> yes, i'd recommend that
<poolie> not just for vcs reasons, but also so you can be clear about what should or shouldn't be included in it
<poolie> and what dependencies it can have on other things, or vice versa
<MattCampbell> Now for the other scenario:  Suppose I have two different source trees "foo" and "bar", and I want to create a new bzr repository with these formerly separate trees as subdirectories (initially; once there's just oen tree, things can be moved around at will).  Can I do this while preserving the two histories thus far?
<poolie> yes, bzr join does that
<poolie> i should mention that this feature still has some rough edges
<poolie> but if you want to give feedback and report some bugs, that would be great
<MattCampbell> Thanks.  I'm evaluating bzr for use in a proprietary project that, to my shame, has not used any VCS at all thus far.
<MattCampbell> though I've used CVS and SVN in some open-source projects.
<poolie> bzr will be great :)
<poolie> the amount of vcs knowledge needed is reasonably small...
<poolie> so my main advice with this kind of splitting and joining is,
<poolie> just to think about the issues beyond the vcs issues
<poolie> dependencies between code and so on
<poolie> keeping things separate is always easier than untangling them later
<poolie> (assuming of course you know what should be separated)
<poolie> btw, we just went 1.0!
<MattCampbell> darn, my rc3, downloaded less than 2 hours ago, is already out of date. :)
<poolie> there are no changes
<poolie> aside from some doc corrections
<poolie> but i'm happy to be here, i wanted to tell someone :)
<Odd_Bloke> poolie: Congrats! :)
<abadger1999> poolie: Woo hoo! Change the topic!
* poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.0 is out!
* poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.0 is out! woo!
<MattCampbell> Include the download URL.
<MattCampbell> tarball URL, rather
<Odd_Bloke> Moar bikeshedding! :D
* poolie changed the topic of #bzr to: http://bazaar-vcs.org/ | Bazaar 1.0 is out! woo! | http://bazaar-vcs.org/releases/src/bzr-1.0.tar.gz
<abadger1999> Excellent!
 * abadger1999 goes forth to make many many packages
<spiv> \o/
<poolie> ^5!
<fullermd> Hm.  Well, that answers one question at least.
<jml> wuuu
<fullermd> FreeBSD ports freeze ended earlier this week.  I wondered which would happen first; they'd get around to committing the 0.92 update I submitted during it, or 1.0 would come out.
<MattCampbell> Anyone here know how quickly a new Gentoo ebuild will become available?  How about a package for Debian Etch?
<poolie> i'm going to do a deb soon, which i hope will be buildable on etch
<MattCampbell> I've just started learning about Bazaar tonight.  I think it's killer feature is support for multiple workflows.  I'll probably start with the serverless solo workflow, then move to centralized with offline commits.
<poolie> i think so too
<poolie> you should check out ian's "adaptive vcs" paper
<poolie> if you have not already
<MattCampbell> URL?
<poolie> http://ianclatworthy.wordpress.com/2007/10/11/why-distributed-version-control-matters/
<poolie> hm
<poolie> http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf rather
<MattCampbell> Is the latter available in HTML?
<poolie> maybe if you ping igc
<MattCampbell> Never mind, I already have enough info to get started.  Thanks.
<poolie> you're welcome
<igc> MattCambell: would you like the OpenOffice original?
<MattCampbell> don't have OO installed; I would prefer a conversion to HTML.
<igc> no problem - I'll generate one
<Peng> Ooh! I didn't know log had a --limit arg! Hg does, but with a -l abbreviation.
<MattCampbell> (I have low vision, so I find HTML is easier to read in a large font or via speech synthesis if it's mostly prose. In case anyone was curious.)
<poolie> peng, want to patch it?
<poolie> except -l might be --long?
<Peng> Nope, no such option! :)
<Odd_Bloke> igc: If you make OO/text available, I'd be happy to make a LaTeX version.
<Odd_Bloke> I take a perverse pleasure in writing LaTeX. :p
<igc> Odd_Bloke: thanks. And good luck with that :-)
<Peng> I shouldn't suggest it for 1.0, should I?
<Odd_Bloke> Peng: It would be somewhat awkward to get it, if you examine the topic. :p
<Peng> Woah!
<Peng> I didn't notice!
<Peng> Awesome!
<Peng> Aww, I can't gpg-verify it. I can't get hkp keys.
<Odd_Bloke> igc: I will need it in some format other than PDF (as pdftotext gives me "^L^L^L^L^L" and nothing else which, while easy to typeset, does not produce the strongest argument for DVCS :p).
<MattCampbell> Why would you want to convert from ODF to LaTeX?
<Peng> Congratulations!
<Odd_Bloke> MattCampbell: Because ODF is fugly.
<fullermd> Oh, you know those LaTeX people.  Buncha cultists.  They're almost as bad as the DVCS freaks.
<Peng> packs, after repacking, in chronological order, in MB: 225, 11, 25, 78, 67.
 * Odd_Bloke is a terrible, terrible person^W^W^W both.
<Peng> I'm afraid to add that up.
<fullermd> Peng: I think these days, that's roughly 18 cents   ;)
<baijum> Congrats to all developers for 1.0 release !
<Peng> Yeah, but like 150 MB of that is from the last month.
<Peng> How are short names for args usually tested?
<baijum> Is there any press release for 1.0 release ?
<igc> MattCampbell, Odd_Bloke: My DVCS paper is now available in multiple formats here: http://people.ubuntu.com/~ianc/papers/
<igc> Let me know if there are any problems
<MattCampbell> Thanks.
<ubotu> New bug: #176284 in bzr ""bzr plugins" should also display the plugin search path" [Undecided,New] https://launchpad.net/bugs/176284
<MattCampbell> igc: One nitpick: The HTML version has no <title>
<igc> Damd OOo - I'll add one by hand
<igc> s/Damn/Damn/
<MattCampbell> Also I think it's best not to specify font family and size in the CSS; users who want your exact formatting can get the PDF.
<lifeless> glyph: bzr --version will tell you the search path
<lifeless> I think
<lifeless> hmm no. Well it should ;)
<glyph> lifeless: heh heh
<glyph> lifeless: well, *something* should, anyway - hence the suggestion ;)
<glyph> and hey, uh
<glyph> bzr: ERROR: Unrecognised value for BZR_SSH environment variable: C:/Program Files/Putty/plink.exe
<glyph> what's up with that?
<poolie> that's strange
<poolie> glyph, I believe you're meant to use that to just say what type of ssh you want us to use
<spiv> glyph: yeah, try just BZR_SSH=plink
<poolie> so try just using "plink"
<spiv> (and set your PATH appropriately, I guess)
<glyph> bleh
<poolie> that's kind of contradictory with how rsync and cvs use it
<spiv> Different SSH programs take different command line arguments, which makes DWIM a little awkward.
<glyph> I specifically *don't* have my PATH set, because I have 4 different plink.exe executables
<poolie> hm
<spiv> Possibily we should have separate BZR_SSH_EXE and BZR_SSH_TYPE variables.
<poolie> i'm filing a bug
<spiv> (Or maybe just rely on "if 'plink' in BZR_SSH:"?)
<poolie> yeah
<poolie> that should work
<spiv> For plink at least.  I don't think we can disambiguate OpenSSH's ssh from SSH Corp's ssh that way.
<ubotu> New bug: #176292 in bzr "BZR_SSH should allow setting the path to ssh, not just the kind of ssh" [Undecided,New] https://launchpad.net/bugs/176292
<poolie> glyph, ^^
<glyph> poolie: thanks
<poolie> subscribe if you like
<poolie> and please let us know if you hit something else
<poolie> s//anything
<Peng> With command arguments, are there unit tests for both --arg and -a or just one of them?
<poolie> it varies
<poolie> ideally, both would be tested
<poolie> there is some work in test.command (iirc) towards testing command line parsing separately from the code that actually runs the command
<Peng> I'm adding a -a for a command that already has a (tested) --arg already should I just add a new copy of the test, "test_command_arg_short" or something?
<Peng> Oops, erase one of those "already"s.
 * baijum just added release link to reddit: http://programming.reddit.com/info/62yy3/comments/ (I should have checked some other DVCS ;)
<poolie> oops
<poolie> but thanks for posting it there
<baijum> np
<ecognito> Hi.  If you have a shared repository that has been created with the --no-trees option, how do you figure out what it in there?  bzr ls only works on branches... I just have a folder with a .bzr sub-folder in it, but is otherwise empty...
<Peng> What?
<poolie> ecognito, try 'bzr info' on that directory
<ecognito> It just says it is a shared repository.  It doesn't tell me what working trees I could pull out of it.
<Peng> Ooh, I broke send!
<Peng> Oh, never mind.
<Peng> Well, send tracebacks when it's not in a branch, I guess.
<nhaines> Congratulations on version 1.00!
<poolie> thanks
<Peng> bzr send tracebacks when used outside of a branch -> known bug?
<poolie> i don't think so
<poolie> ok, i'm going to take a break
<poolie> See you later
<jml> poolie: cya
<jml> poolie: I'll hoist a pint for 1.0
<poolie> cheers
<poolie> me too
<Peng> I'll hoist a pint of...water, if I can find a large enough glass. :)
<ubotu> New bug: #176300 in bzr "bzr send tracebacks when used outside of a branch" [Undecided,New] https://launchpad.net/bugs/176300
<igc> thanks and congratulations to everyone involved in delivering 1.0
<igc> I'm off to celebrate my son's birthday so I won't be hanging around here tonight :-)
<igc> cheers everyone
<igc> night all
<nhaines> Good night and congrats, igc :)
<igc> thanks
<MattCampbell> What's the difference between "bzr update" and "bzr merge", aside from "update" being more familiar to CVS and SVN users?
<Peng> Using checkouts? I'm not sure.
<nhaines> I think update only pulls from the checked-out repository, whereas merge has a lot more options and you can merge from any other branch.
 * AfC never runs update and merge in the same branch
<AfC> In fact, I never run update, but that's another story.
<baijum> Hi AfC, during your FOSS.IN/2007 talk I installed bzr viz, and like it...thanks :)
<AfC> baijum: :)
<nhaines> I installed bzr viz just 30 minutes ago... and I like it.  :)
<nhaines> I'm still a little more used to Subversion... but I could hardly escape the allure of running a VCS written in Python...
<AfC> baijum: it's pretty sweet, although I've recently started realizing that what I really need is a unified cross between visualize, gannotate. I frequently find myself needing to study the evolution of code across revisions, and am trying to figure out what a UI to do that well would look like
<AfC> nhaines: who cares what it is written in?
<nhaines> AfC: I do, merely because I'm most proficient in Python and can therefore make changes and bugs if I need to.
<AfC> One would have thought that "whether it works correctly or not" would be a more important criterion. {sigh}
<nhaines> This is merely a secondary concern: if it didn't work, then of course it would have been right back to svn.  But being written in Python and used by some rather large projects was the draw.
<nhaines> Freedom 1 can't be underestimated.
<baijum> AfC, is olive does provide a single unified UI for all these functionalities ?
<NamNguyen> awesome! 1.0 is out
<nhaines> hmm, need to reboot.  bye, alll!
<jelmer> ddaa: ping
<LarstiQ> elmo: bazaar-vcs.org seems to be having problems?
<sabdfl> Wooooot!
<sabdfl> well done all
<jelmer> thanks sabdfl :-)
<jelmer> hey LarstiQ
<LarstiQ> hey jelmer
<jelmer> Riddell,luks: Just tracked down the memory leak in python-subversion. I've got a hack that works, hopefully something better later this week.
<jelmer> Fetching revisions from KDE's history I've now got bzr using 20Mb RAM while it's already fetched metadat for 30krevisions
<jelmer> (compared to 300Mb earlier)
<Riddell> jelmer: ooh, exciting
<dato> abentley: hi. it seems that http://panoramicfeedback.com/opensource/bzr/repo/plugins/bzrtools/ is missing revisions? (doesn't have an up to date version.py at least, it's at 0.92). is that still the current URL?
<Peng_> When running "bzr status", does bzr read every file to see if it matches, or cache stat information or something?
<Peng_> s/matches/has been changed/
<Peng_> When running "bzr status", does bzr read every file to see if it has been changed, or cache stat information or something?
<mwhudson> Peng: there is caching
<ubotu> New bug: #176350 in bzr "gets confused when editor is killed" [Undecided,New] https://launchpad.net/bugs/176350
<spiv> Peng: it stats, and compares to a cache of stat information.
<spiv> Peng: that's the "dirstate" file.
<spiv> jelmer: fantastic
<Peng> Okies.
<Peng> Hg does too.
<Qhestion> hmm is it possible to write a bazaar plugin that implements a specific merging method for specific files?
<jelmer> Qhestion: I believe Aaron has been working on support for that
<jelmer> Qhestion: His nick on IRC is abentley, but he doesn't appear to be around
<Qhestion> so i cant just hook into the merging method and..?
<Qhestion> :(
<jelmer> Qhestion: You can register a custom merging method I think, but that would be called for all files at the moment
<Qhestion> well, that wont be a problem: i think it would be easy to check for a condition and call the original merging method if not true
<jelmer> Aaron's work was focussed on merge algorithms for specific files I think (e.g. C-specific merges)
<Qhestion> i will look into it, and if i get it to work put my branch somewhere. and with some luck it will get integrated into the the main bazaar branch :)
<jelmer> Qhestion: well, that was the sort of thing Aaron was working on afaik so please coordinate with him if you intend on having this merged into mainline.
<abentley> Qhestion: I'
<abentley> I'm not working on it at the moment and haven't gotten very far anyway.
<abentley> Feel free to proceed.
<Qhestion> oh, bazaar 1.0 today!
<Qhestion> good job!
<jelmer> hi Aaron
<fbond> Anybody know anything about 1.0 .debs maybe being published?
<jelmer> fbond: .debs have been uploaded to Debian sid
<jelmer> lifeless takes care of the Ubuntu and bazaar-vcs.org debs
<jelmer> lifeless: ping
<Peng> Darn, even with the bug-124089 branch that's working on bzr+http's path handling issues, it still gave me "not a branch".
<Peng> Well, I might be using the wrong bzrlib.
<vila> jelmer: lifeless is in vacation :)
<jelmer> vila: well, he seems to be around sometimes
<vila> true, but right now he may just be celebrating 1.0
<Peng> That's a nice kind of vacation! Behave normally, but whenever someone asks you to do something you don't want to, just say "dude, I'm on vacation!".
<fullermd> Heck, I do that pretty much all the time...
<Peng> Heh.
<fullermd> That's the advantage of taking your vacation time in 5 minute increments; you can go on vacation just long enough for somebody to get bored and wander off   ;)
 * vila takes some vacations
<Stavros> Hi, I'm new to bazaar and am trying it out, and I've noticed that when someone pushes their changes to my repo, bazaar automatically merges their changes to my working copy without notifying me. Is that safe?
<Peng> Usually you mostly pull, not push.
<Stavros> Oh hmm. I'm still getting the hang of DVCSs...
<Stavros> How safe is automatic merging in general?
<radix> Stavros: what's automatic merging?
<radix> you mean what "bzr merge" does?
<Stavros> Yes.
<vila> Stavros: may be you're confusing branch and repo here, you can have a repo where everybody push (including yourself) and your own branch(es) as you're working env
<Stavros> Well...
<vila> s/you're/your/
<Stavros> radix: I mean merging of the actual code between revisions.
<Stavros> vila: Isn't a branch an entire repo in itself?
<radix> Stavros: can you name specific bzr operations? because I don't really understand what you're saying
<Peng> Stavros: I'd say "mostly safe", but it is possible to trick the algorithm (3-way merge) into doing things a little wrong, and two people can make incompatible changes to different sections of a file.
<Peng> Stavros: I'd review it if I could.
<Stavros> Peng: Ah, I see.
<radix> Peng: it doesn't sound like he's actually talking about "merge"...
<vila> Stavros: A branch use a repository to store the revisions
<Stavros> radix: What Peng said, I'm talking about the merging of code in the files.
<radix> Stavros: so you mean when you explicitly do a "bzr merge" operation, you're wondering if the algorithm it uses to merge the changes together is safe?
<Stavros> radix: Yes, the same thing that bzr appears to do when pushing.
<vila> Stavros: so I should have said: you can have a branch where everybody push (including yourself) and your own branch(es) as your working env
<radix> Stavros: that's not what happens when you push
<Stavros> vila: Ah.
<Stavros> radix: Well, I just pushed my branch to another repo and it merged the repo's working copy with my changes.
<radix> Stavros: pushing *only* works with non-diverged branches, so there's no actual merging happening -- just appending of revisions
<fullermd> radix: It is when you locally push into a branch with colo'd working tree where somebody is working.
<radix> Stavros: it didn't "merge", it just added some revisions
<Stavros> radix: Ah, different terminology then.
<Stavros> That's what I meant by merging, the actual changing of the file.
<Stavros> Not the bzr "merge" operation.
<fullermd> (not that that's a particularly sane workflow, but...)
<radix> right, ok
<Stavros> I see now though, thanks.
<radix> Stavros: so that's very safe
<radix> Stavros: as long as you don't use --overwrite, it won't affect the target branch in a bad way
<radix> i.e., you can always back out those changes, or whatever.
<radix> and if you don't want *other* people affecting your branch at all, well, don't give them write access.
<Stavros> Yes, I suppose so. I was just worried that it could happen while I wasn't looking, since with SVN/whatever it would tell you that there are new changes and you'd have to merge and then commit.
<radix> Stavros: then you need a different workflow
<radix> Stavros: allow other people to publish branches somewhere else, but not push directly to your branch
<radix> Stavros: and then you can merge them when you want
<Stavros> radix: I was just testing and noticed that, I'll probably be using a SVNish model with a central server.
<Stavros> Just for backup mostly, since I'm usually solo.
<Stavros> I also tried Hg recently and liked it, so now I'm between these two systems, which are both very nice.
<mwhudson> jelmer: that memory leak workaround is lovely :)
<jam>  Stavros: so doing "bzr push .../existing-branch" is similar to if someone in svn did
<jam> svn checkout .../existing-branch; change stuff; svn commit
<jam> It only works if their changes are descended from your tip revision
<jam> I would mention that when you "bzr merge" it *doesn't* automatically commit
<jam> and both pull/push only work if there would be nothing to merge (eg someone has already done the merge)
<luks> well, at least pull will try to merge uncommitted changes
<Stavros> jam: Hmm, I don't think that example is accurate, because in bzr the person's changes are reflected in your working copy, while in SVN you get a notification that there were changes when you try to commit...
<Stavros> I think that there might have been some danger where you'd be working on it, and commit only to find out that your working copy had changed incompatibly and you've checked in a broken build.
<Stavros> But that's a pretty far-fetched usecase...
<jam> Stavros: with SVN?
<jam> or with Bazaar?
<Stavros> jam: bzr, with SVN you get a notification, it doesn't change anything without you knowing.
<jam> In bazaar you would have to bzr update
<jam> And it wouldn't let you commit if you were out of date
<jam> I'm not sure how it is doing what you suggest
<Stavros> No, picture this:
<Stavros> You pull my repo and work on feature B, and I work on feature A. I test feature A, and leave a touch for later. You test feature B and commit and push to mine. Your feature breaks mine, and bzr changes my working copy to implement your changes, and when I commit, it's broken.
<Stavros> Unless I did something wrong?
<jelmer> Stavros: in general, you don't push to somebody elses branch
<jam> Stavros: when you push, how did you update the working tree?
<jam> You might push to the *branch*
<Stavros> jam: I didn't, it was already updated.
<jam> but the WT knows it is out-of-date
<jam> The only way I know to do that is to have both users working on the same machine
<Stavros> Hmm, I'll retest it, maybe I made a mistake.
<jam> and have them bzr push ../other-working-tree
<Stavros> jam: I actually was :p
<Stavros> I didn't think it'd matter, I was testing it out.
<Stavros> So what does it do when you're on another machine?
<jam> It marks the branch at a new point
<jam> and your working tree stays put
<Peng> Stavros: The usual workflow is to have the other person push somewhere, and you pull.
<jam> (we don't update WT on another machine unless you have my push-and-update plugin installed)
<Stavros> Ah, and you have to update as normal?
<jam> correct
<Stavros> Peng: Yes, that would be how I would normally work too...
<Stavros> jam: Good, so I was seeing something else... It makes sense, really, too.
<Stavros> You can push through ssh, right?
<jam> Stavros: bzr+ssh or sftp
<jam> yes
<Stavros> What's the difference between those two?
<jam> one spawns bzr over an ssh connection
<jam> the other just uses an sftp server
<jam> bzr+ssh is a bit faster, but requires you install something on the server
<Stavros> So bzr+ssh is faster but needs bzr?
<Stavros> Aha.
<Stavros> I understand there's a plugin to push/pull from Hg as well?
<Stavros> Why don't these two projects just merge and make my life easier :P
<jam> there is bzr-hg, but I think it is limited to puling atm
<jelmer> yes, it is
<jam> Generally, we can represent hg metadata, but we have to shoehorn ours back into theirs
<Stavros> Oh, hmm...
<Peng> I need a shoe horn.
<jam> bzr-svn is the only one that has gone to the effort of that
<jam> it could probably be done
<jam> but I don't know off-hand how to insert extra metadata about a revision into hg
<Stavros> Is there any chance the two would merge?
<luks> jam, hg has an equivalent of bzr revision properties
<jam> luks: is that a newer thing?
<Peng> Stavros: Well, they have entirely different codebases.
<luks> no idea, I've only seen it in the code some time ago
<Stavros> Peng: True, but they're very similar to what they do... It's a pity that you have to choose between programs that have 90% same functionality...
<Stavros> similar *in* what..
<jam> There certainly are similarities, we actually had a meeting together about 1.5y ago, but at that time both groups were pretty sure that their way was the Right Way...
<jam> hg was focused on being a fast light system
<jam> Bazaar didn't want to give up some of the abstractions
<jam> (which makes it easy to support things like bzr-svn, bzr-hg, etC)
<jam> etc
<Stavros> Hmm, if it's a tradeoff, it'd be hard to reconcile...
<Stavros> I work at most with a few MB of code, so I think I'll go with bzr...
<jam> Some other small things, like whether "merge" should auto-commit
<jam> We generally feel it is a bad idea
<jam> to commit without human interaction
<Stavros> Yes, I would agree.
<Stavros> I don't even like automatic merging of the code :P
<jam> Whether "merge" should make you resolve conflicts as they come
<jam> Or whether you can do it after the fact
<Stavros> How come bzr doesn't have a few critical parts written in C or such, for speed?
<quicksilver> because the language they were written in wasn't obviously the speed problem :)
<quicksilver> it was better to fix the algorithm...
<Stavros> Ah, it's always good when you CAN fix the algorithm... Sometimes you just have to rewrite.
<Stavros> Python's support for C modules is great, so it wouldn't be that hard anyway.
<luks> bzr does have some parts written in pyrex and c
<luks> but they are optional
<LeoNerd> Besides.. I find bzr "fast enough" for my purposes
<LeoNerd> Whereas, I'm impressed by the speed of the bzr developers. The reason they're that fast is they can write high-level python code, not low-level C code
<LeoNerd> I'd rather wait an extra 5 seconds for "bzr shelve" to run, than wait an extra 5 months for the developers to first write it. :)
<jam> Yeah, algorithm tweaking is a bit easier in Python
<Stavros> I think you'd have to have a HUGE codebase to notice slowdowns in your VCS anyway, so it's not really an issue...
<luks> I'm very often tempted to try to use hg or git, but it's hard if you are used to the comfort of bzr :)
<jelmer> mwhudson: :-)
<jam> And then once we figure out what is going on if we've reached a limit and it is a critical function
<jam> we've written some Pyrex extensions, etc.
<Stavros> What does "shelve" do?
<Stavros> I can't find it in help"
<jam> Pretty much all in the form of "if you have it compiled, use it, else use the python implementation"
<jam> Stavros: it is from "bzrtools"
<Stavros> Oh.
<jam> It lets you put patches "on a shelf"
<radix> Stavros: you're really going to have to come up with a better word than "merge" to describe that, since you're going to continue to confuse people :)
<jam> The only reason it isn't core is because it relies on "patch" being available
<jam> and because it doesn't handle binary files
<LeoNerd> Actually, I find shelve needs some work
<Stavros> radix: Where? I haven't said "merge" in ages :P
<LeoNerd> shelve a change, then rename a file. You can't unshelve it without manual hackery within the shelf file
<jam> Stavros: well, fixing the algorithm/fixing how you store data
<radix> Stavros: I guess about a page up is "ages" :)
<Stavros> radix: We have moved on, sir! :p
<jam> LeoNerd: or make a trivial change to the file so it won't apply cleanly
<Stavros> Seriously though, what's it called?
<LeoNerd> That too
<radix> Stavros: "pushing" :)
<jam> luks: you're LukÃ¡Å¡ L, right?
<radix> Stavros: it's really just like any other upload or copy operation, it's just optimized so it doesn't transfer unnecessary revisions and doesn't allow you to do it if branches have diverged
<luks> jam, yes
<jam> It is always fun to submit your patches to PQM and watch the email interfaces choke on your name :)
<luks> heh
<radix> hehe
<Stavros> radix: No, I'm talking about the actual changing of the file to put the changes from another file in it, regardless of a VCS context.
<jam> luks: but at least we represent it properly in the commits
<Stavros> radix: I.e. diff/merge, it's what it's called :P
<radix> Stavros: then I still think you don't understand it
<radix> Stavros: think about "cp fileA fileB"
<Stavros> radix: I think we're talking about two different things.
<radix> Stavros: I think we're talking about what happens when you do "bzr push <remote-URL>"?
<Stavros> radix: No, we resolved that :)
<radix> oh, whew.
<Stavros> radix: It was because I was pushing on the same machine.
<radix> sorry. I have only been half-paying attention.
<Stavros> Shows! :P
<radix> Stavros: oh, pushing on the same machine is basically the same as pushing to a remote machine.
<Stavros> Now I'm confused again, then.
<radix> Stavros: hooray! let's fix it :)
<Stavros> Haha
<jam> radix: if there is a local working tree
<jam> we update it
<Stavros> Okay, when I pushed to the other directory, the working copy was updated with the changes, without me updating.
<jam> That is what Stavros was running into
<radix> ahhh. ok. the orking tree updating.
<radix> Stavros: so, yeah
<Stavros> Ah. So is that it or not? :(
<Stavros> Stop confusing me :P
<jam> Stavros: local working trees are updated by push
<radix> Stavros: ok, yes, so the working tree is updated when you push locally, HOWEVER
<radix> 11:02 < Stavros> radix: I.e. diff/merge, it's what it's called :P
<radix> Stavros: updating the working tree is still totally unrelated to stuff like diff and merge.
<radix> Stavros: we can move back to my "cp" analogy again :)
<jam> luks: are you 'luks' on LP?
<Stavros> radix: I am talking about the verb "to merge", not the VCS operation "merge" :P
<luks> jam, yes
<jam> k
<jam> just marking your bug as merged
<radix> Stavros: even so. it's really just like "cp". except when you do it locally, not only are the low-level revisions copied, so are the working tree files.
<jam> well marking Odd_Bloke's bug as fixed by you, and merged
<Stavros> When you do a push on a local disk, it doesn't do a VCS "merge", but it does merge the changes into your working copy
<luks> :)
<Stavros> My connection is lagging somewhat, apparently, so what I say may appear out of context.
<radix> Stavros: s'cool.
<Stavros> radix: Yes, exactly.
<radix> Stavros: anyway, I guess we're on the same page
<radix> Stavros: I'll try to stop bugging you :)
<jam> Stavros: well, when I switch to work on something else while chatting *I* lag a little bit
<jam> so I don't really notice :)
<Stavros> radix: It's ok :P
<Stavros> ooo, graphs
<Stavros> Hmm, so shelve is for when you want to fix something without losing the changes in your working copy?
<Peng> It's for when you've made multiple unrelated changes and you only want to commit some of them.
<radix> I guess it's really for any time you want to temporarily revert parts of your working tree.
<Peng> Or when you want to put something aside.
<radix> and yeah, committing parts of them is probably a main use case.
<radix> (when the boundaries aren't aligned with files)
<jam> Stavros: I personally use it when I'm working on a bug fix, and I've written a possible fix and some test cases
<jam> and I want to make sure that the test suite *fails* without the patch
<radix> ah, yes, it's a good thing to use when you (ahem) forgot to use TDD ;-)
<jam> So I 'bzr shelve file', bzr selftest new-test, bzr unshelve; bzr commit
<jam> radix: I use TAYD
<Stavros> Aha... Couldn't you do sort of the same with pulling the latest commit into another branch and working on that?
<jam> (test as you develop)
<jam> Stavros: sure, there are other ways to do it
<jam> it is just *fast* to put aside things for a quick second, and then bring them back
<Stavros> Interesting tool, though. I should get it.
<Stavros> Agree.
<jam> you could do a partial commit
<jam> and revert
<jam> I've done that too
<Stavros> Does it work well?
<jam> shelve or commit+revert?
<Stavros> shelve
<jam> commit+revert handles more cases properly
<jam> shelve generally works if the stuff is simple
<Stavros> Yes, but sometimes you aren't done working on the thing so you can commit...
<jam> Stavros: well, that is why branches are cheap
<jam> you can also do partial commits
<jam> etc
<jam> Though "bzr commit" doesn't let you select specific hunks like shelve does
<Stavros> Partial commits are only done with shelve, then?
<jam> 'bzr commit file1 file2'
<jam> won't commit changes to file3 4 or 5
<jam> But committing selected *hunks* are done using shelve
<Stavros> Good, that's a useful tool then.
<jelmer> jam: is there something that allows you to commit just hunks?
<jam> jelmer: not that I know of
<Stavros> That would be a nice feature, instead of shelving the ones you DON'T want and committing...
<jam> It would be a bit tricky considering our commit layering which likes to think of texts as snapshots
<jam> So you would probably have to have a staging area to put the edited text, etc.
<jelmer> yes, I agree
<Stavros> Ah, hmm...
<jam> You probably could keep the hunks in memory if you wanted
<jelmer> jam: Since you can specify a tree to commit, shouldn't it be possible to just build a part-in-memory tree with the hunks you want?
<jam> Since it is generally just use *these* lines or *these*
<jam> jelmer: yeah
<radix> jelmer: well, the thing about shelve is that it gives you a chance to run the tests after separating the changes.
<Peng> (Hg has a record extension to commit hunks.)
<Peng> (Like darcs record.)
<jam> radix: thanks for pointing that out, too
<jelmer> radix: That's a good point
<jam> Stavros: that is probably the #1 reason we went with the shelve workflow
<jam> since it lets you see the tree as it really is
<jam> rather than how you *think* it would be with that patch removed
<Stavros> jam: Yes, that would be much more useful...
<Peng> ?
<Stavros> Damn shortcuts...
<Stavros> Where does shelve store its files?
<jam> Peng: ? who are you questioning?
<radix> (which is the same sentiment that makes me think it's a bad idea to review a branch as a diff of its base as opposed to as how it's merged)
<jam> Stavros: .shelf/*
<Stavros> Ah, I am liking this more and more.
<jam> radix: then again, if you are doing something like PQM, you'll never get a chance to review it how it is merged
<jam> because there may be 3 patches that make there way in first
<Peng> jam: ? was at Stavros suddenly parting.
<Peng> Sorry.
<Stavros> I currently have a bugfix sitting for months because I haven't finished the feature I was working on :(
<jam> Stavros: feature branches FTW
<radix> heh
<Stavros> jam: You branch your code per-feature?
<jam> Stavros: http://bzr.arbash-meinel.com/branches/bzr/
<jam> About 279 branches last I counted
<jam> per feature, per bugfix, per ....
<Stavros> Oh, isn't that like tagging in SVN?
<Stavros> Nice, I was wondering how to do that...
<radix> no, it's like branching in SVN :)
<Stavros> Oh, so you merge them back when done...
<jam> radix: except it remembers when you only merge part of a feature
<jam> so that when it gets more work on it
<radix> but it's a workflow thing, not really determined by the VC.... and as jam points out, the VC can help
<jam> you can simply merge again
<Stavros> Yes, that's true.
<radix> but the basic idea is that ANY distinct development you want to do, you should start a branch for it
<Stavros> I love the fact that you don't need a server, you can just use SSH.
<Stavros> radix: I usually don't bother, if I'm the only one working on it...
<jam> Stavros: yeah, having used Bazaar, trying to "svn/cvs init" a new project is horribly hard
<jam> radix, Stavros: there is also a nice discussion here: http://www.venge.net/mtn-wiki/DaggyFixes
<jam> But I don't know many people who go to the extra effort
<jam> DaggyFixes are very nice conceptually
<radix> Stavros: yeah, generally I don't either, at the very beginning of a project. but even if I remain solo, I generally eventually switch to branch-based development once the project gets semi-mature
<jam> I actually tried doing branch-based devel in CVS back in the day, because it seemed like the "right thing"
<jam> But man was it painful
<jam> So I just ended up with release-level branches
<jam> 0.6, 0.7, etc
<Stavros> radix: I don't see why, since I'll only be working on one feature at a time usually...
<Stavros> Is there a way to switch from SVN to bzr?
<radix> jam: hell yeah. I remember that.
<Stavros> Easily? :(
<radix> Stavros: yep.
<jam> Stavros: bzr-svn
<jam> "bzr pull svn://host/trunk"
<radix> Stavros: there's a whole-repo conversion tool, as well as a thing that allows you to use an SVN repo as if it were a bzr branch.
<Stavros> Ah, great. I tried a bzr2svn script but it didn't work
<radix> jam's describing that last thing.
<jam> I think bzr-svn also provides
<jam> bzr svn-import
<radix> oh, neat.
<jam> Which does the whole repo import
 * Peng deletes 100 MB of testbzr-*.log files.
<Peng> :\
<radix> i guess bzr-svn is winning these days.
<Stavros> Well, I have a repo that has my projects somewhere and I want to make each SVN branch a bzr branch.
<Stavros> So, bzr-svn would be what I need?
<jam> Last I knew, I thought svn2bzr was adapting the same conversion logic
<jam> so they would be compatible
<Stavros> jam: It's not working, though :/
<jam> https://launchpad.net/bzr-svn
<radix> Stavros: yeah, bzr-svn. not svn2bzr; that's a different thing.
<Stavros> radix: Great, thanks, I'll do it now.
<Stavros> Oh hmm, I need to wait for the new laptop. Damn, foiled.
 * radix is waiting for his new laptop as well. It's taking lenovo a *month* to get it out the door!
<Stavros> It's taking Apple two weeks :/
<Stavros> By the way, is there a way to update the working copy immediately when pushing, so I can have the production server change to the new code immediately when pushed?
<jam> Stavros: https://launchpad.net/bzr-push-and-update
<jam> Another plugin which does "ssh server bzr update" for you
<jam> *if* there is a working tree there
<Stavros> I don't suppose it can run commands too, can it? :/
<Stavros> apache restart, in particular
<jam> Stavros: it wouldn't be hard to add into it
<jam> but not at the moment :)
<Stavros> Ah, there's something for me to work on, then :P
<jam> Stavros: patches welcome :) It is pretty trivial to do so, except you need to somehow do the configuration to know what commands to run, etc.
<jam> I would probably go with reading the targets Branch.get_config() (which points at .bzr/branch/branch.conf) and having a "post_push_and_update_commands = XXX" or something to that effect
<Stavros> jam: True... It wouldn't be hard to have it read a shell script to perform on update...
<Stavros> Hmm...
<radix> jam: looks like you need to update the launchpad description
<vila> Peng: bug #123363 ?
<ubotu> Launchpad bug 123363 in bzr "selftest pollutes /tmp" [Medium,Confirmed] https://launchpad.net/bugs/123363
<radix> jam: since you made it a push post-hook and don't require "bzr push-and-update" any more
<Stavros> Man, my sister isn't going to be pleased with all the development stuff I've loaded her laptop with...
<jam> probably
<vila> jam: you know Stavros sister ???
<Stavros> How do you know her?!?! Damn you.
<radix> blasted "context" stuff :)
<jam> radix: can't I just hire someone to take care of all the doc stuff? I'm too busy hacking :)
<radix> hehe. I'd offer my services, but I'm not sure my employer would be happy with me moonlighting for another employee. :-)
<jam> vila: is that still happening?
<jam> (I don't really run the whole test suite often)
<jam> I always blamed bzrtools, just to make myself feel better
<jam> The ones I see right now seem partially if I do "^C" while it is running.
<vila> jam: yes still happening, I had to reboot my test PC today so only for today with just a few full selftest : 1688 testbzr.*.log and a couple of tmp.* dirs
<mw> woohoo, 1.0!
<jam> hm... I only had 88 and most of the ones I actually looked at were KeyboardInterrupt ones
<Stavros> How do I use bzr-svn? Do I just pull my branch?
<jam> Stavros: generally you would do some form of:
<jam> bzr init target
<jam> cd target
<jam> bzr pull http://svn.source/branch
<jam> I'm not sure if "bzr branch http://svn.source/branch" works
<luks> which wouldn't work :)
<luks> branch works
<jam> Simply because Bazaar generally preserves source formats
<luks> or bzr init --format=rich-root
<jam> luks: ah, because you need "bzr init --rich-root" ?
<jam> We need to get that the default soon
<luks> why it isn't the default pack format anyway?
<jam> well, rich-root-pack at least
<mgedmin> congratulations for the 1.0!
<jam> luks: race conditions (rich root pack came out ~ the same time pack-0.92 became default)
<jam> Also, upgrade is slower
<jam> knit => pack 0.92 is just shuffling some bits around
<jam> => rich-root requires regenerating the inventory files
<jam> aka slow
<Stavros> I love not having to have everything under one repo, like in SVN.
<mgedmin> you may want to remove this sentence from the front page of http://bazaar-vcs.org/: "Following a sprint in London in May 2007 which brought together many of our core contributors, we now have a plan for 1.0."
<jam> Oh, and I think Robert pushed for packs, Aaron wrote rich-root :)
<fullermd> The sneaky solution is to get the inventory rewrite pushed in; then the upgrade has to rewrite 'em anyway, so you can push to rich-root behind everyone's back at the same time.
<jam> mgedmin: thanks
<jam> done
<Stavros> Oh, bzr-svn can't handle auth? :(
<jelmer> Stavros: It can, but can't ask for credentials
<jelmer> Stavros: it will use the credentials Subversion has cached
<jam> jelmer: why is that?
<jam> out of curiosity
<Stavros> Oh, I need subversion too? :P
<mgedmin> hm, the ubuntu gutsy repo still only has 1.0~rc1-3bazaar1, I'll wait before upgrading
<jam> mgedmin: yeah, I think poolie is on the packaging while lifeless is away
<jelmer> jam: up until a few weeks ago, it was impossible to register credentials providers in the subversion client libs
<Stavros> I'll do it on the server itself and just pull from that, then.
<jam> jelmer: ah, so just not exposed at the library level
<jam> that's crummy
<jelmer> jam: Yep. It is now, and I'm working on support for AuthenticationConfig. Hopefully that'll be in 0.4.6
<jam> having poked through gits codebase again, I'm reminded why writing a library first is better
<jam> and then command code that calls into that
<jelmer> jam: It's actually exposed at the library level, the python bindings were broken though
<jam> There is a whole lot of global state that you have to figure out
<fullermd> You don't need a library.  You just connect up commands through a shell script...
<jam> fullermd: yeah, and then *each* git process gets to parse all of the index files again
<fullermd> Yeah, but that doesn't matter, 'cuz git is so fast each process finishes before the previous one.
<jam> Well, in *my* testing, creating a git branch by doing "git init; git add; git commit" was *vastly* slower than doing git fast-import
<jam> Like <1s versus 20s
<jam> And git even has their fancy index to make everything faster
 * jam => stops talking to all the nice people and tries to actually get some work done
<radix> jam: oh, thanks for pointing out that DaggyFixes wiki link. We do that in Landscape. But what I'm happy about is that they mentioned monotone's "disapprove", which I didn't know about. I filed bug #152008 a while ago and it looks like "disapprove" is the kind of operation I need.
<ubotu> Launchpad bug 152008 in bzr "Ability to unmerge or revert a merge sensibly" [Wishlist,Triaged] https://launchpad.net/bugs/152008
<Stavros> That's odd, there's an ubuntu "bazaar" package that isn't bzr...
<jam> Stavros: Baz-1.x
<jam> It was an initial attempt at a better version control
<jam> based on Arch
<jam> which ended up having fundamental issues
<jam> So 'bzr' was bord
<jam> born
<jam> damn, I said I was leaving :)
<Stavros> Ah, I see... I was wondering why it was at 1.4.2...
<Stavros> Yes, you did :P
<luks> people always say that on irc :)
<Peng> jam: So, you organize http://bzr.arbash-meinel.com/branches/bzr/ by bzr version?
<jam> well, i blame radix  he mentioned my name
<jam> Peng: generally
<jam> When you have 100 branches
<radix> sorry :)
<jam> simply putting them in a branches/ dir isn't sufficient
<jam> Peng: it is sorted by the approximate revision I expect them to land in
<jam> s/revision/release
<jam> I could have just done it by month, or something
<Peng> All of my branches are just simple typo fix sorta things (and one trivial bug), but I push them because thanks to my locations.conf, the URL is automatically included in bundles.
<Stavros> Any idea why bzr-svn isn't authenticating? svn co worked fine...
<jelmer> Stavros: You can try prefixing the URL with svn+
<Peng> I'm an organization nut, so I've been worrying about how to organize it.
<Peng> (Well, I'm not OCD in general, just with HTTP.)
<jam> Peng: date based works fairly well for me
<Stavros> jelmer: unsupported protocol, svn+http :/
<jam> Peng: but I wrote a doc on it: http://bazaar-vcs.org/SharedRepositoryLayouts
<jam> Stavros: do you have bzr-svn installed correctly?
<jelmer> Stavros: are you sure you have bzr-svn installed?
<jam> cd ~/.bazaar/plugins
<jam> bzr checkout lp:bzr-svn svn
<jam> It should be in ~/.bazaar/plugins/svn
<Stavros> jelmer: Uh. It would have been better if I hadn't forgotten to do that :/
<Stavros> Sorry.
<jam> unless you are installing from debs
<Peng> I decided to create a 'trivial/' directory and put all those things there, and leave the top level for long-lived branches, supposing I ever create one.
<Stavros> Same thing still, "Not a branch"
<jam> Peng: for the real OCD, you can always nuke them after they have been merged
<Stavros> I'll just point it to the actual SVN dir.
<jam> I think there is a plugin for that
<Peng> I've never left a 404.
<Stavros> Still not a branch, that's odd...
<jam> radix: that was the "I want to pretend I didn't merge" so that it backs out the change *and* removes it from the ancestry so a future merge will pull the whole thing in?
<Peng> I'm OCD about good organization and no name clashes, and never leaving 404s, not tidyness.
<Peng> I have thought of that though.
<Stavros> Any idea what "Not a branch" could mean?
<jelmer> Stavros: Does "bzr plugins" list the svn plugin?
<Stavros> Yes.
<Stavros> I'm pointing it to a directory in the trunk.
<Peng> The other thing is that Apache directory listings don't give the status of the branch (experimental, merged, whatever) like Launchpad does.
<radix> jam: yes. I added a comment to the bug.
<jam> I replied
<jam> I think disapprove(A) is just merge(A..A') commit
<jam> But not having used it extensively...
<jam> (or at all :)
<Stavros> Apparently bzr-svn can only be pointed at trunk/? Can't I make a bzr repo out of a SVN subdirectory?
<jam> Stavros: bzr help branch-layouts
<jam> or something like that
<jam> You have to do some work if you want projects underneath the main trunk
<jam> bzr-svn makes sure that if 2 people checkout the same source, they can interoperate
<jam> so they have to agree on how the projects are laid out
<Stavros> Oh... I only need it for one-time migration, though...
<Stavros> The only commands svn has are svn-import and svn-upgrade.
<jam> Stavros: it is a help topic
<jam> try "bzr help topics"
<Stavros> Nothing there either :/
<Stavros> formats?
<Stavros> Nope.
<jam> bzr help svn-branching-scheme
<jam> Is supposed to be the help topic
<jam> according to luks
<jam> from yesterday
<Stavros> Nothing there :/
<luks> not really a help topic, but you can set your own branching scheme there
<luks> but you can also with the command line options in svn-import
<jam> Stavros: http://rafb.net/p/nCHdmV87.html
<luks> s/also/also play/
<jam> But what version bzr-svn do you have installed?
<Stavros> jam: The one from the ubuntu repos.
<Stavros> Probably oldish?
<jam> Stavros: do you know the number?
<jam> you need >0.4 to get branching schemes
<jam> 0.3 didn't support it
<Stavros> Let me check.
<Stavros> 0.3.2, aha.
<jam> jelmer: do you support "trunk/project/*" out-of-the-box
<jam> Or does that require "ListBranchingScheme" ?
<jam> Stavros: peeking at the code it looks like the dev code supports it out-of-the-box
<Stavros> jam: It says it can't find plugin "svn" now...
<Stavros> Unable to load, to be exact
<jam> Stavros: cannot find, or cannot load?
<jam> vi ~/.bzr.log
<jam> will give more info about why it is failing
<jam> Probably needs a newer bzr... :(
<Stavros> No log there, let me get the newest bzr.
<jelmer> re
<Stavros> grr, repository incompativle
<jelmer> Stavros: What sort of command are you running?
<Stavros> pull
<jelmer> you'll have to upgrade the branch you're pulling into
<Stavros> Hang on, I saw this somewhere on the bzr-svn FAQ.
<jelmer> bzr upgrade --rich-root
<Stavros> Ah, thanks.
<jelmer> or if you simply want to make a clone of the branch that exists in svn, use "bzr branch <svn-url> <local-dir>"
<Stavros> Isn't it odd that it takes minutes to convert an empty repo?
<mkanat> Congrats on 1.0, everybody. :-)
<Stavros> Or maybe it's checking out as well.
<jelmer> Stavros: during "bzr upgrade" you mean?
<Stavros> jelmer: Yes.
<Stavros> Yay, the pull seems to have worked.
<jelmer> jam: The sooner we can get rid of branching schemes, the better..
<jam> jelmer: except I think SVN's model is broken, so trying to enforce some sort of logic on it...
<jelmer> jam: Branching schemes will still be required in any case but it should be possible to hide them from the user much more.
<Stavros> How can I check which revision I'm at?
<jam> bzr log -r -1 ?
<jam> Or just bzr revno
<Stavros> Ah, thanks.
<jam> but revno is branch specific
<Stavros> The command line is a bit tedious for viewing changes, I must admit...
<jam> 2 branches can have the same simple revision number (aka revision 10)
<Stavros> Oh, hmm.
<jam> Stavros: you might try installing bzr-gtk
<Stavros> Windows atm :/
<jam> and then you have "bzr viz"
<jam> Stavros: still works ther
<jam> but I guess the gtk dependencies are a bit harder to get
<Stavros> Aha, great, I'll do that then.
<Stavros> Hmm, true...
<jam> There is also a TortoiseBzr that is part of bzr-gtk
<Daviey> jam: embarrassingly i found the problem...  The word that was causing a problem got filtered via procmail on the incomming email :(  silly me
<jam> but I don't think it is nearly as polished as TortoiseSVN
<jam> Daviey: so it was generating them, but you weren't getting them ... weird
<Stavros> Well, TortoiseSVN has had years of development...
<Daviey> jam: yeah, my fault entirely :(
<jam> Stavros: well, at the moment, I think it still needs a caching server
<luks> Stavros, if you want something quickly installed - http://bazaar-vcs.org/QBzr
<jam> so that it doesn't slow down all of for basic Exploring
<Stavros> jam: That's true, that does take ages sometimes.
<Stavros> luks: Oh, nice, thanks.
<jam> "all of your"
<jam> luks: so do you bundle the QT libs?
<luks> yes
<jam> someone needs to get "apt" working on Windows :)
<luks> that would be impossible
<Stavros> Well, you'd have to make a different tool for windows...
<luks> programs on windows usually depends on specific versions of libraries
<jam> yeah, it just seems silly to have 10 versions of similar DLLs
<jam> considering that was the *point* of DLLs
<luks> even MS decided that all apps build with MSVC should ship their own stdc library
<Stavros> luks: That is a nice utility.
<Stavros> Wow, I can even see the changes by clicking, awesome.
<luks> heh
<Stavros> By the way, I am reading the daggyfixes thing, how do you do that? Branch from the change that introduced the bug, fix it and push it back to the repo?
<jam> Stavros: something like that
<jam> "bzr branch -r XX fix_bug_foo
<Stavros> Does it merge all the new changes correctly?
<jam> Stavros: the "push" won't but doing
<jam> cd trunk
<jam> bzr merge ../bugfix
<jam> will do just fine
<jam> 'bzr push' won't let you
<jam> because they are diverged branches
<jam> Stavros:  you might look at: http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/centralized_workflow.html
<Stavros> Hmm, I find it a bit odd that it can correctly merge two very different files... How do you know it won't merge the changes from the old file back?
<jam> It might be a decent migration path coming from SVN
<Stavros> I've sort of read that, it's my personal repo so it's not that huge a deal.
<jam> Stavros: generally we know what set of changes are present, and use a 3-way merge logic
<Stavros> Just trying to learn stuff atm.
<Stavros> Aha.
<Stavros> Hmm, I was wondering why this room had gone silent...
<jam> I was wondering what you "aha" moment was :)
<Peng> Stavros: You didn't miss anything. Just some joins and parts.
<Stavros> Ah, good then.
<Stavros> Wireless isn't that reliable, apparently.
<mrZeby> hello all... i have installed qbzr but when i launch it a have the message "unable to load plugin qbzr..." when i start bzr... somebady can help me, please ?
<Stavros> mrZeby: Which OS?
<mrZeby> vista :-).. sorry
<Stavros> That's odd, I just installed it and it worked fine... Which installer did you use?
<mrZeby> but i had the same problem last time i try to use on xp
<mrZeby> i use python based installer
<Stavros> Try the other one, with everything included.
<mrZeby> i had allready installed python for other program
<mrZeby> python 2.5
<Stavros> Doesn't matter, it should work anyway.
<Stavros> It doesn't actually have python in it.
<mrZeby> i had install bzr with python installer too
<mrZeby> ok i try the windows installer
<mrZeby> but perhaps i can install other thinks.. like pyqt ... ?
<Stavros> mrZeby: No, the installer has everything.
<jam> You can check C:\Documents and Settings\<username>\.bzr.log
<jam> which should tell you why qbzr isn't loading
<jam> which could be something like pyqt not being installed
<jam> The standalone installer should package everything
<mrZeby> ok i take a look
<jam> but you may want to re-use your python install
<jam> mrZeby: You can also check "bzr --version"
<jam> It should have a line for:
<jam> Bazaar log file: /Users/jameinel/.bzr.log
<zero-9376> is it possible to modify the email address for a previous revision? for some reason the email reverted to username@host rather than using the config file in my home directory
<mrZeby> ok i found bzr.log...
<mrZeby> ok ok "ImportError: No module named PyQt4
<Stavros> mrZeby: Yeah, just use the bundle.
<mrZeby> the complete bundle would re install other python directory ?
<Stavros> No, it doesn't install stuff anywhere else.
<mrZeby> do you think i must reinstall bzr with windows installer to ?
<mrZeby> too
<zero-9376> is there any way to do this?
<jam> zero-9376: I do it like that. :)
<zero-9376> sorry i don't understand
<jam> You said "this" without saying what you wanted
<jam> So I said "that" without telling you how to do it
<zero-9376> (04:29:10) zero-9376: is it possible to modify the email address for a previous revision? for some reason the email reverted to username@host rather than using the config file in my home directory
<jam> zero-9376: for the previous commit, you can "bzr uncommit; bzr commit" again
<jam> Otherwise, no
<Stavros> You can uncommit stuff?
<jam> Stavros: yes
<Stavros> Wow, what does it do? Make it as if you never committed?
<jam> Branches are just pointers into a revision graph
<jam> so you are free to move them around if you need to
<jam> Stavros: it leaves the commit available in the repository
<jam> but the branch itself doesn't reference it anymore
<Stavros> Ah
<jam> And when someone branches from you, they won't get that revision, etc.
<Stavros> I must research more.
<Stavros> But first, Futurama!
<woei> and when someone branches from you before you uncommitted and then tries to push/merge with you ?
<Stavros> Later all, thanks for the help!
<jam> woei: If you have a new commit, it will tell them the branches have diverged
<jam> woei: if you just did uncommit
<jam> it won't do anything
<jam> because the source is an ancestor of the target
<jam> they can "pull --overwrite" to switch to your new commit
<woei> I see
<jam> or they can "bzr merge" if they really wanted that comimt
<jam> commit
<jam> (pull --overwrite should also change your local branch to move backwards)
<woei> hmm, but what if someone branched from you, you uncommitted the version they branched from, you work some on your branch, the other person(s) work some on their branch. It's just merging as usual ?
<woei> seems logical, if you take the 'branch is just a pointer in an entire revision graph' angle
<jam> woei: right
<jam> uncommit doesn't record that there was a change
<jam> if you want to reject a patch you need to do
<jam> bzr revert -r -2; bzr commit -m "revert that last change, what was I thinking"
<jam> Or if it is further back you can do
<jam> bzr merge -r 10..9; bzr commit -m "revert the changes introduced in revision 10, WWIT?"
<woei> excellent
<woei> thanks for the pointers
<jam> always happy to help
<bos> hey, guys.  there's been a bit of discussion on reddit about the bzr wiki pages regarding git and hg.  have you seen it?
<jam> bos: not specifically, any links?
<bos> http://programming.reddit.com/info/62z0v/comments/
<bos> i read the wiki pages.  they're very disappointing.
<bos> they have such an overt and obvious bias to them that it's hard to take anything they say seriously.
<bos> which seems to be the consensus on reddit, too.
<mrZeby> thanks a lot for your help mr Stavros :-)
<bos> obviously, you should be advocating for bzr based on its strengths, but it doesn't do any favours to provide biased and distorted comments about the competition.
<bos> that is to say, it doesn't do bzr any favours.
<jam> bos: it is also a bit hard to be perfectly balanced when writing from one side. but I would certainly be interested in reading a logical counterpart to it
<jam> I saw a bit of wiki stuff on selenic, but that seemed full of a lot of anger more than simple reasoning
<mrZeby> a question more can i ? the windows installer wuold install qbzr on directory C:\Users\mrZeby\AppData\Roaming\bazaar\2.0\plugins\qbzr
<jam> It certainly wasn't the point to strictly bash on other systems
<bos> jam: i don't know about the selenic stuff, i'm afraid.  haven't read it.
<mrZeby> can i install it on c:\program files\Qbzr ?
<jam> We were hoping for mostly a comparison of where the projects have chosen different paths
<jam> But it can take a bit of balancing and editing to get there
<jam> I also haven't spent much time doing more than skimming them
<bos> yeah.
<bos> just wanted to bring it to your attention.
<jam> bos: care to flesh out some of the Hg points? (Preferably in an email)
<jam> I seem to recall you were pretty good with writing :)
<bos> jam: honestly, i probably don't have time.  i'm, shall we say, a bit overcommitted.
<jam> bos: np
<jam> We all get that way
<bos> nice talking, as always. cheers!
<jam> I just think of you as a well spoken person who has good opinions
<jam> Rather than just a random fanatic
<jam> later
<bos> :-)
<mrZeby> how to launch qbzr ?
<mrZeby> i have installed bzr and qbzr but i don't how to launch qbzr
<jam> mrZeby: generally you do something like:
<jam> bzr qannotate FILENAME
<jam> bzr glog
<jam> sorry
<jam> bzr qlog
<jam> etc
<jam> I don't know if there is an app you can just run
<jam> luks: ^^ ?
<mrZeby> jam : before i have install bzr and qbzr and when i launch bzr it automaticly try to launch qbzr but said that qbzr can be launch because of missing pyqt4
<mrZeby> jam i have install python installer
<jam> mrZeby: The best I can say is that you need to have the new bzr in your path
<jam> But *I* have never used it.
<jam> so I can't help much more than giving general pointers
<mrZeby> jam after ( now ) i use windows installer and... nothing about qbzr wjen launching bzr
<radix> mrZeby: ok, then does "bzr qlog" do something interesting?
<mrZeby> jam bzr error unknow command
<jam> mrZeby: Are you using the "Windows python installer" or the "Windows standalone installer" ?
<jam> And if you are using "Windows standalone installer"
<jam> did you install Bazaar from the "Windows standalone installer"
<mrZeby> first i have use python installer but know i have used windows installer
<mrZeby> i will retry with python installer and installing pyqt4 manually
<jam> You probably want to use: https://edge.launchpad.net/bzr/1.0/1.0/+download/bzr-setup-1.0.0.exe
<jam> coupled with https://launchpad.net/qbzr/trunk/0.8.0/+download/qbzr-setup-0.8.0.exe
<radix> s/edge.//
<mrZeby> i did it like this now...
<mrZeby> i continu trying the install...
<mrZeby> radiix thanks for your help... see you later perhaps :-)
<mrZeby> jam thanks for your help... see you later perhaps :-)
<jam> k
<jam> later
<mrZeby> radix thanks for your help... see you later perhaps :-)
<radix> :-)
<Solarion> how do I create an svn archive from bzr?
<Solarion> (upstream uses svn; I use bzr)
<radix> Solarion: I don't know if that's possible. why do you want to do it? does upstream just want to be able to merge your changes?
<Solarion> radix: upstream (Professor ;) wants me to create new archive with this code
<Solarion> eh, I can just do it with svn and push up the stuff
<radix> Solarion: so, bzr-svn supports committing back to SVN
<Solarion> radix: is what I've been using to stay sane.  ;)
<Solarion> but we're breaking new ground, and he wanted me to make a new repo
<radix> ah. I see. yeah, I don't know if there's a way to create an SVN repository straight up out of a bzr-svn branch...
<radix> maybe you can push it to an empty SVN repository?
<luks> you should be able to push to an empty svn reporitory
<radix> cool :)
<Solarion> I'm being told I need to merge then push
<Solarion> "these brnaches have diverged"
<luks> hm, I think I remember some bzr-svn announce mail where jelmer said he created a svn repo for bzr.dev
<luks> http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/29013
 * Solarion scratches his head.. how do you merge with no common ancestor, again?
<Solarion> bzr merge -r 1.. <src>
<Solarion> or not.  It didn't do anything.  :(
<Solarion> bzr merge -r ..2 <src>
<Solarion> thanks
<Solarion> bzr-svn keeps me sane.  :)
<jelmer> Solarion: hi
<jelmer> Solarion: did you manage to push into svn?
<Solarion> jelmer: yes, after a while
<Solarion> I had to use svnadmin to create the branch, tho.
<jelmer> you should also be able to use "bzr init-repo --format=subversion"
<Solarion> jelmer: wouldn't that make a local svn repo?
<jelmer> yes, it would
<Solarion> I'm wanting a local bzr, remote svn repo.  :)
<jelmer> creating a branch in a remote svn repo should be possible using svn-push
<Solarion> aah
<Solarion> then you branch it with bzr?
<jelmer> you can push an existing bazaar branch into subversion that way
<jelmer> e.g.:
<jelmer> bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
<jelmer> bzr init-repo --format=subversion svn.bzr
<jelmer> cd bzr.dev && bzr svn-push ../svn.bzr/trunk
<jelmer> or even "bzr svn-push svn+ssh://example.com/existing-svn/repo/trunk"
<jelmer> (where the trunk didn't exist yet)
<Solarion> maybe something's outta whack, 'cause I get connection refused.
<Solarion> ah well, it works now.  that's all that matters at the moment.
<statik> hi, I'm trying to set up bzr on a remote web host, where I can only install in my home directory
<statik> I am able to run bzr just fine when I am logged into the machine, but trying to push to a bzr+ssh path on that system gives me an error about not being able to find the bzrlib
<statik> I'm sure that there is some trick that causes pythonpath to not be set when I am executing a command remotely over ssh
<statik> anyone with better knowledge of ssh have a suggestion?
<dato> well, it's not a matter of python path, because the directory of the executable will be search for bzrlib
<dato> so probably is the executable itself that is not being found
<dato> there's an env variable for that, iirc
<statik> yes, I've tried setting bzr_remote_path
<statik> but I think the executable is being found
<dato> uhm
<statik> 'ssh webserver "which bzr"' shows me the bzr command is found
<dato> oh
<statik> ssh webserver python -c "import bzrlib" shows me the same error I get from running ssh webserver bzr --version
<dato> so in your instalation, is the executable and the bzrlib in different directories?
<statik> about no module named bzrlib
<statik> yes, I did python setup.py install --home ~
<jelmer> statik: what about python -c "import sys; print sys.path" ?
<dato> statik:  I'd recommend you move back the executable to the same directory as bzrlib, and make a symlink from that location to ~/bin or so
 * dato always run from source in $remotehostswithoutroot
<statik> basically the problem is that my .profile is executed and sets $PYTHONPATH correctly when I am logged in interactively
<statik> but it is not set when I invoke a remote command over ssh
<statik> dato: running with BZR_REMOTE_PATH set to the location of bzr in the extracted source tree rather than the installed location worked great! thanks
<statik> this is great, I prefer not to have to run setup.py anyway
<dato> you're welcome
<statik> is there a way for me to tell bzr to update the working tree on the remote server when I push? I'd like to use this to rollout updates to a web server, so I want the working tree updated when I push
<statik> I thought bzr+ssh would allow that, while sftp would not
<dato> install http://launchpad.net/bzr-push-and-update
<dato> voilÃ 
<dato> oh, but create a tree in the remote host first, with `bzr checkout .`
<statik> ah, great. thanks again!
<jam> dato: getting all the credit :)
<jam> is it voilÃ  or voilÃ¡ ?
<statik> jam: btw, CONGRATULATIONS! on 1.0
<jam> statik: thanks
<glyph> jam: hey, about push-and-update; I haven't had the opportunity to try it yet, but will it work on Windows?
<jam> glyph: as long as you have 'ssh' available
<glyph> jam: I don't :( I have plink
<glyph> jam: is there an easy way to make it consider the BZR_SSH variable?
<statik> heh, I wondered why I had not heard of this plugin before. jam you've been busy
<dato> jam, voilÃ  (http://fr.wiktionary.org/wiki/voilÃ )
<dato> jam: I'm giving you this tiny french lesson in exchange for the credit :-PP
<dato> heh
<dato> Top contributors
<dato>  bwinton    15 points
<dato>    Andrew Cowie    11 points
<jam> glyph: we probably could have it hook into the internal SSH code that bazaar hash
<jam> has
<jam> which  will either spawn ssh, plink, or use paramiko
<jam> glyph: it would be something like: vendor = bzrlib.transport.ssh._get_vendor()
<jam> connection = vendor.connect_ssh(..., command=[bzr_remote_path, 'update', path)
<jam> shouldn't be too hard to do
<glyph> jam: #176443 :)
<jam> ubotu: bug #176443
<ubotu> Launchpad bug 176443 in bzr-push-and-update "push and update does not work if the user does not have ssh, for example on Windows, where they might have plink" [Undecided,New] https://launchpad.net/bugs/176443
<glyph> jam: maybe that should have a dependency on a bzr bug though, to make that code not be internal / private
<jam> I don't care for this code :)
<jam> It is unlikely to change
<jam> and if it does
<jam> it should be simple to fix
<glyph> jam: OK
<glyph> jam: Parsing question though; "(I don't care) (for this code)" or "(I don't care for) (this code)"
<jam> glyph: first
<glyph> OK, works for me
<statik> jam: I think bzr-push-and-update should respect the bzr_remote_path config settings. would you agree?
<jam> statik: yeah, that would be part of it, too
<jam> also, you can set the remote path as part of a config entry
<jam> just in case it is different in different places
<jam> something like "bzr_remote_path=XXX" in ~/.bazaar/locations.conf
<statik> jam: yes, that is what I am doing. I think update_remote_branch() just needs to call config.get_bzr_remote_path()
<ubotu> New bug: #176443 in bzr-push-and-update "push and update does not work if the user does not have ssh, for example on Windows, where they might have plink" [High,Triaged] https://launchpad.net/bugs/176443
<jam> statik: by the way, patches are welcome :)
<statik> jam: just testing it now
<statik> jam: I think I need to have the local branch location inside update_remote_branch() in order to query the LocationConfig. does that seem reasonable to you?
<jam> statik: what is wrong with just doing:
<jam> config = target_branch.get_config()
<statik> jam: I like that better, let me try it
<jam> remote_bzr = config.get_bzr_remote_path()
<jam> or whatever the actual function is
<jam> technically, I think it means you can set it in
<jam> ssh://host/branch/.bzr/branch/branch.conf
<jam> which is a little funny
<jam> but it certainly makes the code simpler :)
<jam> statik: otherwise, you can just use "target_branch.base"
<jam> Which is the URL to that branch
<statik> jam: doesn't seem to work. target_branch.base is the path to the remote branch, while I have set bzr_remote_path in locations.conf for my local branch
<jam> statik: well, you can set bzr_remote_path for the remote branch :)
<jam> but sure
<statik> hmm
<statik> that might make more sense
<statik> I was thinking about it a bit backwards
<statik> I'm used to locations.conf referring to local locations
<statik> but I might want to set a different remote path for different machines, which is the whole point of having it in locations.conf
<jam> statik: it is set based on the remote URL
<jam> RemoteSSHTransport
<jam> location_config = LocationConfig(self.base)
<jam> so you have to set it based on the bzr+ssh://  url
<jam> statik: you should be able to do
<jam> [bzr+ssh://host]
<jam> bzr_remote_path=foo
<jam> I'm pretty sure that will catch any branches on that host
<statik> beautiful
<statik> I'll try that now
<statik> jam: it works! do you want this 3-line patch to go to email or the pastebin?
<jam> statik: commit it and send me a bundle :)
<statik> jam: ok
<statik> jam: dumb question, I should use the bzr send command, right? I'm getting an email with a sane subject line but don't see any bundle attached.
<Peng> FWIW, I use 'bzr send -o foo.patch' to save the bundle to a file and write my own email.
<Peng> I just do that because I haven't wanted to figure out how to configure send, and I like having a copy of the bundle, though. :P
<jam> statik: 'bzr send' doesn't work with a single branch
<jam> you have to give an upstream
<jam> so you need
<jam> bzr send lp:bzr-push-and-update
<jam> not
<statik> it found the upstream, I think I hit this bug https://lists.ubuntu.com/archives/bazaar/2007q3/032053.html
<jam> bzr send .
<jam> hmm... could be
<jam> I always use the "editor" client
<jam> since thunderbird on Mac doesn't work properly
<jam> Aaron has a workaround for some platforms
<jam> but apparently invoking the command line does different things
<jam> also, it depends on the thunderbird version
<jam> ah, but if xdg-email is spawning thunderbird
<jam> then it may not know about the workaraund
<jam> workaround
<statik> hey, setting mail_client in bazaar.conf fixed it all up
<jam> k
<jam> statik: you don't need the extra import at the top :)
<jam> but otherwise it looks good
<statik> oops
<jam> the only downside is it won't support BZR_REMOTE_PATH
<jam> apparently .get_bzr_remote_bzr_path() doesn't take that into account
<statik> oh, I thought when I read the patch from aaron that get_bzr_remote_path() does look at the environment
<jam> wait, it does
<jam> my grep was confused :)
<jam> so, patch merged and committed
<statik> and I've now pulled your merge into my local tree. wow this stuff all works great together
<statik> on that note, I'm going to spend sometime in the world outside. thanks for all the help, bzr rocks!
<jam> statik: have a good weekend
#bzr 2007-12-15
<sladen> http://bazaar-vcs.org/BzrVsGit#head-f21c73f492cf1dd00cb19548146501365b3911bd  (Familiar commands...) could do with a tweak, it's misleading whether it's talking about git or bzr, and depending on which one, could do with saying what the other one does (for comparison)
<ubotu> New bug: #176468 in bzr "Optional hostname for AuthenticationConfig" [Undecided,New] https://launchpad.net/bugs/176468
<jelmer> bzr-svn is now retrieving passwords from the Bazaar authentication.conf when committing :-)
<quik_> hey folks
<quik_> my local bzr working copy has had a lock on it since the push failed to a remote server. how do I unlock / clean up the respository?
<dewd> dewd@rubynho:~$ bzr help break-lock
<dewd> Purpose: Break a dead lock on a repository, branch or working directory.
<quik_> Thanks!
<dewd> :-) bzr has some lovely help and interface. rather cool.
<kripken> Is there any way to change how bazaar handles certain file types? For example, I'd like it to _not_ treat opendocument files as binary (these are zipped files). Instead it would be cool if it unzipped it to get the XML inside, then worked on that
<mlh> kripken: that _would_ be cool
<mlh> it's been discussed idly from time to time if I recall correectly.  But nothing done.
<kripken> mlh: I would be glad to code it myself, actually. If there is a possibility it might be merged into the code.
<mlh> kripken: make a plugin
<mlh> it's not just zip files; the idea is extendible to all archive files
<mlh> a related idea - of mine - is to make objects in the tree a proxy of sorts for real file elsewhere in the system
<kripken> mlh: I looked at the existing plugin hooks, none seem appropriate. So I'm not sure how to make it a plugin (add a hook?)
<kripken> not sure I understand your idea that you explain here
<mlh> yeah my idea requires a bit more explainging
<mlh> but as for yours .. I think if you want to code the way to go is to make a plugin
<mlh> good night  (0036 here)
<kripken> ok, thanks
<Solarion> congrats on 1.0
<mdke> hi all
<mdke> trying to branch and getting this - bzr: ERROR: unknown branch format: Bazaar Branch Format 6 (bzr 0.15)
<mdke> any ideas?
<mdke> bzr version says bzr (bazaar-ng) 0.8.2
<frsk> Have you upgraded the branch using bzr-1.0?
<mdke> I don't know
<mdke> the branch is http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy
<mdke> is bzr 0.15 earlier than bzr 0.8.2, or later?
<mdke> ah, perhaps it is. how odd
<jelmer> mdke: 0.15 is later
<mdke> bit confusing :) OK i guess that's the reason for the error
<dennda> Is it possible to get a bit more verbosity while pushing/pulling? (Like speed / time remaining?)
<jelmer> dennda: I believe there was a transport statistics (number of bytes transferred, etc) plugin
<jelmer> Things like ETA are not supported afaik
<Odd_Bloke> mdke: 0.8.2 is incredibly old, you should really upgrade. :)
<Leonidas_> hi
<Leonidas_> is there somewhere a bazaar changelog?
<beuno> Leonidas_, yes, the NEWS file would be the changelog
<Leonidas_> oh, ok. I was looking for the release nots which are not online for 1.0
<beuno> Leonidas_, you're right, a summary would be nice. I guess the devs are all burned out from the release
<Leonidas_> understandable.
<Leonidas_> Fine, I found what I was looking for - the new repository format and the update instructions.
<Leonidas_> thanks
<beuno> Leonidas_, welcome'. And if you have any feedback about the release, please drop by here or the mailing list  :D
<Leonidas_> :)
<Leonidas> But I have some things that I'd like to see in bzr as well
<Leonidas> for example colors. Sounds stupid at first, but I quite like colored output
<jelmer> Leonidas: have you seen the cdiff command? it's part of bzrtools
<Leonidas> no, not yet. But it's not only diff which is colorful, but also git status etc.
 * Leonidas is going to check cdiff out at some point
<Leonidas> hmm, http://doc.bazaar-vcs.org/latest/developer/packrepo.html gives a 404 (URL taken from the announcement)
<Leonidas> so, do I understand it right that pack-0.92-subtree supports subtrees like SVN?
<beuno> Leonidas, that would be a typo, it's in: http://doc.bazaar-vcs.org/latest/developers/packrepo.html
<Leonidas> I'm quite confused by all these formats. Knits, packs, possibly more (?)
<beuno> Leonidas, I'd go with the default (packs) unless you need something fancy
<Leonidas> beuno: ok.
<wolever> I'm getting an error because my local branch format is "... Branch Format 6 ..." but the remote bzr (version 0.8.2) can't read it (says "unknown branch format").  Any way around this? (short of updating the remove bzr)
<wolever> (I'm getting the error on a "bzr branch ...")
<abadger1999> wolever: You could downgrade your local branch using bzr upgrade
<wolever> mmm ok, I'll give that a shot. Thanks
<Peng> Dude.
<Peng> 0.8.2 is ANCIENT.
<wolever> There is one thing more ancient though: the sysadmins who maintain the system I've got to use
<Peng> Heh.
<wolever> I'm up to 1.0 on all my machines
<Peng> Ok, good.
<Peng> Remote bzr? Do you need a remote bzr? You can just use sftp.
<wolever> Awe crap. "bzr: ERROR: [Errno 8] Exec format error" on a "bzr ci"
<wolever> (this is just after apt-get remove-ing .8.2 and installing 1.0 from source)
<Peng> Are the ancient formats still tested?
<wolever> This particular problem is happening with a repo built by .9.2 and client version 1.0
<wolever> Is there any way to force a bit more of a stack trace?
<wolever> Ah, ok.  It looks like it's just having a problem launching the editor.  If I `bzr ci -m ".."`, it works.
<batoms> why do i get the "Tags not supported by BzrBranch5" error when i try to push my changes to launchpad
<batoms> how do i fix it?
<beuno> batoms, what version of bzr are you using?
<batoms>  1.0.0rc1
<beuno> that's odd
<beuno> and the branch was created with 1.0?
<dato> batoms: if you're interested in propagating your tags to launchpad, with `bzr upgrade sftp://bazaar.launchpad.net/~you/etc`
<batoms> no, the branch was created probably around 0.16 or 0.17
<beuno> there you go, a much more educated answer.  dato to the rescue, as usual  :D
<beuno> batoms, you also might want to upgrade locally
<dato> hey beuno :)
<batoms> i've done a bzr upgrade --default
<beuno> heya dato!
<batoms> and bzr upgrade --dirstate-tags
<beuno> batoms, then you just need to upgrade the branch in LP, as dato suggests
<batoms> i thought i tried that but i'll try again
<batoms> is it any different over bzr+ssh://
<dato> I don't think upgrade over bzr+ssh:// works
<dato> it didn't use to, maybe it does now
<dato> batoms: it doesn't hurt to try
<batoms> maybe that was my problem then
<batoms> is there an benefit to using bzr+ssh over sftp
<batoms> or vice-versa
<dato> bzr+ssh is faster
<matkor> Hi !
<matkor> olive-gtk: after hitting "log": AttributeError: type object 'gtk.Action' has no attribute 'set_tool_item_type'
<matkor> too old gtk ?
<batoms> damn this bzr upgrade is slow on my connection
<matkor> Easiest way to generate patch -p1 for changes made in working tree ?
<abentley> matkor: bzr diff -p1
#bzr 2007-12-16
<matkor> abentley: Thanks a lot !
 * beuno wonders why nobody with access to planet.bazaar hasn't made a post about 1.0
<Peng> planet.bazaar?
<jelmer> http://planet.bazaar-vcs.org/
<Peng> Neat.
<TFKyle> they're all too busy drinking I assume
<jdub> query for interest's sake
<jdub> after upgrade:
<jdub> 4.7M    .bzr/
<jdub> 14M     .bzr.backup/
<jdub> after reconcile:
<jdub> 9.1M    .bzr/
<jdub> 14M     .bzr.backup/
<jdub> why is that?
<jdub> (re: size of .bzr)
<Peng> jdub: obsolete_packs?
<jdub> Peng: ah, that's added during reconcile?
<Peng> jdub: The old packs are backed up whenever they're recreated ("bzr pack", auto-packing, and reconcile).
<jdub> righto
<jdub> well, i'm all upgraded to 1.0 now -- yum :-)
 * TFKyle stabs rapidshare, this is starting to get ridiculous
<fullermd> abentley: There, I just submitted the upgrade req for bzrtools 1.0, and optionalized the graphviz dependancy.  I don't have to smack me now   ;)
<Kamping_Kaiser> hi all. is an svn repo import something that can only be done as a one off, or can i reimport if the svn repo changes?
<Alexia_Death> Hello. I have a theoretical question about bazaar.
<Alexia_Death> namely would it be usable as local repositroy mangagement tool under a "add-on" manager?
<bob2> Kamping_Kaiser: you can pull and push from branches in svn
<Kamping_Kaiser> bob2, thanks.
 * Alexia_Death is putting togheter a consept for GIMP add-on library that would be a crossbreed between apt portage and SVN...
<Alexia_Death> and bidirectional all the way.
<soxs> sry, I am a total bzr newbie
<soxs> *g*
<soxs> so let me ask a very simple, stupid q
<soxs> I want to update exaile to the latest version
<soxs> so I did bzr checkout http://bazaar.launchpad.net/~exaile-devel/exaile/main exaile
<soxs> so I got the dev branch
<soxs> but how can I update my installed programm
<soxs> update
<soxs> located /usr/lib/exaile
<soxs> I know that I have to use bzr update
<soxs> but from which folder??
<luks> in the bzr branch
<soxs> the checkout folder or /usr/lib/exaile
<soxs> thx
<soxs> ^^
<luks> putting it to /usr/lib/exaile is probably a job for some install script
<bob2> is there a README or INSTALL file in the tree you checked out? (this is application-specific, nothing to do with bzr)
<soxs> well, exaile is a gnome music player, aming to be similar to amarok but or gtk
<soxs> f
<kripken> most likely you would run "make install" to install it to the actual location (/usr/lib in this case)
<soxs> well, thx
<soxs> o, this messed the installed version up :-/
<soxs> well, does't really matter.. gone compile it rom source
<mrZeby> somedoby have try to install bzr and qbzr on windows vista ?
<mrZeby> hello re.. how to install pyqt4 ?
<luks> mrZeby: are you using the compiled bzr or from sources with your own python installation?
<luks> http://www.riverbankcomputing.com/Downloads/PyQt4/GPL/PyQt-Py2.5-gpl-4.3.3-1.exe
<mrZeby> lucks : thanks for answering.. i try to install python based installers with my own python 2.5 installation
<luks> then install pyqt using the link above
<mrZeby> so easy ? on this site they say : instal SID, use make to compile source,... ?
<luks> you can uncheck dev tools, docs and examples when installing it
<luks> which site?
<mrZeby> SIP
<mrZeby> on the doc of http://www.riverbankcomputing.com/Docs/PyQt4/pyqt4ref.html
<luks> always first look on pages like http://www.riverbankcomputing.co.uk/pyqt/download.php :)
<mrZeby> but perhaps i dont need to recompile anything to use qbzr ?
<luks> no, you don't
<luks> just use the pyqt installed
<mrZeby> nice new you give to me :-)
<luks> installer
<mrZeby> i soo stupid.. i had no see the download link for binaries !!!!
<mrZeby> re hello all
<mrZeby> i have installed bzr and qbzr... but how to launch qbzr ?
<luks> mrZeby: there is no "qbzr" to launch
<luks> it's just a bunch of separate commands
<mrZeby> a command like qlog made on a versionned directory will show some informations in a window ? something like this ?
<luks> yes
<mrZeby> so.. for windows users there is no GUI like winCVS for CVS or rapidSVN for subversion... no so user friendly
<luks> qbzr will have a wincvs like interface in one of the next version
<luks> but not for now
<luks> there is olive, but it doesn't work well enough in my experience
<mrZeby> yes i have try olive and find is not really usable
<mrZeby> and tortoiseBZr not so powerfull as tortoisesvn ou tortoisecvs
<luks> I mainly use command line, that's why qbzr looks like it looks
<mrZeby> you are the qbzr developer ?
<luks> yes
<mrZeby> ouah nice to meet you :-)
<luks> :)
<mrZeby> it'is the first time i speak with a software i will use :-)
<jelmer> it would be nice to have somebody back hacking on tortoisebzr..
<mrZeby> i speak with the developer of a software...
<mrZeby> then i use
<mrZeby> nice nice nice
<mrZeby> well
<mrZeby> the community for bzr looks to be very active
<mrZeby> jelmer : and you ? your are the tortoisebzr developer ?
<jelmer> mrZeby: I work on various bzr-related bits and pieces
<jelmer> I worked on the original version of tortoisebzr and I work on bzr-gtk
<mrZeby> you are mostly linux developers ?
<jelmer> yes, the majority is, though there are some people on windows as well
<jelmer> and some people using both
<mrZeby> jelmer, luks : thanks for explanations, have a day end of day... see you.. bye
<mrZeby> have a nice end of day
<jelmer> thanks, you too
<mrZeby> i english is a little bit funny lol
<Stavros> hello
<Stavros> is there an easy way to disable push-on-commit?
<jelmer> Stavros: "bzr unbind"
<Stavros> ah, thanks
<Stavros> when does it bind by default?
<jelmer> Stavros: "bzr co" binds by default
<jelmer> "bzr branch" does not
<Stavros> is that the only difference between the two?
<jelmer> yes
<Stavros> ah, thanks
<thumper> morning
<izm99> I've started a a new project and have a couple commits but I want to branch what I'm currently working on to a ".experimental" or something.  What's the best way to do this?
<luks> izm99: you mean something like "bzr branch main experimental; cd experimenta; bzr merge --uncommitted ../main" ?
<izm99> luks: i'm not sure...  :P  I started a project by doing "bzr init; bzr add;" in a project folder.  I've since done a couple commits, but what i've done most recently, i don't want to commit to the main (and somewhat stable) branch...  I want to commit it into a new branch which I will merge back later.  if that makes sense.  I'm just learning this (obviously)  :)
<luks> izm99: yes, then merge --uncommited will do what you want
<luks> just branch of the main branch, merge the uncommitted changes to the new branch, and bzr revert in the main branch
<john76> Hi all
<john76> New to Bazaar and love everything I've seen so far but concerned about one feature
<john76> Does remove really delete all history for a file?
<jelmer> john76: no, it does not
<jelmer> it's still visible in history
<john76> good, I've read the docs and tried it myself and had results which suggest it did
<john76> I tried bzr log <deletedfilename>
<john76> plus tried to uncommit
<jelmer> uncommit+revert should bring it back
<john76> but I haven't got far enough in the docs I guess to know what I'm really up to
<john76> ah, excellent
<john76> I'll keep reading then, my concern became to great to ignore
<john76> really appreciate the help
<john76> thanks
<izm99> luks: so within my project folder, "bzr merge --uncommitted ../project.experimental" ?
<mwhudson> izm99: no
<mwhudson> other way around
<izm99> :/
<mwhudson> within your project.experimental folder, bzr merge ../project
<izm99> oh...  merge <destination branch> <parent> ?
<izm99> ok, I only have "project" which is the folder I'm in.  This is the original, it's not centralized or anything.  so "../project" is the current folder.  I want to create a new "../project.experimental" branch with what i've current done (uncommitted).  Should I manually rename the folder to "project.experimental"?
<izm99> I tried following what's been suggested so far in a new simple project, in "project" I made some files, added them, then "bzr merge --uncommitted ../project" ..  It said All changes applied successfully, but that's itself.
<luks> izm99: in the folder above "project" run "bzr branch project project.experimental"
<luks> then go to project experimental and run "bzr merge --uncommitted ../project"
<luks> and in project run "bzr revert"
<jml> have the bazaar-vcs.org debs been updated?
<izm99> luks: ok, thanks, I'll try that.
<luks> that way you will have two branches, one only with the "stable" committed changes, and the experimental one with uncommitted changes
<thumper> jml: not yet
<jml> what a pain.
<izm99> luks: sweet, that worked.  thanks.  :)
<ricardokirkner> hi. Is there any documentation (I couldnt find any) on how to use the bzr smart server?
<mhb> Hello, I get AssertionError: unexpected response code ('error', "Unknown branch format: 'Bazaar pack repository format 1 (needs bzr 0.92)\\n'") whenever I want to push a change via bzr+ssh.
<mhb> using bzr 1.0.0.candidate.1 on python 2.5.1.final.0 (linux2) .
<mhb> hmm, sftp seems to work well enough. forget it.
<jml> mhb: do you know what version of Bazaar is running on the server?
<mhb> jml: I guess that could be it. Thanks!
<jml> ricardokirkner: let me have a look.
<jml> ricardokirkner: one of the reasons you might not be able to find much documentation is that it's actually quite simple.
<jml> ricardokirkner: have you seen http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#running-a-smart-server?
<ricardokirkner> ok, great
<ricardokirkner> thanks
<jml> ricardokirkner: np.
<AnMaster> 1.0 out?!
<AnMaster> cool!!
<AnMaster> where do I find docs on the gpg signing stuff then?
<jelmer> hi AnMaster
<jelmer> the user guide contains some documentation probably
<jelmer> verifying signatures isn't possible yet afaik
<igc> morning all
<jelmer> hi igc
<jelmer> congrats on 1.0 (-:
<igc> hi jelmer - great to hear from you
<igc> how are things?
<jelmer> Very well, thanks :-)
<poolie> hello jelmer, igc
<igc> hi poolie
<jelmer> hi poolie
<jelmer> congrats to you as well!
<AnMaster> does bzr have anything like the svn:externals thing?
<Peng> AnMaster: Not yet.
<AnMaster> ok
<AnMaster> Peng, when will it be added ?
<AnMaster> 2008?
<AnMaster> is there a change log between 0.92 and 1.0?
<Peng> AnMaster: Dunno. There's an experimental disk format that supports it, but the commands don't.
<Peng> AnMaster: NEWS.
#bzr 2008-12-08
<jml> lifeless: how hard would it be to add a rename-thread feature to loom?
<lifeless> jml: trivial - load the dict, alter it, save it, change the current nick (which points into the dict) IF its the same as teh thread breaing renamed
<lifeless> jml: got a few minutes?
<jml> lifeless: I will in a bit.
<jml> lifeless: ok. what's up?
 * jelmer once again wishes Python did tail recursion properly
<mwhudson> i need a plugin that has an "oh crap, i've been editing in trunk again" command
<igc> hello all
<mwhudson> hello igc!
<igc> hi mwhudson
<mwhudson> igc: i gave my bzr talk at osdc last week
<igc> how did it go?
<mwhudson> alright, i think
<mwhudson> i went for a fairly gentle introduction to dvcs
<mwhudson> most people had used cvs, almost all svn, a few bzr, about the same git, not so many hg
<mwhudson> a good way to start a talk: "how many of you have used branches with subversion?"
<mwhudson> (almost all the hands go up)
<mwhudson> "how many of you enjoyed it?"
<mwhudson> (most hands go down)
<igc> mwhudson: :-)
<spiv> mwhudson: that bit was very good :)
<mwhudson> i do think it's worth making the point that most "next gen" vcs tools are just _better_ than svn
<mwhudson> even if you don't do distributed things
<pygi> mwhudson, tho people sometimes just don't care :)
<mwhudson> pygi: well yes, but that's fine
<mwhudson> pygi: but some people also say "this is a one man/in house project, the d in dvcs doesn't get me anything"
<pygi> mwhudson, right...
<spiv> jelmer: congrats on the 0.5.0rc1 !
<jelmer> spiv, thanks :-) It took me long enough...
<pygi> jelmer, you really never sleep o.O
<pygi> isn't it like 5AM for you? o.O
<jelmer> yeah, I just wanted to get this release out..
<jelmer> I do usually sleep at this time of day :-)
<jelmer> pygi, you're still in CA ?
<pygi> jelmer, when was  I in CA? :P
<pygi> jelmer, I'm in Croatia :P
<jelmer> pygi, I figured it would be 5 AM for you as well..
<pygi> jelmer, yes, it is 5AM for me too :p
<jelmer> so I assumed you were at UDS
<jelmer> pygi, heh, ok
<pygi> congrats on the release ;)
<jelmer> thanks :-)
 * jelmer sees he has another 5 hours left for sleep, might as well use them
<jelmer> g'night!
<pygi> night night :)
<mwhudson> i don't bother thinking about what time it is for someone before pinging them on irc any more
<spiv> jelmer: I thought you were sleeping :P
<shelagh> I'm trying to use bzr for a local file that I want to get weekly snapshots for.
<shelagh> I think I've stuffed the setup stage as I keep getting asked about branches, when I try to add the file to bzr.
<shelagh> What I want is essentially simple (I thought). But I'm obviously missing something.
<shelagh> I've used rcs before, but eventually this file will be mirrored on a file server and so bzr seems like a better choice.
<AfC> shelagh: you're describing about the simplest use case going
<AfC> $ bzr init .
<AfC> $ bzr add filename.txt
<AfC> $ bzr commit -m "It is 6 o'clock and all is well"
<AfC> followed by a commit next week.
<AfC> (on the assumption that you want to make . the Bazaar branch)
<vila> hi all
<shelagh> AfC: thanks for that.
<shelagh> AfC: so I need to go into the directory that I put into bzr and add the file?
<shelagh> I need to practice this at home before I try it at work again.
<jaavaaguru> regardless of how /win 12
<jaavaaguru> oops
<Peng_> Hmmm, I think turning off plugins may have fixed my Loggerhead memory issues.
<Peng_> I haven't given it much time to confirm it, but it only grew a few KB in 30 minutes. Before, it would've been...10 or 20 MB, maybe?
<spiv> Peng_: wild guess... you had bzr-svn installed?
<Peng_> spiv: Heh, it's always bzr-svn, isn't it? :P
<Peng_> Since my last update it's been growing a bit, so that may not have fixed it anyway.
<Peng_> OK, I can say now that disabling plugins definitely seems to have fixed it.
<spiv> Peng_: Interesting!
<Peng_> Is it possible to exclude a specific plugin from being loaded from code, or should I just uninstall it?
<spiv> Peng_: echo 'raise ImportError' > ~/.bazaar/plugins/plugin_name.py
<spiv> Peng_: Oh, from code :)
<spiv> Peng_: You can probably do something like "import sys; sys.modules['bzrlib.plugins.plugin_name'] = None"
<spiv> Which IIRC is how sys.modules caches that an import cannot be found.
<Peng_> So when bzr imports it, it would load the dummy instead of the real module? Huh, neat.
<spiv> (if you go with the dummy module that raises ImportError, don't forget to remove the .pyc as well as the .py when you want to remove the dummy)
<Peng_> The sys.modules hack seems to work. Neato!
 * spiv -> sleep
<Peng_> Good night.
<Arjen> What would be the best way to count the number of commits in a repository?
<etank> Arjen: just a guess but wouldn't bzr log show you the revno? is that the same thing?
<Arjen> That's only the mainline
<Arjen> I want the total number of commits
<etank> im trying to get the all-in-one install of bzr for windows to work
<etank> it works fine on one machine but not another
<etank> it is the 1.9 version that i am working with
<luks> asac: bzr info -v
<luks> er
<luks> Arjen: ^
<etank> argh
<etank> finally got my bzr on windows to work
<etank> had to reinstall then do "set BZR_SSH=paramiko"
 * etank is happy now :)
<etank> pingdotfm: finally got my bzr on windows to work. had to reinstall then do "set BZR_SSH=paramiko" to get it to work.
<etank> oops :)
<Tak> wait, how did you get your bzr on windows to work? :-P
<etank> Tak: i used the all-in-one installer
<etank> how can i make bzr always use paramiko instead of plink?
<etank> it keeps going back to plink and i get "ssh implementation is Putty's plink."
<luks> hm, I though it uses paramiko by default
<luks> you can set the BZR_SSH variable globally
<luks> Control Panel -> System -> Environment Variables or something like that
<etank> thanks luks that did the trick
<oldman> is there an easy way to 'forget' remembered submit branch locations?
<jelmer> oldman, see .bzr/branch/branch.conf
<jelmer> you can also get it to remember a new location by using --remember
<oldman> excellent, thanks
<jam> Good morning to all
<jam> Anyone have experience debugging DNS issues on Windows 2003?
<jam> It seems that there are DNS servers, and doing "nslookup" works, but doing "socket.gethostbyname()" does not.
<etank> jam: maybe flush your dns cache first
<jam> I don't know if anyone responded, I seemed to have a network glitch
<etank> jam: maybe flush your dns cache first
<jam> etank: well, I did do "repair" which is supposed to do that, and I've even rebooted that machine
<etank> ipconfig /flushdns
<jam> (It is a virtual host, which we use for the win32 builds)
<jam> I'll try that, I guess
<jam> I found one google result that looked interesting, but it is a "members only" page: http://www.experts-exchange.com/Networking/Unix_Networking/Q_22643954.html
<etank> jam: i have an account there if you want me to look at it for you
<jam> etank: still failing
<jam> etank: that would be nice, though I don't know if it will actually know the answer
<jam> probably worth trying
<jam> btw, do you remember the location of "hosts" and "lmhosts" ?
<etank> c:\windows\system32\drivers\etc
<jam> I never quite understood that. Maybe because the network stack was BSD based?
<etank> jam: here is the "answer" from the ee page http://dpaste.com/97018/
<etank> may not be of any use though
<jam> ugh
<jam> yeah, not the problem I'm having
<jam> it seems that lmhosts.sam is empty, hosts is almost empty
<etank> thats normal
<jam> the one interesting entry in 'hosts' does indeed resolve for "gethostbyname()"
<etank> should have a "127.0.0.1       localhost" by default and that is it
<jam> It has 2 lines:
<jam> 127.0.0.1            LOCALHOST
<jam> 10.0.10.14 vzsveaddress
<jam> I assume the latter has to do with how the virtual host was set up
<etank> or you wanted it to resolve even if the dns server was not found
<jam> sure, but regardless those are the only ones that "work" on this machine for "gethostbyname()" while "nslookup" seems to do just fine.
<etank> what module does bzr use to read the config?
<etank> ConfigParser?
<jam> ConfigObj
<jam> bzrlib/util/configobj/configobj.py
<jam> similar, but also supports writing
<jam> and has support for some stuff that we don't really use
<jam> like lists
<etank> cool
<jam> interesting, it seems to be "the default gateway is not on the same subnet + subnet mask as the ip address"
<jam> so my guess it is getting confused by that
<jam> ok, really weird
<etank> that sounds about right
<jam> the IP address is a public address
<jam> but the default gateway is a 192.168 addres
<etank> are you natting or bridging the connection?
<jam> I have no idea
<jam> this is a virtual host provided by someone in Australia
<etank> oh
<jam> as I can connect via terminal services and openssh, my first guess would be bridge
<jam> but I don't know yet
<jam> I think it is at the point that we need to escalate to their support, but I think only poolie can do tha
<jam> that
<jam> yeah, I can submit a support request, but it will go to his email address, which makes it hard for me to respond :)
<jam> lifeless: ping
<lifeless> jam: pong
<jam> just asking if you could give poolie a poke if you see him
<jam> I need him to open a support case with the host of kerguelen
<lifeless> k
<jam> thanks
<lifeless> I think he's still to arrive at the venue
<jam> lifeless: it isn't critically urgent, so you don't have to go search for him, but if you do run into him, just let him know
<jam> thanks
<gioele> hi
<gioele> is there a way to clean the obsolete_packs dir (pack-0.92 format)
<gioele> I used bzr pack to save some space but I ended up doubling the space used: X in packs and X+something in obsolete_packs
<jam> gioele: rm .bzr/repository/obsolete_packs/*
<jam> It will clean itself out eventually
<jam> at the next time it goes to pack/autopack
<gioele> jam: is that safe to do?
<jam> don't delete the *directory* but you can delete the files
<jam> I would probably run "sync" first
<gioele> why are these "obsolete" packs kept around?
<jam> because we don't know if the OS will order things correctly
<jam> and actually write things to disk before the system crashes
<jam> as it is your precious ancestry we are dealing with
<jam> we default to safe
<gioele> jam: is it my $HOME backup, almost as precious as my ancestry ;)
<jam> so if you know you have another backup, you know the system won't crash right away, etc
<jam> sync && rm .bzr/repository/obsolete_packs/*
<jam> should  be fine
<jam> just make sure to not delete the directory itself
<gioele> ok (I have a backup of the backup anyway)
<gioele> done
<gioele> everything seems fine
<gioele> thanks jam
<jam> happy to help
<lifeless> jam: I suggest mailing him
<jam> I did
<lifeless> :)
<lifeless> jam: I intend to read your updated commit-uses-add-by-delta patch, haven't had time to grab a diff vs my branc to see the changes
<jam> I'm pretty sure I summarized the important changes in the email.
<jam> but that doesn't give you a code-level view
<lifeless> right
<lifeless> cocneptually I'm cool with it
<seb_kuzminsky> i'm converting a smallish svn repo with a couple of branches to bzr
<seb_kuzminsky> i'm planning to use "bzr svn-import"
<seb_kuzminsky> i'm planning to put it in a shared bzr repo
<seb_kuzminsky> i'm using bzr 1.10
<seb_kuzminsky> what repo format should I use (for "bzr init-repo")?  --1.9?
<seb_kuzminsky> --1.9-rich-root?
<lifeless> seb_kuzminsky: 1.9-rich-root
<lifeless> though I think svn-import makes its own repo
<lifeless> poolie: jam was pinging for you
<seb_kuzminsky> thanks lifeless
<jelmer> lifeless, yep, it does
<seb_kuzminsky> so i dont need to init-repo before svn-import?
<seb_kuzminsky> i did a 'bzr svn-import' and it gave me a rich-root-pack repo, not 1.9-rich-root
<seb_kuzminsky> i have bzr-svn 0.4.16
<seb_kuzminsky> and bzr 1.10rc1
<jelmer> seb_kuzminsky, that's correct
<jelmer> seb_kuzminsky, rich-root-pack should work fine as well
<jelmer> seb_kuzminsky, and is supported by more older versions of bzr
<seb_kuzminsky> going back to 1.0 it says
<jelmer> seb_kuzminsky, if you would like to use 1.9-rich-root, you can use "bzr upgrade --1.9-rich-root" in that directory
<seb_kuzminsky> ok thanks jelmer
<seb_kuzminsky> jelmer: it worked :-)
<seb_kuzminsky> jelmer: but is there a way (some --schema perhaps) to turn svn's trunk/branches/tags structure into native bzr representations?
<seb_kuzminsky> i'll try --scheme=trunk
<seb_kuzminsky> the default is "auto", but even with -v, svn-import didnt tell me what it was doing
<seb_kuzminsky> and it seems to have used "none" scheme, instead of "trunk" which is what i think i want
<Peng_> Thanks to that hack to load most plugins but not bzr-svn, it seems bzr-svn is the source of my Loggerhead memory leak..
<beuno> Peng_, that's interesting
<jelmer> Peng_: which bzr-svn ?
<jelmer> beuno, does loggerhead use find_branches() at all?
<beuno> I guess we should add a --no-plugins to server branches?
<beuno> jelmer, no, it shouldn't
<jelmer> beuno, what about find_bzrdirs() ?
<Peng_> jelmer: Latest 0.4 branch.
<beuno> jelmer, nope
<jelmer> beuno, how does it find the branches then in serve-branches ?
<beuno> Peng_, want to write a patche for --no-plugins?   :)
<beuno> jelmer, it tries Branch.open()
<Peng_> beuno: --no-patches. :P
<jelmer> Peng_, depending on how loggerhead is trying to open branches, 0.5 fixes that issue
<beuno> Peng_, also, without bzr-svn, is the memory usage down?
<Peng_> beuno: Yes, it is.
<beuno> Peng_, w00t!  by how much aprox?
<jelmer> beuno, ah, thanks
<jelmer> Peng_, so, yes, bzr-svn 0.5 should fix the memory usage issue
<beuno> poolie, lifeless, james_w  ^^^ LH memory usage down, but still blows up on production
<Peng_> beuno: Oh, right. I forgot about the improvements. I can't really say at this point; all I can say is that disabling bzr-svn stopped it from constantly growing.
<Peng_> jelmer: You figure 0.5 is usable enough at this point that I can try it safely?
<Peng_> Hmm, I'm not even sure I ever use bzr-svn on that machine.
<jelmer> Peng_: Yes, I think so
<jelmer> Peng_, There was a similar bug a while ago in "bzr multi-pull"
<seb_kuzminsky> i did "bzr svn-import --schema=trunk" and still it gave me a single bzr branch with /trunk, /branches, and /tags
<jelmer> seb_kuzminsky, you want --scheme=trunk0
<seb_kuzminsky> "bzr branches" returns without producing any output, and "bzr heads" shows just one head
<seb_kuzminsky> jelmer: oh ok
<poolie> hi jam, beuno, lifeless
<jam> hi poolie, how is mountain view?
<jelmer> seb_kuzminsky, though I think it should yell at you if you use --schema
<jelmer> (since that is not a valid argument)
<seb_kuzminsky> hrm, sorry, i did type --scheme, my bad
<seb_kuzminsky> --scheme=trunk resulted in no branches in the bzr repo
 * Peng_ tests bzr-svn 0.5.
<seb_kuzminsky> trying --scheme=trunk0 now
<jelmer> seb_kuzminsky, in that case trunk0 won't help much I think
<jelmer> seb_kuzminsky, you might want to try 0.5 as well then
<seb_kuzminsky> jelmer: yea after "bzr svn-import --scheme=trunk0" i still have no branches
<seb_kuzminsky> that's ok, i didnt really want my branches anyway....
<jelmer> seb_kuzminsky, you can get the individual branches manually by running "bzr branch <repos-path>/trunk my-trunk"
<mwhudson> morning
<jelmer> hey mwhudson
<seb_kuzminsky> jelmer: right, good idea
<seb_kuzminsky> jelmer: i'm doing this on the machine that hosts the svn repo and i'm using file:// urls to the svn repo, might that have anything to do with the problem?
<jelmer> seb_kuzminsky, no, that shouldn't matter
<jelmer> seb_kuzminsky, I think it's just a general problem causing bzr-svn to use the guessed scheme rather than the specified one
<seb_kuzminsky> ok
<jelmer> seb_kuzminsky, I think it's fixed in bzr-svn 0.5.0~rc1
<jelmer> seb_kuzminsky, looking at the code, I'm sure it's fixed in 0.5
<jelmer> seb_kuzminsky, did you only just start using the trunk/, branches/ structure?
<seb_kuzminsky> the svn repo was created with that structure
<seb_kuzminsky> it has two branches (plus trunk) and no tags yet
<seb_kuzminsky> of the two branches, one is about halfway back in history, and the other is very recent
<seb_kuzminsky> history is about 300 revs long
<Necoro> hmm - is pycurl needed for anything under linux?
<Necoro> because it is not mentioned anywhere - but in the logs there are lots of complaints about not finding it
<LarstiQ> Necoro: the only thing I can think of that it possibly adds over plain urllib is ssl certificate checking
<lifeless> .join #ubuntu-foundations
<jam> LarstiQ: maybe we should only make it the preferred default for https connections, rather than both http and https
<jam> Necoro: we don't need it, we just use it if we find it, and log when we don't find it
<LarstiQ> jam: that sounds like an excellent idea.
<jam> vila: what do you think?
<Necoro> jam: ah ok - the "DependencyNotFound" just sounded quite drastic and I thought whether it could be a reason for some errors ;)
<jam> LarstiQ: patch submitted, though I want to hear what vila thinks before we switch
 * LarstiQ nods
<poolie> hello jam
<jam> hi poolie
<jam> For some reason the login you gave us before isn't working for me now
<jam> trying to follow your support request linke
<jam> link
<poolie> ah :/
<jam> I was able to use it just this morning
<poolie> i reset my password because i didn't have it on my laptop :)
<jam> when I wanted to try myself
<poolie> can you encrypt it and send it back to me
<poolie> plesae
<jam> sure
<poolie> please*
<jam> poolie: sent
<poolie> ok, it's reset back to that
<poolie> so you're welcome to use that to file or comment on support requests
<poolie> just login as mbp@canonical
<Peng_> If http defaults to urllib and https defaults to curl, and an http url redirects to https, will it still switch to curl?
<poolie> yes
<Peng_> :)
<lifeless> abentley1: mirror stuff: init-branch .; set-stacked(mirror_url);pull (official-source)
<jam> poolie1: the only support ticket I see is the "System is not available as the server is currently stopped" ticket
<jam> which I don't think is the same
<poolie1> it is the same, i added on to that ticket
<jam> ah, I see it now
<jam> yeah
<poolie1> because they broke this while trying to fix the first
<jelmer> Is it possible to commit when one of the parent revisions is a ghost?
<jelmer> In particular, what sort of arguments should CommitBuilder.record_entry_contents() receive in that case, since it requires a list of parent inventories.
<lifeless> jelmer: its a little tricky:)
<lifeless> jelmer: but yes, and its tested for commit.py, in bzr's test suite; I don't recall the exact mapping to CommitBuilder though
<jelmer> lifeless, thanks, I'll have a look there
<strk> how to update to a specific revision ?
<strk> bzr help update doesn't tell?
<jam> spiv: are you around?
<seb_kuzminsky> i've got a rich-root-pack repo on a server running bzr 1.10rc1
<seb_kuzminsky> when i try to checkout using hardy (bzr 1.3.1), it fails because it makes the local repo (on the client) pack-0.92
<jam> seb_kuzminsky: I believe it is a known bug in older versions of bzr
<jam> fixed somewhere around 1.6
<seb_kuzminsky> thanks jam, that was quick :-)
<seb_kuzminsky> hardy backports has only 1.3.1...
<seb_kuzminsky> it's easy enough to work around by creating the repo explicitly before doing the checkout
<spiv> jam: yep
<jam> spiv: so I was wanting to implement a FIFO cache, similar to our LRUCache
<jam> and basically, on *access* I don't need to do any work
<jam> just on add() do I need to possibly pop things out of the cache
<jam> and I was hoping to have it have minimal overhead
<jam> but if I try to do "self.__getitem__ = self._adict.__getitem__"
<jam> I get a "readonly" attribute error
<spiv> Right, __getitem__ is special, because it's an operator.
<jam> So the next thing I tried was to subclass a dict
<spiv> (You could do that in a classic-class, but not a new-style class)
<jam> but: TIMEIT -s "x = {10:20}" "x[10]"
<jam> is about 0.07us
<jam> and using the subclass
<jam> it is 0.2 us
<jam> or not quite 5x slower
 * spiv tries
<jam> even worse is doing def __getitem__(self, k): return self._d[k]
<mwhudson> oh right, dict.__getitem__ is special cased in the interpreter look i think
<jam> which is about 0.6us
<jam> or another 2-3x slower than subclassing dict
<mwhudson> loop
<jam> so if I wrote a C class
<jam> which subclasses __dict__
<jam> would it be possible to get the same performance, mwhudson?
<mwhudson> jam: no
<jam> it checks the type first?
<mwhudson> yes
<jam> not the attribute
<jam> :(
<mwhudson> think so, anyway
<spiv> jam: I only see about a 30% speed hit for a subclass
<spiv> jam: well, for a trivial dict subclass with no logic
<mwhudson> actually
<mwhudson> maybe i'm lying
<jam> spiv: well, I only special cased __setitem__
<jam> I'll try without that
<mwhudson> it's list[int] that's special cased, it seems
<jam> I still see 0.06 versus 0.24
<jam> I'm on win32
<jam> which makes a difference
<jam> but still
<spiv> jam: on, hmm, now I get numbers more like yours, it seems a package upgrade in the background was skewing my timings
<jam> now the 30s I was seeing is more about LRUCache.get() overhead
<jam> which has to record the access for the LRU part
<jam> I'm sure a FIFO would still do a lot better
<jam> I was just hoping to remove all overhead through some sort of magic
<jam> subclassing dict still gives 2:1 benefit versus using a dict
<spiv> jam: there's already a collections.deque, btw
<jam> spiv: true, but I want a dict
<jam> not a list
<jam> so I want to use a dict + deque
<jam> and when the dict gets full
<jam> pop things out of the deque
<jam> and remove them from the dict
<spiv> Sounds like a weird FIFO :)
<jam> It would only *have* to override __setitem__
<jam> spiv: FIFOCache
<jam> sorry I wasn't more explicit
<spiv> Oh, right.
<jam> versus the LRUCache
<jam> which we have in bzrlib now
<jam> I also wish I could implement it with a list, because I've also seen deque slower than a list
<jam> probably because of stuff like mwhudson's inlining of list[int]
<jam> mwhudson: is tuple[int] also inlined?
<spiv> lists are pretty quick.
<jam> that would make sense to me
<spiv> Also because lists are very simple.
<jam> spiv: yeah, lists are certainly faster, for everything except stuff like a real FIFO because they aren't double-ended
<jam> so pop(0) has to reallocate and move the whole list
<mwhudson> jam: no
<jam> mwhudson: interesting. Considering how tuples themselves are so much faster, and internally python uses tuples for lots of things, like arguments, etc.
<mwhudson> jam: micro-optimizing the python interpreter has a long history, which may not be entirely coloured with sensible-ness
<spiv> Right, but moving the whole list is fairly fast, depending on the size of the list.  That is, although pop(0) scales O(n), the constant factor is quite low, so you may need a pretty large n for it to be slower than a deque.
<jam> but yeah "list[int]" == 0.0495us, and tuple[int] == 0.0712us
<jam> for a list of 10k entries
<jam> .pop(0) seems to take 7us
<jam> sorry 9us
<jam> at the same time, I can't *measure* the time for deque.pop()
<jam> because the time to build the deque causes enough noise to make it unreliable
<jam> but I would guess significantly less
<jam> something around .2us
<jam> doing the "wrong" thing of creating one long enough to not have to recreate it.
<jam> deque(range(10000)) takes approx 300us, versus list(range(10000)) taking only 50us
<spiv> jam: so if I make the timeit inner-loop be pop(0)/popleft(); append(1), I get 0.43Âµs for deques vs. 18.7Âµs for lists. (with 10000 elems).
<jam> seems about what I'm seeing
<jam> for the pop + append, I see 0.293 for deque, and for pop(0)+append I see 7.7us, for pop + append I see 0.391us
<jam> I'm actually surprised to see y.pop(); y.append(1) being slower with a list than a deque
<jam> but it is consistent with 20k nodes as well
<jam> 0.4us versus 0.28us
<spiv> Right.
<jam> interesting BLOCKLEN=62 for deque
<jam> I'm curious how they came up with that
<jam> I suppose it is the freeblock cache?
<spiv> I have no idea :)
<mwhudson> 62 probably gave optimum results on raymond hettinger's computer
<jam> :)
<jam> I assume there is some amount of tradeoff between wasting space and lots of malloc calls
<jam> And I would imagine it depends dramatically on your workload
<jam> lots of 50-node deques, versus 1M deques
<jam> spiv: are you working, btw, or just wasting your vacation time on IRC :)
<spiv> jam: working :)
<spiv> jam: the wasting holiday time on IRC was last week.
<jam> ok, I don't feel bad for pinging you, then
<eartha`> I have file in bzr.
<eartha`> I want to do a commit once a week in a cron job
<eartha`> do I need to cd to the directory that holds the file under bzr?
<eartha`> I mean do I need to write the cd into the script?
<mwhudson> i think bzr ci /absolute/path/to/file will work
<eartha`> thanks mwhudson
<mwhudson> but try it!
<CraPoLa> http://chatroll.com/chatroll-pub#2
<CraPoLa> come free beer
<eartha`> I certainly will.
<CraPoLa> you will good lol
<CraPoLa> whre u from eartha
<eartha`> earth
<CraPoLa> yeah me to lol
<CraPoLa> now the geophrapic location would be nice
<CraPoLa> australia here
<eartha`> same here
<CraPoLa> good
<CraPoLa> what this site about
<eartha`> ?
<eartha`> site
<CraPoLa> the irc channel
<CraPoLa> the one you on
<eartha`> bzr is a version control system
<eartha`> bazaar
<CraPoLa> ??
<CraPoLa> like a server
<eartha`> as in the "bazaar and the cathedral
<CraPoLa> hmm lost me here sorry
<eartha`> no, more like document change tracking.
<CraPoLa> ahhh ok
<CraPoLa> cool
<eartha`> Or more usually, for source files
<CraPoLa> so what do u do with them
<CraPoLa> do you work for a government place
<eartha`> put your project/ documents/source files in version control and then if you change something that does not work, you can go back to a version that does work
<eartha`> In my case I have a file which needs to be printed out once a week for legat reasons.
<CraPoLa> cool
<eartha`> I want to have a weekly snapshot of the file so that if required I can print out the weekly version if requested, insteadof wasting paper.
<CraPoLa> so the link above planet-bazaar-vcs.org is where i go
<eartha`> I guess so.
<eartha`> what os are you on?
<CraPoLa> me Vic
<eartha`> operating system
<eartha`> windows/freebsd/linux
<CraPoLa> ll have a look at his eartha looks cool
<CraPoLa> urself what part of oz
<eartha`> nice talking, have to get back to work.
<eartha`> nsw
<CraPoLa> nice
<CraPoLa> ok later
<eartha`> ooroo!
<CraPoLa> cya
#bzr 2008-12-09
<Gilgad> does anyone know about the current status of nested tree's is?  Last references on the wiki point to the 0.15 version, saying support is incomplete
<Rolly> Gilgad: last I checked that feature hadn't been worked on in a year
<Gilgad> ouch
<Gilgad> i guess thats why i can't find anything more recient than 0.15
<Rolly> It sure would be nice to have :)
<Gilgad> agreed, i was thinking of doing something like this: http://toykeeper.net/tutorials/svnhome using bzr, but it depends heavily on svn:externals (which as far as i can tell is nested trees) for organization
<Rolly> yep, svn:externals == nested trees
<ToyKeeper> You could do something similar, sort of, by doing a lot of one-way merges.
<Rolly> What is a one-way merge?
<ToyKeeper> Put the config modules in different branches, then merge each into host branches.  It's not the greatest approach, but it can work.
<Gilgad> but when happens when i want to commit a change
<Gilgad> as in, isn't the merge a one time thing
<ToyKeeper> Basically, commit on the module branch, then re-merg.
<ToyKeeper> merge, even.  :)
<Gilgad> hmm
<ToyKeeper> I really haven't found a good way to use bzr for $HOME.
<Gilgad> what do you use? or nothing?
<ToyKeeper> At least, if I want to share parts of a config across multiple hosts and have localized changes on each.
<ToyKeeper> I'm using svn.
<Gilgad> yea
<Gilgad> mm, aparently svn would work, but i don't have a place to set up a server
<Gilgad> i mean, i guess there are free services
<Gilgad> but i like that i can have my repo be just files on another system
<Gilgad> i just use my universities unix access to store it on my space there
<ToyKeeper> Any host you have ssh access to should work.
<Gilgad> for svn?
<Rolly> svnserve daemon would also work, no?
<Gilgad> note my above admission that i know little about vcs in general
<ToyKeeper> Heh, I just perked up because someone said my name.  :)
<pygi> jml, around or busy?
<jml> pygi: just having lunch
<pygi> jml, when you come around, please poke ;) thx
<pygi> hopefully I wont be sleeping
<jml> pygi: ok if I poke you tomorrow morning my time?
<pygi> jml, probably, but we should finish it then :)
<jml> yes
<pygi> because Douglas needs to work on contracts
<jml> *nod*
<pygi> anyway, have fun :)
<AfC> If I've come across an svn:// URL that Subversion can check out but Bazaar can't, would Jelmer et al want a bug report about it?
<pygi> AfC, why not? :)
<pygi> HI abentley
<AfC> Hm. Or it could just be that their "server" is insanely slow and underpowered.
<pygi> url? Perhaps I can try?
<pygi> probably wont help tho :D
<AfC> pygi: svn://svn.xmlroff.org/trunk/xmlroff
<pygi> ups, no bzr svn here :/
 * pygi looks into it
 * AfC has to run, but if works ok for you then I'll try again from a different uplink
<pygi> kk
<abentley> pygi: hi
<GPH-Laptop> Is there a way to get a print out of the directory structure in a repository?
<fullermd> ls?   8-}
<fullermd> (which is to say, you're probably asking either too little or too much; what's the goal?)
<awmcclain> Do I need to set up an ssh umask to be able to share the branches that I push? Every new bracnh that I push has teh wrong group perms. :(
<spiv> awmcclain: https://lists.ubuntu.com/archives/bazaar/2007q3/027560.html ?
<awmcclain> I already set the repo branch to 2770
<awmcclain> repo dir
<awmcclain> :-\
<awmcclain> ohhhh
<awmcclain> let me try doing it one level down
<GPH-Laptop> fullermd: Oh, you're back. Yay!
<GPH-Laptop> fullermd: Is there a command that I can use to just list the whole directory structure of the repository? (Similar to ls, I guess, but recursive, maybe?)
<GPH-Laptop> Or am I asking too much
<GPH-Laptop> ?
<GPH-Laptop> Also, what's with the delay in packaging 1.10?
<jml> GPH-Laptop: possibly UDS?
<awmcclain> spiv: drwxrwsr-x 14 clownfish dev 4096 Dec  8 16:22 andrew
<GPH-Laptop> jml: Sorry, UDS?
<jml> GPH-Laptop: the Ubuntu Developer Summit that's going on right now.
<GPH-Laptop> ah
<GPH-Laptop> wasn't aware of that
<jml> GPH-Laptop: I haven't been tracking the 1.10 release closely, so it might not be the case
<AfC> fwiw, Gentoo Linux has got bzr 1.10 packaged. Great to see them so on top of things.
<GPH-Laptop> jml: Doesn't look to be much more than source and Mac OS X 10.5
<GPH-Laptop> unfortunately, I'm on 10.4 ;)
<fullermd> GPH-Laptop: Do you actually mean the structure of a [shared] _repository_?  Or do you mean of a branch?
<fullermd> For a branch, there's always `bzr ls` and its various options.
<GPH-Laptop> fullermd: Um... probably a shared repository, but either should do.
<GPH-Laptop> Yup, that does it.
<GPH-Laptop> Thanks
<fullermd> There's nothing in bzr to list _repositories_ as such (at least, not at the UI level), since they're not treated as semantic units.
<GPH-Laptop> Alright... but an up-to-date branch serves just as well.
<GPH-Laptop> fullermd: Any reason why directories don't have a trailing slash?
<fullermd> Well, the flip answer is "because that's how it was written"   :)
<fullermd> I don't know if there was an intentional choice to not have them, or whether it "just happened" to be so done.
<jml> GPH-Laptop: any reason why they should?
<fullermd> Well, there's "because it's conventional".
<jml> fullermd: only in some conventions :)
<fullermd> Well, in the ones that are Right And Proper, of course.  ;)
<GPH-Laptop> jml: There's no other way to differentiate between files and directories (ignoring file extensions, of course)
<jml> GPH-Laptop: not visually, no. but why is that useful?
<GPH-Laptop> jml: Well, it prints out a list of everything in the branch... Wouldn't you want to be able to know which are files and which are directories, without having to look to see if there are files within that directory? (What if it's empty?)
<GPH-Laptop> I would, particularly if I'm copying the list to paste it somewhere else.
<GPH-Laptop> regular ls at least has a mode for that, if not the default action
<jml> GPH-Laptop: 'bzr ls -v' prints trailing slashes.
 * fullermd could really get to hate '-v' sometimes...
<GPH-Laptop> but it also prints "V" in front of every line... what does that even mean, anyway?
<fullermd> It's listed on every command, even those where it doesn't actually do anything.  There's never any indication of what it _does_.  And most of the things it does aren't what I considered "verbove" anyway.  Blah.
<fullermd> GPH-Laptop: "Versioned" presumably.
<jml> GPH-Laptop: whether the file is versioned or not.
<jml> I still haven't come across a circumstance where I *care* whether a thing is a file or not.
<GPH-Laptop> jml: But I didn't ask it that question. I just wanted a list of files and directories.
<jml> GPH-Laptop: which question?
<fullermd> (which _will_ be the only option when ls is run on a branch without an [accessible] working tree)
<GPH-Laptop> whether the file is versioned
<jml> GPH-Laptop: are you using a Unix?
<GPH-Laptop> jml: Mac OS X
<spiv> Yes.  Other possiblities are 'I' for ignored, and '?' for unknown.
<jml> GPH-Laptop:  bzr ls -v -V | cut -c 10-
<jml> GPH-Laptop: I *think* cut on OS X is close enough for GNU cut to work
<GPH-Laptop> wow... that was way too complicated
<GPH-Laptop> but yes, it did work
<spiv> GPH-Laptop: feel free to file a bug report or post to the mailing list to ask for this behaviour
<GPH-Laptop> not that I needed it... my file structure is currently small enough that I could just add the slashes myself (thanks, though)
<spiv> GPH-Laptop: I don't think anyone has wanted it before, so the current behaviour is just that way because that's all that was needed so far.
<GPH-Laptop> spiv: OK. I just might do that.
<spiv> GPH-Laptop: it doesn't sound unreasonable, although it does sound like something that will inspire some bike-shedding...
<AfC> bike shedding, hooray!
<GPH-Laptop> spiv: I didn't mean to start any arguments. I'm just saying what _I'm_ looking for. ;)
<spiv> GPH-Laptop: sure.  I'm glad you're letting us know what you want :)
<GPH-Laptop> spiv: I'm glad you're willing to listen. :)
<GPH-Laptop> jml, fullermd, spiv: https://bugs.launchpad.net/bzr/+bug/306424
<ubottu> Launchpad bug 306424 in bzr "Add trailing slash to directories in `bzr ls` output" [Undecided,New]
<GPH-Laptop> oh
<GPH-Laptop> heh
<GPH-Laptop> OK, another question
<GPH-Laptop> If I branch the bzr development branch, can I run the bzr script from that branch
<GPH-Laptop> that is, the modified one?
<jml> GPH-Laptop: yes.
<jml> GPH-Laptop: /path/to/that/bzr should just work
<GPH-Laptop> jml: OK, thanks
<jml> GPH-Laptop: that's how bzr developers run unit tests and the like
<GPH-Laptop> Is all the code just in that one bzr file?
<jml> hell no
<GPH-Laptop> I didn't think so
<jml> bzrlib/ has all of the code in it.
<GPH-Laptop> I guess I'm just looking at Launchpad wrong
<drew_> sorry if this may sound elementary, but i stumbled across bazaar in looking for revision control, i just have a simple(hopefully) question.  Does Bazaar track revision numbers on a per file/per branch basis?
<GPH-Laptop> drew_: Per branch, I believe
<GPH-Laptop> but I'm nowhere near an expert yet ;)
<GPH-Laptop> Is Launchpad acting up for anybody else?
<jml> GPH-Laptop: not for me.
<jml> GPH-Laptop: are you looking at the branch browser or at launchpad proper?
<GPH-Laptop> " Sorry, there was a problem connecting to the Launchpad server. "
<GPH-Laptop> for example, http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/3883
<jml> right, the code browser
<GPH-Laptop> yeah
<drew_> GPH-Laptop: ty, guess it's time to actually figure out this whole version control thing :)
<GPH-Laptop> drew_: Yeah. fullermd patiently helped me when I first got started with bzr... not to put any pressure on him, though ;)
<fullermd> It's part of my clever scheme to build up a mass army of people indebted to me, for when I decide to remake the world in my own image.
<drew_> :) nah i'll fight my way through(ofcourse i'm stil adjusting to linux in general here) but a peer of mine suggested i look into revision control at home and the only experiance i have is with PDMWorks
<Rolly> Hm, never heard of THAT one
<drew_> solidworks revision and workflow control
<GPH-Laptop> fullermd: I suppose you can count me in on that one. ;)
<Rolly> Aha
<GPH-Laptop> Now I have to learn Python, too... :P
<drew_> ty again, guess it's time to get a scotch and see what i can break :)
 * fullermd rubs his hands together and cackles.
<GPH-Laptop> lol
<jml> drew_: excellent idea
<GPH-Laptop> OK... first I have to figure out where the ls code is located...
 * jml goes off to consort with enemy languages.
<GPH-Laptop> THEN, I can learn Python :P
<jml> GPH-Laptop: you trying to fix that bug you just filed?
<GPH-Laptop> jml: I was gonna look into it, yeah
 * fullermd keeps on working on some perl   :p
 * GPH-Laptop does PHP
<fullermd> That's what I get paid for most of the time.
<jml> GPH-Laptop: feel free to ask me any questions
<GPH-Laptop> jml: I kinda just did. ;)
<GPH-Laptop> <GPH-Laptop> OK... first I have to figure out where the ls code is located...
<GPH-Laptop> ;)
<jml> GPH-Laptop: oh right.
<jml> GPH-Laptop: so, bzrlib/builtins.py has all of the built in commands
<GPH-Laptop> ah
<jml> GPH-Laptop: like 'ls'
<GPH-Laptop> OK
<fullermd> Search in it for cmd_{whatever_command}
<jml> GPH-Laptop: there'll be a class called cmd_ls or something like that.
<GPH-Laptop> ugh... Launchpad is being naughty again
 * fullermd accidentally glances at the 'ls' code.
<fullermd>                     if non_recursive and '/' in fp:
<fullermd> That's efficient   :p
<GPH-Laptop> jml: Loggerhead is being stubborn again.
<jml> GPH-Laptop: I'll pass it onto the OSAs.
<GPH-Laptop> jml: K, thanks.
<jml> GPH-Laptop: url please?
<GPH-Laptop> jml: http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/3883?file_id=builtins.py-20050830033751-fc01482b9ca23183
<GPH-Laptop> It's on a URL-specific basis?
<jml> GPH-Laptop: well, it's working for me.
<mwhudson> annotating files with complicated history takes ages :/
<mwhudson> this one is a bazaar problem not a launchpad problem, really
<jml> yeah.
<GPH-Laptop> is there a way to view it non-annotated?
<mwhudson> you can download it
<jml> GPH-Laptop: if you want to get a local copy of the whole branch, 'bzr branch lp:bzr'
<GPH-Laptop> ...without having to download it? ;)
<GPH-Laptop> jml: Alright, I might do that
<mwhudson> that said
<jml> GPH-Laptop: 'bzr cat http://bazaar.launchpad.net/~bzr/bzr/trunk/bzrlib/builtins.py' might get you the file though.
<mwhudson> annotating builtins.py locally takes a few seconds
<GPH-Laptop> but it would be useful to have the features of ViewVC
<mwhudson> so something funny is going on
 * GPH-Laptop <3 ViewVC
<GPH-Laptop> jml: Nah, that's fine. I'll just do the whole branch.
<jml> GPH-Laptop: well, you can get all of those features with the bzr client
<jml> GPH-Laptop: although the colors are less pretty :)
<GPH-Laptop> heh
<GPH-Laptop> jml: Hmm... slow...
<GPH-Laptop> should I have run an init or something first?
<jml> GPH-Laptop: it's got a biggish history.
<jml> GPH-Laptop: no, not really.
<GPH-Laptop> OK
<GPH-Laptop> I have a feeling it's going to take a long while before I get the hang of this :P
<GPH-Laptop> So get used to me ;)
<jml> GPH-Laptop: once it's downloaded, you might want to do something like 'bzr init-repo bzr-branches'; 'bzr branch bzr bzr-branches/trunk'
<jml> GPH-Laptop: no worries.
<GPH-Laptop> bzr-branches being my current directory, or what?
<jml> GPH-Laptop: bzr-branches being a new directory that will be a shared repository of all your branches of bzr itself
<jml> GPH-Laptop: you can call it susan if you really want.
<GPH-Laptop> how is that related to the directory I just did `bzr branch lp:bzr`? Should I issue them in the same directory?
<GPH-Laptop> Heh
<jml> GPH-Laptop: so, the directory that you're in now isn't special (unless you've already done init-repo)
<GPH-Laptop> I may have a bit upstream... I don't recall
<GPH-Laptop> would that matter?
<jml> GPH-Laptop: what does 'bzr info' say?
<GPH-Laptop> not a branch
<jml> GPH-Laptop: ok. so it's just a boring old directory.
<jml> GPH-Laptop: you want to make a directory like ~/Projects/bzr or whatever you prefer
<jml> GPH-Laptop: that will hold all of the branches that you make of bzr itself
<jml> GPH-Laptop: but you make that directory using 'bzr init-repo'
<GPH-Laptop> ~/Development/bzr/bzr/
<GPH-Laptop> is where it is
<GPH-Laptop> And, of course, it just created another bzr
<jml> GPH-Laptop: so that the branches share their revision data.
<GPH-Laptop> so ~/Development/bzr/bzr/bzr/
<fullermd> OK, so you can make ~/Development/bzr/ the shared repo, and use reconfig to shuffle the branch you're making into it after it's done.
<jml> GPH-Laptop: heh. is that 'bzr branch' command finished?
<GPH-Laptop> yeah
<fullermd> So, something like
<fullermd> cd ~/Development/bzr ; bzr init-repo . ; mv bzr/bzr bzr.dev ; bzr reconfigure --use-shared bzr.dev
<fullermd> (or call it 'trunk' instead if you prefer)
<jml> right. what fullermd said.
<fullermd> (and then that extraneous 'bzr' dir can be tossed too)
<jml> and then, to work on your bug fix, go 'bzr branch bzr.dev trailing-slash-bug-306424' (or whatever)
<GPH-Laptop> well... the first bzr directory hold more than just Bazaar stuff... it's actually a directory of code that uses bzr... so should I do that in bzr/bzr?
<fullermd> Ah, in that case, yah.
<GPH-Laptop> so I should have ~/Development/bzr/bzr/bzr.dev/?
 * fullermd nods.
<GPH-Laptop> OK
<fullermd> That'll be your local branch of the bzr trunk, using the shared repo in ~/Development/bzr/bzr/.  Then other branches like ~/Development/bzr/bzr/add-trailing-slash/ can share the repo.
<spiv> "bzr/bzr/bzr" sounds a bit swedish chef-like!
 * fullermd swats at the fly.
<GPH-Laptop> lol
<GPH-Laptop> ok
<jml> spiv: make a dvcs called "Shantih!" and make us all happy
<fullermd> Or maybe "Beetlejuice"   :p
<GPH-Laptop> And then I can run ~/Development/bzr/bzr/bug-306424-ls-trailing-slash/bzr to test?
<jml> GPH-Laptop: yep
<GPH-Laptop> cool
<jml> GPH-Laptop: another thing you may be interested in...
<GPH-Laptop> yeah?
<jml> GPH-Laptop: bzrlib has a lot of unit tests
<GPH-Laptop> Will I need to change them?
<jml> GPH-Laptop: you might want to add one or two.
<GPH-Laptop> Oh, OK
<GPH-Laptop> one step at a time, though ;)
<jml> GPH-Laptop: "./bzr selftest" will run all of them.
<GPH-Laptop> alright, I'll keep that in mind
<jml> GPH-Laptop: and './bzr selftest test_ls' should run the ls ones
<GPH-Laptop> cool
<jml> (which live in bzrlib/tests/blackbox/test_ls.py)
<GPH-Laptop> k, got it
<fullermd> Running all of them will take some time   :p
<GPH-Laptop> Is there a good place for python docs (commands) like there is at php.net?
 * fullermd shrugs.
<GPH-Laptop> heh
<fullermd> Start from python.org and follow likely links.  There are some within a click or two.
<GPH-Laptop> ok
<GPH-Laptop> What is PyQt4?
<jml> GPH-Laptop: it's Python bindings to Qt version 4. Qt is a graphical widget toolkit, used by KDE and others.
<GPH-Laptop> the unit test failed because I don't have it
<jml> GPH-Laptop: I'm sceptical.
<jml> GPH-Laptop: can you paste the command you ran and the output to paste.ubuntu.com (or the pastebin of your choice)
<GPH-Laptop> jml: http://gphemsley.pastebin.com/d6a1a95dd
<jml> GPH-Laptop: ./bzr --no-plugins selftest test_ls
<igc> night all
<jml> igc: g'night :)
<jml> igc: good to see you back :)
<igc> thanks jml
<GPH-Laptop> jml: Yup, that did it. Thanks.
<GPH-Laptop> igc: Good night stranger. :P
<jml> GPH-Laptop: one of your installed plugins requires PyQT
<GPH-Laptop> interesting... how come I didn't know that before?
<fullermd> Alien mind control rays.
<GPH-Laptop> and how come I don't have it?
<jml> GPH-Laptop: dunno.
<jml> GPH-Laptop: 'bzr plugins' will list the plugins that bzr can find that work
<GPH-Laptop> hmm... you think it's qbzr? :P
<vila> GPH-Laptop: ./bzr selftest -s bb.test_ls will be far quicker than ./bzr selftest test_ls (give it a try) and it may even works around your plugin problem
<GPH-Laptop> vila: Indeed.
<vila> GPH-Laptop: the quicker part, the plugin part or both ?
<GPH-Laptop> both
<spiv> Adding --no-plugins will also work around the plugin problem.  (But I know vila gets sad when people do that...)
<vila> spiv: :-)
<GPH-Laptop> heh
<vila> spiv: try writing a plugin that you want to use to run selftest and you'll quickly get sad too :-)
<jml> I'm sad about being hungry.
<fullermd> Dangit, you had to mention hungry...
<vila> spiv: like, for example, plugging a real hpss server in the test framework :-P
<vila> or even an instrumented one :)
<spiv> vila: I don't follow that example, currently there's both real and instrumented hpss servers in the test suite...
<vila> spiv: by the way, any idea about how to fix FAIL: branch_implementations.test_sprout.TestSprout.test_sprout_preserves_kind(BzrBranchLoomFormat6)
<vila>     BzrBranch6('file:///tmp/testbzr-MSlMuJ.tmp/bzrlib.tests.branch_implementations.test_sprout.TestSprout.test_sprout_preserves_kind%28BzrBranchLoomFormat6%29/work/branch2/') is an instance of <class 'bzrlib.branch.BzrBranch6'> rather than <class 'bzrlib.plugins.loom.branch.LoomBranch6'>
<vila> spiv: say you want to test an older hpss server then
<spiv> (too many real, really; most of the tests that start a TCP server and a thread don't really need to...)
<vila> spiv: right, that was just *one* example
<vila> but plugging *real* servers into the test framework is still the best way I know of to check bzr compatibility
<vila> (even if I understand that you're referring to writing simpler tests)
<vila> s/simpler/more focused/
<spiv> vila: possibly by deleting the clone method from loom.branch.LoomSupport ?
<GPH-Laptop> jml: Oh... bzr files indent with spaces...
<spiv> vila: does that test even exist in current bzr.dev?
<jml> GPH-Laptop: these days, almost all Python does
<GPH-Laptop> jml: Oh, really?
<jml> GPH-Laptop: well, all sane Python :)
<vila> spiv: isn't it the one you hack with jam ?
<spiv> $ grep test_sprout_preserves_kind bzrlib/tests/branch_implementations/test_sprout.py | wc -l
<spiv> 0
<jml> GPH-Laptop: indent with four spaces. there's a hacking guide in doc/developers/HACKING.txt
<jml> GPH-Laptop: (and lots of other juicy docs in the same dir)
<GPH-Laptop> jml: Oh. Probably should have looked for that first.
<spiv> vila: there's not test_sprout_uses_bzrdir_branch_format
<spiv> s/not/now/
<vila> 8-)
<jml> GPH-Laptop: docs are for looking at second :)
<GPH-Laptop> What do you think I should do... add the trailing slash by default or add another option?
<GPH-Laptop> heh
<spiv> vila: and it passes
<fullermd> I'd be in favor of it just being there always.
<jml> GPH-Laptop: add it by default.
<spiv> vila: (I'm still suspicious of LoomSupport.clone, though...)
<vila> spiv: great ! Looks like I should update the bottom thread in my loom !
<vila> The comment talks about updating the nick too
<fullermd> For even extra fun and bikeshedding, add a * on executable files too   :p
<jml> (why doesn't ubuntu ship with wireshark by default?)
<jml> fullermd: !
<fullermd> (the lack of something like that has made me very cranky in the past)
<jml> fullermd: definitely would want that in an option
<vila> fullermd, GPH-Laptop : Don't forget the '@' for symlinks !
<jml> fullermd: not in default behaviour
<fullermd> See?  Instant argument; just add fullermd!
<vila> --decorated --color... definetly bikeshedding when color becomes an option :)
<spiv> jml: possibly because default installing software with a history of exploits that allow executing arbitrary code makes people nervous
<GPH-Laptop> heh
<GPH-Laptop> jml: so... anything besides slash in default?
<spiv> "I want my bikeshed to be suffixed with the @ character!"
<fullermd> Adding the / is probably a safe thing to have on it.  I can't offhand think of anything it would hurt...
<fullermd> spiv: Don't be such a rogue   :p
<jml> GPH-Laptop: no.
<jml> GPH-Laptop: just '/'.
<spiv> Adding @ at least has some consistency with adding /; they are both signifiers of the inventory entry type.  * doesn't have that distinction.
<vila> The only case I know of where *not* having the final '/' hurts is Apache
<spiv> At some point the answer is "if you want a custom tree formatter, there's an API you can use..." :)
<fullermd> True.  OTOH, (1) the '/' doesn't harm anything I can think of offhand ('cd', 'ls', etc) you'd paste it to, where '@' would.
<fullermd> And (2) there's no case [on POSIX] where a trailing '/' could validly appear, so you could always sed it away if you wanted, whereas a trailing @ could be significant.
<fullermd> [in the filename I means]
<jml> I'm using wireshark to track some machine-local traffic, how do I filter so I only capture one direction?
<spiv> jml: filter on src port?
<fullermd> Specify src/dest port.
<spiv> (or dst port)
<jml> how do I do that?
<spiv> That's how the TCP stack distinguishes them, after all.
<spiv> With much clicky-clicky.
<jml> spiv: yeah, there's a sense in which you just restated my question :)
<fullermd> "and src 123"
<jml> hmm... I think I want a *capture* filter, not a display filter
<jml> (they have different syntax, yay!)
<fullermd> Oh.  Display filter would work too...
<spiv> "tcp.srcport == 1234" looks likely.
<spiv> (I clicky-clicked on the "+ Expression..." button, expanded the "TCP" filters, etc etc...
<spiv> )
<spiv> (I'm sure you'd have been as distressed as me if I hadn't closed that paren)
<jml> spiv: good grief! I wonder what the alternative UI design was :)
<GPH-Laptop> jml: Is there any special protocol for commit messages in my local branch/
<GPH-Laptop> ?
<vila> spiv: ./bzr selftest -s bt.branch_implementations.test_sprout -v not failing anymore ! Hurrah ! :-)
<jml> GPH-Laptop: not at all.
<jml> GPH-Laptop: generally, you just want to make them helpful.
<jml> GPH-Laptop: also, if you haven't used a dvcs before, you want to commit way more often than you are used to :)
<GPH-Laptop> jml: I think I'm pretty much done
<GPH-Laptop> it was pretty simple
<GPH-Laptop> but how come it seems like the unit tests aren't all being run?
<GPH-Laptop> that is,
<GPH-Laptop> some of the test lines don't give errors when I forgot to fix them
<jml> GPH-Laptop: 'bzr di -r submit:' should generate you a diff, I think. If you pastebin it I can take a look.
<GPH-Laptop> jml: http://gphemsley.pastebin.com/d1454f2dd
<GPH-Laptop> oh wait
<GPH-Laptop> I think I have a little optimization to do
<GPH-Laptop> hang on
<jml> GPH-Laptop: looks fine to me. If you do 'bzr send' once you're done, that will prepare a merge directive (a patch on steroids) and attach it to a message, you can then send it to the mailing list.
<jml> GPH-Laptop: the HACKING guide has some more info about that.
<GPH-Laptop> jml: http://gphemsley.pastebin.com/d2ef5b771
<fullermd> I dunno if I'd reuse outstring like that...   but that's stylistic quibbling.
<GPH-Laptop> fullermd: Well, it is the outstring... isn't it?
<fullermd> No, it's a filename.  It doesn't replace outstring, it replaces fp, so I'd call it 'fnstr' or something like that, and replace the requests for fp with it.
<jml> send it to the mailing list!
<jml> that way, stylistic quibbling will get the patch landed :)
<GPH-Laptop> heh
<GPH-Laptop> ok
<fullermd> Hey!  We have to run the gauntlet of the IRC bikeshed before we can run the ML bikeshed!
<GPH-Laptop> I edited the NEWS file... anything else I have to do before sending it?
<mwhudson> is there some way to force bzr to use paramiko over openssh?
<luks> BZR_SSH=paramiko ?
<GPH-Laptop> jml: Does the merge directive include my commit messages?
<jml> GPH-Laptop: yes, it does.
<mwhudson> luks: you are my hero
<GPH-Laptop> jml: OK, so now I just e-mail it?
<GPH-Laptop> Or should I attach it to the bug?
<jml> GPH-Laptop: yeah. put [MERGE] at the start of the subject, and include text that human beings will read
<jml> GPH-Laptop: (assuming you are using bzr send)
<jml> GPH-Laptop: and send it to the mailing list. Include a link to the bug as well.
<GPH-Laptop> I did send -o
<GPH-Laptop> is that OK?
<jml> GPH-Laptop: sure. just attach the output to your email
<GPH-Laptop> and do I attach it to the bug?
<jml> GPH-Laptop: no
<GPH-Laptop> OK
<jml> GPH-Laptop: if you want, push your branch to Launchpad (bzr push lp:<yourusername>/bzr/<branch-name>)
<jml> GPH-Laptop: and then link that branch to the bug.
<GPH-Laptop> jml: It says invalid branch name
<spiv> GPH-Laptop: use a valid one, then *wink*
<spiv> What name did you try?
<luks> GPH-Laptop: it's easier to just mail it :)
<GPH-Laptop> spiv: bzr push lp:gphemsley/bzr/bug-306424-ls-trailing-slash
<luks> missing ~
<spiv> GPH-Laptop: your username needs to be prefixed with a ~
<GPH-Laptop> oh
<spiv> so bzr push lp:~gphemsley/bzr/bug-306424-ls-trailing-slash
 * GPH-Laptop nudges jml 
<spiv> jml: tsk tsk :P
 * spiv wanders off
<luks> but really, isn't pushing the whole bzr just for one patch an overkill?
 * GPH-Laptop shrugs
<spiv> Sometime soon we should update the branch format of bzr trunk so that pushing bzr branches to launchpad will use stacking.
<GPH-Laptop> may as well learn the process
<strk> how do I switch to a specific revno ?
<spiv> strk: bzr pull --overwrite -r REVNO, usually
<jml> sorrry
 * spiv really wanders off
<GPH-Laptop> jml: OK, posted to the mailing list, but awaiting moderation
<GPH-Laptop> Branch available @ https://code.launchpad.net/~gphemsley/bzr/bug-306424-ls-trailing-slash
<strk> spiv: thanks!
<jml> GPH-Laptop: thanks
<strk> chefan: is
<jml> GPH-Laptop: I don't have moderation privileges, but I'll ping poolie or someone similar tomorrow.
<GPH-Laptop> jml: OK
<GPH-Laptop> then I'll head off to bed
<jml> GPH-Laptop: ok. g'night.
<GPH-Laptop> jml: g'night
<spiv> GPH-Laptop: moderated
<lamont> can I safely remove .bzr/repository/obsolete_packs? or is there a command to prune the cruft from the repo?
 * lamont checks to see what bzr pack buys him
<Peng_> lamont: You can empty the directory, but I don't think you can delete it.
<Peng_> lamont: Anyway, there's no real reason to. It'll be cleaned out (and filled with new packs) the next time the repo is auto-packed or you run "bzr pack".
<lamont> neat.  bzr pack brought me from 808MB clear down to 1150MB
<Peng_> lamont: Right. When a pack is no longer needed, it's moved to obsolete_packs instead of being deleted outright, in case something goes wrong.
<luks> if will be cleaned up and new obsolete packs will be added
<lamont> otoh, .bzr/repository/packs went from 574920->574904 (woo!!) while obsolete_packs went from 233MB->574MB
<luks> *it
<Peng_> lamont: When it auto-packs, some packs will be compressed down into one, and the old ones will be moved to obsolete_packs. When you run "bzr pack", *everything* will be compressed down to one pack, so obsolete_packs will have a copy of the entire repo.
<lamont> right
<lamont> is there a way to tell bzr that I actually do backups of the machine and to quit saving me from myself by bloating said backups with extra copies of everyting?
<Peng_> Heh.
<Peng_> Can your backup software exclude obsolete_packs?
<lamont> it could
<Peng_> (I mean, exclude the contents of it. The directory itself needs to exist.)
<lifeless> lamont: sounds like you'd just hit a extreeme autopack anyhow; obsolete_packs' contents are automatically pruned
<lamont> lifeless: I manually did 'bzr pack' to see if it would help.
<lamont> which, uh, not so much
<lifeless> lamont: yes, I saw
<lifeless> for obsolete_packs to have been at 250MB it must ave already just packed 50% of your archive
<lamont> well... total of 11 files in the archive
<lamont> 42MB, 1.1MB, 1.1MB, and < 10k
<lamont> so 575 MB of .bzr, and another 50MB total in the tree.
<lifeless> you're versioning a 422MMMB file?
<lamont> sure.  iz histyory
<lamont> ot
<lamont> it's also not very compressable, since it's already,uh, bit-indexed data
<lamont> I stand corrected.  bzip2 takes it down from 42.2MB to 28.0 MB
<lamont> the tree has a whopping 36 commits, and no branches
<lifeless> ok
<lifeless> so at the 30th commit it autopacked
<lifeless> that gave you te 250mb thing
<lifeless> then 6 more commits that didn't autopack
<lifeless> the 40th would have trimmed wiped obsolsete_packs and then moved the 10 most recent files into there when autopacking again.
<lamont> ok
<lamont> every 10 or so then?
<lifeless> lamont: it allows no more than 10 packs with a given revision count, rounded up to the next base10 digit
<lifeless> lamont: e.g. 10 of 1, 10 of 10, 10 of 100 etc
<lifeless> lamont: so log backoff
<lamont> ah, ok
<lamont> hrm.. why no bzrtools 1.10-1 backport for dapper?
<lifeless> because you haven't done one yet?
<lamont> s/you/poolie et al/
<lamont> or will bzrtools 1.9.1-1~dapper1 "just work" with bzr 1.10-1?
<lifeless> dunno, where did the dapper binary comefrom
<lamont> lifeless: jam did the upload it would appear
<lamont> besides, I don't have write privs to the ppa :-p
<lifeless> lamont: file a bug, surely you should be able to :)
<lamont> heh
<lamont> ah.  iz funnier when read that I should surely be able to file a bug.
<jam> lamont, lifeless: I haven't been packaging dapper because it needs different settings from all of the other packages
<jam> most of them are just "dch && bzr commit && bzr builddeb"
<lamont> jam: we still need/want dapper... and pushing it back to y'all is specifically because it requires a merge instead of a smack...
<lamont> wc -l /home/lamont/bin/build-package
<lamont> 300 /home/lamont/bin/build-package
<lamont> ^ I already have a bitchslap script
<jam> lamont: so why no concern over bzr-svn? Which has never been packaged for dapper
<lamont> because that machine is running hardy.
<awilkins> Ok, https://bugs.launchpad.net/bzr/+bug/304023
<ubottu> Launchpad bug 304023 in bzr "Autopack fails with err 17 "File Exists" on windows" [Undecided,New]
<awilkins> I've traced a fail and a success, and it looks like the success should be failing :-)
<lamont> jam: and bzr should require more than just smackery for dapper, too.  py-support vs py-central
<jam> lamont: that is already handled by someone else
<jam> "has been handled"
<jam> and yes it does
<lamont> right
<jam> building the "bzr" package is automated
<jam> building bzr and bzr-svn still requires me to do a lot of manual steps
<jam> because they aren't built in the same way
<jam> bzrtools and bzr-svn are generally built from the debian package
<lamont> yeah - bzr-svn just needs hardy, bzrtools needs dapper/hardy
 * awilkins has a roughly automated build script for either, maybe it could be done for both
<jam> and the debian package doesn't support dapper
<awilkins> My script is Powershell though, and rather specific to my environment at present
<jam> because of py-central versus py-support
<awilkins> (on win32 at any rate)
<lamont> yep
<jam> also, we run into weird problems with multiple-targets and "bzr builddeb" if you build from a bzr tree rather than from a tarball
<jam> because it rebuilds the tarball
<jam> which causes the md5sum to change
<jam> which causes it to fail to upload
<jam> etc
<jam> which is partially why I do it manually
<jam> as I build a tarball for the first time, and then re-use that tarball for all the others
<jam> anyway, *right now* I'm on win32, which is a real pain for building packages :)
<jam> If you are stressing that getting bzrtools-1.10~dapper1  is very important for you I can do something about it
<jam> lamont: What is your specific need/urgency/etc ?
<GPH-Laptop> jml, fullermd: Are you around?
<Peng_> lifeless: brisbane-core uses more disk space right now, right? But that's because compression hasn't been optimized yet, and it will become significantly better than the current stuff, right?
<lifeless> Peng_: yes, its more  disk space for the inventories
<Peng_> Thanks for the confirmation.
<lifeless> Peng_: massively less uncompressed
<Peng_> What?
<Peng_> That it's much smaller when not compressed?
<lifeless> Peng_: the inventories inv development4 are about one 20th the size of the inventories in --1.9 *before compression*
<lifeless> Peng_: but --development4 doesn't delta compress the inventories, just gzips, at the moment
<Peng_> How good should they be when they're delta compressed?
<lifeless> better than 1.9, but more than that I can't say
<lifeless> we have a feedback loop to do to tune them - the inventories may change to be more compressable, for instance
<pygi> poolie, hey, could I poke for a sec? :)
<Peng_> The inventories are much smaller when uncompressed, but what does that buy me as a user? On disk, they're always compressed.
<lifeless> Peng_: bzr spends less time comparing the inventories between two revisions, so fetch, log -v, and other such commands have less work to do
<Peng_> lifeless: Ah, that sounds good.
<poolie> hello pygi
<Peng_> Would memory usage be improved too?
<lifeless> Peng_: yes
<seb_kuzminsky> ongoing svn->bzr switch saga...
<lifeless> Peng_: e.g. mysql-server has a 1.7MB inventory, on average (in 1.9). So diff requires assembling 3.4MB of text, parsing it, then doing a full dict comparison between the objects
<seb_kuzminsky> i've read the Bazaar User Reference, and i can see how to add a client-side post-commit email hook, but i'd prefer to do the email-sending via a single server-side post-commit hook i think
<seb_kuzminsky> the developers all have login accounts on the server, and we use bzr+ssh to commit/push
<lifeless> Peng_: in split-inv, we read a tree on demand, so we may only read 30 or 40 k of data - total.
<seb_kuzminsky> is that possible somehow?  if so where's it documented?  ;-)
<lifeless> seb_kuzminsky: it is possible; s piv made it so, I'm not 100% sure what-all is needed :)
<seb_kuzminsky> hm
<seb_kuzminsky> also a post-commit hook to poke the buildbot would be nice
<lifeless> seb_kuzminsky: spiv will be online in about 4 hours
<seb_kuzminsky> ok thanks lifeless
<lifeless> seb_kuzminsky: but generally, try just insalling bzr-email on the server and see what happens :)
<seb_kuzminsky> i tried that, now when i "bzr up" in my checkout (bound branch) i get this warning message:
<Peng_> Errm, BTW, sorry about not getting around to the bzr search index thingy yet. I have been busier than usual, but mostly I'm just goofing off and being lazy. :\
<seb_kuzminsky> /usr/lib/python2.5/site-packages/bzrlib/plugins/email/__init__.py:57: DeprecationWarning: bzrlib.branch.BranchHooks.install_hook was deprecated in version 1.5.
<seb_kuzminsky>   Branch.hooks.install_hook('post_commit', branch_commit_hook)
<lifeless> Peng_: no worries
<seb_kuzminsky> bzr 1.10rc1
<lifeless> seb_kuzminsky: did you install  bzr-email via package?
<seb_kuzminsky> bzr-email 0.0.1~bzr5 (Debian Sid's standard .deb)
<seb_kuzminsky> maybe i should bypass debian and grab bzr & friends from lp
<seb_kuzminsky> oops, typo, that' bzr-email 0.0.1~bzr25-1.1
<seb_kuzminsky> whatever that means ;-)
<seb_kuzminsky> "bzr plugins" doesnt show a version number for email
<lifeless> right the debian package is old
<lifeless> file a bug there asking for a new version to be packaged :P
<seb_kuzminsky> ok will do
<lifeless> now, for yourserver, you can probably just ap-tget source bzr-email
<lifeless> grab the bzr-email upstream (bzr branch lp:bzr-email)
<lifeless> drop the newer source on top of the debian source package, and rebuild it
<seb_kuzminsky> sorry, i had the "testing" version installed, there's a newer one in sid
<seb_kuzminsky> the sid one is "bzr34"
<seb_kuzminsky> from august sometime
<seb_kuzminsky> i'll try that
<seb_kuzminsky> looks like it's pretty close to top-of-tree bzr-email, it's just missing some test suite fixes
<seb_kuzminsky> with bzr-email r34 (from Sid) it no longer gives an error when committing :-)
<seb_kuzminsky> hm, the "bzr help email" only talks about configuring client-side post-commit email-sending hooks
<seb_kuzminsky> ok i think i'm thinking about this wrong
<seb_kuzminsky> we've been using subversion, but we're switching to bzr
<seb_kuzminsky> i'm basically trying to replicate our existing svn infrastructure using bzr
<seb_kuzminsky> the sticking points are server-side post-commit hooks
<seb_kuzminsky> one for sending email on commit, and another for prodding the buildbot
<seb_kuzminsky> this seems to be not well supported in bzr currently
<seb_kuzminsky> so bzr admins must be using some other mechanism to accomplish something similar
<seb_kuzminsky> in terms of workflow, we're using something like one of the "Centralized" flows, or "decentralized with shared mainline"
<seb_kuzminsky> how do others do this?
<lifeless> seb_kuzminsky: how did you go?
<lifeless> seb_kuzminsky: re: bzr-email docs, when the server runs the mail hook the *server* acts as the client
<seb_kuzminsky> lifeless: i'm not there yet, but still trying :-)
<seb_kuzminsky> the bzr-email hook runs in the server's copy of the branch, i get that
<seb_kuzminsky> but where does it get its configuration from?  from the user who's running bzr, right?
<lifeless> you can configure it in branch.conf
<seb_kuzminsky> hm
 * seb_kuzminsky is rereading the docs
<GPH-Laptop> jml, fullermd: Are you around?
<seb_kuzminsky> so it's ok to edit .bzr/branch/branch.conf?  the .bzr/README told me not to
<GPH-Laptop> jam: What about you? You around?
<jam> GPH-Laptop: absolutely not :)
<GPH-Laptop> heh
<GPH-Laptop> jam: Just wondering if you saw my response to your e-mail?
<jam> I did
<GPH-Laptop> I wasn't sure what poolie's response meant
<jam> I would probably still be more in favor of writing out the plain fp if --null is given
<jam> I don't think he fully understood
<jam> I know I was wrong in thinking that it would give @, etc
<lifeless> seb_kuzminsky: we're a little unclear about things; yes its ok to edit .bzr/branch/branch.conf
<seb_kuzminsky> okay then :-)
 * seb_kuzminsky edits
<jam> I'll go ahead and respond to the email so it is documented :)
<GPH-Laptop> ok, thanks :)
<GPH-Laptop> jam: Also, any idea why I got an e-mail about not having voting rights?
<GPH-Laptop> from Bundle Buggy
<jam> I believe when you replied to me, it didn't properly "quote" my BB:resubmit vote.
<jam> I'm not 100% sure ,though
<jam> It *looks* like your mail client is indenting the response, but not prefixing it with ">"
<GPH-Laptop> Ah
<GPH-Laptop> Alright, I'll change to unformatted
<GPH-Laptop> you can thank Gmail for that ;)
<seb_kuzminsky> lifeless: now the server's .bzr/branch/branch.conf says this:
<seb_kuzminsky> post_commit_to = seb@highlab.com
<GPH-Laptop> jam: So, am I to make a change and resubmit?
<seb_kuzminsky> and "bzr hooks" shows post_commit as bzr-email
<jam> We need 1 other person to approve it.
<lifeless> seb_kuzminsky: that sounds good
<jam> The change is small enough that someone can do it for you
<seb_kuzminsky> i'm not setting post_commit_mailer, so it should default to /usr/bin/mail
<jam> but if you do it, it is easier on us :)
<lifeless> seb_kuzminsky: yes
<seb_kuzminsky> i can send myself email that way
<seb_kuzminsky> but when i commit, i get nothing
<GPH-Laptop> jam: Alright. Same way? bzr send -o?
<jam> should be fine
<GPH-Laptop> jam: Can I just reply to that e-mail?
<jam> as long as you attach a patch you can just reply
<GPH-Laptop> okey doke
<jam> BB should notice and mark the patch as superseding the previous one
<seb_kuzminsky> lifeless: my commits are happening (i can pull them)
<seb_kuzminsky> but the mailserver logs on the bzr server machine show nothing going out, and the mailserver logs on the receiving side (highlab.com) see nothing coming in
<lifeless> seb_kuzminsky: what bzr client and server versions do you have ?
<seb_kuzminsky> the server is 1.6.1, with bzr-email r34
<seb_kuzminsky> er, the server is 1.10rc1, with bzr-email r34
<seb_kuzminsky> sorry
<seb_kuzminsky> the client is 1.6.1
<lifeless> I think you need a newer client
<lifeless> let me check
<seb_kuzminsky> lifeless: why should the client version matter?  isnt it the bzr on the server doing this work (the client commits on a bound branch)
<lifeless> seb_kuzminsky: older clients do more things via the VFS than via RPC calls
<poolie> hell jam
<jam> i'm sorry poolie, I didn't mean to upset you :)
<seb_kuzminsky> lifeless: gotcha
<lifeless> seb_kuzminsky: so 1.6 looks like it should be ok
<lifeless> seb_kuzminsky: I'm not sure whats wrong, digging
<mwhudson> so i have a bazaar install which is doing annotates (at least) REALLY slowly
<poolie> hella jam dude
<mwhudson> all the c extensions are built now, though it's possible they're not being used for some stupid reason
<mwhudson> how can i debug this?
<seb_kuzminsky> lifeless: i committed in a bound branch on the server, and it sent out the email
<jam> mwhudson: how slow is slow? And what version of bzr?
<jam> We had a fix recently
<poolie> mwhudson: press C-\ in the middle of the annotate and look at where it is
<poolie> and what he said
<jam> bzr 1.9
<lifeless> seb_kuzminsky: ah!
<mwhudson> jam: ah, maybe it's just relative age, indeed
<mwhudson> the slow one is tiocsctty
<mwhudson> no
<mwhudson> 1.7.1rc1
<mwhudson> (fricking x clipboards)
<jam> mwhudson: so bzr 1.6 introduced a regression
<jam> where we weren't using the stored values
<jam> we fixed that in bzr 1.9
<mwhudson> jam: ok, that went easily then
<mwhudson> (glad i asked!)
<seb_kuzminsky> is there a preferred way to install a newer bzr on Intrepid?  backports doesnt have anything.  a PPA maybe?
<mwhudson> yes, the "bzr" ppa
<seb_kuzminsky> thanks mwhudson
<lifeless> seb_kuzminsky: ok, its because bzr-email uses the post_commit hook
<poolie> jam, i started on a namedtuple-like object
<poolie> and am trying to get it to pass tests in dirstate.py
<poolie> currently just written in python
<poolie> it certainly looks better
<lifeless> seb_kuzminsky: could you please file a bug, that it should support [optionally] using post_change_branch_tip as well, with an option to enable that
<seb_kuzminsky> lifeless: instead of the post-tip-change hook
<seb_kuzminsky> lifeless: ok will do
<poolie> we'll have to see if it's possible to make a C version comparably fast to Py_Tuple
<lifeless> seb_kuzminsky: it can't just swithc over, because 'pull' locally shouldn't usually email :)
<jam> sounds interesting
<GPH-Laptop> jam, poolie: Any idea why all packages aren't available for 1.10 yet?
<jam> GPH-Laptop: what packages are you looking for?
<jam> poolie: I would imagine you could get close, with the exception of anything that is folded into the interpreter directly
<jam> poolie: the other question would be what the overhead of using the named arguments instead of the offset
<seb_kuzminsky> lifeless: is it similar to this: https://bugs.launchpad.net/bzr-email/+bug/250934
<ubottu> Launchpad bug 250934 in bzr-email "bzr-email should support email on push" [Wishlist,Triaged]
<lifeless> seb_kuzminsky: oh, identical - thats fine
<GPH-Laptop> jam: Mac OS X 10.4
<seb_kuzminsky> domo arigato mr ubottu  ;-)
<poolie> heh
<poolie> jam, good question
<GPH-Laptop> jam: Hey, by the way, looks like I made a boo-boo on my last commit message.
<jam> Since i believe it will be implemented as "name => offset => get" there will obviously be *some* overhead
<poolie> i might leave this angle of getting the python impl to pass and instead write up the C version and do some microbenchmarks
<jam> GPH-Laptop: the Mac installers are built by the community, so someone just has to wake up and do it.
<GPH-Laptop> jam: It kinda expanded my "`bzr ls`" to be the contents of the current directory.
<GPH-Laptop> jam: Ah, OK
<poolie> jam, what do you mean by "name => offset => get"
 * Peng_ points out that there are already namedtuple implementations out there.
<GPH-Laptop> Is there a command to change the commit message?
<Peng_> GPH-Laptop: No.
<jam> GPH-Laptop: bzr uncommit; bzr commit -m "new message"
<Peng_> I -- yeah, what he said.
<GPH-Laptop> alright
<GPH-Laptop> should I resubmit again?
<jam> you can't really change one after-the-fact
<jam> but you can regenerate the commit
<jam> if it is important to you, you can email it to me
<Peng_> If it's just a typo, it's not worth fixing (you should look at bzr.dev's history...)
<GPH-Laptop> Peng_: It kinda contains the contents of the directory instead of just the name of the command ;)
<poolie> Peng_: in C?
<GPH-Laptop> Alright, I'll be back later.
<Peng_> GPH-Laptop: Heh, nice.
<poolie> Peng_, there is http://svn.python.org/projects/python/trunk/Objects/structseq.c but it's not exposed in python
<GPH-Laptop> jam: Alright, new patch sent.
<GPH-Laptop> adieu
<Peng_> poolie: Ah... Never mind, then, I gues.s
<poolie> it would be nice if there were
<poolie> i thought that 2.6 namedtuples
<jam> Peng_: IIRC 2.6 does have a namedtuple class
<jam> but it is *really* crummy
<poolie> would do this directly, but in 2.6.0 they're slower than objects
<jam> it is a pure-python class
<jam> and does things *really* weird
<jam> like using "eval()"
<poolie> after thinking about this a bit more, i'm not convinced they should be tuple subclasses
<poolie> or more precisely, "should provide the tuple protocol"
<Peng_> jam: Yeah, it's pure Python, and uses exec.
<jam> the reason we *use* tuples is because they are very fast to create
<poolie> but we could use Py_StructSeq, unless we can do something faster
<jam> so named tuple breaks that
<poolie> so being able to index things by ints, or iterate them, or take the length, when they're not conceptually sequences, is a bit of a bug source
<seb_kuzminsky> lifeless: i installed bzr 1.10 on my client & still no email when i commit, is that expected from the bzr-email hook hooking in the wrong place?
<lifeless> seb_kuzminsky: do you mean commit or push?
<lifeless> jelmer: ping
<lifeless> seb_kuzminsky: I've uploaded draft code to mail on push/pull for you, to http://bazaar.launchpad.net/~/bzr/bzr-email/trunk
<pygi> poolie, ups, sorry, I was out to eat :)
<poolie> np
<seb_kuzminsky> lifeless: wow, thanks for the draft code!!
<seb_kuzminsky> lifeless: the client has a heavy checkout (a bound branch), and i did commit in there, and it didnt email me
<seb_kuzminsky> i'll try again with your new code, thanks!
<seb_kuzminsky> lifeless: aww yeah!!
<seb_kuzminsky> thank you
<lifeless> seb_kuzminsky: my pleasure
<Oli``> I'm currently using one big bzr repo for all my website projects. I'm a few days down the road now and 3 sites in and it's already pretty slow to work out commits. Is it possible to split these 3 directories into their own repos (keeping, if possible, ignore settings and revision info from the existing repo)
<luks> is it a big repo or a big branch?
<Peng_> I doubt the repo is making a significant difference.
<Peng_> Well, some, but..
<Oli``> yeah I'm probably using the wrong terminology... I typed bzr init. made 3 directories inside with all the site files in each of those and that's where I am =)
<Peng_> Oh, one big branch.
<Oli``> Peng_: does that make a difference to what you said?
<Peng_> Oli``: Yes. Committing requires the entire working tree to be scanned for changes, so obviously the size of the branch matters.
<Peng_> But that probably doesn't happen if you run "bzr commit some_file", and you might be experiencing slowness for other reasons too.
<Peng_> Oli``: What version of bzr?
<Oli``> 1.10
<Oli``> Ubuntu PPA, I believe
<Peng_> Oh.
<Peng_> I was hoping it was some really old version, so upgrading would make everything much faster. :P
<lifeless> Oli``: generally, we'd say one branch per project :)
<Oli``> lifeless: yeah I was being lazy to see if I wanted to stick with bzr
<lifeless> Oli``: if they are all one website, one branch is fine, but if they are for different VHosts it reallu doesn't make sense to use one branch
<lifeless> Oli``: bzr commits should not slow down noticably under about 5000 files
<Oli``> hmm.. they're each only about 30 files each =\
<Peng_> Oli``: Would any of the files happen to be gigantic?
<lifeless> Oli``: are you committing .iso files or similar ? :)
<Oli``> nope. python source files, jpeg images (small, sub-200k)
<Oli``> css, javascript, nothing scary
<lifeless> Oli``: can you do 'time bzr st'
<LarstiQ> Oli``: are you using a checkout against a remote machine, or a local branch?
<lifeless> Oli``: oh, also 'bzr inventory | wc -l'
<Oli``> LarstiQ: both but --local seems pretty slow too
<Oli``> sorry I had a phone call
<Oli``> 0.844s was the real result for time bzr st
<Oli``> bzr inventory | wc -l = 152
<Oli``> Perhaps I'm imagining things (or expecting things to run at light-speed) but for the sake of correctness, I probably aught to split things up while I'm only dealing with 3 projects...
<Oli``> Is it going to be more hassle than its worth trying to keep the current history? Should I just juggle things around and create three new branches?
<Peng_> Oli``: Well, you might be able to use "bzr split" to spin off each directory into its own branch, though they'll all contain the full history up until this point.
<Peng_> I think.
 * jml beats combine-thread repeatedly
<lifeless> Oli``:
<lifeless> Oli``: 'time bzr commit -m 'unchanged' --allow-unchanged'
<Oli``> no such option --allow-unchanged
<Oli``> but --unchanged exists
<Oli``> 1.1s
<lifeless> Oli``: that is a bit slow. How did you install bzr?
<Oli``> from the ubuntu repo.. then upgraded to the PPA version
<lifeless> Oli``: 'python -c "import bzrlib._dirstate_helpers_c"
<mark1> igc: woohoo - welcome back :)
<mwhudson> revision-info should take a -d argument
<pygi> jml, in 10 minutes?
<jml> pygi: sure.
<seb_kuzminsky> i'm trying to use bzr 1.10rc1 to provide read-only anonymous access to my repo
<seb_kuzminsky> i'm starting it from inetd like this:
<seb_kuzminsky> bzr stream tcp nowait nobody /usr/bin/bzr bzr serve --directory=/data/bzr --inet
<lifeless> seb_kuzminsky: the easiest way is just to put the repo up on http ;)
<seb_kuzminsky> lifeless: i had a feeling you'd say that :-)
<lifeless> seb_kuzminsky: easier for folk beind firewalls and so on
<seb_kuzminsky> it's an internal server
<seb_kuzminsky> the only user will be our buildbot
<seb_kuzminsky> all the devs access it via bzr+ssh
<seb_kuzminsky> so the firewall is not an issue for us
<seb_kuzminsky> when i telnet to the bzr port on the server, inetd starts bzr like i tell it to, but then the bzr server says:
<seb_kuzminsky> No handlers could be found for logger "bzr"
<Peng_> That's just a warning..
<seb_kuzminsky> if i say "bzr ls bzr://server", it says:
<seb_kuzminsky> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<seb_kuzminsky> Server does not understand Bazaar network protocol 2, reconnecting.  (Upgrade the server to avoid this.)
<seb_kuzminsky> bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: 'No handlers could be found for logger "bzr"\n'
<Peng_> Heh.
<seb_kuzminsky> both client and server are 1.10rc1
<Peng_> Oh. I guess the warning gets in teh way.
<Peng_> bzr likes to log to ~/.bzr.log. If it's being run as some user that can't, I guess it will emit the warning.
<seb_kuzminsky> oh i see
<seb_kuzminsky> i'm running it as nobody
<seb_kuzminsky> i'll try running it as me, hold on
<Peng_> Can you set the environment variable BZR_LOG (to a writable file, or /dev/null to suppress logging)?
<Peng_> IMO, that's a bug that the logging warning breaks the smart server..
<seb_kuzminsky> sounds like a bug to me ;-)
<seb_kuzminsky> if i run it as me it works fine
<seb_kuzminsky> i'll see if i can convince inetd to do like you suggest
<seb_kuzminsky> do you want me to open a bugreport?
<Peng_> I think so (if there isn't already one!)
<seb_kuzminsky> even "bzr serve -q" gives that error
<seb_kuzminsky> Peng: i think there's no way to tell inetd to doctor the environment of the programs it runs
<seb_kuzminsky> i could write a wrapper...
<Peng_> Ah. I don't know what you should do, then. It would be a really trivial wrapper.
<seb_kuzminsky> https://bugs.launchpad.net/bzr/+bug/129030
<ubottu> Launchpad bug 129030 in bzr "Bzr inetd smart server requires write access on the user's home directory" [High,Confirmed]
<Peng_> Oh, nice.
<Peng_> Less than 1.5 years old! :P
<seb_kuzminsky> https://bugs.launchpad.net/bzr/+bug/106117
<ubottu> Launchpad bug 106117 in bzr "bzr serve should log somewhere other than ~/.bzr.log" [Low,Confirmed]
<seb_kuzminsky> those two look related to this problem, i dont see any other bugs that seem related
<jam> lifeless: you may be interested to know that I've been able to tweak the old Inventory deserialization to the point that fetching 1.9 => chk for mysql  seems to be spending 78% of its time in CHKInventory.create_by_apply_delta
<jam> also, your page cache helps a *lot*
<lifeless> jam: thats cool
<lifeless> jam: how fast is it?
<jam> if only apply_inventory_delta re-opens the base tree each time
<jam> lifeless: I got to 34k revisions after 15k seconds
<lifeless> 2/sec?
<jam> approximately
<jam> I just stopped it because I wanted to do an lsprof now that we are further along
<lifeless> so, we need to make create_by_apply_delta faster :>
<lifeless> jam: pick three reviews you need and link em here please
<jam> I'm also seeing "52.009MB => 13.017MB"
<jam> my update to your commit builder patch: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493C0839.10808%40arbash-meinel.com%3E
<jam> The follow-on interdiffering serializer patch: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493C0958.9010704%40arbash-meinel.com%3E
<jam> The rest of what I've been playing with is not in a mergeable state. But if you get those, then I have a patch which merges the new code from bzr.dev back into the chk branch.
<jam> Which resolves some conflicts, etc.
<jam> Since you approved the FIFO code, I can go ahead and offer a bzr.dev patch using that for XML deserialization
<jam> that is at least worth reviewing for conceptual merit
<jam> lifeless: Anyway... I'm thinking that flattening the trie will actually help the create_by_apply_delta a lot.
<jam> I don't have much better answers, as the time is partially spent in "serialize"
<lifeless> jam: k
<jam> and I've already worked out that merge revisions are pretty much always going to get collisions
<lifeless> jam: so, parameterised key-transforms ++
<lifeless> I think that that is a good thing to do
<lifeless> I think we should consider/do a C serializeer and parser very soon
<seb_kuzminsky> Peng: works fine with the little wrapper we talked about, with BZR_LOG=/dev/null
<Peng_> seb_kuzminsky: :)
<seb_kuzminsky> i also added a comment to one of those bug reports, and suggested merging them
<jam> lifeless: well, as significant amount of time is in the Index code
<jam> 100s / 300s for converting 100 revs
<jam> (though from scratch, so nothing is paged in already)
<jam> (under lsprof)
<lifeless> jam: ok, index tuning to do too then
<lifeless> :)
<jam> 279k calls to _KnitGraphIndex._get_entries
<jam> which seems like a bit much versus only 100 revisions
<lifeless> I'd add a tracer for that
<jam> 25k calls to get_parent_map => 194k calls to _get_entries
<lifeless> meep
<jam> 17k calls to get_build_details => 54k calls to _get_entries
<jam> get_entries is an iterator, so that is how many records we are *reading* not the actual number of calls
<jam> but even 25k calls to get_parent_map is 250 calls per revision
<jam> I suppose some of that may be the "_walk_to_common_revisions" code
<jam> which has to go pretty far back
<seb_kuzminsky> aaahhhhh: https://launchpad.net/bzrbuildbot  :-)
<jam> but there *are* 16.5k calls to "add_records" which hints that we are adding 165 pages per revision
<lifeless> jam: what project?
<jam> mysql
<jam> And I'm guessing 50-75% of those are collisions
<seb_kuzminsky> hm, but they have no code or anything  :-(
<jam> lifeless: oh and one more. http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493EF306.6000906%40arbash-meinel.com%3E
<jam> It is a trivial update to the earlier LRUCache update
<Gwaihir> is there a bzr 1.10 package for lpia architecture?
<lifeless> Gwaihir: I'm not sure, it will depend if the ppa builds lpia automatically I suspect
<jam> Gwaihir: should be
<jam> it usually builds i386, amd64, lpia
<lifeless> jam: all reviewed
<jam> lifeless: thanks
<Gwaihir> looks like the package is present, but if I add the sources.list entry it complains that it's not possible to find the lpia architecture
<jam> lifeless: quick question... if we are walking in topological order. will a merge revision actually usually follow the right-hand parent?
<Gwaihir> anyway... thx, found the package
<lifeless> jam: rephrease/more detail please
<jam> putting together a paste, just a sec
<jam> http://paste.ubuntu.com/83214/
<jam> If you have the simple merge graph
<jam> and you topo_sort
<jam> lifeless: the idea is that mysql is merging the 5.1 branch into 6.0
<seb_kuzminsky> thanks again lifeless and Peng_, see you later
<jam> but the InterDifferingSerializer code will see the 5.1 as the "basis" versus 6.0
<jam> which causes us to create a delta of all of 5.1 versus 6.0
<lifeless> jam: topo_sort has no preferennce between B and C
<lifeless> DCBA and DBCA are both valid IIRC
<jam> lifeless: what about: http://paste.ubuntu.com/83217/
<jam> I'm also more concerned with the output of "tsort.topo_sort" than the definition of "topologically sorted" :)
<jam> Anyway, my point is that C=>E and E=>G may be small changes, but B has lots of changes
<jam> and if we use all of C, E, G as the base
<jam> then each delta includes the changes from B
<jam> which is why we are getting so much redundancy in the conversion
<jam> arg..... python2.4's collections.deque doesn't have a ".remove()" attribute
#bzr 2008-12-10
<lifeless> jam: btw, is up or down 'towards parents'
<jam> parents are up
<jelmer> lifeless, pong
<jelmer> AfC, I would very much like a bug report :-)
<AfC> jelmer: It was a false alarm, turns out. I think their first revision is huge (it was an import of an existing project into VCS), and I was on poor link. I tried it again from my office and while it took a long time before network traffic started, eventually it got going and did a huge transfer.
<AfC> jelmer: thanks for your response, though.
<jelmer> AfC, ah, ok - no progress indication whatsoever, or just slow?
<lifeless> jelmer: hi
<jelmer> lifeless: hi!
<lifeless> jam: merge_sorted would be more concise perhaps
<AfC> classic case of Bazaar's less than useful progress indicator hurting more than it helps - it was camped out on the initial 0/260 for several minutes. And since no network I/O was going on either, it was disheartening.
<AfC> (it's so cosmetic, but if youtube-dl can actually give you live activity stats, surely bzr could. Its one of the things that massively contributes to the subjective opinion that Bazaar is slow if you've used Git)
<lifeless> AfC: was the spinner spinning?
<jelmer> lifeless, what's up?
<jelmer> AfC, right
<AfC> (and yes, I know about how it's all one library call, and that library doesn't report back events, etc. {shrug} Whatever it is, it needs replacement.)
<fullermd> Well, look at the bright side; if the progress indicator actually updated progress more, you'd have more chances to get annoyed at the step-numbering...
<AfC> lifeless: checking
<AfC> [and if you haven't tried youtube-dl, grab it and watch it go. It's *sweet* from a user feedback standpoint]
 * fullermd rather likes mtn's progress output too.
<fullermd> Both in its smoothness of update, and in that it *STAYS* there; after it's done, you can still see what it did.
<lifeless> jelmer: are  you waiting on me for any reviews?
<AfC> lifeless: can't reproduce right now. I'll try it again from that cafe later today.
<lifeless> AfC: k
<fullermd> AfC: Of course, you think THAT bad usage of a library is living long...   Mozilla *STILL* doesn't give you any freakin' stats on what/how much/how fast it's loading.  WTF?
<AfC> lifeless: [just now there was 21 seconds of no progress bar at all, and no network activity, and then a monster transfer, and then the progress bar came up at 1/. When I was having the trouble 2 days ago it was stuck at 0/ with no network activity]
<jelmer> lifeless, not that I'm aware of :-)
<jelmer> lifeless, well, I'm waiting for two minor requests for bzr and one for pqm, but that's not waiting on you particularly
<AfC> Is bzr-webserve still an active project, or did it get absorbed by loggerhead  | launchpad, or ...?
<AfC> Sorry, my actual question is "I've long heard discussion of a simple and if-possible-more-or-less-built-in web interface for Bazaar; did anything come of that? Is bzr-webserve that?"
<spiv> AfC: not yet
<AfC> Either way, what should I be trying and who trying to help?
<AfC> s/who/who should I be/
<spiv> I think a cut-down loggerhead is likely to be the way to get there.
<spiv> But I don't know of anyone working on it.
<AfC> spiv: k, thanks
<lifeless> spiv: I've updated bzr-email for server side deployments
<lifeless> spiv: if there are docs for gnome or whatever you might like to give it a spin :)
<spiv> lifeless: ah, neat.
<ym1> I used bzr co to get a project from google code. I would like to work for some times locally using bzr.
<ym1> However as soon as I try to do a bzr commit, bzr tries to commit on google code. what should I do to stop this ?
<jelmer> ym1, use "bzr branch" rather than "bzr co"
<ym1> jelmer: I have already done some modification there. Is it too late to save this branch
<jelmer> ym1, "bzr unbind"
<jelmer> will turn a "bzr co" into a "bzr branch"
<ym1> jelmer: thank you
<ym1> That is the command I was looking for
<ym1> Before applying, does bzr bind is working in the context of bzr svn ?
<ym1> If yes that means that I can work disconnected for some times that then apply my changes to the central repository.
<ym1> jelmer: If this possible I am curious to know how the 10 "locals" commit is going to be represented in the central SVN repository.
<jelmer> ym1, you'll have to push them back using "bzr push"
 * spiv -> lunch
<ToyKeeper> D'oh.  'bzr st' reports modified files, and 'bzr di modified_file' says nothing at all.
<spiv> ToyKeeper: does "bzr st" report it with a "*"?
<ToyKeeper> Nope.
<spiv> Or any other flags?
<ToyKeeper> The only odd thing is I made the branch via bzr-svn.
<ToyKeeper> Let's see... bzr 1.10~rc1-1 from debian
<spiv> That doesn't affect working trees AFAIK.
<spiv> Can you pastebin the exact output of the bzr st and bzr diff?
<ToyKeeper> Sure.
<ToyKeeper> Ah, it's definitely because of bzr-svn.
<ToyKeeper> When I disable it, everything works fine.
<ToyKeeper> I'm guessing jelmer did something clever.
<ToyKeeper> Like, intercepting diff and hiding the result if 'svn diff' says it's up to date.
<spiv> That does sound like a bzr-svn bug, although a weird one.
<spiv> But it's not an SVN working tree?
<ToyKeeper> It's also a svn working tree.
<spiv> You mean there's both .svn and .bzr stuff for that directory?
<ToyKeeper> This project does stupid things, like call 'svn info' during its debian build process.
<ToyKeeper> Yes, both .bzr and .svn dirs.
<spiv> I can see how that would cause confusion -- the .svn directory might think the working copy is at a different revision to where the .bzr directory thinks it is at.
<spiv> So inconsistent results are a fundamental issue there.
<spiv> I guess bzr-svn could perhaps try to warn you if that's the case, although I'm not sure it's possible to do that cheaply with svn.
<ToyKeeper> Yeah, I don't care if svn is confused by it.  I'd prefer to get rid of it entirely.
<ToyKeeper> I'm thinking I'll probably skip bzr-svn on this one...  don't need history just to make a few small patches.  :)
<spiv> If you don't care what svn thinks, then just get rid of the .svn directories :)
<ToyKeeper> That breaks the build process.  :(
<ToyKeeper> Oh, nice.  'bzr diff file' says nothing, but 'bzr diff' alone shows the changes.
<ToyKeeper> Or, with bzr-svn removed, everything works.
<ToyKeeper> woot, bzr-svn also breaks 'commit' in this case.
<funkychicken818> i am running bzr on windows and i have two problems 1 when i open bzr i get unable to load bzr-svn extension - did you build it? 2 bzr cache is annoying and takes up to much memmory how do i stop it?
<funkychicken818> any one?
<ToyKeeper> I've never tried bzr on Windows, so I'm not much help.
<rocking777> hello room
<rocking777> i am using bzr for the first time ein my new project and facing lot of difficulties
<rocking777> there is work going on 2-3 of my modules and one of the module is completeed. I want to push this module to staging server
<rocking777> but it is not allowingg me to do so
<rocking777> it is saying that there are uncommitted changes in my code
<bob2> 'push' doesn't care about thta
<bob2> what command are you running?
<rocking777> bar push and then providing the repository address
<rocking777> my bazaar checkout is a direct branch of SV
<rocking777> SVN
<rocking777> bzr push svn+ssh://my address
<vila> hi all
<vila> rocking777: 'push' cares only about revisions, so to avoid errors it checks about uncommitted changes
<vila> You may want to look at shelve/unshelve to get to a point where you can commit and then push
<rocking777> yes, but then those uncommitted changes are related to other modules
<rocking777> so i dont want to commmit or push that coe
<igc> hi vila
<rocking777> i want to push only the code related to my module
<vila> igc: HI !
<vila> igc: was thinking about you at that precise second :-)
<igc> vila: :-)
<fullermd> Fine then, don't think about me   :(
<Peng_> igc: Welcome back. :)
<igc> thanks Peng_
<igc> fullermd: we're always thinking of you  - take it for granted :-)
<vila> fullermd: I was thinking about you when reading my IRC backlog :-)
 * fullermd is mollified for the moment.
<vila> People most often refer to the Muppet's Show for the Swedish Chef, but my favorite muppets were the two old mens and their remarks... :-)
<vila> That was a random thought of course....
<funkychicken818> bzr cache is annoying and takes up to much memmory how do i stop it?
<jml> vila: Waldorf and Stadtler, I think.
<vila> jml: Wow ! I didn't even know they had *names* :-)
 * fullermd nods at jml.
<luks> funkychicken818: depends on what do you mean by bzr cache
<GPH-Laptop> jml, vila, fullermd: I'm pretty sure it was Statler (without the D)
<funkychicken818> luks well i mean the tortise cache bzr cache
<funkychicken818> Tortoise Bazaar
<Peng_> GPH-Laptop appears to be correct.
<GPH-Laptop> ;)
<luks> funkychicken818: surry, I don't know then
<funkychicken818> hey how do i not cache with bzr?
<LarstiQ> funkychicken818: most of us are not windows users, I at least have only a vague hunch what that means. Is that the status cache to speed up icon overlay drawing?
<funkychicken818> yes
<funkychicken818> its very annoying its taking up tons of memory
<funkychicken818> right now its at 500,000 K
<funkychicken818> and i only have 2GB of memory
<funkychicken818> LarstiQ: is the any way to stop it?
<wild_oscar> hey there. could someone help me with the bazaar plugin for eclipse?
<wild_oscar> I was following the steps here http://bazaar-vcs.org/BzrEclipse/Installation
<wild_oscar> but I'm getting an error when configuring bazaar in the preferences: http://pastebin.com/d45c56522
<vila> wild_oscar: what does 'bzr plugins' display ?
<vila> wild_oscar: or said otherwise, do you have the xmloutput plugin installed ?
<kebomix> Free Programming e-books With Direct Links & Request ebooks Here : http://request-ebooks.blogspot.com/
<wild_oscar> back
<wild_oscar> vila: well, it seems it was a problem with bzr's version
<wild_oscar> I upgraded to 1.10 and it's working
<vila> good
<wild_oscar> thanks for the tip, though
<nevans> so... let's say that you are writing a teeny tiny little library for a community that seems irrationally connected to github, and you want to make a git mirror so that they can send in patches that way
<nevans> but you would rather be using bzr yourself
<nevans> what are your options (besides just sucking it up and using git yourself, because that's what the crowd wants)
<lifeless> nevans: use bzr fast-export to generate the git repo
<lifeless> nevans: and insist on patches not branches being given to you :)
<nevans> lifeless, sounds like a plan.  :)
<nevans> I suppose there isn't a decent two way mirroring solution as of yet?
<NfNitLoop> Hrmm.
<NfNitLoop> SO I've got a bzr repo that I've been working on standalone.
<NfNitLoop> and I would like to check it in to subversion.
<NfNitLoop> I tried bzr svn-push $REPO/branches/newbranchname
<NfNitLoop> is that correct?   (I got an assertion failed message.)
<NfNitLoop> This is with 1.9 and the corresponding bzr-svn, so I guess I'll upgrade and try again.
<luks> does anybody know if there is a way to get bzrlib call ui_factory.get_password() when using openssh?
<NfNitLoop> Hmm, same error with bzr 1.10 and the new (.4.x) bzr-svn:
<NfNitLoop> assert not self.push_metadata or self._new_revision_id is None or self._new_revision_id == revid
<NfNitLoop> fails.  :/
<khemicals> I set up bzr server to run via xinetd on Centos 5 via the EPEL package (version 1.3.1) and was getting bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: 'No handlers could be found for logger "bzr"\n'
<khemicals> so I upgraded to 1.10 -- still getting that error and an additional set of "Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)" -- ideas?
<NfNitLoop> khemicals: Hmm, I haven't actually ever run the bzr server before... sorry.
<NfNitLoop> khemicals: Why are you using that instead of just HTTP and/or SSH?
<NfNitLoop> (just curious)
<khemicals> When over SSH I get similar error message
<khemicals> haven't tried HTTP
<lifeless> NfNitLoop: tat should have been right; I suggsest putting a question on bzr-svn in lp
<lifeless> luks: no, openssh doesn't call the get_password callback
<NfNitLoop> lifeless: actually, what I'm working on isn't a branch, it's completely new code.
<NfNitLoop> I'm wondering if that's what's messing it up.
<luks> lifeless: so if I call access a bzrlib transport from a GUI program and it needs password I'm screwed?
<lifeless> luks: ssh-agent
<lifeless> NfNitLoop: no, that should be fine.
<lifeless> bbiab
<NfNitLoop> and instead of trying to put it in $REPO/newproject, I'm trying to put it in $REPO/oldproject/branches/xyz which might confuse the branching scheme?
<NfNitLoop> aah.
<lifeless> NfNitLoop: ah, newproject may be better ;
<lifeless> )
<lifeless> -gone
<luks> lifeless: well, not in *my* case, but how do I tell the user it's not going to work?
<luks> hm, perhaps I should force bzrlib to use paramiko when running qbzr commands
<jam> luks: you're pretty dependent on how ssh works
<jam> It generally doesn't let you get around its password prompt, for security reasons.
<luks> jam: I just don't want my programs to hang, that's all
<jam> I thought there was a way to declare a password program.
<jam> Since that works with Gnome, etc.
<luks> jam: it sits and waits for the password on a terminal, with no notification to the GUI
<jam> If you run something that requires ssh but doesn't have aterminal, it will pop up a gui password
<luks> jam: I'd rather make it fail than do this
<jam> luks: man ssh gives me this: http://paste.ubuntu.com/83568/
<NfNitLoop> lifeless: aha, yes, pushing to $REPO/newproject worked.  Unfortunately that doesn't match our branching scheme here, hrrmm.
<khemicals> luks: Why not just use ssh keys for auth instead of password auth?
<jam> I also see something about SSH_TTY
<luks> khemicals: because I don't have a way to tell the user of my application that asking for password is not going to work in this specific case
<jam> You can also pass "-n" to the ssh process
<luks> khemicals: I can't do it globally, because it works for some different ssh provider
<jam> which causes it to redirect stdin to /dev/null
<jam> khemicals: luks is trying to get qbzr to work nicely
<jam> which is a gui app
<jam> luks: I would recommend doing something with SSH_ASKPASS
<jam> it seems like you could have a tiny qbzr command
<luks> I'll try that
<jam> well, probably not command
<jam> it probably needs to be a full script, etc.
<khemicals> Did you poke at how tortoiseCVS handles it?
<jam> khemicals: I'm pretty sure TCVS requires you use the putty code
<luks> "bzr qaskpass" should probably work
<jam> not openssh
<jam> luks: I just don't know if you can supply arguments, or if it has to be a single no-whitespace string.
<jam> env vars aren't particularly great for allowing whitespace-in-path *and* allowing arguments
<luks> hmm
<luks> I need to find a way to trick it into thinking it doesn't have a terminal available
<LeoNerd> pipe stdout through cat?
<luks> nah
<luks> it's smarter than that :)
<fullermd> Presumably you'd have to use something like setsid() to throw away the process group holding you on the terminal.
<jam> luks: it mentions needing to redirect stdin to /dev/null as a possibility
<jam> you could also unset TTY
<jam> and possibly SSH_TTY
<jam> I don't know why that would be set
<jam> (I would assume ssh itself sets that)
<jam> or passing "-n" on the command line
<jam> A bit hard to do through the bzr layers
<jam> but you could hack it in and see if that fixes it
<luks> jam: nope, neither of that works
<jam> luks: not even -n ?
<luks> it seems to be a common problem though
<jam> do you have DISPLAY set?
<luks> I have a running X11 session, so yes
<jam> anyway, I've never done it myself
<jam> just trying to track down the things it mentions in the man page
<luks> it will really need some syscalls to disassociate the process from the terminal
<luks> which will get ugly, I guess
<jam> of course, it is easier if you just force the ssh agent to be paramiko
<jam> but that would also mean losing whatever config they have set up in ssh
<jam> And I know I have some ssh connections that require going through a proxy ssh connection, etc
<jam> (canonical is pretty tight on security)
<jam> It is probably not the most common case, but I know I can't (easily) use paramiko to access things on most canonical machines.
<vila> luks: as a last resort you may check that the SSH_AUTH_SOCK env variable is set to ensure same ssh agent is used...(but do ssh agents work for passwords ?)
<khemicals> found the cause of the issue I noted earlier -- noting for anyone reading through the logs -- set the BZR_LOG env variable and the errors go away (set it to something writable -- ala /tmp/bzr.log) -- suggest setting to something sane and properly perm-set for a proper permanent solve
<khemicals> bug #106117
<ubottu> Launchpad bug 106117 in bzr "bzr serve should log somewhere other than ~/.bzr.log" [Low,Confirmed] https://launchpad.net/bugs/106117
<rocky> jelmer: hey ... when a bzr svn-push is pushing and it scans for all branches in the remote svn repo .... does it save that info so it doesn't have to do it again on the next svn-push ?
<jelmer> rocky, most of it, yes
<rocky> jelmer: i'm pushing to a repo which apparently has about 1100 branches and it's taking forever right now
<rocky> i don't undesrtand why it has to scan branches for "projects" which aren't even related to the folder/trunk i'm dealing with
<jelmer> rocky, 0.5 should be able to not do that
<jelmer> rocky, 0.4 basically assumes one project per repository
<rocky> gotcha
<kjcole> 'lo. Back again.  I'm rebuilding a knit file the hard way.  What is the last number on the first line (version line) of a knit file and can I regenerate that outside bzr?
<kjcole> And second, compressing the file: is there any special option I should add to gzip to produce the compressed knit?
<kjcole> (The knit file doesn't need to be 100%, as the file's been removed.  It just needs to be good enough for the repository to survive an upgrade to a better format.)
<kjcole> I have a possibly corrupt version line from the original, and it contains the right filename and line count.  I also have the original file from which the knit was produced.
<kjcole> Is the sha1 hash for a knit determined from the raw data (without compression, version header, end trailer, line prefixes) or after?
<lifeless> kjcole: the sha in a knit record is that of the data alone
<kjcole> lifeless: Thanks. (I just finished posting the question on the mailing list, so ignore it there.)  Does it exist anywhere else?  and is it simply what "sha1sum" produces?
<lifeless> kjcole: bzrlib/knit.py
<lifeless> kjcole: if oyou're creating a knit from scratch you can just use the api :)
<kjcole> lifeless: Although I've "fixed" the broken gzip knit file, I now have an incorrect sha1. So I'm wondering if it recomputes it or compares it to a stored value.
<kjcole> lifeless: I suppose that would have been the sensible thing to do. ;-)
<lifeless> its compared on extraction
<lifeless> if it doesn't match its an error
<kjcole> lifeless: Hokay...  Lemme see if I can figure out knit.py.  Thanks.
<seb_kuzminsky> me again with more problems
<lifeless> kjcole: I suggest creating the knit using the api
<lifeless> kjcole: this will ensure no mismatches
<lifeless> seb_kuzminsky: hi
<seb_kuzminsky> thanks to lifeless, the server-side email plugin/hook is doing it job well
<seb_kuzminsky> but one of the developers here is on a mac, and it chose to install some unknown version of bzr-email along with bzr 1.10
<seb_kuzminsky> now his local bound branch tries to run bzr-email when he commits on his mac
<seb_kuzminsky> and it's failing, it looks like the mac "mail" program isnt quite what bzr-email expects
<lifeless> well
<lifeless> 'bzr help email'
<lifeless> will document the options there; but that dev doesn't need bzr-email installed :)
<kjcole> lifeless: I'm just trying to get past an error from a single corrupt file many revisions back.  (The file is one that never changed, and was removed from the repository minutes after it was added.)
<seb_kuzminsky> we tried setting post_commit_mailer=/usr/bin/true in his .bzr/branch/branch.conf, but to no avail
<seb_kuzminsky> i understand he doesnt need bzr-email install
<kjcole> lifeless: (in fact, minutes after the repository was inited.)
<lifeless> kjcole: yes, I understand, what I'm suggesting is probably the easiest way. Note that you *cannot* make 'check' pass unless you can get something that matches the sha1sum sum in the layer above the knit
<kjcole> lifeless: Thanks. Will pursue.
<lifeless> kjcole: as inventing something with a specific sha1 is hard :) - you'll be better off with the rebase-the-repository approach :)
<seb_kuzminsky> is there a way to enable/disable plugins/hooks on a per-branch basis?  it seems like it's pretty much system-wide
<lifeless> seb_kuzminsky: the plugins run systemwide, but *activate* per-branch
<seb_kuzminsky> what controls which plugins are active on each branch?  i didnt see anything in .bzr/branch
<seb_kuzminsky> hi lenny
<lennybn> seb_kuzminsky: hi
<seb_kuzminsky> lifeless: meet lenny my mac-using co-worker
<lifeless> lennybn: hi
<lifeless> seb_kuzminsky: well for bzr-email, its 'has a post_commit_to value set'
<lifeless> lennybn: can you (simplest thing) just remove bzr-email
<lennybn> lifeless: do you know where it lives?
<seb_kuzminsky> i'm pretty sure lenny doesnt have post_commit_to set in his .bzr/branch/branch.conf
<seb_kuzminsky> it's in /usr/share/pycentral on intrepid, not sure about on the mac
<lifeless> lennybn: python -c 'import bzrlib.plugins.email; print bzrlib.plugins.email.__path__'
<lennybn> for future reference it is in /Library/Python/2.5/site-packages/bzrlib/plugins/email
<lifeless> just delete that directory
<seb_kuzminsky> lifeless: do you want a bug report against bzr-email that it still does something on mac even if post_commit_to is not set in .bzr/branch/branch.conf?
<lennybn> I removed the the directory and now it is working correctly.
<lifeless> seb_kuzminsky: it is set - if lennybn has a bound branch
<seb_kuzminsky> lifeless: i thought the "local" branch had config & plugins independent of the "remote" branch it's bound to (on another machine), is that not so?
<lifeless> seb_kuzminsky: plugins are per-machine/user; config is bzr/branch/branch.conf + ~/.bazaar/locations.conf + ~/.bazaar/bazaar.conf
<lifeless> seb_kuzminsky: bound branches couple together two branches
<lifeless> seb_kuzminsky: or lenny may have had a checkout, which doesn't have a full local branch anyhow
<lifeless> seb_kuzminsky: I'm aware that there is some less-than-optimal stuff with smarst-server + bzr-email interactions, but don't need a bug for it
<seb_kuzminsky> oh, hm.  i think he has a "heavy checkout", which i *thought* was the same as a bound branch
<vadi2> Hi, I'm having some trouble pulling from a branch. My local copy was modified, so bzr told me to merge - I did, however it still does not want to pull: http://pastebin.com/m1592533f
<Peng_> vadi2: You have to commit after merging.
<vadi2> ok
<luks> vadi2: but that will not solve your "pull" problem
<luks> vadi2: bzr will not allow you to pull until you have local revisions not present in the pulled branch
<yml> I have done bzr push <svn repository> after rather long reorganization. This reorganization has lot of addition, and mv .
<yml> The command is running for the last 10 minutes
<yml> can I be confident that this is gonna end up in something good or should I kill it and try again.
<vadi2> Peng_ thanks, that helped
<Peng_> Whether or not it will succeed, I doubt killing and restarting it will do anything but waste time.
<Peng_> vadi2: :)
<yml> Peng_ : I will wait some times and see if anything could come out ?
<yml> In case nothing good happens what are the options ?
<yml> I mean anything better than do it again in a fresh svn co. If this information can help I have done a push between 2 bzr repositories and it works fine.
 * Peng_ shrugs.
<yml> jelmer: After a long can I know that bzr push < URL of the svn repository> is not going to do anything.
<meoblast001> my friend just said bzr hung while pushing... killed all his programs.. and gave him the busy box fatal message
<mtaylor> hey all... I know this is an outstanding bug, but getting messages about bzr break-lock lp-44825360:///~drizzle-developers/drizzle/development/.bzr/branch/lock continues to be confusing to people...
<rocky> jelmer: i just had my "bzr svn-push" take several hours and sitll not complete, it looped over all branches over and over :(
<roadrunner_> Noob here. Sorry in advance. Wondering how to pull down using bzr previous versions of a main branch
<roadrunner_> My latest version of Gwibber does not work
<roadrunner_> Previous version worked fine so I had bright idea of using bzr to grab earlier revision
<jml> roadrunner_: "bzr pull -r <revision_spec>"
<jml> roadrunner_: if you know the revno you want, use that. Otherwise "bzr help revisionspec".
<jml> if you want to make a new branch for the older version, "bzr branch -r <revision_spec> <url>"
<mwhudson> vila: you here?
<mwhudson> mm, i guess it's pretty late for you
<yml> ï»¿rocky : If this can help you. I had the same problem
<yml> I haven't been able to solve it at the end I gave up I did all the modif again with SVN
<yml> rocky How do you know what bzr is doing ?
<rocky> yml: use the -v switch and monitor ~/.bzr.log
#bzr 2008-12-11
<yml> If I feel like trying again
<dD0T> Hy guys. Did anyone of you try the current windows build 1.9? I'm unable to get the svn plugin working.
<dD0T> It says Unable to load plugin 'svn' from 'C:\\Python25\\lib\\site-packages\\bzrlib\\plugins' . But if I understoof the website correctly svn should be included
<eferraiuolo> wondering how to get bzr to recognize my authentication.conf file.
<eferraiuolo> I'm using the bzr-svn plugin over https and it asks me for my pw multiple times
<poolie1> dD0T: can you please file a bug in https://bugs.launchpad.net/bzr-svn, including the contents of ~/.bzr.log
<poolie1> (see bzr --version for the location)
<jml> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<jml> is there a way I can tell _how_ they've diverged
<jml> bzr missing --mine-only, perhaps?
<lifeless> jml: yes
<jml> hmm. either that interacts poorly with looms
<jml> or my loom is shagged.
<jml> (both are possible, I hit Ctrl-C during a combine-thread and since then it's been a bit wonky)
<lifeless> jml: combine-thread is basically atomic
<jml> lifeless: I ended up with a checkout/limbo dir and something else.
 * jml resorts to export-loom again
<lifeless> jml: st;diff;revert should all fix it
<jml> yeah, so it looks like my bottom thread has all sorts of stuff that doesn't belong there :(
<pygi> jml, poke :)
<jml> pygi: hi
<jml> :( :( :(
<jml> _every_ time I work with looms I end up being sad.
<pygi> jml, :/
<lifeless> jml: is your bottom thread upstream?
<newz2000> Hi, I made some changes to a project some time ago and now I need to temporarily undo them and apply a change to an older version of a branch and publish it somewhere.
<newz2000> I did bzr branch project project-2 -r 4 and now have a copy tat is the way I want it
<newz2000> presumably I can make my change to this copy and get what i want, but how do i avoid bad stuff happening in the future?
<newz2000> what's the "right" thing to do I guess?
<mwhudson> newz2000: what 'bad stuff' are you afraid of?
<newz2000> losing a revision or making it hard to put stuff back together down the road
<newz2000> let me give more details
<newz2000> I have a branch I share with sysadmins. They codereview and publish it to a website.
<newz2000> Temporarily we'll be making a change for the holidays
<newz2000> I want to share my branch with them so that they can push the changes out but later on (after the new year) they'll use my changes that are in progress in the other branch
<newz2000> I don't want to make their life hard
<mwhudson> i think you should be fine
<mwhudson> just tell the admins to use push/pull --overwrite to move your changes onto the sever
<newz2000> ok, so just commit my change and push to the place I normally push to?
<mwhudson> server
<newz2000> ok
<mwhudson> you might want to push to somewhere else
<newz2000> ok, that makes sense
<newz2000> thanks for the help mwhudson
<mwhudson> np
<igc> hi all
<lifeless> hi igc
<igc> hey lifeless!
<pulsar> I am trying bzr update command to get updates from bzr repository on launchpad. it says tree is upto date at revision 183 but when i see it via web interface it shows revision 184
<pulsar> do I need to do anything before issuing bzr update for it to check the server for new revision
<spiv> pulsar: if you have a branch, you need "bzr pull" to get the new revisions
<spiv> "bzr update" updates a checkout to be current with the branch that it is a checkout of, "bzr pull" updates a branch from another branch.
<pulsar> spiv: ok trying that. my version control basics are really weak.
<pulsar> spiv: it to be at revision 185 now at both places. :)
<pulsar> thank you
<vila> hi all
<igc> night all
<ieei> does anyone know why I cant add a subdirectory in my bzr branch which includes a .svn subdirectory?? I'm using bzr1.9 and have bzr-svn installed
<spiv> ieei: bzr-svn allows you to use bzr to operate on SVN checkouts
<spiv> ieei: so if you have a .svn directory in a bzr checkout, then bzr-svn will notice that and so bzr will open the checkout as a SVN checkout and not as a bzr one.
<spiv> ieei: you could temporarily disable bzr-svn by passing --no-plugins to bzr
<spiv> ieei: but by far the simplest thing to do is to not have the same directory on disk versioned by both svn and bzr
<spiv> ieei: e.g. things can get very confusing if the .bzr directory says the checkout is at one revision of the SVN repo and the .svn directory says it's at another
<LeoNerd> I've tried to keep dual bzr/cvs checkouts before... It's doable, but it takes a lot of careful management
<LeoNerd> Easy to mess it up, and end up with conflicting histories in each side
<spiv> LeoNerd: dual bzr/cvs checkouts is easier because there's no bzr-cvs
<LeoNerd> How does that help?
<spiv> LeoNerd: so you don't have the problem that doing "bzr ci" will try to operate on the cvs data rather than the bzr data.
<ieei> spiv: thanks, I know that it is a bit stupid and confusing, but what I'm doing here is really stupid in the first place. I want to version the svn metadata in my bzr branch.. so anyway, thanks, i'll just temp. disable the bzr-svn
<fullermd> For extra points, version the bzr metadata in svn at the same time!
<ieei> hehe :P
<awilkins> Where are the Windows installers ;-)  ?
<jelmer> lifeless, ping
<LarstiQ> pwong
<jam> morning all
<LarstiQ> hei jam
<gioele> hi
<gioele> bzr revert does not revert the last commit. How come?
<fullermd> Because revert doesn't revert commits.
<luks> bzr revert reverts the working tree
<gioele> bzr uncommit then
<gioele> I see
<gioele> thank you
<lifeless> jelmer: yo
<NfNitLoop> *headdesk*   Someone at work has decided that half of the tree I am working on needs to be in another, separate SVN repository.
<lifeless> NfNitLoop: _nice_
<NfNitLoop> lifeless: isn't it?  This place so fails at sane source control.
<jam> lifeless: ping
<lifeless> jam: yo
<jam> how's MV?
<lifeless> intense :)
<lifeless> some very good discussion
<lifeless> chatted with jerry from samba today
<jam> how was that?
<lifeless> good
<jam> I was wondering if you had any thoughts on my "chunked" patch.
<lifeless> saw it go by last night, haven't had a chance to review; I was feeling quite ill last night
<lifeless> I'll poke at it asap
<jam> it isn't critically urgent, but I was hoping for "design" thoughts
<jam> more than code-level
<lifeless> well
<lifeless> we've discussed previously yes? seems fine to me
<lifeless> outputting thefragments a compressor has as they arrive is ok
<lifeless> it does seem a little special cased
<jam> So the big thing I wanted to get away from was needing to ''.join() and split_lines()
<jam> when some implementation thinks in fulltexts
<jam> and others think in line
<jam> lines
<jam> a fulltext => chunks is just (fulltext,)
<jam> which has a nice effect that ''.join([text]) is text
<jam> (if the list is a single string, it just returns the string)
<jam> mm-mysql: hey. Any updates on a Lunch schedule?
<jam> lifeless: btw, the 'chunked' work shows a decrease of about 300MB for the conversion. So we still use 700MB, but that is down from 1GB
<jam> And it seems to start at 400MB and then grow to 700. I'm not entirely sure why
<Peng_> jam: I have a possibly-stupid question: what's the point of running chunks_to_lines() over the result of file.readlines()? Won't it be identical?
<jam> Peng_: the previous code did "split_lines(''.join(readlines())"
<jam> so there was obviously some doubt
<Peng_> jam: Ah, good point.
<jam> I believe abentley was concerned about platform differences for file.readlines()
<lifeless> file.readlines() can be an arbitrary object
<jam> Like on Mac 9 it would split on '\r'
<jam> though we don't support OS 9
<lifeless> worth a comment I think
<jam> lifeless: it *can* but that code just did "open(filename)" so we know it is a real File object
<jam> Peng_: Also if you don't open the file in "binary" mode on Windows
<lifeless> jam: ah, heh. Certainly things like commit() don't know that
<jam> but we should always be doing that anyway
<lifeless> because they ask the tree and the tree is virtual
<jam> lifeless: yeah, that is TreeTransform code
<jam> where we do now
<marcoil> I changed svn-revision-scheme and now I get check_file_version_parents errors when checking and when trying to commit :( I've tried to remove the svn properties in the repo, but no luck
<lifeless> jelmer: ping
<mwhudson> vila: ping
<vila> mwhudson: pong
<mwhudson> vila: so we're vaguely thinking of not using apache to serve bazaar branches from bazaar.launchpad.net
<mwhudson> (and using something more dynamic instead)
<mwhudson> and were wondering what sort of features bazaar needs from an http server for efficient operation
<Peng_> Something more dynamic?
<mwhudson> range: header support is an obvious one
<vila> mwhudson: have a look at bzrlib/tests/http_server.py ? :-)
<mwhudson> Peng: branches are accessed via ~user/project/name but stored by database id
<mwhudson> Peng: this ends up being a pain
<mwhudson> vila: good idea!
<vila> mwhudson: from the top of my head, missing parts will be authentication, but even there I think there are some basis
<mwhudson> vila: we really don't care about authentication; yet, anyway :)
<vila> and of course you may want https too which I'm still working on
<jam> mwhudson: so if you aren't thinking to enable 'smart' support
<jam> then the #1 thing is Range: operation
<vila> mwhudson: there are also a couple of bugs pending regarding xmlrpc from behind proxies (which is used by the launchpad plugin)
<jam> vila: that shouldn't effect the server end, though
<jam> mwhudson: we can have some fairly large Range: requests
<jam> both number of bytes
<jam> and complexity of request
<mwhudson> jam: yes, i've noticed :)
<mwhudson> (they break the squid my isp lumbers me with)
<jam> I don't know how that would effect a potential Squid proxy
<jam> mwhudson: well that specifically is just because we start at 0
<jam> and then make a request >1MB away
<jam> we could break that into 2
<jam> but it adds a round-trip
<jam> and, unfortunately, we don't know we are going to have the problem
<jam> until after we have waiting for a *very* long time
<jam> I think we should consider a config-ish entry for controlling that, for people who know they are behind a broken proxy
<jam> mwhudson: Anyway, other than maybe 5-10 GET requests for a couple files, everything else is a readv()
<jam> we use it on both indexes and raw content
<mwhudson> ok, that's what i thought
<vila> jam: the squid bug doesn't occur so often AFAICT and is fixed in recent versions
<jam> I would *like* to see launchpad implementing bzr+http
<vila> jam: +1
<lifeless> squid bug is fixed in all supported versions; just some folk are bad about upgrading
<mwhudson> jam: that would be nice, yes
<jam> vila: what are you still doing around ? :)
<mwhudson> i get faintly terrified by resource consumption
<mwhudson> but that's step 2, anyway
<vila> jam: ponging mwhudson :-)
<jam> vila: when *I* work until after 10pm, its because I'm home all alone. I didn't think you had the same excuse
<vila> I don't, just back from restaurant and showing blinking icon to gf: look ! They're pinping again !
<vila> pinging even
<jam> Seems like you respond a bit too much to the little blinking icon :)
<jam> I'll keep it in mind
<mwhudson> vila: sorry for disturbing your evening
<vila> mwhudson: don't worry, I won't stay there :-)
<jam> vila, vila, vila: please pay attention to me :)
<vila> jam: I already voted tweak to your chunked patch :)
<jam> Sorry, but my wife and son are away for a month...
<mm-mysql> jam: Ah, hi.
<mm-mysql> Sorry.
<jam> hi mm-mysql
<mm-mysql> I was going to get back to you about *this* week, but unfortunately, I had a death in the family (grandma, not unexpected, totally, but still busy because of it), and a release to get out the door
<mm-mysql> What does next week look like for you?
 * mm-mysql pulls up the calendar
<jam> mm-mysql: I'm very sorry to hear that.
<jam> Next week I'm probably going to be out of town.
<mm-mysql> Ah.
<mm-mysql> Okay, so....
<mm-mysql> It's the week of xmas, what about the 22nd?
<jam> should be fine by my calendar (it is pretty much wide open :)
<mm-mysql> Let's pencil that in?
<mm-mysql> Where/when would you like to meet?
<jam> sure
<jam> Anywhere/anytime :)
<mm-mysql> heh.
<jam> Panera or the Brewery are both fun places
<jam> lunch or dinner is fine
<mm-mysql> Let's do the brewery, lunch?
<mm-mysql> High noon, or?
<jam> sounds good.
<jam> around noon
<mm-mysql> Okay. You're on the calendar.
<jam> I'll see you at the Brewery, around 12 noon, on Dec 22nd.
<vila> mwhudson: a word of caution about bzrlib/tests/http_server.py, look at it for features, not implementation, it's nowhere near to be optimized (quite the opposite even as it's the base for all sort of torture test servers, so the emphasis is on easy extension/redefinition rather than performance)
<mwhudson> vila: sure, i think i'm probably going to start with something from twisted
<lifeless> mwhudson: have you considered a j-i-t mapping lookup, feeding the result into the mod-rewrite core?
 * emmajane submits her first-ever bzr bug.
<mwhudson> lifeless: you mean the "prg" rewritemap thing, or however it's spelt?
<mwhudson> yeah
<mwhudson> it's another option, no decisions as yes
<mwhudson> yet
<Devourer> Is there a way to convert a Mercurial repository to a Bazaar repository?
<lifeless> Devourer: you can you hg fast-export and bzr ast-import quite easily
<lifeless> *fast-import*
<jelmer> hi abentley, poolie
<abentley> jelmer: Hi.
<meoblast001> hi
<meoblast001> does pushing a large revision often say 0/0 for a long time?
<meoblast001> how do i drop a revision
<meoblast001> i dont want to change any files
<meoblast001> i just want to delete revision 2
<meoblast001> i really messed it up
<bob2> you can't, really
<bob2> you could branch from r1 and merge r3... into it
<meoblast001> ok i'll just delete the files and recommit
<bob2> that won't remove them from the history, though
<meoblast001> revision 2 has too many files and it hangs trying to upload them
<bob2> you might just need to wait longer
<meoblast001> i put wxGTK and wxMozilla in it
<meoblast001> im not supposed to do that right?
<bob2> no
<meoblast001> yeah
<meoblast001> exactly
<meoblast001> bob2: i broke bazaar
<meoblast001> bzr: ERROR: Could not acquire lock "(remote lock)"
<meoblast001> what do i do?
<meoblast001> bob2: im about ready to hit myself in anger
<Peng_> meoblast001: If you're absolutely sure the branch/repo isn't actually in use, you can use "bzr break-lock $the_url" to unlock it.
<meoblast001> ok
<meoblast001> thanx
<meoblast001> i know its not
<meoblast001> no one ever uses it
<Peng_> meoblast001: You do. :)
<meoblast001> i dont  want to push revision 2
<meoblast001> only revision 3
<meoblast001> revision 2 has too much for my internet connection to handle
<meoblast001> Peng_, is this imposible? if it is im gonna hit a wall or something
<Peng_> meoblast001: More or less, no. It would be easiest to uncommit revisions 2 and 3, delete the stuff from 2 and recommit 3.
<meoblast001> ok
<meoblast001> how do i uncommit?
<meoblast001> i hate timelimits
<jam> meoblast001: bzr uncommit -r1
<Peng_> "bzr uncommit" :D
<jam> to commit *to 1*
<jam> you'll probably want to follow that with "bzr revert" to stop versioning mozilla and wx
<jam> either revert everything, or just parts of the tree
<meoblast001> thanx
<meoblast001> i always forget this stuff
<meoblast001> i gtg though
<meoblast001> bye
<emmajane> spiv, heh. "This space left intentionally blank."
<spiv> emmajane: pretty much :)
<emmajane> I like it. :)
<emmajane> I'd been getting random errors on .bzr/repository/obsolete_packs/': as well. But it wasn't anything I could reproduce reliably so I hadn't reported it yet.
<emmajane> It sounds like that might be the same problem though?
<spiv> Right.
<emmajane> sometimes it's a problem, and then 2 seconds later I run the same commit again, and it's fine.
<spiv> It's an often empty directory, but whenever packs are repacked (which happens automatically every so often) then you'll get that error.
<emmajane> ah
<emmajane> yes, "every so often"
<spiv> "every so often" == every 10 commits, if commits are all you do (rather than pushing/pulling into the repo, say)
<emmajane> "random" problems are a little bit infuriating. :)
<jml> lifeless: is it a bug that for looms, 'switch' will change threads when there are uncommitted changes, but 'down-thread' won't?
<jml> lifeless: (hint: yes)
<emmajane> spiv, commits and uploads.
<spiv> jml: down-thread won't?
<emmajane> spiv, I'm in the middle of tweaking CSS files...
<lifeless> jml: no
<spiv> jml: I thought it did...
<spiv> (but I guess I haven't tried doing that)
<lifeless> jml: I thought about it hard when merging abentley's branch, and its correct
<jml> lifeless: it's also causing me lots of problems.
<lifeless> jml: now is not a great time to discuss; but think about the issues of going down-thread with a pending merge - down-thread is recommended for various workflows
<lifeless> jml: alternative safety nets are good
<lifeless> as in, I'd like alternatives
<jml> lifeless: I want switch to stop me from switching unless I pass a --yes-i-know-what-im-doing flag
<jml> that would give me options
<jml> but as you say, we can discuss later.
<jml> lifeless: I'll review your branches now, btw.
<emmajane> It took me a while (and a lot of face on desk smashing) to figure out that "uploads" the directory is in no way related to the plugin uploads.
<emmajane> and we won't talk about the .bzr folders that I just plain old deleted assuming it was corrupt.
#bzr 2008-12-12
<spiv> Well, technically, a .bzr/repository folder without an upload folder is corrupt.
<spiv> It happens to be a very easy-to-repair corruption, though.
<emmajane> spiv, yes. :)
<emmajane> spiv, it's "corrupt" not "OMG THE SKY IS FALLING" ...
<kenichi> hello, i'm a bzr n00b, and it's printing this error with a "get" : bzr: ERROR: Lock not held: LockableFiles...
<kenichi> hmm.... it also happens with "info" on the same URL... is it a server issue?
<jml> I need to make a knit branch with lots of ugly, url-escape-needing paths.
<jml> anyone have one lying around?
<mwhudson> bzr-svn is good at that :)
<mwhudson> jml: https://code.edge.launchpad.net/~mwhudson/pydoctor/axiom-attr-support might fit
<mwhudson> yeah, looks like it
<jml> mwhudson: sweet. thanks.
<mwhudson> e.g. http://bazaar.launchpad.net/~mwhudson/pydoctor/axiom-attr-support/.bzr/repository/knits/06/
<lifeless> jml: interesting; its a key goal of switch to switch with edits; you just want a '--with-edits' option, or ???
<jml> lifeless: basically, yes.
<jml> lifeless: the thing that's happened a lot to me is that I've switched to trunk to pull, and got conflicts because I have uncommitted changes.
<lifeless> jml: would it help if switch told you about the remaining local edits?
<lifeless> e.g. switch == switch + status --short?
<jml> lifeless: before or after it switched?
<lifeless> post
<lifeless> pre is meaningless as the switch may eliminate outstanding changes
<jml> hmmm. well, it would help if there was a clear way to undo it, particularly in the case of conflicts.
<lifeless> jml: I think this needs more discussion; please mail the list and I'll try to reply tonight once backa tthe hotel
<jml> lifeless: will do.
<mwhudson> i've always found it slightly weird that pull doesn't complain about local changes
<mwhudson> if you're pulling, you're maintaining a local mirror
<mwhudson> wth are you doing editing it?
<mwhudson> other workflows may vary i guess
<Peng_> kenichi: :P
<Peng_> fwiw, kenichi is running bzr 1.10, and i experience the same problem in bzr.dev.
<kenichi> http://pastebin.com/d37ce3b4f   <--- all two lines of my issue :)
<Peng_> Traceback: http://paste.pocoo.org/show/VFV2fMUc25uhKKEBIuRf/ (But it doesn't look very interesting; the exception is rather self-explanatory.)
<mwhudson> is bzr-svn messing things up again?
<Peng_> mwhudson: For this? --no-plugins doesn't help.
<mwhudson> ah well
<Peng_> Heh.
<abentley1> mwhudson: It's more for a workflow where you "bzr pull; bzr commit; bzr push".
<mwhudson> yeah, i guess so
<jml> use pyflakes guys
<jml> https://bugs.edge.launchpad.net/bzr/+bug/307327
<ubottu> Error: <Bugtracker.plugin.Launchpad instance at 0x874150c> bug 307327 not found
<jml> I smell replication lag :)
<spiv> jml: by "guys", you mean "abentley" ;)
<abentley> jml: ?
<spiv> abentley: a -Dhpss mutter that moved in your patch from remote.py to graph.py is failing due to a missing import of mutter in graph.py
<abentley> spiv:
<abentley> Sorry.
<spiv> abentley: not a big deal.  I'm considering just deleting the offending mutter.
<spiv> I don't think we've ever really used it, so it's just yet another thing filling log files.  And -Dhpss isn't exactly the right condition for it now it's in a more general-purpose class.
<spiv> Hmm, although, you did make a _debug variable for it.
<spiv> So if we want to keep the debugging there ought to be tests for the debug case.
<abentley> spiv: Yeah, I agreed that hpss was the wrong flag for a general-purpose thing.
<jml> I'm going to make a plugin that does: bzr down bottom:; bzr pull; bzr up-thread --auto; bzr switch <original-thread>
<spiv> abentley: do you have any interest in keeping that debugging?  I'm inclined to just delete it.
<abentley> spiv: No, I don't.
<abentley> jml: What about "shelve --all" first?
<spiv> Ok, let's just remove it as cruft.  It's not hard to reinstate if someone actually wants it.
<jml> abentley: and unshelve at the end? not a bad idea.
<abentley> jml: yeah
<spiv> jml, abentley: patch for 307327 sent
<abentley> spiv: I see you also deleted an import.  Was that deliberate?
 * jml bundle buggers.
<spiv> abentley: yes.  That import statement was unused.
<spiv> I meant to mention that in the email...
<spiv> abentley: that import statement was all that was standing between me and clean "pyflakes bzrlib/graph.py" output :)
<mwhudson> i cleaned up all the flakes in bzrlib/[ab]*.py at one point i think...
<abentley> spiv: I'm not sure why that was there in the first place.  It may have been backwards compatibility.
<spiv> abentley: well, in the absence of a comment...
 * spiv looks at how long it's been there
 * spiv also wishes Python had a mechanism for deprecating module attributes
<spiv> abentley: that line was added on "Fri 2007-06-08 17:48:42 -0400", in a commit by you saying "Rename graph to deprecated_graph"
<spiv> abentley: I guess it's been deprecated long enough by now?
<abentley> spiv: lemme check bzrtools
<spiv> abentley: hah. :)
<abentley> spiv: bzrtools is still importing that stuff, but I can change it to use deprecated_graph.
<spiv> abentley: thanks
<spiv> abentley: I guess I should add a note to NEWS just in case someone else is still using them.
<lifeless> spiv: please do
<lifeless> you can deprecate a module BTW
<lifeless> 1) make it demand loaded within bzrlib, 2) during import emit a warning
<jml> lifeless: I've reviewed tags. I'll get to the others later.
<spiv> lifeless: really, part 1) isn't even necessary.
<lifeless> spiv: well, it helps :P
<spiv> :)
<Rolly> Someone made a mistake and committed a sensitive file in the very first revision of a branch. Can I use rebase to fix this? I think I can, but I don't understand the documentation
<lifeless> jelmer: ^ we really need to make this a nobrainer
<lifeless> Rolly: its something like 'bzr init; bzr merge -1 ../source; bzr revert --forget-merges; bzr rm SENSITIVE; bzr commit -m 'first post'; bzr rebase -r 2.. ../source'
<Rolly> lifeless: thanks! I'll give it a shot
<mwhudson> that's merge -r 1 ../source, i think
<Rolly> yeah
<lifeless> you'll need to use a new repository too, as the history data will stay in the repository and that would be annoying for you :)
<Rolly> Ah that's OK, it's not shared :)
 * spiv -> food
<Rolly> whoops, there's also a sensitive change in revno 3
<Rolly> I think I can figure it out
<jml> bzr expunge-swearing
<Rolly> whoops. "bzr merge -r 2 ../source" => bzr: ERROR: A nested progress bar was not 'finished' correctly.
<lifeless> Rolly: -r 1..2
<lifeless> also file a bug
<lifeless> bbiab, bus time
<Rolly> thanks lifeless
<Rolly> still get the error
<Rolly> filed bug #307340
<ubottu> Launchpad bug 307340 in bzr "bzr merge: A nested progress bar was not 'finished' correctly" [Undecided,New] https://launchpad.net/bugs/307340
<meoblast001> hi
<lifeless> Rolly: oh, try -r 1..2 --force
<meoblast001> i want someone to pull from my project on launchpad but he's not a launchpad member
<meoblast001> what should he do?
<lifeless> Rolly: though really, to get rev2 you want to be using rebase at that point
<meoblast001> bzr pull bzr+ssh://bazaar.launchpad.net/~mysticgalaxies/opencollab/devel ?
<lifeless> meoblast001: go to the project page, then the branch and there is an http url
<lifeless> meoblast001: bzr branch http://bazaar.launchpad.net/~mysticgalaxies/opencollab/devel
<meoblast001> ok
<meoblast001> thanx
<Rolly> lifeless: --force still produces the same error
<lifeless> Rolly: ok, you're going to have to edit the code and disable the error about progress bar not closed to see the real error
<lifeless> Rolly: thats in bzrlib.progress.py
<Rolly> can do
<Rolly> bzrlib/progress.py?
<Peng_> Rolly: Yeah.
<igc> hi all
<Rolly> Peng: you'll have to guide me through it, I'm afraid. I don't know very much python.
<Peng_> Rolly: Eh. I just walked in on this conversation.
<Peng_> igc: Hello
<Rolly> oh sorry, I was addressing lifeless
<lifeless> Rolly: have a look for the error in the file
<lifeless> Rolly: line 150
<lifeless> change
<lifeless> raise errors.Missing...
<lifeless> to
<Rolly> ah
<lifeless> return # raise errors.Missing
<Rolly> lifeless: http://pastie.org/337348
<lifeless> Rolly: thats a bug; may be hard to reproduce. abentley ^ can you suggest anything?
<lifeless> Rolly: may need to fill abentley in on how you got that
<lifeless> Rolly: also, have you already done the init;merge;revert--forget;rm;commit dance to get the first rev across?
<Rolly> yes i did
<lifeless> Rolly: try bzr diff -r 1..2 ../source | bzr patch :)
<Rolly> That will work, but I can wait for abentley to give his input
<abentley> Rolly: I wasn't aware of any bugs in that area.  Is this a publically-available branch?
<Rolly> I'm afraid not
<Rolly> Both target and source branches are 1.9-rich-root
<abentley> Rolly: So you're running it on an empty branch?
<Rolly> abentley: I did a few things first:
<Rolly> bzr init ; bzr merge -r 1 /source ; bzr revert --forget-merges ; cp config.php config.php.template ; bzr rm config.php ; bzr add config.php.template ; bzr ci -m "Initial import"
<Rolly> by the way, that last commit produced messages like "renamed TODO => TODO", "renamed classes => classes", "renamed models => models", etc
<Rolly> just thought that was a little wierd
<Rolly> and at the end of the messages it said:
<abentley> Rolly: So, you should never merge into an empty branch unless you're deliberately trying to get the effect of pull.
<Rolly> deleted
<Rolly> deleted config.php
<Rolly> Committed revision 1.
<Rolly> notice the empty "deleted"
<Rolly> I see
<Rolly> I try again, this time using pull
<Rolly> *I'll
<abentley> Well, in your case, maybe that works.  But the results are generally confusing.
<abentley> Rolly: I *think* what you did is equivalent to "bzr pull -r -1; bzr uncommit"
<abentley> Rolly: Why "bzr rm config.php"?
<Rolly> I don't want config.php versioned at all (I wanted a sanitized config.php.template instead)
<Rolly> I think pull was the wrong choice
<abentley> Rolly: The empty deleted might refer to the root directory.
<Rolly> It did work, though. No errors when I tried merge -r 1..2 ../source
<Rolly> but config.php is right there, in revno 1
<Rolly> oh, you suggested "bzr pull -r -1; bzr uncommit". I'll try that
<Rolly> doesn't uncommit still leave the old tip in the repo, though?
<spiv> Yes.
<Rolly> Ah, that won't work for me, then.
<abentley> Rolly: So does merge.
<Rolly> I think that's why lifeless initially suggested 'bzr init; bzr merge -r 1 ../source; bzr revert --forget-merges; etc...'
<abentley> Rolly: That will still leave the old tip in the repo.
<spiv> There currently isn't anything that removes revisions from a repo.  You can gc the repo manually by making a new repo and copying across only the tips you want to keep.
<Rolly> Is there no way to rebase this branch so that the sensitive file in revno 1 of ../source is completely gone?
<spiv> Rolly: removing the sensitive data from the history of the branch is different to also removing it from the repo.
<Rolly> spiv: what about the remove-revisions plugin?
<spiv> Rolly: Rebasing will change the branch history, but you still need to take extra steps (i.e. making a new repo) to remove the revisions from the repo.
<abentley> Rolly: If you create a new copy of the branch with "bzr branch", it won't copy the tip.
<spiv> Rolly: I'm not familiar with it, sorry.
<Rolly> OK. Boy, this is extremely confusing to me ;D
<Rolly> if I branch -r 1 of ../source, the offending file I wish to remove is right there in my repo, no?
<Rolly> *in my new repo
<abentley> Rolly: Yes.  I'm talking about if you branch "."
<Rolly> What if I simply export or copy revno 1 of ../source into my new empty repository, delete the file, and commit?
<Rolly> Can I then continue to merge the rest of the revisions in ../source?
<abentley> Rolly: You need to preserve the file-ids, or else merge won't work.  So plain copy or export is not going to do what you want.
<Rolly> And will that keep the deleted file out of the repo?
<Rolly> I see
<Rolly> 'bzr remove-revision' will apparently 'Remove revisions from repository'. Do you think I could use that command to accomplish what I want?
<abentley> Rolly: I don't know that command.
<abentley> What plugin does it come from?
<spiv> If it does do that, then that will accomplish what you want.
<Rolly> http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk
<Rolly> But how would it fit in to this whole process?
<abentley> Rolly: Presumably, you could run it after you had generated your revised version of the branch.
<Rolly> bzr init ; bzr pull -r 1 ../source ; bzr remove-revision -r 1 ; bzr add . ; bzr ci
<Rolly> something like that? ^
<spiv> Rolly: that plugin looks like it needs revids, rather than revnos.
<spiv> (which makes sense)
<abentley> Rolly: No, you can't commit when your current revision doesn't exist.
<abentley> Rolly: You don't need remove-revision.  You just need to branch "."
<spiv> Rolly: so the procedure would be: generate a branch without the offending revision in its ancestry (e.g. with rebase), then generate a repo without that revision (e.g. with remove-revision, or e.g. by making a new standalone branch).
<Rolly> abentley: Do you mean 'bzr branch ../source/.' ?
<abentley> Rolly: EMPHATICALLY NO
<Rolly> :*(
<Rolly> spiv: the offending revision is revno 1. Is rebase still possible?
<abentley> I mean "bzr branch . new_version_of_branch_without_offending_revision_in_repo"
<Rolly> thanks I'm trying that now
<spiv> Rolly: I haven't used the rebase plugin enough to know.
<abentley> Rolly: you need to do that after you've committed your alternate revno 1.
<abentley> Rolly: And probably your alternate revno 2 also.
<spiv> But it sounds like you want a different first revision, rather than to just remove the first revision?  If so, the "init;merge;revert--forget;rm;commit dance" lifeless mentioned sounds reasonable.
<Rolly> abentleyL I'm really sorry, I don't understand. I just did "cd ../source ; bzr branch . ../new" and it branched all of the revisions
<abentley> Rolly: The problem is that you did "cd ../source".
<abentley> Rolly: You have a current directory, containing an alternate revno 1, which does not have config.php.  *that* is what you need to branch.
<abentley> You have not told me the name of that directory, so I'm calling it "."
<Rolly> Gotcha. And what does "new_version_of_branch_without_offending_revision_in_repo" mean?
<Rolly> is that the location I'm branching to?
<abentley> Rolly: Yes.
<Rolly> Eureka, thanks
<Rolly> Is the "." somehow special?
<spiv> No, it's a path like any other.
<spiv> Well, a path meaning "the current directory", of course.  But just a path.
<Rolly> Thanks spiv/abentley/lifeless. I'll continue tomorrow but I think I know what I'm doing now
<chrismurf> How can I *permanently* obliterate all records of a file from BZR?
<chrismurf> I'm trying to move some files from a previous closed SVN repo to an open BZR repository, and would like to maintain what history I can, but delete some files which aren't being opened
<spm> chrismurf: "A" method that I personally used: http://www.stedee.id.au/2008/11-06/manually_migrating_subversion_repository_launchpadbzr
<spm> there may be other better ways. YMMV.
<chrismurf> hmm - doesn't sound like fun, but does sound like exactly what I'm looking for :-)
<chrismurf> thanks
<spm> np
<chrismurf> what's the benefit of faffing  about with svndump and svnadmin, rather than just using svn2bzr --exclude?
<Peng_> We use bzr-svn instead now, and it can't exclude? :P
<chrismurf> haha - I see :-)
<chrismurf> oh yeah - svn2bzr doesn't even exist
<chrismurf> how about that
<Peng_> svn2bzr doesn't exist anymore?
<chrismurf> well, the repo linked to on the site is down: http://bazaar-vcs.org/svn2bzr
<chrismurf> but there are branches in LP that I'm looking at.
<spiv> chrismurf: which repo is that?  The links I followed on that page all seem to work.
<chrismurf> bottom of page
<chrismurf> "Current development version can be found in"
<spiv> chrismurf: that link works for me.
<spiv> chrismurf:
<spiv> $ bzr log -r -1 --line http://bzr.labix.org/svn2bzr/trunk/
<spiv> Format <RepositoryFormatKnit1> for http://bzr.labix.org/svn2bzr/trunk/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
<spiv> 13: Gustavo Niemeyer 2008-04-06 Merging changes from James Henstridge branch...
<chrismurf> oop -I'm being stupid
<chrismurf> no HTML page, but BZR Repo.
<chrismurf> thanks
<chrismurf> Judicious use of svn2bzr is just the ticket.  Thanks spm!
<spm> chrismurf: np. I found that bzr-svn just wouldn't work the way I needed it to. Could have been pebkac. Shrug. I got there in the end. :-)
<chrismurf> yeah - I'm finding it doesn't quite do what I want either :-/
<chrismurf> in particular SVN mv's (of which there were some near the end) are not handled well
<chrismurf> I think that's a problem on the SVN side, but I'm trying to figure out how to match up the move's manually...
<chrismurf> sigh.
<chrismurf> I need a repository editor ;-)
<chrismurf> little delete here and tweak there.... voila!
<chrismurf> what could possibly go wrong
<spm> I vaguely recall it would only process about half of the main repo and then barfed. Hence the switch to svn2bzr, which worked.
<spm> :-)
<chrismurf> I tried to include /trunk/foo/bar and exclude everything else, and it barfed until I also included /trunk$ and /trunk/foo$
<chrismurf> wasn't smart enough to create dir's
<spm> heh - try and use svndumpfilter maybe?
<chrismurf> may just look at the BZR python API and code the transfer by hand.
<chrismurf> don't know svndumpfilter or particularly want to learn SVN internals :-)
<chrismurf> or maybe I'll just horribly abuse svn2bzr -- hard to say.  I'll come up with something.
<spm> svndumpfilter is documented enough in the red-bean book (from memory); and the actual dump file is pretty obvious - well I was able to use awk against it :-)
<chrismurf> anybody know generally how to import "SVN MV" actions to BZR?
<chrismurf> ie how to convert a "delete, add" to a "rename"
<lifeless> chrismurf: bzr pull will do that
<chrismurf> ah - as opposed to bzr co?
<lifeless> well bzr co svn://foo will do a branch operation, same overall result
<chrismurf> hm - seemed to not understand mv's somehow...
<chrismurf> will try again.
<lifeless> sleeptime for me
<lifeless> gnight all
<vila> hi all
<chrismurf> spm, you there?
<jelmer> spm, what were you trying to do exactly?
<jelmer> spm: Importing a svn branch into bzr but ignoring some files from the svn branch in the process?
<jelmer> lifeless, What should be made a no-brainer?
<spm> jelmer: hey. 2 things - 1. import trunk, ignore all the tags and branches made; and a series of files that I didn't want/need in bzr & 2. change the 'committer' so LP would register it as me. That 2nd was more of an everest challenge than truly being useful. :-)
 * igc dinner
<jelmer> spm, ah, ok
<jelmer> spm: That's indeed not possible with bzr-svn
<jelmer> spm, The idea would be that bzr has some tools to do that sort of thing
<spm> :-)
<spm> jelmer: fwiw, I originally worked this out back in July, so reasons for/why etc are a tad vague now. The blog posting was the streamlined version when I redid for another project.
<spm> "I know this works; I will do it this way"
<tga> howdy
<jelmer> spm, ah, thanks
<jelmer> spm, (just curious, but it's good to know about that use case)
<spm> jelmer: np, glad to help even in such a small way :-)
<tga> I'm looking at setting up a central repository for a project and I'm not sure where the files are actually supposed to live
<tga> the manual says that "central shared branches typically only want to store history, not working copies of files"
<tga> so where do the files go?
<bob2> tga: do you understand the distinction between working copy, repository and branch?
<tga> not fully, as it's probably evident
<tga> working copy = actual files I'm working on, checked out from repo
<spm> tga: they live inside the ... repository, kinda like inside a zip file, to use a really loose analogy. You can extract them in the dir in the cental location, but don't have to.
<bob2> repository = bag of revision data
<bob2> branch = pointer to one revision (and thus all that revision's ancestors)
<bob2> working copy, yeah
<bob2> so in a ceentral shared branch dealy, you just have branches and a repository, no working copies
<tga> so does the repository contain the actual files or just changes?
<bob2> the latter, sort of
<tga> so when I check out a file is recreated by going through all changes?
<bob2> conceptually
<bob2> in reality it'll probably have a nearby copy cached
<tga> I see now, so there is no need for a working copy on the repo
<bob2> *handwave*
<spm> tga: exactly
<tga> alright, thanks, I'm slowly getting to understand what's going on
<spm> tga: if you have access to 2 machines? create a local repo. add some files, commit, repeat a few times to get some simple history; now 'bzr push' that repo to the 2nd PC via, eg, ssh. You should only have a .bzr in the remote directory.
<spm> on the 2nd machine; now bzr branch from that .bzr only directory, and behold, all the files re-appear :-)
<spm> So in your case; that 2nd machine would be the central repo that everyone else could branch from. Clear as mud?
<tga> why do I need to explicitly create a repo? from what I can see, bzr init on a directory gets me the same thing
<spm> you don't need to.
<tga> what do I get by doing it though?
<spm> ... control over who can commit to trunk
<bob2> it is just a storage optimsation
<bob2> you only need to store changes shared between related branches once
<bob2> rather than for each one
<bob2> spm: you sure you need a repository for that?
<tga> sooo technically I could bzr init on my working dir and copy the .bzr dir to the server?
<spm> bob2: no - I misunderstood the question - your answer was more correct
<bob2> tga: yup
<tga> that's nice
<spm> tga: is very nice. we rsync dir's all over the place that way. Even to the prod servers.
<bob2> (if you 'bzr init' in a repository, though, you can't - .bzr in the branch doesn't store the "revision data", it just points at the repository's store)
<tga> just to make sure I'm on the right track here, does this sound alright: bzr init, add, commit on /local/project/src dir, bzr init-repo on empty /server/project, then in /local/project/src, bzr push /server/project/trunk
<Peng_> tga: I just walked in on this conversation, but yes, it does.
<tga> thanks Peng_
 * tga is fixing a million "file name too long" errors
<Peng_> tga: (You'd probably want to create a local repo too in /local/project or whatever, if you hadn't already.)
<tga> why?
<Peng_> In case you want multiple branches.
<tga> oh, I see
<tga> so I don't duplicate code all over the place?
<Peng_> Without a shared repository (bzr init-repo), "bzr branch" will copy the entire repository, which just wastes space.
<tga> gotcha
<jonnydee> hi, does anyone know when the bzr-1.10 installer for windows will be released?
<Peng_> jonnydee: Posts on the list have said that there are problems with the machine they're built on, so the answer is either "When the people responsible for the machine fix it", or "When someone else manages to go through the complicated build procedure".
<Peng_> (Or, "When anybody manages to figure out what's wrong in the first place, and fix it"
<Peng_> )
<jonnydee> Peng_: thangs for your info :)
<LarstiQ> moin
<rocky> is there anyway to merge repos? i need all the history out of one repo to go into another repo
<awilkins> rocky: You can just branch the branches into the other repo
<awilkins> Do you mean "can I splice the history of two branches together" though?
<rocky> no i think your first suggestion is what i need
<rocky> i have bzr repo X, repo Y ... repo Y has a couple branch histories that i need in repo X, and i need to destroy repo Y
<awilkins> The converse is also true - you can "split" repos by making new ones and only branching branches with history you wish to keep into them
<rocky> hm... how do i make eshell display the status bar that comes up on a long bzr checkout? :)
<vila> rocky: export BZR_PROGRESS_BAR=tty
<Peng_> rocky: Repositories are just big bags of revisions. They don't have to be related at all.
<etank> how do i tell bzr to stop watching a file that is already being watched
<etank> bzr ignore tells me that it is already being watched and will not be ignored
<awilkins> bzr ignore foo
<awilkins> bzr rm foo --keep
<etank> aah
<etank> --keep
<etank> cool thanks awilkins
<awilkins> You're welcome
<etank> i did a bzr rm and the file went o00f
<etank> s/o00f/p00f/
<awilkins> you could make an alias - "forget = rm --keep"
<etank> that would work too
<etank> sweet
<etank> i should have looked at http://doc.bazaar-vcs.org/bzr.dev/en/quick-reference/quick-start-summary.pdf more closely
<etank> what i was looking for is right there in the middle :)
<tga> how can I automatically update a working copy of a branch on the server every time there is a commit?
<Peng_> tga: If you're pushing over bzr+ssh or sftp, you can use the bzr-push-and-update plugin.
<tga> ah, plugin, right
<marcoil> with bzr-svn 0.5 rc1: "bzr: ERROR: Could not determine revno for {svn-v4:<s3kr3t>:33292} because its ancestry shows a ghost at {<s3kr3t>}". Any idea?
<marcoil> (when committing, btw)
<marcoil> the last two days with bzr-svn have been hell, really. I don't know what I did, but it stopped working perfectly as it used to do and it's making me go nuts :(
<LarstiQ> marcoil: did that timeframe include a move from 0.4 to 0.5
<LarstiQ> ?
<marcoil> yep, it was the only way of getting it to at least work. For one commit :) Then I got that strange message. Sorry, I didn't want to rant...
<LarstiQ> why did 0.4 not work?
<marcoil> I added a branch to the svn-branching-scheme and I stated getting lots of error messages
<marcoil> and couldn't commit
<bialix> hi, is Marius here?
<LarstiQ> marcoil: aha
<bialix_> I guess no.
<LarstiQ> marcoil: branching-schemes are a painful area of bzr-svn, so I'm unfortunately not surprised changing it gave some problems
<LarstiQ> marcoil: as to 0.5, I haven't tried it yet. It's supposed to get rid of branching schemes, but apparently it's not yet ideal either.
<marcoil> anything that gets rid of the branching schemes is great... Our repo has some really strange scheme
<lamont> so how do I get bzr visualize (bzr-gtk) in intrepid without getting that bzr-notify crack?
<jam> lamont: I'm pretty sure the notify stuff is only a "recommends" not a requires
<jam> I would uninstall bzr-dbus if it lets you easily
<lamont> bzr-notify is delivered in the bzr-gtk package
<lamont> which I just removed from my machine as the simplest way to get rid of the totally annoying popup
<lamont> of course, if there's a way to have it _NOT_START_, that'd let me have bzr visulaize
<jam> I don't really know enough about it to help
<jam> I generally run from source
<lamont> because every commit really wants to interrupt my thought process with a popup telling me that, oh wait: I just committed
<jam> mkdir -p ~/.bazaar/plugins; cd ~/.bazaar/plugins; bzr co lp:bzr-gtk gtk
<lamont> ah
<lamont> yeah - I'm a package kind of guy
<lamont> and I use bzr when the folks I'm working with want me to use it... otherwise there's this other VCS that I'm still more comfortable with that has all my source in it already...
<StoneToad> lamont: you can tell it to stop running
<lamont> StoneToad: yeah...  it was a "GRRR HOW" kind of moment that I didn't want to bother figuring out
 * fullermd didn't even know there was a 'notify', and still doesn't know what it does   :p
<StoneToad> lamont: ah yea, I ran into the instructions somewhere when I was trying to figure out what the hell this icon in my satuts bar was :)
<StoneToad> try apt-get remove bzr-dbus
<StoneToad> intrepid pulls in recommends by default now
<StoneToad> (which is the correct default for debian based systems)
<StoneToad> if you want to block a recommended package from being installed you can do something like apt-get install packageIwant packageIdontwant-
<StoneToad> you can also use + appended to the name to make it install that package (handy for forcing an alternative package that provides a dependency)
<lamont> StoneToad: yeah... apt and I are old friends
<lamont> and installing recommends? yeah, makes sense for many things, esp when suggests are correctly used
<StoneToad> ahh how important that "correctly" is :)
<lamont> verily
<lamont> esp when many crackheads use Recommends as "I think this'd be cool"
<onox> I get this error when I try to pull a branch:
<onox> bzr: ERROR: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed.
<onox> anyone know what's wrong?
<StoneToad> are you in a console? (no X)
<lifeless> onox: remove the bzr-dbus plugin; there is a bug if you are not in a X session
<onox> in a gnome-terminal
<onox> never happened before. Just yesterday with 1.9 and today with 1.9 and 1.10
<Tak> I get that sometimes with screen sessions as well
<Tak> (even in an X session)
<lifeless> onox: aare you in a screen session that was started from a previous X instance?
<onox> no
<onox> it happens when emerge starts to pull in revisions of awn-extras
<lifeless> emerge is probably isolating itself then
<lifeless> I'll try and get it ixed today, but its kinda hectic here
<onox> lifeless: maybe, I do have sandbox and userfetch FEATURES enabled, but it has worked for months this way
<lifeless> onox: did you dbus version change? they change the exact error-to-catch regularly
<lifeless> its like whack-a-mole
<onox> lifeless: nope, only upgraded portage to 2.1.6 on Dec 11 02:13
<onox> but it also happens with pkgcore
<lifeless> onox: so the cause is probbly something adding more sandboxing IMO.
<lifeless> not the root cause, which is the bug, but the proximate cause
<onox> I'll try it without sandboxing
<onox> back in 20 min.
<lamont> lifeless: all of dbus is whack-a-mole
<lifeless> abentley1: https://code.edge.launchpad.net/~bzr/bzr-dbus/trunk seems not to be syncing
<lifeless> abentley1: the webui is showing 37, I see 38 as most recent
<abentley1> lifeless: That's how it looks to me, also.
<lifeless> mthaddon: ping ^
<mthaddon> lifeless: let me check if there's a problem with the branch scanner
<abentley> lifeless: I'm adding the ability to specify a thread to up-thread --auto
<lifeless> abentley: cool. Do we hwave up-thread --auto?
<abentley> lifeless: We do.
<abentley> lifeless: Should up-thread $THREAD imply --auto?
<abentley> lifeless: The alternative seems to be erroring.
<lifeless> abentley: yes, I think it should
<abentley> lifeless: Cool.  Will do.
<lifeless> alternatively
<lifeless> up-thread is automatic, and --manual is used to go up one-thread manually
<abentley> Okay, I'll do that.
<bialix> luks: hi
<abentley> lifeless: --no-auto or --manual?  --no-auto is just a change of default, and won't break anyone.
<lifeless> abentley: no-auto seems ugly to me
<lifeless> loom is still really beta, I think breaking people is better than ugly
<abentley> lifeless: Okie.
<lifeless> --manual isn't perfect either, if you think of a better name, go for it
<abentley> lifeless: I've pushed the performance enhancements and --manual change into my branch.
<lifeless> abentley: cool; doubt I can look trivially today, can you drop a merge-request into lp for it ?
<abentley> lifeless: Sure.
<jam> lifeless: after today you are gone until January, right?
<enigma> Question about bzr-svn 0.5 RC1...
<enigma> It's great that it supports following copies now.  Woohoo!
<enigma> Is the SVN version which made the copy supposed to be showing up in the version history?
<enigma> Example.
<enigma> If I have: svn copy http://server/svn/trunk/foobar http://server/svn/branches/newfoo
<enigma> Then, if I do a bzr branch on each of those URLs.
<enigma> I don't get the same history.
<enigma> The history for the copy has an extra revision in it: the revision that made the copy.
<jelmer> enigma: Yes, that's correct
<enigma> So I can't merge between the branches.
<enigma> Which seems a little strange to me since in bzr when I make a branch, the history is identical.
<jelmer> enigma, You can merge between the two, they share the same ancestry
<enigma> Oh...you're right...my mistake...I was trying to "pull"
<enigma> I can't pull from the "trunk" to the "branch"
<enigma> Since the trunk is missing a revision.
<enigma> I'm just trying to understand if that's the intended behavior.
<jelmer> yeah, that sounds right
<jelmer> the same thing would happen if you had two bzr branches, one of which was one revision ahead of the other
<enigma> So I should be using "merge" instead of "push" and "pull"?
<enigma> Yeah, that's what's messing me up.
<enigma> In SVN, they are identical.
<enigma> Intuatively, I expect the rev that made the branch to not count as a revision from bzr's point of view.
<jam> enigma: well, why have  a separate branches if you are going to push&pull between them to keep them as identical mirrors?
<enigma> Just like making a new branch in bzr doesn't create a revision.
<jelmer> enigma, they have the same contents in svn
<jelmer> enigma, but they have a differen thistory in svn too
<jam> enigma: but it does in svn
<jelmer> enigma, try running "svn log" on both
<jam> IIRC you have to commit the new branch
<jelmer> enigma, creating a new branch in svn means doing a "pointless" commit
<enigma> jelmer: We have a "business requirement" to use SVN.
<enigma> And that "business requirement" mandates a layout.
<enigma> So, there are some branches in two parts of the tree that are simply clones of each other.
<jam> enigma: interesting. Though I would still say "merging things into trunk" rather than push&pull is a better way to work
<jam> If only for the joy it gives "bzr log --short"
<jelmer> enigma, sure, I don't see what the problem is with that pointless commit in either svn or bzr
<jam> enigma: so after creating the new branch, can you push that back into trunk?
<enigma> One thing we've done before is a: bzr push --overwrite http://sever/svn/branches/newbranch
<enigma> jam: let me try
<jam> It seems like it would be a bit weird for svn to support that
<jam> since it versions everything in the same namespace
<jelmer> it does support it
<enigma> Then I can push and pull between the two...which is REALLY COOL! :-D
<enigma> So I was expecting to be able to do that between branches in SVN with 0.5...but I can't because of the extra "pointless commit" which made the branch.
<jelmer> jam, It removes the old branch with the same name and creates a new one with the same name
<enigma> jam: and it pushes the whole revision history with it. :-D
<jelmer> enigma, only in 0.4
<jelmer> because you had two branch paths with different branching schemes
<enigma> Oh...OK.
<jelmer> it should no longer do that in 0.5
<jelmer> enigma, you should be able to get around the pointless commit by using merge or rebase
<enigma> OK...that's good to know.
<enigma> I can rebase an SVN branch?
<jelmer> well, you can rebase your local bzr branch before you push it to svn
<enigma> Oh, I see...but then I can't push it back to the original, right?
<jelmer> enigma, right
<enigma> Is there anyway to "hide" or "ignore" the pointless commit and not have it considered part of the branches history?
<enigma> Since it really is meaningless from bzr's point of view?
<jelmer> enigma, you can set the bzr:hidden revision property on the pointless commit
<jelmer> that will make bzr-svn ignore it
<enigma> Yeah!? Is "bzr:hidden" in the docs?
<enigma> It's new to me.
<jelmer> enigma, no, it's not in the docs
<enigma> How do I use it?
<jelmer> it's an experimental new feature
<enigma> OK, and it's part of 0.5 RC1?
<enigma> How do I use it?
<jelmer> it's not actually intended to be set by users
<jelmer> but you can, if you insist
<enigma> >:-)
<jelmer> set "bzr:hidden" to ""
<jelmer> and "bzr:root" to the branch path on which you made the commit, with all leading and traling slashes trimmed
<jelmer> you will have to remove your bzr-svn cache if you do this, since bzr-svn normally sets this during commit
<jelmer> and you will have to make sure everybody else who is using that repository removes their bzr-svn cache as well
<enigma> Where is that property set?
<jelmer> you can set it with "svn propset --revision ...
<enigma> SVN let's you set properties on revisions? Really? (I never knew...)
<enigma> OK. I'll give that a go
<jelmer> enigma, not out of the box
<jelmer> enigma, you have to enable the right revision property hook
<enigma> Oh, OK. I'll check and see if that's setup for our repo.
<enigma> Thanks again for all your help!
<enigma> bzr-svn is fantastic! I've been really impressed.
<jelmer> thanks
<jelmer> enigma: btw, you will have to remove your existing bzr branches if they were created using bzr-svn already contain any revisions on which you're setting these svn properties
<enigma> OK...that's good to know too.  Thanks.
<LarstiQ> heya poolie, sabdfl
<sabdfl> howdy LarstiQ
<poolie> hello LarstiQ
#bzr 2008-12-13
<enigma> I think I'm hitting a bug in bzr-svn 0.5 RC1
<enigma> bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'uuid'
<jelmer> enigma, I think there's an open report about that one
<enigma> OK. Are those reported in the same place as bzr bug?
<enigma> Or is there a separate bug tracker for bzr-svn?
<jelmer> launchpad.net/bzr-svn
<enigma> OK. Let me look it up.
<enigma> jelmer: It looks like those errors come up when the bzr properties are missing. I created the svn branch using "svn copy", is that why it doesn't have bzr properties?
<jelmer> based on the tracebacks in that bug report at least, it can't be related to bzr propeties
<jelmer> it's a problem in the way bzr-svn follows the svn log to find out the branch history
<jelmer> unfortunately I can't reproduce it here
<enigma> Which bug report are you looking at?
<enigma> I found: https://bugs.launchpad.net/bzr-svn/+bug/177383
<ubottu> Launchpad bug 177383 in bzr-svn "traceback when importing svn tree: 'NoneType' object has no attribute 'splitlines' (dup-of: 174690)" [Undecided,New]
<ubottu> Launchpad bug 174690 in bzr-svn ""pull" should handle removal of bzr:ancestry property" [Low,Fix released]
<jelmer> enigma, that's not the same bug
<enigma> And: https://bugs.launchpad.net/bzr-svn/+bug/206728
<ubottu> Launchpad bug 206728 in bzr-svn ""'NoneType' object has no attribute 'splitlines'" crash in checkout" [Undecided,Fix released]
<jelmer> https://bugs.edge.launchpad.net/bzr-svn/+bug/306288
<ubottu> Launchpad bug 306288 in bzr-svn "pulling a previously branched SVN repo with no local commits causes a "branches have diverged" error" [Undecided,New]
<enigma> Oh...this is what I did...I have a few hundred revisions I pulled down using bzr-svn 0.4.15. I then pushed those revisions into a brand new repository.
<enigma> I then upgraded to bzr-svn 0.5 RC1 and pulled those revisions from the brand new svn repo.
<enigma> (using bzr to pull it)
<enigma> I do a commit on the branch.
<enigma> I then try to "push" back to that new svn repo and that's when I get the error.
<enigma> (And yes, I cleared the svn-cache and subversion.conf after moving 0.5 RC1)
<enigma> Is the bzr:* properties that are created with bzr-svn 0.4 incompatible with bzr-svn 0.5?
<jelmer> no, they should work ok
<jelmer> though there could be a bug there
<jelmer> of course
<pygi> hi hi folks
<enigma> jelmer: OK...now I'm reverting to 0.4.16 and I'll try the same commit with a push back to svn.
<enigma> (After clearing svn-cache and all that)
<enigma> Hm...now if I revert, I get this: bzr: ERROR: exceptions.KeyError
<enigma> Sorry, I just re-read that and I don't think it's clear.
<enigma> What I mean is...now if I try the commit back to the same svn repo using bzr-svn 0.4.16 instead of 0.5 RC1 I get that "KeyError"
<jelmer> enigma, can you pastebin the full backtrace?
<jelmer> enigma, were some revisions already pushed using 0.5rc1?
<enigma> Not that I can recall....
<enigma> I'm pretty sure it was all push with 0.4.16...
<enigma> You want me to recreate the SVN repo from scratch with 0.4.16 to make sure?
<enigma> (Where's the pastebin?)
<jelmer> pastebin.ubuntu.com
<enigma> http://pastebin.ubuntu.com/84616/
<jelmer> I think that's actually a bug that's fixed in 0.5..
<enigma> Oh, OK. :-D
<enigma> I'm recreating the svn repo using 0.4.16.
<enigma> Then I'm going to switch to 0.5 RC1 and see if I can get that "uuid" error again.
<enigma> I'm getting another exception with 0.4.16, might this be a bug?  bzr: ERROR: bzrlib.errors.NoSuchRevision: <bzrlib.plugins.svn.revids.RevisionIdM
<enigma> apCache object at 0x88c328c> has no revision enigma@neumannc-desktop-20081202021
<enigma> 216-yyxr9acya83v2rjt
<enigma> I got the tree I'm trying to push from another svn repo.
<enigma> And now I'm doing this: bzr push -v --overwrite svn+http://localhost/svn/test/trunk/gui
<enigma> Oh...this is strange...
<enigma> If I push just the first rev it works fine: bzr push -r 1 -v --overwrite svn+http://localhost/svn/test/trunk/gui
<enigma> But pushing 386 revs doesn't work.
<enigma> After pushing the first rev with "overwrite", I can do a "normal" push, but I get segfaults.
<enigma>  bzr push -v --overwrite svn+http://localhost/svn/test/trunk/gui
<enigma> The svn+ syntax is deprecated, use http://localhost/svn/test/trunk/gui instead.
<enigma> \ [===                                              ] pushing revisions  25/385Segmentation fault
<enigma> jelmer: Even though I got a segfault, I can push some more...
<enigma> jelmer: But then I get another segfault after 44 revs...
<enigma> After restarting the push about 5 times, I get all revision into svn.
<jelmer> enigma, but that's using 0.4 ?
<enigma> Right. this is with 0.4. Want me to try with 0.5?
<enigma> I'll go through the same steps with the same repo.
<enigma> Yeah, I get the same behavior with 0.5 RC1
<jelmer> same being that error about uuid ?
<enigma> Sorry...haven't gotten to the uuid error.
<enigma> I'm getting a NoSuchRevision error when I'm trying to recreate my svn repo.
<enigma> Quick recap: zapped the svn repo which I was using that was giving me a "uuid" error.
<enigma> Started recreating the repo from scratch.
<enigma> That brought up this other bug which I encountered before but had forgotten about.
<enigma> And it appears this bug is in 0.4 and 0.5
<enigma> This is for the NoSuchRevision error: http://pastebin.ubuntu.com/84623/
<enigma> Work around is...
<enigma> do this: bzr push -r 1 -v --overwrite svn+http://localhost/svn/test/trunk/gui
<enigma> But the work around only seems to work for 0.4.16
<jelmer> any chance you can file a bug about this?
<enigma> Sure.
<enigma> OK, here's the new bug report for the "NoSuchRevision" error (which exists for both 0.4 and 0.5): https://bugs.launchpad.net/bzr-svn/+bug/307611
<ubottu> Launchpad bug 307611 in bzr-svn "Pushing lots of revisions from one svn repo to another results in bzrlib.errors.NoSuchRevision" [Undecided,New]
<jelmer> enigma, the repository is private, I presume ?
<enigma> Unfortunately, yeah.
<enigma> I wish I could share. ;-)
<enigma> jelmer: Is there a bzr-svn equivalent of "bzr check"?
<jelmer> well, you can run "bzr check" on a svn branch but it won't do much
<enigma> Is there something that can "check" the bzr:* properties on an svn repo?
<enigma> That sort of thing?
<jelmer> nope
<enigma> OK.
<jelmer> there's probably something going wrong recording the contents of enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt
<jelmer> is it a merge revision or something? What sort of changes does it contain?
<enigma> How do I see?
<enigma> I tried:  bzr log -r enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt
<enigma> that doesn't seem to work
<jelmer> bzr log -rrevid:enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt
<jelmer> should work
<enigma> Oh, OK...trying...
<enigma> No...it wasn't a merge...
<enigma> Just a plain commit...
<enigma> Is there a way to rebuild the map?
<jelmer> enigma, what sort of changes does it contain?
<jelmer> enigma, which map?
<enigma> The bzrlib.plugins.svn.revids.RevisionIdMapCache
<enigma> That map.
<jelmer> it's part of the cache
<jelmer> so after you remove the cache, the map will be empty (and it gets filled lazily)
<enigma> Oh...I see what might be going on....
<enigma> I did this: bzr branch svn+http;//remote/svn/trunk/gui gui-trunk
<enigma> then I did this: bzr branch gui-trunk gui
<enigma> After which I cleared my cache.
<enigma> And then I tried to push the versions into: http://localhost/svn/trunk/gui
<enigma> Which is a totally different server.
<jelmer> not sure I follow..
<enigma> And if I do a bzr info on "gui", it only knows about "gui-trunk" and not the original svn server.
<enigma> So it will never tried to rebuild the map.
<enigma> Which I purged from the cache.
<enigma> In short, I did a "pull" from server A and then a push to server B.
<jelmer> that should work just fine
<enigma> However, after doing the "pull", I remove the svn-cache (due to experiementing with other things)
<enigma> The "push" to server B isn't rebuilding the RevisionIdMapCache for server A.
<enigma> Just for server B.
<jelmer> there's no reason why it should
<jelmer> we don't need the cache for A in that situation anyway
<enigma> Oh, OK.
<enigma> So why would I get an error about a particular revision not being in the RevisionIdMapCache?
<enigma> If the cache isn't used?
<jelmer> to bzr-svn, those revisions are just like ordinary bzr revisions
<jelmer> or should be, at least
<enigma> Why would that revision id be expected to be in the RevisionIdMapCache at all then since I haven't pushed it to server B and the RevisionIdMapCache for server A shouldn't be used?
<jelmer> it's thinking one of the children of that revision has to be pushed and that revision itself is already present
<jelmer> so when it crashes, it hasn't pushed that particular revision yet?
<jelmer> what is the revision id of the children of that revision?
<enigma> Right. That the latest revision in the repo.
<enigma> There are not children of that revision...it's just a straight up commit.
<enigma> Correction...it's the -2 revision, not the -1 revision.
<enigma> Second most recent rev.
<jelmer> what's the revision id of the last revision?
<enigma> Is there a nice way to get a revid from a revno?
<jelmer> bzr log --show-ids -r<revno>
<enigma> Cool, thanks. It's not in the help for log.
<enigma> Oh wait...yes it is...I missed it...sorry.
<enigma> revno: 385
<enigma> revision-id: enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt
<enigma> parent: enigma@neumannc-desktop-20081202014850-fgbyjkv8rqfbdm23
<enigma> What's the "parent"?
<enigma> In this case, the "parent" is the previous revision.
<jelmer> the parent is the revision the revision was basd on
<enigma> OK.
<jelmer> there can be multiple parents in thecase of a merge
<enigma> OK.
<jelmer> but what's the revision id of the last revision?
<enigma> revno: 386
<enigma> revision-id: enigma@neumannc-desktop-20081202023059-gzdv3fvxklm0v1z4
<enigma> parent: enigma@neumannc-desktop-20081202021216-yyxr9acya83v2rjt
<enigma> So, I'm not seeing anything weird about rev 386 or 385 or 384....
<jelmer> is that revision a merge revision perhaps?
<enigma> No...the last merge in the history was at rev 378
<rocky> jelmer: don't suppose you have a good list of new stuff in the bzr-svn 0.5.x series?
<jelmer> rocky, see NEWS
<jelmer> enigma, strange
<enigma> I have exactly 4 merges in the whole history.
<enigma> And doing a "push -r 1" works just fine.
<jelmer> enigma, is this 0.5.0rc1 or 0.5 ?
<enigma> This is 0.4.16 in this case.
<jelmer> enigma, push -r1 would push the first revision in history, so that's a noop :-)
<rocky> jelmer: ah thanks ...
<enigma> With 0.5 RC1 I get a different error.
<enigma> Well...sort of...
<jelmer> ah, what's the error in that case?
<enigma> I get the same error for "push --overwrite"
<enigma> But I get a different error for "push -r 1"
<enigma> I mean...
<enigma> "push -r 1 --overwrite"
<enigma> I posted both the 0.4.16 error and the 0.5 RC1 error on: https://bugs.launchpad.net/bzr-svn/+bug/307611
<ubottu> Launchpad bug 307611 in bzr-svn "Pushing lots of revisions from one svn repo to another results in bzrlib.errors.NoSuchRevision" [Undecided,New]
<enigma> They are both in the block at the top.
<enigma> They kind of run together...probably needed some more whitespace between them.
<jelmer> I mean with "bzr push -r1 --overwrite" on 0.5
<enigma> OK...let me get that error and post in on the bug report...one sec.
<jelmer> (bugs in 0.4 are not likely to be fixed anymore, I'm focussing on 0.5)
<enigma> (Makes sense.)
<enigma> OK, look at my most recent comment here: https://bugs.launchpad.net/bzr-svn/+bug/307611
<ubottu> Launchpad bug 307611 in bzr-svn "Pushing lots of revisions from one svn repo to another results in bzrlib.errors.NoSuchRevision" [Undecided,New]
<enigma> I get an AssertError with 0.5 RC1
<enigma> bzr: ERROR: exceptions.AssertionError: revprops: ['bzr:revision-id', 'bzr:user-agent', 'bzr:timestamp', 'bzr:root', 'bzr:committer', 'svn:log', 'bzr:revprop:branch-nick', 'bzr:file-ids', 'bzr:base-revision', 'bzr:revno', 'bzr:mapping-version']
<jelmer> ah, that's been fixed in the 0.5 branch
<enigma> So should I get the truck for 0.5 instead of RC1?
<jelmer> yeah
<jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.5
<enigma> OK, let me grab it.
<rocky> i was just about to play with 0.5rc1 .. should i skip it and just try 0.5 branch ?
<rocky> jelmer: python setup.py install doesn't appear to work with 0.5rc1 :(
<rocky> basically it looks like the subvertpy package doesn't get installed
<enigma> jelmer: OK, the latest bzr-svn 0.5 fixed that assert error.
<enigma> It did not, however, fix the missing revision error.
<enigma> So that seems like it's still a bug.
<enigma> Ah ha! I got the "uuid" error again: bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'uuid'
<enigma> That was after pushing just one revision.
<rocky> enigma: how are you installing 0.5rc1 (or the branch?) ... the used-to-work-with-0.4.x "python setup.py install" doesn't seem to work  for me
<enigma> Oh, I just run it out of "~/.bazaar/plugins/svn"
<enigma> I do a "make"
<enigma> And then copy it to the plugins directory.
<enigma> I don't do a sitewide install.
<jelmer> rocky, that's also fixed in the 0.5 branch
<rocky> lol
<jelmer> enigma, at the risk of asking the same question twice..
<jelmer> enigma, the backtrace in bug 307611 for 0.5 was produced by pushing into a fresh svn repository?
<ubottu> Launchpad bug 307611 in bzr-svn "Pushing lots of revisions from one svn repo to another results in bzrlib.errors.NoSuchRevision" [Undecided,New] https://launchpad.net/bugs/307611
<enigma> yes, a fresh repo.
<jelmer> enigma, with fresh repo you mean "svnadmin create ..", right?
<enigma> yeah.
<jelmer> ok (since you mentioned "svn mkdir" in the bugreport)
<enigma> I had one commit to make "trunk"
<enigma> And one commit to make "trunk/gui"
<enigma> So, the svn repo was at v2 when I tried the "push --overwrite"
<enigma> So here's something strange with 0.5-trunk...
<enigma> I'm being told wrong svn info now:
<enigma> revno: 1
<enigma> svn revno: 4684 (on /trunk/press-gui)
<enigma> committer: Christoph Neumann <enigma@qbert>
<enigma> So, after sucessfully doing this: bzr push -r 1 -v --overwrite svn+http://localhost/svn/test/trunk/gui
<jelmer> enigma, that looks alright if you ran "bzr push -r1 --overwrite"
<enigma> I did this: bzr branch svn+http://localhost/svn/test/trunk/gui
<enigma> Which is *really* strange because the svn repo is at rev 3 now.
<jelmer> yes, but you pushed only one bzr revision, right?
<enigma> Yeah, so why is it telling 4684?
<jelmer> enigma, that's derived from the revision id
<enigma> That was the right svn revision for the repo the change came from.
<enigma> But the new repo is now at rev 3.
<jelmer> enigma, what does "svn info" on http://localhost/svn/test/trunk/gui say?
<enigma> svn info http://localhost/svn/test/trunk/gui
<enigma> Path: gui
<enigma> URL: http://localhost/svn/test/trunk/gui
<enigma> Repository Root: http://localhost/svn/test
<enigma> Repository UUID: 27530666-c0bc-4525-b9dd-495b6ed8d586
<enigma> Revision: 3
<enigma> Node Kind: directory
<enigma> Last Changed Rev: 3
<enigma> Last Changed Date: 2008-12-12 19:17:26 -0800 (Fri, 12 Dec 2008)
<jelmer> hmm
 * jelmer has to get some sleep
<jelmer> I'll have another look at your bug report tomorrow
<jelmer> sorry
<enigma> No problem.
<jelmer> thanks for the help debugging, at least
<enigma> I'll see if I can get in IRC tomorrow.
<enigma> If you have more questions.
<enigma> Thanks for all your help!
<jelmer> cool, that could be useful
<enigma> I learned lots of stuff.
<jelmer> I'll try to reply in the bugreport as well
<jelmer> g'night!
<enigma> OK. Goodnight.
<Rolly> is it possible to list all revids in a repository?
<lifeless> jml: yo
<jml> lifeless: hey there
<lifeless> jml: so testresources has a bunc of 'fix committted' stuff.
<lifeless> I'm wondering if 'its in trunk' is good enough
<jml> lifeless: good enough for what?
<lifeless> for us
<jml> lifeless: are you wondering whether we should do releases?
<lifeless> kinda
<jml> lifeless: I've been using "fix commited" in the bzr project sense.
<jml> lifeless: i.e. "there's a branch with a fix"
<lifeless> hmm
<lifeless>  think some bugs are mislabelled then
<jml> lifeless: it's possible.
<jml> lifeless: I haven't done a round of gardening for a while.
<jml> lifeless: also, my laptop battery is dying and I'm not near power.
<lifeless> jml: ok, I have what I need - I'll use test released for stuff in trunk
<lifeless> jml: thanks
<jml> lifeless: I've just reviewed the third of the four subunit branches marked for review.
<jml> lifeless: I'll get to the fourth soon.
<jml> "polish" hasn't been submitted for review either.
 * jml suspends.
<meoblast001> does launchpad have bzr-cia?
<lifeless> jml: thanks
<cammoblammo> I'm running the bzr 1.5 on Debian. I only use it for syncing a heap of text files between a few machines. Is there anything to be gained by compiling and installing 1.10?
<davidstrauss> I'd like to understand why this bug isn't being treated too seriously: https://bugs.launchpad.net/bzr/+bug/113809
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed]
<davidstrauss> Is there a workaround I'm missing?
<davidstrauss> How can users do local commits without having to worry about this?
<bialix> does anybody knows about something like `bzr chdir` command? to change directory before run arbitrary command and then chdir back?
<davidstrauss> bialix: just change your actual directory
<davidstrauss> bialix: and many commands allow explicit definition of a directory
<bialix> I need this for batch processing.
<bialix> but missing is not
<bialix> https://bugs.launchpad.net/bzr/+bug/207762/
<ubottu> Launchpad bug 207762 in bzr "missing does not accept "-d" parameter" [Low,Confirmed]
<davidstrauss> bialix: I don't see why actually changing your directory would be a problem
<bialix> because I'm working on scmproj plugin that operates on the set of bzr branches as unite project
<bialix> I've implemented project-command command to run some command for all branches in the project in one loop
<davidstrauss> bialix: I still don't understand why you can't run "cd" instead of your desired "bzr chdir" command
<bialix> but `bzr missing` is unable to run in this way
<bialix> because of design of my plugin.
<bialix> actually I'm already implemented chdr command, I'm just wonder is not I'm reinventing the wheel, or does anybody else needs such feature.
<davidstrauss> bialix: and your plugin could run something like "bzr chdir"?
<bialix> yes, I'm just finished it
<bialix> in the past I remember that `bzr status` is also behaves differently either it runs as `bzr status .` or without any arguments.
<davidstrauss> bialix: I know several bzr commands interpret "." as an argument differently than nothing, especially add
<davidstrauss> bialix: add only uses ignores without an argument
<bialix> yep
<fullermd> Er, not exactly.  Add only uses ignores for discovered items, not given items.
<davidstrauss> fullermd: And if you give it an argument, you're using a "given item."
<fullermd> Yes, but add can still discover items (e.g., 'bzr add .' will recurse and discover items, to which ignores will be applied.  But they won't be for '.' itself, only for the discovered ones.)
<davidstrauss> Maybe I was thinking bzr add *
<davidstrauss> but that's only one level different
 * fullermd nods.
<fullermd> So that will add an ignored subdir, but not add anything _within_ it (which can be a little confuzzling)
<davidstrauss> fullermd: Agreed, especially when you're coming from svn
<fullermd> Wait, that's wrong.  I'm thinking of a different case.
 * bialix likes "confuzzling" :-)
<fullermd> Ignoring the subdir doesn't ignore the files within it.  I'm thinking of cases where I ignore '*'
 * fullermd aims to please  ;)
<LarstiQ> bialix: you're familiar with the -d option on a number of commands?
<LarstiQ> bialix: in my and mwhudson's opinion at least, that should be supported on more commands
<bialix> LarstiQ: yes, I'm aware about -d. But `bzr missing` lacks it
<davidstrauss> fullermd: Then I'll give you a fresh opportunity. I'm trying to figure out the best Bazaar workflow for next week's Drupal code sprint. It's all the core Drupal developers. If Bazaar handles things smoothly, I think it may strongly influence Drupal's next choice of VCS>
<LarstiQ> bialix: right, so my vote is for missing to be modified to support it. How exactly does your `bzr chdir` work?
<bialix> I'm just wanna say that you could provide valid non-local URL to -d, so --directory name for this option is actually bad name
<bialix>         cwd = os.getcwdu()
<bialix>         os.chdir(directory)
<davidstrauss> fullermd: Given the terribly flawed implementation of commit --local, I need a smooth way for developers to commit changes locally (to a branch, likely) but still push changes centrally
<bialix>         try:
<LarstiQ> bialix: hmmm. That won't work for commands needing a workingtree, would it?
<bialix>             return run_bzr(argv_list)
<bialix>         finally:
<bialix>             os.chdir(cwd)
<LarstiQ> bialix: (giving a non-local url to -d)
<bialix> LarstiQ: most of the command that supports -d works with the branch, not WT
<davidstrauss> fullermd: The problem with bzr push is that it modifies the central repository history
<davidstrauss> fullermd: and that's sort of evil
<LarstiQ> bialix: I'm thinking of merge specifically
<davidstrauss> fullermd: I can make the central repository "append-revisions-only", but then diverged branches can't be pushed
<LarstiQ> davidstrauss: you can set a branch config to not reorder the mainline.
<LarstiQ> right
<bialix> yes, you're right; merge is exception here
<davidstrauss> LarstiQ: So, is there any solution other than the terribly clunky combination of checkout and branch for each developer?
<LarstiQ> bialix: so you'd use bzr chdir by writing your normal command, and then sticking chdir between 'bzr ' and the rest?
<LarstiQ> davidstrauss: I'm not entirely sure what you're trying to solve.
<LarstiQ> davidstrauss: since to me, reordering the mainline is not evil.
<bialix> LarstiQ: yes
<fullermd> Well, that's the sorta setup I always use.  I've not found it especially clunky, but then I don't run into offline conditions often.
<davidstrauss> LarstiQ: I guess I don't understand how the reordering affects the mainline
<bialix> why not?
<fullermd> Not when I'm doing something I'd put right on trunk, anyway.
<LarstiQ> davidstrauss: but, if I understand you correctly, merge the diverged branch into trunk. And the checkout helps in not racing.
<LarstiQ> bialix: okay, that approach will work with any and all commands, which is a plus.
<LarstiQ> bialix: I don't find it too elegant though :/
<bialix> LarstiQ: exactly
<davidstrauss> LarstiQ: How does the mainline get reordered? Does it use the revnos from the branch that was pushed?
<bialix> LarstiQ: well, it's a 5 minute hack to provide workaround
<LarstiQ> davidstrauss: it will use the ordering of the pushing branch, yes
<fullermd> davidstrauss: The revnos are dependant on what the head rev is (rather, the history implied by it)
<LarstiQ> bialix: right
<bialix> it may be confusing, but it's a matter of taste
 * LarstiQ nods
<bialix> bzr cd foo/bar missing http://foo.net/branch
<davidstrauss> So, how should other developers get changes from the central branch, pull or merge? If they pull, then their local revnos change, too, right?
<bialix> well, it actually need to train the eye
<LarstiQ> davidstrauss: right
<davidstrauss> LarstiQ: So should local devs merge?
<davidstrauss> (from the mainline)
<LarstiQ> davidstrauss: depends on what they want to do
<LarstiQ> davidstrauss: personally, I'd just pull.
<davidstrauss> But if there's divergence, you have to merge first, right?
<LarstiQ> davidstrauss: that could go two directions though
<davidstrauss> LarstiQ: the merge?
<LarstiQ> davidstrauss: they could merge their stuff into trunk, commit, and then pull from trunk
<LarstiQ> instead of merging trunk into their branch
<davidstrauss> How do people on a development team communicate about revision numbers if they're unstable?
<LarstiQ> bialix: on the -d side, it would be nice if this operation was the same on all commands, but it would also be nice if you could use the '-d' branch without a working directory. Hmmm
<LarstiQ> davidstrauss: right, that is the question you need to ask. How much is that worth to you?
<davidstrauss> I think it's worth a lot to have consistent revision numbers for communication
<bialix> LarstiQ: sometimes I think -d is misdesigned
<LarstiQ> davidstrauss: One answer could be: revnos are instantaneous, they lose their validity after a (short) amount of time
<bialix> especially re tag command
<davidstrauss> LarstiQ: like process IDs on unix
<LarstiQ> davidstrauss: that's a nice analogy
<LarstiQ> bialix: how so?
<LarstiQ> davidstrauss: if you want to use them in bugreports that might be open for a couple of weeks, then it becomes more important that they be stable.
<bialix> IMO bzr tag TAGNAME URL is good enough
<LarstiQ> davidstrauss: so there you could do two things afaics, one is to refer to revision ids, not revision numbers. The other would be to base the revnos on a branch where the mainline does not get reordered.
<AmanicA> as I mentioned i nthe mailing list I think we need a "standard option" -d which works the same for all commands
<bialix> AmanicA: some commands don;t need -d, e.g. status, diff, commit, add
<davidstrauss> revision IDs are 100% stable, right?
<LarstiQ> davidstrauss: yes
<AmanicA> yes but for scripting purposes, I think it'l be nice to have a consitant interface for all commands
<davidstrauss> Is there a way to detect whether a revision ID has been integrated into a branch?
<bialix> may be you're right; but having 2 ways to express things... confuzzling?
<davidstrauss> (Other than bzr log --show-ids|grep ID)
<LarstiQ> davidstrauss: bzrlib wise or command line wise?
<davidstrauss> command line wise
<fullermd> You could use revision-info maybe.
<fullermd> (there's no "yes/no" giving command, but you can use side effects like "does this work".
<LarstiQ> that would be my guess as well.
<LarstiQ> or bzr missing
<fullermd> Hm.  Well, OK, you can use revision-info and see if it blows up and gives you a traceback   :|
<davidstrauss> Cobalt:a straussd$ bzr revision-info "david@fourkitchens.com-20081213120349-g6y28op35qnf3rhe"
<davidstrauss> bzr: ERROR: No namespace registered for string: u'david@fourkitchens.com-20081213120349-g6y28op35qnf3rhe'
<davidstrauss> that's what I get
<davidstrauss> with or without quotes around the revision id
<fullermd> bzr revision-info -rrevid:a@b.c-1235
<davidstrauss> that works
<davidstrauss> thanks
<davidstrauss> How do other DVCS tools handle the issue of stable history on the main branch?
<davidstrauss> I know most use the hash-based IDs as the primary revision tracking IDs.
<LarstiQ> davidstrauss: right, that's how hg and git do it
<LarstiQ> davidstrauss: there are some Linus quotes on revision numbers being a stupid idea even :)
<davidstrauss> LarstiQ: I think I'm starting to agree with him
<davidstrauss> I don't like that Bazaar gives the false impression that the numeric IDs will be stable.
<LarstiQ> where? how?
<LarstiQ> Revision numbers are stable in one branch only.
<davidstrauss> LarstiQ: When you come from SVN or CVS, you're used to revision numbers never changing once set.
<davidstrauss> LarstiQ: And, no, revision numbers are not stable even within one branch if you push to that branch.
<fullermd> Well, it's not to do with revision numbers at all.
<fullermd> Nobody else (TTBOMK) has a concept of a branch mainline at all.
<davidstrauss> fullermd: pardon?
<LarstiQ> davidstrauss: you just changed the branch there
<LarstiQ> but yes, what fullermd said
<fullermd> People who rail against bzr revnos always seem to miss that they're not the primary at all; they're an emergant property of the mainline concept.
<davidstrauss> fullermd: Please explain.
<davidstrauss> (or link me to something)
<fullermd> The problem with fiddling the history isn't that the revnos get messy per se; it's that you lose the mainline, and so lose that extra tool (and because the UI is built assuming the usage of that tool in many ways, a lot of things get way less convenient)
<davidstrauss> fullermd: Which extra tool?
<fullermd> The mainline.
<fullermd> Think of it as a way of winnowing down history.
<fullermd> Would it be useful to run $VCS log, and get the revisions in your history in a randomized order?
<davidstrauss> fullermd: obviously not
<fullermd> Yah.  So you need to sort them somehow.
<fullermd> The "right" was is "in the order they belong", which is way too ill-defined to actually use.
<fullermd> A good first approximation is chronological.
<fullermd> That works great in a purely linear system like CVSVN.
<davidstrauss> fullermd: So how does bzr order them if you have a sort-of mainline everyone pushes to?
<fullermd> In a parallel system like a DVCS, it's a bit stickier, since a revision no longer has a unique "that came before me".
<fullermd> So bzr imposes an extra structure of a 'mainline', which is defined by the left (or first, whatever term you want) parent of each revision.
<fullermd> And declare that that revision is the one that, conceptually speaking, was "before me".
<fullermd> Later parents (usually there would only be one, but you could octopus if you really wanted) are conceptually "stuff I grabbed from elsewhere".
<fullermd> Linus likes to emphasize that merges are symmetrical; you merge two things together.  That's true technically, but I (and bzr apparently) feel that socially they're asymmetric; you merge FROM somewhere else INTO your local thing.
<fullermd> The mainline is a way of using that symmetry breaking to split up your history.  So conceptually, unless you push/pull over something, the mainline is "what happened on this branch", and the right-side descents are "things I got from elsewhere".
<fullermd> That means that, for instance, the revision before the head on the mainline (revno -2) is what was the head before your last commit.
<fullermd> Whereas if you act in a way that doesn't preserve a mainline (like fast-forward merges, which most other systems default to always doing), you can't actually say "what was this before?"
<fullermd> This is especially useful on a 'trunk' type branch, because it may be very useful to be able to look back and say "Hey, what was trunk like last week?"
<davidstrauss> fullermd: Is there a concrete example of this behavior I can work through myself?
<fullermd> With something like git, it's impossible to say deterministically (unless you tagged it), because there could be 5 or 6 branches of the history that existed independantly then.
<fullermd> Sure, look at the history of bzr.dev.
<fullermd> This exhibits another emergant property of the mainline, which is the 'rollup' capability for offside work.
<fullermd> If I look at the --short log output for bzr.dev (which doesn't include non-mainline revisions), I see that the last commit was vila fixing some redirection bugs.  The one before that was him messing with log formatting.  Before that was Marius fixing some dotted revno stuff, then Solaris compilation fixes, cleaning debug code, adding another build target...  and on and on.
<fullermd> So in a way, I see the 'rollup' of what the conceptual bits that were done were.
<davidstrauss> fullermd: By "rollup," do you mean a revision that encompasses several others?
<fullermd> If I need to delve into the defailts of "what were the steps in changing that log format", I can walk down that line of history.  But in a high-level view, I don't care; I want to know the bigger conceptual "things that were done" to the project.
<davidstrauss> ok
<fullermd> Sort of.  In log [--long, or any formatter that shows merge revs] they look that way.
<fullermd> In a strict sense, the history is no different than in git or any other ancestry-based VCS; it's all a DAG, and no revision is 'a subpart of' any other really.
<davidstrauss> understood
<fullermd> But the output uses the mainline to create a visual fiction that it's like that.
<davidstrauss> fullermd: Will I see this behavior even if people push into the mainline?
<fullermd> If you work in a way that preserves the mainline, and treats each commit to it as an individual unit (merge this feature, write that feature, etc), the log just walking down the mainline gives you a very neat view of the history.
<fullermd> Pushing over the trunk can change the mainline, since the left-hand path is now different.
<fullermd> That could mean that, say, the last 10 commits that were on mainline, are now "off to the right" of the last merge, and the new last 8 or 15 commits on mainline were details of implementing that last feature landed.
<fullermd> If the heads of two branches are different, their mainlines will be different.  If they're related branches, the mainline will usually be the same up to a point, but you'd have to examine a particular case to see where that is.
<fullermd> For instance, my copy of bzr.dev and the "real" bzr.dev have different heads right now (I'm a revision behind; haven't sync'd since yesterday)
<fullermd> So our revnos are the same up to 3904, but it's got a 3905.  So, I have sorta an "earlier version" of it.
<davidstrauss> fullermd: So, next week I'll be setting up Bazaar and training all the Drupal core developers on using it for the sprint. I'd like to have a clean mainline that exhibits the nice history you've mentioned. It looks like my choices for appending to that history are (1) commits from checkouts and (2) merges into the mainline.
<davidstrauss> What workflow do you use for your working copy(ies) of bzr.dev?
<fullermd> (2) is what you'd need, yes.  (1) is IMO the simplest way of doing so.
<fullermd> Well, I don't really work on bzr; I have bzr.dev around because it's the bzr I use day to do.  In my work, we work with a shared trunk which all the devs checkout.
<davidstrauss> fullermd: Do you use local commits at work?
<fullermd> Trivial stuff is often just done directly on trunk, CVS style.  More involved stuff happens in separate branches (most commonly dev-local, with the sort of work we do, but occasionally shared)
<fullermd> I don't, no.  If I'm working on trunk, I'm connected.
<fullermd> And if I run 'commit' on trunk, it's because whatever I'm committing is ready to go out into the world.
<LarstiQ> davidstrauss: I either work directly on trunk if it's small, or in a different branch if it's bigger, and merge it into trunk when ready.
<davidstrauss> fullermd: Do you maintain a checkout and a branch, typically?
<fullermd> Yah.  Or several branches.
<davidstrauss> LarstiQ: How do you merge into trunk? Do you directly got onto trunk and run "bzr merge"?
<LarstiQ> davidstrauss: yup, with the branch I've been working in as an argument
<davidstrauss> LarstiQ: Or do you keep a checkout of trunk to merge into?
<LarstiQ> oh
<fullermd> Actually, because of details of the environment, I generally have one branch that gets pull'd over and re-used, instead of recreated from scratch, for a lot of things.  But I make specific branches sometimes too.
<LarstiQ> I didn't understand 'directly' correctly
<davidstrauss> For most projects I manage, logging into the Bazaar mainline server and running merge is a non-starter.
<LarstiQ> davidstrauss: I never work directly on the remote trunk that lives on the central server.
<LarstiQ> right
<LarstiQ> davidstrauss: so, I cd to my local branch of trunk, and run merge
<davidstrauss> It looks like "checkouts" are best treated as remote access points to do stuff directly on trunk.
<fullermd> Nor I.  The central 'trunk' doesn't even have a working tree.
 * LarstiQ nods at fullermd 
<fullermd> Yah.  There's pretty much two ways to do it.
<davidstrauss> fullermd: Same here. No working trees on trunk
<LarstiQ> davidstrauss: depending on the project, my local copy of trunk is a checkout or a branch
<fullermd> (1) have a 'branch' of trunk.  When you want to land something, pull to update, merge your stuff, then push.  Or, (2) have a checkout, update merge commit.
<fullermd> They're roughly the same thing, but (2) is usually simpler.
<davidstrauss> fullermd: Will (1) preserve a nice history on the mainline?
<LarstiQ> davidstrauss: when a branch, I need to push after committing. If someone else than has committed something to the remote trunk, I need to do more work to get caught up, a potentially neverending cycle with race conditions. That is what a checkout makes easier.
<fullermd> Yeah, they have the same end result.  But the checkout automates staying in sync, making sure you're up-to-date, etc.
<LarstiQ> davidstrauss: yes
<fullermd> push won't push if you're out of sync.  Strictly speaking, the remote head rev has to be in your history, or push will error.
<davidstrauss> Doesn't pull refuse to run if you've diverged?
 * LarstiQ would  go for (1) if there is little chance of the remote trunk changing under your feet AND the overhead of a checkout is bothering you.
<LarstiQ> davidstrauss: yes
<fullermd> Right.  But in this case, you'd intentionally never diverge the trunk branch.
<davidstrauss> So when you say "merge" into the branch of trunk, you mean from another branch that has the changes?
<fullermd> (so if that priming 'pull' failed, something went wonky somewhere)
<LarstiQ> davidstrauss: yes
<fullermd> Yah.  cd foo ; hack commit hack commit hack commit ; cd ../trunk ; bzr up ; bzr merge ../foo ; bzr ci
<davidstrauss> fullermd: that's with a checkout
<davidstrauss> right?
<fullermd> Aside from the workflow stuff, I find it convenient having an up to date copy of trunk around anyway, for reference.
<fullermd> Yah.  With an independant branch of turnk, those last 3 steps would turn into "bzr pull ; bzr merge ../foo ; bzr ci ; bzr push"
<LarstiQ> davidstrauss: for a branch it would be : cd foo; hack commit hack commit hack commit; cd ../trunk; bzr pull; bzr merge ../foo; bzr ci; bzr push
<fullermd> Checkout saves you a step, and makes things easier if trunk happens to move while you're doing it.
<LarstiQ> and beaten by fullermd, again :)
 * fullermd steals LarstiQ's typing speed.
<fullermd> Since with a branch, if that last pull fails because trunk moved, you have to undo all the work, pull again, re-do the merge, etc.  With a checkout, you can just 'update' and it will take care of merging your changes on top of the new head.
<fullermd> (which may conflict, to be sure, and you may find it easier to revert and re-do the merge than to fix them, but usually IME it doesn't)
<davidstrauss> yeah, i think i'll use the checkouts as the gateways to the mainline
 * LarstiQ nods
<fullermd> And remember too how I scorn the Distributed Creed, and work on trunk a lot too   ;)
<LarstiQ> davidstrauss: I think that is good practice indeed.
<fullermd> Probably the majority (by number, though not by time) of the changes I make are small enough that they belong in 1 commit anyway, so I just do those straight on trunk.
<davidstrauss> As a side note, this isn't terribly documented on the Bazaar site
<davidstrauss> Rather, I find the workflows document rather vague and poor
<fullermd> So for those, the workflow is exactly as if I were still using CVS; make the change, commit, done.
<davidstrauss> fullermd: And that's something I really like about Bazaar: the zero learning curve of just doing what you did with SVN
<fullermd> Yeah.  That workflow hung around for 20 years because for a lot of things, it works fine.
<davidstrauss> It makes it easy for me to force bzr on dev teams and then evolve use of the powerful distributed features
<davidstrauss> gradually
 * fullermd nods.
<davidstrauss> With the Drupal dev team, we're taking CVS users in many cases
<fullermd> You can move a whole team from SVN over to bzr, and not disturb anybody's workflow.  Heck, everybody else can keep just working on trunk forever, but you still get to use branches.
<davidstrauss> talking*
<davidstrauss> exactly :-)
<LarstiQ> there are some small glitches like svn copy, but in general, yes.
<davidstrauss> And svn add vs. bzr add
<davidstrauss> and the branch centricity of bzr versus current working directory and below for svn
<davidstrauss> I've actually used bzr quite a bit at this point. I'm in here to become more of an expert because I know I'll get grilled next week for all of this.
<davidstrauss> We're flying in people from around the world for this. I'm expected to know everything about the VCS I decided on.
<LarstiQ> aah
<LarstiQ> when does this all start?
<davidstrauss> Monday
<LarstiQ> ok
<davidstrauss> Worst case was going to be falling back on just checkouts
<davidstrauss> which would put us exactly where we would have been with SVN, anyway
<LarstiQ> which will then get you the question, "why switch if it is the same?"
<fullermd> I like to use profanity in answer to that   :)
<LarstiQ> davidstrauss: I'm going out for shopping now, but I'm interested in talking more about this if that's ok with you.
<davidstrauss> LarstiQ: I maintain a bzr branch that tracks CVS HEAD. Even if we branch from that and then do everything checkout-style, we still save time.
<davidstrauss> LarstiQ: Because then I don't have to set up Subversion with a vendor branch and a clone of my HEAD-trackign scheme.
<davidstrauss> LarstiQ: bye
<davidstrauss> Also, bzr is generally easier to use than svn. I hate svn's property-based ignore scheme.
<davidstrauss> And my inability to use it is why you'll find an old checkin of mine for MediaWiki that includes a password file (albeit, a development one that would be useless outside the firewall).
<davidstrauss> How is this possible when using shared branch storage? "In commercial environments, different teams might have their access controlled to various branches (e.g. development vs QA vs maintenance) on a server but, once again, these branches can be using a shared repository for efficient storage. It's also clearly beneficial for hosting sites like Launchpad."
<davidstrauss> Wouldn't all of the teams need access to the shared storage location?
<Peng_> davidstrauss: Yeah, you're right. I guess you could create repos per-team, and the recent stacking feature will really help.
<davidstrauss> Peng_: I pulled the quote from the BzrVsGit page. It seems like shared storage makes it distinctly less possible to separate out permissions.
 * Peng_ doesn't read the Vs pages.
<Peng_> davidstrauss: Yeah, it does.
<fullermd> It's easy.  First, we eliminate the VFS layer from the SS...
<Peng_> davidstrauss: Like I said, stacking really helps there.
<davidstrauss> fullermd: I can't tell if you're being sarcastic
<Peng_> fullermd is right too. It would be possible to make the smart server support permissions, though not easy.
<Peng_> davidstrauss: Taking out the VFS would be a ton of work, but is desired for the future anyway, since it's often bad for performance.
<davidstrauss> ok
<davidstrauss> Also, it seems like full branch > history horizon branch (not existent yet) > stacked branch in terms of space requirements and local capabilities.
<davidstrauss> But I've never seen them described as such
<fullermd> Oh, not sarcastic per se.  Sardonic maybe.
<rocky> jelmer: another svn branch checkout failing... with bzr 1.10 and bzr-svn  0.5 branch
<rocky> :(
<rocky> jelmer: http://cluebin.appspot.com/pasted/3611
<rocky> jelmer: and http://cluebin.appspot.com/pasted/4002 for the bzr.log output
<mkanat> Let's say I had a repo where the clock was wrong for a really long time, and now I have thousands of commits whose time is off by X hours exactly--can I fix that?
<mkanat> s/repo/branch/
<davidstrauss> mkanat: The general response I hear is that revision history data is immutable.
<mkanat> davidstrauss: That's what I've heard as well, I was just wondering if there was any way to safely muck about with it.
<mkanat> Anyhow, I'm off to sleep, I'll ask again some time later.
<davidstrauss> mkanat: I'm guessing the answer is no *safe* way
<davidstrauss> mkanat: goodnight
<mkanat> davidstrauss: I'd guess that too. :-)
<mkanat> Night1
<mkanat> *Night!
<Peng_> The time is used in the revision IDs themselves too, not that it really matters.
<lifeless> 0
<davidstrauss> lifeless: ?
<lifeless> mistype
<GaryvdM> Hi - What do I do if I get this error: http://pastebin.com/mf46f9ef
<GaryvdM> BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x01548CD0> has delta references to items not in its repository:
<davidstrauss> GaryvdM: You have a corrupted repository.
<GaryvdM> Where I am pushing from or where I am pushing to?
<davidstrauss> GaryvdM: what do you get from "bzr check"
<GaryvdM> Ok - I'm runing check on my local branch
<davidstrauss> GaryvdM: though it's likely the issue is with the external repository
<GaryvdM> http://pastebin.com/m7264518f
<GaryvdM> Seams ok
<davidstrauss> GaryvdM: What client version are you using?
<GaryvdM> Bazaar (bzr) 1.11dev
<GaryvdM>   from bzr checkout C:/Documents and Settings/Gary/My Documents/bzr/bzr.dev
<GaryvdM>     revision: 3904
<GaryvdM>     revid: pqm@pqm.ubuntu.com-20081213000403-r1acnqhux25xhil1
<GaryvdM>     branch nick: bzr.dev
<davidstrauss> GaryvdM: stacked branch?
<GaryvdM> Yes
<davidstrauss> GaryvdM: https://bugs.edge.launchpad.net/bzr/+bug/302698
<ubottu> Launchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2e23f90> has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed]
<GaryvdM> Ok - thanks. I'm going to try an older version of bzr.
<davidstrauss> GaryvdM: Also similar: https://bugs.launchpad.net/bzr/+bug/307146
<ubottu> Launchpad bug 307146 in bzr "Can't push svn clone to bzr" [Undecided,New]
<davidstrauss> GaryvdM: you can also check the Launchpad branch remotely, I believe
<GaryvdM> davidstrauss: I revert to bzr 1.10 - The problem still existed. I reverted to bzr 1.9 and I was able to push successfully. Later tonight I'll try work out at which revision this regression occurred.
<mdmkolbe> Help my repository has gone haywire.  I did some edits then a "bzr ci --local" (when off the network) and some more edits afterwords.  Now back on the network, I try to do a "bzr ci" and it says it can't do that until I do a "bzr update".  Now it has thrown up all sorts of text conflicts and a pending merge (what ever that means).  I am the only person editing the source so I don't understand how conflicts could have appeared.  How do I get back to a
<LarstiQ> mdmkolbe: cut off at 'How do I get back to a'
<LarstiQ> mdmkolbe: https://bugs.edge.launchpad.net/bzr/+bug/113809
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed]
<mdmkolbe> How do I get back to a sane state?  (I have uncommited changes that I *don't* want to loose)
<davidstrauss> LarstiQ: beat me to it
<davidstrauss> mdmkolbe: The changes you generally want to keep will be in the .moved files
<davidstrauss> mdmkolbe: checkout + local commit + uncommitted changes + update is currently a recipe for disaster
<davidstrauss> mdmkolbe: The *.THIS.moved files likely have your uncommitted changes in them
<davidstrauss> mdmkolbe: Is that the case?
 * mdmkolbe looks
<davidstrauss> mdmkolbe: And the "pending merge" represents a local commit you did
<mdmkolbe> davidstrauss: yes the THIS.moved files look right
<davidstrauss> mdmkolbe: You'll want to copy the contents of the THIS.moved files into the conflicted files
<davidstrauss> mdmkolbe: And then you can delete all the THIS, OTHER, BASE, and .moved files
<davidstrauss> mdmkolbe: run bzr resolved
<davidstrauss> mdmkolbe: and you should have a clean copy
<mdmkolbe> davidstrauss: it looks like I have a conflicted directory and some sort of path conflict(?)
<davidstrauss> mdmkolbe: the path conflicts are side-effects of the same thing
<davidstrauss> mdmkolbe: bzr treats directories as versioned objects
<davidstrauss> mdmkolbe: back up the conflict files, just in case they have anything useful in them
<mdmkolbe> it is still listing "conflict adding file foo.BASE"
<davidstrauss> mdmkolbe: in bzr status?
<mdmkolbe> yes
<davidstrauss> mdmkolbe: have you run "bzr resolve"
<mdmkolbe> (also OTHER and THIS)
<mdmkolbe> yes, it says "remainling conflicts:" then lists *base, other, this"
<davidstrauss> mdmkolbe: and moved the conflict files where bzr can't see them?
<mdmkolbe> I now have but on the first resolve I didn't
<davidstrauss> mdmkolbe: you need to run resolve after removing the conflict files
<davidstrauss> mdmkolbe: and you may need to "bzr resolve [file-it's-complaining-about]" explicitly
<mdmkolbe> ah, that last part did it
<davidstrauss> mdmkolbe: The only safe way to update is if you don't have a combination of uncommitted changes and local commits.
<davidstrauss> mdmkolbe: I personally avoid local commits because of the problem you just encountered.
<mdmkolbe> davidstrauss: what if I have multiple local commits.  (i.e. instead of "ci --local" and "ci" do "ci --local" and "ci --local" "update)
<davidstrauss> mdmkolbe: i believe multiple local commits is fine
<davidstrauss> let me check
<LarstiQ> if you have local commits, but no uncommitted changes, that should work afaik
<mdmkolbe> davidstrauss: ok, so I've cleared all the conflicts, but bzr st still lists a "pending merge".  Do I need to clear that?
<LarstiQ> what could happen is that you have file.moved.moved.moved
<davidstrauss> mdmkolbe: Just checked, and multiple local commits is OK.
<LarstiQ> with multiple levels of conflict
<davidstrauss> mdmkolbe: the pending merge is just your local commit
<LarstiQ> in that case, you might need to bzr resolve file.moved.moved, not just 'file' itself
 * LarstiQ hopes 113809 gets fixed soon
<mdmkolbe> davidstrauss: so ... do I do another local commit now and finish with an update?
<davidstrauss> mdmkolbe: do you have uncommitted changes?
<mdmkolbe> davidstrauss: yes
<davidstrauss> mdmkolbe: then, yes, do a local commit and update
<davidstrauss> mdmkolbe: and then you may commit
<davidstrauss> (centrally)
<mdmkolbe> davidstrauss: ok, I did "ci --local" and then "update".  It complains about "conflict: can't delete <directoryname> because not empty"
<davidstrauss> mdmkolbe: what directory?
<mdmkolbe> src/unicode/ucd/properties
<LarstiQ> that might be a valid conflict between your local revisions and the upstream?
<mdmkolbe> LarstiQ: I am the only committer so I don't think so
<davidstrauss> mdmkolbe: do you have local changes in that directory?
<mdmkolbe> davidstrauss: yes
<davidstrauss> mdmkolbe: i'd back up that directory, revert it, update, and re-integrate your changes
<davidstrauss> sorry, back
<LarstiQ> didn't miss anything
<mdmkolbe> davidstrauss: I *think* it is now all back to normal.  Is there a graphical tool for viewing revision history trees? (I'm currious what happened as a result.)
<davidstrauss> mdmkolbe: It's not going to be visible in the tree. It happened due to a double merge. The craziness never got committed.
<LarstiQ> mdmkolbe: qlog from qbzr and viz from bzr-gtk are nice tools, but I'm not sure that is what you are asking for
<mdmkolbe> davidstrauss: but I see 16 then 16.1, 16.2,16.3 and finally 17 in the bzr log
<davidstrauss> mdmkolbe: there will be at least your local commits
<davidstrauss> mdmkolbe: i mean, you won't see the problem in the tree
<LarstiQ> 16.1, 16.2 and 16.3 should be your local commits
<mdmkolbe> ah, I think I see what you mean
<mdmkolbe> Thank you *very* much for your help.
<davidstrauss> :-)
<mdmkolbe> (Though it baffles me that such a bug could exist (I would have thought a proper design would prevent it) and actually makes me wonder whether I can continue to trust bzr with my data.)
<Peng_> What bug? Local commits getting mangled?
<mdmkolbe> Peng_: yes
<Peng_> Well, I trust bzr with my data, but I don't use checkouts.
<davidstrauss> mdmkolbe: Just don't use local commits. I haven't encountered a similar problem elsewhere in Bazaar.
<davidstrauss> mdmkolbe: There's a lot of debate about the future of local commits in Bazaar, anyway.
<mdmkolbe> what if I am away from a network?
<mdmkolbe> (that was the reason I used local commits in the first place)
<davidstrauss> mdmkolbe: The best thing to do is checkout to your laptop and then branch from that.
<davidstrauss> mdmkolbe: It's lightweight it you use shared branch storage.
<davidstrauss> mdmkolbe: The workflow is then local branch --- merge ---> local checkout --- commit ---> central branch
<davidstrauss> mdmkolbe: The local checkout is merely a gateway to the central branch
<davidstrauss> mdmkolbe: Or you can always merge into the central branch
<davidstrauss> mdmkolbe: Or push and pull
<davidstrauss> mdmkolbe: Or just resolve to not mix local commits with uncommitted changes when you update.
<davidstrauss> That last one is the easiest, but it's also the most likely to have you running into the problem again.
<mdmkolbe> ok, well I guess I'll be remembering that for next time
<davidstrauss> mdmkolbe: I'm currently pushing for updates to be denied if you have both local commits and uncommitted changes
<davidstrauss> mdmkolbe: http://www.nabble.com/Re%3A-Recommended-use-of-Bazaar-for-single-committer-multiple-machine-projects--p20989853.html
<mdmkolbe> davidstrauss: I think that should be done at a bare minimum.  What I would have expected what that a check out just means that "ci" is really "ci --local;push" or some such (maybe with a rolback of the "ci --local" if the "push" fails). then this problem shouldn't even be able to happen
<davidstrauss> mdmkolbe: ci --local;push does something quite different
<davidstrauss> mdmkolbe: There's actually no obvious solution for merging into a checkout with both local commits and uncommitted changes.
<mdmkolbe> davidstrauss: hmm, this may explain why both darcs and git require local changes to be explicitly staged before being pushed up stream.  I guess I assumed bzr was doing the same just providing a single command.
<davidstrauss> mdmkolbe: yes
<davidstrauss> Where is the code for the update command in the Bazaar source?
<GaryvdM> bzrlib\bulitins.py line 1121
<davidstrauss> Thanks
<davidstrauss> GaryvdM: How easy would it be to change it to detect either uncommitted changes or local commits?
<Peng_> Probably not very difficult.
<davidstrauss> That's what I thought
<davidstrauss> If we can at least get that into trunk, we can avoid the horrors mdmkolbe just experienced.
<mdmkolbe> I should note that this sort of check to stop bad behaviour has precident.  IIRC there are some situations where SVN will refuse to do an operation.  It gives an infomative message about why it wont do it and what you should do in order to make it happy.  It also tells you that if you really do want to do it any way you can pass a "--force" option.
<mdmkolbe> As a user seeing that message is mildly anoying (sometimes I think "if svn is telling me what I need to do to make it happy, then why doesn't it go ahead and do it itselft").  but when using it I also realize that having your VCS be too conservative is better than having it be too loose
<davidstrauss> My Python is rather rusty, but I should be able to just pull some code over from the status command into the update one to do the necessary check.
<davidstrauss> How can you detect the presence of local commits?
<LarstiQ> davidstrauss: presumably this is at the point where you are running update, right?
<davidstrauss> LarstiQ: yes
<LarstiQ> In which case you should know the tip of the master branch, and your own tip.
<davidstrauss> Yes, I see that
<LarstiQ> if there is divergence, there are local commits.
<LarstiQ> There might be nice api for this, that I do not know.
<davidstrauss> I assume "master is None" means it's not a checkout?
<LarstiQ> davidstrauss: I haven't looked at that code, but I'd guess that's correct.
<LarstiQ> AmanicA: ooh, _you're_ Marius Kruger!
<davidstrauss> Is there a command to have Bazaar list local commits?
<GaryvdM> qlog
<GaryvdM> I don't know about the command line
<davidstrauss> qlog?
<Odd_Bloke> davidstrauss: "bzr missing --mine"
<davidstrauss> Odd_Bloke: nope
<davidstrauss> Odd_Bloke: maybe "bzr missing --mine :bound"
<Odd_Bloke> davidstrauss: What do you mean by 'local commits'?
<davidstrauss> Odd_Bloke: to a checkout
<Odd_Bloke> davidstrauss: Have you tried "bzr missing --mine :bound"?
<LarstiQ> didn't he just say that? :)
<LarstiQ> Odd_Bloke: davidstrauss is working on bug 113809
<LarstiQ> Odd_Bloke: heya, btw :)
<ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809
<Odd_Bloke> LarstiQ: No, he didn't. :)
<davidstrauss> I'm at the point where I need to test for the (1) uncommitted changes and (2) local commits
<Odd_Bloke> LarstiQ: Hi. :D
<bialix> AmanicA: ping
<davidstrauss> Local commit testing: check
<davidstrauss> Now to look for uncommitted changes
<aantn> hello
<aantn> what's the best way to remove the last commit from a remote branch
<aantn> (If I use bzr uncommit, it'll only remove it from the local branch's history)
<aantn> someone accidentally committed personal information and I'd like to remove all traces of the commit
<davidstrauss> aantn: uncommit won't do that
<bialix> push --overwrite
<aantn> bialix: thanks
<bialix> np
<davidstrauss> I said "won't do that" because uncommit doesn't destroy the data
<aantn> davidstrauss: is there a way to do that, then?
<davidstrauss> aantn: not to my knowledge
<bialix> removing the branch completely and push it again
<bialix> there is no simple way for nuking uncommitted revisions
<davidstrauss> bialix: aantn would still have the ghost revision in the pushed data
<bialix> no
<bialix> it's not ghost revision
<davidstrauss> even when you uncommit?
<bialix> there is (was) plugin named remove-revisions to do this job
<bialix> when you uncommit your revision still in the repository
<bialix> when you do push, uncommitted revisions will not propagate
<bialix> or pull or branch, does not matter
<aantn> bialix: would uncommitting be sufficient then?
<bialix> this is main reason why branching in bzr much slower operation than clone in hg or git
<davidstrauss> I see
<bialix> aantn: it depends if you have shell access to your server
<aantn> bialix: it's a launchpad branch
<bialix> oh
<aantn> I've already notified the person and they should have changed the password by now anyway
<LarstiQ> aantn: uncommit and push --overwerite are sufficient for no one being able to get the information by branching
<bialix> do local uncommit and then push --overwrite to lp
<aantn> bialix, LarstiQ: thanks; already done
<LarstiQ> aantn: and ask one of the lp admins to clean the repository
<aantn> LarstiQ: ok; is there anyone in here who can help?
<LarstiQ> aantn: https://answers.launchpad.net/launchpad/+addquestion
<bialix> AmanicA: if you'll read this later tonight: I'm going offline, check your mail
<bpierre> hi
<bpierre> do you use the launchpad interface for merge requests?
<davidstrauss> Done with my patch :-)
<davidstrauss> What do you guys think? http://pastebin.com/m5586168e
<davidstrauss> How do you use bzr send to create a merge directive but not send an email?
<LarstiQ> davidstrauss: bzr send -o <file>
<bpierre> davidstrauss: use -o file
<davidstrauss> not sure how i missed that in bzr help send
<davidstrauss> More importantly, what do you think of the patch?
<LarstiQ> davidstrauss: you should probably use `dir` instead of u"."
<davidstrauss> LarstiQ: Like this? "local_branch = Branch.open_containing(dir)[0]"
<LarstiQ> davidstrauss: yup, assuming dir is still the same as at the top of the cmd_update run
<LarstiQ> davidstrauss: other than that, looks good.
<LarstiQ> davidstrauss: you might want to include a NEWS entry too
<davidstrauss> Is there a special Launchpad way for me to submit merge directives?
<davidstrauss> LarstiQ: And it has a NEWS entry, too.
<LarstiQ> that I do not know. But the Bazaar project primarily uses bundle buggy wathcing the mailing list for patch proposals, not launchpad.
<davidstrauss> then I'll email to that
<bpierre> ah, answered my question
<LarstiQ> davidstrauss: after which you can track it at http://bundlebuggy.aaronbentley.com/
<cammoblammo> I'm running bzr 1.5 on Debian. I mainly use it for syncing a heap of text files between a few machines, although I also follow a couple of software projects with it as well. Is there anything to be gained by compiling and installing 1.10?
<davidstrauss> LarstiQ: And emailed.
<davidstrauss> I do email to bundlebuggy@aaronbentley.com right?
<LarstiQ> eh, no :)
<LarstiQ> davidstrauss: sorry, I should have made that more clear.
<LarstiQ> davidstrauss: bundlebuggy monitors the regular bazaar mailing list
<davidstrauss> So I email to bazaar@lists.canonical.com?
<LarstiQ> davidstrauss: use a subject of [MERGE/RFC] warn the user when updating with both local commits and uncommited changes, or something like that
<LarstiQ> davidstrauss: yes
<LarstiQ> davidstrauss: more guidelines are listed in doc/developers/HACKING.txt, specifically 'Sending patches for review' in this case
<davidstrauss> LarstiQ: thanks
<LarstiQ> davidstrauss: it's in bundle buggy now too
#bzr 2008-12-14
<AmanicA> does anybody know if there is a way to determine weather a revid is between 2 other revid's in the revision history?
<jelmer> AmanicA, there's no standard version
<jelmer> s/verison/function/
<jelmer> but you can of course iterate over the ancestors of revision 1 and look for your revision until you hit revision 2
<AmanicA> is there a way though?
<AmanicA> do you know of an example I can find somewhere
<AmanicA> (eg. which command does something like this)
<jelmer> not aware of anything of the top of my head, sorry
<AmanicA> thx
<jelmer> iterating over ancestors should be pretty easy with a Graph object though
<AmanicA> jelmer: thanks a lot, I got it working! :)
<lifeless> AmanicA: graph.heads() perhaps too
<AmanicA> lifeless: thanks, I ended up using graph.is_ancestor which claims it uses graph.heads()
<AmanicA> (its used for `bzr tags -r 1..2` which I submitted two seconds ago :)
<cammoblammo> I'm running bzr 1.5 on Debian. I mainly use it for syncing a heap of text files between a few machines, although I also follow a couple of software projects with it as well. Is there anything to be gained by compiling and installing 1.10?
<lifeless> cammoblammo: speed
<cammoblammo> lifeless: Speed's not a huge factor, although it's always nice. I have had problems pulling from a project's server lately though---is that a possible cause?
<lifeless> cammoblammo: anything is a possible cause. details needed to analyse
<cammoblammo> lifeless: I knew you'd say that ;-) I'll try to replicate it when I get a chance. It's not a problem.
<Enisseo> hi everyone!
<Enisseo> Last time I came here, I've been suggested to use the bzr upload plugin, and it works perfectly
<Enisseo> except one thing
<Enisseo> the ftp upload makes all the uploaded files having a specific "chmod"
<Enisseo> which prevent the server to execute them
<Enisseo> so I need to use SSH to change the "chmod" of these files
<Enisseo> Can the plugin (or bazaar) do this itself?
<Enisseo> (info: I upload from Windows to an Unix ftp server)
<LarstiQ> Enisseo: possibly, but I'm guessing this is going to be very ftp server dependant.
<Enisseo> LarstiQ: you mean that this is a global option for all bzr branches?
<LarstiQ> Enisseo: no, I mean that it may not always be possible to chmod files on an ftp server, since there are a lot of broken ftp servers out there.
<LarstiQ> Enisseo: can you ftp manually to your server, and chmod them that way, instead of sshing in?
<LarstiQ> Enisseo: if not, then there isn't much that can be done unfortunately.
<Enisseo> LarstiQ: well, what I want is to use the bzr upload plugin, which is great but does not apply the expected rights to the file it uploads
 * LarstiQ nods at Enisseo 
<LarstiQ> Enisseo: so could you tell me if it is possible to chmod using ftp?
<LarstiQ> Enisseo: another option for you personally, would be to use sftp instead of ftp
<duckx> Hy
<duckx> I was wondering if there is any way to unsplit a tree ?
<LarstiQ> duckx: if you did `bzr split` before, `bzr join`
<duckx> Ok thx ;)
<duckx> I have a try now
<duckx> -> bzr: ERROR: Cannot join apache2/.  Trees have the same root
<duckx> In my case bzr is used to store revision for the /etc of my servers
<duckx> I initialised /etc (bzr init) & /etc/apache2 (Both contains a .bzr subdirectory)
<duckx> -> I converted the /etc directory to the --dirstate-with-subtree format ...
<jelmer> duckx: there should't be a need to use a -subtree format, -rich-root (e.g. 1.9-rich-root) should be sufficient
<duckx> bzr version is 1.5
<duckx> ok
<jelmer> in that case, --rich-root-pack probably
<duckx> ok
<duckx> Let me retry
<duckx> Well quite logicaly I hit this :
<duckx> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack4>.  Does not support nested trees
<duckx> In both trees (/etc & /etc/apache2) Tree root is .
<duckx> Which could explain the thing (bug) I hit, as the path are not expanded
 * LarstiQ only knows how to change the treeroots via bzrlib
<duckx> ;)
<LarstiQ> duckx: I suppose you have multiple servers?
<duckx> Indeed ;)
<duckx> Changes on the servers are then send to mailing list through the mail plugin
<jensen> Hi. Do I need to open up for any special port numbers, in order to access a remote bazaar repository, using the bzr+ssh protocol? (other than port 22)
<duckx> Nop
<duckx> I am on the server
<LarstiQ> jensen: no, it's just ssh
<jensen> LarstiQ: hum,
<duckx> It is local commit
<jelmer> duckx: you can't go back after you've upgraded to -subtree, unfortunately
<duckx> That is quite logical
<LarstiQ> duckx: how willing are you to experiment?
<jelmer> duckx: What are you trying to do exactly though? A one-time join? Since it'll be problematic keeping "apache2" up-to-date afterwards
<duckx> Well, that a kind of test server
<duckx> History of revision are not so important
<jensen> LarstiQ: I've made a ssh tunnel to the remote machine (which is not directly accesible from my current location), I am able to successfully connect to it with a standard ssh client, but for some reason, bzr fails, with an "ERROR: Connection close: ..."-message.
<jelmer> duckx: you'd want "bzr join --reference" for that, which is still experimental
<duckx> ok lets test
<LarstiQ> jensen: the two tree roots are still the same then?
<jensen> yeah, it should be.
<duckx> Indeed bzr: ERROR: Cannot join apache2/.  Trees have the same root id.
<LarstiQ> ehm
<LarstiQ> s/jensen/jelmer/
<LarstiQ> duckx: is it an option to `bzr init` and use a rich-root format from the start, so that it will set the tree root to something unique?
<LarstiQ> duckx: if not, you could 'from bzrlib.workingtree import WorkingTree; WorkingTree.open(".").set_root_id("something-unique")'
<jensen> LarstiQ: hehe,
<LarstiQ> jensen: which client are you using to set up the tunnel?
<jensen> i'm using putty.
<duckx> Hmm, I thing I will get ride of the revision on my apache2 conf, and add them to the /etc root tree
<jensen> LarstiQ: is that a problem?
<LarstiQ> jensen: I've seen some problems in this area before, having to do with aliases of tunnels
<jensen> aliases?
<LarstiQ> duckx: or that :)
<LarstiQ> jensen: doesn't ring a bell? good :)
<jensen> Hum, I can see, that i get far enough, to get the servers key fingerprint...
<jensen> LarstiQ: hehe
<LarstiQ> jensen: did you check ~/.bzr.log for more information on the connection close?
<LarstiQ> jensen: can it find bzr on the server?
<jensen> LarstiQ: No, just a sec.
<jensen> LarstiQ: I believe so, the exact same command works perfectly, when i remote desktop to a desktop on the internal network.
<jensen> LarstiQ: hm, is the ~/.bzr.log located some place else on windows?
<jensen> +file
<LarstiQ> yes :)
<jensen> :)
<LarstiQ> iirc it says where if you run `bzr --version`?
<jensen> 1.9
<jensen> oh, sorry
<jensen> misread that. :)
<jensen> yes, it does, thanks.
<jensen> hm, nothing but a Traceback, orginating in bzrlib/smart/message.pyo, L247, does'nt really ring a bell for me.
<LarstiQ> could you pastebin me the traceback?
<jensen> Of course, just a sec.
<jensen> LarstiQ: http://pastebin.com/m257da06d
<jensen> s/<username>/username/, s/<bzr-path>/full-path/ ...
<LarstiQ> oh feh
<LarstiQ> and not a bzrlib install with source
<jensen> Those should be correct, again, same command works internally on the network.
<jensen> LarstiQ: should I get that?
<LarstiQ> jensen: hmm, first try if bzr gets to log something on the server
<jensen> hm, doesn't seem like it..
<duckx> Me again ...
<duckx> I removed my .bzr in the subtree ...
<duckx> Works fine now ;)
<jensen> LarstiQ: No activity when I make a new attempt.
<LarstiQ> jensen: I'm having my doubts it is finding a bzr to execute at the remote end
<jensen> LarstiQ: it is possible, but it seems strange, that everything works fine from the other desktop.
<LarstiQ> jensen: does that desktop have the same ssh tunnel?
<jensen> No, it is on the same internal network, so it can connect directly to the server.
<duckx> bzrlib.errors.InvalidURL: Invalid url supplied to transport: "file://hestia/etc/": local urls must start with file:///
<duckx> hmmm, this is not rfc compliant dudes ;)
<duckx> In my case it would be really nice if the host could appear in the base info of a branch
<LarstiQ> duckx: interesting
<LarstiQ> duckx: what would that do if the host is not the local host as well?
<duckx> LarstiQ: I have got no idea ...
<duckx> May be the best test would be to use urllib2 & have a try
<LarstiQ> duckx: sounds fair
<duckx> http://pastebin.com/d65b05eb1
<duckx> Here is the trace I have for an unknown host lookup
<duckx> Works fine with the right hosts
<LarstiQ> duckx: will you submit a patch?
<duckx> Hmm, first I would like to determine the best to implement it
<duckx> Because putting it by default would break one workflow
<duckx> scp your tree to another host
<LarstiQ> it is only used in bzrlib.urlutils.local_path_from_url
<LarstiQ> (the posix and win32 variants)
<LarstiQ> duckx: right
<duckx> bzr will break if the host could not be lookup
<duckx> I am more thinking to a switch to init ....
<duckx> Like add hostname
<duckx> sorry --add-hostname or something
<LarstiQ> maybe we should take a step back
<LarstiQ> what is it you want to accomplish?
<duckx> Well, when I commit my modification on my server (Still on the /etc tree) the branch.base is append to the mail subject
<LarstiQ> right
<duckx> that is on my case file:///etc
<duckx> Each time I commit on a server I should specify on what server I was working on
<duckx> eg: Subject: MY_HOST I did some stuff on it
<duckx> So I tried to find out a way to add the server automaticaly
<duckx> That has a sense only if you work locally
<LarstiQ> maybe it is a better idea to add an option to the emailing hook?
<duckx> Yeah, but options are parsed from the bazaar.conf configfile
<duckx> Where you only have static information
<LarstiQ> 'include hostname in email subjects'
<duckx> lol ;) That is what I was trying to say ;)
<duckx> So best way is to patch email plugin right
<LarstiQ> I think so
<duckx> K
<fullermd> At one time, I think lifeless discussed adding templating capability to the email thingy...   I don't know how far that ever got.
<fullermd> But if it were completeish, adding a %h escape or something wouldn't be much work I'd think.
<LarstiQ> that would the more general step
<duckx> Well, I am ready to hack a bit on email module ...
<duckx> But I prefer to follow your instructions/point of view ;)
<LarstiQ> duckx: if you have enough time, see if there has been work done on templating, if not, ask lifeless about his plans. And then implement them :)
<duckx> Short term could be a commit_include_host option in the config file  ?
<LarstiQ> something like that, yes
<duckx> ok
<LarstiQ> I'd say subject_include_host
<duckx> Ok I am on it ;)
<LarstiQ> duckx: you'll be at fosdem I assume?
<duckx> lol, I don't even know where it takes place ;)
<LarstiQ> Brussels!
<duckx> Well, it is not far away ...
<duckx> May be it will be a good time to find a job @ canonical ... ;)
<duckx> -> my current job breaks my xxx
<duckx> I am currently working @ a banck doing some wired Unix Admin tasks ...
<fullermd> Better than wireless admin tasks  ;>
<duckx> Ok patch ready ;)
<duckx> LarstiQ: What the best way to submit it ?
<LarstiQ> duckx: the email plugin README doesn't mention anything?
<duckx> Let me check
<duckx> This should be send to the mailing list ;)
<LarstiQ> pl
<LarstiQ> ok
<LarstiQ> make sure to include in the subject that it is for the email plugin
<duckx> ok
<LarstiQ> duckx: bzr/doc/developers/HACKING.txt on the code review process might be helpful too
<duckx> Ok let me have a look at it
<duckx> Time to go see my parents
<duckx> Thx for your help dudes !
<duckx> See you
<LarstiQ> duckx: have fun!
<dilema> hi
<dilema> i have a problem to get a connection via ftp to my webspace
<dilema> i have no chance to init my webspace as a branch
<dilema> any idea
<thumper> dilema: so how do you get access?
<dilema> per ftp
<thumper> dilema: can't you just go bzr init ftp://whatever?
<dilema> matthias@matthias-laptop:/var/www/mydomain.de$ bzr init ftp://mydomain.de@mydomain.de/home/www/mydomain.de/htdocs/test/test
<dilema> thumper, he required a pw
<dilema> thumper, he gets it
<dilema> thumper, then nothing happen
<thumper> dilema: when you say nothing happens, does it hang?
<dilema> thumper, i mean no feedback
<thumper> dilema: I'm not sure if you normally get feedback...
<dilema> thumper, ok
<thumper> what if you then go `bzr info ftp://mydomain.de@mydomain.de/home/www/mydomain.de/htdocs/test/test`
<dilema> thumper, wait ..
<dilema> thumper, ok it looks nice, or? -> branch root: ftp://mydomain.de@mydomain.de/home/www/mydomain.de/htdocs/test/test/
<dilema> thumper, and sthing like Standalone branch (format: pack-0.92)
<garyvdm> Hi. What work around are there for bug 302698?
<ubottu> Launchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2e23f90> has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed] https://launchpad.net/bugs/302698
<thumper> dilema: yes you have a branch there
<dilema> thumper, so i can work with
<thumper> garyvdm: not sure, but when you find it, I'd like to know
<thumper> dilema: yes
<dilema> thumper, thx ;)
<thumper> garyvdm: I'd ask jam when he arrives, or poolie
<garyvdm> thumper: I actualy know 2, but they are both pain full. 1. Delete branch and start again. 2. Install old version of bzr (1.9).
<garyvdm> I'm trying to find a deb for 1.9 intrepid. I'm only able to find 1.10.
<spiv> garyvdm: installing 1.9 isn't a good workaround; 1.9 has the same problem, but doesn't notice it.  i.e. it appears to succeed, but makes a repo with missing data that will cause problems later on.
<spiv> garyvdm: although the traceback in that bug involves autopack, which suggests the repo already had this problem in it.
<spiv> garyvdm: if there's a more recent traceback, could you pastebin it/
<spiv> ?
<garyvdm> Hi spiv.
<spiv> garyvdm: hi
<garyvdm> Which repo would have the problem? The repo that I'm pushing from, or the repo that I'm pushing to, or the repo that I'm skated on?
<garyvdm> *stacked
<spiv> The one you are pushing to.
<garyvdm> I can reproduce the bug as follows:
<garyvdm> Delete the branch that I'm pushing to (lp:~qbzr-dev/qbzr/threadless-throbber/)
<garyvdm> push -r -1 (gets stacked on lp:qbzr)
<garyvdm> push - get error
<spiv> Can you pastebin the traceback for that error?
<garyvdm> ok
<spiv> The one in the bug involves autopacking, but a fresh push shouldn't.
<garyvdm> http://pastebin.com/m2284da73
<spiv> garyvdm: and that's with 1.10?
<spiv> (final?)
<garyvdm> Yes - deb from ppa
<spiv> Huh, interesting, it hasn't taken the code path that it's supposed to if the target repo is stacked on another.
<spiv> i.e. it's taken the code path for unstacked repos.
<garyvdm> Sorry - that went over my head.
<spiv> That's ok :)
<spiv> Basically, it looks like that part of the code thinks the target is not stacked.
<garyvdm> ok
<spiv> Hmm, lp:qbzr is in pack-0.92 format, which means that's probably correct.
<spiv> What does info -v report in your local branch?  (pastebin again)
<garyvdm> Ah - I've recently changed the format on my local. When that stack happend - the repo was using 1.9
<spiv> Ok, that's interesting.
<garyvdm> http://pastebin.com/d2d1ed0f6
<spiv> Can you tar up the local repo and put it somewhere?  (maybe chinstrap?)
<garyvdm> ok
<spiv> (I'm thinking that perhaps I was wrong, that this might actually be an issue in your local repo after all)
<garyvdm> Sorry - whats the url for chinstrap
<spiv> garyvdm: ah, nevermind, just mail it to me at andrew.bennetts@canonical.com
<garyvdm> ok
<garyvdm> Ok - I've sent it. I'm in South Africa - so it will get to you in Telkom time.
<garyvdm> 3.4mb
<spiv> Ok.  Thanks!
<spiv> garyvdm: got it
<garyvdm> I'm busy trying the following: I've done an upgrade --1.6 on both repo and branch, and now trying to see if I can reproduce.
<garyvdm> Thats local branch and repo.
<garyvdm> Ok - That worked
<spiv> garyvdm: interesting.  I haven't been able to reproduce so far.
<garyvdm> I upgraded to --1.9 and then pushed a new rev and it also worked. I'm confused now.
<garyvdm> Ok - let me try one more thing - going afk
<garyvdm> spiv: Revised steps to reproduce:
<garyvdm> 1 - delete remote branch
<garyvdm> 2 - *use bzr 1.11dev rev 3409*
<garyvdm> 3. push -r -1
<garyvdm> 4. push - get erro
<garyvdm> step 4 can be with 1.11 dev or 1.10
<garyvdm> but step 3 must be with 1.11dev
<spiv> garyvdm: I'll try that
<garyvdm> *rev 3904
<spiv> garyvdm: I have r3904, but I can't seem to reproduce :(
<garyvdm> Ok - I did step 3 on my windows box (cause I'm running 1.11dev on it)
<garyvdm> I don't know what's different there.
<garyvdm> I'm going busy branching bzr.dev to my ubuntu box to see if I can reproduce it.
<spiv> garyvdm: hmm.  so from a different source repo?
<garyvdm> Yes
<spiv> garyvdm: try running "bzr check" on that repo or branch, just in case.
<garyvdm> Someone else suggestive that when I first had the problem. It came up clean
<spiv> Yeah, I thought it probably would.  It was worth checking :)
<garyvdm> I was not able to reproduce on my ubuntu box. I'll sign in to irc from my windows box.
<GaryvdM> spiv: I was not able to reproduce on ubuntu, but I was able to reproduce on windows. Here is another pastebin: http://pastebin.com/mc2183f1
<spiv> GaryvdM: it seems likely that there's something different about that repository.
<GaryvdM> I ran bzr check again, and noticed something I didnot notice before: 4 inconsistent parents (http://pastebin.com/m79361e1)
<spiv> GaryvdM: likely it has delta records at different points than the other one?
<GaryvdM> Can I send you another tar?
<spiv> Sure.
<spiv> You can correct the inconsistent parents with bzr reconcile IIRC.
<spiv> My guess is that that isn't the issue, but I'm not very confident about that.
<GaryvdM> spiv: reconcile did not fix.
<GaryvdM> Did you get my tar?
<spiv> GaryvdM: ah, yes
#bzr 2009-12-07
<der|> I've used bzr without any problems so far when adding/pushing on linux. I'm using bzr on windows now, and 90% of the time,when I add or push to a repository, I get this message: "Unable to obtain lock file....", it's on a point that it's annoying, is there any way to fix that problem ?
<igc> morning
<meoblast001> hi
<meoblast001> i'm having a problem with fast-import
<meoblast001> http://pastebin.com/d449f0c4d
<spiv> igc: ^
<meoblast001> spiv: does igc do fast-import?
<spiv> meoblast001: yeah
<igc> meoblast001: which version of bzr and bzr-fastimport?
<meoblast001> 2.0 of bzr
<meoblast001> let me check the bzr-fastimport version
<meoblast001> dang it, i can't figure this out
<igc> meoblast001: bzr plugins
<meoblast001> igc: how do i get fast import version?
<igc> should tell you
<meoblast001> fastimport 0.9.0dev
<igc> meoblast001: ok, so it's reasonably recent
<igc> meoblast001: did you install it from apt? or are you running from a branch?
<meoblast001> branch
<meoblast001> i believe
<igc> meoblast001: ok, so try this ...
<meoblast001> igc: i exported my project, modified a few mistakes i made at commit 1, updating the sizes as i went
<igc> cd ~/.bazaar/plugins/fastimport
<meoblast001> i removed 9 characters from each file
<meoblast001> and if i did my math right, i subtracted 9 from each file's size
<igc> bzr revno
<meoblast001> 243
<igc> ok, 263 is the latest, so
<igc> bzr pull
<igc> meoblast001: ^
<meoblast001> ok
<meoblast001> don't think that will help, but what will it hurt
<meoblast001> ok, updated to 261
<meoblast001> igc: maybe you need to bzr push ;)
<igc> meoblast001: if the problem is still there, raise a bug please and I'll take a look later today
<meoblast001> i might be the problem
<meoblast001> is it possible i did math wrong?
<spiv> meoblast001: that doesn't look like the sort of error I'd expect if you did
<meoblast001> oh :/
<spiv> meoblast001: I could be wrong, of course :)
<meoblast001> should i re fast-export and try again?
<meoblast001> i wrote a program a while ago that automates these changes
<meoblast001> let me see if i can find it
<meoblast001> yuck, C++
<meoblast001> i thought i did it in C
<meoblast001> spiv: igc: i redid the import and it worked
<spiv> meoblast001: hooray :)
<zsquareplusc> is it possible to fix a bug number entered with --fixes later? (i.e. many commits later)
<poolie> zsquareplusc: not as such
<poolie> only by uncommitting and redoing things
<poolie> which is probably not worth it
<poolie> is this on lp or elsewhere?
<zsquareplusc> someone mistyped a bug number back in july. he remeved the related bug in the launchpad interface, but now it apears again. maybe th they rescanned the branch
<zsquareplusc> it would be good if it were possible the edit the comments/metadata for such cases...
<igc> poolie: I'm reviewing https://code.edge.launchpad.net/~mbp/bzr/remove-logging/+merge/15306
<igc> poolie: does it require a bump of the bzrlib API version?
<igc> I'm thining about the constructor changes for TextUIFactory() mentioned in NEWS
<poolie> igc, it is an api bump
<poolie> are we measuring apis per 2.1beta?
<igc> poolie: wasn't sure, just wondering
<igc> poolie: I haven't looked over the policy lately
<poolie> i think the six month cycle probably makes api versions redundant
<spiv> I think we were just going to have a 2.1 API, rather than per-beta.
<poolie> because between betas there are no guarantees, in a stable series there will be no changes, and between series there are guaranteed to be changes
<spiv> Yeah.
<igc> spiv: care to land https://code.edge.launchpad.net/~spiv/bzr/hardlink-2a-408193/+merge/15591?
<spiv> igc: will do shortly :)
<igc> spiv: thanks :-)
<poolie> igc: the sysadmins started on the web server cleanup etc
<neoTheCat> newbie here... if i have a centralized repository, and i went to have a long bath (e.g. documents/programming/guides/...", but i want the leaf directories to be it's own revision, what's the best way to set this up?
<neoTheCat> i setup "documents" as the repos, but i am not to sure the best "bzr" way to do it without causing myself problems down the road
<gutworth> do bzr ini multiple times
<gutworth> bzr init I mean
 * igc lunch
<neoTheCat> gutworth: do a bzr init on each dir in the tree, or just the ones i want to have seperate revisions for?
<gutworth> neoTheCat: just the ones you want separate revisions for
<gutworth> they'll be different branches
<neoTheCat> gutworth: thank you very much.
<mrooney> hello all, my push was interrupted by a network disconnection, so I tried pushing again and it said there was a lock
<mrooney> so I ran the command it supplied, but that gives me an unsupported protocol error
<mrooney> okay, I fixed it by changing the syntax of the command based on https://answers.edge.launchpad.net/launchpad-code/+question/74032, but, why does it give the wrong command?
<spiv> mrooney: because of a bzr bug, just a sec I'll find the number
<spiv> mrooney: bug 250451
<ubottu> Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock for smart-server branches" [High,Confirmed] https://launchpad.net/bugs/250451
<spiv> mrooney: the bug comments have the gory details
<mrooney> spiv: ah neato, thanks for pointing me to the bug!
<poolie> spiv, hi
<spiv> poolie: good afternoon
<poolie> how are you?
<poolie> i was just thinking about the lp: anonymous case
<poolie> because it also came up in this spurious comparison to hg
<spiv> Pretty good, I'm digging into the per-file merge hook bug/feature atm.
<spiv> What's your current thoughts on the lp: anonymous case?
<poolie> i'd do whichever option is easiest to implement on the lp side
<spiv> I'm inclined a bit towards doing it via anonymous ssh, but I think that's partly because I know off the top of my which bits to hack on to make that happen.
<poolie> also, i'd think about getting rid of the lp: xmlrpc and just mechanically transform the url
<poolie> then the server can redirect if the branch should be taken from elsewhere
<poolie> however, that would be a loss of capability a way to send that is actually written
<spiv> Redirect via HTTP or a branch ref?
<spiv> The server could simply alias, too.
<poolie> i was wondering if you'd like to hack on that to keep your hand in
<poolie> right, any of them
<poolie> there is the case of say redirecting to http under heavy load
<poolie> not sure if this is important enough to worry about
<spiv> I am tempted to hack on that.
<spiv> In some ways I think bzr+ssh is the less risky option too, because the WSGI glue isn't as battle tested.
<spiv> I have some fears about its memory consumption.
<poolie> oh my other thought is that it would be interesting to break down the time to get an initial branch of some small project
<poolie> the whole thing from start to finish
<poolie> including dns, xmlrpc, ssh startup, etc
<spiv> The big downside for bzr+ssh for small projects is the 5+ seconds of SSH handshake overhead.
<poolie> it may be that we should recommend some ssh settings to cut down on that
<poolie> right, or it may be that the best case for ssh is still noticeably slow
<spiv> I think multiple round-trips is pretty unavoidable for SSH handshakes without the fiddly persistent connections feature.
<spiv> Which is sufficiently fiddly that I don't even use it.
<spiv> So I think that this would be a potentially big point in favour of hpss-over-http instead.
<poolie> right
<poolie> hm
<poolie> is it really 5s?
<poolie> well, 4.5s for me
<poolie> probably speed of light bounded
<spiv> poolie: hmm, yeah, 4.2s for me I guess.
<poolie> so perhaps that invalidates this bug
<poolie> well
<poolie> at least deprioritizes it
<spiv> Yeah.
<poolie> if you could do it in a trivial patch, it'd be worth having at least for testing purposes
<poolie> and it will be an improvement over http
<poolie> but not so clearly so
<poolie> for example http is faster for bzr info
<poolie> lifeless: when james_w says "updated package targeted to -proposed" just what does that mean?
<poolie> actually -> #ubuntu-motu
<vila> hi all
<mwhudson> spiv, poolie: i think we can easily run bzr+http on a separate box from the main code host
<poolie> hi vila
<mwhudson> which will at least mean that memory gobbling will not affect other services
<poolie> vila, good luck piloting
<poolie> ok
<mwhudson> vila: good morning
<poolie> mwhudson: wbn to have metrics in place from the begining
<vila> poolie: thanks !
<mwhudson> poolie: which ones did you have in mind?
<poolie> hm
<poolie> number of connections, number of crashes, number of distinct ips
<poolie> something like that
<mwhudson> i don't know much about sensible bzr+http deployment, would process per connection make sense?
<mwhudson> poolie: for bzr+http, apache logs can probably give us most of that
<poolie> yes
<spiv> mwhudson: "connection" isn't a directly applicable concept for HTTP
<mwhudson> spiv: even bzr+http?
<mwhudson> it's _really easy_ for us to handle the .bzr/smart requests separately
<spiv> mwhudson: I mean, at some level there are sockets.
<spiv> And a one-to-one mapping of processes to those probably would work well...
<spiv> But configuring that via Apache or whatever when there's HTTP in the middle might not be simple.
<mwhudson> spiv: there are forking wsgi servers i think?
<spiv> mwhudson: quite possibly
<spiv> mwhudson: basically it's 'research required', I think
<spiv> mwhudson: I'm sure it's possible, but the exact software and config to do it wel  isn't immediately obvious to me
<mwhudson> i guess this is an argument for just putting "4133: bzr lp-serve --inet anonymous" in /etc/inetd.conf or whatever
<spiv> mwhudson: yeah.
<spiv> mwhudson: incidentally, someone should do something about the ~anonymous user ;)
<mwhudson> spiv: like our friendly losa spm?
<spiv> mwhudson: quite probably
<spm> do we have a bonefide account as ~anony?
<spm> ha. yes.
<mohit> hey guys
<mohit> How do I prevent a repository from accidentally being pushed to?
<mohit> Does bzr provide any such functionality, or I have to change the file permissions on the OS to achieve the result?
<spiv> mohit: in what context?
<spiv> mohit: file permissions in the OS is often a good answer
<mohit> I have a "LIVE" repository, which powers production systems
<mohit> all the development branches are spun from it
<mohit> I dont want anyone to accidentally push to production
<mohit> Okay
<mohit> there is no way bzr provides such "lock" or something?
<mohit> changing chmod on main trunk is something I am awry of
<spiv> It sounds perhaps like you want chown rather than chmod
<spiv> But either could work, and would be fine.
<spiv> bzr itself doesn't do access control.
<mohit> okay
 * igc dinner
<mohit> thanks a lot man
<mohit> spiv, You are awesome! :-)
<bialix> hello
<jelmer> 'morning bialix
<bialix> good day jelmer!
<The_User> Hi! I try to use BzrGit, so  I installed dulwich, but I still get: "no module named git.remote", how to install this module?
<jelmer> The_User, hi
<jelmer> The_User, how did you install bzr-git?
<The_User> I guess I have to run setup.py? what would be the correct prefix?
<jelmer> put it in ~/.bazaar/plugins/git
<The_User> ah got it, had to remove the original dir from ~/.bazaar/plugins
<The_User> thanks
<TakWork> hm, is there a way to add available statuses to a launchpad projectâ½
<jelmer> TakWork, bug statusses you mean?
<TakWork> yes
<TakWork> basically, I was wanting NEEDINFO
<jelmer> we usually use incomplete for that
<TakWork> ah, ok
<TakWork> I didn't want the reporter to feel chastised ;-)
<rubbs> Usually, if you report Invalid, you want to tell the user why. If you say you need more info, then they probably won't feel chastised, even if you mark it as invalid
<TakWork> it's our first user - I don't want to scare him off :-D
<rubbs> fair enough.
<rubbs> Maybe keep status the same (*new*) and then ask for information. If it's more like a conversation, they are less scared (*as a somewhat new user to bug filing myself *)
<TakWork> yeah, that's what I did
<rubbs> but there is no exact science
<rubbs> I think that's a good idea then.
<TakWork> jelmer: could you update your md-bzr addin repo from trunk, pretty please?
<neoTheCat> hello.  i asked a question yesterday, and it was answered, but i have a followup.  if i have a long directory structure, the root being a repo, and i want the leaf to be different revisions.
<neoTheCat> do i need to init every directory level or just the leaf nodes?  because i am having trouble doing a "bzr push"
<gioele> neoTheCat: bzr init-repo on the root, then bzr init of each leaf directory
<neoTheCat> gioele: thanks
<mwhudson> in mooloolaba the question was asked "what can bazaar do to make launchpad's job easier"
<mwhudson> right now, i would really really really really like bounded memory consumption for bzr serve processes
<elmo> I second mwhudson's request.  with cherries on top.
<mwhudson> elmo: good evenin
<mwhudson> g
<tsmith> hey
<tsmith> how am I supposed to get bzr-svn working in Cygwin??????
<flvr8> hey all, the eclipse update site for the eclipse plugin seems to have a config issue. is there anybody around who can give it a kick
<tsmith> are you talking about how it NEVER saves bzr config changes?
<flvr8> no, it's just not working.... "No repository found at http://bazaar-vcs.org/releases/3rd-party/bzr-eclipse/" when I try to add as an update site
<flvr8> so there must be a config file missing, permissions issue, or similar
<tsmith> o that's been dead for ages
<tsmith> i'll get you the one i used
<flvr8> ah ok
<tsmith> if you figure out how to get bzr-svn for cygwin, let me know lol
<flvr8> it's still referenced on the bazaar wiki
<tsmith> can you edit the wiki?
<flvr8> yeah, looks like i can...what's the right site?
<tsmith> alright you read, flvr8 ?
<tsmith> http://verterok.com.ar/bzr-eclipse/update-site/
<flvr8> ah yeah, that's listed there already as "development snapshots". would prefer to stick with "stable" (at least for the non bleeding-edge ppl on my team)
<flvr8> http://bazaar-vcs.org/BzrEclipse/Installation
<tsmith> yeah see, they pulled it
<tsmith> http://74.125.113.132/search?q=cache:uxRjqo09d88J:bazaar-vcs.org/releases/3rd-party/bzr-eclipse/+http://bazaar-vcs.org/releases/3rd-party/bzr-eclipse/&cd=1&hl=en&ct=clnk&gl=us
<tsmith> it existed as late as mid-Nov 09
<verterok> flvr8: Hi, I'll check with a sysadmin why the "stable" update site isn't working
<tsmith> http://74.125.113.132/search?q=cache:3AJYGPdkifgJ:https://bugs.launchpad.net/bugs/492400+http://bazaar-vcs.org/releases/3rd-party/bzr-eclipse/&cd=4&hl=en&ct=clnk&gl=us
<verterok> flvr8: in the meantime, try using the one at verterok.com.ar
<tsmith> there's the bug report
<flvr8> cool
<tsmith> people in here don't reall seem to care, to be honest
<tsmith> everyone just tells you to use the dev builds
<bialix> tsmith: care about what?
<tsmith> bialix, that the link to the stable eclipse bzr plugin listed on the wiki has been broken for ~16 days
<bialix> your wordings a bit sharp
<tsmith> well, to be honest, i was basing my opinion based on the responses of a very few individuals on this channel that may have been trolls.
<bialix> I'm sure verterok is the one who really care
<bialix> because he's author
<verterok> bialix: :)
<bialix> I was close?
<verterok> bialix: yeap
<tsmith> it definitely was not verterok
<bialix> :-)
<verterok> tsmith, flvr8: looks like some wiki config was changed and it's hidding the releases/3rd-party path
<daneoverton> hey everyone, i'm getting this error when trying to checkout:
<daneoverton> bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n'
<jelmer> daneoverton, what version of bzr are you using?
<mkanat> daneoverton: That sounds pretty clear to me.
<daneoverton> yeah, i guess i need to update, but is there a command for that or do i need to download it
<tsmith> does bzr-svn for cygwin exist?
<jam> tsmith: not sure, though I would highly recommend avoiding cygwin
<jam> (it is about 2-5x slower than native code)
<jam> I personally run native bzr from a cygwin shell without any major problems
<tsmith> bzr for win32 run in cygwin FREEZES for many seconds
<tsmith> how many seconds? like 60-90
<tsmith> sometimes 10 min
<jam> hm...
<jam> you could try Ctrl+Break and see what is going on
<jam> if it is actually frozen
<jam> I don't think I've experienced that
<tsmith> it took bzr win32 FIFTEEN MINUTES to remove a simple lock
<jam> 'to remove' ?
<jam> do you mean 'bzr break-lock' or it was doing something that took 15min before the lock was done?
<mkanat> daneoverton: You'll have to download it.
<bialix> hello jam
<tsmith> bzr break-lock on c:\ took 15 min
<daneoverton> k, that's what i'm doing, thanks!
<tsmith> when i did the exact same operation using cygwin bzr, it took less than a second
<bialix> tsmith: there was a bug related to operations on drive root
<tsmith> well it was in c:\www\projectname
<bialix> do you have antivirus?
<jam> tsmith: well, if cygwin gives you better experience, go for it. My personal experience has been significantly different
<tsmith> yes
<bialix> tsmith: I'm not sure how cygwin avoids crazy checks from antivirus, but that's it
<bialix> tsmith: maybe you need to add bzr to list of "good" applications, or something like that
<lifeless> win 38
<Peng> \i/
<Peng> \o/ I can't type today.
 * bialix fears to ask what is 38
<Peng> #launchpad-dev for me. :D
<Peng> How topical!
<mkanat> Peng: Maybe \i/ is a submarine as seen from behind.
<mkanat> In a narrow channel.
<lifeless> #drizzle
<Peng> mkanat: OK, I'll go with that.
<igc> morning
<mwhudson> spiv: can you think of a way to get different lp-serve processes to log to different files?
<mwhudson> spiv: i.e. not all jumbled up in ~/.bzr.log
<mwhudson> ~/.bzr.log.$pid might work ok for us
<spiv> mwhudson: yeah.  You can probably get roughly that by calling bzrlib.trace.push_log_file(...)
<mwhudson> spiv: ok cool
<spiv> mwhudson: or mv .bzr.log .bzr.log.$pid after the process starts ;)
<bialix> hi igc
<igc> bialix: hi!
<spiv> mwhudson: It might not be crazy to add support for an environment var like BZR_LOG_PATH='~/.bzr.log.%(pid)s'
<spiv> mwhudson: a cruder solution would be to change $BZR_HOME...
<mwhudson> the bzrlib.trace approach is probably fine for us
<bialix> spiv: what's wrong with BZR_LOG?
<spiv> Oh, right, that already exists.  It doesn't have any room for parameterisation though.
<spiv> bialix: mwhudson has many bzr processes running simultaneously, and would like them to have separate log files.
<bialix> well, ues
<bialix> understand
<spiv> mwhudson: so all you need is to replace the 'bzr' executable with a wrapper that does "os.environ['BZR_LOG'] = 'bzr.log.%s' % os.getpid()" first ;)
<spiv> mwhudson: another alternative would be to set it in the SSH daemon to bzr.log.$id(sock_object)
<mwhudson> spiv: it would be nice to be able to map "process using megawads of ram" to the log file
<spiv> mwhudson: trace.mutter('my PID is: %d', os.getpid())  ;)
<spiv> mwhudson: but sure, push_log_file sounds like a pretty good answer.
 * spiv hmms
<mwhudson> spiv: feel free to put any of these ideas in a branch ;-)
<spiv> mwhudson: it's a shame actually that Twisted's spawnProcess doesn't have a pre-exec hook.
<spiv> mwhudson: because otherwise you could use that.  Well, you could monkeypatch os.execvpe, but that's not quite the same...
<mwhudson> spiv: yes, i kinda wanted that for something else the other day too
<spiv> mwhudson: did you file a ticket on Twisted trac for that, or shall I do that now?
<mwhudson> spiv: i did not
 * mwhudson lunches
<bialix> igc: ping
<igc> hi bialix
<bialix> hi
<spiv> mwhudson: twisted ticket #4159
<bialix> some thoughts about your new suggestion feature for qpush
<bialix> igc: when I've cloned branch from server, made changes, commit and then run qpush, it auto-suggests me parent location
<bialix> igc: is it intended change in your patch or side effect?
<igc> bialix: not intended
<igc> bialix: I only suggested when the parent's parent was on LP so perhaps your subsequent tweak introduced that?
<bialix> igc: but it is. I'm still not sure is it should be fixes
<bialix> *fixed
 * bialix checks
<bialix> igc: it seems I found, return '' need to be de-indented
<igc> bialix: I resolved that merge wrt qrun categories btw - just pushed new version
<bialix> igc: thanks, I'll look and merge
#bzr 2009-12-08
<MTecknology> so.. is there any nice intuitive docs for using bzr-fastimport?
<MTecknology> bazzar-vcs.org/BzrFastImport explains hwat it is but not how to use it..
<spiv> MTecknology: bzr help plugins/fast-import
<spiv> (or maybe "bzr help plugins/fastimport", actually...)
<poolie> hi spiv
<poolie> hi bialix, igc, MTecknology
<igc> hi poolie
<MTecknology> spiv: oh - thanks
<MTecknology> poolie: hi
<fullermd> Oh, thanks for mentioning fastimport.  Reminds me I wanted to prod the cvs2svn port maintainer about upgrading...
<igc> MTecknology: see http://doc.bazaar-vcs.org/plugins/en/fastimport-plugin.html
<MTecknology> spiv: now - how about a bzr-fastdeb tool?
<MTecknology> igc: thanks
<igc> and http://doc.bazaar-vcs.org/migration/en/data-migration/index.html
<spiv> MTecknology: what do you mean by "fastdeb"?
<xnox> Hello I've realised I've been working in the wrong branch =) how can I pull just the working tree from the other branch? Can I shelf it on one branch and unshelf in another working-tree/branch
<spiv> xnox: perhaps "bzr merge --uncommitted" can do what you need
<xnox> spiv: Awesome thanks =)
<xnox> how can I push to parent branch instead of push branch without retyping it?
<spiv> bzr push :parent, IIRC
<xnox> spiv: thanks =) is it part of revspec?
<spiv> And if you did "bzr push :parent --remember", then subsequent pushes of that branch you can do just "bzr push".
<xnox> manual?
<xnox> spiv: no I don't want that =) parent is svn repo. Push is bzr for me =)
<xnox> Push is to lp ;-)
<spiv> I'm not sure where it's documented.  The defined aliases are :parent, :submit, :public, :push, :this, and :bound.
<spiv> Hmm, I don't think it is documented.  There's probably a bug about that...
<spiv> It's bug 337834
<ubottu> Launchpad bug 337834 in bzr "AliasDirectory locations are undocumented" [High,Confirmed] https://launchpad.net/bugs/337834
<spiv> igc: any progress on alias (:parent, etc) docs?
 * xnox feels like he know bzr zen now =) working with undocumented tricks ;-)
<poolie> xnox: spoilers welcome
<SamB_XP> spiv: is that one of mine ?
<igc> spiv: still on my todo list. Maybe this week all going well
<spiv> SamB_XP: that bug?  It doesn't have your name on it, but I suppose if you wrote a patch no-one would complain... ;)
<xnox> Oooh Can I write a patch? =)
<xnox> I'll poke around bzr code and try all of them ;-) Black-box testing for perfect documentation =)
<spiv> xnox: well, you can just read the code rather than guess :)
<spiv> xnox: bzrlib/directory_service.py has the relevant code :)
<xnox> ok I'll see what I can come up with ;-)
 * spiv -> lunch
 * igc lunch
<jfroy|work> hey people
<poolie> hello jfroy
<jfroy|work> I'm getting an core dump running a plan diff command in a working tree because of a missing revision (probably a ghost)
<jfroy|work> This being on machine B
<jfroy|work> and the branch having been acquired through bzr-svn
<jfroy|work> so, basically, to be expected
<jfroy|work> the question is, how do I 1) get a list of ghost revision IDs
<jfroy|work> 2) figure out in which branch a particular revision ID lives (on machine A which should have said rev ID)
<jfroy|work> poolie: and hi !
<poolie> hm
<jfroy|work> Also, as a suggestion, core dumping on a missing revision when doing a simple diff -> going to scare people away
<poolie> !!
<jfroy|work> really should handle it better
<poolie> yeah
<poolie> do you mean actually dumping a core file?
<poolie> or just a python stacktrace?
<jfroy|work> right, python stack trace
<jfroy|work> not an actual interpreter core dump
<jfroy|work> that'd be *very* scary :p
<poolie> that's what i thought
<jfroy|work> sorry for the confusion :.
<jfroy|work> * :/
<jfroy|work> Though I consider unhandled exceptions in bzr as "crashes"
<jfroy|work> they're just as unhelpful as plain old crashes to users
<jfroy|work> anyways, on the matter at hand...
<jfroy|work> bzr check lists the the number of ghost revisions
<jfroy|work> but I can't seem to find a command to actually give me the revids
<poolie> jfroy: i agree, we should never show python crashes to user - this is the documented policy, that whenever this happens, it's a bug
<jfroy|work> although the backtrace does have one, which seems kind of silly -- "oh just use unhandled missing revision exceptions to find the ghost revision IDs!"
<poolie> however, in 95% of cases, there is actually some more important underlying bug
<jfroy|work> yeah
<poolie> so showing a crash is an appropriate way to represent it
<poolie> not trying to fob you off but the best thing is probably to either look for or file a bug
<poolie> it may already be known
<poolie> about the ghost revision crash
<poolie> and that bug may have better info than i have in my head
<jfroy|work> Oh I know why I'm getting it.
<jfroy|work> It's a ghost.
<jfroy|work> The bug already exists to handle them better in various commands.
<jfroy|work> well, bugs
<jfroy|work> I just want to get a list of them so I can turn around and find who has those revs...
<jfroy|work> mm, well that worked; used the revid from the backtrace with bzr log -c -r revid:<id>
<jfroy|work> from a random branch
<jfroy|work> it found it, got me the branch nick, and I pulled that branch in
<jfroy|work> need a better workflow than that -- ghosts are going to be common for bzr-svn users
<jfroy|work> might be worth a plug-in...
<igc1> bbiab
<xnox> I have wrote some help for the urlspec and URL directories
<poolie> nice
<xnox> I have tried automating code just like with protocols and it showed up three directories
<xnox> : Easy access to remembered branch locations
<poolie> jam, how do you get into the breakin debugger on windows?
<xnox> lp: Launchpad-based directory service
<poolie> igc ^^?
<xnox> and
<xnox> deb: whitch uses Vcs-* fields.
<xnox> But where did the deb: directory came from?
<xnox> I don't remember installing such plugin and it sounds awesome
<poolie> probably bzr builddeb?
<spiv> xnox, poolie: yes, bzr-builddeb
<xnox> Well I never new about it..... =( now with my improved documentation I found out about it =_
<xnox> =)
<RAOF> It seems that lp:do/0.8 has had a failed upgrade at some time in the past, so when I try to upgrade it now it complains that backup.bzr exists.  How can I fix this?
<spiv> RAOF: connect to it with an sftp client (lftp is a good one) and delete that dir and its contents.
<spiv> RAOF: lftp -e 'rm -r backup.bzr' sftp://bazaar.launchpad.net/~do-core/do/0.8
<RAOF> Aaah.  It's the full specification that's strange.
<spiv> Yeah.
<poolie> spiv, in question 93050 and i think a couple of others recently we've seen things hang during a long body fetch
<poolie> there may be nothing in common and there's not much to go on
<poolie> but i wonder if it's more than a coincidence
<spiv> poolie: hmm, the only other case I recall seeing recently was vila's VM at the sprint
<spiv> (hi vila!)
<vila> hey :) Don't mention that VM hangs, not now, let me get some more coffee first :)
<spiv> That case was due to misconfigured network(s)
 * vila kicks babune hard hoping to un-hang gentoo and hardy and jaunty
<vila> Hi all
<spiv> And in that question 93050 there was definitely a misconfigured network (dropping all ICMP!), pity that correcting that didn't make the problem go away :)
<vila> by the way, if anybody landed some patch related to log, the tests are failing for LOCALE=C (the part we don't run anymore on PQM)
<spiv> It does seem fairly clear from the description that it's something to do with their firewall, which makes me think that it's not bzr's fault, but maybe there's something we can do to make us less susceptible?
<poolie> hi vila
<spiv> vila: I think r4868
<poolie> vila, maybe it was igc sponsoring marius's patch?
<vila> yeah I suspected so... or not, I seem to recall a discussions about tests during the review... I was hoping some long due refactoring there had started :-P
<poolie> spiv oh my mistake
<poolie> i thought there was another one where they hadn't specifically mentioned a firewall thought
<spiv> poolie: hmm, it's confusing, 93050 is a dupe of 93043, although I realise now they misfiled that one against bzr-upload
<spiv> poolie: but in a reply to 93043 they say "If i disable ufw firewall completely, then, i am able to do checkout from the external network."
<spiv> er, 93045 I mean.
<vila> LC_ALL=C ./bzr selftest -s bb.test_log -s bb.test_commit is the recipe to get the 4 errors
<poolie> vila, file a bug for igc, if you haven't already
<vila> poolie: sure
<vila> poolie: do you intend to land or work on https://code.edge.launchpad.net/~mbp/bzr/progress-output/+merge/14944 ?
<vila> if it's 'land' I can help, if it's 'work' let's put it back into wip (Work in progress)
<poolie> vila, it has test failures
<poolie> which i should fix, but i suck
<vila> lol, so wip ? Too many things are already falling from my plate to honestly propose help here :->
<poolie> nag me
<poolie> i'll do it now
 * igc1 dinner
<poolie> vila, sanity check wanted re that review
<poolie> how about giving log code two file like objects, one for unicode and one for bytes (for the diffs)
<poolie> it essentially does this internally but it gets them by peeking inside what it assumes is a codec wrapper
<vila> let me get the code
<vila> argh, marked wip I presume, it went out of the active review page :-/
<vila> so, without the code, two file objects sounds weird, but if it's through an API, I think it's fine and if that's what the code needs anyway then that's the way to go
<poolie> i know
<poolie> there's a bug about that
<vila> one aspect I like a lot about TDD is that it gives more users to the code which is the best way to find the good design and APIs
<poolie> mm
<vila> ha, found it back lp:~mbp/bzr/progress-output right ?
<poolie> right
<poolie> you can still use the url you pasted above
<poolie> like this http://pastebin.ubuntu.com/337132/
<vila> hmm, my gut feeling looking at that is: ui.ui_factory.make_output_stream(encoding) is all that is needed
<vila> each command can then decide how many file objects it wants
<poolie> where?
<vila> http://pastebin.ubuntu.com/337132/
<poolie> i mean
<poolie> are you suggesting i do that in cmd_log?
<vila> log -p is really a special beast AIUI, other commands will use a single file object, only log -p needs two
<poolie> right
<poolie> so i'm just doing this as a special case in log
<vila> yup, as long as the buffering is right
<vila> make_output_stream can then handle the special cases (tty, redirected, etc), the caller is still responsible for the encoding
<poolie> hm
<vila> does that fly ?
<poolie> oh you're saying one level for just 'give me a stream'  and then another doing encoding?
<vila> make_output_stream takes an encoding parameter
<poolie> right
<vila> encoding_type, sorry, hmm
<poolie> so you're suggesting moving that into say make_encoded_output_stream?
<poolie> it takes both
<poolie> it can be eg 'utf-8', 'replace'
<Kamping_Kaiser> can i delete a branch from a remote host? (a branch i've pushed in the past which isn't needed anymore)
<vila> no, just using it, AIUI log requires different encodings for the commit messages and the diffs
<vila> Kamping_Kaiser: bzr doesn't provide a command for that, but you can delete the directory on the remote host (especially if you use a shared repo there)
<Kamping_Kaiser> vila: ah, so i have to ssh to the host and rm -f the branch? no worries. cheers.
<vila> Kamping_Kaiser: that's it, you're welcome
<Kamping_Kaiser> thanks :)
<poolie> vila https://bugs.edge.launchpad.net/launchpad-code/+bug/489036  btw about wip mps
<ubottu> Ubuntu bug 489036 in launchpad-code "where do in-progress mps go to?" [Undecided,New]
<vila> poolie: comment added there
<vila> poolie: also since you're touching _setup_outf(), if you could call it at the right time so that using Command objects become less painful... you'll be my hero :-)
<vila> By 'less painful' I'm thinking about tests or plugins that override commands and have to call _setup_outf() explicitly when building Command objects
<vila>  # XXX: is the caller supposed to close the resulting object?
<vila> yes
<vila> poolie: ^
<vila> # XXX: this does not handle the case of writing part of a line
<poolie> heh
<vila> caller responsibility, trying to address it there will be nightmarish
<poolie> thanks lazyweb
<vila> lazyweb ? Literally a social network of lazy people ?
<poolie> mm, the term for asking humans something that you could look up yourself but are to lazy to
<poolie> too*
<vila> hmm, found it, yeah, got it
<poolie> i'd like to land this but i'd be happy to look at that next
<vila> sure
<poolie> ok
<poolie> incremental diff posted - should be ok but will you have a quick look?
 * vila reading
<vila> poolie: hmm, why not just self.to_exact_file = to_exact_file in LogFormatter.__init__ ?
<vila> and callers will fail if they try to use it without setting it
<vila> jelmer: hi :)
<poolie> (phone)
 * vila cries, vbox's bug is making scroll wheel unusable :-(
<bialix> heya
<jelmer> hey vila :-)
<jelmer> 'moin bialix
<bialix> moin jelmer!
<bialix> bonjour vila!
<vila> hi bialix
<poolie> escudero going down soon
 * shyam_k trying out loggerhead
<shyam_k> but gets the message "internal server error" as i try 127.0.0.1:8080/
<shyam_k> http://pastebin.ca/1706723 thats what "./serve-branches ~/Scheme" says where i have bazaar set to ~/Scheme
<shyam_k> what is wrong here? i just untarred the logger head source and ran that command
<shyam_k> as said in its README
<shyam_k> ./serve-branches ~/Scheme/.bzr shows the directories inside the control directory but not the files..
<shyam_k> ah ic.. thats just the response it gives for any random directory..
<poolie> vila: should i send it?
<vila> poolie: hmm, why not just self.to_exact_file = to_exact_file in LogFormatter.__init__ ?
<vila> and callers will fail if they try to use it without setting it
<vila> you didn't answer that :)
<vila> but anyway, if the actual patch works and given it has already been approved, I don't want to delay it further, if you have enough info to do another submission, please land that one
<poolie> mm
<poolie> misguided conservatism
<vila> and replace some commas by periods in the sentence above, its unreadable :)
<vila> mm, from me or from you ?
<poolie> me
<poolie> leaving the old path
<poolie> k
<poolie> almost 10
<poolie> will fix that and send it tomorrow
<vila> poolie: excellent
<vila> enjoy your night !
<vila> hmm, is there some example somewhere to use pqm for remote branches >
<vila> s/>/?/
<poolie> no
<poolie> i couldn't work it out
<vila> LOL
<poolie> ping spiv for some docs?
<poolie> i meant to do that
<vila> spiv: your patch to pqm is great !!!!
<vila> spiv: Please add doc so all patch pilots can enjoy it !
<vila> :D
<shyam_k> what i am trying to do is to see a web frontend of my local bazaar files..
<shyam_k> bzr serve said its listening on port 4155 but then localhost:4155 just goes on "Transfering data from localhost.."
<vila> poolie, spiv: So the trick is to specify --public-location and --submit-branch and have a locations.conf setup so that it provides pqm_email... a bit tortuous
<vila> oh, and use http: not lp:
<vila> and --ignore-local
<vila> and then... it just works :D
<sepult> i'm trying to checkout the grub trunk from savannah, but bzr
<sepult> complains it's not a branch
<sepult> how does one check it out ?
<sepult> hey
<sepult> anyones awake ?
<spiv> vila: yeah
<spiv> vila: I basically just hacked until it did just enough to work and then went back to doing something more directly productive
<vila> sepult: if it complains, it means you're not using the right url
<vila> spiv: yeah, I can understand that, but a one line example in the readme or somewhere would have addressed that ;)
<bignose> is Ian Clatworthy here?
<bignose> or someone who manages <URL:http://planet.bazaar-vcs.org/> feeds?
<Peng> igc: You have a customer. :D
<bignose> a post from Ian C is messed up, it has an empty URL for the article link.
<Peng> Yeah, that's been going on for a while. You can go to http://bazaarvcs.wordpress.com/ directly.
<vila> poolie, spiv: I knew I read a working example somewhere: bug #487458
<ubottu> Launchpad bug 487458 in bzr-pqm "lookup email target on the target branch not the submitted branch" [High,Confirmed] https://launchpad.net/bugs/487458
<rubbs> If I'm making small changes in the docs to fix bugs (mostly just broken links) should I be putting something in the NEWS file? I haven't been, but I wasn't sure what should go in there.
<bialix> rubbs: just file a merge proposal and reviewer or patch pilot will help you with this question
<rubbs> bialix: ok thanks, should I do something about the ones that were already merged?
<bialix> rubbs: no, if they're merged you can forgot about 'em
<bialix> if you don't plan to continue improve them of course
<vila> rubbs: The rule is that bugs are mentioned in NEWS when they imply a "significant" change in bzr usage, doc is a bit different but sometimes fixing a broken link can change the whole experience...
<vila> rubbs: so use common sense and do as you feel, the reviewer can still disagree if needed :)
<rubbs> vila: cool thanks a lot. that helps. That also means I've been correct so far as well.
<vila> rubbs: sure !
<james_w> rubbs: you could put one NEWS item that summarised the improvements, possibly with the list of bugs
<vila> rubbs: anwyay, the meta-rule is: when in doubt, ask the question in the cover letter
<rubbs> vila: james_w: cool, will do in the future. Most of my changes have been rather small nearly trivial stuff so far, so no need to add to NEWS
<Peng> IMO, enough trivial changes can add up to something NEWSworthy.
<rubbs> maybe what I'll do is find all the doc bugs that have been done in the last few weeks and add them in (since the bzr-doc team has been created)
<rubbs> under a "various bug fixes" heading or something
<rubbs> It might be too much to list all the bug #'s even.
<jam> morning all
<bialix> hi jam
<jam> hi bialix
<bialix> jam, can you suggest some tool to log memory consumption of the linux system?
<bialix> I need to log it to file, not to GUI
<jam> bialix: you might check 'trace.debug_memory()'
<jam> bialix: I also have this script: http://paste.ubuntu.com/337403/
<jam> which spawns a command that you specify
<jam> and then sits and polls the memory consumption every N seconds
<rubbs> bialix: another hackish way to do it might be to use the 'free' command in a shell script like: watch -n 1 free >> log.txt
<rubbs> not sure how well that would work though
<bialix> ok, I'll try to experiment with this, thanks guys
<rubbs> bialix: np. good luck!
<james_w> anyone know why t.path2id would return an id, but t.get_file_text(that_id) would say NoSuchFile?
<james_w> symlink?
<jam> james_w: file deleted on disk but not removed via the api?
<james_w> oh, this is a revision tree I think
<jam> or directory
<james_w> thanks
<james_w> also, I currently have a long running bzr process
<jam> `I usually think of NSF being for a physical file that we failed to read
<jam> not a missing file in a tree
<james_w> strace appears to show it opening the dirstate and reading it, then copying some working tree files to limbo then repeating
<james_w> any idea what it it might be doing?
<james_w> it is a large tree
<jam> if you are looking at a symlink or a directory, I would expect you to get back an empty string for the content
<jam> from what I can see
<jam> james_w: if you are opening dirstate, then it isn't a revisiontree
<jam> james_w: do you have the traceback?
<james_w> oh, two issues
<james_w> http://launchpadlibrarian.net/35785267/merge-issue is the traceback for the NSF
<jam> ah, hmm.. I missed the translation
<jam> RevisionNotPresent => NoSuchFile
<jam> james_w: can you drop into the debugger, and give me the output of "pp repo_desired_files" ?
<jam> hmm.. I guess it is supposed to be [('changelog-20090616010821-kgsodu5lhwu5pm2i-145', 'james.westby@ubuntu.com-20090905094641-seag0w0dagb6q3m1') ]
<jam> so...
<jam> my best guess right now is that you have corrupted data
<jam> something thinks that its text should be found at X, but X isn't present in the repo
<jam> i certainly can't guarantee that
<james_w> maybe it's just bzr-builddeb looking in the wrong repo
<james_w> no, that's not it
<jam> vila: ping for great justice
<jam> james_w: well the line: fix_ancestry_as_needed
<jam> concerns me
<jam> given that it looks like you are doing surgery on stored data...
<james_w> I don't think it means what you think it means :-)
<jam> inconceivable
<jam> :)
<james_w> granted, using ancestry to mean two things is likely to do that :-)
<james_w> ok, your suspicion of corruption may be correct
<james_w> % bzr branch lp:debian/sid/cwidget debian
<eric_f> I'm running Loggerhead 1.17, is there something I'm missing about getting the syntax highlighting support enabled?
<james_w> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('column_definition.cc-20090616010821-kgsodu5lhwu5pm2i-43', 'james.westby@ubuntu.com-20080120093711-23aliq7ki0te4l21')")
<vila> jam: NACK, dinner time, I'll read the logs and be back later (if time permits)
<james_w> hi vila
<james_w> eric_f: do you have pywotsit installed?
<jam> vila: just thinking about trying to get a win32 host running from babune again, and thought I'd chat with you about it.
<jam> can wait till tomorrow
<james_w> eric_f: or "pygments" as it is more commonly known?
<eric_f> james_w: probably not, is that the answer?
<james_w> I think that's the library used to do it
<eric_f> james_w: can that be installed via aptitude?
<james_w> I think so
<Peng> eric_f: python-pygments
<jam> eric_f: apt-cache search pygments
<Peng> eric_f: Should start working automagically once you install Pygments and restart Loggerhead.
<eric_f> james_w, Peng, & jam: thanks! That all worked
<jam> vila: also, wondering the status of fixing the selftest is broken on win32 stuff
<jam> I'll put together a patch if you can't, at least for the "test suite should run" part
<vila> jam: sooo, I couldn't work on bug #492561 today but first thing tomorrow !
<ubottu> Launchpad bug 492561 in bzr "Seftest fails to start on Windows" [Critical,Confirmed] https://launchpad.net/bugs/492561
<jam> vila: I already have a patch that at least lets "bzr selftest" run
<jam> I'm putting it up for review now
<jam> It doesn't fix the failure
<jam> but at least I can get a failure :)
<vila> jam: I too thought about adding a win32 host to babune *but* babune is acting like crazy these days
<vila> jam: yeah, I saw your patch, you're right, put that up for review but let's leave the bug open
<jam> sure
<vila> I'll start from that anyway
<vila> I'm quite sure the failure is closely related to the ones I have from PQM or under emacs depending on details. The crux is that we lack tests :-) But it's damn hard to test these things :-/
<vila> Let's have a call tomorrow, there are other things I like to discuss too anyway. Deal ?
<vila> jam: ^
 * vila hears family calling again
<jam> vila: sure
<jam> vila: enjoy yourc family time
<jam> your
<jam> vila: if you get a chance to approve: https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-win32-test-imports/+merge/15829
<druido> hi, I've got this error message: bzr: ERROR: The method _generate_inventory is not supported on objects of type CHKInventoryRepository.
<druido> I can't find anything on the web about it
<druido> does anybody know what it means?
<druido> this is what i've done: i've splitted a subtree of my branch using the following commands (say 'trunk' is the main branch and 'foo' is the subtree to be splitted):
<druido> cd trunk
<druido> bzr split foo
<druido> cd ..
<druido> bzr join âreference trunk/foo
<druido> bzr commit
<druido> now, whenever i add a file to trunk and try to commit, or whenever i try to revert a change in trunk i get
<druido> bzr: ERROR: The method _generate_inventory is not supported on objects of type CHKInventoryRepository.
<druido> i'm using bzr 2.0.1 and my repository format is 2a
<jam> druido: I'm pretty sure that 2a format repos *don't* support subtrees
<jam> so you can't join --reference in them
<jam> I'm a bit surprising it isn't failing earlier with a 'supports_subtree' check
<druido> ah, ok, in fact that command didn't seem to have any effect
<druido> is it possible to change the format to fix the problem?
<druido> i've repeated the steps again right now, with a new repository and it works as i've explained
<druido> (of course, i forgot to add 'cd trunk' before 'bzr commit' in the steps above)
<druido> ok, here is a minimal set of commands to reproduce my problem:
<druido> bzr init-repo foo-repo
<druido> cd foo-repo
<druido> bzr init trunk
<druido> mkdir trunk/foo
<druido> bzr add trunk
<druido> bzr commit trunk -m "Added foo."
<druido> bzr split trunk/foo
<druido> bzr join --reference trunk/foo
<druido> mkdir trunk/bar
<druido> bzr add trunk
<druido> It seems that, without bzr join, the above works ok
<druido> The problem is, I have given that command, and I've got no error :(
<vila> jam: passing around, https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-win32-test-imports/+merge/15829 approved with minor tweaks
<vila> jam: and to clear any ambiguity, adding a win32 host is high on my list and I agree that any regression in the test suite there is as critical as anywhere else (but I've yet to re-activate the OSX slaves :-/)
<jam> druido: without 'bzr join' bzr add of a sub branch is a no-op, I believe
<druido> ok, but it fails even if i try bzr add with new files
<druido> i should be able to add trunk/bar in the example above, or am i missing something?
<jam> druido: well 'bzr add sub/branch' is saying add all the files in sub/branch, not add sub/branch to the current branch
<druido> sorry, maybe i've not used the cleanest syntax in my commands above
<druido> after the split and join, i cd into trunk and perform 'mkdir bar; bzr add'
<druido> that gives me the error i've mentioned
<druido> i don't understand why
<jam> druido: after you've done the 'join' the content is broken
<jam> it just doesn't catch it early
<jam> as it should
<druido> ok, at least now i understand why
<jam> I don't know why it lets you get into that state by running join
<jam> it shouldn't
<druido> is there a way to fix it? i've tried bzr check and bzr reconcile without success
<jam> bzr revert
<jam> I think will undo it
<jam> if not
<jam> rm .bzr/checkout ; bzr co .
<jam> sort of thing
<jam> but be careful with the last one
<druido> bzr revert gives me the same error
<jam> k
<jam> mv .bzr/checkout .bzr/checkout-broken
<jam> bzr co .
<jam> druido: are you back?
<druido> yes, i was trying your last idea
<druido> it seems to work
<jam> k, I wasn't sure how much you caught with the irc disconnect
<druido> after checking out, i've got a conflict on the subbranch i've splitted
<druido> "Conflict adding file foo.  Diverted to foo.diverted."
<druido> but, after resolving it, it seems to work fine
<druido> now i can add and revert
<druido> great, thank you!
<druido> should i file a report somewhere?
<jam> yeah, https://bugs.launchpad.net/bzr
<jam> there may already be a bug report for this
<druido> ok, i'll search for it
<jam> but something along the lines of "bzr join --reference breaks 2a format trees"
<poolie> hello all
<poolie> i'll file an rt for bignose's issue
<jam> hi poolie
<druido> i've found this: https://bugs.launchpad.net/bzr/+bug/369923 but the error is different
<ubottu> Ubuntu bug 369923 in bzr "Nested tree commit fails in shared repositories" [Medium,Triaged]
<jam> ugh
<jam> On Windows
<jam> copy adir\ file
<jam> well
<jam> copy adir\ target
<jam> ends up copying all files in adir
<jam> into a *single* destination file 'target'
<jam> similar to
<jam> cat adir\* > target
<druido> i'll add a comment to bug 369923 then
<ubottu> Launchpad bug 369923 in bzr "Nested tree commit fails in shared repositories" [Medium,Triaged] https://launchpad.net/bugs/369923
<jam> not exactly what I expected
<druido> ok, i've added a comment to bug 369923
<ubottu> Launchpad bug 369923 in bzr "Nested tree commit fails in shared repositories" [Medium,Triaged] https://launchpad.net/bugs/369923
<druido> thanks for your help, folks!
<igc> morning
<RenatoSilva> how to hack the history? I passed certain time calling the rabbit as fox
<poolie> james_w: around? need anything from us?
<poolie> we need to chew on the udd thread a bit more.
<james_w> poolie: I reported a bug today, I don't know whether it needs some more info first
<james_w> I know the error message is usually not very helpful in understanding what is wrong
#bzr 2009-12-09
 * poolie looks
<poolie> ok
<mwhudson> the bzr-builder "parser" is a little sad making
<james_w> oi!
<mwhudson> james_w: hi :-)
<mwhudson> it'
<james_w> hi mwhudson :-)
<james_w> output from "bzr merge":
<james_w> deleted misc
<james_w> ...
<james_w> Path conflict: misc / misc
<james_w> "bzr st":
<james_w> removed:
<james_w>   misc/
<james_w> ...
<james_w> conflicts:
<james_w>   Path conflict: misc / misc
<james_w> ls misc*:
<james_w> No matches: misc*
<james_w> what sort of conflict is that?
<spiv> james_w: exciting?  confusing?  There are lots of adjectives ;)
<james_w> mwhudson: I don't have anything specifically against using a "proper" parser, I'd just like it to pass the tests, or equivalent ones
<james_w> It's not inexperience that led to that implementation
<james_w> spiv: I'd say both of those apply
<james_w> I've no idea how to resolve it, or even why I thinks I need to
<mwhudson> james_w: it would be nice if there was a grammar for recipes i think
<james_w> yes
<mwhudson> it's not that the current parser is bad, but it's a bit of a blob
<mwhudson> separate lexing and parsing might be nice
<james_w> and then it would be nice if the parser was generated from that, so it was confirmed to be nice
<mwhudson> but maybe that's ott for something simple
<mwhudson> james_w: my use case is wanting to rewrite the branch references in a recipe
<james_w> lexing is hard in this case
<mwhudson> i guess line.split() is a fair approximation of what's possible actually :)
<james_w> yes
<james_w> plus, "bzr tag 'a tag'" would lead to some issues
<james_w> and spaces in URIs may be a bit of a pain with bzrlib
<mwhudson> %20 ftw i guess
<mwhudson> but you can't put a space in the url of a branch on launchpad so...
<james_w> true
<james_w> the issue is that bzr transports take strings, and there's no way to tell if whether it is escaped or not
<james_w> e.g. https://bugs.edge.launchpad.net/bzrtools/+bug/310631
<ubottu> Ubuntu bug 310631 in bzrtools "bzr patch doesn't understand query strings in URLs" [Undecided,New]
<mwhudson> james_w: i think bzrlib generally assumes that urls are escaped
<mwhudson> so that looks like a straight up bug
<mwhudson> hm, i guess you're right, it's a bit muddled
<james_w> bzrtools is doing urlutils.normalize_url() on the path, which might be wrong
<james_w> not doing it might give other problems though
<mwhudson> no, it's the split path and get that's messing things up
<mwhudson> >>> urlutils.normalize_url('http://python.org/?arg=value')
<mwhudson> 'http://python.org/?arg=value'
<james_w> ah
<james_w> that bug's all over the place in my code then
<mwhudson> well
<mwhudson> i don't know what the right fix is
<mwhudson> i guess httptransport's .get() is broken
<mwhudson> but fixing it might break other stuff
<mwhudson> james_w: bzrlib.transport.Transport._unsplit_url says in the docstring
<mwhudson>         Build the full URL for the given already URL encoded path.
<mwhudson> but then escapes the path anyway
<lifeless> jam: https://ec2-sshd.dev.java.net/
<mwhudson> james_w: still here?
<james_w> yep
<mwhudson> james_w: where in the world are you at the moment? ;)
<james_w> home
<james_w> physically, if not temporally.
<mwhudson> yikes
<mwhudson> james_w: we have this need to rewrite the branch urls in a recipe
<james_w> yes
<mwhudson> partly this relates to the way we plan to store the recipe for the moment, but we'll also need it to inject the credentials for building from private branches
<mwhudson> james_w: i think it makes sense for this code to be part of bzr-builder
<james_w> yep, in some form
<mwhudson> james_w: i'm not sure whether the input to this functionality should be the recipe text or the BaseRecipeBranch
<mwhudson> the problem with starting with the latter (and attacking the manifest generating code i guess) is that you'll lose comments and formatting
<james_w> not sure offhand
<james_w> it would be possible to preserve that
<james_w> fugly, but possible
<mwhudson> unless you make the parser smarter
<mwhudson> yeah
<james_w> preserving comments is probably something we should do anyway
<mwhudson> if you take the text as input, you can probably just remember where the branch urls came from and string manipulate them out
<mwhudson> james_w: preserving comments in the manifest, you mean?
<james_w> yeah
<mwhudson> ok
<mwhudson> well that's an argument towards making my changes more "core" and less of a parallel hack i guess
<mwhudson> which is probably a good thing
<james_w> yeah
<james_w> I dread the code to preserve though
<james_w> I think we might need to change the model to make it palatable
<james_w> or maybe not too much
<mwhudson> it's not clear to me where you'd put comments in the model
<james_w> perhaps a new instruction that's a null, but stores the comment?
<mwhudson> james_w: i guess
<mwhudson> james_w: edge cases galore though
<mwhudson> james_w: spot the difference! http://pastebin.ubuntu.com/337738/
<james_w> them the rules! :-)
<spiv> mwhudson: makes perfect sense ;)
<james_w> we could fix that case if you want to file a bug though
<james_w> try putting 3 spaces in the middle line though :-)
<mwhudson> oh and you can't have comments at the end of significant lines
<mwhudson> james_w: i noticed the mandatory two space indent, at least that gets around some of python's complexity here :)
<james_w> that's one of Mark's :-)
<mwhudson> heh heh
<mwhudson> james_w: is not being able to put comments at the end of a line a feature?
<mwhudson> it leads to some slightly strange error messages
<james_w> I don't think it is
<mwhudson> ok
 * mwhudson gets his bug filing hat on
<mwhudson> james_w: https://bugs.edge.launchpad.net/bzr-builder/+bug/487174 reminds me to ask you what the branch ids are for
<ubottu> Ubuntu bug 487174 in bzr-builder "Doesn't enforce uniqueness of branch ids" [High,Triaged]
<james_w> revno:<id>
<james_w> and derivation when we implement that
<mwhudson> james_w: oh, in the debversion?
<james_w> yeah
<mwhudson> makes sense
<mwhudson> james_w: i filed three bugs, i guess you got emailed about them
<james_w> I do, thanks
<treeform1r> it keeps asking me for password how can i unbind
<treeform1r> if it says i am unbound?
<treeform1r> i type "bzr unbind" - it asks me for passwrod - why?
<treeform1r> i type it in
<treeform1r> it says i am unbound allready
<treeform1r> how can i just work locally?
<mwhudson> james_w: i worry a bit about the interaction of # and the run command
<mwhudson> treeform1r: what does bzr info say?
 * igc lunch
<gbbzr> anybody know why bzr is stuck at 1.x in the Fedora repos, even though the package was updated in June of this year?
<poolie> gbbzr: no, but you could ask on the list
<poolie> abadger i think is involved with it but he's not here now
<jml> hello
<jml> does Gordon Tyler hang out on IRC?
<spiv> jml: I think he does, sometimes
<spiv> jml: nick is dOxxx I think, maybe +/- an x
<jml> spiv, thanks.
<bignose> I see references to âNo handlers could be found for logger "bzr"â in various search results
<bignose> but no real clue as to why it would suddenly start happening.
<bignose> I gather it's to do with the fact that logging hasn't been properly initialised, but why would that suddenly start happening without a change in Bazaar for several weeks?
<spiv> bignose: perhaps because bzr couldn't open ~/.bzr.log?
<spiv> (or wherever 'bzr --version' says the log file ought to be)
<bignose> argh
<spiv> bignose: IIRC a relatively common cause is 'sudo bzr'
<bignose> why does that file occasionally get owned by root
<bignose> well, grumble mumble bumble.
<spiv> I *think* there's a bug report about that somewhere, although off the top of my head I'm not sure what bzr can do about it.
<bignose> perhaps a FAQ entry would be good on that.
<spiv> Well, I suppose bzr could emit a clearer warning.
<bignose> yes, that too.
<bignose> it would be good to say explicitly that Bazaar doesn't have the permission it needs to its own log file.
<spm> spiv: so THAT's what that means. I've been happily ignoring it till now. face? please meet palm. Gah. I should have just asked... lala me
<spiv> spm: heh
 * spm emails losas with this fine tidbit of info
<spiv> It's bug 354843 FWIW
<ubottu> Launchpad bug 354843 in bzr "better handle failure to open ~/.bzr.log - Bzr should be smart about who owns ~/.bzr.log" [Medium,Triaged] https://launchpad.net/bugs/354843
<spiv> (And I just marked two other bugs as dupes of that!)
<spiv> Oh hmm we have two 'Critical' bugs, I hadn't noticed that.
<jml> I really, really want to depend on launchpadlib.uris
<spiv> jml: sounds a bit like an ad campaign for a cleaning product... "launchpadlib... you can depend on it!"
<jml> heh
<vila> hi all
<vila> spiv: I don't think #461992 is critical, a 700MB *VM* that can't co a 1GB file... gee, increase the VM ram...
<vila> jml: ECONTEXT, I'm sure launchpadlib.uris is great why advertising it here ? :D
<vila> s/great why/great BUT why/
<vila> Here I go, ruining my first joke of the day with stupid typos... not even a good joke...
<jml> vila, because I could delete code from bzrlib.plugins.launchpad
<vila> ha! And you fear the consequences :)
<jml> vila, well, bzr can't have a hard dep on launchpadlib, realistically
<vila> yeah, but I thought the plan was to make it a soft one
<jml> vila, also, launchpadlib.uris was added to launchpadlib mere hours _after_ the last version of launchpadlib was released
<vila> LOL
<vila> Gimme the new toys !
<jml> it was released last in October
<vila> argh
<jml> there's been a whole release of Ubuntu since then.
<vila> jml: don't get me wrong, there are very good reasons to use the new toys :)
<MvG> Hi! Is there some public official way to have bzrlib determine the relation between two revisions? I'm thinking along the lines of Branch._revision_relations, preferably with the caching Repository.__heads as the backend graph.
<spiv> MvG: I guess doing g = repo.get_graph();  heads = g.heads([revA, revB]) gives you that info with reasonable caching.
<spiv> MvG: I think it would be reasonable to promote _revision_relations to a public API somewhere, although it probably doesn't belong on branch.
<MvG> I think so, too.
<MvG> I guess I'll write a mail requesting that. Last time I wrote such a mail, I was told the function I requested already exists (Repository.iter_reverse_revision_history), so I thought I'd ask here first this time. :-)
<spiv> MvG: so what I'd do then is rely on _revision_relations and file a bug about promoting it
<spiv> Heh.
<spiv> Well, it's possible that it already does and I just haven't thought of it :)
<spiv> If it does, then presumably I can remove _revision_relations and cut down on duplicated code ;)
<spiv> Hmm, I think it probably makes sense a method on Graph.
<spiv> I suppose Graph.find_difference sort of gives you the same thing.
<spiv> Dunno what the performance of that is lie.
<spiv> like, rather.
<spiv> There's Graph.is_ancestor, which gives you part of the info.
<MvG> Graph.find_difference does much more: it seems to list all revisions which are ancestor of one head but not of the other. Way too much overhead.
<spiv> But no equivalent method that I can see.
<MvG> Graph.is_ancestor is implemented in terms of heads, so using heads directly to determine both directions should cut my costs by hald at least.
<spiv> _revision_relations is also implemented in terms of heads.
<MvG> Yes, that's how I found it.
<spiv> But only makes a single heads call, of course.
<spiv> Anyway, a patch to move _revision_relations to Graph with a public name makes sense to me.  I'd happily review a patch to do that, presumably we'd want to add unit tests for it though.
<MvG> spiv: Why to graph, not to repository? Repository.__heads is a special caching graph instance, and reusing that instance seems benificial to me.
<spiv> MvG: Repository.get_graph() should already be caching, so I don't think there's a practical difference
<MvG> Repository.get_graph() does cache the graph itself, while Repository._heads does cache results from heads requests directly.
<spiv> Well, I suppose __heads is specially optimised for heads() lookups.
<spiv> But if it's that useful I would think it should be cached on graph rather than the repository.
<spiv> MvG: Actually Repository doesn't have __heads/_heads, you're looking at CommitBuilder I think
<spiv> MvG: which probably explains why there's no code that resets the _heads cache during Repository.unlock, and probably also ensures the memory impact of that cache will be small :)
<MvG> spiv: You're right. I guess I'm too used to Java, with its one class per file paradigm.
<jml> On https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth/+merge/15853, poolie points out that the patch will cause launchpadlib to be loaded whenever bzr is loaded
<MvG> OK, so we assume that caching all heads requests might be too expensive, and furthermore that we can get at a reasonable caching graph using Repository.get_graph(). In this case a method in Graph would really be the better alternative, I guess, yes.
<spiv> MvG: right
<jml> I thought plugins were loaded lazily
<jml> if they aren't, how can I do a conditional lazy import?
<spiv> MvG: if you find with that that performance isn't good enough, then we can always try to think of ways to do better :)
<spiv> jml: they can't be; otherwise how can a plugin e.g. decorate a builtin command the way bzr-loom does?
<spiv> jml: however, plugins can and should use lazy_import themselves
<jml> spiv, ok. that's good to know.
<jml> spiv, how do I do a lazy import that behaves like the one in the patch?
<spiv> jml: in my ideal world, a plugin's __init__ would register commands or hooks or whatever it needs to do, and have the rest of the code lazy imported.
 * spiv looks
<spiv> jml: so, you want lp-mirror to only exist if the dependency is available?
<spiv> jml: why not make it always exist, but give an error if the dependency is missing?
<spiv> jml: I think that might be a nicer UI too, it seems more discoverable to me
<jml> spiv, I guess I could do that.
<spiv> "Why don't I have lp-mirror, I have the launchpad plugin!"
<spiv> jml: and in that case, the lazy import can just be a good ol' fashioned local import in the run method of that Command if you like.
<jml> spiv, I can imagine it being a little confusing to have lots of available commands that you can't actually use.
<spiv> Well, let's worry about that when we have lots rather than one?
 * igc dinner
<spiv> I can imagine making some infrastructure for that, maybe provide something like "bzr plugins --check-deps" that plugins can hook into?
<spiv> But we already have this situation with e.g. SFTP support without causing much drama.
<spiv> (If you don't have paramiko I believe attempts to use sftp:// URLs will give you a relatively friendly error about needing paramiko)
<spiv> Anyway, I'd argue it's no more confusing than commands simply not existing even though you think you've installed the plugin that provides it.
<jml> OK
<spiv> (Or with a bundled plugin, that you think you've installed the version bzr that bundles the plugin that provides it... see, confusing ;)
<spiv> jml: I'll add a brief note about my opinion to the review for posterity
<MvG> spiv: I guess I'd rather return a number (e.g. -1, 0, 1) instead of a string, as numbers are cheaper to compare. Opinions?
<spiv> MvG: strings are almost as cheap to compare, especially if they are literals that contain strings that can be Python identifiers, because those strings are interned
<spiv> MvG: so the comparison in that case is basically just a pointer comparison
<spiv> MvG: I'd be happy have module-global constants for those strings, I think.
<spiv> MvG: but I really doubt that the cost of that comparison will be significant compared to the cost of the underlying heads call!
<MvG> Probably true, yes.
<spiv> MvG: If you measure a performance problem, I'd be very happy to look at the measurement and figure out improvements, though :)
<spiv> MvG: but I strongly advise against micro-optimisations that impact code clarity without evidence that they'll have a significant effect.
<MvG> Agreed. Didn't know about Python cheaply comparing such things.
<MvG> spiv: would you agree that the plural in "_revision_relations" is wrong? There is only one possible relation between any two given revisions.
<spiv> MvG: yes
<spiv> MvG: I've no idea why I never noticed that before :)
<spiv> MvG: as far as Python cheaply comparing such things, I've skipped over a bunch of mostly unimportant details about how CPython compares ints and how it compares strs... But the general rule of measure before guessing about optimisations certainly applies :)
<spiv> MvG: I'll happily chat about CPython implementation trivia sometime if you like, but not tonight :)
<MvG> spiv: I guess I also had some concerns about typos in literals on the part of the caller, but constants take care of this. By the way, is there some python idiom to declare a constant as opposed to a variable?
<spiv> MvG: CONSTANT = 'value'
<spiv> MvG: rather than: variable = 'value' :)
<MvG> But python doesn't enforce constantness on these, does it?
<spiv> No, but it doesn't enforce constantness on anything, more or less :)
<spiv> Except the evaluation of 1+1, and I've seen an extension module to change that ;)
<MvG> spiv: By the way, I sent my mail requesting the method: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/64622
<spiv> MvG: thanks!
<sjamaan> I'd like to make a checkout (or branch) of only a subdirectory in a repo. Is that possible?
<MvG> sjamaan: I'm no expert, but I'd guess no. I assume you'd have to branch the whole tree, then you could split of a subdirectory into a separate project if you want to.
<MvG> Although I assume that if you split, changes to that subdir are at least more difficult to merge back into the whole tree. Dunno, though.
<sjamaan> Can I keep updating the subtree from the main repo?
<sjamaan> (I've never used SPLIT before)
<sjamaan> ie, can pull fetch data from a subdir in a branch?
<jml> spiv, I'm pushing up a new version that makes the change you've suggested.
<jml> very. solwly.
<jml> (well, after I upgrade it. man, isn't that just the gift that keeps on giving?)
<jml> spiv, pushed.
<TeTeT> I run into a problem on karmic when pushing to LP, http://pastebin.ubuntu.com/337892/
<TeTeT> it says different rich-root support
<TeTeT> I assume I need to upgrade the LP branch
<spiv> TeTeT: right
<spiv> TeTeT: generally "bzr upgrade lp:FOO" should Just Work.
<TeTeT> spiv: can I still access the branch from hardy then with the new format?
<spiv> TeTeT: you need bzr 2.0 (or at least 1.18), which I don't think is in hardy's backports yet, but we have a backport in the PPA: https://edge.launchpad.net/~bzr/+archive/ppa
<TeTeT> spiv: ok, so I rather branch on merge on hardy then, so it stays compatible, thanks
<spiv> TeTeT: if you create your repo with --pack-0.92, it'll be the same format as that branch on Launchpad
<TeTeT> spiv: I do that for init-repo?
<spiv> TeTeT: yep
<TeTeT> spiv: thanks for your help!
<spiv> TeTeT: not a problem, glad I could help.
<spiv> jml: are you sure you pushed?  I don't see any new revisions
<spiv> jml: oh, it's stacked on the old, non-rich-root, bzr trunk, so boom: https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth
<spiv> jml: I think bzr and launchpad can take equal credit for that snafu ;)
<vila> jam, jam1, jam*: ping
<jam> vila: pong
<jam> sorry, pidgin disconnected and didn't want to reconnect until I restarted it
<vila> bad pidgin :)
<vila> jam: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 is up for windows tests
<vila> ./bzr selftest -s bt.test_osutils.TestTerminal should now pass
<vila> but see cover letter for my requests ;-)
<__monty__> Is it a good idea to have a hand at some low priority bugs to get more python experience?
<vila> __monty__: sure
<rubbs> __monty__: sure. The devs here are really good at helping you through the process of getting it included too.
<jam> __monty__: you might look for the "easy" tag
<jam> if people haven't grabbed them all already
<jam> I think there might also be "trivial" ?
<jam> vila: so, one of the primary reasons to use stderr is because progress bars go to ... stderr
<jam> so even if you redirect stdout
<jam> you still would like to know the term width, to draw a progress bar
<__monty__> Thanks for the quick replies.
<jam> that said, I guess the test suite wants to have stdout width
<jam> which means... it sounds like we should have a flag
<rubbs> __monty__: I would suggest a trivial tag at first. just to get your first patch in. Then once you get the hang of how to get something in go for something bigger.
<rubbs> that's what I did at least
<vila> jam: bzr help also needs the terminal width but outputs on stdout...
<vila> and so does log --line
<jam> sure
<jam> though what should those do when redirected to a file?
<jam> log --line, I would probably expect to go full width
<vila> use None and not cut lines
<jam> bzr help... probably we want to keep it wrapped at a reasonable width
<vila> yup
<jam> since otherwise the full help texts becomes super long
<jam> or the text editor wraps it in an ugly way
<vila> long story short, that's what BZR_COLUMNS is for
<vila> to come back to windows, using stderr or stdout shouldn't matter since it should not be called anymore
<vila> you had some tests with and without redirection, how do they behave now ?
<vila> with --subunit and tee IIRC
<jam> vila: but that is an ugly way to do it
<jam> BZR_COLUMNS=20 bzr command foo >
<jam> espec on windows
<jam> where you can't inline it
<jam> set BZR_COLUMNS=40
<jam> bzr command foo >
<jam> set BZR_COLUMNS=
<jam> I would like to have a better answer than that
<jam> but yes, I'll run the tests
<vila> yeah I know, poolie filed a bug about using -O to set options without polluting the global options namespace. Fom there having some rules to go from env variables to options should filled the gap. At least for things like BZR_PLUGIN_PATH and BZR_COLUMNS
<vila> so you can use say bzr -OBZR_COLUMNS=46 command
<vila> or bzr -OBZR_PLUGIN_PATH=-site selftest \o/
<jam> vila: test suite passes on windows when run manually and when run redirected
<jam> oops
<jam> spoke too soon
<jam> test_falls_back_to_COLUMNS
<jam> fails
<jam> when redirected
<jam> 42 != None
<jam> vila: you have: getattr(sys.stdout, 'isatty', None) before the COLUMNS check
<jam> so I think that test would fail on Linux when redirected as well
<vila> yeah, so that test is bogus
<vila> COLUMNS makes sense only for a tty
<jam> vila: as said before, stderr may be a tty even if stdout isn't
<jam> ... :)
<vila> hmm
<vila> I;m tempted to reply ESCOPE :-)
<jam> so, I want my test suite to pass
<jam> I don't really care about the answer here
<jam> what we've had has been just fine for me for a long time
<vila> jam: pushing a fix
<jam> I would be a little concerned about fixing something that isn't broken
<jam> but apparently for others it is ?
<vila> well, the main problem was pagers and the lack of overriding solution
<vila> I think the proposed fix make things clearer
<vila> to address the stdout/stderr I think we need yet another pass on all uses and disambiguate the API by explicitly requesting for either stdout or stderr, the windows heuristic sounds brittle otherwise
<vila> what if stderr is redirected and not stdout ?
<jam> vila: right, so 'bzr log --line | less' is different than 'bzr log --line > file', but I don't think there is a way to detect the difference
<jam> vila: unlikely to have stderr redirected and not stdout
<jam> and if it does, then progress bars do crazy things
<vila> OMFG how did they implement pipes 8-/
<vila> jam: never say unlikely on IRC, fullermd is never far away....
<jam> we've had similar issues with encodings based on "| less" versus "> file"
<jam> because on windows
<jam> standard file encoding
<jam> != standard terminal encoding
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<jam> which is crazy
<jam> oh, and it isn't filesystemencoding either
<vila> !triggers ubottu ?
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<jam> vila: yeah
<jam> so you can say !paste
<jam> but only at the beginning
<jam> !paste
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from  command line | Make sure you give us the URL for your paste - see also the channel topic
<jam> !pastebinit
<ubottu> pastebinit is the command-line equivelent of !pastebin - Command output, or other text can be redirected to pastebinit, which then reports an URL containing the output - To use pastebinit, install the Â« pastebinit Â» package from a package manager - Simple usage: command | pastebinit
<jam> interesting
<jam> hard to parse "pastebin it"
<jam> I thought it was "pastebin init" at first
<jam> anyway
<jam> vila: do what feels good to get things passing
<jam> we've probably spent far too much time versus the utility already
<jam> (my feeling is, we're going to get it wrong, probably fairly often. whatever decision we choose)
<vila> jam: agreed, fix pushed, can you check it works for you
<jam> vila: all tests pass
<vila> on the other hand, people have complained regularly about the lack of pager support, now we have *some* support
<vila> jam: Courtesy url for votes: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858
<vila> :D
<vila> you assigned bzr core devs on #154129 , what do you mean by that ?
<jam> we all worked together on implementing 2a
<jam> so we all get credit
<jam> bug #154129
<ubottu> Launchpad bug 154129 in bzr "pack should recompress objects, optimise layout, etc" [Medium,Fix released] https://launchpad.net/bugs/154129
<jam> well, at least I didn't feel I should be the only one getting credit, and once the number is greater than 1, there isn't a clear value to put three
<vila> jam: nevermind, I thought it was still open
<jam> vila: merge approved, witha bit of a mini rant for posterity
<vila> lol
<vila> jam: good summary.... I'll put https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 in some commit message so you'll get true posterity :^)
<__monty__> Would this: https://bugs.launchpad.net/bzr/+bug/257170 be a good bug for a beginner?
<ubottu> Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed]
<fullermd> Hmm?  Somebody summon me with an 'unlikely'?   :p
<jam> __monty__: probably. I think it is already slightly fixed when there is an exception, but it probably would be good to write out "bzrlib.__version__" on startup always.
<jam> fullermd: your summoning time has gotten slow recently :)
<jam> well, today at least
<__monty__> jam: By startup you mean?
<fullermd> Well, you've never met me, so you'll have to take my word for it, but TRUST me; I NEED my beauty sleep   :p
<vila> fullermd: sleep  is for ?
<jam> __monty__: the bug is that when the bzr process starts, we log the command line arguments, but we don't put version info into the log file
<jam> fullermd: sort of a Shrek1 sort of thing? (by night one way, by day another)
<__monty__> jam: So it doesn't have anything to do with bzr log ?
<jam> __monty__: correct
<jam> this is about .bzr.log
<jam> not 'bzr log'
<fullermd> Of course, in this case I won't contest the unlikely.  Being a csh user, I don't get to adjust stderr without touching stdout   :p
<__monty__> To work on bzr bugs, which source release should I get?
<Pilky> ouch: http://www.reddit.com/r/programming/comments/acsad/bazaar_blows_goats/
<Pilky> I sort of agree with the gist of his launchpad comment and the cold start slowness, but the rest of it sounds like "It isn't what I'm used to, waaah"
<jam> fullermd: why is that the case on csh?
<__monty__> Should I get the stable or the developer release of the source code to work on bugs?
<jelmer> __monty__, the code from bzr.dev ideally
<fullermd> jam: You mean historically?  Dunno.  Just how it is.
<jam> fullermd: is it just that the syntax doesn't let you?
<jam> __monty__: for this, the stable code would be ok, but bzr.dev is fine, too
<fullermd> Oh, yes.  It's one of the standard csh-whynot-isms.
<fullermd> You can dup it onto stdout, and that's about it.
<NfNitLoop> so... I seem to get the impression that bzr-svn stores more metadata than git-svn when you push back into the upstream svn repo...
<NfNitLoop> is that true?  Anyone know off-hand?
<NfNitLoop> Ok, I'll ask Google. :)
<jelmer> NfNitLoop: yes, that's true - bzr has more metadata than git
<NfNitLoop> I know bzr stores the non-linear history metadata as svn properties...   is that what's missing in git?
<NfNitLoop> It may be a bit academic.  If git-svn lets me work with our SVN repo that bzr-svn won't (because at some point in its history there was a file with backslashes in its name)...  I may just suffer through using git.
<Tak> bzr-git < git-svn < svn ? ;-P
<NfNitLoop> ya, ew.
<NfNitLoop> :p
<jelmer> NfNitLoop: That's one thing
<jelmer> NfNitLoop: Other things are: file ids, revision ids and revision properties (none of which git has)
<Pilky> Tak: why not throw hg in there and do bzr-hg < hg-git < git-svn < svn :p
<NfNitLoop> ah, I knew git didn't do file IDs...  it doesn't even store the revision ID!?
<NfNitLoop> that seems odd.
<Pilky> Tak: if you tried hard enough you might be able to get cvs in there somewhere
<fullermd> git revision id's are entirely derivable from the contents of the revision.
<NfNitLoop> so if you then do an update you might start getting conflicts with branches that have already merged the changes?
<NfNitLoop> aaah.
<NfNitLoop> ok, that's fine then.
<jelmer> NfNitLoop: I'm not sure what the status of backslash support is
<NfNitLoop> in git?  I guess I'll see when git gets to that revision. :p
<Tak> Pilky: I guess that would depend on whether hg or git have a cvs wrapper
<Tak> speaking of which, I pulled down someone's inadvertent commit of an RCS dir to our svn repo the other day
<jelmer> NfNitLoop: in bzr
<jelmer> NfNitLoop, bzr-svn supports backslashes fine
<NfNitLoop> jelmer: ah, I'm subscribed to the bug about it.  haven't seen any traffic lately.
<__monty__> Is there a bug which you would advise for a newb?
<jelmer> __monty__: try looking for bugs triaged trivial in launchpad
<__monty__> Any of them?
<__monty__> Such as: https://bugs.launchpad.net/bzr/+bug/239523
<ubottu> Ubuntu bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed]
<jelmer> yeah, all bugs tag trivial *should* be doable for people looking to contribute to bzr for the first time
<jelmer> feel free to ask for mentoring here or on the mailing list
<RenatoSilva> verterok: hi
<__monty__> What are the responsibilities of a mentor?
<jam> __monty__: it isn't quite an official thing. Just that you can ask for help/questions and we'll try to help you
<__monty__> Oh ok.
<RenatoSilva> verterok: ok np :)
<jam> __monty__: I should also mention our PatchPilot program: http://wiki.bazaar.canonical.com/PatchPilot
<jam> Which is where we have people specifically working on helping people land their patches
<johnjosephbachir> hello
<__monty__> hi
<johnjosephbachir> how do i make a new remote branch? this equivalent from subversion does not work: bzr branch http://example.com/foo http://example.com/bar
<johnjosephbachir> do i make the new branch locally and then push it?
<beuno> johnjosephbachir, yes
<johnjosephbachir> there isn't a more direct way?
<beuno> johnjosephbachir, bzr init REMOTE_LOCATION
<beuno> but you can't do it via http
<beuno> you will need ssh
<johnjosephbachir> how about webdav?
<johnjosephbachir> bueno what would be the command for ssh?
<johnjosephbachir> okay, i just did it the push-from-local way, and it worked in seconds -- so i guess bzr was smart about using the remote repo, hoorary
<johnjosephbachir> sorry for the newb question
<rubbs> johnjosephbachir: don't be sorry for newb questions. If anything it gives those of us on the doc team something to consider
<rubbs> ;)
<johnjosephbachir> thanks
<rubbs> np
<jml> spiv, I don't supposed you fixed it?
<dOxxx> *sigh* cable outages suck :P
<rubbs> dOxxx: yes, cable outages do suck. What caused yours?
<dOxxx> we've had a bit of a winter storm here, so I guess it's causing trouble with the wires
<dOxxx> don't know for certain though
<rubbs> ah, you in the midwest?
<rubbs> I used to live in Iowa
<dOxxx> nope, Toronto
<rubbs> ah, gotcha.
<rubbs> I live in Ohio now so we're about to get one too.
<dOxxx> Enjoy! :)
<dOxxx> hmmm... might be cutting out again soon
<dOxxx> ominous pauses
<rubbs> haha
<fullermd> Winter...   yeah, I remember hearing about that, years ago...
<phinze> ack! my shelf! http://gist.github.com/252861
<phinze> hmm looks like it's bug 389674
<ubottu> Launchpad bug 389674 in bzr "exception encountered when unshelving" [Undecided,New] https://launchpad.net/bugs/389674
<phinze> This is because the conflict handling code has not been fully updated to avoid using Tree.inventory. -- abentley
<phinze> i'm looking at the shelf-1 file, which is in 'Bazaar pack format 1'
<phinze> i feel like i know where the evil conflict is, but i don't know how many lines to delete :P
<phinze> eh, feels like i'm about 10 minutes short of finding docs on the format, but it's small enough that it's faster for me to manually re-apply the changes
<phinze> sure
<phinze> that worked
<jelmer> what exactly are the release plans for bzr 2.1? Should lucid have 2.1?
<spiv> jml: at 11pm?  No :)
<jml> spiv, what are you replying to, excatly?
<spiv> jml: <jml> spiv, I don't supposed you fixed it?
<jml> spiv, oh ok. I wasn't online at 11pm, so I was a bit confused.
<poolie> hi all
<mdt> I'd like to back up my repositories (weekly using a cron script) to a remote backup service.   Anybody know how to do this?  With CVS I just copied the files in the central repository to the remote server using rsync.
<gioele> mdt: you can do that with bzr as well
<mdt> New to Bazaar so don't rly know how/where data is kept, even
<gioele> just rsync the .bzr directory of the repository
<gioele> I have a repository at /srv/backup/
<gioele> that directory contains a .bzr sub directory
<gioele> I use rsync --archive --partial --partial-dir=.rsync-partial --delete-delay --progress -i /srv/backup/ remote:~/backup-bzr
<fijal> hi
<fijal> I'm looking for bzr benchmarks
<poolie> fijal: http://bazaarvcs.wordpress.com/tag/benchmark/
<poolie> to start with
<fijal> er
<fijal> ok
<fijal> let's be more specific
<fijal> I look for bzr performance benchmarks
<spiv> poolie: fijal is a pypy dev, I think
<fijal> correct
<poolie> you want to test bzr under pypy vs elsewhere?
<fijal> yop
<poolie> check out https://launchpad.net/bzr-usertest
<spiv> And thus wants to make C extensions for performance obsolete ;)
<poolie> which runs various macrobenchmarks
<poolie> ooh, welcome :)
<fijal> does it come with "a standard repository"?
<poolie> there are some in-tree microbenchmarks but they tend to rot
<poolie> fijal: no, it runs on your choice of repository
<poolie> since the test data would be large
<poolie> possibly we should put some snapshots in its download files
<fijal> can I have one large repository please :)
<spiv> fijal: lp:mysql :)
<poolie> bzr branch lp:mysql
<poolie> :)
<fijal> ok
<poolie> hi spiv too
<spiv> Good morning :)
<fijal> well, it's sort of hard to look for pure-python benchmarks
<fijal> which are *not* template languages
<spiv> Haha
<spiv> I can believe that :)
<mdt> so does the .bzr directory contain all the info required to reproduce all the files in my project?  I mean if I simply copy that dir recursively onto a brand new machine somewhere I'll be able to check out my project from it?
<fijal> for example mostly everybody moved to C
<fijal> side question - what's the ratio of oldstyle vs newstyle classes in bzr?
<fijal> (I'm too lazy to check)
<spiv> Practically all new.
<fijal> good
<fijal> this is completely unlike twisted
<spiv> Indeed :)
<fijal> which has practically all old
<spiv> We've depended on python >= 2.4 since bzr began.
<spiv> Twisted didn't have that luxury :)
<fijal> right
<spiv> (glyph just cited some 1.5.2 docs at me in a recent review of a patch I just did for Twisted!)
<mdt> @gioele ty
<igc> morning
<fijal> ok
<fijal> since it
<fijal> 's midnight I'll actually go to bed
<fijal> I'll try to make some benchmarks tomorrow then
<gioele> just wondering, how long does it take to branch lp:mysql?
<spiv> fijal: oh, lp:mysql-server is actually the large branch I think, I'm not sure there's actually a lp:mysql
<spiv> gioele: well, lp:mysql-server is ~450M of history, although it's still in 1.9 format
<Peng> gioele: You didn't make the destination repo 2a, did you?
<gioele> Peng: everything is pack-0.92
<gioele> Peng: couldn't I do that with 2a? I don't see why
 * jelmer waves to igc, spiv, Peng and gioele
<igc> hi jelmer!
<gioele> lifeless: ping
<lifeless> hi?
<gioele> lifeless: may I ask you something (in a query) about the la_AU locale?
<gioele> hi jelmer
<jelmer> la_AU... is that what I think it is?
<lifeless> jelmer: lingua latina
<spiv> jelmer: hi :)
<lifeless> the AU is a nonsense due to posix being naffed
<lifeless> gioele: sure, or you can ask here.
<gioele> oh, well, OK
<Peng> gioele: It's just that trying to convert lp:mysql-server to 2a over the network ends in unhappiness.
<lifeless> its not particularly private :>
<gioele> I'm trying to create a locale as well (English language with European LC_*)
<gioele> how did you test it?
<lifeless> built packages, installed, ran shit.
<lifeless> uhm, the xlib thing is the most tricky bit - gnome apps *ignore* xlib's locale support
<gioele> did you sudo cp la_AU into /usr/lib/locales?
<lifeless> so
<lifeless> no
<gioele> ok, I suppose I'll have to bzr-debuild some packages :)
<lifeless> I patched gdm, libc6, libx11
<gioele> lemme write that down
<lifeless> these days you shouldn't need to patch gdm
<gioele> these days? why?
<lifeless> its been rewritten and no longer has a whitelist of locales.
<gioele> ah, ok, one down
<gioele> what should be done in libx11?
<lifeless> there is a long list of keyboard processing stuff
<lifeless> so you will need to pick a locale that works, find all references to it, and clone them to your new one.
<lifeless> locales: why conflating data with different dimensions is a bad idea.
<lifeless> breakfast time
<lifeless> gioele: I blogged about this at the time, with links to my patches
<lifeless> two separate blog posts I think, cause I realised libx11 was broken after the first patch.
<gioele> lifeless: I read those, this is the reason I'm here asking these questions :)
<gioele> the fact is I can't find a link to the libx11 issue
<lifeless> hmm
<spiv> poolie: no, I'm not on emacs-devel
<lifeless> gioele: https://bugs.edge.launchpad.net/ubuntu/+source/libx11/+bug/423569 https://lists.ubuntu.com/archives/karmic-changes/2009-June/002209.html https://edge.launchpad.net/ubuntu/+archive/primary/+files/libx11_1.2.1-1ubuntu1.diff.gz
<ubottu> Ubuntu bug 423569 in libx11 "la locale support was reverted in merge from debian" [Undecided,Confirmed]
<lifeless> poolie: you pung on a patch; I'll probably look at it in the new year.
<poolie> k
<poolie> is not urgent
<poolie> just shows up in my activereviews page
<lifeless> its bzr-email, right? get jam to review
<lifeless> he has done a lot in that plugin as well
<lifeless> or andrew :) - its a team branch I think, and I feel no special urge to control it
<gioele> lifeless: thank you, the libx11 part does not look difficult at first sight (now that you dig into it ;))
<johnjosephbachir> anyone here have much experience with split/join/ nested trees ?
<xnox> Does a "$bzr checkout lp:project" have full branch history?
<spiv> xnox: yes
<xnox> But it is bound?
<spiv> RIght.
<spiv> If you run "bzr info", you'll see that the repository for it is local rather remote.
<xnox> Ok. And I can run $bzr reconfigure to change from a regular branch to bound
<xnox> Can a checkout still have :parent, :push and :submit?
<xnox> Or bound to two places?
<spiv> It can only be bound to one place.
<spiv> Otherwise you'd have to deal with confusing situations like "bzr commit" successfully updating one place but failing on the other.
<xnox> get it =) and confusing
<spiv> Well, I guess in that case lock_write() each place first might be ok... but you get the idea :)  It's complex enough! :)
<spiv> I believe a checkout "has" :parent etc, because actually those belong to the branch, so they are looked up on the bound branch if you have a checkout.
<spiv> So they work, but I think they belong to the branch rather than checkout itself.
<spiv> I'm not 100% certain about that.
<xnox> I'll try to make a :parent :push and then reconfigure as bound
<gioele> goodnight
#bzr 2009-12-10
<xnox> Can someone give me a scenario when you want to use :parent :push :submit and :public branches
<xnox> spiv: yeap everything gets preserved you can be bound and have :parent :push :submit and :public
<johnjosephbachir> anyone here have any experience with add --file-ids-from ... ?
<johnjosephbachir> it seems tantalizingly useful but i cannot find any examples
<james_w> johnjosephbachir: you pass a path to another branch and if the path it is adding is in the other branch then it re-uses the file-id from that in this branch
<james_w> say you have a stable and a development branch
<james_w> you want to add COPYING to each
<james_w> you go in to stable and "bzr add COPYING", commit etc.
<james_w> then go to development, put the file there, and then "bzr add COPYING --file-ids-from ../stable"
<james_w> and then when you merge there won't be a path conflict due to two random id assignments being done
<james_w> that's not the only use, and there are other ways to achieve the same thing in that case, but it's an example
<johnjosephbachir> cool
<johnjosephbachir> i am interested in the last line of the paragraph in the manpage: It is also useful when merging another project into a subdirectory of this one
<johnjosephbachir> james_w: i imagine that this should be useful in subsequently updating the files in the subdirectory project
<johnjosephbachir> but i can't fathom what that workflow would be
<johnjosephbachir> since there is no notion of running a merge on a subtree which points to a foreign branch (is there?)
<james_w> well, if the ids match then it will merge the files
<james_w> however, I'm not really sure how that would work
<james_w> as you have to get the revision history joined as well (could perhaps just be a second step)
<james_w> and I don't know how you deal with the root, or the path differences
<james_w> there's a merge-into plugin for doing this task, probably better to look at that if you are actually looking to do this
<johnjosephbachir> james_w: great, i will definitely check that out. was also looking at bzr-scmproj but it seemed a little heavy
<johnjosephbachir> it doesn't work with 2a repos... great.
<james_w> what doesn't?
<poolie> igc, random idea for the plugin guide, since it came up with jml
<poolie> document how to handle heavy dependencies
<poolie> don't load them from __init__
<poolie> just let the commands fail
<poolie> hello james_w
<igc> poolie: interesting
<james_w> hi poolie
<james_w> morning igc
<igc> poolie: bialix made some changes to the command handling is explorer lately to reduce start-up time, etc. so it will be nice to capture that sort of wisdom
<igc> in
<james_w> poolie: the couple of threads on udd seem to be stalled
<james_w> do we need to jump-start them?
<poolie> they do a bit
<igc> hi james_w
<poolie> we are working on some bugs
<poolie> spiv is doing per-file merge hooks today
<poolie> but i think we need to get the earlier pipeline stages flowing too
<poolie> james_w: any specific things we should do?
<poolie> just reply to the loose ends?
<der|> is there any command to remove the 'pending-deletion' and 'limbo' directories from my .bzr directory ?
<poolie> hm
<poolie> do you need to?
<der|> many times bzr complains that the files exist and I can't do nothing
<poolie> i guess you can just delete them but maybe file (or look for) a bug report
<james_w> my mail about the things we may need over the next few months hasn't seen many responses
<poolie> because you shouldn't need to manually remove them
<der|> bzr: ERROR: This tree contains left-over files from a failed operation.
<james_w> I don't think there's been an assessment of which we need and which we will do
<poolie> i'll look at them again- but igc, spiv, can you look too please?
<der|> now, I've heavily used bzr on a linux-based system, but since I (unwillingly) had to migrate to windows, bzr starts creating some sort of lock files and the limbo ones
<igc> poolie, james_w: shall do
 * spiv looks
<der|> on linux bzr works flawlessly to my experience
<der|> poolie, there's already a bug report in this: 427773
<poolie> bug 427773
<ubottu> Launchpad bug 427773 in bzr/2.0 "empty limbo dirs prevents to successful execution of bzr commands and left working tree locked" [Medium,Fix released] https://launchpad.net/bugs/427773
<poolie> hm
<poolie> and are you on 2.0.1 or 2.1.0b1 or later?
<der|> Bazaar (bzr) 2.1.0b3
<der|> poolie, so far I haven't had the annoying lock issues (thank God)
<der|> seems like that has been fixed
<poolie> der|: so this bug is apparently not fixed?
<der|> poolie, btw, if I have to report something regarding the bzr explorer plugin, where should I go ?
<poolie> and they are empty?
<poolie> please comment there and reopen it then
<poolie> launchpad.net/bzr-explorer
<der|> the limbo and pending-deletion are empty correct
<der|> poolie, maybe this helps:  I was workign with a Photoshop PSD file, and I was trying to revert it with:   bzr revert --no-backup -r5 home.psd, after that the limbo and the pending-deletion directories were conflicting
<der|> poolie, do the bzr explorer guys have an IRC channel ?
<poolie> they're in here -- hi igc!
<poolie> der|: please reopen the bug and say that there
<poolie> i'm happy to help you here but i want a record too
<poolie> was it maybe still open in ps when you did this?
<poolie> could be file locking
<der|> poolie, sure, I'm filing a bug for bzr explorer now, just 1 sec
<der|> poolie, yeah, ps was open, maybe that's the issue
<poolie> i'm surprised it would fail on the limbo directories rather than when moving the file though
<johnjosephbachir> james_w: merge-into doesn't work with 2a
<johnjosephbachir> it also doesn't help with subsequent merges (i think)
<james_w> that sounds odd
<johnjosephbachir> indeed
<der|> poolie, how do I reopen the bug ?
<poolie> click 'status'
<der|> it has 2 statuses, one says Bazaar and the other says 2.0
<der|> both say 'Fix Released'
<poolie> mm
<poolie> cos it's a bug we'd like to fix in the stable series
<der|> https://bugs.launchpad.net/bzr/+bug/427773
<ubottu> Ubuntu bug 427773 in bzr/2.0 "empty limbo dirs prevents to successful execution of bzr commands and left working tree locked" [Medium,Fix released]
<poolie> so in this case it would be reasonable to reopen both
<der|> indeed
<der|> so, post the same comment on both statuses ?
<poolie> just one comment will do
<der|> ok good, which status I set ?
<poolie> both
<poolie> you can change them with no comment
<der|> ok, but where it says Fix Released, should I put 'In Progress' ?
<poolie> i'll do it
<poolie> you concentrate on the comment :)
<der|> ok hehe, I'll just put the comment
<der|> poolie, ok, posted the comment
<poolie> can you reproduce it?
<der|> ok, let me try, 1 sec
<der|> poolie, if I try to revert 3 times, it first tells me about the pending-deletion, then about the limbo, and then it locks it
<der|> poolie, ok, I'm able to reproduce it 100% of the time, what should I do now ?
<der|> poolie, and by the way, bzr actually reverts the file, so that error or exception should not be displayed/thrown
<poolie> just post that
<poolie> maybe garyvdm can look at it
<der|> ok, I'll post how to reproduce it
<Stavros> hello
<Stavros> does anyone know of a continuous integration server that receives pull requests, pulls, checks the build and merges if the tests pass?
<Stavros> i can't remember the name...
<lifeless> igc: http://blogs.sun.com/joshis/entry/hudson_integration_in_netbeans_6 <- slick :)
<der|> poolie, just posted the comment with the replication procedure, hope it helps :)
<bob2> Stavros: PQM?
<Stavros> bob2: let me check, i think that's it
<Stavros> yes, fantastic, thanks!
<der|> well, I'm out, thanks for the support guys, and kudos for creating such a wonderful piece of software... peace and good night!
<Stavros> does anyone know how it compares to hudson?
<lifeless> Stavros: apples and oranges
<lifeless> hudson does not have test-before-commit yet
<lifeless> pqm only has test-before-commit
<lifeless> hudson has a shiny UI and lots of toolchain support
<lifeless> pqm has bare bones UI - its a 'hackers tool'
<Stavros> ah, i see
<Stavros> does it only work by email?
<Stavros> basically as i understand it hudson only tests after the commit while pqm does not commit unless the tests pass
<lifeless> pqm has a pluggable queue concept but only one impleentation -the email submission, locally stored queue
<Stavros> ah right right, i see
<lifeless> http://issues.hudson-ci.org/browse/HUDSON-1682
<lifeless> if that ^ gets done, then it would be equivalent to pqm, but much much nicer
<poolie> james_w: so i guess just knowing that people should report those failures as bugs on udd helps
<Stavros> yeah, but also much harder for them to do it i imagine
<Stavros> since they're looking to do it in a general manner
<Stavros> i have to decide which method i want to use, then
<lifeless> Stavros: not really, pqm is pretty general
<lifeless> its just a matter of doing it.
<Stavros> does it support other scms?
<poolie> der|: fyi 'incomplete' means 'we need more data to do anything' not 'incompletely fixed'
<spiv> poolie, james_w: replied to udd list
<spiv> poolie, james_w: there are some points there that I think need attention from the lp code team rather than the bzr team, though
<spiv> e.g. the query about 'Do Branch.requestMirror() and Branch.last_mirror_attempt refer to importing to the code if the branch is a vcs-imports one?'
<fungalicious> poolie: ping
<fungalicious> thumper: ayt?  (this is actually kfogel)
<thumper> fungalicious: nah, you don't sound like him
<fungalicious> thumper: :-)
<fungalicious> thumper: heh.  At Winnie's house, left my computer elsewhere
<fungalicious> thumper: can you do me a favor?  I forgot to send out a message to internal launchpad list, addressed to team leads, saying that we were giving up on the SIP thing and that the next call would use regular conf system
<fungalicious> thumper: I can't send it easily from here, as my work email authn creds are not on this box
<thumper> fungalicious: I'll send one out
<fungalicious> thumper: my impersonation worked!  You really believed I am kfogel!  MY CORPORATE ESPIONAGE IS SUCCESSFUL!!!
<fungalicious> thumper: thank you
 * thumper thinks twice
<fungalicious> c'mon, only kfogel would say that
 * thumper thinks thrice
<thumper> heh
 * fungalicious goes recursive on the whole impersonation thing
<thumper> sure, I'll send it out
<fungalicious> Now I have to wonder if this is really thumper.
<fungalicious> HAH
<fungalicious> nic
<fungalicious> nice
<eric-the-half-a-> dang
<fungalicious> ok, signing out as I think spending the night on IRC is perhaps not what Winnie and I had in mind
<fungalicious> thumper: thanks
<poolie> wonder what he wanted
<lifeless> whom?
<gutworth> (who you mean?)
 * igc lunch
<jam> lifeless: I did some work on bug 481119, it is pretty annoying as it prevents using hudson + junit with bzr selftest --subunit
<ubottu> Launchpad bug 481119 in pyjunitxml "TypeError while running bzr selftest --subunit | subunit2junitxml" [High,Triaged] https://launchpad.net/bugs/481119
<jam> tz aware datetime is crap
<jam> IMO
<jam> note that *with* my ugly ugly hack, I was able to run a subset of the test suite using hudson on win32 and have it report results
 * igc medical appointment
<jam> igc: good luck
<igc> hi jam - thansk
<igc> thanks
<lifeless> jam: oh, cool
<lifeless> jam: let me have a look at the bug, one sec.
<jam> is there a reasonable "display a rough summary of what is going on" that would be reasonable to include in the 'build and run the tests' output?
<jam> I'd like something that I could check to see that it is making progress
<jam> but I don't really want the full subunit output
<lifeless> jam: sure, subunit2pyunit
<poolie> night all
<jam> so, subunit2pyunit --progress makes sense to be, but not really in a build system
<jam> night poolie
<jam> I guess it just gives pyunit --verbose output, which you're probably right
<jam> is the most reasonable thing
<jam> one line per test
<jam> now if only pure win32 actually had a 'tee' program... :)
<lifeless> we can make subunit2pyunit pass the stream through
<lifeless> selftest | subunit2junitxml -o tests.xml | subunit2pyunit
<lifeless> jam: there is a hudson ssh thingy now, for ec2 w/ windows
<jam> lifeless: well, I have cygwin installed and can just grab that, but it seems stupid
<lifeless> I've linked it to the ec2 windows bug
<jam> lifeless: yeah, I saw the ssh thing
<jam> I don't know about start/stop yet for windows
<lifeless> jam: win32 shell can pipe can't it ?
<jam> lifeless: shell can pipe, can't tee
<lifeless> right
<lifeless> so would -  selftest | subunit2junitxml -o tests.xml | subunit2pyunit work ?
<lifeless> if that passed the stream through
<jam> lifeless: probably
<jam> I sort of like saving the subunit results, though
<jam> since I can use them in debugging
<lifeless> yes
<jam> the hudson progress bar is quite interesting
<jam> it seems to base it on how long things are expected to take
<lifeless> yes
<jam> based on previous runs
<jam> as mine is now fully in the red
<jam> as previously I just ran "setup.py build" which is a bit faster than 'selftest' :)
<lifeless> what hudson instance are you using?
<jam> local
<lifeless> cool
<jam> Eventually, I'd like to hook it up to ec2
<jam> and then see about stuff with babune
<jam> but figured one step at a time
<lifeless> so, parameterised jobs will let you submit arbitrary branches
<lifeless> night poolie
<lifeless> the drizzle folk do this
<jam> yeah, though there is also a Bazaar plugin
<jam> that can check out code from bzr automatically
<lifeless> they have a parameter trigger in fact - one field, put in a branch, and it kicks off 8 different configs
<jam> which I'm also playing with
<lifeless> jam: this is with that plugin.
<lifeless> the two combine for more awesome
<jam> hmm.. I haven't seen a way to use the parameter from the parameterization in the plugin
<jam> I've seen the fields you can add
<jam> but I would have to write the 'bzr branch' manually (from what I've seen so far)
<lifeless> let me poke at their config
<lifeless> you have a parameter BZR_BRANCH
<lifeless> and in the SCM details you say
<lifeless> ${BZR_BRANCH} as the bazaar repository URL
<jam> So in the "configure this build" page, I have a "Repository URL" in the Source Code Management section.
<jam> ah, ok
<jam> I did play with params at the beginning
<jam> I also have to say +1 to the Bruce Schneier plugin
<lifeless> :)
<jam> I've seen it before, but it adds a bit of levity when browsing the results
<lifeless> chuck norris++
<jam> Bruce Schneier's secure handshake is so strong, you won't be able to exchange keys with anyone else for days.
<lifeless> lol
<jam> lifeless: do you know the specifics between a 'successful build' and a 'stable' one?
<jam> Is it returns 0 for successful
<jam> and 'stable' is all tests pass?
<jam> interesting, even gives an rss feed for 'all builds' or 'all failing builds'
<lifeless> so
<lifeless> you can introspect builds a bit if you build with more finesse than shell scripts
<lifeless> and you can separate 'compiled' from 'something wrong after the compile'
<lifeless> stable build is all tests passed
<lifeless> unstable build is some tests failed but the build completed.
<lifeless> there isn't currently an interface for shell steps to indicate unstable.
<lifeless> I was thinking of writing a plugin to look for a file 'build-unstable' to permit that.
<jam> lifeless: I find this odd: http://weblogs.java.net/blog/2009/05/20/project-day-ssh-daemon-ec2-windows-amis
<jam> given that there is already cygwin with a fully functioning ssh
<lifeless> there is
<lifeless> but it can be a little temperamental, and its much more complex than I'd want to have a remote-setup maintain
<lifeless> where as this is a single jar, anda  jvm, which hudson wants anyway.
<lifeless> jam: anyhow, glad you are enjoying it; the tz thing - I think I started to stab at it; basically subunit was sending the wrong timedness for the junitxml code
<lifeless> jam: my inclination is just to say 'always be utc (tz) aware, because subunit generates iso timestamps, which are always given a tz.
<jam> lifeless: Did you see my branch/
<jam> ?
<lifeless> yes, I haven't looked at the content yet
<jam> it implements an overly simple tzinfo class
<jam> and then changes the line from
<jam> datetime.utcnow() to datetime.now(local_tz)
<lifeless> that seems reasonable. its a bit nuts that utcnow doesn't return, well, utc datestamps
<jam> yeah
<jam> another possibility
<jam> is to use the test start time as the first time in the stream
<jam> I think it is actually going to be a bit broken for my use case
<jam> since I'm running subunit2junitxml *after* the test suite finishes
<lifeless> I don't see why that would make it broken
<lifeless> (but why are you running it after ?)
<jam> lifeless: it will report a total-time of however long it takes to parse the file
<jam> since it takes the individual time runs based on the stream
<lifeless> huh ?
<jam> but startTestRun() it takes from whenever the script starts
<jam> lifeless: self._run_start seems to be set before any of the stream is parsed
<jam> it is the only call that uses datestamp.utcnow()
<lifeless> ah
<jam> all the rest return the time that got set by the call to the .time() function.
<lifeless> subunit doesn't have a start stream command
<lifeless> so, thats likely a bug in subunit2junitxml
<jam> lifeless: so if you just fixed that, it would avoid needing to call utcnow() (IME)
<lifeless> it probably wants to reset the total time at the first explicit time() call
<jam> right, something like that
<lifeless> bbs
<jam> well, I'm heading to sleep anyway
<jam> subunit2pyunit seems to have the same problem, for what its worth
<jam> Ran 13835 tests in 3.475s
<vila> jam: sleep well ! :)
 * vila 's not there yet
 * fullermd waves at vila.
<vila> hi all
 * vila waves back to fullermd 
 * igc dinner
<vila> igc: ping
<_Andrew> hi guys, quick question
<_Andrew> how do I produce a diff with the authors name in it
<_Andrew> so I can send it as a patch
<Kamping_Kaiser> bundle, iirc
<fijal> eh
<fijal> I seem to be caught in a dependency cyclce
<fijal> cycle
<fijal> how do I get a checkout of bzr?
<fijal> seemingly harmless question, but the repository is newer than my bzre
<fijal> bzr
<Kamping_Kaiser> your not able to upgrade your bzr?
<fijal> ok, got the tarball
<fijal> I don't want to upgrade my bzr
<fijal> I just want a checkout
<fijal> seems to be contradictory
<fijal> how do I run bzr tests?
<fijal> bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'get_foreign_tests_branch_factory'
<fijal> this is what happens if I run bzr selftest
<fijal> great
<jelmer> fijal, looks like you have an old version of one of the foreign branch plugins
<fijal> that's great
<fijal> how do I tell bzr "ignore my plugins, I don't care"
<fijal> ?
<spiv> fijal: --no-plugins
<fijal> any reason why bzr has yet-another test runner?
<fijal> for example, is there an option "stop at the first crash"?
<vila> fijal: -1
<vila> fijal: there are many good reasons for that yes, one is that the full test suite run can be quite long and even just loading the python modules containing the tests is significant, so there is the --starting-with (-s option) that greatly speeds up that part.
<spiv> fijal: it's basically just standard unittest with a bunch of tasteful extensions.  There's a branch from lifeless that removes a bunch of our test code and replaces it with a dependency on testtools (http://launchpad.net/testtools)
<__monty__> How do I get to know the bzr source? Do I start at setup.py and follow every outside call?
<james_w> __monty__: bzrlib/builtins.py might be a good place to start
<james_w> it's the top-level for each of the commands you know and love
<james_w> so you can see the sort of thing you have to do to display the history in "bzr log"
<rubbs> __monty__: what james_w said. That and there are some dev docs here : http://doc.bazaar-vcs.org/developers/
<__monty__> Ok thanks you guys.
<rubbs> __monty__: np. good luck
<Mez> hardy PPA isn't building.
<Mez>   bzr: Depends: python-central (>= 0.6.11) but 0.6.7ubuntu0.1 is to be installed
<Mez> sorry, isn't installable.
<Mez> nvm, my mistake
<jam> vila: looks like you had a good start to your piloting :)
<vila> jam: thanks for the support :)
<vila> Except for the remaining doc ones that I hope igc will look into soon, I think all mps got at least one comment and only one is still waiting for some work from me (deprecation warning).
<vila> Nobody has voluntereed (sp?) for next week though...
<znik> i am getting this error: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~flavour/sahana/sahana-trunk/".
<james_w> why can't I find <built-in function utf_8_encode> in the python 2.6 docs?
<james_w> and why does it seem to be trying to encode to ascii?
<james_w> znik: running what command?
<jelmer> james_w: it's in codecs
<znik> james_w:  bzr branch lp:~flavour/sahana/sahana-trunk sahana
<james_w> znik: do you want lp:sahana/sahanapy
<james_w> ?
<james_w> jelmer: yeah, I can't find it
<vila> james_w: str.encode('utf8') ?
<znik> james_w: ohh sorry imissed the py!!
<james_w> vila: it's in bzr
<jelmer> james_w: what gives you the impression it encodes to ascii?
<james_w> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 12: ordinal not in range(128)
<jelmer> james_w: that suggests you're passing in a plain string, not a unicode string
<james_w> I'm trying to pass in the result of <string>.decode("utf-8")
<vila> james_w: it's implemented in C: ./Modules/_codecsmodule.c:684:utf_8_encode(PyObject *self,
<vila> james_w: it's weird that you get a UnicodeDecodeError if you're *enc*oding
<james_w> ah
<calvin1602> Hi. I'm deperately looking for PQM documentation.
<calvin1602> Any help ? :)
<james_w> so it's presumably the str = PyUnicode_FromObject(str); that is failing
<vila> james_w: ECONTEXT
<assad> james_w: i am getting a permission denied. do i have to ask the moderators for permission
<james_w> vila: in the function you just pointed too
<james_w> assad: doing what?
<assad> james_w: bzr branch lp:~flavour/sahana/sahana-trunk sahana
<vila> james_w: if you passed in an unicode string that shouldn't occured
<james_w> I must be passing a plain string as jelmer suggested
<james_w> I'm looking now to see if re is getting in the way
<james_w> or something isn't doing what I think
<james_w> assad: I don't see why that would give a permission denied. Could you pastebin the output please?
<vila> james_w: osutils.safe_utf8 and safe_unicode may help if in doubt
<calvin1602> BzrDocsRock pretends that it is 90% complete, but there is no trace of it ...
<calvin1602> and there is a question about it on launchpad, with no answer
<assad> james_w: http://pastebin.com/d33d8e510
<james_w> calvin1602: I don't know of any, sorry
<james_w> assad: don't run with sudo
<jam> assad: "Permission denied (publickey)."
<jam> something is wrong with your ssh key when connecting
<jam> possibly because of sudo
<assad> james_w: http://pastebin.com/d6944f64f
<james_w> assad: "sudo rm -r sahana"
<james_w> then try "bzr branch ..." again
<james_w> without sudo
<assad> ok
<assad> james_w: no such file or directory. cant remove 'sahana'
<james_w> assad: perhaps the permissions on /home/user/Downloads/web2py/applications/ don't allow your user to write there
<assad> james_w: that is why  i did the sudo bzr branch .. !
<assad> still i wasnt able to !
<james_w> that was because root can't access you ssh key
<james_w> I suggest you allow your user to write to your own home folder
<james_w> sudo chown -R user /home/user/Downloads/web2py
<james_w> or your username if it is not in fact "user"
<assad> james_w: its working now!!
<james_w> nice
<assad> thanks
<lamont> wth does 'pretifying graph' mean, bzr-gtk?
<vila> lamont: mostly loading the whole ancestry and building the graphical version
<rubbs> Is their any way to remove the history of a HUGE file in a shared repo? I was dumb as a newbie and trying to backup my shared repo is slow and big because I once committed a big file, and my repo is fairly big, and I don't need that file or that history (I was playing around, dumb I know).
<rubbs> sorry run on sentence there
<NfNitLoop> well, as long as the file is in the history of one of your branches, and you're not doing a lightweight or stacked checkout, you need that large file in your shared repo to have a complete history.
<NfNitLoop> if it's been a while, you could create a branch of the revision just before you added it.
<lamont> vila: I suspect it wanted to use the (also non-word) 'prettifying"
<NfNitLoop> then merge in all changes except the one that added that big file.
<vila> lamont: you mean the code or the feature ? Did you try qlog instead >
<vila> ?
<lamont> vila: it was more that I failed totally to understand the origins/roots of 'pretify' - if it's based on 'pretty', then it needs a second 't'
<lamont> this is in the messages spit out in 'bzr visualise'
<vila> lamont: oooook, I can fix that:)
<lamont> just wasn't sure if I was missing some new tech term, or if it was a bug
<rubbs> NfNitLoop: I was afraid of that. Ok no biggie. I'll just deal with it.
<vila> lamont: hehe, many non-native english speakers have contributed here, thanks for helping them :)
<lamont> I speak 'merican, not English :-D
<vila> merican girls are pretty too so that should be good ;)
<rubbs> NfNitLoop: the merge idea is nice, but i have 3 or for more branches that were created after my mistake, and are still in on going development, so I'm just going to deal with it for a while. I might take your suggestion and do the merge later
<lamont> vila: I'm not supposed to notice, other than my wife
<vila> lamont: looking is not the same as touching, I have full permissions to look :)
<lamont> heh
<rubbs> lamont: my fiancee said this to me : "Just because I'm on a diet, doesn't mean I can't look at the menu." Of course when I look at the menu, I get in trouble ;)
<vila> lamont: How can you still compliment here if you can't compare... There is a lot of good reasons to keep looking :)
<rubbs> vila: haha good one.
<vila> rubbs: here is a even worse: Just because I have lots of good bottles in my basement doesn't mean I can't have a beer at the bar...
<vila> This one is really horrible because she just can't deny it :)
<rubbs> I don't think that'd go over well, but it is pretty funny
<vila> rubbs: of course that don't go, that's why it's horrible: if accepted it covers far more than just looking :)
<rubbs> vila: true enough.
<assad> james_w: bzr was working but after some time i got this error:   bzr branch lp:~flavour/sahana/sahanapy-trunk sahanabzr: ERROR: [Errno 13] Permission denied
<james_w> you must still have strange permissions on your local disk
<assad> james_w: should i work with root?
<james_w> assad: you shouldn't need to
<assad> james_w: bzr does work for some time "fetching revision: inserting streams" after which i get the error!!
<pindonga> hi. I am trying to branch a project from launchpad, but I am behind a squid proxy and a firewall that block ssh access... is there any way I can branch the project?
<cody-somerville> pindonga, http
<pindonga> I tried, but I keep getting errors
<pindonga> bzr branch https://code.launchpad.net/...
<pindonga> and I get bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden)
<cody-somerville> bazaar.launchpad.net
<pindonga> cody-somerville: how can I find out the correct url for my project?
<pindonga> using bazaar.launchpad.net?
<jam> pindonga: generally it is "http://bazaar.launchpad.net/~user/project/branch"
<jam> https generally redirects
<jam> but as it is https you may encounter different issues, versus going straight to the target.
<pindonga> jam, indeed, I am getting some issues, if I do bzr branch https://bazaar.launchpad.net/~ricardokirkner/lalita/sentry I get 'Not a branch', if I do branch bzr+https I get 'Generic bzr smart protocol error: Invalid http response for [...] Unable to handle http code 404: Not found'
<jam> there is no bzr+https on that location
<jam> neither https
<jam> just "http"
<jam> http://bazaar.launchpad.net/~ricardokirkner/lalita/sentry
<jam> this seems to work for me: bzr branch http://bazaar.launchpad.net/~ricardokirkner/lalita/sentry
<pindonga> jam, yes, you are right
<pindonga> thx
<pindonga> now, if I want to push stuff, do I have to do that through http?
<pindonga> is there no support for https?
<beuno> pindonga, just use lp:~ricardokirkner/lalita/sentry
<beuno> make sure you've specified your launchpad-login
<pindonga> beuno, I cannot . I am behind an http proxy and firewall that blocks ssh
<beuno> and that your ssh key is up on launchpad
<beuno> pindonga, ssh or sftp are the only ways of pushing up data
<pindonga> beuno, do you know where I can read about this? (I mean the underlying reasons for not supporting anything besides ssh/sftp)
<beuno> pindonga, I don't think there is anything documented
<beuno> I also don't know of any other services that let you write through http
<pindonga> no, that's why https would be good
<beuno> pindonga, http and https would be almost the same to support really
<pindonga> I know of two services that let you write through https: googlecode and bitbucket :-)
<pindonga> is there anything that can be done to support https directly?
<beuno> pindonga, you can try bringing up the topic on the launchpad-dev mailing list
<beuno> but considering there isn't a bzr smart server for http, and the cost of developing and maintaining an extra moving part, it seems unlikely to happen
<pindonga> ok, thx
<saedelaere> hi
<saedelaere> i have a little project and started to use bazaar recently. this is my first version control system so I'am quite inexperienced.
<saedelaere> now, i want to release a new stable release of my software. after that i want to start with the next development branch.
<saedelaere>  the problem is what happens if there are bugs in the stable release. i would need to make an update for this version. do i need to start a new branch after releasing my stable version?
<beuno> saedelaere, there are many different ways of handling these things
<beuno> one way would be to always have a "trunk"
<beuno> trunk is where you develop
<beuno> when you release, you branch off, and keep that separate
<beuno> any updates you need to do to the release, you do on the release branch
<saedelaere> ok i started, with bazaar using one of the tutorials on the homepage. in fact i'am working alone on this project if this important. so what would i need to do now?
<saedelaere> this is the output of [bzr info]
<saedelaere> http://pastebin.org/63172
 * beuno looks
<beuno> saedelaere, you are ready to release?
<saedelaere> ups sry pidgin crashed
<saedelaere> beuno: no I'am not ready now :) i hope next week. i just wanted to ask now to be able to start right away.
<saedelaere> is it complicated`
<saedelaere> beuno still here? :)
<saedelaere> so is it correct to go to my working directory.
<saedelaere> bzr branch bzr://tv-viewer.bzr.sourceforge.net/bzrroot/tv-viewer tv-viewer.081
<saedelaere> this creates a new directory tv-viewer.081 correct?
<saedelaere> now i could work on this branch if there are any bugs and even push them back to sourceforge. so this will also create a new directory there?!
<saedelaere> omg i'am unsure and don't want to mess it up
<saedelaere> ok just played around with it in virtualbox. it created a new directory as i supposed. should i add this directory now to ignore files?
<meuserj> At some point an upgrade cause the following error to happen on most of my branches in a shared repository:
<meuserj> http://pastebin.com/d48d63a40
<Typh> what's the best practice for moving a versioned directory somewhere else within the project
<gutworth> bzr mv
<Typh> I tried that but it complains the destination was unversioned. Of course it's unversioned, it doesn't exist yet
<Typh> or should I create the required dirs, add them, then bzr mv the files
<gutworth> add it then
<rubbs> Typh: you could try to move them with mv and then do a bzr mv
<rubbs> read : bzr help mv
<rubbs> it says that if the old file exists only in the versioning and not on the fs, and the new name is on the fs but not versioned, it will assume you moved to the new location
<Typh> so it does. shame on me :)
<rubbs> Typh: np. it happens, I didn't know until I looked
<NfNitLoop> Hrmm, reading 'bzr help branch' and --hardlink supposedly "Hard-link[s] working-tree files where possible."
<NfNitLoop> working tree files!?   so if I change something in one branch it updates the other?
<NfNitLoop> That seems wrong.
<gutworth> NfNitLoop: hard links are not like symbolic links
<fullermd> NfNitLoop: Well, theoretically you'd only use it with an edit{or,ing method} that breaks the link...
<NfNitLoop> gutworth: I know hard links aren't like symbolic links, but with hard links you have two filenames pointing to the same content.
<fullermd> saedelaere: Ignore file?  Maybe I mis-skimmed what you're trying to do, but I don't see how that would fit in...
<NfNitLoop> fullermd: ah, I didn't know there were editors that did that.
<NfNitLoop> does bzr hardlink its pack files / revisions?
<fullermd> No.
<fullermd> Seems to me somebody hacked up a patch to do it once, but it's just an unpleasant idea all 'round.
<fullermd> (of course, so's linking the working tree, but...)
<meuserj> ok.. still can't figure out my problem.. but I get a bit more info from bzr info:
<meuserj> http://pastebin.com/d3202ab9d
<fullermd> What happens if you run check on the repo?
<meuserj> fullermd: on each branch which I'm having a problem with, I get this error:
<fullermd> No, not on the branch.  Just the repo.
<fullermd> I suspect the problem is a mismatch; not that something back in the ancestry went off somewhere, but that the branch is pointing at a head that's not in the repo.
<fullermd> I can think of various ways to make that happen, but they mostly involve sneaky manual poking around behind bzr's back.
<meuserj> found error:Internal check failed: revno does not match len(mainline) <some integer> != -1
<meuserj> err..
<meuserj> found error:Internal check failed: revno does not match len(mainline) integer != -1
<meuserj> and "integer" is some integer which seems to be different for every branch
<fullermd> That's expected if they're pointing at things not in the repo.
<meuserj> fullermd: I get those branch errors when I run check on the repo
<fullermd> Do an info -v on JUST the repository.
<meuserj> http://pastebin.com/d334cc377
<fullermd> OK, so it's not empty.
<fullermd> But it doesn't have any of the revs the branches are pointing at.
<fullermd> I don't know how you'd provoke that, short of manually moving stuff across the repo boundary.
<meuserj> so, how do I fix it?
<fullermd> Well, how'd you cause it?   8-}
<meuserj> I didn't.. this is happing on branches which haven't had any activity for months, and have never been moved around.
<meuserj> err happening
<fullermd> Maybe you made an interposing repository somewhere along the line?
<meuserj> interposing repository?
<fullermd> e.g., you have all these branches in /var/projects/{a,b,c}, which are using a repo in /var.
<fullermd> You make a new repo in /var/projects/
<meuserj> no
<fullermd> That hijacks the search, so it never finds or checks the repo in /var that actually has the revs.
<meuserj> everything has been in /var/projects since we created the repository years ago.
<fullermd> Mmm.  You mentioned an upgrade.  Is that recent?
<meuserj> for some of the branches I've been able to recover things by finding a separate up-to-date branch, and pushing + overwriting the branch in the central repo.. but I may not be able to find branches for older code...
<meuserj> well, I upgraded to 2.0 a few months ago.. I typically keep up to date with BZR
<meuserj> and upgrade the repository and branch formats.. since you have to
<fullermd> Maybe those branches that are having errors were (for whatever reason) not using the repo before, and something in the upgrade errored before updating their in-branch repos.
<fullermd> You sure the upgrades completed successfully?
<meuserj> I believe so
<meuserj> I would have looked at it then if I had errors
<fullermd> Are the backup.bzr/ dirs still around?
<meuserj> yeah
<fullermd> Or are they backup_bzr?  Something like that...
<fullermd> Ah, good.
<fullermd> See if any of them have a repository/ directory in them, and the current .bzr/ doesn't.
<meuserj> nope... a few have a repository directory in both
<Peng> fullermd: backup.bzr
<fullermd> If you do an 'info' on those that have it in both, do they show up as standalone, or are they still trying to use the shared repo?
<fullermd> (and is there any correlation to those that are erroring?)
<meuserj> Standalone, and no correlation
<fullermd> Grr.  I'm going to give you another opportunity to change your answer   :)
<fullermd> Anything interesting in the backup.bzr/'s of the branches having issues?
<fullermd> Is the listed head rev the same, frex?  (don't know why it wouldn't be, but...)
<meuserj> let me get a list of ones I know there are problems with and see if I can find some common ground.. hold on.
 * meuserj sighs
<meuserj> I hae 28 good branches and 34 bad ones
<meuserj> I have more that are erroring than are good.. that's not good...
<fullermd> Well, it could be good.
<fullermd> If it were just 1 branch going all stupid, you could chalk it up to the branch or repo being skr00d somehow.
<fullermd> With a bunch erroring in apparently the same way, it sounds more like some particular (and possibly reversable) problem.
<fullermd> It really sounds most like the repository the branches were using when last used isn't the same as the one currently sitting there.
<fullermd> You have the backup.bzr from that?
<fullermd> You could try restoring that in another place, and mv/cp'ing one of the failing branches into it, and see if that changes things.
<meuserj> no, but I have a backup of the repository dir.
<meuserj> bzr info -v for the good branches: http://pastebin.com/d23c5b6c6
<meuserj> bzr info -v for the bad branches: http://pastebin.com/d7b70627c
<meuserj> the reason there is no branch history data for any of the "bad" branches is that bzr crashes at that point.
<meuserj> and I didn't redirect stderr
<fullermd> Yeah, that doesn't tell anything new, it just means that it wound up asking after a revision that's not in the repo.
<meuserj> OOoo progress..
<NfNitLoop> oh?
<meuserj> I copied the entire repository to anther machine to be safe and there I restored the repository.backup file, and tested one of the broken branches, and it seems to work now.
<NfNitLoop> strange.
<NfNitLoop> so they just didn't get updated when you updated the repo format, likely?
<meuserj> maybe... I'll try upgrading it again.
<meuserj> ok.. the branches which were erroring before, seem to work now, and some of the newer branches which worked fine before are now broken in a similar way (assumingly because they have revisions which didn't exist before the upgrade)
<meuserj> if nothing else, I can branch off the broken projects from this working copy of the repository and push --overwrite them into the central repo...
<meuserj> does that sound logical?
<fullermd> Yeah, that should work.  Or go the other way; make a tmp branch in the new repo, and successively pull --overwrite all the broken ones from the old repo.
<fullermd> Doesn't answer much about how it got broken in the first place; upgrade shouldn't (doesn't, AFAI've ever seen) throw away revs.
<fullermd> But it'll get you working.  You could try experimenting with redoing an upgrade on the copy of the backup, and see if it comes up again.
<meuserj> fullermd: yeah.. my priority of course at the moment is recovering everything I can.
<igc> morning
<poolie> hi all
<lifeless> hai
<james_w> morning poolie and lifeless
<poolie> hi there
<jelmer> hi poolie, lifeless, james_w
<lifeless> hi, bye ;)
<poolie> i'm going to be offline a bit today
<poolie> so if anyone wants to talk... do it now
<spiv> Maybe we like talking to ourselves ;)
<igc> hi lifeless, spiv, jelmer, james_w
<james_w> morning people of the future
<spiv> james_w: I may be from the future, but I'm not a morning person!
<james_w> heh
#bzr 2009-12-11
<lifeless> boo!
 * fullermd spills coffee all over the keyboard.
<sysadmin2> hi - any ideas where I can ask about loggerhead please ? I'm struggling to find the homepage and wondered if it was part of bzr
<mkanat> sysadmin2: Here is the place.
<mkanat> sysadmin2: Ask and somebody will answer. :-)
<mkanat> sysadmin2: http://launchpad.net/loggerhead
<sysadmin2> thanks - I'm running it on stock karmic, it is not running from the init script - further investigation reveals I can only get it to run if I run it in the foreground with the -f switch - the same command without throws horrible errors
<sysadmin2> http://pastebin.ca/1710444
<mkanat> sysadmin2: Are you running trunk?
<mkanat> sysadmin2: start-loggerhead is really not the way loggerhead should be started.
<mkanat> sysadmin2: Better to use serve-branches if you can.
<sysadmin2> apt-get install loggerhead - I took that from the /etc/init.d/loggerhead script
<mkanat> sysadmin2: Oh, I've never used the package, I don't know what version it is.
 * mkanat actually doesn't even use ubuntu.
<sysadmin2> oh hell - thats jaunty not karmic - okay - I'll download trunk
<mkanat> sysadmin2: Okay.
<mkanat> sysadmin2: Should just be bzr branch lp:loggerhead I think.
<sysadmin2> thank you
 * igc lunch
<james_w> please help me
<james_w> I'm going mad
<james_w> http://paste.ubuntu.com/339059/
 * poolie tries
<james_w> when I run that from the command line all is good
<james_w> when I run it from cron it never returns
<poolie> !
<james_w> but doesn't throw an exception apparently
<james_w> and the processes aren't still running
<james_w> is there an equivalent to "set -x" for python?
<poolie> not really
<poolie> (that i know of) - i'd manually open a file and print things to it
<poolie> hm
<poolie> could it be that failure_dir is not absolute and it's run from a different directory?
<poolie> james_w: when you say 'never returns' do you mean the process is hung?
<poolie> what happens if you strace it then?
<james_w> the next line after that function is called is:
<james_w> sys.stderr.write("Done\n")
<james_w> sys.exit(1)
<james_w> but I never get the mail
<poolie> do you need to set MAILTO maybe?
<james_w> and I can't find any processes still running
<james_w> MAILTO is set
<james_w> if I move the exit() to the first iteration of the loop then it mails me
<poolie> oh ok
<james_w> if I remove the open() stuff then it works again
<james_w> if I only have the open stuff then it works
<james_w> but I can't see a mistake with reusing variables
<poolie> meaning if you only open it and don't read anything?
<james_w> if I just "cat" the files it works
<james_w> if I ignore the files and just do the prints with the info in the dicts then it works
<poolie> could any of the files be enormous?
<poolie> or not a regular file?
<poolie> (biab, will try to help more then)
<james_w> most are a few bytes
<james_w> the biggest might be 1k
<lifeless> james_w: whats your cron line
<lifeless> james_w: and what is failure_dir
<james_w> strace shows that everything is being printed
<james_w> it's something to do with buffering or the like
<_Andrew> Anyone know how I run a test case on a bzr plugin?
<lifeless> _Andrew: bzr selftest plugins.pluginname, if its a tes tincluded in the plugin
<lifeless> james_w: whats the total size ofoutput you are generating ?
<lifeless> james_w: and do you have HOME set ?
<james_w> HOME isn't set in crontab
<james_w> total size is not huge
<james_w> couple of thousand lines
<lifeless> my guess is that you're exceeding a buffer in whatever cron has you hooked up to
<lifeless> and so your process blocks on writing to that pipe
<james_w> but it's not still running
<james_w> */1 * * * * /bin/bash -c "/usr/bin/python /srv/package-import.canonical.com/new/scripts/categorise_failures.py 1>&2 || false"
<james_w> that's the cron line
<james_w> I wasn't sure whether it sent email only on failure, and only stderr
<sysadmin2> resolved my issue from ealier by upgrading to karmic and a later version of loggerhead - thanks all
<james_w> ok, worked around it
<james_w> just making the script send the mail itself now
<james_w> my guess is that cron didn't like some of the characters that were being output and so refused to send the mail
<poolie> could be
<spiv> Yeah, could be.  Perhaps cron runs with LANG=C or something like that that means Python won't let you write non-ascii unicode objects to stdout?
<poolie> surprising he didn't get a mail with the traceback though
<spiv> Although I'd -- yeah.
<spiv> I was just thinking that :)
<poolie> spiv, when will we enjoy your sparking wit live and in person?
<spm> yeah spiv, when???
<spiv> spm (and poolie): at the bbq, I think -- I've had some unplanned disruptions this morning and atm I'm having a bizarre compulsion to try get some work done!
<_Andrew> wth..
<_Andrew> My colleague has somehow managed to remove the same file three times in each commit he's done
<_Andrew> How's that even possible
<lifeless> james_w: or it could be you exceeded a system mail size cap
<lifeless> the canonical servers all have them, unless you get it configured to be larger.
<james_w> I'm sending the same text though
<james_w> and I could send *larger* text
<spm> spiv: for shame, tsk tsk tsk even
<lifeless> is someone picking luke up?
<poolie> igc, still here?
<poolie> is alldocs still the correct thing for the top-level doc pages?
<igc> poolie: yep
<igc> yes
<poolie> k
<poolie> just getting things restarted after escudero rearrangements
<poolie> vila, hi?
<bialix> igc here?
<poolie> hi bialix
<igc> hi bialix
<poolie> vila, hi now?
<bialix> hi all
<GungaDin> Is bzr 2 compatible with bzr1 repos?
<GungaDin> Can it still checkout from old repos?
<GungaDin> and commit?
<bialix> igc: if you have 5 minutes I can teach you about uplod translations
<spiv> GungaDin: yes
<bialix> igc: it seems your mails going to me with biiiiiiiiiiiig delay
<igc> bialix: now is bad sorry - need to run some errands before the shops close
<bialix> np
<bialix> I'll be online after 3 hours
<igc> bbl
<poolie> have a good weekend, all
<poolie> i'm off to the canonical sydney xmas party soon
<bialix> hello bzr
<bialix> igc: new pot uploaded
<igc> bialix: mega thanks
<fullermd> igc: BTW, is fast-export-from-cvs supposed to Just Work?
<igc> bialix: I'm scrambling to wrap things up here before I need to start packing for my leave
<igc> fullermd: does anything-from-cvs Just Work?
<bialix> I don't understand
<bialix> fullermd: not for me
<igc> bialix: if you get a chance to look at any recently added epxlorer bugs today, that would help
<fullermd> Well, no.  But some of them pretend to   :p
<bialix> igc: unlikely
<igc> bialix: at this point, I'm either going to package first thing in my morning (13-14 hrs from now) or not at all :-(
<bialix> igc: are you going on vacation?
<igc> bialix: yes, offline and out of the city!
<bialix> COOL!
<bialix> I can release it for you
<igc> bialix: that might be best - we can then wait a little longer for translations to get done over the weekend say
<igc> fullermd: I did plan for fast-export-from-cvs to Just Work fwiw
<bialix> so, you're free to fly away as soon as you wish ;-)
<igc> fullermd: and in a sense, *my* bit of it does
<igc> i.e. I think I wrap the underlying script successfully :-)
<igc> but cvs2bzr needs some love I believe
<igc> fullermd: I will say that the cvs2svn guys are really helpful though
<fullermd> I presume you'll need at least something to point it at a config file.
<fullermd> I hacked up a conversion manually some time ago, and I had to put together some rather obscure and sparsely-documented config file to get it to work.
<igc> fullermd: so if you need assistance, ping them, Michael Heggerty in particular is great
<fullermd> (it's nice how cvs2_bzr_ tells you "ERROR: Git output [...]" though   :p)
<bialix> fullermd: ~1.5-2 months ago I've sent mail to list with my experience about cvs2svn usage re conversion to bzr
<igc> yeah, that's gross
<fullermd> So f-e-f-c probably needs some way to pass an option through pointing at it.
<igc> fullermd: right. It's a simple patch to add that btw
<bialix> igc: enjoy your vacation :-) ping me if needed
<igc> fullermd: it never went into the initial wrapper because the underlying script used to take either options or an options file. Now isn't smart enough to support both
<igc> thanks bialix!
<bialix> anybody seen here garyvdm?
<bialix> he's offline for ~ week
<igc> bialix: bug 495003 may be a simple fix. It's happening on Windows iiuic and not on Ubuntu
 * fullermd nods.
<ubottu> Launchpad bug 495003 in bzr-explorer "Tools \ Add Tool dialog generates TypeError" [Undecided,New] https://launchpad.net/bugs/495003
<igc> bialix: I think someone needs to look at that before 0.10.0 ships
<fullermd> Just happened to steal some time tonite to fiddle with it and see what it did.
<vila> hi all
<vila> igc: Hey ! Good to see you here :)
<bialix> bonjour vila
<vila> hi bialix
<igc> hi vila!
<vila> igc: can I ask you to pilot the doc patches by neil ?
 * bialix looks at igc bug
<fullermd> Ooer, vila's up and about.  Guess that means it's time to go to bed...
<vila> igc: I've tried to review the ones I was comfortable with but except for the "chained bound branches" concepts which I think is wrong and mentioned in several patches, I just can't finish reviews
<vila> fullermd: hey !
 * bialix wonders why you guys wrote windows-specific bugs
<bialix> igc: I need your help
<igc> on phone
 * bialix waiting
<bialix> this is not windows-specific bug
<bialix> just pyqt 4.4 specific
<bialix> QComboBox.addItem (self, QString atext, QVariant auserData = QVariant())
<bialix> you put simple string instead of QVariant
<igc> vila: I'm on vacation within the hour so I won't have time to look over Neil's patches sorry
<igc> bialix: so what's the fix?
<bialix> it depends on how you want to use this data
<bialix> the fix itself is to wrap data to QVariant
<bialix> but then you need to extract this data
<bialix> where this data used?
<igc> bialix: so the combo box has nice labels and actual values
<igc> the user sees the nice (l10n) label
<igc> the data is what's returned
<bialix> yes, I see data=='bzr' and label=='Bazaar Command'
<igc> right
<bialix> where the data used later?
<igc> get_tool() looks up the value
<igc> no where else
<bialix> igc: change line 64 to             combo.addItem(label, QtCore.QVariant(data))
<bialix> can you test that everything works?
<bialix> I'm not sure yet how to use this new feature
<igc> bialix: I can't test it on pyqt 4.4
<bialix> test on your own
<bialix> it should work on any pyqt
<igc> bialix: to test the feature, put in some random data and check BZR_CONFIG/explorer/tools.xml has a new entry
<igc> i.e. .bazaar/epxlorer/tools.xml on ubuntu
<bialix> it seems work for me
<bialix> I'll push the fix
<igc> bialix: works for me too
<bialix> thx
<igc> bialix: btw, after adding a tool, it should appear on your Tools menu and in your Toolbox
<bialix> igc: can you prepare announce mail draft for me?
<igc> bialix: sure do later tonight
<igc> shall
<bialix> igc: pushed
<igc> bialix: thanks!
<bialix> without your help this fix won't be so quick ;-)
<bialix> igc: btw, fyi, I'm thinking about writing standalone app for explorer
<bialix> maybe on xmas vacation
<igc> to drop the dos box?
<bialix> yep
<igc> that would rock. dos box yells "non-professional" to me :-(
<bialix> this black hole/console is annoying
<bialix> yep
<bialix> I just need to figure out where to redirect all this junk bzrlib tends to drop on stderr (and stdout sometimes)
<bialix> e.g. when ssh connection established et al
<vila> bialix: the easy-don't-think-too-much-about-it will be to have some console for bzr-explorer that can be opened on demand, where you drop the whole content of stdout/stderr
<vila> like many ftp/sftp clients do for example
<bialix> that's my intent, just need to convert it to code and see how it will work
<LeoNerd> bzr-svn++ # I just  bzr merge svn+ssh://'ed and it JustWorked
<LeoNerd> And bzr even knows its a merge in log10.. Hrm.. I wonder how that happens
<bialix> magic
<LeoNerd> Mmm... Well.. since I don't understand it, Clarke says it must be magic :)
<Kamping_Kaiser> how does one debug a _slow_ bzr upload problem?
<vila> Kamping_Kaiser: what is your remote server ?
<vila> Kamping_Kaiser: ftp or sftp ?
<vila> Kamping_Kaiser: by upload you mean the bzr-upload plugin or a regular bzr push ?
<Kamping_Kaiser> vila: remote version? I don't know (i didn't set it up). using sftp.
<Kamping_Kaiser> vila: and i was refering to bzr-push, its doing 1-2Kb/s
<Kamping_Kaiser> s/-/ /
<rubbs> good morning every one.
<Kamping_Kaiser> i'm not sure whats caused it - it was either upgrading from the bzr in debian stable, or the repo getting converted from unique branches into a shared repo (which i think is the current situation)
<vila> Hmm, that's highly unusal... unless you have a very high latency or are using a very old format
<vila> hi rubbs
<vila> what does bzr info <remote_url> says about the format and the branch/repo relationship ?
<vila> Kamping_Kaiser: debian *stable*, what bzr version is that ?
<Kamping_Kaiser> vila: shall i pastebin it?
<vila> s.that.there.
<vila> Kamping_Kaiser: sure
<vila> !paste
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from  command line | Make sure you give us the URL for your paste - see also the channel topic
<Kamping_Kaiser> vila: currently using 2.0 from backports, i forget what stable ships by default
<vila> ha, good, I had a horrible doubt about you using 1.12 or something :-)
<Kamping_Kaiser> hehehe
<Kamping_Kaiser> vila: http://pastebin.com/f717e494a
<vila> no offense implied though, it's just that the problem would have been totally different
<Kamping_Kaiser> i've had issues with debians default bzr before, so no offence taken.
<vila> format: unnamed, bad juju
<vila> either the repo or the branch may not have been upgraded
<vila> try bzr info -v sftp://kgoetz@bzr.savannah.nongnu.org/srv/bzr/gnewsense/
<Kamping_Kaiser> http://pastebin.com/f646ece25 this appears to know what it is
<vila> good
<vila> you may want to try an upgrade of the branch then
<vila> it should be fast, really fast since you use a shared repo
<Kamping_Kaiser> thelocal branch?
<vila> the remote one
<vila> I don't know how the upgrade was done there, but it seems that only the repo  has been upgraded (at least that's my understanding)
<Kamping_Kaiser> hm. I'll have to get someone to look at that.
<Kamping_Kaiser> vila: thanks for your help :)
<vila> Oh, and you want to check what format you use locally, cross-format conversions are still slow
<vila> Kamping_Kaiser: you're welcome, feedback appreciated if you solve the problem !
<vila> and more help available if you don't :)
<Kamping_Kaiser> ok. so local tree is rich-root-pack, shared repo with trees is ormat 2a - are you saying i should upgrae my checkout to match teh shred repo?
 * Kamping_Kaiser tries it
<vila> Kamping_Kaiser: yes
<vila> what does 'bzr info -v' says locally ?
<Kamping_Kaiser> vila: beofre or after upgrade?
<vila> now
<Kamping_Kaiser> http://pastebin.com/f49fe8c18
<vila> you mean you did upgrade in the last 2 minutes ?
 * Kamping_Kaiser wonders how he lived before pastebinit
<Kamping_Kaiser> yes
<Kamping_Kaiser> hang on and i'll give you before upgrade too
<vila> right, so you use a standalone branch not a 'checkout'
<Kamping_Kaiser> http://pastebin.com/m9ba9455 pre upgrade
<Kamping_Kaiser> yeah. my branch predates the move to shared repo
<vila> right, try again, things should go better and faster
<Kamping_Kaiser> woot.
<vila> you may not even need to upgrade the remote branch, but I think it's worth checking what happened there
<Kamping_Kaiser> I don't have anything to hack at the moment, so it'll have to be another day. I'll let you know how it goes
 * Kamping_Kaiser takes his headache to bed ;)
<vila> ok
<Kamping_Kaiser> thanks again, I'll hunt you down if it works and thank you :D
<vila> hehe, take care of your headache !
<jam> igc: go enjoy your vacation :)
<jam> morning vila, bialix, et al
<bialix> heya jam!
<vila> Goood morning jam
<rubbs> morning jam
<igc> thanks jam!
<igc> jam: those fastimport patches look fine btw. Merge away ...
<igc> night all. I'll offline now for a week plus.
<jam> igc: have a great vacation
<igc> shall do!
<bialix> igc: you don't forget about me?
<igc> bialix: I trust you to write a nice summary from the NEWS :-)
<bialix> rats
<bialix> so, enjoy!
<igc> bialix: I didn't forget - just too sleepy sorry!
<bialix> :-)
<rubbs> igc: doing anything special for vacation?
<jam> rubbs: not hanging around here :)
<rubbs> jam: haha fair enough.
<abentley> jam: Launchpad's test suite checks to make sure garbage isn't left behind.  On one machine, it's now complaining about _LockWarner, but the other is happy.  Any thoughts what would cause this?
<jam> abentley: I'm trying to track some of that stuff down myself. _LockWarner can generally only trigger in a thread, because we run with -Werror (so if it triggers in the main thread it fails PQM)
<jam> when you say "garbage" you mean data on stderr?
<jam> my experience on this so far is single-cpu machines have issues cleaning up resources on secondary threads in a timely manner.
<abentley> jam: No, I mean that it has an entry in gc.garbage, i.e. it's not garbage-collectable.
<jam> ah
<abentley> jam: It is collectable if I disable the __del__, but that defeats the purpose, of course.
<jam> abentley: right, and _LockWarner is meant to hang of of an open lock and never be in a ref cycle
<abentley> jam: And of course, they should be equivalent machines (dual-core x86-64/emt64)
<jam> abentley: you could try something like this: http://paste.ubuntu.com/339283/
<jam> and see if anything is assigning to LW that shouldn't be
<abentley> jam: I've added the slots, but I don't understand the second part.
<jam> 'understand the second part' ?
<jam> The idea is if you have slots and someone assigns to _LockWarner.foo = bar
<jam> it will fail
<jam> rather than allowing a refcycle
<jam> is it possible to inspect the LW class that is left in gc.garbage?
<jam> or is it only reproducible on a machine you don't have direct access to?
<abentley> jam: I see.  Well, it's not failing.
<abentley> jam: It is possible to inspect the LW class in gc.garbage.  What should I look for?
<jam> abentley: well, it is in gc.garbage because it is in a refcycle and has __del__ right?
<jam> So you need to find the attribute that is causing the refcycle
<jam> without __slots__ then doing "pp LW.__dict__" should give you an idea
<jam> (with __slots__ there is no __dict__ attribute)
<abentley> jam: pp lw.__dict__
<abentley> {'lock_count': None,
<abentley>  'repr': 'LockableFiles(<bzrlib.transport.chroot.ChrootTransport url=chroot-121047632:///~person-name9/product-name4/branch11/.bzr/repository/>)'}
<abentley> jam: If there were live objects that referred to the LW, it wouldn't be in gc.garbage, right?
<abentley> jam: gc seems to think that the LW doesn't refer to anything uncollectable: http://paste.ubuntu.com/339310/
<abentley> jam: And note that the lock count is None.  This implies that it's been locked and unlocked, because it's initialized to 0, not None.
<jam> abentley: well, repr is a string and  lock_count is None, I don't see how it could be in a reference cycle
<jam> unless maybe the class itself is referencing the object?
<abentley> jam: yeah, me neither.
<jam> can you check the references from bzrlib.lockdir._LockWarner ?
<jam> or gc.get_referents(gc.get_referents(gc.garbage[0])[-1])
<jam> (should be the same thing)
<jam> and what does sys.getrefcount say?
<jam> hmm... looking at http://docs.python.org/library/gc.html
<jam> it looks like if gc thought it was once in a refcycle
<abentley> jam: http://paste.ubuntu.com/339321/
<jam> it would go into gc.garbage
<jam> and never come out
<jam> even after that cycle was fixed
<abentley> jam: sys.getrefcount(gc.garbage[0]) returns 2
<jam> http://docs.python.org/library/gc.html#gc.garbage specifically
<jam> abentley: right, that means that gc.garbage is the only thing referring to this object now
<jam> priority on *now*
<abentley> jam: Okay, so if I follow the instructions and del gc.garbage[:], and then gc.collect, the list is empty.
<jam> right
<jam> from reading the docs, it sure looks like at some point LockWarner was referring to itself when gc.collect() ran
<jam> oh, or it was part of some bigger cycle
<jam> you know, it could have been in something like a comprehension
<abentley> jam: I think this means that the test infrastructure is broken.  Do you agree?
<jam> so, trying to read fully
<jam> it sounds like if LW was in a refcycle with other code that didn't have __del__
<jam> only *it* would get put into the garbage
<jam> "By default, this list contains only objects with __del__() methods."
<jam> the key is also this part:
<jam> " including objects not necessarily in the cycle but reachable only from it."
<jam> so if we have a cycle, and hanging off of that is this class with __del__ it could get put into gc.garbage
<jam> which is a bit broken in python, if you ask me
<jam> of course, you can't fix python for your test suite :)
<jam> you might try running with: DEBUG_SAVEALL
<jam> ?
<abentley> The test infrastructure wants to know if we've left anything uncollectable behind.  It seems to me that we haven't left anything uncollectable behind.
<jam> abentley: but it may have been uncollectable at some point, which then gets cleaned up by the time you investigate...
<abentley> jam: True, but my point is that the test infrastructure is buggy, and presumably the way to fix it is to either disable automatic garbage collection during the test run or to do this del gc.garbage[:] thing.
<abentley> jam: I assume if it was actually uncollectable, it would get put back into gc.garbage?
<jam> abentley: I'm willing to write a test to find out :)
<jam> abentley: You seem to be correct, I'll paste
<jam> abentley: http://paste.ubuntu.com/339330/
<jam> so doing "del gc.garbage[:]; gc.collect()" does, indeed, seem to restore things that are still in cycles
<abentley> jam: cool.
<abentley> jam: So what's odd here is that I've disabled the gc before running the test.  After the test, gc.garbage is [].  Then I call gc.collect, and it adds the lock warner.
<jam> abentley: well, disabling gc means that nothing will get put into gc.garbage as gc.collect is never running
<abentley> jam: So it seems there's a cycle, but python fixes it.
<jam> yeah
<jam> it does seem a bit odd
<abentley> jam: It means that there was a cycle after the test exited.
<jam> if you go back to: http://docs.python.org/library/gc.html#gc.garbage
<abentley> jam: at least, AFAICT.
<jam> if DEBUG_SAVEALL is not set
<jam> then it only puts the objects with __del__ into the garbage
<jam> and goes ahead and deletes the rest
<jam> which may be breaking the cycle somehow
<jam> you might try running with
<jam> gc.DEBUG_SAVEALL = True
<jam> gc.collect()
<jam> or something like that
<jam> I should mention that pyrex/C objects get a _dealloc() function which doesn't block the garbage collector
<jam> and can run actions at deconstruction
<jam> so if LockWarner was in a cycle with an extension class, the extension class may break the cycle in its deconstructor
<abentley> Actually, I believe DEBUG_SAVEALL is a flag you pass into gc.set_debug()
<abentley> jam: Oh, this gets better and better: repr(gc.garbage)
<abentley> *** UnicodeEncodeError: 'ascii' codec can't encode character u'\u02bb' in position 20: ordinal not in range(128)
<jam> probably a case where an object is returning a Unicode from __str__
<jam> which we've been guilty of in the past
<jam> (and may still be guilty of...)
<jam> well, tries, I think it forcibly casts the return  from __str__ to a str
<abentley> jam: So with SAVEALL, there are 39 LockWarners in gc.garbage.
<Calvin1602> Hi ! I'm experiencing a proxy problem with tortoiseBzr
<jam> strange
<Calvin1602> bzr: ERROR: Connection error: while sending OPTIONS /inkscape/: (10061, 'Connection refused')
<jam> Calvin1602: how are you setting your proxy?
<Calvin1602> ( the URL was https://launchpad.net/inkscape )
<Calvin1602> Well, I don't, my question is how do I do it :)
<jam> well, https://launchpad.net/inkscape isn't an actual branch
<jam> bzr branch lp:inkscape would probably work better for you
<Calvin1602> The user manual is very poor about that, especially for Windows
<Calvin1602> nope
<Calvin1602> tried it
<Peng> jam: That should work as a branch, though. (There's a reference.)
<Peng> I think.
<jam> so, setting a proxy is generally setting "HTTP_PROXY" environment variable.
<Peng> jam: Yeah.
<Calvin1602> http ?
<jam> Peng: I think the problem is some issues with bzr-svn trying to send OPTIONS and it getting caught in a auto-proxy
<Calvin1602> not https ?
<jam> but not sure
<Peng> jam: Yeah, probably. I was just sayin'.
<jam> Calvin1602: https:// is used by launchpad for serving lp pages, but not for bzr branches
<jam> you could also try
<jam> bzr branch http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/
<jam> if you want to go directly to what everything will eventually redirect you to
<Calvin1602> ok so I've set the HTTP_PROXY trough Windows+Pause, and ran bzr branch lp:inkscape
<Calvin1602> guess what, bzr crashes
<Calvin1602> want the stack on patebin ?
<Calvin1602> http://pastebin.org/63578
<Calvin1602> on the other hand, bzr branch http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/ gave a much nicer error :
<Calvin1602> bzr: ERROR: Invalid url supplied to transport: "proxy.insa-rennes.fr:8080": No host component
<Tak> does it work if you prepend "http://" to your proxy ?
<Calvin1602> it does indeed, thanks :)
<Calvin1602> Any idea why lp:inkscape makes it crash ?
<Tak> no clue
<jam> Calvin1602: we send an xmlrpc request to a different location
<jam> what version of bzr?
<jam> 2.0.2... probably doesn't have the xmlrpc supports proxies
<jam> fix
<Calvin1602> very last one, downloaded 1 hour ago
<Calvin1602> 2.0.2, yeah
<jam> yeah, looks like: bug #186920
<ubottu> Launchpad bug 186920 in bzr "bzr xmlrpc client doesn't use http proxy, causing network errors trying to resolve lp: urls" [High,Fix released] https://launchpad.net/bugs/186920
<jam> the bzr 2.1 series has a fix for it
<jam> since 2.1.0b2
<Calvin1602> Is there a windows installer for it ?
<jam> yep
<jam> Calvin1602: https://edge.launchpad.net/bzr/2.1/2.1.0b3
<jam> or the direct link: http://edge.launchpad.net/bzr/2.1/2.1.0b3/+download/bzr-2.1.0b3-1-setup.exe
<Calvin1602> Well, in fact, I can't use it right now. I'm not on my own computer, the network admin is away, so i'll have to live without it for the weekend
<Calvin1602> So, hopefuly my last question : how do I convert a lp: adress to a https:// adress ?
<Calvin1602> I have a project on launchpad. I'm told to use lp:~arnaud1602-gmail/sffs-sandbox/trunk , but as I said, I can't use it
<Calvin1602> ( and, btw, I will need push privileges on it, so I guess https is needed instead of http ? )
<Peng> Calvin1602: No, bzr+ssh (or sftp) is needed.
<Peng> Calvin1602: Well, for pushing.
<Peng> Calvin1602: Unless you're arnaud1602-gmail, you can't push to *that* branch, just your own branches (and those of teams you're in).
<Calvin1602> I am arnaud1602
<Calvin1602> and I want to push back tu launchpad
<Calvin1602> to*
<abentley> jam: Thanks for the help, but my brain is gonna explode.
<jam> abentley: no problem, it would seem that just doing "gc.collect(); del gc.garbage[:]; gc.collect()" may be sufficient for what you need
<jam> Calvin1602: you need an sshkey
<jam> and then you can do "bzr lp-login arnaud1602-gmail"
<jam> and it will connect via bzr+ssh instead of via http
<abentley> jam: Yes, though the right place for that is the zope test runner, which is more work to patch.
<jam> abentley: could you do the first part in tearDown ?
<jam> (gc.collect(); del gc.garbage[:])
<jam> It is a bit hackish
<jam> but it may wokr
<jam> work
<abentley> jam: Yeah, I can do that as part of the cleanup, though it would reduce performance a bit.
<abentley> jam: I'm still unclear whether there's a bug in python's garbage collector.
<jam> not very clear here either
<jam> and the randomness of it triggering is also unfortunate
<cody-somerville> http://launchpadlibrarian.net/36654571/live-helper-trunk-log.txt <-- Can anyone help me with this import error?
<NEBAP> hi
<NEBAP> is there a document describing the current file format of bazaar?
<phoenixz> With bzr st -S, what is the difference between +N and + ?
<phoenixz> Because it seems that sometimes when I bzr add, the file has status + and sometimes the file has status +N but I can't find what the difference is
<NEBAP> is there any document which tells me how a bazaar repository should be read?
<NEBAP> i just wanted to add native read support for bazaar in non python code ..
<NEBAP> but I couldn't find any documents about the file format
<Peng> NEBAP: That's, uh, not simple...
<NEBAP> :(
<Peng> phoenixz: I think that stuff is documented in bzr.dev now.
<NEBAP> I already talked to a developer (sorry couldn't remember the name) and he pointed me to the sources
<NEBAP> but reading the sources for someone that isn't into the project is ... really hard ;)
<phoenixz> Peng: bzr.dev?
<Peng> phoenixz: lp:bzr
<phoenixz> Peng: sorry, what?
<Peng> phoenixz: "the trunk". "The development version". Whatever.
<NEBAP> Peng: the problem is that there is no bazaar support for shared hosts (web interface)..
<phoenixz> Right..
<Peng> NEBAP: You *can* run Loggerhead with FastCGI, etc. Probably.
<Peng> NEBAP: Not that your average shared host has the rAM for it....
<NEBAP> Peng: so I need a solution for shared hosts, and I think many others would also appreciate a working solution
<Peng> phoenixz: Hmm, I was wrong. I take back what I said.
<Peng> phoenixz: I don't know the answer, sorry. :\
<phoenixz> Peng: well, honestly, I didnt get the answer anyway...
<NEBAP> what kind of documentation is used by the developers? Are they just using the source??
<NEBAP> I know the file format is very tricky, but I thought it should be possible to just read from it ...
<CaptTofu> hi, does anyone know why bzr/lp is broken like this: http://pastie.org/739518
<CaptTofu> I upgraded bzr to 2.0.2, and still no go
<beuno> CaptTofu, looks like a bug
<beuno> could you please file it?
<dOxxx> NEBAP: you  may get a better response if you ask on the bzr mailing list
<dOxxx> NEBAP: or ask a question here: https://answers.launchpad.net/bzr/+addquestion
<NEBAP> dOxxx: thanks, I posted a question on launchpad: https://answers.launchpad.net/bzr/+question/93740 (hope my english is ok ..)
<Tak> NEBAP: it's great
<NEBAP> Ta: what? the english??? you making fun of me ^^
<rubbs> NEBAP: I had no problem understanding your question. Unfortunately, I don't know the answer to it :(
<NEBAP> rubbs: no problem ;)
<NEBAP> thanks
<NEBAP> hopefully there is such a document ;)
<NEBAP> making bazaar repositories be accessible on shared hosts would be great ;)
<Tak> NEBAP: your english was very good, and I'm not making fun of you
<NEBAP> Tak: thanks :)
<NEBAP> good night, I'm leaving for today ;)
<eric_f> Is it possible to have multiple branches in the same working dir? I would like to have trunk, feature1, and feature2 branches in my one working dir and be able to switch between them. You can do this with Git, I was curious if you can with Bzr?
<rubbs> eric_f: I'm not 100% sure, but I believe bzr switch can do what you want
<rubbs> eric_f: 'bzr help switch' it gives a discription. see if that's what you're talking about
<eric_f> I guess I should rephrase, I want to have multiple local branches that are NOT published to a central server. I would like it if these branches and their data all existed in my working dir
<eric_f> â¦I can publish to the central server if it's not possible, or a seperate-from-my-working-dir folder to hold all my local feature-branches
<zsquareplusc> eric_f: it's typical to have a separate directory for each branch. but you can make a shared repo so that the history does not need to be multiple times on your disk
<dOxxx> eric_f: something like this? http://doc.bazaar.canonical.com/developers/colocated-branches.html
<eric_f> in Git you don't need a separate dir for each branch
<rubbs> eric_f: not trying to say it can't be done (yet) but is there any reason to keep it all in the same working tree?
<dOxxx> eric_f: the answer is that it's being contemplated but not currently possible
<dOxxx> eric_f: the clsoes you can get is to create a shared repository with tree-less branches and a single working directory that is a lightweight checkout of a branch, and then you use 'bzr switch' on the checkout to switch between branches
<dOxxx> closest*
<eric_f> dOxxx: that looks like it
<eric_f> dOxxx: yeah, I guess that makes sense to do for now
<eric_f> rubbs: because I want to do all my bzr commands in one place
<rubbs> eric_f: cool, np. I was just curious
<dOxxx> eric_f: if co-located branches become possible in the future, I'm quite certain that you'll be able to migrate your stuff to it
<eric_f> rubbs: I don't want to have to commit in my working dir, which commits to my local branch, which then I have to cd into and push up to the server
<rubbs> xnox: I don't believe it can show a ascii DAG. I may be wrong, but I don't think it can. (unless it's some hidden feature I didn't know about).
<rubbs> xnox: just check some help files, and I'm pretty sure that it can't give you an ASCII DAG. sorry.
<Pilky> anyone around interested in seeing/giving feedback on some mockups I've done for improvements to launchpad?
#bzr 2009-12-12
<magcius> [###################-] 199212KB   183KB/s | Fetching revisions:Inserting stream:Walking content 8911/8911
<magcius> It's been doing this for about a half an hour now.
<ronny> hi
<ronny> what could case bzr to yank 'No handlers could be found for logger "bzr"'
<ronny> also lots of logging messages
<jelmer> ronny, hi
<jelmer> ronny, IIRC there is a logging setup function you can call to have it log to ~/.bzr.log
<jelmer> or you can set up something custom to handle logging
<ronny> jelmer: this is invoking the cli
<jelmer> ronny: Is ~/.bzr.log perhaps not writable?
<ronny> inded, it was write protected
<ronny> now stuff is fine
<timeless_mbp> hello world
<timeless_mbp> http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#rename-tracking-and-smart-merging
<timeless_mbp> is there someone here i can talk to about that section?
<timeless_mbp> specifically:
<timeless_mbp> > not something than can exist and be tracked independently.
<bob2> just ask
<ronny> timeless_mbp: i suppose you refer to the fact that the statement is a blunt lie?
<timeless_mbp> ronny: nah
<timeless_mbp> it's grammatically incorrect
<timeless_mbp> 'than' should be 'that'
<timeless_mbp> i sent an email to the author with a list of errors
<timeless_mbp> lying is fine
<ronny> oh, heh
<timeless_mbp> as long as you don't have any errors in your lies
<ronny> please never fix the bible
<timeless_mbp> the bible doesn't lie ;-)
<timeless_mbp> so no need to worry about fixing it :)
<ronny> timeless_mbp: its not even consistent in itself
<timeless_mbp> sure
<timeless_mbp> but it's a series of stories, not lies :)
<timeless_mbp> and surely this is at least a bit offtopic for #bzr
<ronny> heh
<_habnabit> If I have a file and I'm trying to split it into multiple files, is there any way to keep the revision history in the new files?
<timeless_mbp> copy it x times?
<_habnabit> Hmm, that would do it.
<timeless_mbp> then replace each w/ the portion you want
<bob2> alas there is no bzr cp
<timeless_mbp> i'm just a hacker, no idea if there's a more correct way in bzr
<timeless_mbp> really?
<_habnabit> Oh.
<_habnabit> Well.
<timeless_mbp> http://wiki.bazaar.canonical.com/BzrFileCopies
<_habnabit> Looks like it's not implemented.
<timeless_mbp> _habnabit: well, it'd work in mercurial ;-)
<timeless_mbp> sorry :(
<_habnabit> That page also describes that mercurial has inconsistent behavior when copying files. ;D
<_habnabit> I'm guessing this means I can't preserve my revision history. Dang.
 * timeless_mbp couldn't really parse their paragraph there
<timeless_mbp> so
<timeless_mbp> i don't think i find mercurial's behavior there odd
<timeless_mbp> nor for that matter did pierre having read hgbook afaict based on the remainder of the paragraph
<timeless_mbp> roughly speaking, if you rename a file, you've broken your relationship to the original file
<timeless_mbp> and if you need to get the merge behavior, you'd just work from a changeset which doesn't have the rename
<timeless_mbp> but... it's irrelevant to you, as you couldn't do anything useful anyway
<timeless_mbp> you're taking a file and splitting it
<timeless_mbp> you're not going to be able to get a useful behavior from renaming the original unsplit file
<timeless_mbp> anyway... have fun
#bzr 2009-12-13
<wgrant> Is there a nice bzr viz-ish tool around that will show me several branches in one revision tree? I've got a set of inter-related branches from a couple of months ago that I'd really like to see the relationships between.
<lifeless> bzr viz has some stuff to do that, and I think qlog can to
<lifeless> failing that: bzr merge --force them all together, do a single commit, and then use bzr viz :P
<wgrant> I considered that last option.
<wgrant> i tried qlog, but it seems to have hung.
<wgrant> But maybe it's just processing 70000 LP revs.
<geartrooper> hello, is it possible to lock a folder in ubuntu for a bzr repo that friends can only see the folder?
<cody-somerville> geartrooper, pardon?
<geartrooper> ty for responding cody-somerville.  Is it possible to use my machine for a repo and have friends use only the repo folder?
<cody-somerville> geartrooper, for read only or read and write operations?
<geartrooper> read and write
<cody-somerville> Yes its possible but requires setup.
<geartrooper> is there a tutorial for such cody-somerville
<cody-somerville> geartrooper, Have you considered using launchpad.net to host the branches?
<cody-somerville> geartrooper, https://launchpad.net/+tour/branch-hosting-tracking
<geartrooper> I have
<cody-somerville> If you could share with me why you didn't find it a suitable option it'll help me understand what your needs are.
<geartrooper> well, I am using bzr for a secret gaming project.  I would like to keep the assets hidden from potential players.
<cody-somerville> Launchpad offers commercial subscriptions but I take it you've already evaluated and ruled that option out for whatever reasons?
<geartrooper> that assumption would be correct
<cody-somerville> An alternative to setting up a restricted file server on your personal machine is to use a distributed development model.
<geartrooper> please elaborate
<cody-somerville> Certainly.
<cody-somerville> geartrooper, http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/bazaar_workflows.html
<wgrant> lifeless: qlog eventually worked (but hung for a looooong time). thanks.
<geartrooper> cody-somerville, does centralized run the risk of a changing ip address on desktop machines?
<cody-somerville> geartrooper, depends on your internet connection. Most residential connections have a dynamic (ie. changing) ip address.
<geartrooper> crud
<lifeless> wgrant: file a bug
<geartrooper> well, launchpad will work fine, we'll just have to be smart.  cody-somerville thank you very much for your help and best wishes on the project
<lifeless> geartrooper: you can by an lp subscription
<lifeless> geartrooper: which will let you make your branches private and only accessible to folk you choose
<geartrooper> noted
<geartrooper> thankyou guys very much.
<cyberix> What is "the gui" for bzr in Ubuntu?
<bialix> hello
<bialix> anybody here remember old baz?
<jelmer_> not really
<bialix> evening jelmer
<jelmer> hey bialix
<jelmer> congrats on the new bzr-explorer
<bialix> do you know maybe, mainline idea is specific for bzr or it comes from baz/arch?
<jelmer> no idea, sorry
<bialix> jelmer: thanks, but all congrat belongs to igc
 * bialix writing blog article about 1 branch is 1 directory
<mjg> hello.  is it possible to configure loggerhead to allow commits?
<mjg> (ie not just be read only)?
<jelmer> mjg: Not that I'm aware of
<mjg> OK - so how to have a read/write repo accessed over http?
<mjg> is it possible?
<jelmer> Yeah, I'm pretty sure it is possible
<jelmer> Unfortunately I don't have any experience with it myself
<mjg> :) thanks
<mjg> it's quite frustrating trying to get it set up
<bialix> mjg: read about bzt+http
<bialix> mjg: also there is webdav plugin
<bialix> *bzr+http
<mjg> gotcha
<mjg> OK: I have run  bzr serve --directory=/home/tapir/bzr/ on my repo server
<mjg> on the client machine I can run  bzr branch bzr://tapir:4155/myProject/trunk and get a working copy no problem
<mjg> but if I try  bzr branch bzr+http://tapir:4155/myProject/trunk I get errors
<mjg> do I need to start the server differently to use the client like this?
<NfNitLoop> I'm not sure what bzr+http:// means.   bzr:// is for bzr serves, and http:// is for a bzr directory served via HTTP.
<mjg> OK - I am still a bit confused, but if I try  bzr branch http://tapir:4155/myProject/trunk I still get an error
<mjg> which is: bzr: ERROR: Invalid http response for http://tapir:4155/myProject/trunk/.bzr/branch-format: Bad status line received
<NfNitLoop> well, bzr serve isn't http.
<NfNitLoop> It's its own protocol.
<mjg> OK - I see
<mjg> slowly
<NfNitLoop> so you wouldn't expect that to work.
<mjg> I thought the "smart" of the "smart server" would allow that to work
<NfNitLoop> No, the "smart" of the smart server is that it can do some of the work of picking which revisions to send you.
<NfNitLoop> instead of your client having to poke around, say, and HTTP share and find them.
<NfNitLoop> an* HTTP
<NfNitLoop> and I'm sure there's other stuff too, I'm not one of the developers.
<NfNitLoop> But generally with your own custom protocol, you can make things go faster than trying to do it over HTTP. :)
<mjg> sure :) but I have a strict firewall to contend with
<NfNitLoop> ah.   Does that firewall allow you to ssh?
<mjg> so I'd like to be able to checkout & commit over http
<mjg> no
<NfNitLoop> Hrmm.
<mjg> it is port 80 only, so I'd like to run bzr over http and use apache as a reverse proxy
<NfNitLoop> You can check-out via HTTP by just putting your project in a directory that's servable via your HTTP server.
<mjg> yes, but then I can't check it back in
<mjg> :(
<NfNitLoop> correct.
<NfNitLoop> you could check in locally, though, and then pull up to there via HTTP.
<mjg> if I could ssh to the remote server, you mean?
<NfNitLoop> Yeah.  I imagine you have *some* way of connecting to it if you're getting files onto it in the first place.
<mjg> if I go to another building and use the terminal, yes
<NfNitLoop> maybe it's not the best place to store your branches, then.
<mjg> perhaps not.  I want to store my repo on my home computer then be able to checkout, work, and checkin again from a pc in my lab at work.  But work has a horrid firewall which doesn't allow me to ssh into home.
<mjg> so I thought I could run a read/write bzr server over http
<mjg> but it doesn't seem possible, from what I am finding
<NfNitLoop> You can only read bzr over HTTP at the moment.
<mjg> oh,  then I am going to have to remember to carry my usb-key with me all the time then
<NfNitLoop> That works.
<mjg> until I lose it :o)
<NfNitLoop> put it on your keychain. :)
<mjg> well I guess I could run the standard bzr serve on port 80
<mjg> but what about security?
<mjg> the advantage of running over http is to put t behind an apache proxy that uses http-auth
<NfNitLoop> at that point, why not run ssh on port 80? :)
<NfNitLoop> http-auth isn't very secure, all your passwords go over plaintext.
<mjg> yy
<mjg> good points, all
<mjg> I'll have to think this through.  thanks for your help
<jelmer> jam, lifeless: around?
<thumper> morning
<jelmer> hi thumper
<thumper> jelmer: have the branch stalled for bzr-hg into LP?
<jelmer> thumper: it's waiting for some changes to the database schema
<jelmer> jam: ping
<lifeless> jelmer: ?
<lifeless> NfNitLoop: you can write over http, just use the wsgi service
<lifeless> mjg: ^
<jelmer> lifeless: I'm playing with using indexes for the shamap in bzr-git
<jelmer> lifeless: but I was having a hard time finding a helper class to do my directory management for me
<jelmer> lifeless: just sent an email to the list about this
<lifeless> the simplest example I know of is inbzr-search
<lifeless> I haven't factored out a just-help-this class yet
<lifeless> I want to write a flexible schema package built on these concepts
<lifeless> I've even got a name :P but no substantial code
<NfNitLoop> lifeless: Oh, huh.  Sorry, thought I saw someone in here the other day saying that HTTP didn't support writes.
<lifeless> plain http with no smart server or webdav doesn't
<lifeless> http with webdav
<lifeless> or bzr+http (which just needs the server configured)
<lifeless> do
<jelmer> lifeless: yeah, such a class would be neat - I don't feel like reimplementing this behaviour in bzr-git, bzr-svn *and* bzr-hg :-)
<NfNitLoop> guess I've got some reading to do. :)
<_habnabit> If I have a file and I'm trying to split it into multiple files, is there any way to keep the  revision history in the new files?
<jelmer> _habnabit, at the moment, no
<_habnabit> Dang.
<_habnabit> It sounds like it's a planned feature, though.
<_habnabit> (And this is probably a subset of allowing versioned copying. Is there an open ticket for that?)
<jelmer> _habnabit, there is a spec, not much more than that
<_habnabit> Aha.
<poolie> good morning
* poolie changed the topic of #bzr to: Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Patch pilot: ??
<jelmer> 'morning poolie
<poolie> hi jelmer
<poolie> how's soyuz going for you?
<jelmer> poolie: fun :-)
<jelmer> I've landed 7 branches so far, though almost all for trivial things
<poolie> great
<poolie> well, you need to get your feet wet
<jelmer> poolie: Also, http://jelmer.vernstok.nl/blog/archives/244-My-first-week-as-a-Launchpad-developer-impressions.html
<poolie> that's good that reviews and questions are quickly answered
<poolie> and re karmic, as you probably know, it's a conscious tradeoff decision
<jelmer> poolie: yeah, I realise that - it's still something I ran into though
<poolie> iwbni it worked in more places but i think the external version dependencies are quite tight
<poolie> still worth mentioning
<poolie> we should add you to planet launchpad?
<jelmer> that'd be great, I wasn't aware there was such a thing :-)
<lifeless> jelmer: you could patch pilot too :P
<poolie> ooh
<poolie> i was just wondering who should do it next
<poolie> also you are on our planet, but it's apprently not updating
<jelmer> poolie: it was only posted a few minutes ago, I had forgotten to set it to Published in serendipity
<jelmer> lifeless: yeah, I guess I should at some point...
<lifeless> jelmer: why delay, pilot today
<jelmer> lifeless: lack of spare time at the moment :-(
<jelmer> lifeless: Wait, did I just see you quit IRC for a second?
<lifeless> bouncing irssi because of freenodes retarded behaviour on channel joins before auth
<fagan> Hey all I have a small problem with bzr in lucid anyone around to figure it out with me?
<jelmer> hi Shane
<jelmer> fagan: what is the problem?
<fagan> jelmer: hang on ill get you a pastebin of the message
<fagan> http://pastebin.ubuntu.com/340831/
<fagan> I have my pub key set and imported to launchpad but I still get the error
<Peng> fagan: Is that with Launchpad?
<Peng> Ah.
<fagan> yep
<Peng> Well, apparently you don't. :P
<Peng> Are you sure it's the right key? Did you paste it properly?
<fagan> Yep
<fagan> Synced the key
<fagan> then copyed the fingerprint and confirmed it
<Peng> The fingerprint? Not the id_rsa.pub file?
<fagan> When you sync your key all you have to do is give the fingerprint
<fagan> bzr didnt ask for my password though
<fagan> Could that be the problem?
<Peng> ....
<Peng> "give the fingerprint" means "paste the contents of id_rsa.pub in the form"?
<fagan> I did that
<fagan> the key is definitly linked to my launchpad
<Peng> LP would've probably given an error if you did it wrong anyway.
<Peng> Sorry, my only other guess is that your SSH client is using the wrong key.
<fagan> hmmmm
<Peng> Or you're using the wrong username.
<spiv> Try sftp -v your_launchpad_username@bazaar.launchpad.net
<spiv> That will show you which key it is trying.  (And if it works then that suggests that bzr isn't trying the right username)
<spiv> Hmm.
<poolie> hello spiv, peng
<spiv> I wonder how hard it would be to include the username bzr tries in that error text...
<Peng> Good $time_of_day, poolie. :)
<fagan> Ah its using the wrong key
<Peng> \o/
<poolie> spiv, that would be good, though...
<fagan> Ill fix it thanks all
<poolie> maybe sometimes we let the ssh client default? i don't know
<spiv> Hmm, and we could probably add a -Dssh flag that would cause -v to be passed to openssh.
<spiv> We sometimes do, but I think in the case of Launchpad after lp-login we pass it.
<Peng> fagan: How did it wind up using the wrong key?
<poolie> i think i've sometimes seen launchpad sftp default to 'mbp@sourcefrog.net' as the username
<fagan> It said the number and I just matched it
<poolie> i haven't dug into why
<fagan> I just looked at the file and looked at launchpad and went I uploaded the wrong one
<fagan> I feel nice and dumb after that
#bzr 2010-12-13
<poolie> spiv, go ahead and land to 2.2
<poolie> i might add something to the coding guide about making exceptions error objects?
<poolie> i wonder if we should just have call a '.hint' method if it exists?
<poolie> actually maybe we do have a rule about repr methods being passive?
<spiv> Hmm, a .hint method might work well.
<spiv> I'm not sure a written rule about repr methods being passive would have caught this problem much sooner.
<poolie> it would have to either trip something in the brain of the person writing it or a person doing a review
<poolie> i don't know if writing it in a doc really makes that more likely
<poolie> _saying it_ now might
<spiv> I'm not sure I realised that repr(BzrError) would invoke that code path when I wrote it.  If someone had specifically asked about it I probably would have guessed correctly, but it's thinking about it in the first place that's the tricky bit...
<poolie> putting it in a doc gives people something to point to as "we agreed we wouldn't do this"
<spiv> Actually, that reminds me of something I was wondering: perhaps BzrError.__repr__ shouldn't invoke str(self)
<spiv> Precisely because people writing subclasses might not realise that __str__ and thus _format need to be as careful as a __repr__ should be.
<spiv> I guess in practice it would have only prevented this one problem in however many years BzrError.__repr__ has had that implemenation.
<poolie> ah, i didn't realize that calling str was something we added, rather than the default
<poolie> i have seen several other bugs to do with complex repr methods
<spiv> Yeah, the default repr doesn't call str.
<spiv> I wonder if the use cases for repr-of-BzrError are better served by showing repr(self.__dict__) rather than str(self) there?
<poolie> could very well be
<poolie> i wonder what an uncaught exception does?
<spiv> Shows the traceback and str(e)
<spiv> http://paste.ubuntu.com/542865/
<poolie> i'm just trying to work out why we called repr here
<spiv> It's a mystery to me :)
<spiv> I guess because it looked nice?
<poolie> it's not obviously called by anything on the stack
<poolie> perhaps twisted was trying to warn about a (what would you call it) leaked exception?
<poolie> how about
<poolie> http://pastebin.ubuntu.com/542866/
<spiv> Possibly.  But also Twisted turns raised exceptions during callbacks/errbacks into "Failure" objects, as a sort of async error+traceback
<spiv> But Failure has a fairly obnoxious behaviour of eagerly taking the traceback and turning it into a string (so it can discard the original traceback and all the probably circular references)
<spiv> And that stringification reprs lots of stuff.
<spiv> poolie: I'm ok with that.  It's a shame we don't have a good answer for "what about when we want to show hints for that error that may require IO to generate".  But that's just a wishlist thing rather than something important.
<poolie> i'd be ok with having .get_suggestions() optionally present
<poolie> then the ui code can call it, and perhaps suppress knock on errors while calling it
<poolie> ok, i'll put that patch up
<vila> hi all !
<poolie> hi there vila
<vila> poolie: hey !
<vila> hmm, where are core dumps dumped ? In the process working dir ? In the user home ? In some fixed place ?
<spm> bonjour vila!
<vila> :)
 * spm exhausts his high school french in one word.
<vila> spm: ...on the other hand, I'm sure you can teach me a lot about core dumps :D
<spm> apple cores are nicest
<poolie> vila, normally they go into the process cwd
<poolie> but on ubuntu they're configured into /var/crash by default i believe
<poolie> there is a /proc file that controls it
<vila> well, in this case it's a karmic VM that says: 'invalid environment block' and the Virtual Box is supposed to have crashed, but I can't find any core...
<vila> poolie: ha, one more place to rey
<vila> no luck, no /var/crash dir on the host either... puzzling
<poolie> they may just be off by default
<poolie>  'invalid environment block' is an interesting error
<vila> I turned them on in /etc/limits.conf
<vila> I turned them on in /etc/security/limits.conf or something
<poolie> that probably only takes effect on new logins or something
<poolie> try 'ulimit -c'
<gorakhargosh> Can bzr determine when a file is renamed/moved to a different directory on Windows?
<gorakhargosh> s/determine when/determine whether/
<poolie> i think 'bzr mv --auto' will automatically detect it
<poolie> but you need to run that command
<gorakhargosh> ah, so if i did a mv foobar blah/foobar it wouldn't?
<vila> poolie: checked, I did that last Friday, I'm lazily hunting them, but that's the third time the VM can't boot at all anymore which make the problem more... interesting
<vila> ouchy, > 100 errors fixed by fsck...
<vila> make that >1000.... sounds like I may restore from a backup instead...
<poolie> gorakhargosh: if you do that it will also work
<poolie> there's a lot of it around :)
<gorakhargosh> poolie: so my next question would be: how does it detect that? windows has no concept of inodes. how does it know it's the same file that is moved?
<poolie> vila, i was going to ask what you were going today but i think now i know :)
<vila> hehe, no, it's only a VM
<vila> wt.... stupid hudson ! Don't even try to start this VM, I just told you it was offline !
<gorakhargosh> poolie: I'm asking this because I'm writing a directory monitoring library which needs to do this on Windows (detect file movement, that is) and there is no reliable way of determining movement to my knowledge.
<gorakhargosh> Without this bit of info, I would think the 'bzr mv' command is not irrelevant. It is very relevant on filesystems like NTFS. It's hard (or I don't know yet how) to detect file movement on Windows.
<vila> gorakhargosh: mv --auto looks at the content of the files to guess renames, it didn't track it at the file system level
<gorakhargosh> vila: What do you mean by "guess renames"?
<gorakhargosh> <â currently downloading the source for bzr
<vila> gorakhargosh: we know the last versioned content of a file and we look at the actual content of files for close enough content
<gorakhargosh> vila: bzr mv should need to guess renames. it's a command known to bzr that renames. how would bzr determine movement if i used plain old "mv" instead?
<gorakhargosh> s/should need/shouldn't need/
<vila> mv doesn't guess, mv --auto does
<gorakhargosh> vila: ah
<gorakhargosh> ah
<gorakhargosh> also, by the latter "mv" i don't mean the bzr subcommand. i mean the UNIX mv tool.
<vila> gorakhargosh: I meant 'bzr mv'
<gorakhargosh> vila: yep
<DonDiego> hi everybody
<DonDiego> i patched the bzr text_checker plugin
<DonDiego> what is the preferred method for submitting a patch?
<beuno> DonDiego, merge proposals on launchpad
<DonDiego> so i push my local branch to my private space on lp and then connect it to the text_checker lp home with a merge proposal?
<jelmer> DonDiego: yep
<DonDiego> ok, thx, will do
<dev001> hi.  i've added to my .bzrignore, "./sites/mysite/files/".  but when i 'bzr add', that subdir & contents is still added.  wrong sytax on my part?
<soren> Can someone smarter than me take a peek at http://hudson.openstack.org/job/nova-tarmac/43312/console ?
<soren> Search on that page for "Lockable".
<soren> What is that?
<lifeless> soren: oh
<lifeless> either a bug, or a bad bzrlib script that isn't calling 'thing.unlock()'
<lifeless> make sure you have the latest release, then file a bug
 * soren glances at tarmac
<soren> ...and by extension rockstar`.
<soren> mtaylor: btw ^
 * mtaylor pokes rockstar
<lifeless> mgz: can you join #subunit ?
<lifeless> jam: hey, around?
<jam> hi lifeless, yep
<lifeless> wondering if you could do a small favour
<lifeless> we had a test failing on windows
<lifeless> in lp:testtools
<lifeless> rev 158 was broken, 159 should be fixed
<lifeless> wondering if you could run the tests on native windows python
<lifeless> for those two revs
<jam> lifeless: certainly
<lifeless> thanks!
<jam> lifeless: how does one run the tests
<jam> I think I found it
<lifeless> make check
<lifeless> or look at the makefile
<jam> lifeless: "make check PYTHON=.../python26" has 2 failures at r158, but 1 failure at r159
<lifeless> interesting!
<lifeless> what are the test ids
<jam> Failure for 159: http://paste.ubuntu.com/543271/
<lifeless> ahha
<lifeless> ok we didn't know about that one
<lifeless> jam: what was the additional failure in 158 ?
<jam> lifeless: testtools.tests.test_testresult.TestNonAsciiResults.test_unprintable_exception
<jam> and testtools.tests.test_testresult.TestNonAsciiResultsWithUnittest.test_unprintable_exception
<lifeless> ah, you didn't see a spinner test failure in either case?
<jam> nope
<jam> r157 has the same failures
<lifeless> and this is with native python ?
<jam> yep
<jam> python 2.6
<lifeless> its bizarre that 159 would fix testtools.tests.test_testresult.TestNonAsciiResults.test_unprintable_exception
<jam> well, now I'm getting the failure again
<jam> maybe there is a race?
<lifeless> perhaps
<lifeless> mgz: ^ wrote those tests
<jam> is there a randomize?
<lifeless> I was hoping to see a fix for a threaded twisted support thing.
<lifeless> no, I don't think so
<jam> lifeless: I might also need to have appropriate deps installed. how many tests should be running?
<lifeless> oh, good point!
<lifeless> 585 with no skips
<jam> lifeless: test suite at r159 runs 100% clean on python2.5
<jam> yeah, I'm getting 585 both ways
<jam> of course, r158 also passes on py2.5 fails on py2.6
<lifeless> mgz: https://bugs.launchpad.net/testtools/+bug/689858
<ubot5> Ubuntu bug 689858 in testtools "test failures on windows w/python 2.6" [Undecided,New]
<lifeless> jam: can you import twisted successfully in those pythons ?
<jam> lifeless: no twisted for py2.5, there *is* twisted for py2.6
<jam> but both claim 585 tests ran and no skipping
<lifeless> grr :(
<lifeless> we need a skip summary like bzr does
<jam> lifeless: Ran 585 tests in 1.091s
<jam> seems awfully fast
<jam> and -v doesn't show any actual "running test XX"
<lifeless> Ran 585 tests in 0.950s
<lifeless> testtools test suite is reasonably healthy
<lifeless> we could bear to make it a bit faster I think
<jam> lifeless: well, I miss stuff like "-v" printing what tests are running and individual status
<lifeless> yeah
<lifeless> agreed
<jam> Verbose doesn't seem very, verbose
<lifeless> real    0m1.221s
<lifeless> real    0m1.512s
<lifeless> time() with parallel/serial
<jam> lifeless: anyway, I can't confirm or deny what tests are being run, it says everything is fine
<jam> at least for py2.5, but I don't have twisted there
<jam> so I *know* it is lying :)
<jam> installing 10.2 now
<lifeless> thank you!
<lifeless> if that still shows nothing unusual changing between the two revs, I think we should let mgz look at it
<jam> lifeless: 2.5 passes cleanly on both 158 and 159. This time it prompted me that it was trying to open up a port, so installing twisted did change something.
<lifeless> interesting, thanks!
<lifeless> I think mgz has something different again
<jam> lifeless: he used to have 2.4, and then I've seen him run bzr against 2.7
<yhager> Hi, we are working on a central SVN repo, and I want a subteam to work on a DVCS repo. I am seeing that git-svn has quite a bit of limitations, and would like to check bzr-svn - as it looks better. Any good references to this? I know git, but don't know bzr, so any pointers to "bzr for gitters" would be appreciated too
<spiv> Good morning folks.
<spiv> yhager: http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html http://doc.bazaar.canonical.com/migration/en/survival/index.html
<yhager> spiv: thanks!
 * yhager sits back and starts reading...
<mgz> lifeless: that's certainly odd. it's possible that the twisted somehow screws up that test, as it involves traceback formatting, but really twisted shouldn't see it.
<mgz> jam: if you could get that rev where you were having the random failures again, and try moving twisted off your python path, might answer that question.
<lifeless> mgz: can you check if 159 fixes the _spinner issue you reported ?
<mgz> lifeless: on the r159 change, that doesn't fix it for my default install
<lifeless> mgz: grah, srs?
<lifeless> mgz: can you pastebin the code in your threadpool.py then ?
<mgz> gra, I hate twisted, the package structure makes no sense to me and the names are all too cute to be meaningful
<mgz> (under 'python' for future self-reference)
<yhager> Can anybody testify that working with bzr under an SVN repo is almost seamless, as opposed to trying to do the same with git?
<mgz> http://float.endofinternet.org/temp/threadpool.py
<lifeless> yhager: many folk have praised it
<mgz> lifeless: if the result is "upgrade your damn twisted install", I can live with that.
<yhager> lifeless: You see, I usually use git, and I want to introduce DVCS to the team. git-svn has put me down in that it is fairly easy to get wrong, especially for DVCS newbies. bzr looks better in that sense..
<lifeless> cool
<yhager> I am now looking for reassurance :)
<lifeless> mgz: that source appears to have the same bug - check _worker and stop()
<lifeless> mgz: what I don't understand is why it wouldn't be working
<mgz> reading your notes on the bug now.
<lifeless> mgz: care to put a print in before the self.threads.remove(ct) in _worker, before/after the threads copy
<lifeless> mgz: also try a gc.collect :P
<mgz> http://paste.ubuntu.com/543309/ <- like that?
<mgz> or do I also need to weakref the ct itself?
<lifeless> yeah
<lifeless> try that
<lifeless> In principle the thread exits to the Threading wrapper function
<lifeless> yhager: Lots of folk use bzr-svn and enjoy it
<lifeless> yhager: the mailing list has active helpful users of it
<lifeless> yhager: and launchpad.net uses it for mirroring many many svn repositories
<lifeless> yhager: bzr is somewhat different to git, and some folk love that, others don't :)
<mgz> hm, I think I'd need a context switch for that to work, I'm guessing threading.currentThread will mean something in the interpreter is holding onto it.
<yhager> lifeless: well, I like git, but I am not religious. If bzr works better for me, I'll use it just as happily (or maybe even more..)
<lifeless> mgz: its interesting reading in the core
<jam> mgz: I don't think it is twisted. it is python 2.5
<jam> vs 2.6
<jam> py2.6 always fails
<jam> py2.5 never fails with or without twisted
<jam> but *with* twisted it prompted my Firewall alert
<jam> meaning the tests that were running did something different
<jam> (even though the test suite always says "ran 585 tests in 1.0s"
<jam> )
<mgz> mphf, 2.7.latest works for me though, and that isn't really a complex test
<mgz> (it does involve what happens when exceptions are raised from magic methods, but python doesn't change what happens there if it can help it)
<jam> mgz: Py2.7 without twisted passes cleanly
<jam> looks like 2.6 formats exceptions differently from the rest
<mgz> what's your minor version?
<lifeless> __repr__ and __str__ got fiddled with
<lifeless> :P
<lifeless> yhager: so, give it a spin ?
<yhager> lifeless: yes, I guess I will. I want to read a bit more first...
<mgz> lifeless: failing to make that twisted method do anything different. what exactly is the intention of the workaround? because it seems to me as soon as the `self.threads.remove(ct)` line gets hit we're (maybe) screwed
<lifeless> mgz: see stop()
<lifeless> mgz: its possible that the thread isn't getting any timeslice at all though
<lifeless> mgz: throw some more prints in, and paste the instrumented file/diff so that I can see what you've changed
<mgz> ha, joy. extra prints = delay = bug vanishes!
<mgz> presumably that's io sync
<mgz> okay, os.write saves me.
<mgz> lifeless: http://paste.ubuntu.com/543321/
<poolie> hi mgz, jam, lifeless
<mgz> hey poolie.
<mgz> whoops, c/p error, not printing the local threads variable in stop.
<lifeless> hi poolie
<mgz> fixing that gives me the last line instead as:
<mgz> GZ: stop after joining [<Thread(PoolThread-twisted.internet.reactor-1, stopped)>]
<lifeless> mgz: three tweaks
<mgz> so, the thread does get stopped, but threading.enumerate in the test case still pulls it up.
<lifeless> stop before and stop after joining should prit threads
<mgz> right, did that.
<lifeless> and can you put a print in the for thread in threads loop
<mgz> sure.
<lifeless> and a print of threading.enumerate() as well Iguess
<lifeless> mmm, no that shouldn't be needed
 * poolie is curious about the context
<lifeless> poolie: https://bugs.launchpad.net/testtools/+bug/666345
<ubot5> Ubuntu bug 666345 in testtools "test_spinner.TestRunInReactor.test_clean_running_threads fails with an extra thread" [Critical,Fix committed]
<mgz> <lifeless> and a print of threading.enumerate() as well Iguess <- already done as well :)
<lifeless> mgz: so, how does it look ?
<mgz> http://paste.ubuntu.com/543326/
<mgz> looks like I need to check out what threading.enumerate does.
<lifeless> ok, so we're definitely joining
<lifeless> phew
<lifeless> and you can see the context switch to the thread triggered by join
<mgz> yup.
<lifeless> wtf is enumerate returning a stopped, joined thread
<lifeless> 'Return a list of all Thread objects currently alive. The list includes daemonic threads, dummy thread objects created by current_thread(), and the main thread. It excludes terminated threads and threads that have not yet been started.'
<lifeless> per 2.6 docs
<lifeless> 2.4.4 claims the same
<lifeless> mgz: try a sleep(0) after the join
<lifeless> I think you proposed that in the test case
<mgz> yup. that's sufficient.
<lifeless> so
<lifeless> theory:
<lifeless> join() isn't calling the os level pthread_join [the equivalent of, on windows]
<lifeless> mgz: do you get this failure on 2.6/2.7?
<lifeless> jam: how many cores does your machine have?
<lifeless> mgz: ^
<jam> lifeless: 2
<mgz> I don't have twisted installed for my svn python, 1.
<mgz> but this may be some long-fixed threading bug.
<spiv> lifeless: I've seen enumerate return stopped, joined threads.
<spiv> It's caused me a bit of grief in the past.
<spiv> I forget if it's a bug fixed in later upstream, but the practical result is that you have to filter the result of enumerate.
<spiv> (if you care about the threads all being alive)
<lifeless> spiv: thanks
<lifeless> mgz: ok, so I'm very glad we investigated this, as I do believe it would have caused memory pressure issues and potential bugs in large test suites
<lifeless> mgz: the fix I've landed fixes that correctness issue (though twisted upstream is still borked if you downsize a threadpool)
<lifeless> mgz: so I think:
<lifeless>  - check for a fix in upstream python
<lifeless>  - if not, file a bug
<lifeless>  - we should filter enumerate(), with a comment and a link to the python bugtrackers bug about this.
<mgz> just installed 10.20 on 2.7 and don't get failure, which may or may not mean it's fixed.
<lifeless> mgz: I suspect its not fixenated
<lifeless> otoh perhaps it is :P
<mgz> timing stuff is sensitive.
<lifeless> http://www.mail-archive.com/python-bugs-list@python.org/msg11648.html
<mgz> http://bugs.python.org/issue1703448
<mgz> heh, same thing.
<mgz> either lifeless or me could pass for a psychic this evening
<spiv> Oh look, I filed that.
<lifeless> mgz: would love https://bugs.launchpad.net/testtools/+bug/689858 to  be figured out ;)
<ubot5> Ubuntu bug 689858 in testtools "test failures on windows w/python 2.6" [Critical,Triaged]
<mgz> metoo.
<spiv> Gosh, I filed that 3Â½ years ago, and fixed within a year.  It's such a shame we still have to cope with it :(
<lifeless> mgz: I've pushed a fix, can has confirmation ?
<mgz> spiv: you deserve some kind of reward
<mgz> lifeless: passes.
<lifeless> ok great
<mgz> nit: 2.5.2
<lifeless> mgz: are you going to look into jams' test failure?
<spiv> mgz: I'm just glad I've forgotten whatever horrible thing it was that made me diagnose that.
<lifeless> mgz: E-pic shrug :P
<lifeless> spiv: bzr server threading tests
<mgz> lifeless: I'll branch release26-maint and see if I get anywhere, but I have doubts.
 * spiv puts his fingers in his ears and sings "la la la la"
<lifeless> grrr
<lifeless> python.threading doesn't say whether one must call join() or not. Just 'can call it'
<lifeless> spiv: http://twistedmatrix.com/trac/ticket/4770
<mgz> jam: http://paste.ubuntu.com/543343/ <- is there anything else you can suggest?
<mgz> hm, something's up with the importing.
<mgz> okay, twisted tests working, but I can't repo jam's failure.
<lifeless> jam: still playing wow at all?
<lifeless> mgz: oh
<lifeless> mgz: i finished my parallel test stuff for testrepository
#bzr 2010-12-14
<poolie> hi spiv
<spiv> Hi poolie
<yhager> lifeless: yes, I guess I will. I want to read a bit more first...but the minimum exported version is (2, 3, 0),
<yhager> oops..
<yhager> I installed bzr latest (2.3b4) and latest bzr-svn, but bzr-svn seem to be too old?
<maxb> yhager: which bzr-svn are you using?
<yhager> 1.0.3 - it's the latest I found
<maxb> You probably need the current development version
<maxb> bzr branch lp:bzr-svn
<yhager> maxb: thanks. It's not very clear from http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion how to get it (especially to bzr newbies..)
<maxb> yhager: Ah. The sad truth is that the wiki is seldom the most up to date about where to get things
<yhager> It's usually the first place I go before I bug people on IRC.. :(
<maxb> In particular, any time you see a list of versions on wiki.bazaar.canonical.com, don't trust it
<maxb> For example, 1.0.4 is out
<yhager> hmm..
<maxb> jelmer: Would you be opposed to deleting the list of versions from http://wiki.bazaar.canonical.com/ForeignBranches/Subversion and just pointing to the Launchpad project page?
 * maxb adds 1.0.4 to the wiki meanwhile
<yhager> When I want to create a feature branch, in git, 'git branch' is a very lightweight operation. 'bzr branch' seem to copy the whole branch to a new directory. Is this the same concept?
<lifeless> yes, but the default is setup to be more like a full 'cp' - to ease the learning curve
<lifeless> sadly this means nontrivial projects often need to do a bit more (and we'll be changing this sometime soon)
<lifeless> you might like the bzr-colo plugin
<lifeless> which gives you multiple branches in one directory
<lifeless> or setup a 'shared repository' (using bzr init-repo), and branch into that
<lifeless> there are docs for both these I think, on the docs website
<yhager> I read about shared-repository, but did not really understand what it does. I
<yhager> I 'bzr init-repo', then cd into that, and branch from there?
<maxb> yhager: A shared repository is a way to share revision history disk storage between multiple branches. This saves disk space, and also makes branching faster because none of the history needs to be copied
<yhager> maxb: but still, it copies the whole directory..
<maxb> The working tree, you mean?
<yhager> maxb: yes. Our project is huge..
<yhager> so a shared repository can share info on more than one project? i.e. can I put all my bzr stuff in ~/bzr after the initial 'bzr init-repo ~/bzr' ?
<maxb> There's two approaches to working with many branches but a single working tree, you can look at the colo plugin, or you can have a shared repository that contains a number of treeless branches and a single lightweight checkout
<yhager> maxb: just measured, it's 2.5GB
<maxb> yhager: You can put multiple projects into one shared repository, with the caveat that the process of packing the repository is then over all the projects, not just the project you happen to be working on
<yhager> maxb: the way I understand it is that every checkout is lightwieght in a shared repo?
<maxb> yes (more or less)
<yhager> ok, I see. so I will use a shared repo as a parent dir for all the feature branches.. but still, checking out a branch will mean copying 2.5 GB around..
<maxb> why?
<maxb> making a new checkout will, yes. So the answer is to only make one of those, and switch it between branches, much as you might do with git
<yhager> maxb: ok, I need to read some more. I am confused between checkout and branch now..
<maxb> branch == a pointer to a current revision, plus a dictionary of tags
<maxb> A branch must have an associated repository somewhere, to actually hold the revisions pointed to
<maxb> checkout == A working tree, that is linked to a branch (which is where it puts new revisions when you commit them)
<yhager> ok, so a checkout is similar so SVN checkout - all operations are done centrally. Not very interesting if I am trying to make the team switch from SVN
<yhager> I have a large team working on an SVN repo of 2.5GB. I want to work with a couple of guys on our own feature branch, and I want to show them the awesomeness of DVCS. What setup would you suggest for this?
<yhager> I was thinking of a central repo that imports from SVN, and everyone is branching and pushing to it.. does this make sense? However I am confused on how feature branches can work on a 2.5GB workspace
<yhager> In my testing of bzr-svn using a test svn repo, I am now in a situation I cannot push changes anymore to SVN. I get "Operation denied because it would change the mainline history.". Tried rebasing but it does not seem to help
<yhager> I prefer to keep append_revisions_only=true
<lifeless> sure
<lifeless> grab a checkout of your svn branch, do a 'bzr merge otherbranch' and 'bzr commit
<yhager> lifeless: it worked! I am trying to understand why. We circumvented the inability to rewrite history in SVN by doing a bzr merge commit, directly onto svn. right?
<jam> mgz: I don't know, my python is 2.6.4
<jam> lifeless: yeah, I'm still playing, just hit 85 last night
<jam> mgz: my py2.6.4's twisted is 10.1 vs 10.2
<yhager> lifeless: hmm.. but I lost the individual commits this way..
<yhager> This is still far better than git-svn. git-svn rewrites history upon every dcommit (push to svn) - since it adds the svn id to the commit messages. This seems more robust.
<lifeless> yhager: right
<lifeless> to keep the individual commits you can rebase your local branch and push at the same time using the 'dpush' command.
<yhager> lifeless: why would I want to use dpush?
<lifeless> yhager: if you wanted to keep the separate commits of a branch done in bzr, when propogating it to svn
<yhager> wouldn't this work with push as well? (as long as I am not merging)
<lifeless> something like that anyhow - I don't interact with svn these days, so ... I'm not the best advisor
<yhager> lifeless: you helped a lot! thanks.
<yhager> How can I specify complex layouts of the SVN repo? bzr help svn-import does not help too much...
<spiv> yhager: bzr help svn-layout
<yhager> spiv: thx
<yhager> Darn.. after all this research.. bzr svn-import failed with an internal error...
<yhager> I'll try a simpler branch structure..
<lifeless> jelmer is pretty responsive to bug reports
<lifeless> launchpad.net/bzr-svn
<jelmer> maxb: I'd prefer to keep the list, as it mentions which bazaar versions are compatible
<jelmer> maxb: the list on Launchpad is not authoritative, it's just a mirror of the actual downloads
<lifeless> jelmer: what would lp need, to be able to be authoritative
<jelmer> lifeless: some place I can just scp/sftp stuff to, or the release-from-tag feature I filed a bug about earlier
<jelmer> lifeless: I realise there might also be a command-line tool based around the API nowadays for uploading releases (is there?).  I'm not necessarily opposed to migrating but it means taking some time to dig up that tool, figuring out how it works, and migrating existing tarballs/links.
<jelmer> lifeless: at this point hosting the tarballs on launchpad makes things (slightly) more complicated for me, rather than easier (which it should be)
<spiv> It would be nice to make launchpad support sftp uploads of download files.
<poolie> there is abentley's tool the-kraken
<poolie> i think it does this, but i haven't tried it
<jelmer> yeah, it can create releases from tags and upload them to launchpad. but it needs to be run user side.
<spiv> (And scp for that matter)
<spiv> I could imagine something like "scp foo.tar.gz foo.tar.gz.asc downloadfiles.launchpad.net:~proj/series/release/" that just DTRT.
<spiv> Hmm, I think I've accidentally found a way to tighten one of the HPSS ratchets by deleting redundant code.
<poolie> nice, good for you
<jelmer> spiv: Yeah, something like that would be neat.
<jelmer> poolie: the idea behind the-kraken is nice, but it requires running a tool locally and it requires per-project configuration that you need to carry around with the project.
<lifeless> jelmer: you should reopen that release from tag bug or something
<poolie> mm, that's a shame
<lifeless> I think it would be very nice
<poolie> it seems like there is generally a gap between "patch to launchpad itself" and "tool people need to run on their own machines"
<poolie> in theory you could run a kraken-like thing on a server somewhere, even using oauth
<poolie> but it does not seem to often be done
<lifeless> its hugely more convenient and discoverable to have links in the webui
<lifeless> one could add such links and docs to external tools, of course
<jelmer> poolie: it would be nice if launchpad supported push notifications to help with that sort of thing.
<jelmer> lifeless: I'll follow up on the bug.
<poolie> agree
<jelmer> lifeless: Looks like I already followed up to Aaron's last reply earlier.
<lifeless> jelmer: kk
<lifeless> jelmer: I thought it was closed, clearly I'm wrong ;)
<lifeless> jelmer: what is its status?
<jelmer> Its status is "Opinion", not sure whether that counts as Closed :-)
<jelmer> bug 673407
<ubot5`> Launchpad bug 673407 in Launchpad Bazaar Integration "automatic tarball creation for tags" [Medium,Opinion] https://launchpad.net/bugs/673407
<lifeless> bah
<lifeless> thats closed
<poolie> aka "that's your opinion" :)
<vila> hi all
<vila> hi jelmer
<jelmer> vila: moin
<poolie> hi there
 * vila jumps (silly volume control staid on very high...)
<jelmer> vila: I uploaded bzr-upload 1.0 to Debian the other day, should land in natty soon.
<jelmer> vila: Only a few more broken bzr-related daily builds remaining now.. bzr-search, bzr-dbus, bzr-email and bzr-xmloutput
<vila> jelmer: rmadison says 1.0.0 is in natty already
<jelmer> vila: hmm, that was quick! Never mind me then :-)
<vila> jelmer: I've seen weird failures for the daily builds about truncated time stamps
<vila> jelmer: I was wondering if they were related to py27 ?
<jelmer> vila: I don't recall seeing any; there were some related to python-testtools and py27 a while ago but those should be fixed now
<jelmer> the 4 packages I mentioned are all failing because of failures in their test suites.
<poolie> does bzr choose base texts using the per-file graph now?
<vila> poolie: I don't think so (well, IIUC you mean by first establishing this graph)
<vila> jelmer: so presumably old failures right ?
<vila> jelmer: yes, I was referring to semi-old failures and testtools was among the suspects
<jelmer> vila: the testtools related issues should be fixed now as far as I can tell, these remaining issues are AFAIK all due to API changes in bzrlib
<vila> jelmer: ok
<jelmer> except for bzr-email perhaps, I'm not entirely sure what's going on there
<vila> jelmer: looks like it's config related
<vila> jelmer: fixed
<poolie> vila: see my pm?
<vila> jelmer: well, fixed but requires a new-ish bzr
 * poolie is going soon
<vila> poolie: oops
<vila> jelmer: the fix is only in the tests so I don't think we should spend time ensuring compatibility there... or not ?
<jelmer> vila: how hard would it be to fix compatibility?
<jelmer> vila: Hmm, nevermind - I was thinking of older Ubuntu releases but I guess those should be fine as long as we have a newer bzr?
<vila> jelmer: http://paste.ubuntu.com/543473/ is the fix, so it could certainly be made compatible
<vila> jelmer: exactly
<vila> jelmer: people using old bzr versions will still be able to use the plugin
<vila> jelmer: if they care about running the tests... I'd be surprised if they don't want to upgrade...
<vila> jelmer: should I push this fix ?
<jelmer> vila: yeah, that seems reasonable
<jelmer> vila: please do, thanks for fixing this!
<vila> jelmer: done
<cvv> Hi all?
<cvv> is currently here Vincent Ladeuil?
<vila> cvv: Vitaly ?
<vila> cvv: yeah, that should be you :) bug #684728 has some 'cvv' in the paths :)
<ubot5`> Launchpad bug 684728 in Bazaar "bzr push refuse with message "bzr: ERROR: Working tree "/root/projects/games/logic/v2/cvv-dev/" has uncommitted changes (See bzr status). Use --no-strict to force the push." on clean tree" [Undecided,Incomplete] https://launchpad.net/bugs/684728
<cvv> Yes, I'm Vitaly
<vila> cvv: welcome :)
<vila> cvv: can you still reproduce the bug if you use 'shelve' instead of 'shelve1' ?
<cvv> May be will be interesting for you output of 'bzr info'?
<vila> cvv: that too !
<vila> !paste
<ubot5`> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<spiv> vila: thanks for the review of sprout-does-not-reopen-repo, if you want to look at my reply and make another reply that would be lovely :)
<vila> cvv: also, what OS/version are you using ? And are you indeed running bzr as root ? (This may not be related but will help me understand your setup)
<vila> spiv: planned
<spiv> vila: yay, thank you :)
<cvv> mmm. shelve miss some functionality to be replacement for shelve1. I will try during few minutes.
<vila> spiv: but roughly: 1) if you don't want import repository, I feel far better 2) I was hoping to give you the energy to nail it, not implying you haven't tried ;-)
<spiv> vila: if you want an easier review you can look at https://code.launchpad.net/~spiv/bzr/redundant-missing-keys-check/+merge/43623 ;)
<spiv> vila: it deletes more lines than it adds, including release-notes and whats-new :)
<vila> spiv: hehe, I think the sprout-does... is more important since it's a pre-requisite, but I'll look at both
<vila> cvv: what is missing ? Have a look at shelve --list and unshelve too
<vila> spiv: just checking: did you try to run the bzr-{svh|hg|git} for sprout ?
<vila> jelmer: if you could have a brief look at https://code.edge.launchpad.net/~spiv/bzr/sprout-does-not-reopen-repo/+merge/41037 that would be nice !
 * jelmer looks
<cvv> viva: I frequently use shelve, but sometimes I need shelve1 functionality. I try to reproduce bug with shelve and found out then my bug is unreproducible with shelve.
<cvv> viva: only with shelve1
<vila> jelmer: I'm looking at the xmloutput failure but... it looks quite complicated... that's the perfect example of why CI is needed to get faster feedback... I wonder when this started failing
<vila> cvv: haaaa, good, huge progress
<vila> cvv: so what is missing in shelve that shelve1 provides ?
<jelmer> vila: yeah, I didn't see anything obvious that was the culprit in bzr-xmloutput either.
<jelmer> maybe we can convince beuno or verterok to have a look?
<cvv> vila: output of bzr info -v: http://paste.ubuntu.com/543492/
<vila> jelmer: may be, but this sounds like a bzr change is the culprit there...
<vila> cvv: wow, you're using a very old bzr format, upgrading will get you smaller repositories and faster operations (let's finish diagnosing your actual problem first though)
<vila> cvv: the 'bzr info' output is fine, nothing wrong here
<cvv> vila: one second
<vila> cvv: sure
<maxb> jelmer: The problem with versions on the wiki is that the lists inevitably get out of date. If they are to stay, we need a better way of remembering to update them
<jelmer> maxb: I update it when I do a release, but obviously I forgot last time.
<cvv> vila: that's  was false alarm.
<maxb> ok. It's just conversations here involving users mislead by stale wiki pages appear to be somewhat commonplace (in general, not just for bzr-svn)
<vila> jelmer: meh, bzr-email failing because it can't import testtools ? wth ?
<jelmer> vila: where is that?
<vila> jelmer: https://launchpad.net/~bzr/+archive/daily/+build/2096278/+files/buildlog_ubuntu-karmic-i386.bzr-email_0.0.1%7Ebzr45%7Eppa53%2B53%7Ekarmic1_FAILEDTOBUILD.txt.gz
<vila> oh, karmic ?
<cvv> vila: I currently log out. If there will any ideas about additional interesting or useful info - I will be happy to give.
<vila> cvv: you didn't tell what is missing from shelve1 ?
<vila> argh
<jelmer> vila: Yeah.. looks like the version of testtool is too old
<vila> jelmer: but where ? I don't get which archives/ppa are involved here nor where you specify them
<vila> Get:40 http://ftpmaster.internal karmic/universe python-testtools 0.1~r16-0ubuntu1 [8504B] is certainly weird
<jelmer> vila: Each PPA has a link "Edit PPA dependencies" where you can specify the other PPA's that will be used to install dependencies
<jelmer> it might make sense to add "ppa:testing-cabal/archive" for the newer testtools
<vila> why not the bzr-beta ppa instead ?
<jelmer> vila: either works I guess
<jelmer> testing-cabal/archive has daily builds of testtools so is likely to be more recent, but I'm not sure how important that is
<vila> well, from babune, I had mixed experiences tracking testtoosl/subunit tips, bzr-beta will be updated less often but should be 1) less likely to fail, 2) broader than testing-cabal if there are more dependencies (cross plugins ?)
<jelmer> the daily builds run the test suites so broken tips shouldn't be an issue
<jelmer> is there no PPA with just bzr build dependencies?
<jelmer> I'd just like to make sure we build the plugin daily builds against e.g. the bzr daily build rather than the release
<vila> testtools is not strictly a build dependency, I think that an issue that has been discussed in the past
<vila> oh
<vila> s/that/that's/
<vila> bah, know issue is what I meant
<vila> known
<vila> wow, tyops attack !
<jelmer> adding a PPA to the dependencies won't pull in its packages, it'll just mean that PPA will get used during the build.
<vila> good point about daily bzr though
<vila> right, so you did add testing cabal since this failed build right ? (looking at https://launchpad.net/~bzr/+archive/daily/+edit-dependencies right now)
<vila> . o O (Would you stop adding 'right' at the beginning *and* the end please ?)
<jelmer> :-)
<jelmer> Yeah, I did add the testing cabal PPA to the dependencies earlier
<vila> haaaa, but it doesn't contain the packages for karmic
<vila> only lucid/maverick/natty
<spiv> vila: I haven't run the foreign vcs plugins, I expect they will need to be updated for the new signatures
<spiv> vila: but the new signatures will work ok with old bzrs, so it's not too bad
<vila> spiv: meh, you lost me here
<jelmer> vila: I suspect there was a reason we couldn't build on karmic, but I don't remember off the top of my head.
<spiv> vila: the sprout patch adds params to stuff like BranchFormat.open
<vila> if plugins use the new parameters, surely they won't work with old bzrs
<spiv> vila: so I expect SvnBranchFormat.open (or whatever it is called) will need to add the new param to its definition
<vila> urgh
<spiv> vila: it can even ignore the new param, it just has to allow it to be passed.  It's an optional param.
<vila> yeah, got it now
<spiv> (ideally they'd use it rather than ignore it of course)
<maxb> I wonder, if we should have a status wiki page for collaborative notes on investigations of ~bzr daily recipe build failures
<jelmer> maxb: I'd like to see +recipes page that lists the failures.
<jelmer> *a
<jelmer> maxb: As far as I know there are only three failures left, in bzr-xmloutput, bzr-search and bzr-dbus. They're not specific to the daily builds.
<vila> Some of them may be worth filing as bugs
<vila> jelmer: the bzr-search failures all point to the *same* root cause apparently
<vila> jelmer: by the way (dunno if it applies to your recipes) you know you can use BZR_PLUGINS_AT=xxx@.
<jelmer> vila: that's what they're using.
<vila> I mean a single '.'
<vila> That may seem a bit unsafe in scripts but in interactive use it's neat ;)
<jelmer> vila: IIRC that doesn't always work for me, when plugins use chdir() and relative imports.
<vila> jelmer: ok, file bugs next time ;)
<vila> or not...
<jelmer> vila: well, is that really a bug?
<vila> I just happen to use it for plugins that I don't install
<jelmer> I generally use BZR_PLUGINS_AT="svn@`pwd`"
<vila> jelmer: well, I'm not sure where the bug is in this case, chdir() and relative imports in plugins are... borderline to me ;)
<vila> yeah `pwd` is safer (I use it too, I realized '.' allowed me to be even more lazy ;)
<knittl> how can i describe LCA merge in one o r two sentences?
<AdamDV|iPad> Just looking at the documentation, and trying to understand the difference between a merge and a pull. A pull allows you to grab the code if you don't intend to make changes to it, right?
<AdamDV|iPad> And then you could branch and commit and remerge if your going to change the code, and by sending the code back to the maintainers, they can approve it and merge your code back into the master branch?
<fullermd> Loosely speaking, pull is for maintaining a mirror; merge is for combining outside changes with your own.
<AdamDV|iPad> I see.
<maxb> pull == bring some history, which is a strict superset of what I already have, from over there, to my local branch
<AdamDV|iPad> Alright.
<AdamDV|iPad> And if I do a 'bzr send -o file.patch' it will output file.ptch which I can then email to the project maintainers (pr somehow get it to him)?
<AdamDV|iPad> And what command would be run on the server to merge changes from the patch file to the master branch?
<maxb> I think you can 'bzr merge' from a bundle
<AdamDV|iPad> Bundle?
<vila> 'send' produces bundles (there is more than just the patch in them)
<AdamDV|iPad> I see.
<vila> but using branches is preferred over bundles when possible since you can reuse them
<AdamDV|iPad> But, contradictory to the name, bar send does not actually upload any code into the meter branch, correct?
<vila> 'send' is for mail
<AdamDV|iPad> Well, how would you submit code for approval without using a bundle?
<AdamDV|iPad> Alright.
<vila> by publishing a branch somewhere
<vila> http/ftp/sftp server
<AdamDV|iPad> Hmm
<vila> or on launchpad
<vila> have a look at merge proposals there and how they can be reviewed
<AdamDV|iPad> And then the maintainer would merge from you published branch, right?
<AdamDV|iPad> Your*
<vila> through a dialog between a submitter and the maintainer the branch evolves without the need to send multiple mails (even if mail can be used to interact with launchpad)
<vila> yes, merge accept branches and bumdles
<vila> bundles
<AdamDV|iPad> I see.
<AdamDV|iPad> But if your merging from a branch and not a bundle, doesn't that mean that each branch being merged from or submitted for merging has t be stord in it's own directory on the server?
<AdamDV|iPad> Or, away from the master branch?
<vila> yes, they are separate branches
<vila> But that doesn't mean they can't share history :)
<AdamDV|iPad> Of course not :)
<AdamDV|iPad> I see. I'll probably be back. Gonna go read the doc some more.
<vila> By that I mean at the storage level too (search for shared repositories)
<vila> my ISP has gone mad again...
<vila> ...their new DSL modem will now also includes a blu-ray drive, a 250GB HDD, DECT support, 3G, Wifi-n HDTV
<vila> oh, I forgot the accelerometer and gyro in the remote ...
<fullermd> It can't read email?  What a piece of junk.
<vila> ...
<vila> ... you can... if you have a TV...
<fullermd> Ugh.  Who wants THAT?
<vila> did I mention support for optic fiber ?
<vila> and the game pad ?
<vila> poor other french DSL ISPs they have just produced new boxes to compete with the old one...
<vila> jam: hello ! Thanks for the review ;)
<jam> morning vila]
<jam> np
<jam> sorry about the delay
<vila> jam: np, that wasn't an important change, just a cleanup ;)
<vila> jam: but for the sphinx one, I think I answered your review and I'd like to make babune a bit more blue ;)
<vila> https://code.edge.launchpad.net/~vila/bzr/688072-skip-sphinx-failures/+merge/43227
<vila> courtesy URL :)
<jam> vila: well, I did say "I'm fine with this", sorry for not giving an actual vote
<vila> ha, I'm always unclear about implied votes :-/
<vila> err, confused I meant
<jam> if it seems like an approve, and it takes a week to get a response, it *is* an approve
<jam> (heck, if it takes a week, it *is* an approve anyway, :))
<fullermd> vila: Speaking of votes, does that combination of your and my changes on smooth-upgrades satisfy your Needs-Fixing?
<vila> fullermd: shudder, almost, I'd like to get rid of the not-so-useful-so-let's-not-add-stuff-requiring-maintenance helper
<vila> I'll get to that asap and nag the pp from there
<vila> ...or not
<vila> hmm
<fullermd> Who...   oh, yes.  I'd want to hear from him anyway, since he was the last comment on igc's original MP.
<vila> fullermd: by the way,feeling better ?
<fullermd> Oh, fairly.  I can breathe again.  Just the trailing ends to deal with for some days to come probably.
<vila> fullermd: good ;)
<RenatoSilva> I have a merge which will add new files, how to avoid these files to be added?
<RenatoSilva> bzr remove them doesnt' work, it'd be something like bzr unadd
<RenatoSilva> oh bzr revert them
<RenatoSilva> never mind
<vila> ultimate support via IRC !!
<yhager> unfortunately bzr-svn fails on me with sqlite3 errors, and I can't install tdb. See https://bugs.launchpad.net/bzr-svn/+bug/685251/comments/4. That's too bad, cause bzr-svn seems very solid to me.
<ubot5> Ubuntu bug 685251 in Bazaar Subversion Plugin "bzr-svn aborts instead of waiting if its sqlite DB is locked" [Low,Triaged]
<jelmer> yhager, do you really need to use multiple instances of bzr at the same time?
<yhager> jelmer: nope
<jelmer> yhager, sqlite shouldn't give that error if you have only a single instance of bzr-svn running
<yhager> jelmer: well, I only run a single 'bzr svn-import'
<yhager> jelmer: thanks for helping me on this
<jelmer> yhager, that's strange, I haven't seen that before
<jelmer> yhager, another thing you can try is to disable the cache altogether, but that will have some performance implications
<yhager> jelmer: how?
<jelmer> yhager, set "use-cache = False" in the relevant section in ~/.bazaar/subversion.conf
<jelmer> or perhaps just in ~/.bazaar/bazaar.conf
<yhager> ok. I need to unfold my python2.7 source compiling, and go back to the previous setup. Now it doesn't even run...
<yhager> darn, no uninstall for this
<yhager> jelmer: Usually it failed in the getting branch info (at ~4k revisions out of 24k). I ran with use-cache = False, and now it is already in the "copying revisions" phase..
<RenatoSilva> Imagine I patch a given changeset of some project and I need to update the patch as new changesets are introduced in upstream. It is a mercurial repository, so I import it into launchpad, and merge my patching branch with the latest changed on that branch. The problem is, how do I generate the patch? This workflow is not making sense to me
<yhager> jelmer: so far so good. use-cache = False seem to have been a good workaround. (copying revision 7094/22784) :)
<RenatoSilva> *latest changes
<RenatoSilva> in my mind, the workflow which would allow me to generate the patch is branch the imported branch, and merge from the patching branch
<RenatoSilva> the problem is that I'd need to do revolve merge conflicts every time there's a new changeset in upstream, this is boring
<RenatoSilva> * resolve
<RenatoSilva> does anyone understand what I mean?
<vila> roughly
<yhager> jelmer: oops.. bzr: out of memory
<vila> you mention two problems here: one is getting your patch up to date, the other is the conflicts
<vila> for the patch, I don't see why one workflow will give you a patch different than the other but if you're more comfortable with it, just use it
<vila> for the conflicts, I think you will get the same whatever your workflow is but it's hard to guess which kind of conflicts you're getting
<RenatoSilva> vila: let's say I use the first workflow and my patching branch looks like this: 1. Initial commit from upstream release 1.0, 2. My patch, 3. Merge upstream changeset 123, 4. Merge upstream changeset 124, 5. Improve my patch, 6. Merge upstream changeset 125
<RenatoSilva> vila: then they want to apply my patch in changeset 126. I need to provide them a component.patch, but I can't figure out how exactly...
<vila> then you get your patch against upstream with 'diff -rsubmit:' probably
<vila> submit: will use whatever branch is named submit_branch in the output of 'bzr info'
<RenatoSilva> bzr diff -rsubmit: imported-hg-branch?
<vila> just 'submit:' , it will use the right branch
<vila> well, "right", most of the time, check 'bzr info'
<RenatoSilva> but the right branch is not what's in bzr info by definition
<RenatoSilva> what operation makes a branch get into bzr info as the submit branch?
<vila> merge
<vila> merge --remember will set it again
<RenatoSilva> hmm ok, so I just need to keep bzr merging with upstream, and if they accept the patch, I just need a bzr diff -rsubmit:
<vila> another way to get it is to do 'bzr merge --preview ../feature' in your mirror
<RenatoSilva> bzr -rsubmit: will make a diff bewteen the submit branch and current one, starting from the common revision. It will differentiate between the commits in current branch which are just merges and the ones which are real diffs from upstream, so resulting patch will just contain my changes not the merges. Did I understand correctly?
<vila> yes, try it ;)
<RenatoSilva> vila: ok thanks.
<RenatoSilva> vila: if I understand correctly: the problem with that second approach is that if I just wait them to accept the patch, it could have passed a long time and merging may become complicated. I think it's better to rather update the patch itself regularly. I could do this with that approach, but I think I'd need to be resolving the same merge conflicts again and again, whereas in the first approach I sort of "save" them as they appear.
<RenatoSilva> *it could have been passed
<tacone> hello, bzr behaves badly when called inside a bash script
<tacone> it says it has added the files, but it throws a Pointless commit error when I try to commit
<RenatoSilva> vila: can't try it while bug 670870 isn't fixed :(
<ubot5> Launchpad bug 670870 in Bazaar Hg Plugin "bzr crashed with ValueError in convert_converted_from()" [High,Triaged] https://launchpad.net/bugs/670870
<tacone> any advice ?
<RenatoSilva> tacone: pastie.org it
<tacone> what do you want me to paste ? bzr.log ? the output ?
<RenatoSilva> tacone: I'm not sure if I can help at all, but I'd paste your call from script, and bzr output
<tacone> http://pastie.org/1376812
<RenatoSilva> tacone: from bzr help add:  "--dry-run will show which files would be added, but not actually add them."
<tacone> omg
<yhager> In bzr-svn, can I just 'bzr checkout' the SVN repo, have people branch this out. Can then changes then be pushed all the way back to SVN?
<yhager> What I mean is: bzr checkout svn://svn svn; bzr branch svn bzr-svn-branch; and then push commits from bzr-svn-branch all the way to svn - is this possible?
<maxb> yes
<maxb> although merging will be required first if anyone commits to svn
<yhager> is there a way to do a lightweight checkout from SVN?
<maxb> I wouldn't recommend it
<maxb> You'd be forcing bzr-svn to reconvert bits and pieces all the time, the performance would be abysmal
<yhager> ok. Is there a way to svn-import partial history, e.g. just the last 6 months?
<RenatoSilva> Any highlight on how to fix this error? http://pastie.org/1377048
<RenatoSilva> bzr-hg is the latest repository version
<poolie> hi all
<spiv> Good morning
<poolie> hey there spiv
<poolie> how are you?
<spiv> Good.  Happy to have https://code.launchpad.net/~spiv/bzr/sprout-does-not-reopen-repo/+merge/41037 unblocked!
<poolie> oh, great
<poolie> i saw the cover letter
<yhager> I found out what causes 'bzr svn-import' to go out of memory - a 600MB iso file was added in a revision. I don't care about that file - can I ignore it for the import?
<poolie> yhager: i don't know of a way to do it
<poolie> yhager: perhaps you can use svn history editing (dump/reload?) to get it out of the history there?
<yhager> poolie: hmm.. Can I do that without access to the subversion server?
<poolie> sorry, no
<yhager> poolie: ok. is the svn dump a format I can edit?
<poolie> i suggest you send mail to the list, and somebody else might know more
<yhager> I opened a bug on this..
<yhager> I'm trying to hack it somehow now..
#bzr 2010-12-15
<wolfrage> Hello, I was wondering what is the impact of using Bazaar Explorer on a Git repository.
<wolfrage> I have all of the proper tools for bzr installed like bzr-git. So far I have just found that it could not pull down a git repository.
<wolfrage> Is any one in here?
<poolie> hi
<poolie> yes
<poolie> what specifically fails?
<yhager> Are there any issues with python 2.7 (bzr, bzr-svn) - that should cause me to use python 2.6?
<spiv> None that I know of
<wolfrage> poolie: Sorry did not notice you responded. Well it appears that the git plugin is read only for git repos.
<wolfrage> poolie: I was hoping to use a nice tool like Bazaar explorer to help me contribute to Telepathy
<wolfrage> poolie: But I have not found a single complete GIT tool, so I guess I will just have to guess at it. and be CLI only.
<poolie> wolfrage: i didn't think it was readonly
<poolie> i think you do have to use 'dpush' rather than 'push', per http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-git-projects.html
<wolfrage> poolie: http://doc.bazaar.canonical.com/plugins/en/git-plugin.html
<poolie> ah, i think think title might just be a bit out of date
<poolie> s//that title
<poolie> the project homepage says "All operations except for "push" are supported"
<wolfrage> hmmm ok, but with dpush I should be able to push the git repo to an online repository
<poolie> what do you mean by online?
<wolfrage> gitorious account
<poolie> you want to push from a local git repo to a remote one?
<poolie> what happens if you try just bzr push?
<wolfrage> yes
<wolfrage> poolie:  stby, it seems to have not error'd this time, one sec.
<RenatoSilva> anyone using bzr-hg can do a test to me?
<wolfrage> poolie: bzr: ERROR: Unsupported protocol for url "git@gitorious.org:wolfrage-telepathy/otr.git"
<wolfrage> poolie: Full out put:  Run command: bzr push git@gitorious.org:wolfrage-telepathy/otr.git
<wolfrage> bzr: ERROR: Unsupported protocol for url "git@gitorious.org:wolfrage-telepathy/otr.git"
<spiv> wolfrage: bzr-git uses URLs like git://...
<wolfrage> spiv: good catch that was for ssh
<spiv> Or git+ssh://
<wolfrage> how would I have it do ssh on git, or is that not possible...
<wolfrage> so this should work then? git+ssh://gitorious.org/wolfrage-telepathy/otr.git
<spiv> Maybe git+ssh://git@gitorious.org/wolfrage-telepathy/otr.git
<spiv> (I'm not a bzr-git expert)
<wolfrage> spiv: k trying
<wolfrage> spiv: Thanks that worked!
<spiv> Great :)
<wolfrage> OK one more question and then I will leave you guys alone for a little while. How can I pull and merge the revisions that have occurred in this repository: http://git.collabora.co.uk/?p=telepathy-spec.git;a=summary and merge them back into mine. More... explanation on the way.
<wolfrage> Basically the repository I have has not been updated for nearly 3 months. I want it up to date before I being to much work on it.
<wolfrage> Is that asking too much?
<wolfrage> That would be a merge right?
<spiv> pull if the revision history hasn't diverged, merge if they have.
<spiv> i.e. pull is good for updating a mirror of another branch, merge is what you use when you have an independent branch and want to incorporate changes from another branch.
<wolfrage> OK this one is independent and has been for almost a year, and last got a update three months ago
<wolfrage> So I should go with a merge.
<wolfrage> when I try to merge it fails with permission denied
<aj00200> poolie: this is aj00200 with that Unicode bug. Thanks for all your help :)
<yhager> poolie: the problem is that bzr tries to load the whole file into memory. This is a real blocker for our team to consider bzr.. :(
<RenatoSilva> let's say I create a branch from upstream release 1.0, then commit my patches, then merge upstream changes, then improve my patches etc. Is there any way to generate a patch for 1.0 release, that is, a diff of the changes since release 1.0 but ignoring all merges?
<fullermd> Not in any remotely automatic way.
<RenatoSilva> I'm thinking on setting up two branches for that, one mypatch-r1.0 as main entry point for improving the patch, and other mypatch-dev from which I merge both upstream and mypatch-r1.0 changes
<fullermd> You could attempt it by a series of cherrypicks.  You could try finding (or building) a patch composition tool and doing the whole diff, then reverses of each merge (sorta the complement of the cherrypick method).
<fullermd> More flippant-cum-HHOS'ly, you could convert it into darcs and then commute the patches  ;)
<spiv> HHOS?  High Horse Of Silliness?
<fullermd> Well, I was thinking Ha Ha Only Serious, but that works too   :p
<RenatoSilva> cherrypicks? flippant-cum-HHOS? darcs?
<fullermd> RenatoSilva: Well, it's a bit yflurgic, but as a TRX it's less nurrific than your average KSTRN-ish arglefarx.   :]
<RenatoSilva> o.O, it seems easier just keeping the two branches
<fullermd> Very probably.
<RenatoSilva> I just thought if I could do something like bzr diff -r 1.. --ignore-merges
<fullermd> That, no.  Trying to actually do it would be decidedly Not That Simple(tm).
<RenatoSilva> ok thanks fullermd
<wolfrage> Wanted to stop back and thank you guys, now with a little bit of GIT on the command line I can run my repository with Bazaar, and do it smartly!
<poolie> excellent
 * spiv -> late lunch
<poolie> mkanat: nice essay :)
<mkanat> poolie: Thanks!
<vila> hi all
<jelmer> g'morning Vincent
<vila> jelmer: heya !
<vila> jelmer: I submitted a mp for bzr-search fixing the failing tests
<jelmer> \o/
<jelmer> vila: I submitted a MP for most bzr-xmloutput test failures (only one left) earlier
<vila> jelmer: I digged the xmloutput a bit more... and it's even more obscure now, I ... huh ?
<vila> jelmer: meh, there was only one failure when I started...
<vila> let me see your mp...
<jelmer> vila: the daily build is failing with 4
<vila> meh, I was pretty sure the custom escape_data was already fixed....
<vila> mgz: escape_data xmloutput, can you refresh my memory ?
<jelmer> vila: it may not be an issue when the in-tree elementtree is used
<vila> hmm, could it be py27 related ?
<vila> jelmer: or is it that you're using 0.8.6 and I use trunk ?
<vila> jelmer: qlog says: look at revno 147
<jelmer> vila: I'm using lp:bzr-xmloutput and indeed python 2.7
<vila> jelmer: bzr-xmloutput-0.8.6+bzr148~ppa112+113~natty1 should include it which means... meh wth
<vila> jelmer: right, which should mean the bzrlib.xml_serializer logic needs one more fix for 2.7 ?
<vila> jelmer: and your remaining failure is for test_info (which is the one I'm digging)
<jelmer> vila: the remaining failure for me is bzrlib.plugins.xmloutput.tests.test_info_xml.TestInfoXml.test_info_locking
<vila> yup, a single test to test 8 combinations, I've got a parameterized version now with 2 failures and 3 errors
<jelmer> vila: also, more test failures in the natty bzr daily build :-/
<wolfrage> I am using Bazaar Explorer with a GIT repo, and I am trying to push a commit to my remote branch, as an update. But I keep getting this:
<wolfrage> Run command: bzr push
<vila> but at this point I need to talk to verterok as the intent of the xmlinfo command is unclear
<wolfrage> error: refusing to create funny ref 'None' remotely
<wolfrage> bzr: ERROR: None failed to update
<jelmer> vila: I see the timestamp error you mentioned earlier, but also: "AttributeError: 'InstrumentedTestResult' object has no attribute 'report_error'"
<vila> jelmer: the later sounds like a testtools version mismatch
<poolie> hi vila!
<vila> poolie: hello !
<jelmer> vila: Ahm, hmm
<jelmer> 'evening poolie
<vila> jelmer: argh, you're using testtools trunk
<vila> jelmer: did I complain yesterday about you *not* using trunk ?
<vila> :D
<vila> doomed if you do, doomed if you don't :D
<jelmer> vila: :-) I'm surprised it only breaks on natty though, not on Maverick
<jelmer> wolfrage: hi
<jelmer> wolfrage: "bzr push" won't work for git branches, you can only "bzr dpush" (though arguably the error message should be clearer)
<vila> jelmer: It's a zen thing, testtools failures causes are of an infinite nature
<wolfrage> jelmer: Hi sorry about the interupt
<vila> jelmer: that's because when you test, you want to always be prepared to accept new failures, zen thing...
<wolfrage> jelmer: ahh, I see. I got confident as it was able to push it as a new branch. But I guess updates will not. Since I am using Explorer, if i run the command "bzr dpush" do I need any other parameters?
<jelmer> wolfrage: I'd be very surprised if it was able to push it as a new branch
<jelmer> wolfrage: bzr dpush requires the URL to the branch to push to
<jelmer> vila: :)
<wolfrage> jelmer: I was surprised too, but poolie was talking to me at the time that it did it. | Ok I will give it a go with the url attached. Thank you.
<vila> jelmer: the daily builds are a nice complement to babune, but we face a common issue here: the combinations and their related failures can be daunting at times
<wolfrage> jelmer: does the command need any dashes "bzr dpush --url" or just "bzr dpush url"
<jelmer> wolfrage: just "bzr dpush <url>", much like you would use "bzr push"
<jelmer> vila: The intent isn't really to provide CI but rather to allow users to more easily follow current trunk, I'd rather catch these errors before we'd actually get to the package building stage.
<vila> jelmer: hehe, but isn't that the intent of CI ? :D
<vila> jelmer: don't get me wrong, I'm very happy about the daily builds, they address combinations that I can't address so far in babune (not do I really plan to address ;)
<vila> s/not do/nor do/
<wolfrage> jelmer: did not work is it ok to post the error?
<jelmer> vila: Yeah, I guess that's also a form of QI :-)
<jelmer> wolfrage: sure
<jelmer> vila: Errhm, CI
 * jelmer clearly has been watching too much QI lately
<wolfrage> jelmer: Run command: bzr dpush git+ssh://git@gitorious.org/wolfrage-telepathy/otr.git
<wolfrage> bzr: ERROR: <LocalGitBranch('file:///home/wolfrage/Programing/git/telepathy/otr/', 'HEAD')> and <RemoteGitBranch('git+ssh://git@gitorious.org/wolfrage-telepathy/otr.git', 'HEAD')> are in the same VCS, lossy push not necessary. Please use regular push.
<vila> jelmer: :)
 * wolfrage thinks that is a good show.
<jelmer> wolfrage: ah, you've got a git repository locally that you're pushing from, not a bzr branch?
<wolfrage> jelmer: Sorry thought I included that detail
<jelmer> wolfrage: I figured you were pushing from a local bzr branch to a remote git branch, I didn't realise you had a git branch locally as well.
<wolfrage> Yes using bzr-git to push my local git to a remote git
<jelmer> vila: I'll chase down the testtools error. Do you have any idea about the timestamp?
<jelmer> wolfrage: in that case "bzr push" is indeed the right thing to use, can you file a bug about the issue you saw?
<vila> jelmer: not from the top of my head, pretty surprising
<vila> jelmer: but I vaguely remember something like that happening in the past
<wolfrage> jelmer: sure. I was wondering should it be filled under bzr on launchpad or is there a bzr-git
<jelmer> wolfrage: there's a separate bzr-git project
<wolfrage> jelmer: copy.
<wolfrage> jelmer: Bug #690547   https://bugs.launchpad.net/bzr-git/+bug/690547
<ubot5> Ubuntu bug 690547 in Bazaar Git Plugin "GIT to GIT bzr push Fails "funny ref 'None' remotely"" [Undecided,New]
<ubot5> Launchpad bug 690547 in Bazaar Git Plugin "GIT to GIT bzr push Fails "funny ref 'None' remotely"" [Undecided,New] https://launchpad.net/bugs/690547
<jelmer> wolfrage: any chance you can add the relevant error log in ~/.bzr.log as well?
<jelmer> wolfrage: the fix is probably that we should push to refs/heads/master, something that we're not explicitly doing at the moment
<wolfrage> jelmer: Working attachment.  Interesting, It somehow committed a delete of the branch. It is ok, but not sure how that happened. Or maybe Gitorious just screwed up. GIT makes my head hurt
<wolfrage> jelmer: Is it ok if I delete my email out of the logs.
<jelmer> wolfrage: of course
<wolfrage> jelmer: As soon as it finishes what it is doing currently I will submit the log.
<wolfrage> jelmer: I wanted to know I see how to add files to a git with bzr but how do I remove them?
<jelmer> wolfrage: it should be the same as regular bazaar
<jelmer> wolfrage: please note though that bzr-git's main focus so far has been on interoperating with remote git repositories, the local support is still quite experimental - in particular as we can't really map the git index to anything in bzr
<wolfrage> jelmer: I know I am asking alot of the software, unfortunately all of the other GIT tools can not stack up to Bazaar Explorer, which is sad considering it was made for bzr not GIT. But it is helping me to contribute to the community because of it's versatility.
<wolfrage> jelmer: I do hope that you will not mind me making more bugs though as I find them. It seems that Add has no effect and Remove fails with permission denied which makes no sense as I own all of the files and directories.
<jelmer> wolfrage: no, please do file more bugs
<jelmer> wolfrage: please note though that these don't have a high priority for me at the moment, I'm mainly concentrating on the remote git repo use case
<jelmer> wolfrage: patches are very much welcome though
<wolfrage> jelmer: OK I understand priorities. I just appreciate that the Software has helped me along this far. I really was not impressed by the other GIT tools.
<wolfrage> jelmer: LOL, After I get through with Telepathy, then I will come back over here. But I can only tackle so many bugs at once too. lol.
<wolfrage> jelmer: Log is attached, The error is at least a few operations back. But it was attempted multiple times.
<vila> spiv: changing signatures for branch creation broke looms :-/
<RenatoSilva> I have deleted the hg directory from plugins dir but it's still showing up in bzr plugins: hg 0.2.0dev in  C:\Program Files\Bazaar\plugins\hg.
<RenatoSilva> How to purge it?
<RenatoSilva> bzr hg-import is even running. How can that be? It's like bzr-hg is cached somehwere?!
<RenatoSilva> c:\>ls   "C:\Program Files\Bazaar\plugins\hg" => __init__.pyo  commands.pyo  info.pyo  revspec.pyo
<RenatoSilva> c:\>dir "C:\Program Files\Bazaar\plugins\hg" => not found o.O
<vila> RenatoSilva: 'bzr plugins -v' should tell you
<RenatoSilva> vila: (11:07:02) RenatoSilva: [...] but it's still showing up in bzr plugins: hg 0.2.0dev in  C:\Program Files\Bazaar\plugins\hg.
<RenatoSilva> vila: where I got that path with -v
<RenatoSilva> vila: seems a crazy windows 7 bug, I just rm -r'ed  it
<vila> RenatoSilva: then it's probably windows specific and the plugin may be in bzrlib.zip
<vila> RenatoSilva: see if you can reinstall bzr without the plugin
<RenatoSilva> vila: I removed it with rm -r
<RenatoSilva> vila: bzr-hg now disappeared
<vila> RenatoSilva: *I* understand and trust you, yet, bzr plugins -v seems to disagree with you
<RenatoSilva> vila: it was like the hg dir was still existing in the filesystem "partially". For explorer and dir, it didn't exist, but for bzr and ls and rm it did
<vila> RenatoSilva: try a reboot first to exclude nasty caches (doubtless)
<jelmer> somebody else ran into similar problems
<vila> meh, why do I say doubtless when I doubt...
<vila> yup, as jelmer says, this rings a bell
<RenatoSilva> vila: I removed hg dir yesterday, and turned pc on today, and the issue was there
<vila> wowwwww
<jelmer> I'm not sure if it was windows 7 as well, but it seems like the GUI doesn't always display the actual contents
<RenatoSilva> vila: not sure if it's clear but after rm -r, bzr plugins doesn't list bzr-hg anymore
 * vila blinks
<jelmer> RenatoSilva: what do you mean with rm -r though?
<vila> RenatoSilva: no, it's not clear
<RenatoSilva> jelmer: I thought about that, but I could create the hg dir in explorer!
<RenatoSilva> jelmer: at the same time hg was already there (for some tools)
<RenatoSilva> let me explain again form beginning. I removed bzr-hg yesterday by deleting C:\Program Files\Bazaar\plugins\hg. Today I turned computer on and noted that it was still there in bzr plugins. The -v options was showing that exact path. I went to explorer, and it wasn't there. I went to win32 terminal, and dir command couldn't find it.
<RenatoSilva> But ls.exe could (I have MSYS)! And so rm.exe. Weirdly, I could create the hg dir again in explorer, even with it already existing for ls and bzr
<RenatoSilva> So I just tried rm -r /c/Program Files/Bazaar/plugins/hg, and it worked, bzr plugins stopped showing bzr-hg in the list
<RenatoSilva> * the -v option
<awilkins> Is there a gitstats for Bazaar? If (e.g.) gitstats worked internally on git-fast-export format (don't know if it does), it would work for anything that had a fast-export frontend, no?
<mgz> vila/jelmer: yes, that xmloutput thing was fixed on both trunks
<mgz> I'm not sure what the failures were from
<mgz> but looking at <https://code.launchpad.net/~jelmer/bzr-xmloutput/fix-tests/+merge/43738> I'm a little concerned
<vila> mgz: including python 2.7 ?
<vila> mgz: by the way, I nailed the last failures on osx 10.6 only to be bitten by a new one ;)
<mgz> just seen that as well and will review.
<jelmer> mgz: I still get them on trunk:
<jelmer> TypeError: _escape_cdata() takes exactly 2 arguments (1 given)
<vila> mgz: patch awaiting review... too fast :)
<mgz> anyway, not using a function from bzrlib.xmlserialiser would be fine
<mgz> but the one you've written in does less than the etree one, which was already insufficient
<jelmer> mgz: the only difference with the etree one is that it doesn't take an encoding argument
<mgz> right, so... passing non-ascii either unicode or bytes becomes risky.
<mgz> it's a bad interface which doesn't help, but it's even easier to use incorrectly now.
<jelmer> mgz: we weren't passing an encoding before either
<jelmer> mgz: so that situation doesn't really change
<mgz> no, but the etree 1.3 function defended against bad bytestrings
<mgz> also, string.replace jelmer? how retro are we? :)
<jelmer> mgz: I just took whatever etree was using :-) I guess that can be text.replace now, indeed...
<mgz> the problem in the first place was etree changed this function, which python 2.7 picked up.
<mgz> I'd like to just make xmloutput less retarded about xml generation, but that's a big job.
<mgz> anyway, I'll look into why you were getting failures, I thought I'd checked different version combinations
<mgz> wasn't helped by most of the bzr-xmloutput test suite failing here.
<jelmer> mgz: FWIW I don't think we can use the stock _escape_cdata since it always encodes in python 2.7
<mgz> well, it's a question of which misuse we want to break
<mgz> most of xmloutput happens to work because the data is ascii, it's not hard to break it.
<jelmer> mgz: there are more than a few places where the text passed into _escape_cdata is unicode, and the caller expects it to come back as unicode too
<mgz> okay, yep, this is a problem.
<mgz> will put review in that mp.
<RenatoSilva> mgz: what do you mean with xmloutput less retarded about xml generation?
<mgz> it's doing the print statement and string interpolation approach
<RenatoSilva> I think I've found a bug: http://pastie.org/1379843, that error pops up on a gui dialog and then qlog list commits without the messages
<mgz> this can work if you're an expert about what the xml spec says, but anyone normal just gets it wrong in all kinds of edge cases.
<mgz> vila: jam's reviewed your mp already, so I don't need to :)
<vila> mgz: indeed :)
<vila> jam: thanks and hi !
<RenatoSilva> mgz: I dealed with some xmloutput weaknesses some time ago, and some of them still exist
<RenatoSilva> mgz: I contributed some patches for encoding fixes, but work is still needed
<mgz> example of some wrongness:
<mgz> except Exception, e:
<mgz>     xml += '<error><message>%s</message></error>' % \
<mgz>         _escape_cdata(str(e))
<RenatoSilva> mgz: for example, bzr xmlstatus is putting cp1252 in the preamble, which is W3C invalid iirc
<mgz> what happens if the exception instance stringifies to non-ascii?
<RenatoSilva> well for sure, cp1252 is not a proper encoding
<mgz> that depends on in iana.
<mgz> some of the cp* encodings are listed, some (like cp932, which would actually be useful) aren't.
<mgz> *on the iana.
<mgz> http://www.iana.org/assignments/character-sets <- allows "windows-1252"
<mgz> they should just add the "cp" prefix as an alias to all windows numbered encodings they list there
<mgz> instead of it being pot-luck.
<mgz> anyway, there's an easy fix xmloutput could use
<mgz> the output-based-on-terminal-encoding is just daft.
<mgz> should instead either do utf-8 with no prologue, iff the terminal is utf-8, or ascii with &#...; escaping.
<mgz> but that means touching all the output code, which I don't want to do without actually making it robust.
<awilkins> Some things don't even like UTF-8 AFAIK. The MS libraries had a bug where they would emit Â¬ characters happily enough and then drop dead trying to parse their own output.
<RenatoSilva> xml needs prologue
<RenatoSilva> I mean, if you have a chance to tell what encoding it is, why not say? tools reading that output will need to guess it's utf-8 if you don't declare it
<mgz> nope, it's speced very clearly.
<mgz> without prologue, it depends on the bom, without bom it's utf-8
<RenatoSilva> mgz: what you're saying is addressed in bug 394943
<ubot5> Launchpad bug 394943 in bzr-xmloutput "Declared and actual XML encoding should match, and the encoding should be XML valid" [High,Confirmed] https://launchpad.net/bugs/394943
<mgz> thus, if you want a utf-8 xml document, ommitting the prologue is fine.
<awilkins> Indeed. Many things just use the platform encoding by default (esp Java which assumes that all InputStream is the JVM encoding - which is cp1252 (or whatever the equivalent is) on Windows
<RenatoSilva> mgz: without bom it's utf-8? how can you guess that? you know because you make bzr-xmloutput do it, but apps doesn't have a way to know it
<RenatoSilva> "without prologue, it depends on the bom, without bom it's utf-8", do you mean this is the XML spec? iirc it doesn't even allow you to remove the prologue
<awilkins> BOMs are a PITA anyway ; so many tools don't handle them right, so many XML output encoders don't write one (although some do).
<RenatoSilva> http://www.w3.org/TR/2008/REC-xml-20081126/#dt-xmldecl
<mgz> note that's not a MUST.
<awilkins> A SHOULD requirement is probably something you ... should .. make the effort to implement. The BOM thing is a MAY for UTF-8 ; and I'd prefer to see it left off because it will break casual compatibility with many tools if left in.
<RenatoSilva> awilkins: why would xml generators choose BOM over preamble, specially when BOMs are a PITA, and W3C obligates you to write a preamble? :P
<awilkins> RenatoSilva, Oh, quite - I'd rather not see BOM, and I'd prefer a preamble.
<RenatoSilva> does it stand must != should? I didn't know that
<RenatoSilva> because in dictionary, you must do it is the same as you should do it afaik
<mgz> yes, and given the way things have developed, even SHOULD is a little strong.
<awilkins> If you neglect a MUST you've not met the standard - missing a SHOULD will attract "tch, tch" and frowns but not get you labelled non-compliant.
<awilkins> And a MAY is a nice-to-have.
<mgz> see 4.3.3 as well, which has some encoding specific directives.
<awilkins> AFAIK cp1252 is the same as ISO_8859_1
<mgz> anyway, for this plugin none of this should matter regardless of the terminal encoding
<mgz> awilkins: nope, it swaps out the C1 control characters for some extra glyphs
<awilkins> Gah, MS at their finest.
<mgz> ^shouldn't matter, because unlike rio which causes issues here, xml *does* have a proper escpaing mechanism if the encoding can't represent a character
<RenatoSilva> afaik cp1252 is a superset of latin1
<RenatoSilva> mgz: see comments 15-18 in bug 394943
<ubot5> Launchpad bug 394943 in bzr-xmloutput "Declared and actual XML encoding should match, and the encoding should be XML valid" [High,Confirmed] https://launchpad.net/bugs/394943
<mgz> not printing mojibake is always worth while.
<mgz> it's only hard to fix because the code is a mess, particularly over what's unicode, what are bytestrings, and so on.
<RenatoSilva> anyway, does the xml spec stand that if an xml misses encoding declaration, you can use boms to inform the encoding, and does it say if there's no bom you shall read it as utf-8???? this sounds weird
<mgz> yes, see 4.3.3
<RenatoSilva> mgz: yeah that bug is hard to fix because the whole code needs to be checked
<mgz> it's worded at little backwards, but:
<mgz> "...it is a fatal error for an entity including an encoding declaration to be presented to the XML processor in an encoding other than that named in the declaration, or for an entity which begins with neither a Byte Order Mark nor an encoding declaration to use an encoding other than UTF-8."
<mgz> is there something more general as well...
<RenatoSilva> mgz: "In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 MUST begin with a text declaration"
<mgz> right, "other than"
<mgz> so, utf encodings don't need it.
<RenatoSilva> mgz: imho this is pretty much a fallback is case there's no way to know what encoding it is than it's stimulating you to not use the xml preamble. As the doc says, you must not, but you should, use preambles. Unless you have a specific good reason for not using:
<RenatoSilva> mgz: "SHOULD This word, or the adjective "RECOMMENDED", mean that there    may exist valid reasons in particular circumstances to ignore a    particular item, but the full implications must be understood and    carefully weighed before choosing a different course. "
<mgz> right, and that was reasonable advice.
<mgz> but in the years since the spec was written, no other version of xml has gained traction, and utf-8 is increasingly the default encoding everywhere.
<mgz> so it's less important than it was to state the bleeding obvious.
<RenatoSilva> well anyway, I'd recommend not removing the preamble, it doesn't hurt anyway. And I disagree, as I think you disagree too, with bzr-xmloutput trying to guess the output encoding to use. It should use a single static encoding, preferably utf8.
<mgz> I'm not quite saying that.
<mgz> There's no reason to print utf-8 to a non-utf-8 terminal, so it should just not do that.
<mgz> which is trivial.
<RenatoSilva> I don't get you
<RenatoSilva> bzr-xmloutput is not supposed to be used in a terminal
<mgz> the annotated xml spec is informative on the thinking at the time.
<RenatoSilva> ?
<mgz> http://www.xml.com/axml/notes/Enc1.html "Very little of the world's text is stored in Unicode encodings"
<mgz> http://www.xml.com/axml/notes/ASCII.html "As the spec says, pure ASCII files are UTF-8 as they sit, and thus don't require an encoding declaration. The problem is that a lot of ASCII files are not quite pure."
<mgz> ^ it's not intended to be, but these things do get used on the terminal, where's that version-info bug...
<mgz> and as it's trivial to avoid printing junk to a terminal, it should.
<RenatoSilva> why would one use bzr-xmloutput in terminal? examples?
<Peng> Spent too much time working on web apps and can't read plain text anymore? :P
<mgz> see bug 518609
<RenatoSilva> mgz: I personally don't like the idea of converting non-ascii to XML char entities
<ubot5> Launchpad bug 518609 in Bazaar "Unicode exception occurs by "version-info"" [Medium,Fix released] https://launchpad.net/bugs/518609
<mgz> there's no reason to use that command rather than one that works, but we got three bugs filed about it.
<mgz> Renato, I think you're overestimating how hard it is to conditionally escape characters if a terminal is detected.
<mgz> it's like, three lines of code in a well constructed program.
<vila> mgz: for values of 'well' known long after the program has been written :-P
<vila> mgz: not that I disagree ;-)
<RenatoSilva> mgz: how about version-info, what does it have to do with xmloutput?
<mgz> it's an internal-use command with escaping issues.
<RenatoSilva> mgz: sorry, and how does this take you to "I must now use xmloutut"?
<RenatoSilva> mgz: do you mean xmloutput has an xml version for that command and it does work?
<mgz> no, I'm just pointing out that it's easier to write a command correctly than assume people won't try and break it.
<mgz> anyway, I now need to go and clean the house before I get yelled at.
<RenatoSilva> ok, but back to the question, why one would use bzr-xmloutput in terminal? it's not supposed to be used there. If you want to use it, then use a terminal with utf8 support. That won't be a problem for Linux users, not even for Windows users, they can chcp 650001 before command call.
<vila> mgz: nah, nobody will yell at you for cleaning xmloutput :)
<RenatoSilva> So I really see no reason for xmloutput caring about terminal encoding. It should use a static utf8 encoding, that will make the actual use of xmloutut a lot easier (in bzr-java-lib, bzr-eclipse etc)
<mgz> I think you think I'm suggesting something I'm not.
<vila> :)
<RenatoSilva> what's funny about xmloutput at the moment is that it's more crazy than before, because it mostly used to declare utf-8 and write something else, but now it gets some system default encoding and writes based on the terminal encoding, or something like that (for example win32 console is cp850, and so it is xml output, but declared as cp1252)
<RenatoSilva> (continuing the example, but if I use mintty, which is not a proper win32 console, it writes latin1 bytes)
<mgz> I am getting yelled at.
<mgz> look, all it needs is something like:
<mgz> output = sys.stdout
<mgz> if getattr(output, "encoding", None) != "utf-8":
<mgz>     output = codecs.lookup("ascii")[3](output, "xmlescape")
<mgz> and a proper method of writing xml rather than the current mess.
<mgz> (which is the hard bit)
<mgz> writing that is easier than saying Don't Do That whenever someone accidentally uses an xml command on a non-utf terminal, and proper parsers are perfectly capable of handling numeric entities
<RenatoSilva> I don't like escaping chars to xml entities
<RenatoSilva> I'd rather go with just printing the actual char
<jelmer> RenatoSilva: that may not be possible
<RenatoSilva> jelmer: why not?
<mgz> you prefer UnicodeEncodeError bug reports?
<mgz> this sounds like a pretty irrational fear, and not one you'd ever actually encouter
<RenatoSilva> mgz: iirc there's a way to print bytes to stdout, without encoding mess
<mgz> either, as you say, no one ever prints this to a terminal, in which case you never see it
<RenatoSilva> mgz: in a way that you delegate the encoding mess to the terminal or what reads stdout
<mgz> or someone does try that, and you want bzr to break rather than show them something understandable.
<jelmer> RenatoSilva: the characters might be utf8 while the terminal is iso8859-9, so some characters would not be printable.
<mgz> anyway, this is trivia, and really didn't need this much discussion.
<RenatoSilva> jelmer: there's no terminal, bzr xml-output is not to be used in a terminal
<mgz> what we've been talking about for half an hour has nothing to do with the actual bug that exists, or what needs to be done to fix it.
<RenatoSilva> jelmer: even if so, then the user just changes terminal's encoding before running xmloutput
<mgz> so I'm really going/
<jelmer> RenatoSilva: So the user has to be told to change their encoding (which might be nontrivial)
<RenatoSilva> mgz: I don't like your idea of entities that's why I'm discussing. I suspect it would break bzr-java-lib and bzr-eclipse more than they already are
<jelmer> RenatoSilva: I don't see what is problematic about entities.
<jelmer> RenatoSilva: Then we should fix them, don't they use standard XML parsing libraires?
<RenatoSilva> jelmer: ok xml parsers should be ok with that, but not sure if bzr-java-lib and bzr-eclipse will be ok. Kind of a feeling from having writing some patches to them
<RenatoSilva> jelmer: I'm not sure on the exact purpose of entities but why allow non-ascii in XML then? I mean, why not make XML standard ascii-only with using char entities for specifying non-ascii?
<jelmer> RenatoSilva: If they don't use standard XML parsing libraries then I suspect we have worse things to worry about.
<RenatoSilva> jelmer: I wouldn't be surprised if they don't, that's what I mean :)
<jelmer> RenatoSilva: That's possible but can use significantly more disk space for some languages if e.g. the document is stored as UTF16.
<RenatoSilva> jelmer: so it's an alternative for when there's a reason for using them
<jelmer> RenatoSilva: and I think this is a perfectly valid situation to use them
<RenatoSilva> jelmer: for example you need to send the xml somewhere but before it gets there something reads it and tries to decode it as it was ascii-only, raising errors. So you use entities as workaround for the xml passing fine over it and getting fine in the destination
<RenatoSilva> jelmer: well I don't think making things pretty to crazy users reading xml output in terminal rather than using the regular bzr commands is a good reason, it's just that what I think.
<jelmer> RenatoSilva: I don't think it's a very big deal, but it does mean we get to avoid a bunch of encoding-related issues.  And I haven't heard any disadvantages of using entities yet.
 * maxb skims scrollback and asks: Use entities for which characters, precisely?
<jelmer> maxb: characters that can't be represented using current terminal's encoding
<maxb> That seems sane, just so long as the current encoding in the absence of a terminal being involved isn't affected by the system's terminal encoding
<RenatoSilva> maxb: but the command in question is not supposed to be used in terminal, so why care so much about crazy users doing it?
<maxb> RenatoSilva: because it's a hopefully simple way to do something reasonable in a terminal. Doing something reasonable rather than erroring outright is better.
<RenatoSilva> maxb: as I said iirc there's a way to send raw bytes to stdout in python, so no exception would be raised. The only issue would be junk in terminal, but who cares? The user should not be doing that anyway. Besides, it's easy to fix, because Linux terminals support utf8, and in windows it's just chcp65001
<maxb> RenatoSilva: Your proposal would be acceptable behaviour, IMO, but if we can do better with little effort, why not do so?
<RenatoSilva> maxb: the issues I have seen with bzr-xmloutput, bzr-java-lib and bzr-eclipse, were related to doing things wrong, not simply by the pure fact of not having chars represented as entities
<maxb> OOI, what is the way to send raw bytes to stdout?
<maxb> RenatoSilva: "Let's emit XML that is compatible with the terminal encoding" is not incompatible with "Let's do things right". You seem to be suggesting otherwise.
 * jelmer -> foods
<RenatoSilva> maxb: "Let's emit XML that is compatible with the terminal encoding"
<RenatoSilva> maxb: that's valid for commands supposed to be run in terminal, not bzr-xmloutput. Besides, I see it from the opposite perspective, like the natural, and hence good way is having the actual bytes, then I start to think of the advantages of converting to entities, and I see no reason for that, in the specific case of xmloutput :)
<maxb> Your goal is to get valid data out for programmatic use. Other people may also have the goal of XML that is valid if copy/pasted from a terminal. The two goals are not incompatible
<RenatoSilva> maxb: convert actual bytes to entities, then converting them back to the same actual bytes. I just think this is useless overhead (ok it's useful for displaying in terminal, but still useless, because terminals are not for xmloutput)
<maxb> There is no useless overhead, because if you're writing to a pipe to another program, you'd be operating in UTF-8, and the only entities you'd be using are the five basic ones to escape characters that have meaning in XML itself
<RenatoSilva> I may have the goal of xmloutput making some coffee, but that doesn't mean it makes sense so that developers should work on it :P
<jelmer> RenatoSilva: if converting encoding and decoding special characters to entities has an overhead that's in any way noticable overhead then you're transmitting way too much data with XML anyway.
<maxb> Anyone know a good document about the guts of python's stdout encoding handling I could read?
<RenatoSilva> jelmer: I'm not sure if I understood correctly, but the idea is convert every non-ascii char into a xml char entity, right? So that the data is ascii-only, right? Well imagine you use bzr-eclipse to fetch the commit logs on a sufficiently big branch, it may become slow enough for being annoying.
<maxb> RenatoSilva: no, only convert characters not representable in the target encoding
<jelmer> RenatoSilva: Other things will hit you much much worse.
<RenatoSilva> jelmer: I just had an insight, why discuss this so much, xmloutput could just have an argument for that :D like --use-entities or --use-actual-bytes :)
<jelmer> RenatoSilva: the character conversion won't have any noticable impact
<maxb> ew. NO>
<jelmer> maxb: what are you saying no to ? :-)
<maxb> Pointless options are fail, both for understandability and maintainability
<RenatoSilva> maxb: ah ok so it's using entities only for unrecognized byte sequences? ok, but converting to entity doesn't really fix the problem, it just changes from python unicode exceptions from some more high level error in the application which will be fed with such crazy data
<RenatoSilva> maxb: not that I disagree with that, but just noting
<jelmer> RenatoSilva: The application is very likely able to deal with unicode
<RenatoSilva> maxb: the proper fix is to find out why the xml is getting invalid chars inside it
<jelmer> RenatoSilva: that's the point, the XML isn't getting invalid characters in it
<jelmer> it's just getting characters that can't be encoded for the current terminal.
<RenatoSilva> jelmer: but how about the invalid chars which were changed into entities. I'm not sure if parsers will convert those invalid-char entities back to the actual bytes, or will leave it out for who's reading, but either way, the application will get invalid input. Either with the data containing entities or the actual invalid bytes, the app will crash on processing it.
<RenatoSilva> jelmer: ah ok, so the problem is parsing errors due to the actual bytes, I see
<jelmer> RenatoSilva: which invalid characters are you talking about?
<RenatoSilva> jelmer: (16:44:04) maxb: RenatoSilva: no, only convert characters not representable in the target encoding
<jelmer> RenatoSilva: right, those are unprintable targets.. they're not invalid in any way
<jelmer> and they're only unprintable in the context of the terminal
 * RenatoSilva confused
 * jelmer really goes to get some food now
<RenatoSilva> I think I understand a bit better now
<RenatoSilva> but I agree only if it's for terminal
<RenatoSilva> in mgz's example,  if getattr(output, "encoding", None) != "utf-8": output = codecs.lookup("ascii")[3](output, "xmlescape")
<RenatoSilva> what if it's None, how will output behave, since there's no target encoding to check compatibility to
<mgz> ...how is this conversation still going on?
<lifeless> what if what is None ?
<mgz> RenatoSilva: could make no encoding attribute do plain utf-8, it doesn't really matter.
<mgz> would just involve changing the test and an else clause.
<RenatoSilva> lifeless: the encoding returned by getattr(output, "encoding", None). Since there's no target encoding (it's None), I wonder how entities will be handled in that example, will they be generated for every non-ascii char or for no char at all?
<RenatoSilva> lifeless: specially, it's None when redirecting to files, or using pipes I suppose, so I wonder what will be the behavior. Because if it's a pipe or file, there isn't really sense, imho, in generating the entities. But for terminals, ok, it doesn't hurt.
<smoser> so on fresh lucid install:
<smoser> $ bzr branch lp:qa-regression-testing
<smoser> You have not informed bzr of your Launchpad ID, and you must do this to
<smoser> write to Launchpad or access private data.  See "bzr help launchpad-login".
<smoser> bzr: ERROR: [Errno 4] Interrupted system call
<smoser> i see evidence that this is fixed in 2.1.2.
<lifeless> RenatoSilva: if its not, it will encode to an ascii encoding with xml escaping, no ?
<smoser> evidence at http://doc.bazaar.canonical.com/development/en/release-notes/bzr-2.1.2.html . is there an explicit bug that i should ask be made available in -updates ?
<RenatoSilva> lifeless: not sure if you followed but I was talking about mgz's example:  if getattr(output, "encoding", None) != "utf-8": output = codecs.lookup("ascii")[3](output, "xmlescape")
<RenatoSilva> lifeless: if it's not == if stdout is not a pipe/file?
<RenatoSilva> how got another crazy error with bzr qlog in bzr-eclipse
<RenatoSilva> looks like new versions of bzr have compatibility problems with old branches
<RenatoSilva> s/how/wow
<mgz> there's no need to get hung up on that example, as an exercise feel free to write your own version.
<mgz> but this discussion ceased to be useful about... well, I'm not sure it was ever useful.
<mgz> corner case behaviour with encoding attributes is not what's breaking things for you, nor is anything else we've talked about.
<RenatoSilva> mgz: ok I just mean that would be interesting for non-utf8 terminals *only*, so it would need a way to check if stdout is a terminal, something like posix's isatty
<mgz> as I said, feel free to write your own example.
<RenatoSilva> ok
<mgz> it's not actually making progress on fixing the bugs here, but whatever.
<RenatoSilva> heh true
<lifeless> mgz: hi
<lifeless> mgz: can you reproduce jams testtools failures?
<mgz> lifeless: no. see the log from the other day.
<mgz> and he's not been on at the same time as me since so haven't been able to bug him further about it.
<mgz> ah, I see he said 2.6.4 at three that morning, I could try backing up my build to that minor version.
<wolfrage> So I have a small problem. I used Bazaar Log and reverted my Git Repo to an earlier revision, just one. But GIT on the command line still shows fine. But Bazaar explorer shows like there are uncommited files.
<wolfrage> How do I get Bazaar Ecplorer to see that there are no changes to be made.
<maxb> The meaning of "bzr revert" is quite different from "git revert"
<wolfrage> ok How do i tell bzr to go back to where it was
<wolfrage> even if i choose update, it says that it is up to date, but yet it differs from working branch
<wolfrage> So did i change the branch some how
<lifeless> wolfrage: if bzr diff shows changes, then the tip commit refers to different content than is in your working tree
<lifeless> wolfrage: I don't understand how git is related to your question though
<wolfrage> lifeless: it is a local git repository. I am using bazaar to work on it, because it seems to work great as compared to the other tools
<wolfrage> I used Bazaar to work through a rebase in git, and it helped alot.
<wolfrage> lifeless: But now I did this revert and Bazaar shows the working tree is different. I just want all of the error messages to go away so i can continue to use it on this GIT repo agian. i will not play around with it agian like that once I do
<wolfrage> lifeless: So how do I move the tip back to the working tree
<lifeless> what was the revert you did, in git?
<lifeless> jelmer, the author of bzr-git would be a great person to ask about this (you are using bzr-git?) but hes not around right now
<wolfrage> well I did it in Bazaar explorer, GIT still shows same status. In Bazaar I was in the log and told it to revert to the revision just before the last.
<wolfrage> lifeless: I was talking to jelmer earlier about a seperate issue, he is very helpful, and yes I am using bzr-git
<lifeless> ok, so in bzr-explorer you said 'revert'
<lifeless> what that does is changes the working tree *only*
<wolfrage> lifeless: yes
<lifeless> if you reverted to a particular revision using bzr-explorer
<lifeless> to under it, just do 'revert' without a particular revision, again using bzr explorer
<wolfrage> lifeless: OK. I appreciate you taking the time to explian it to me also.
<lifeless> this will force all your files to be the same as tip.
<lifeless> then, if you want to rollback the branch to a particular revision, you can use uncommit, or pull
<RenatoSilva> is it normal to revolve functional merge conflicts on a following commit, not in the merge commit?
<RenatoSilva> I think this helps clarifying things
<RenatoSilva> the merge I did fixed a problem, but my patch made it come back again, so it's a merge issue. I'm thinking of uncommitting  the merge (it's the last commit) and applying it there, or just commit a new change referring to the merge in comment
<wolfrage> lifeless: It did not work, it says no revisions to be pulled and for the revert it just runs with no error, but Bazaar remains the same after a refresh.
<wolfrage> lifeless: What if i deleted the bzr folder
<RenatoSilva> it didn't exactly made it come back again, but sort of
<wolfrage> lifeless: in the git repo, would that revert it?
<wolfrage> lifeless: I take it back there is a bzr folder with in .git, but it is just file lock.
<RenatoSilva> btw, is there any way to see only the merge changes? That is, when you click over the merge in bzr qlog, you see changes made by the merged branch and changes made due to the merge itself. I'd like to see only the latter
<lifeless> RenatoSilva: yes, the difftastic plugin
<lifeless> wolfrage: sorry, I'm not sure whats going on there
<lifeless> 'revert' with no revision + bzr diff should always show nothing
<lifeless> if its not, its a bzr-git interaction - could you file a bug on bzr-git?
<RenatoSilva> lifeless: difftastic? ok thanks
<RenatoSilva> lifeless: btw do you know how is bzr-hg, iirc you were the maintainer? I need it but it doesn't work, tried last from trunk too
<lifeless> jelmer is looking after i tnow
<wolfrage> lifeless: seems to be more of minor error. I will try the series of commands agian.
<wolfrage> then i will just keep on, as it seems to not effect anything
<wolfrage> Is there an easy way to convert to an from GIT - BZR? and will it maintain compatability when it goes back to GIT?
<lifeless> wolfrage: bzr branch git://... destinationpath; read the bzr-git documentation
<lifeless> please file a bug - something went wrong, we should fix it
<wolfrage> lifeless: I am not sure if i could even reproduce it. This branch is volitile. It just got rebased twice and has been updated from almost 13 months of inactivity
<lifeless> knowing that there was a problem is often most of the battle in fixing it :)
<wolfrage> lifeless: I filled a bug on an issue earlier, and I will be hanging around here, so any errors I can reproduce I will be sure to file agianst.
<radix> what's that configuration parser library that bzr uses?
<lifeless> configobj ?
<radix> yeah, probably
<wolfrage> lifeless: OK I will file. I like Bazaar as a tool, lets me program and not get stuck on the command line trying to figure out Version Control Systems...
<lifeless> thanks!
<poolie> jam, spiv, jelmer, udd meeting is now
<RenatoSilva> how do I specify the submit branch so that bzr diff -rsubmit: will use the right branch?
<RenatoSilva> hmm a useless merge, nevermind
<jelmer-n900> renatosilva: you can edit .bzr/branch/branch.conf or perhaps use bzr config
<mwhudson> yeah, merge --remember will do that
<jelmer-n900> hey mwhudson
<mwhudson> jelmer-n900: hello
<spiv> poolie: I think https://code.launchpad.net/~mbp/bzr/687653-notbrancherror/+merge/43314 probably ought to be marked rejected (for 2.2 at least)
<poolie> i agree
#bzr 2010-12-16
<chx> just out of curiosity ,how can i use bzr blame to find the oldest surviving code in a tree?
<mkanat> Gee, that's a good question.
<mkanat> chx: I'm betting that's plugin territory.
<mwhudson> especially as i guess you'll want some heuristics
<mwhudson> (only considering non-blanks lines for example?)
<chx> hrm, right
<chx> and no } either
<mwhudson> well, in some lesser languages, yea :)
<spiv> Or in Python code with lots of multiline dict literals ;)
<poolie> spiv:
<poolie> <vila> oh, and I tried to warn spiv this morning but he was gone, his patch changing the branch creation signatures broke loom
<poolie> <vila> I didn't have time to look at that but I'm afraid that will mean some hard compatibility issue for such plugins: 2.3 XOR the rest
<spiv> No, I don't think it's a hard compatibility problem, I thought I'd already chatted with vila about this.
<spiv> Implementations of BranchFormat.initialize etc need to accept a new optional keyword arg.
<spiv> That won't impact their compatibility with old bzrlib versions at all.
<poolie> spiv, well, from what he said it was actually breaking looms
<poolie> i have not tested  myself
<spiv> I just made the small patch to bzr-loom it needs to be compatible.
<poolie> great
<spiv> Compatibility with older bzr is unaffected.
<spiv> https://code.launchpad.net/~spiv/bzr-loom/bzr-2.3-compat/+merge/43851
<poolie> :)
<mkanat> Why does bzr seem to print spaces out to the right side of the terminal for some things that it prints to the terminal?
<mkanat> I'd think that it was just my terminal, except that it's only the first and last line of the commit output.
<fullermd> Maybe where it had printed a progress bar, so had to put spaces to cover it up?
<mkanat> fullermd: Oh, that could be, yeah.
<poolie> probably that
<Chris79> Hi, anyone here using the bzr-eclipse plugin with eclipse helios on win 7? I have trouble committing / updateing a project pulled from a remote bzr repo. Thanks for you help!
<vila> hi all !
<vila> poolie: thanks for the pqm email !
<vila> poolie: I have *no* idea what is happening there though... never saw this kind of failure
<vila> it may be another isolation issue uncovered by my fix...
<mgz> morning vila.
<vila> mgz: hey !
<mgz> just looks like doctest isolation vila?
<vila> mgz: now you're really reading above my shoulder ! This is in a private mail from poolie, how on earth can you see that ? :D
<mgz> as in, you accidentally provided some.
<mgz> it's in the mp!
<vila> lol, pfew, I feel better :D
<vila> ok, so I accidentally provided what ?
<mgz> some isolation :)
<vila> ha ! yes, that's the idea
<poolie> on phone atm
<poolie> perhaps we should look at tarmac now
<vila> I'll have a look today
<vila> mgz: given the order of the tests, that sounds right, and id didn't fail here because I have (as almost everybody running the tests) a valid whoami
<vila> in my home directory
<vila> which is now reached because BZR_HOME has been cleared
<mgz> yup.
<mgz> annoyingly the proper fix here is moderately hard.
<vila> that's exactly the type of failure I was afraid of and why my fix may seem very shallow but the problem is deeper
<vila> just a sec
<poolie> don't know if it's actually going to fix this type of issue
<mgz> all the bzrlib.tests.TestCase.setUp code needs factoring out into a method that can be passed to the doctest constructor
<vila> poolie: no, in fact it will *uncover* other occurrences of this type of issue
<poolie> is that good?
<vila> yes
<vila> otherwise we don't test what we think we test
<mgz> but it was nice ignoring the fact doctests were borked vila :)
<vila> mgz: hehe, we could just delete them :D
<vila> kidding ! I don't want to start a religious discussion about doctests so early in my day :D
<mgz> I'll bump the doctest bug up my todo list, can you hack around this failure by adding some whoami setting line to the doctest that fails?
<mgz> ideally without further breaking the underlying environment...
<mgz> now I need to go get ready and things.
<vila> https://code.launchpad.net/~vila/bzr/690563-better-env-isolation/+merge/43871
<vila> mgz: as soon as I reproduce it (my pqmlike setup was broken, fixing it right now)
<vila> poolie: feedback on the above would be good (mgz too if you're still there), I don't want to land as is, but don't want to deploy to be said after the fact "Oh, why didn't you use *this* name instead ;)
<vila> just added a comment explaining one dormant bug we have today
<poolie> sure, i was going to do a couple more reviews
<poolie> vila are you going to clean up the existing methods and their users?
<poolie> or add an alternative?
<poolie> i'd like the first a bit more
<vila> My plan is to first remove all uses of _captureVar in the code base
<vila> then I can cleanup further but I suspect some plugins may be using _captureVar and there I don't know if I should deprecate or delete it
<vila> I think I'll probably go with several submissions to address and discuss each controversial point one by one
<vila> I smell bike-shedding coming up at least as hard as the import saga ;D
<poolie> on the environment stuff? i doubt it
<vila> poolie: smooth_upgrade still on your list ?
<poolie> vila, mgz: can i get you two to agree on https://code.launchpad.net/~gz/bzr/add_two_in_unicode_cwd_686611/+merge/43152
<vila> mgz, poolie : yeah, can you agree ?
<vila> :D
<poolie> it is still on my list
<vila> mgz: more seriously, what do you have in mind here ? I'm open to patches on any stable branches (it's simple enough), the main problem I mentioned was merging up to trunk but even if you plan a different fix for trunk, handling the merges yourself will be the simplest (unless we do it in sync via discussion here)
<poolie> what does "with a boolean False path" mean there?
<poolie> oh i see, meaning if we call it with ''
<poolie> vila, will merging that to 2.0 actually make things harder when we merge up? why?
<vila> poolie: only the NEWS related part is messy especially when we cross 2.2 -> 2.3
<poolie> ok
<poolie> but, generally speaking, we are still going to fix things in 2.2
<poolie> so we have to cross that
<vila> but even the 2.0 -> 2.1 doesn't merge that cleanly if news_merge is not configured
<poolie> it's not a reason not to merge any particular change?
<vila> not at all
<poolie> ok, so i approved that with tweaks
<vila> the one doing the merge should just be aware of the issue
 * mgz returns
<mgz> will comment on both those mps.
<vila> mgz: ok
<mgz> I'd be happy to do the merging up if it'll be particularly painful vila.
<vila> mgz: error prone more than painful, which is why I mentioned it
<vila> mgz: is there a bug filed for doctest isolation ?
<mgz> it's bug 321320
<ubot5> Launchpad bug 321320 in Bazaar "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/321320
<vila> mgz: if you dont' know... 8-) Rock & roll !
<vila> mgz: http://paste.ubuntu.com/544336/ is enough to fix the failure I'm encountering while trying to land bug #690563 fix
<ubot5> Launchpad bug 690563 in Bazaar "bzrlib.tests.test_import_tariff.TestImportTariffs.test_simple_local failure" [Medium,In progress] https://launchpad.net/bugs/690563
<mgz> that's the sort of thing I meant, yep
<vila> mgz: sounds ok to land with this workaround until we fix 321... ok
<poolie> vila, ok, upgrade thing is reviewed
<mgz> you'll then be leaking that envvar again, but... that's only what we were doing before anyway
<vila> poolie: ok, I'll tweak as much I feel reasonable and land it then
<vila> mgz: damn, you're right ! ... and wrong too, I should not let this leak happen, hmm
<mgz> import osutils instead and use set_or_unset twice?
<vila> how does one disable a doctest ?
<vila> mgz: would still be too brittle for my taste
<mgz> no easy way to disable them, apart from changing the syntax so the scraper doesn't spot them
<vila> oh easy, I would just comment out branchbuilder in the list of doc tests with a ref to 321320 to fix it
<mgz> ah, or that works.
<vila> I'll add a comment to that effect to the bug
<mgz> how am I spelling my name in news these days...
<poolie> vila that would be great, thanks
<vila> mgz: unicode bug cruncher would be appropriate ;D
<vila> mgz: a bit restrictive though...
<poolie> :)
<poolie> ok, i should go
<vila> poolie: enjoy your evening ! And thanks for the reviews !
<mgz> bye poolie!
<vila> mgz: so this will be http://paste.ubuntu.com/544345/, still ok ?
<vila> grr, fill-paragraph is too agressive, the bzrlib.branchbuilder should be on its own line
<mgz> Looks fine. Could explicitly state it involves no user being set in the environment.
<vila> indeed !
<vila> done
<mgz> I've pushed up NEWS for the bug 686611, could I ask you to look at it again and maybe land it for me vila?
<ubot5> Launchpad bug 686611 in Bazaar 2.2 "`bzr add file1 file2` in non-ascii folder fails, but `bzr add file1` works" [Low,Confirmed] https://launchpad.net/bugs/686611
<mgz> +fix
<vila> ubot5: why the hell are you choosing 2.2 when most of the discussion is whether we start fixing it in 2.0 ???
<ubot5> Error: I am only a bot, please don't think I'm intelligent :)
<vila> ubot5: I wasn't implying anything...
<ubot5> Error: I am only a bot, please don't think I'm intelligent :)
<mgz> it's possibly the last milestone I added to the bug?
<mgz> it's a little odd it picks that one though.
<vila> no big deal :) I was just surprised and wondered if *you* had changed your mind (sent to pqm)
<vila> a fix for 'lost connection during test' will make me so happy... ;D
<mgz> urk, running out of time, will have to file paths bug later.
<vila> spiv: oh ! Thanks for the loom fix ! Sorry to mention it so late, I was thrilled when I read the irc log !
<vila> mgz: let me know about where you end up merging this fix up
<vila> mgz: I expect it to be a bit stretched along the day if you wait for pqm
<mgz> vila: yup, and I'll put them in the review queue anyway as I can only submit to bzr.dev
<mgz> will start some time early afternoon when I get back.
<vila> mgz: really ? We should fix that
<vila> mgz: ok
<vila> grr, one more pqm failure without mail :(
<vila> mgz: if you're still around may be you can submit for me ;)
<tacone> hello, i need a quick way to check if bzr is locked. anyone ?
<Peng> tacone: bzr info, if you're really asking about the lock status of a bzrdir.
<tacone> yes, that. thanks !
<mgz> ack, vila, sorry, I didn't notice, you commented the wrong line to skip that doctest
<mgz> you want _test_suite_modules_to_doctest 'bzrlib.branchbuilder'
<vila> no ???
<mgz> but did _test_suite_testmod_names 'bzrlib.tests.test_branchbuilder'
<mgz> that'll fix that and I'll send to pqm so we get the output in case it complains again
<vila> and I'm banging my head on an apport failure for nothing ?
<mgz> (personally, I'd do that as a seperate branch, first, then send lp:~vila/bzr/690563-test-isolation without that change on it at all.
<vila> why ?
<mgz> it's not really related, and wants to be backed out in the future. also, if that change is wrong, 's more obvious pqm'ed seperately
<mgz> I don't think it matters much in this case.
<vila> it *is* related, the change *uncover* the problem
<mgz> right, but say, for example, the wrong line was commented out.
<mgz> having a pqm run first just for that workaround makes it more obvious we've just lost a bunch of tests.
<mgz> (just... babune would be clearer, but doesn't run each change)
<vila> yeah :-/ I don't know what happened, I clearly remember seeing your comment on _modules_to_doctest...
<mgz> brains are funny things.
<mgz> sometimes they work, sometimes...
<vila> right, that's a bit excessive I think, it will also clutter the bzr.dev history plus I'm almost ready to submit a more robust alternative (while also realizing there is an even more robust one possible ;-/)
<vila> what was the problem with apport tests last time ?
<vila> or was it maxb ?
<maxb> ?
<mgz> hefixedit.
<mgz> see bug 686439
<ubot5> Launchpad bug 686439 in Bazaar "easy_install breaks due to SandboxViolation on SLES" [Medium,Fix released] https://launchpad.net/bugs/686439
<vila> python -Werror -O ./bzr selftest -s bt.test_crash fails reliably on my pqmlike host
<vila> I thought that was why my submission was failing and start bisecting like crazy until I realize it was related to '-Werror -O'
<mgz> ah, different thing.
 * vila bangs ahead a bit nore
<vila> python2.5 only so unrelated to pqm
<vila> mgz: I've filed an RT about pqm access, I'll keep you informed (but the admins are quite busy these days ;-/)
<vila> mgz: your fix has landed for 2.0, tell me when you're ready for 2.1
<mgz> just doing it now.
<mgz> vila: https://code.launchpad.net/~gz/bzr/merge_2.0_to_2.1/+merge/43913
<Peng> The admins are too busy? Sounds like somebody needs to have their sleeping privileges taken away.
<vila> Peng: that the problem with admins: they are the ones handling the privileges
<fullermd> How does one go about aquiring these "sleeping privileges" of which you speak?
<vila> mgz: sent to pqm
<mgz> thanks!
<vila> . o O (Damn, no he will be suspicious about his lack of sleep)
<vila> s/no/now/ shudder tyop ekoj
<lvh> Hi!
<lvh> I'm ordinarily an Emacs user, but if I want to try bzr with Eclipse/Pydev, should I use the Eclipse-Bzr plugin or the QBzr plugin?
<jam> lvh: AIUI eclipse-bzr has closer integration, but qbzr has more total polish
<lvh> jam: Hm, okay.
<lvh> jam: I'll try both and see what happens.
<lvh> jam: It's not the case that one is particularly deprecated/bad, right?
<vila> jam: good morning !
<vila> mgz: yeeeeehaaaa, one more blue target on babune ;)
<vila> mgz: 2.1 landed
<mgz> cool! will do the next merge step.
<jam> morning vila
<jam> I'm very happy that we're really close to getting lp-forking-service rolled out on qastaging.
<mgz> blue macs mean I could feasably tackle the filesystem normalisation issue.
<jam> the service is installed and running, and the mp is submitted to activate it
<vila> jam: yeeehaaa ! :D
<vila> mgz: or submit your fixes to turn the windows one blue ;)
<jam> fullermd: sorry, no sleeping priviledges are available at this time. Please submit form INTS5525. Expect processing to take 1-5 weeks.
<mgz> yeah, to many things not enough time.
<vila> I know :)
<mgz> +o
<vila> +o..... female symbol turned clock-wise ? some unknown smiley ? /me facepalms tyop ! to+o :D
<mgz> right :)
<mgz> you can sort of parse what I said with the wrong too? but the meaning is different
<mgz> vila: https://code.launchpad.net/~gz/bzr/merge_2.1_to_2.2/+merge/43925
<vila> well, my parser is tolerant to some form of typos :)
<vila> mgz: sent
<mgz> thanks! I can do the last one myself, but will probably bug you anyway to check I've understood spiv's split correctly.
<vila> mgz: and now the tricky one :) You'll have to update the doc/en/release-notes manually during the merge
<vila> because NEWS -> doc/en/release-notes/bzr-2.3.txt which produces horribly wrong merge results
<vila> garyVDM ! gary ! gary ! Come back !
<hallyn_> Hi,  when i try to do a 'bzr merge-upstream' from a packaging tree, i get:
<hallyn_> bzr: ERROR: Merge upstream in merge mode is not yet supported.
<hallyn_> will it do any harm if i temporarily remove 'merge = True' from .bzr-buildddeb/default.conf ?
<jelmer> hallyn_, hi
<jelmer> hallyn_: if you're trying to run "bzr merge-upstream" I wonder if you should need "merge = True" at all
<jelmer> hallyn_, Does your packaging branch contain the upstream source code ?
<hallyn_> no
<jelmer> hallyn_: "bzr merge-upstream" will add the upstream source, is that what you're trying to do?
<hallyn_> upstream source code is in lp:vmbuilder, the packaging branch is at bzr+ssh://bazaar.launchpad.net/~vmbuilder-dev/vmbuilder/packaging/
<hallyn_> heh, i don't know.  i didn't create the trees, i inherited them
<hallyn_> i'm just trying to build a package to propose for archive, based on the new pacakaging and source trees
<jelmer> hallyn_: So you mainly want to add a new changelog entry for the appropriate revision in lp:vmbuilder /
<jelmer> ?
<hallyn_> i did that
<hallyn_> now i want a bzr command in place of building a source package and asking someone to dput that.  i.e. somethint to create a tree that someone can review and sponsor
<hallyn_> AIUI that was bzr merge-upstream...
<jelmer> hallyn_: Ah, ok. You're probably after "bzr builddeb -S"
<jelmer> hallyn_: "bzr merge-upstream" merges in an upstream revision and updated debian/changelog appropriately
<hallyn_> no, that creates the package which i then have to scp somewhere for someont to look at out of band
<jelmer> hallyn_: So you'd like to propose a merge that somebody can review?
<hallyn_> right, what i want is a bzr tree which someone can review and sponsor as though it had been a package
<hallyn_> if that makes any sense at all
<hallyn_> (sorry, terrible network lag due to sync)
<hallyn_> yes
<jelmer> hallyn_: yep - I think "bzr lp-propose" should do that, or you can click "Propose for merging" on the branch web page
<hallyn_> awesome, let me try that, thanks
<hallyn_> well no, wait
 * hallyn_ wonders why hundreds of megs are being xferred to sync one changed U1 file)
<hallyn_> jelmer: i guess where i am confused is that this is not the actual source tree.  I'ts *just8 the packaging tree with only the contents of debian/
<jelmer> hallyn_: You would propose your branch for merging into the packaging branch
<jelmer> hallyn_: The upstream branch is only used by "bzr builddeb" and should not be relevant here
<hallyn_> the packaging branch being which?
<jelmer> lp:~vmbuilder-dev/vmbuilder/packaging/
<hallyn_> IIUC i've already pushed the change into the packaging branch
<hallyn_> ok, yes
<hallyn_> i own that.  So now the next step is actuallyuploading the resulting package to the archive
<jelmer> hallyn_: The only way to do that is to create a source tarball and upload it
<hallyn_> jelmer: ok, thanks.  i think the hope was for there to be a single bzr tree containing source+packaging which could be diffed for whoever sponsors the package upload.  But I guess that doesn't quite fit into this setup
<vila> mgz: 2.2 landed
<mgz> pull me push you.
<vila> too bad, I missed the joke ;-/
<vila> mgz: by the way, you've got a mac ?
 * vila revises his beliefs...
<mgz> vila: no. I have babune!
<vila> LOL
<vila> I should definitely make it easier to use selftest-subset then :)
<mgz> what's bug 687653 about ubot5?
<ubot5> Bug 687653 on http://launchpad.net/bugs/687653 is private
<mgz> vila: does this look about right? http://paste.ubuntu.com/544559/
<vila> mgz: pretty much, but I think we don't copy the new entry across the 2.2/2.3 barrier (cooking time here, but check what I did with ... can't remember, last merge from 2.2)
<mgz> ah, I see what you mean.
<mgz> so I can just revert doc/en/release-notes/bzr-2.3.txt
<lifeless> mgz: hola
<mgz> shazam.
<lifeless> mgz: I think jam is preoccupied atm
<lifeless> mgz: so we should decide if its environmental or not, and move forward accordingly
<jam> lifeless: sorry, I'm missing the context
<jam> testtools stuff?
<lifeless> jam: yes
<lifeless> jam: we can't reproduce the problem
<mgz> jam, can you just run that test and still repo the random failure?
<jam> lifeless: k. Fully reproducible here, what would you like from me
<jam> mgz: what test?
<jam> (i'm missing something from the traceback, I guess)
<mgz> the one that fails.
<jam> just the failing one?
<lifeless> jam: probably drop into pdb and see whats going on
<lifeless> mgz has a crazy theory about twisted but I think thats ... crazy :)
<jam> lifeless: is there a new testtools I should be using?
<mgz> otherwise yeah, stick a breakpoint in the __str__ method and step out from there to see what happens
<lifeless> jam: just tip
<lifeless> to run a single test, python -m testtools <testid>
<lifeless> grah
<lifeless> testtools.run <testid>
<lifeless> [doesn't work for scenarios yet, but the failing test wasn't a scenario test anyhow IIRC]
<lifeless> what seems to be different to me is that we get just the class name, not the <..> sutff
<mgz> yup. which implies either the exception doesn't propogate, or that __str__ method is never called and something else stringifies it.
<jam> lifeless: so I'm sitting here, and I can paste the output
<jam> what are you looking for?
<jam> lifeless: also note, you are doing "raise UnprintableError"
<jam> not "raise UnprintableError()"
<jam> I don't know if that matters
<jam> lifeless: http://paste.ubuntu.com/544575/
<jam> If I just run the test and capture the 'stream.getvalue()' that is the traceback the test runner sees
<jam> If I create the class in a python interactive shell
<jam> and raise it
<jam> that is what I see
<jam> I'm assuming something in testtools is supposed to be catching the error for formatting and isn't?
<jam> Aren't you just using traceback.format_exc() ?
<mgz> nope, this is the whole point of these tests.
<mgz> they need to be going through TestResult._exc_info_to_unicode
<lifeless> format_exc generates non-local-encoding bytestrings
<mgz> so, if you do that same microtest, but try/except round the raise and pass to testtools.TestResult()._exc_info_to_unicode do you get the same final line?
<mgz> because that's what your test failure imples.
<mgz> +i
<mgz> either that, or it's somehow escaping that method.
<jam> mgz: I'm trying to get there, but you also need a test case
<jam> mgz: are you saying inside the created file?
<mgz> or just on the terminal
<mgz> putting a break point anywhere before or during the actual test run would also work, but there are a lot of testtools levels to step through, and the fact these tests use generated files probably isn't helping any
<jam> mgz: using this hack: http://paste.ubuntu.com/544580/
<jam> I get this: http://paste.ubuntu.com/544581/
<jam> printed to stdout
<jam> mgz: so yes, testtools.TestResult._exc_info_to_unicode(exc_info, ...) is generating output that only has the class name
<mgz> okay, that's borked. step into the execution of that call?
<mgz> you should end up in testtools.compat
<mgz> if you didn't, all the other tests would fail...
<jam> mgz: at what point?
<lifeless> mgz: jam's query is interesting
<lifeless>             testline="raise UnprintableError")
<jam> the immediate jump is to unittest._exc_info_to_string
<lifeless> aren't you meant to construct things always, these days ?
<mgz> doesn't make any difference.
<jam> lifeless: I think you are, but it doesn't seem to change the tracebacks
<lifeless> kk
<jam> At least manually doing "raise Foo" and "raise Foo()" gave the same results
<mgz> so jam, what should happen is from testtools.compat._format_exc_info the exception instance is passed to testtools.compat._exception_to_text to do the stringifying
<jam> mgz: (Pdb) tr._exc_info_to_unicode.im_func.func_globals['traceback']
<jam> <module '__fake_traceback' (built-in)>
<mgz> oooo... I wonder if there's a __unicode__ method screwing me up here?
<jam> which looks like it is properly overriding the thing you want to
<jam> mgz: when I step through it, I've gotten into the testtools.compat._format_exc_info
<mgz> jump forward to near the end and the _exception_to_text call
<mgz> hm, no __unicode__ issue on 2.6.6 at least: http://paste.ubuntu.com/544585/
<jam> mgz: if I'm doing it right, for some reason at the point of "svalue = _exception_to_text(evalue)" the evalue is None
<jam> even though there is an earlier "if evalue is None: return"
<jam> ah wait, probably just a bug in "pp evalue" in the debugger
<jam> since this class isn't printable
<jam> mgz: unicode(evalue) returns
<jam> unicode(evalue) == u''
<mgz> Exception.__repr__(evalue) would give you feedback if pdb has issues
<mgz> okay, that's bad and wrong, and the bug.
<mgz> I'll defend the test from it.
<jam> mgz: so is this just a bug in python 2.6.4 then?
<jam> (Pdb) evalue.__unicode__
<jam> <built-in method __unicode__ of UnprintableError object at 0x025732B0>
<mgz> I presume they added a seperate __unicode__ method to the base Exception class... then removed it again.
<lifeless> yes
<lifeless> I thought I mentioned that the first day ;)
<mgz> ...you did? where did you ;_;
<lifeless> here
<mgz> thanks jam! you have been very patient with me.
<lifeless>  /lastlog futzed|changed might find my comment
<lifeless> I'm not 100% sure I did - but there is a python bug on __unicode__ in Exception in 2.6.x
<vila> lifeless: by the way, when do you plan to push a debian release of python-testtools ? Our MRE/SRU is blocked on that so far (in short)
<lifeless> vila: when we can release
<jam> mgz: http://mail.python.org/pipermail/python-bugs-list/2006-September/035171.html
<lifeless> vila: which is why I'm talking to mgz and jam now
<vila> lifeless: great, so this will be 0.9.8 ?
<mgz> I'll put a branch up now avoiding that.
<lifeless> vila: something like that
<jam> mgz: I assume you can just add "def __unicode__(self): raise RuntimeError"
<mgz> yup, that's what I'll do.
<val_> ping vila
<mgz> lifeless: https://code.launchpad.net/~gz/testtools/avoid_exception_unicode_method_bug_689858/+merge/43967
<lifeless> jam: can you confirm that that passes?
<jam> runs clean
<jam> lifeless, mgz: ^^
<lifeless> thanks
<lifeless> I'll pull it in and do a release later today
<mgz> ha, lifeless, I see you even commented in the bug for the __unicode__ method backout
<lifeless> mgz: yes, this is why I was able to mention it easily :)
<lifeless> what was the issue number again ?
<mgz> http://bugs.python.org/issue6108
<mgz> just adding note to the bug so I have a record.
<lifeless> care to put that as a note in the branch too ?
<lifeless> spiv: ^ btw, thats why we override __unicode__
<lifeless> spiv: or something
<mgz> done.
<mgz> quite glad I ran into this now, I'm fiddling with unicode and exceptions in bzr currently.
<renatosilva> how to resolve conflicts in bynary files?
<renatosilva> bzr status is showing as removed and unknown even if I bzr resolve binfile (where binfile is the right one, resolved)
#bzr 2010-12-17
<maxb> james_w: Hi. If you're around, I'm staring at the complex comparison logic that the UDD importer uses to decide which order to do imports in, and am wondering why it is the way it is
<maxb> I think I can blame the insane branching structure that results when unblocking a long-broken UDD import on this ordering
<RenatoSilva> how to diff two branches? I remember using a command for checking if local copy was up-to-date with LP
<RenatoSilva> is bzr pull enough?
<spiv> RenatoSilva: perhaps you are looking for "bzr missing"?
<RenatoSilva> spiv: that's it, thanks!
<AfC> spiv saves the day
<wallyworld> spiv: can you answer a question about branch revisions?
<wallyworld> can you tell me, given a BranchRevision, the correct way to figure out if the revision was from merging in another branch and what that other branch is? Do you look for some attribute of any revision parents? i'm currently looking at the first parent and use getBranch() on that. is that the right thing to do?
<spiv> wallyworld: Hmm
<spiv> wallyworld: I'm not especially familiar with Launchpad's BranchRevision...
<spiv> wallyworld: all bzr records is the DAG of revisions
<wallyworld> the BranchRevision joins the branch to its Revisions
<wallyworld> in bzr terms, what would you do?
<spiv> There's no way in general to go from a revision to a branch that created it.  For example imagine there are two identical copies of a branch pushed to different locations on Launchpad.
<spiv> If the tip revision is merged into another branch, which copy would you want to attribute as the merge-from branch?
<wallyworld> hmmm. i see what you mean
<wallyworld> i'm working on this bug 334336
<ubot5> Launchpad bug 334336 in Launchpad itself "Show which branch and bug are related to a revision" [High,In progress] https://launchpad.net/bugs/334336
<spiv> In many cases in Launchpad I could imagine that there *might* be one most likely branch.
<wallyworld> to answer your question, perhaps the original branch of the tip, not the one merged into
<spiv> Which branch is the "original", though?
<wallyworld> on seconds thoughts, maybe not :-/
<wallyworld> is the bug reasonable then? or should we mark it as invalid?
<spiv> I think it is reasonable in intent, but a bit vague.
<wallyworld> yeah. i've got something working based on what i explained above. i'll run it by thumper next week and see what he says
<spiv> Launchpad does know more facts than just the DAG, like perhaps that merge proposal existed for a branch with that revid
<wallyworld> thanks for the input
<spiv> I would say that *if* there is one branch on Launchpad whose tip is the revision you are interested in, then you have a pretty good answer.
<spiv> And that will probably cover quite a few cases.
<spiv> Otherwise maybe something like "the first time Launchpad encounters a revision as a mainline revision, Launchpad should take note of that branch and treat it as the 'original' branch for these purposes"
<spiv> There are going to be lots of edge cases no matter what you do, I think.
<spiv> (e.g. what if someone does "bzr push --overwrite" or "bzr uncommit" to partially rewind a branch?)
<spiv> wallyworld: if you'd like a concrete use-case to guide your work
<spiv> wallyworld: what I'd love to have is say I'm looking at the webpage for lp:bzr
<spiv> wallyworld: I'd like the list of recent revisions there to link to the branches and even merge proposals corresponding to those revisions
<spiv> wallyworld: (in bzr's case, almost all our mainline revisions on lp:bzr and our release branches do have corresponding merge proposals)
<wallyworld> spiv: here's my prototype so far : http://people.canonical.com/~ianb/br.png
<spiv> wallyworld: that would be nice because it gives me a single page that not only shows the recent changes to the branch, but also provides links to the discussions (in merge proposals, and bugs linked to branches) about those changes
<spiv> wallyworld: yes, that sort of thing :)
<wallyworld> does that look suitable? i could add in the mp too
<wallyworld> so it's just figuring out how to get that "Merged From" branch
<spiv> The MP might be good.
<spiv> Although it's not too hard to navigate from a branch to a merge proposal, IIRC.
<wallyworld> the mp is easy :-)
<james_w> maxb, you mean comparing distros, releases, versions etc?
<vila> hi all !
<mthaddon> vila: do you know who filed RT#42981 (Some committers lack access to some bzr pqm branches)?
<vila> mthaddon: yes, me
<vila> anything wrong with it ?
<mthaddon> vila: np - just couldn't work out who it was from - have replied
<vila> mthaddon: oh yeah, indeed sounds sensible...thanks for posting the definitions, we could discuss it further but we will probably keep it this way
<mthaddon> ok
<dnivra> hello. i am trying to make bzr display a message but I can't display an email address-i get the following error http://paste.ubuntu.com/544937/. how can i fix it?
<ovnicraft> hi guys i want to create a branch at revno explicit can pass some like bzr branch lp:proyect -r myrevno ?
<vila> yes
<vila> see 'bzr help branch' and bzr help revisionspec'
<vila> see 'bzr help branch' and 'bzr help revisionspec'
<ovnicraft> vila, yes but can help with an example
<ovnicraft> ?
<ovnicraft> i am trying bzr branch lp:proyect revno:num but create a folder with revno:num
<vila> bzr branch -r 42 lp:bzr my-local-branch-at-revno-42
<mkanat> So, I just filed bug 691756. Any ideas for a fix or workaround?
<ubot5> Launchpad bug 691756 in Bazaar "unversioned files underneath a directory that is now a symlink cause bzrlib.errors.PathNotChild " [Undecided,New] https://launchpad.net/bugs/691756
#bzr 2010-12-18
<jderose> quick question: what's a good tool for visualizing a complicated history of branches and merges with a lot of criss-cross?
<jelmer> jderose: qlog probably
<jderose> jelmer: cool, thanks :)
<lifeless> vila: testtools is in unstable now
<lifeless> 0.9.8
<lifeless> vila: I don't know how that hepls the SRU
<vila> lifeless: great !
<vila> lifeless: it's rather involved: we need the related bug to be fixed in natty, which needs testttools and from there, cascading effects unblocks the SRU
<lifeless> so
<vila> so we needed testtools in unstable so it can get into natty
<lifeless> you'll need to get python-fixtures
<lifeless> python-testtools
<lifeless> synced to natty - if they haven't synced themselves
<lifeless> python-fixtures is there already
<lifeless> so just python-testtools is all thats needed
<vila> hmm, never heard about python-fixtures before
<lifeless> build-dep on python-testtools, like python-twisted
<vila> don't tell me it's a new dependency not present in main or the whole circus will start again
<lifeless> its a build dep
<lifeless> so is python-twisted
<vila> yes, that's exactly what python-testtools is for bzr and why we needed an up-to-date version
<vila> and why I asked for python-testtools to be included in main, so back to square one :-(
<lifeless> I don't know the details
<lifeless> but it seems like you're making the change bigger than necessary, no ?
<vila> I'm trying to comply with the defined rules...
<lifeless> I'd challenge the 'must be fixed in natty' component
<vila> bug #684099 should gives you the entry point
<ubot5> Launchpad bug 684099 in python-testtools (Ubuntu) "[MIR] python-testtools" [Undecided,Fix released] https://launchpad.net/bugs/684099
<vila> bug #659950
<ubot5> Launchpad bug 659950 in Bilboplanet "Statistique Nombres de post manquant" [Medium,Fix committed] https://launchpad.net/bugs/659950
<vila> shudder
<vila> bug #659590
<ubot5> Launchpad bug 659590 in Bazaar 2.3 "dput sftp upload hangs after all files successfully uploaded" [Critical,Confirmed] https://launchpad.net/bugs/659590
<lifeless> well
<lifeless> keep me in the loop
<lifeless> but I expect us to add more build-deps as we add support for scenarios, other frameworks and so on to testtools
<lifeless> I'm sure we can figure something out, but there is a balancing act between running the testtools tests and dragging lots of stuff into main transitively.
<vila> well, I'm pretty sure this means we should just give up then, the SRU is blocked since ~2010-10-13 and obviously we can't keep up
<lifeless> I do wonder if the transitive requirement is entirely necessary for things like built deps
<vila> the middle path would be to have >= 0.9.5 available without added deps
<lifeless> python-twisted is in main
<vila> maxb: what do you think ? ^
<lifeless> python-fixtures has no unusual build-deps of its own
<lifeless> you probably just need an MIR for python-fixtures, which the distro team may do for you when python-testtools attempts to sync and FTBFS on natty
<vila> hopefully your're right
 * vila off
<vila> jelmer: thanks for the upgrade bugs triaging ! Good reminder as I'm tweaking fullermd's proposal.
<jelmer_> vila: np, I suspected there were some dupes
<jelmer_> there weren't, but it does seem like a week of upgrade hacking might be a useful thing to do at some point
<vila> jelmer_: Yeah... some of them may be addressed by the proposal but this was an unfinished job (there are empty tests there) so it's a bit hard to see where the tweaks should end and where a new submission starts
<vila> but definitely it would be good to clear some backlog there
 * jelmer_ waits for testtools to enter sid so he can upload bzr 2.3b4
<maxb> vila: It looks like we have no choice but to MIR python-fixtures
<vila> maxb: thanks for the feedback
<vila> maxb: yet, we should not need python-fixtures on maverick for the SRU right ?
<vila> s/yet/still/ ?
<maxb> We're fine there because 2.2 doesn't need the newer python-testtools
<vila> maxb: ok, so this doesn't propagate, good
<vila> maxb: so, if 0.9.8 enters natty (main) will it brings p-x with it ? (aka is the MIR implicit or not)
<vila> not p-x p-f == python-fixtures
<maxb> Well, it'll sync, then FTBFS, and someone will check it and see the reason is a component-mismatch, and then consider MIR-ing at that point
<maxb> On a different note, I need somewhere to put a shell-script that I use for some of the bzr ppa maintenance. I don't want to put it in lp:bzr, because I don't want to have to do the MP-and-PQM dance for every change
<maxb> The script in question pleases me greatly, because I just did:
<maxb> bzrppa-backport -s -u ppa:bzr/proposed -U medium -D "maverick lucid karmic jaunty hardy" python-fixtures_0.3.5-1.dsc
<maxb> for a one-liner upload of python-fixtures to all relevant series, stating just with the unmodified debian source :-)
<maxb> oh yay, python-fixtures tests are broken in python 2.5
 * maxb wonders what to do about updating python-testtools for hardy in the ppa
<vila> maxb: sry was away, let me re-sync
<vila> maxb: you use the script locally only right ?
<maxb> yeah
<vila> maxb: then lp:bzr is still the best place for many reasons
<maxb> and as it turns out, fixtures is FTBFS on hardy anyway, so I still needed to go back and do proper branches anyway
<vila> maxb: and as far as mp-pqm dance, since that's not blocking I don't quite get your reticences
<vila> maxb: additionally the constraints for such a script are vastly different than for the code so there shouldn't be issues
<vila> maxb: if I had some, it would be about clarifying the constraints about the branches handled locally, but it would be absurd to complain about that
<vila> maxb: I meant *blocking* a mp would be absurd
<vila> so, my point is: submit whatever works for you as soon as you can :D
<vila> maxb: I would even say: ask help from the pp if you feel some parts are missing, be it tests, docs, whatever
<maxb> i guess so
<vila> maxb: and if the pp is too slow for your taste, nag the RM ;)
<txdv> what is the default command to start bzr-gtk?
<jelmer_> maxb: as you might've seen I've uploaded loggerhead
<lifeless> txdv: bzr-gtk has a bunch of cli accessible commands, and optional nautilus integration
<lifeless> txdv: you may be thinking of 'olive', a gtk ui along the same lines as bzr-explorer - its separate to bzr-gtk
<lifeless> AIUI
<lifeless> maxb: is that bug 691916 ?
<ubot5> Launchpad bug 691916 in Python Fixtures "tests are broken on python 2.4" [Undecided,New] https://launchpad.net/bugs/691916
<lifeless> maxb: or something idfference again?
<lifeless> *different*
<txdv> lifeless: but i cant find it anywhere in the ubuntu reps
<exarkun> bzr svn-import exploded with an out of memory error, when I run it again, this happens, http://pastebin.com/AcEjtq0H
<Peng> exarkun: After making triple-sure there really isn't another bzr process running, bzr break-lock /media/sda1/divmod.org/bzr/Divmod/branches/flattener-error-formatting-2808
<exarkun> Thanks
<lifeless> txdv: sorry, what are you looking for ?
<txdv> olive
<lifeless> jelmer_: where does olive live these days?
<exarkun> Hm
<exarkun> I did the break-lock, but svn-import failed the same way
<lifeless> exarkun: does that file exist?
<lifeless> if its a file rather than a dir, remove it (no idea how that would happen)
<exarkun> it's a directory, with a directory `held` in it
<exarkun> with a file `info` in that
<exarkun> Oh.  But I guess the break-lock didn't do anything.
<exarkun> Coz it's still all there afterwards.
<Peng> How does break-lock not break the lock? o_O Permissions issue?
<Peng> Then I expect it would die horribly, though...
<exarkun> does this help, http://pastebin.com/WR10kDR5
<Peng> That makes my brain hurt.
<lifeless> uhm
<lifeless> I think it failed very early on in making the branch
<exarkun> There's very little in here, yes
<lifeless> yeah
<lifeless> delete that 'branch' entirely
<exarkun> http://pastebin.com/k217x2fv
<exarkun> Hrm.  Out of memory again.
<jelmer_> lifeless, txdv: Olive lives at https://launchpad.net/olive these days
<jelmer_> exarkun: hi
<exarkun> jelmer_: Hello
<txdv> hm
<txdv> thanks
<jelmer_> exarkun: I just got back - you're having locking issues running svn-import?
<Peng> jelmer_: exarkun is having svn-import-OOMs-and-leaves-behind-locks issues.
<exarkun> jelmer_: First I had memory issues so the import got interrupted.  That seems to have led to a locking issue.
<jelmer_> exarkun: I guess I can see how that could cause locking issues
<jelmer_> exarkun: how big is the repository?
<exarkun> 374MB
<jelmer_> hmm, that doesn't seem too bad
<jelmer_> what bzr/subvertpy/bzr-svn versions are you running?
<exarkun> bzr 2.2.2, bzr-svn  1.0.4, subvertpy 0.6.9-1
<exarkun> no sorry, subvertpy 0.7.5
<exarkun> 0.7.5-1~bazaar1~karmic1
<exarkun> latest run is now stuck, using 3GB of RAM and 100% CPU.  Not sure if the previous attempts entered this state before they died, I wasn't paying that close attention.
<jelmer_> exarkun: is one of the files particularly large?
<exarkun> cd
<jelmer_> cd?
<exarkun> sorry, wrong window
<exarkun> there are a few files a little over 100kB
<exarkun> nothing bigger than that
<exarkun> maybe there's a lot of branches?
<exarkun> it's converted 244 branches at this point
<RenatoSilva> if your branch is outdated with trunk but you're about to merge, what do you prefer, merge from trunk then into trunk, or merge into trunk directly?
<jelmer_> RenatoSilva: there isn't a particular reason for merging trunk into your feature branch first
<RenatoSilva> jelmer_: not sure but maybe leave the conflict stuff in the merge from trunk not the merge in trunk from that branch?
<RenatoSilva> jelmer_: so that when you qlog trunk and click the merge, you see a clear diff without hidden for-conflict-solving lines
<RenatoSilva> I mean, when you don't know which lines were result of merge conflict
<RenatoSilva> that way you'd be sure no conflict happened because you fixed it when merging from trunk
<RenatoSilva> and hence the diff of the merge from branch into trunk would be clear, without lines targeted at fixing conflicts
<RenatoSilva> Do I make any sense?
<lifeless> RenatoSilva: that only works on projects with a small number of branch merges a day, or both trunk and the branches maintained by the same person
<lifeless> RenatoSilva: otherwise, by the time someone has merged trunk and fixed conflicts
<lifeless> trunk will have new commits
<RenatoSilva> I see, but in that case, isn't it interesting?
<lifeless> to some people, perhaps.
<lifeless> I think having trunk always build-and-test-cleanly is much more interesting than how things get into trunk.
<RenatoSilva> merging from trunk immediately before merging into it is a way to ensure that
<lifeless> lets say you have 50 developers
<lifeless> and your test suite takes 40 minutes
<lifeless> if each developer does one patch a day, you have 2000 minutes of tests to run per day (which fits, 3600 minutes in a day)
<RenatoSilva> withing these 40 minutes there would probably be a new commit in trunk
<lifeless> right
<RenatoSilva> *within
<lifeless> if you have a serialised queue of things to land on trunk
<lifeless> and test the test suite one at a time, you can avoid trunk regressions
<lifeless> if you merge trunk to a branch, test *that*, then commit to trunk without testing - interactions between branches can easily - and often do for the Launchpad project which does it this way - break trunk.
<exarkun> jelmer_: is there something I can do to reduce the memory requirements for the conversion?  or do I just have to switch to a 64bit machine?
<jelmer_> exarkun: Our memory requirements are pretty heavy, but what you're describing sounds more like a memory leak of some sort
<jelmer_> exarkun: I guess a 64 bit machine might work around it, but I'm still curious what would be going wrong.
<RenatoSilva> lifeless: that's what I mean, you need to be as much updated with trunk as possible
<RenatoSilva> lifeless: so that you can run the tests on your branch before merging into trunk, so that there are less diff as possible when that happens and hence trunk is less likely to break
<lifeless> RenatoSilva: but thats different
<lifeless> RenatoSilva: you are saying 'do this thing*in a branch*'
<lifeless> RenatoSilva: I'm saying '*do this thing as part of the merge to trunk*'
<RenatoSilva> lifeless: run the tests locally? ok
<lifeless> well
<lifeless> not necessarily locally
<lifeless> but as part of the do-a-merge-to-trunk-process
<lifeless> however you're doing that
<RenatoSilva> ok
#bzr 2010-12-19
<CyberDomovoy> i have a trouble using bzr to branch on a nfs mount, ("bzr branch ...", $(pwd) is a nfs mounted directory), i get an error saying "Could not acquire lock ... No locks available", googling it told me it is a trouble with nfs locking. But, i have lockd running on both client and server, i tried doing a "mount -o remount,nolock" for my nfs mount, but it tells me "an incorrect mount option was specified" (???). Any idea?
<AfC> Can you generate a bundle of an entire branch? I tried -r 0.. . but that didn't work
<mathrick> jelmer_ / jelmer__: hi
<mathrick> mathrick@hatsumi:/tmp$ bzr get https://github.com/dto/iosketch.git
<mathrick> bzr: ERROR: Invalid http response for https://github.com/dto/iosketch.git/info/refs: Unable to handle http code 0
<mathrick> any idea what's wrong?
<mathrick> git seems pretty happy cloning that repo
<jelmer__> mathrick: hi
<mgz> I get a 200 from that url with curl, but if I add an Accept-Encoding header I don't get a valid response back
<jelmer__> mathrick: when cloning from github, use git://
<jelmer__> mathrick: they don't support "dumb" access over http at the moment
<mathrick> jelmer__: oh
<mathrick> are there different modes of access over HTTP for git?
<jelmer__> mathrick: yeah, two
<mathrick> odd
<mathrick> jelmer__: but speaking of github, I have another odd failure
<mathrick> ah, not actually github
<mathrick> just git
<mathrick> 3623kB     4kB/s - finding revisions to fetch 132 <-- huh, that's a lot of data sent for 132 revs
<mathrick> jelmer__: okay, got it
<mathrick> mathrick@hatsumi:/tmp$ bzr get http://common-lisp.net/project/parenscript/git/parenscript
<mathrick> bzr: ERROR: [Errno 2] No such file or directory: 'pack-027b9225cdb4a06f422e6321d92328dfb7103b92.pack'
<mathrick> that's after the above revision-finding
<jelmer__> mathrick: git access over "dumb" http is really inefficient
<mathrick> again git seems perfectly happy
<mathrick> jelmer__: I see. Well, that's what I got for the URL, so guess can't blame anyone but the author here
<mathrick> but I'm more concerned with the fact this thing fails ultimately
 * jelmer__ is trying locally
<mathrick> jelmer: does it fail for you too?
<jelmer> mathrick: it's working so far..  fetching revisions 506/609
<mathrick> huh
<mathrick> it errors out right as it tries to fetch revisions for me
<mathrick> that, or during revision-finding, hard to say
<mathrick> jelmer: it might be some outdatedness in my setup, lemme check
<mathrick> bzr-git 0.5.0
<mathrick> seems to be in my ~/.bazaar/plugins and not distro package
<jelmer> mathrick: yeah, that's fairly old
<jelmer> mathrick: You might also want to try the daily builds PPA
<mathrick> I will, yeah
<mathrick> huh
<mathrick> now I got 0.5.2 from distro, and it errors out with "not a branch"
<AfC> jelmer: is the bzr-git 0.5.2 from Ubuntu Maverick sufficient, or is this one of those "would have been updated if we could convince Canonical to SRU the thing" occasions?
<jelmer> AfC: I think it's not really about being able to convince Canonical to accept the SRU, it's more about the effort involved in doing a SRU vs the benefits
<jelmer> AfC: SRU's can't really be new upstream releases, and cherrypicking bugfixes is often tricky (and also carries risks)
<AfC> jelmer: sure. I guess you know about mere users's frustration at constantly being told "it works in the next (unreleased) release of the distro"
<AfC> For me personally your work has always been caught by that. Kinda a shame. (for example, I want almost  8 months without being able to use Bazaar to work on GNOME stuff. It's working now, though, for which I compliment you and the others working on bzr-git!)
<jelmer> AfC: Yes, I realize that - I've hit it as well myself.
<jelmer> AfC: But this isn't specific to Bazaar, it's specific to bleeding edge code in general - I see the same thing with Samba 4.
<jelmer> well, specific to bleeding edge code and the fact that releases happen only every 6 months
<mathrick> jelmer: where exactly is the daily build PPA you mentioned?
<jelmer> mathrick: https://launchpad.net/~bzr/+archive/daily
<AfC> [as a slightly broader theme, Fedora is utterly unusable because no one runs release - developer throw stuff at rawhide without really caring about it, and meanwhile corporate sustains RHEL, but no one is actually trying to live on current and the result is always "wait for the next release"]
<AfC> jelmer: right, but if we never get the code [in Ubuntu's terminology, SRU
<AfC> jelmer 'ed] then the code will always be bleeding edge :)
<AfC> anyway, not meaning to nag
<jelmer> AfC: SRU's are fairly heavyweight (for a good reason, we don't want to break existing stable users)
<AfC> Yeah, but when shit wholesale doesn't work, then who cares that it's "not broken"?
<jelmer> AfC: http support in bzr-git was only added recently anyway - most people use git://
<AfC> Of course, we are dealing with this in GNOME land right now - GTK 3.0 is still not out and GNOME 2.26 aka GNOME 3.0 is due out in less than three months. Total dogs breakfast.
<mathrick> jelmer: ah, but that doesn't have bzr-git in it, does it now?
<mathrick> no, it does
<mathrick> it showed something different when I googled
 * mathrick confused
<jelmer> mathrick: https://launchpad.net/~bzr/+archive/daily lists it for me
<mathrick> yeah, it does
<mathrick> jelmer: re: SRU, bzr seems to be particularly hard-hit by always being in the "will work in the next release" limbo
<mathrick> I'm not quite sure what makes it so prone, but it's always there
<jelmer> mathrick: I'm not sure either :-/
<mathrick> probably because there's so much tricky interop code (hello, Mr Jelmer sir), which never quite works until it's been bashed at by many people for a long time, which means every time you hit a bug, you're pretty much required to wait or go to the -dev anyway
 * jelmer will probably be a bit more involved in the Ubuntu packaging of Bazaar as of January
<mathrick> which suggests it'd be actually stabler for end-users if they could get recent packages in stable
<jelmer> mathrick: I think if the packages are that error prone we should probably not have them in stable releases at all :-/
<mathrick> jelmer: but then they will never get tested and brought up to the real-world quality
<mathrick> at some point, the shit has to hit the fan. If you want bzr to talk to git and SVN seamlessly, somebody has to test it in real-world broken scenarios
<jelmer> mathrick: Users who are interested can always use the daily builds PPA or backports
<jelmer> and that has a much quicker feedback + fix cycle
<mathrick> true
<jelmer> mathrick: fwiw the clone of the http git repo just succeeded here
<mathrick> yeah, it's at 469 / 609 here with PPA
<exarkun> Urff.  Negative revision numbers?
<exarkun> Not quite what I was going for.
<exarkun> How should I extract some (quite well isolated) changes from one branch and put them into another unrelated branch, preserving their history?
<exarkun> I thought rebase would work, but it kept too much history.
<exarkun> does the remove-revisions plugin do what I want?
<mathrick> exarkun: what exactly do you mean by "preserving their history"?
<exarkun> There's 11 or 12 revisions, with their own diffs and commit messages and such
<exarkun> I should have put them in a different branch than I did
<exarkun> I want what I would have gotten if I'd put them in the right branch in the first place
<mathrick> exarkun: then probably bzr-fastimport is what you want
<exarkun> Thanks
<mathrick> it won't preserve the tree equivalence (that is, you won't be able to merge properly before and after), but the commits will look the same
<exarkun> sounds like just what I want
<mathrick> jelmer: so yes, a PPA bzr-git works fine with that repo, thanks
<jelmer> mathrick: great
<mathrick> I also need a way to export all revisions from one repo (shared repo, not branch) into another, and move all the branches based in that repo there
<mathrick> because it's corrupted and hits me hard, particularly when I touch anything git-related
<mathrick> any idea how to do it?
<mathrick> I don't mind a bit of programming against bzrlib if that's what it takes
<jelmer> mathrick: this is a bzr repo?
<mathrick> yes
<jelmer> mathrick: how is it corrupted?
<mathrick> jelmer: sec, I'll get the errors it throws
<exarkun> humph, `bzr: ERROR: Unable to import library "fastimport": No module named fastimport`?  I branched fastimport directly into my ~/.bazaar/plugins/
<jelmer> exarkun: do you have the fastimport python module installed?
<txdv> is there a standard for the bzr commit message? I know that the first line has to be short, but do i have to break up the subsequent lines up or can i use long long lines?
<exarkun> jelmer: All I did was branch fastimport into ~/.bazaar/plugins.  Is there something beyond that I should do?  The README suggests that's intended to be sufficient.
<jelmer> exarkun: you need the python-fastimport package or the fastimport module from http://launchpad.net/python-fastimport
<jelmer> txdv: it's up to you
<exarkun> I see
<jelmer> exarkun: I've clarified the error message
<exarkun> cool, works now, thanks
<txdv> bzr so fucking lacks --amend
<exarkun> oh man
<exarkun> trying to merge that fast-imported stuff, http://codepad.org/stXoQ9jp
<jelmer> exarkun: what are you trying to do?
<exarkun> fix one tiny mistake :(
<jelmer> exarkun: are you trying to merge into an empty branch?
<exarkun> yes
<jelmer> exarkun: That doesn't work at the moment - there's an open bug about it. Is there any reason for not pulling?
<jelmer> txdv, exarkun: yes, we need better tools for history editing :-/
<exarkun> no, I just didn't know there was a special case around empty branches for merging
<jelmer> exarkun: it's a bit of an odd situation. hg and git both simply default to a pull in this situation, perhaps that's what we should do too for the moment.
<exarkun> jelmer: even refusing to merge would be better than corrupting the target branch :)
<exarkun> I don't have an opinion beyond thinking that the current behavior is kinda bad.
<mathrick> exarkun: there's no special case really, it just fails because of the nature of the operation
<exarkun> mathrick: it's a special case for me.
<mathrick> it's that git and hg both silently replace it with pull when possible
<mathrick> which bzr doesn't
<exarkun> and I have no experience with git or hg in this situation
<mathrick> I've seen good arguments against bzr's behaviour
<exarkun> so don't think I'm trying to impose another system's behavior on bzr :)
<mathrick> exarkun: well, they basically go "oh, I can pull, so I'll just interpret it as a pull request instead of merge"
<mathrick> bzr, OTOH, sticks to merge unless you tell it not to with --pull
<exarkun> merge and data corruption
<exarkun> :)
<mathrick> and pull and merge are two different situation. Pull can succeed on an empty tree, merge not really
<mathrick> exarkun: sure, it _shouldn't_ corrupt the tree. That is clearly a bug. But it also helps to know that merge on an empty tree is sort of meaningless
<mathrick> s/situations/operations/
<exarkun> whereas merge on any non-empty tree is not sort of meaningless.  so how is it not a special case?
<mathrick> exarkun: because it's not _coded_ to be a special case. It's just an edge condition in which the algorithm fails. So it's the opposite, it fails to special-case the situation it should
<exarkun> alright
<mathrick> sort of like throwing -1 at sqrt() function that's not prepared to deal with negative numbers
<mathrick> jelmer: sorry, I got completely sidetracked there, lemme get the error
<mathrick> jelmer: it doesn't seem to error out in the same way as before so far, but one of the things I get is that when I do "bzr get git://github.com/dto/iosketch.git", I get "updating git map" about 20 times
<mathrick> some of them are like 1/2, some 1/41, and now one 1/1245
<jelmer> mathrick: that's because of the repository you're cloning into
<peitschie> hi everyone :)
<RenatoSilva> Ursinha-afk: help me please
* spiv changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | 2.3b4 is officially out ! (rm vila)
#bzr 2011-12-12
<vila> hi all
<jelmer> hi vila
<mgz> morning all
<vila> synchronicity :) hey mgz, jelmer
<mgz> who's pilot?
<mgz> ...jelmer, sayeth the wiki
* mgz changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot:
<mgz> ...arkgr
* mgz 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
<jelmer> ah, hmm
<jelmer> vila, mgz: if either of you could do a second review of https://code.launchpad.net/~nmb/bzr/893470-dedupe-list-branches/+merge/83075, that'd be grand
<jelmer> hmm, doesn't seem like there is an awful lot to PP on..
<vila> jelmer, mgz: on it
<mgz> jelmer: there might be a rush later in the week, you never know :)
<mgz> jelmer: is bug 55461 fixed now with the splitting of get_transport in two?
<ubot5> Launchpad bug 55461 in Bazaar "get_transport accepts non-URL's" [Low,Confirmed] https://launchpad.net/bugs/55461
<jelmer> mgz: yup
 * jelmer assigns to himself
<jelmer> mgz: thanks
<vila> jelmer: reviewed, BB:tweak
<jelmer> hmm
<jelmer> mgz: bug 390486 also seems to be in progress now..
<ubot5> Launchpad bug 390486 in Bazaar "bzr should automatically retry idempotent network operations" [Low,Confirmed] https://launchpad.net/bugs/390486
<mgz> heh, just looking at that one as well.
<mgz> trying to find a bug for remote push not creating trees, but we don't seem to have anything saying exactly that
<vila> because we've never supported it except via push-and-update
<jelmer> mgz: bug 325355 ?
<ubot5> Launchpad bug 325355 in Bazaar "smart server should update remote working trees" [Medium,Confirmed] https://launchpad.net/bugs/325355
<mgz> ...that'll do
<vila> and the current effort from jelmer is blocked by the chroot
<mgz> if it was a real chroot, could just treat the paths as relative to /
<mgz> and worry less about accidentally escaping
<vila> the issue is that the chroot is a transport and wts want local paths (or be fixed to use the transport API)
<vila> does 'safe_decode() called on an already-unicode string' ring a bell ? Recent addition ?
<mgz> o_O
<vila> seen in an import log file so a trace.mutter probably
<mgz> stack? it's not a function we use I think
<vila> brz-builddeb ?
<vila> yup, in util.py
<mgz> ah, b...
<mgz> you got there first
<vila> testing a local jubany ~clone
<mgz> change that to mutter_callsite if you want to see the cause
<astraljava> Hi guys. Got a small puzzle here which is probably a cakewalk for you guys. Basically, I did a merge on a branch, which wasn't up-to-date, and now as I try to revert, it does nothing.
<astraljava> The branch is lp:~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.precise
<mgz> astraljava: did you commit the merge?
<astraljava> mgz: Yes. Now I got it reverted, but the earlier commits are still missing.
<mgz> reverted as in... `bzr uncommit` or as in `bzr revert -r-2 && bzr commit` or as in `bzr merge -r-1..-2 && bzr commit`?
<mgz> likely, all you want is to do `bzr pull`
<astraljava> mgz: I did `bzr uncommit` && `bzr update`
<mgz> and get the tip from lp again... unless you already pushed to lp
<mgz> in which case you want to get the old head from your repo and pull that revid
<astraljava> mgz: I didn't push after the uncommit, no.
<mgz> so, does pulling from lp get you back up to the latest rev?
<astraljava> mgz: No. It is back to the revision that I pushed as the merge.
<mgz> okay, so you did push to lp.
<astraljava> mgz: I pushed after the merge, yes, but not after the uncommit.
<astraljava> Sorry if I was unclear.
<astraljava> I was told that bzr doesn't allow this operation (pushing from a non-up-to-date branch) by default, but I don't find --overwrite in my config either.
<astraljava> I didn't expect this, cause I use other rcs more, and there this doesn't happen. Is there a config entry I can make so that it won't happen again?
<mgz> it is a little suprising it was allowed, suggests you didn't do exactly what you thought
<mgz> what changes did you lose from tip? just two?
<astraljava> mgz: Perhaps so, I claim not to be an expert by any means.
<astraljava> mgz: Two, yes. There were already commits 1278 and 1279, but seems my branch was only at 1277, thus my merge commit becoming the new 1278.
<mgz> one from colin and one from steven? in which case, you just reordered the mainline
<mgz> which is easy to fix, and there is a config option to prevent accidentally doing it
<astraljava> mgz: I believe so, yes. I only noticed 1279 from Colin.
<mgz> so, in your local branch, do
<mgz> `bzr pull -r 1277.1.2`
<mgz> then you can either merge the current tip, or redo the original merge and overwrite the top revision on lp
<astraljava> Did the first, now says on revision 1279, which sounds lovely.
<astraljava> So it's up-to-date now, and I can merge another branch with that?
<mgz> so, if you now do `bzr merge :parent`
<mgz> you'll merge in the merge you did already, but without reordering the mainline, and can commit and push that
<mgz> which should make the branch on lp look sensible again without having to uncommit there as well.
<mgz> or, at your choice, do uncommit lp:... and if anyone has pulled in the mean time they'll need to drop that revision too
<mgz> once done playing, can avoid this in future by doing `bzr config append_revisions_only=True -d lp:~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.precise`
<astraljava> mgz: Okay, so `bzr status` says there's a pending merge, so I just merge again now? What does `bzr merge :parent` mean?
<mgz> ...this is a little hard to explain without drawing trees
<astraljava> mgz: Okay, nevermind. :)
<mgz> basically, all you did was change the left-hand path
<mgz> by merging your previous merge again, but onto the latest revision, you change what counts as the mainline back to what it was
<mgz> (:parent just means "from launchpad" in this case, which has the merge you did before)
<astraljava> mgz: Gotcha.
<mgz> so, committing this merge and pushing it reorders the tree again
<mgz> but existing revisions stay as they were
<mgz> there are some threads on the bazaar list with pretty pictures
<astraljava> mgz: I must have done something wrong, still, cause now it says the branches have diverged.
<mgz> do `bzr log -c-1 -n0` in your local branch and pastebin me the output?
<astraljava> mgz: http://paste.ubuntu.com/767743/
<astraljava> Oh btw. can that config be a global one? I didn't find a global config file.
<mgz> it's a per-branch config
<astraljava> Okay, thanks.
<mgz> ideally it'd be set true by default in many circumstances, as this is confusing and annoying for people
<mgz> right... that's not the right revision merged somehow
<mgz> but you could push --overwrite that and it would be fine.
<astraljava> Ok, so it will be fine for others after the push?
<mgz> it would tell them their branches have divered if they've already pulled, but it's likely not fatal here
<astraljava> mgz: Okay. Is there then a way to get rid of that message? I could tell people that then, if they visit our channel complaining about that.
<mgz> they basically just need to pull --overwrite
<astraljava> Ok. Haha! Now it complains about "AppendRevisionsOnlyViolation". :D
<mgz> right :)
<astraljava> Ok, let's see now whether it worked alright.
<astraljava> At least it says it pushed up to revision 1280.
<astraljava> YES!
<astraljava> mgz: I could kiss you right now.
<astraljava> mgz: But I think I better let that be.
<astraljava> Thanks so much!
<mgz> great!
<glen> how do i update current trunk checkout to some named tag?
<mgz> `bzr update -rtag:your_tag`
<glen> $ bzr up -r tag:release-2.3.1-final
<glen> bzr: ERROR: no such option: -r
<jelmer> glen: what version of bzr are you using? the -r option is fairly recent.
<glen> bzr-0:2.0.3-1.amd64
<jelmer> that's quite old
<jelmer> more than two years I think
<jelmer> glen: you can also use "bzr revert -rtag:your_tag"
<glen> not as old as bzr-1.18-1.amd64.rpm :)
<vila> Riddell: hey ! How are you ? Hopefully better ?
<glen> and how to go back to trunk?
<jelmer> glen: "bzr revert"
<mgz> he has too many llls now, perhaps he's become welsh?
<vila> argh, false alert ?
<Riddelll> vila: well better is a relative term, my brain is still a bit slow and I've got an eye blocked off else I see squint
<glen> jelmer: seems i can't upgrade bzr. i'm on py2.4. [ERROR] Not a supported Python version. Need 2.6+
<vila> :-/
<vila> Riddelll: glad to see you here anyway :)
<Riddelll> vila: I won't be driving on French roads in the near future :)
<vila> Riddelll: caribean drivers (and roads) are... different
<vila> Riddelll: what happened ?
<vila> Riddelll: I remember getting very very scared the first time I saw a car on the right *lane* one night, stopped and without lights...
<vila> Riddelll: since then, I drove far slower...
<Riddelll> vila: I don't remember what happened
<vila> :-/
<vila> Riddelll: you were alone ?
<Riddelll> yes
<vila> Riddelll: and woke up at the hospital ?
<Riddelll> yes
<vila> :-(
<Riddelll> where the doctors promptly kicked me out and sent me home in a taxi
<mgz> Riddell: we love you, even if we can't do much from this side of the ocean :)
<Riddelll> I'm back on the same side of ocean now
<Riddelll> in presence if not in timezone
<mgz> ah, you're returned? in time for the cold and storms?
<vila> Riddell: wow, that was rude :-(
<vila> Riddell: I hope you still have better souvenirs from Guadeloupe :-}
<Riddell> mgz: the storms I'm used to but not the cold
<schnoodles> Howdy i merged a branch and pushed it but i was told that its not ready to be merged. How do i revert the git history ?
<jelmer> glyph: bzr < 2.4 should still work
<jelmer> glyph: bzr 2.3 is a huge improvement over 2.0
<jelmer> schnoodles: wrong channel ? :)
<mgz> glen: ^
<jelmer> oops
<jelmer> sorry glyph
<jelmer> glyph: I guess you're higher than glen in my irssi <tab> priority list..
<jelmer> urgh
<jelmer> 1490 'open' calls during a simple "bzr ls" without plugins
<jelmer> (my serializer-avoids-xml branch brings that down to ~1290)
<jelmer> there is lots of stuff in there that's unnecessary though
<vila> jelmer: o_O, open as in python builting open ?
<mgz> is that including imp...
<vila> s/g//
<mgz> what vila asked
<jelmer> vila: no, libc open
<jelmer> there's ~100 opens related to ubuntu one
<vila> what does u1 have to do with 'bzr ls' ???
<jelmer> vila: it installs extra .pth files, which means python probes for modules in more locations
<mgz> okay, back to what I was asking then, how many of those are python imports?
 * jelmer files a bug against u1
<vila> argh
<jelmer> mgz: all but 2 dozen
<jelmer> mgz: those 2 dozen are system libraries and bzr repository opens
<jelmer> hmm, more like 3 dozen, actually
<jelmer> mgz: 1206 from python, 20 from the system and 19 for bzr
<mgz> okay, not quite as bad as it sounds then, we do need to do some more stuff on reducing the total number of modules basic bzr operations want though.
<jelmer> vila: bzr actually opens bazaar.conf 6 times :(
<mgz> vila's on that! :)
<jelmer> mgz: (that's with my xml branch, otherwise there's 200 more from the xml modules)
<mgz> reviewing now
<vila> jelmer: I know, there is currently no central place where we could avoid re-opening bazaar.conf
<mgz> library_state!
<vila> mgz: hehe, yes, library_state will be involved but some sort of possible_config_stores is also needed
<jelmer> bug 903180
<ubot5> Launchpad bug 903180 in ubuntuone-storage-protocol (Ubuntu) "extends python path, slowing down python imports" [Undecided,New] https://launchpad.net/bugs/903180
<jelmer> vila, mgz: Hmm, I wonder if it makes sense to use "from __future__ import absolute_import" everywhere
<vila> jelmer: what does absolute_import ?
<mgz> vila: breaks plugins :)
<vila> oh, you mean, making relative imports illegal ?
<vila> +1 :)
<jelmer> mgz: I don't think it will, it's limited to the module in which you add it right?
<mgz> I'm joking a little jelmer, 'everywhere' would take some doing.
<mgz> but bzrlib shouldn't break... much
 * mgz eyes bzrlib.test_suite
<mgz> def test_suite(): import tests return tests.test_suite()
<vila> pff
<mgz> I'd prefer not to add things all over the code base if we could do a lint check instead.
<mgz> otherwise seems a fine idea.
<jelmer> hmm, actually
<jelmer> it's a trivial patch to make lazy_import do absolute imports only by default
<mgz> that's worthwhile.
<jelmer> now that we're on >= 2.5
<mgz> jelmer: do we want mkdir -p to actually not complain if dir exists?
<mgz> seems that's the shell behaviour so might be least suprising
 * mgz writes some tests and adds try/except
<jelmer> mgz: hmm, I guess
<jelmer> mgz: it seems we'll need to check before running os.makedirs(). The code that does the versioning already handles it existing.
<mgz> well, what I've just written is catching the OSError
<mgz> but... seems that builtins doesn't have the errno module imported which is mildly annoying
<mgz> okay, lazy import, tests pass
<mgz> phone answered, branch pushed
<jelmer> mgz: sorry for the noisy comments..
<wgz> I approve of noise!
<vila> wgz: meh, I missed that while reviewing but it seems get_environ_unicode in win32utils is not used outside of tests ??
<wgz> vila: indeed, it's another one of the little pieces branches
<vila> ha ok
<wgz> next in the stack is bug 832028
<ubot5> Launchpad bug 832028 in Bazaar "environment variables are not decoded properly" [Medium,Confirmed] https://launchpad.net/bugs/832028
<vila> wgz: ok, what's the plan ?
<vila> requires some encoding and force a wrapper around os.environ ?
<wgz> pretty much
<wgz> -    base = os.environ.get('BZR_HOME', None)
<wgz> +    base = osutils.path_from_environ('BZR_HOME')
<wgz> hm, commited that with the wrong whoami last week
<wgz> the tricky bit is not breaking nix too much by decoding paths we used to let through as bytestrings
<wgz> hence the diversion via bug 794353
<ubot5> Launchpad bug 794353 in Bazaar "ascii is a bad default filesystem encoding" [High,In progress] https://launchpad.net/bugs/794353
<wgz> argh, would have been faster to just delete everything and start from scratch, there's no sense to how things are arranged currently
<jelmer> wgz: which things?
<wgz> all of osutils and win32utils more so, and how they interact
<jelmer> ah
<wgz> I can't use osutils functions from win32utils (without local imports), and the randomness of how things are split between then is crazy
<wgz> there's a bug that was reported, and worked around, just because it wasn't clear there was already an implementation of the right thing in the other file
<wgz> and bzr-explorer et all make things worse by duplicating even more :)
<jelmer> ahh
<wgz> need to stop trying to make things perfect and just... go for better
<glyph> wgz: Le mieux est l'ennemi du bien
<wgz> should make that my motto really, I get stuck on dumb things like this way too much
<glyph> Is there an idiom that bzr users use which I haven't discovered yet, which is (without using colocated branches) similar to 'git fetch'?
<glyph> I find myself doing stuff like "(cd ../upstream; bzr pull); bzr pull" quite a lot.
<jelmer> glyph: there is "bzr multi-pull"
<jelmer> part of bzrtools
<glyph> "... and the branches of checkouts"?
<glyph> this is going to be a learning adventure :)
<jelmer> glyph: branches of checkouts?
<Saxy> Anybody here ?
<Saxy> Have a question about bazaar !
<Saxy> .-(
<Saxy> Will try again later !
<glyph> jelmer: heh, unfortunately my directory structure (there are SVN checkouts here too) looks quite antagonistic towards multi-pull
<glyph> but this will be quite useful in some cases
<glyph> jelmer: what's a "branch of a checkout" though?
<glyph> My understanding was that a branch was a thing you have a checkout of, not vice versa.
<fullermd> Presumably it means "the branch this is a checkout of".
<fullermd> i.e., foreach(thing in we_found) { pull(open_branch_of(thing)) }
<thomi> Hi - is there a bzr command that lets me know if branch X will cleanly merge into this branch? Currently I do a merge & then a revert, but maybe there's a simpler way?
<wgz> thomi: `bzr merge preview > /dev/null && echo 'Will merge cleanly'` maybe?
<wgz> *--preview
<thomi> oooh
<thomi> hmmm, it's be nice to have a --dry-run flag
<thomi> because I can't do the above with a bzr alias.
<thomi> I guess I could set up a bash alias, but that's not as nice.
<wgz> I'm reading the XDG Base Directory spec, and I have no idea where it thinks .bzr.log should go
<jelmer> wgz: that's a good question, indeed
<spm> jelmer: ta wrt the importd cleanup; just getting rid of the .db and tmp files now.
<mgz> okay, enough banging head against this environment/configs stuff, let's discuss it in the standup tomorrow
<jelmer> spm: anytime :)
<wgz> ha, bug 257895 is funny, the xml inventories don't cope with files containing C0 control codes
<ubot5> Launchpad bug 257895 in bzr (Ubuntu) "bzr: ERROR: not well-formed (invalid token)" [Low,Confirmed] https://launchpad.net/bugs/257895
<wgz> that must be pretty much wontfix by now, it would require layering an escaping scheme on top, or at least rejecting dodgy filenames
<jelmer> wgz: you have an... interesting sense of humour
<wgz> I was looking the regexps in your code moving earlier today and thinking "hey, that's not actually correct",
<wgz> and lo, we have bugs.
<jelmer> wgz: introduced by me, or prexisting?
<jelmer> *pre-existing
<Noldorin> hi folks
<Noldorin> lifeless, hey
<wgz> jelmer: bugs as old as the original code, not your move today
<Noldorin> hi wgz
<wgz> I can never tell if you saying hi means you want something Noldorin :)
<Noldorin> wgz, who doesn't? :-P
<Noldorin> would you prefer i say bugger off ;-)
<fullermd> If you're offering, I'd like a bacon cheeseburger.
<jelmer> fullermd: I think you have to say hi first
<wgz> we're having a burger off?
<wgz> I don't think I'm very good at making burgers...
<fullermd> You kill a cow, you kill a pig, you put the big on the cow, add fire.  's not that hard   :p
<fullermd> (note that I didn't say the fire should be _near_ the cow and the pig, of course.  Who wants burnt meat?)
<Noldorin> wgz, fullermd you could have made a slightly less appetising joke but that isn't what i meant either :-P
<Noldorin> wgz, bah, you probably aren't even familiar with the English expression :-P
<Noldorin> anyway...
<BlindWolf8> Hello all. Is there a way that myself or a team member can view the latest changelog without doing an Update/Pull locally?
<LeoNerd> bzr log URL
<fullermd> Will probably be as fast (or faster) to pull locally though, unless you're a long way behind.
<BlindWolf8> I think he just wants to see it to avoid conflicts...I could just get him to update at the start of each day to avoid issues
<spiv> "bzr missing URL" might be what they want?
<BlindWolf8> that could be...is there a GUI option or is the only option a command line?
<BlindWolf8> he can use the comand line no problem, but I figured I'd ask
<BlindWolf8> btw, just saw an option for Shelve/Unshelve changes. I'm assuming this is something new? what does it do?
<maxb_> It has existed for years :-)
<BlindWolf8> hahah
<BlindWolf8> I found the docs
<maxb_> It means to temporarily remove uncommitted changes from the working tree and hide them inside the .bzr dir for later recall
<BlindWolf8> does shelfing a change work on uncommited changes too?
<BlindWolf8> I'm assuming so since shelfing a commited change is just like reverting
<maxb_> shelving a committed change doesn't really make any sense to me
<BlindWolf8> right, just making sure
<BlindWolf8> thanks guys!
#bzr 2011-12-13
<mgz> morning!
<vila> mgz: hey !
<vila> mgz: already read your proposal for paths from env, will review shortly
<mgz> thanks vila
<vila> mgz: done, update pending, will reboot shortly
<mgz> thanks vila!
<vila> mgz: thanks to you, that proposal is really good
<vila> jelmer: so you fixed bug #pipi :)
<vila> jelmer: wait, no, you finished the fix from Riddell (the bug number is still funny though ;)
<mgz> ...isn't LGPL entirely pointless for python?
<vila> no idea
<vila> mgz, jelmer : standup ?
<mgz> standup now if jelmer's around would be good, I need to nip out over lunch
<vila> k, let's see when he comes up
<mgz> jelmerctl start
<vila> jelmerctl alarm ring
<jelmer> hi vila, mgz
<vila> It Works !!!!
<jelmer> I'll be right there
<jelmer> :)
<mgz> :)
<vila> jelmer, mgz: pad created, ready when you are
<jelmer> mgz: join us?
<mgz> nearly with you, too many tabs to close
<jelmer> mgz, vila: bug 881142
<ubot5> Launchpad bug 881142 in Bazaar "AssertionError: unversioned parent while creating working tree using pypy" [Medium,Confirmed] https://launchpad.net/bugs/881142
<zyga> hi http://paste.ubuntu.com/768793/
<zyga> I got this on precise just now
<zyga> is this known?
<jelmer> mgz: ^
<jelmer> zyga: please file a bug
<jelmer> zyga: we'll assign it to mgz :)
<zyga> jelmer, will do
<zyga> bug 903639
<ubot5> Error: Launchpad bug 903639 could not be found
<zyga> meh, private bug reports
<zyga> jelmer, mgz: ^
<jelmer> zyga: thanks
<jelmer> mgz: ^
<mgz> zyga: looks from the traceback like fallout from me removing some default options, should be easy to fix, thanks
<zyga> mgz, this bug is highly annoying, I'd love to use a beta/trunk just to get rid of it
<zyga> on the similar topic, when using bzr pressing tab for the first time takes a good 5-10 seconds to finish, have you seen this yourself? I think it's related to one of the foreign vcs plugins (perhaps svn, I did some digging around this a few months ago but my memory might be faulty now)
<jelmer> zyga: that's the hard disk cold cache, python loads a lot of stuff on startup
<zyga> jelmer, I don't think so, it happens all the time throughout the day, it's not just pure disk cache (I can trigger this by going to another directory and pressing tab a few times) -- if anything it is related to a repository/working tree/branch
<zyga> jelmer, and I'm 100% sure it does not happen if I get rid of all the foreign vcs plugins
<zyga> (I remember this being x10-100 slower on windows when using a large repository)
<zyga> anyway
<zyga> separate bug
<zyga> I can scratch my itch when tab works again
<jelmer> zyga: the foreign plugins only update a few dictionaries during bzr loading
<jelmer> zyga: so I'd be surprised if they actually have an impact on startup overhead
<jelmer> unless the bash_completion script is doing something weird
<zyga> jelmer, interesting, I'll try to measure this sensibly if I can get tab complete to work
<mgz> zyga: the issue there is I'm not sure which plugin has the problem option
<zyga> jelmer, I'm 100% sure it's not as nice as you say, perhaps the interactions are less trivial than I thought
<zyga> jelmer, but pure bzr was lightning fast on tab complete last time I've checked
<zyga> mgz, I can help you track this down
<zyga> mgz, is there a way to switch plugins on and off one by one?
<mgz> vila: ^
<jelmer> zyga: set BZR_DISABLE_PLUGINS=name1:name2:name3 in the environment
<zyga> jelmer, ok, let's try this
<zyga> jelmer, I'm getting plugin names from the output of `bzr plugins`
<jelmer> zyga: nevermind, I see what's going on here
<zyga> oh
<jelmer> zyga: bash-completion is triggering the loading of all plugins
<zyga> jelmer, It happens when I keep the 'git' plugin
<zyga> jelmer, disabling it makes tab work
 * zyga keeps digging
<zyga> yup
<mgz> okay, so, you can redo the bash-completion script sans plugins with:
<zyga> only git seems to be affected
<zyga> $ BZR_DISABLE_PLUGINS=git bzr bash-completion
<zyga> mgz, this works
<jelmer> zyga: can you try with bzr-git trunk?
<zyga> jelmer, sure, just a moment
<zyga> do I need to get rid of the packaged plugin or will ~/.bzr/plugins take priority?
<jelmer> zyga: ~/.bazaar/plugins takes priority
<zyga> good
<vila> this is controlled by BZR_PLUGIN_PATH
 * zyga branches lp:bzr-git
<zyga> jelmer, git trunk works
<jelmer> zyga: it works and it doesn't slow things down, or it just works ? :)
 * zyga thinks that bzr needs firefox-style plugin compatibility system where plugins are NOT loaded if they are not marked as supporting certain version of bzr
<zyga> jelmer, I'm just checking plain tab working
<zyga> jelmer, let me check speed stuff now
<jelmer> zyga: we have that actually, but it's up to plugins themselves to sign up for that
<zyga> jelmer, perhaps it would be saner to swap that responsibility
 * jelmer files bug 903650
<ubot5> Launchpad bug 903650 in bzr-builddeb "loads lots of modules in top-level of cmds module" [Medium,Triaged] https://launchpad.net/bugs/903650
<mgz> zyga: so, can run for each of those plugins in your list:
<mgz> `bzr bash-completion --plugin launchpad >/dev/null`
<zyga> mgz, sure
<mgz> with 'launchpad' replaced in turn with a plugin
<mgz> and see which one throws the error
<mgz> (if any are very noticiably slower that's also interesting)
<zyga> mgs, no crashes
<zyga> all seem fast now
<mgz> ...is that with any of the plugin envvars set?
<mgz> I'm trying to work out which plugin I need to update, so I want the error :)
<zyga> mgz, no, that's without any special environment
<zyga> mgz, you probably want to look at the git plugin as I indicated above
<mgz> ah, I did actually change bzr-git
<mgz> so updating that would have been enough
 * mgz wasn't following closely enough :)
<zyga> yes, it seems to be enough
 * jelmer will look at doing another bzr-git release
<vila> wgz: when you get back, down to 4 failures on babune's windows slave, expected or just lucky ?
<johan> Hi, I'm having a problem with a bzr repository of mine:
<johan> $ sudo bzr update
<johan> All changes applied successfully.
<johan> bzr: ERROR: An inconsistent delta was supplied involving 'gdm/failsafeBlacklist', 'failsafeblacklist-20101011211133-ux797y0aieyjrmnf-718'
<johan> How can I solve that issue?
<vila> johan: bzr version ?
<johan> vila: 2.4.2
<johan> format 2a of the branch
<vila> hmm, better file a bug, we fixed some inconsistent delta bugs lately but 2.4.2 is recent enough to include them
<vila> you may try a 2.5 beta to be sure
<johan> do you know the ppa name in your head?
<vila> johan: also, .bzr.log will probably contain more detailed data that should help diagnosing the issue
<johan> vila: https://bugs.launchpad.net/bzr/+bug/855155
<ubot5> Ubuntu bug 855155 in Bazaar "InconsistentDelta error when using bzr update" [High,Confirmed]
<johan> less
<johan> oops :(
 * vila blinks, kiko ? Is that you hiding behind johan ? You've got the *exact* same file reported in the error
<vila> including the file-id...
<johan> vila: I'm not kiko, but it's the same repository
<vila> hehe
<johan> vila: I added the relevant parts from .bzr.log to that bug
<vila> johan: did you try bzr repair-workingtree as suggested in the comments ? (Keeping a copy of .bzr/checkout/dirstate just in case ?)
<vila> johan: is that a public repo ?
<johan> vila: yes, I tried that, it does not work
<vila> ok, mention that in the bug report, that will help
<vila> ... others
<johan> vila: nope, it's /etc of a server I'd rather not expose the configuration in public for
<vila> hmm
<vila> anything special about this repo ? stacking ?
<vila> johan: can you paste bin an ls -lR of .bzr on paste.canonical.com ? (.bzr contains only bzr stuff, nothing confidential should be exposed by an ls)
<johan> just a sec, checking 2.5 beta
<vila> johan: and do you know if kiko find a way out for his own case ?
<vila> johan: sure, waiting
<johan> vila: it's the same case, we both maintain the same server
<vila> ok, 'bzr st' paste too ?
<vila> or is status already failing in this setup
<vila> maxb: 2.5b4 is out, could you update the beta ppa ?
<johan> vila: http://paste.ubuntu.com/768887/
<johan> vila: and http://paste.ubuntu.com/768889/ for bzr st
<johan> g
<johan> gotta run, but I'll be back in 2h
<vila> johan: let us know when you're back
<vila> johan: just looking at your pastes, the first question that comes to mind is: is there a gdm/failsafeBlacklist in the tree ?
<vila> johan: the second one is: it's weird to see a file-id with  '-20101011211133' and no pack file around this date (but may be it just get repacked into a more recent one),
<vila> the '-718' hints at a massive 'bzr add' (including at least 718 files) but that doesn't mean this get committed
<vila> johan: there are several things we can try to 1) get you out the problem, 2) better diagnose what is happending, but both need your hands ;)
<jml> I've got python-bzrlib 2.4.1-1ubuntu1 installed, but it doesn't come with bzrlib.tests.
<jml> Which is annoying, since I'm using code that depends on bzrlib.tests (lp:udd, fwiw)
<maxb> jml: apt-get install python-bzrlib.tests
<jml> maxb: wow. thanks.
<johan> vila: there's no gdm/failsafeBlacklist in the tree
<johan> revisioned or not
<vila> johan: hmm, there was one at some point apparently
<vila> johan: what does 'bzr rm --keep gdm' says ?
<vila> johan: no wait,
<vila> johan: is 'gdm' still versioned (in itself or because other files into it are versioned) ?
<johan> vila: gdm is versioned
<johan> gdm/failsafeBlacklist was versioned in revno 1
<johan> $ sudo bzr rm --keep failsafeBlacklist
<johan> gdm/failsafeBlacklist is not versioned.
<johan> bzr log -p gdm|pastebinit - -> http://paste.ubuntu.com/769040/
<johan> current revno is 306 fwiw
 * vila scratches head
<vila> johan: what happens if you do 'bzr update' again ?
<johan> All changes applied successfully.
<johan> bzr: ERROR: An inconsistent delta was supplied involving 'gdm/failsafeBlacklist', 'failsafeblacklist-20101011211133-ux797y0aieyjrmnf-718'
<johan> reason: Unable to find block for this record. Was the parent added?
<vila> bzr missing ?
<vila> err, what does 'bzr missing' says ?
<vila> say even
<johan> Using saved parent location: /etc
<johan> Branches are up to date.
<vila> 'bzr info -v' ?
<johan> http://paste.ubuntu.com/769047/
<johan> a different traceback
<vila> yup
<vila> 'bzr check' ?
<vila> could be long, heavily depends on revision graph size and repository size, but /etc.. shouldn't be that big
<johan> Checking working tree at '/etc'.
<johan> Checking branch at 'file:///etc/'.
<johan> Checking repository at 'file:///etc/'.
<johan> checked repository file:///etc/ format RepositoryFormat2a()
<johan>    347 revisions
<johan>   3288 file-ids
<johan> checked branch file:///etc/ format Branch format 7
<johan> that's the output of bzr check
<lamont> bzr: ERROR: The dirstate file (DirState(u'/home/lamont/foo/.bzr/checkout/dirstate')) appears to be corrupt: failed to find trailing NULL (\0). Trailing garbage: '\n'
<lamont> is there a way to clean that up, I wonder?
<jelmer> lamont: "bzr repair-workingtree" might help
<jelmer> vila: the issue johan is running into sounds like a transform issue?
<lamont> jelmer: what is that going to do to the working tree?
<lamont> bzr: ERROR: unknown command "repair-workingtree"
<jelmer> lamont: its help probably describes it better than I can
<jelmer> lamont: it's a fairly recent command
<jelmer> lamont: another alternative is to rm -rf .bzr/checkout, and then run "bzr co"
<jelmer> but that might move some of your existing files that have changed out of the way
<lamont> ew
 * lamont starts with a backup
<mgz> lamont: if you have lots of file metadata changes you care about, you have an issue, but just checking out the most last rev somewhere else and copying over the files in your tree would cover most things
<vila> jelmer: like a symlink -> dir issue you mean ?
<vila> lamont: or checkout somewhere else and copy the .bzr/checkout/dirstate only, then do 'bzr st'
<lamont> I saved the tree did the rm/bzr co, and then did the rsync --exclude=.bzr to bring it all back.  bzr st is now clean
<lamont> I'm going to guess that we managed to reboot the machine in the middle of something in the way of a commit or so
<vila> lamont: sounds like a possible explanation
<vila> lamont: we never have such reports though
<vila> had
<mgz> just during bzr st would be enough. dirstate isn't all that robust, but it's also easy enough to recover in most cases
<mgz> vila: we had various ext4 reports, some of those were dirstate
<vila> mgz: really ? I can remember only repository related ones... But Alzheimer...
<jelmer> vila: IIRC repair-workingtree was added exactly for this reason
<mgz> the mp for bug 898541 is sitting on its own crying, ever since it had a little blip from launchpad librarian dying... won't someone review him?
<ubot5> Launchpad bug 898541 in Bazaar " UnicodeEncodeError on mv of a deleted non-ascii file" [Low,In progress] https://launchpad.net/bugs/898541
<mgz> I'm really mad that I lost my text file with all my NULL_REVISION bug notes in it
<mgz> must have put it under a branch that got rmrfed
<mgz> spent a good half hour going through dupes and categorising failure types
<hrw> bug 893495 again ;(
<ubot5> Launchpad bug 893495 in bzr-builddeb (Ubuntu) "Zero byte successful merge after error from dpkg-mergechangelogs" [Medium,Confirmed] https://launchpad.net/bugs/893495
<mgz> hrw: good (kinda), I wanted to look at that again and can't practically merge gcc locally
<jelmer> mgz: I'll have a look
<hrw> this time I handled it with 'bzr diff -c72 >72.diff', extracting changelog.diff, applying it by hand and merging changes by hand
<mgz> a good start would be to set BZR_PDB=1 and see what this_lines, other_lines, and base_lines are and how they get generated
<hrw> ok, will branch, revert change and do merge again with this var set
<mgz> from last time, with the right THIS OTHER and BASE the merge goes fine, so the problem happens before passing things off to dpkg-mergechangelogs
<hrw> dpkg-mergechangelogs: bÅÄd: ss-970814-1 is not a valid version
<hrw> basically bug is same
<hrw> I exported BZR_PDB=1 and then did merge - no extra log outputed
<mgz> hm, but you didn't get the UnicodeDecodeError? I was relying on that to break into the debugger at a handy place
<hrw> http://pastebin.com/nsWC2uLF is whole output
<mgz> you still have my hack around that problem from last time? basically, I want to know what the merge_changelog.py sees for THIS OTHER and BASE so we know why it's generating 0 byte output (that's till the end symptom, right?)
<hrw> shit. indeed. I forgot about it
<mgz> that's fine
<mgz> if you also remove the shutil.rmtree at the bottom of that file
<hrw> it was in bzr-builddeb package?
<mgz> that will leave the tempfiles that dpkg-mergechangelog is having problems with in place
<mgz> ^yup
<mgz> you can leave the hack around in, it's harmless
<hrw> 17:53 hrw@puchatek:b$ bzr branch -r71 lp:~hrw/ubuntu/precise/gcc-4.6/gcc-linaro-ci-native;cd gcc-linaro-ci-native;BZR_PDB=1 bzr merge lp:ubuntu/gcc-4.6
<hrw> this is all you need to reproduce
<mgz> thanks hrw.
<hrw> no problem
<hrw> solving bug will help my work in ufutre
<mgz> hrw: can you try this on your local bzr-builddeb? <http://pastebin.ubuntu.com/769149/>
<jelmer> vila: urhg, we're reading the user identity from a "email" file ??
<hrw>   sure
<hrw> it will be /usr/lib/python2.7/dist-packages/bzrlib/plugins/builddeb/merge_changelog.py file?
<mgz> yes.
<mgz> what I expect on the merge: the new message added should be output, and then in /tmp there'll be a dir with 'deb_changelog_merge' in it containing the interestingly broken changelogs
<hrw> test in progress
<hrw> changelog.base
<hrw> http://paste.ubuntu.com/769169/
<hrw> changelog.other
<hrw> http://paste.ubuntu.com/769170/
<hrw> changelog.this
<hrw> http://paste.ubuntu.com/769171/
<mgz> those look not unreasonable, and `dpkg-mergechangelogs changelog.base changelog.this changelog.other > changelog` produces something reasonable?
<hrw> 18:16 hrw@puchatek:tmpgUvyzWdeb_changelog_merge$ dpkg-mergechangelogs changelog.base changelog.this changelog.other
<hrw> dpkg-mergechangelogs: bÅÄd: ss-970814-1 is not a valid version
<mgz> the warning/error about ss-970814-1 is expected, does it also fill out the changelog file?
<hrw> ss-970814-1 exists as package version
<hrw> looks like at 20 August 1997 it was valid version
<mgz> right, it exists, but debian doesn't like it
<mgz> for me, I get the warning but I also get a correctly merged 'changelog' output
<hrw> no, bzr does not like it
<hrw> when I 'LC_ALL=C' failure is same (but in English)
<hrw> changelog is never generated here
<mgz> okay. what does `dpkg-mergechangelogs --version` say?
<hrw> Debian dpkg-mergechangelogs version 1.16.1.2.
<hrw> dpkg-devii  dpkg-dev                          1.16.1.2ubuntu3                   Debian package development tools
<mgz> oh, I forgot to ask, when you ran the merge, did my new message print out after the old error?
<hrw> Packaging branch status: CURRENT
<hrw> dpkg-mergechangelogs: bÅÄd: ss-970814-1 is not a valid version
<hrw> Successful merge, but empty file? Dodgy...
<mgz> if so, there's a simple enough work around in bzr-builddeb that will help you.
<hrw> so yes, it did
<mgz> yeay, okay, will fix today.
<hrw> Ã¼bercool
<mgz> first, I'll work out what they broke in the newer dpkg versions that's causing things.
<mgz> *this
<mgz> `bzr branch apt:dpkg` ... is still really neat
<hrw> thanks
 * hrw -> off 
<mgz> ...then bzr-git nearly OOMs me to death
<mgz> let's manually delete some caches and see if it can finish
<jelmer> mgz: what are ou trying to branch?
<mgz> dpkg
<mgz> (Pdb) self._group_cache._value_size
<mgz> 44979584
<mgz> bye bye
<mgz> hm, that didn't get me my 50MB back, needed to chase refs
<mgz> ...will have to give in for now and cancel to do incremental pull
<jelmer> hah, commit over lightweight checkouts with pure HPSS \o/
<mgz> ehehe
<mgz> urk, git:/ doesn't support -r incremental pull?
<jelmer> mgz: nope, because you can't introspect the revision graph remotely
<mgz> okay, I'll just have to get the packaging branch rather than upstream I guess
<mgz> most of that mem usage was probably overhead, pulling from git to bzr shouldn't need local groupcompress caches
<mgz> that was a pain, but I have repo.
<mgz> `PERL5LIB=~/.local/share/perl5 ~/.local/bin/dpkg-mergechangelogs`
<vila> jelmer: what email file ???
<mgz> vila: doesn't die in perl get you somehting other than 0 as a return code?
<vila> mgz: not fully sure but it should
<vila> mgz: on the other hand I think I remember than die can be caught...
<mgz> oh, oh, whoops
<mgz> the logic is bzr-builddep is `if retcode == 1: ... else: # assume all is well!`
<mgz> -p+b
<vila> mgz: yup, man perlfunc says: ptrints LIST to "STDERR" and exits with a non-zero value.
<vila> geee
<vila> I managed to make tyops while pasting...
<mgz> :D
<vila> anyway, that's followed by: If you need to exit the process with a specific exit code, see exit.
<mgz> so, not dying on bad version numbers would be nice, as it doesn't in my older dpkg version, but this is nice and fixable in builddeb
<vila> johan: still there ?
<jelmer> vila: see bzrlib/config.py
<jelmer> vila: we try to read the user identity from .bzr/branch/email
<vila> ooooh, in the good old days you mean, not now ?
<jelmer> vila: we still do
<jelmer> vila: config.py:1400
<vila> ;_;
<vila> jelmer: this is broken for remote branches right ?
<vila> jelmer: this code should die and nobody should ever talk about it anymore
<jelmer> vila: hehe
<jelmer> vila: it's not broken for remote branches, it works
<fullermd> Sounds like we need the ability to edit history   :p
<jelmer> vila: but it triggers VFS access
<vila> jelmer: and who is able to create this file ?
<jelmer> vila: "echo" ? :-)
<jelmer> vila: we have tests that it still works
<jelmer> vila: but I'm all in favor of killing it, too.
 * vila bangs head
<vila> decoded with user encoding though :)
<vila> I'm off, it makes me cry too much :)
<vila> jelmer: sorry, by 'who' I was thinking about launchpad, you think it's allowed there ?
<jelmer> vila: I doubt anybody is using it, but launchpad does allow creating that file.
<vila> yeah, same here, I doubt anybody even knows about it (I'm sure I've seen this code but I managed to forget until you mentioned it ! Shame on you ! ;) Too bad lp allows it to be created...
 * vila really off
<thomi> Hi - is there a way to import a branch from repository X into a sub-directory of repository Y and keep the history of those files from repo X?
<jelmer> thomi: "bzr join" ?
 * jelmer heads out
<thomi> jelmer: it seems like that only works for branches from the same repo?
<fullermd> No, it works for any two.
<fullermd> "from the same repo" doesn't really mean much anyway.
<thomi> hmm, when I try, I get this:
<thomi> NoSuchRevision: CHKInventoryRepository('file:///home/thomi/code/unity/.bzr/repository/') has no revision thomir@gmail.com-20111208204500-9v1r9owjaz1qu6aa
<thomi> I must be doing it wrong ;)
<fullermd> What command are you running?
<thomi> bzr join subdir
<fullermd> Well, that's a new one in me.
<fullermd> Which branch is that rev from?
<thomi> the target branch - i.e.- the 'subdir'
<thomi> hmmm, I might try this with clean branches, see if I can reproduce it.... one second
<fullermd> Mmm.  Works in a trivial example I tossed together, with 2.4.2 and .dev.
<thomi> yeah, it works for me when I start from scratch...
<thomi> fullermd: filed bug: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/903906
<ubot5> Error: ubuntu bug 903906 not found
<Noldorin> hi jelmer, life
<jelmer> hi Noldorin
<jelmer> I have to admit, no lifeless on IRC would surprise me too :)
<Noldorin> jelmer, haha yeah. curse him for making me tab-fail.
<Noldorin> how's your work going anyway?
<jelmer> hacking on HPSS, going well :)
<jelmer> with a bit of luck bzr 2.5 won't need any VFS calls anymore for normal operation
<Noldorin> jelmer, not familiar with HPSS. is it like software raid?
<Noldorin> or a protocol maybe
<Noldorin> ?
<mwhudson> Noldorin: high performance smart server
<Noldorin> mwhudson, not storage system? wikipedia tells me this :-S
<Noldorin> hmm
<jelmer> Noldorin: high performance smart server
<Noldorin> what does it do? :-)
<jelmer> Noldorin: it's what powers bzr+ssh
<fullermd> Performs highly.
<Noldorin> heh
<Noldorin> fullermd, always a help :-)
 * fullermd is a helper!
<mgz> jelmer: what's traditional to do if I want to get something changed that has a debian upstream?
<mgz> file a bug against debian? just post the patch to the relevent ml?
<jelmer> mgz: you mean something that is "debian native" ?
<jelmer> mgz: a good bet is to file a bug in the debian bts and attach a patch
<mgz> ...the fun thing with that is the bug is not actually present on my system
<mgz> I'm not sure how well reportbug copes with that
<jelmer> mgz: that's fine
<jelmer> mgz: it'll ask you whether you're sure you want to file a bug, but you can just answer yes :)
<jelmer> mgz: alternatively, you can send an email to submit@bugs.debian.org
<Noldorin> bzr: ERROR: Could not acquire lock "(remote lock)":
<Noldorin> jelmer, mgz any idea what this means ona bzr init? :-)
<Noldorin> it's inside a symlink dir on windows
<Noldorin> normal dirs work fine
<Noldorin> not sure if it's to do with symlinks though...
<Noldorin> or permissions or something else entirely
<Noldorin> :-S
<mgz> from inside cygwin? symlinks don't work gererally in bzr win32 certainly.
<mgz> jelmer: still kicking? mind eyeballing a patch for me to see if I've done anything too stupid?
<Noldorin> mgz, yeah, within cygwin
<Noldorin> has to be to get ssh working heh ;-)
<jelmer> mgz: sure
<mgz> jelmer: http://pastebin.ubuntu.com/769461/
<Noldorin> mgz, recommend any alternative for windows/cygwin if i want to specify a custom base path via bzr+ssh?
<Noldorin> also, can i manually defien custom prefixes like lp:foo without recompiling bzr?
<mgz> Noldorin: see the suggestions from the other evening, bzr-bookmarks is probably simpler than playing symlink games
<Noldorin> mgz, how does that work though?
<mgz> that's for <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651993>
<ubot5> Debian bug 651993 in dpkg "dpkg-mergechangelogs fails if any changelog contains an invalid version" [Normal,Open]
<mgz> mgz: try it and find out, it's not something I've ever needed
<mgz> wait, that's me
<jelmer> mgz: oh perl.. joy :)
<mgz> Noldorin: ^, also send mail to the list as you do things, this stuff is under documented so your experiences are useful
<mgz> jelmer: indeed, and try not to let the mixed tabs and spaces confuse you either :)
<mgz> (I didn't really rearrange code just so I could remove some of those... honest)
<Noldorin> mgz, lol you just self-highlighted :-)
<mgz> it was an amusing line to do that on too :)
<jelmer> mgz: it looks plausible :)
<jelmer> mgz: I haven't done an in-depth review, but I'm sure buxy will
<mgz> thanks, will post and see if I get suggestions
<Noldorin> mgz, eh looks like a cool plugin. still doesn't help me provide two ssh users on my win server access to the same dir though :-(
<jelmer> Noldorin: can't they just specify the same location?
<Noldorin> jelmer, no. all paths are relative to the user home
<mgz> hm.
<mgz> okay, now the easy bit.
<Noldorin> mgz, i guess it's something weird cygwin is doing? :-P
<mgz> it seems very likely
<mgz> there probably is a neat way around your issue, nothing's coming to mind currently though.
<Noldorin> mmh...
<poolie> hi all
<jelmer> hey poolie, how was Queensland?
<mgz> hey poolie
<poolie> ah i didn't go quite that far this time
<poolie> it was good though
<poolie> how are you?
<jelmer> I'm doing alright too
<poolie> i need to miss our calls again tonight
<poolie> for the canonical sydney xmas party
<jelmer> that sounds like fun
<poolie> yeah it should be
<poolie> i think there are a few people who haven't met yet
<jelmer> poolie: how many people are there in Sydney? I can only think of a handful
<poolie> 12 are coming tonight, counting one guest
<poolie> and with a few coming up from canberra
<jelmer> ah, cool
<mgz> okay, enough of debian changelogs for the day
<mgz> I need some food.
#bzr 2011-12-14
<mgz> morning all
<vila> mgz: oh, I missed that, hey !
<mgz> hey vila!
<mgz> hm, I need to fix my builddeb test a little, looking at it again this morning
<vila> jelmer: no need for a DictStore, we already have everything we need ;) Running a full test suite before pushing my changes to lp:~bzr/bzr/commit-uses-config-stacks but there are still issues to be addressed (more in my review comment) :-/
<vila> jelmer: done
<vila> jelmer: all these minors bugs are the most painful part of the option migration :-/
<mgz> the bugs were introduced by children?
<vila> jelmer: ha crap, I didn't notice you pushed additional revisions :-/
<vila> ?
 * mgz is just teasing about a misplaced 's' :)
<vila> ha ha
<vila> :)
<vila> mgz: by the way, is http://paste.ubuntu.com/769900/ clearer ?
<vila> mgz: i.e. the added comma
<jelmer> :)
<mgz> ...I still can't parse that I'm afraid
<mgz> you need to just flip the clauses
<mgz> "The ``SectionMatcher`` objects are for defining which." for eg.
<vila> mgz: thanks, fixed
<mgz> okay, nearly caught up with life.
<mgz> just need to write news and land things...
<vila> mgz: yeah for news ! :) If you had a look at what's new for 2.5 too that would also be truly great :-p
<vila> mgz: found that bug back: #659763
<vila> bug #659763 you helpful bot
<ubot5> Launchpad bug 659763 in bzr (Ubuntu Natty) "bzr smart server can't handle UTF-8 user names, gives UnknownErrorFromSmartServer" [High,Fix released] https://launchpad.net/bugs/659763
<sidnei> hi there! how does one change an existing branch hosted in launchpad to set append_revisions_only?
<sidnei> is it enough to change .bzr/branch/branch.conf and push?
<mgz> vila: hey, another path for doing a similar thing, what fun
<mgz> sidnei: with recent enough bzr versions you can do `bzr config append_revisions_only=True -d lp:...`
<sidnei> thanks mgz!
<mgz> I wonder whether this diff/merge is bad because the file contains conflict markers for test examples...
<jelmer> vila, mgz: Could I persuade either of you to take a look at https://code.launchpad.net/~jelmer/bzr/hpss-no-vfs/+merge/85153 ? It's one of the prerequisites for hpss-get-inventories
<vila> on it
<vila> jelmer: done
<jelmer> vila: merci bien :)
<vila> hehe
<vila> lunch time for me
<mgz> bzr info is too slow.
<jelmer> mgz: -v you mean?
<mgz> just plain, it takes as long as st on hot cache and shouldn't need to do as much work
<mgz> -v is just silly.
<mgz> takes 6 seconds herre.
<mgz> 400ms was what I was talking about with "too slow"
<mgz> it's long enough that there's a noticable pause
<jelmer> it looks at the full branch history to see what the revid of the first revision is, so it can figure out its date
<mgz> yup, at least the other output comes out before it goes off and does that.
<jelmer> hmm, is there a particular reason we always open a branch for a working tree?
<jelmer> it seems like some operations should be able to get away with not opening the branch (especially if it is remote)
<mgz> probably similar to reasons we reopen repos and branches way too much
 * jelmer lunches too
<jelmer> vila: have you decided what you want to do with lp:~jelmer/bzr-upload/fix-2.4-compat yet?
<jelmer> It's fine with me if you reject it, but it would be nice to see it disappear of my activereviews queue :)
 * jelmer stumbles onto mumble
<mgz> ha, well spotted on bug 317778 jelmer
<ubot5> Launchpad bug 317778 in Bazaar "Switching to a local sibling with non-ascii name causes error" [Low,Fix released] https://launchpad.net/bugs/317778
 * jelmer was browsing switch bugs anyway... :)
<jelmer> *crickets*
<mgz> I think I borked by audio setup someone
<mgz> oh, nope, just being an idiot
<vila> jelmer: what I don't get is why you uploaded a new version when none has been released >-/
<jelmer> vila: I had to earlier, because bzr-upload was broken with bzr 2.5
<vila> that's fine, 2.5 is still beta, but then, why trying to ensure compat with 2.4 ?
<jelmer> vila: I'd rather not maintain two copies of bzr-upload in debian
<vila> meh, the point of splitting into series is to have *less* maintenance to do indeed, can't they be used in debian ?
<jelmer> vila: it means I have to do twice as many uploads to debian
<jelmer> vila: anyway, the current situation is fine for me, let's just reject the MP
<vila> ok, but be aware that I intend to track 2.5 far more than 2.4 so the series will diverge
<jelmer> sure
<jelmer> 2.4 will stop being relevant in Debian too at some point
<vila> right
<vila> jelmer: by the way, did you start to CC me when replying to reviews ? I got duplicate mails in the last days...
<jelmer> vila: https://code.launchpad.net/~jelmer/bzr/hpss-_get-checkout-format/+merge/85652
<vila> ha no, not this thime
<jelmer> s/vila/mgz/
<jelmer> vila: sometimes I have to resend email if I forget to use GPG/MIME
<vila> jelmer: sry, misread your re-submission, I *got* 3 copies last time you CC'ed me,
<jelmer> vila: as launchpad seems to refuse GPG signatures from thunderbird that don't use GPG/MIME
<vila> the (small but annoying) issue is that some of them are filtered in the wrong mailbox
<mgz> lunch lunch
<vila> meh, can't '+reply' on comments from previous versions of a proposal o_O
<vila> jelmer: you really think BZR_EMAIL is used for cases where it is *also* defined in bazaar.conf and/or branch.conf ?
<jelmer> vila: yes
 * vila shudders
<jelmer> launchpad uses it in its test suite for example, but I also imagine things like cron scripts rely on it
<jelmer> -Oemail=.. seems like a reasonable alternative, but IFF we want to change the behaviour I think we should deprecate BZR_EMAIL first and start warning existing users
<vila> yeah, but -Oemail may not work for crontab or scripts since it needs to be passed to bzr itself
<jelmer> vila: right
<vila> email_from_store may do the trick (ugly but doesn't require another confusing parameter to Option), let's try
<jelmer> vila: are you looking into implementing that or should I?
<vila> jelmer: ok, that fixes the issue with BZR_EMAIL, now looking into post_commit deprecation warnings
<jelmer> vila: I already added one to the definition of post_commit in BranchConfig
<vila> yeah, but the test suite is complaining now :)
<jelmer> vila: ah, ok
<jelmer> vila: if you need me to do a review, you know where to find me >-)(
<vila> hehe
<vila> BZR_EMAIL=me@example.com ./bzr config -Oemail=you@xxx.com  email
<vila> gives the expected result :)
<jelmer> \o/
<vila> well, for some compat-nutty value of expected
 * jelmer is compat-nutty and proud of it :P
<vila> jelmer: hehe, about compat, tried the loom test suite recently ?
 * vila dodges
<vila> jelmer: oh, forgot to reply: yes, post_commit predates our hook system (by far)
<vila> jelmer: dunno if it's casher but I approved your part of the common branch ;)
<mgz> lambed up.
<mgz> vila: on the config branch, BZR_EDITOR has a similar issue
<vila> of overriding any option setting ?
<mgz> order is currently BZR_EDITOR, get('editor'), EDITOR, VISUAL... other fallbacks
<vila> same era probably
<jelmer> vila: makes sense to deprecate it then, IMO
<vila> jelmer: BZR_EDITOR ? BZR_EMAIL ? both ?
<vila> I would rather deprecate all of them in one go if only for users to handle them all at once
<vila> no ?
<jelmer> vila: post_commit
<jelmer> vila: I think we should keep BZR_EMAIL and BZR_EDITOR
<vila> jelmer: ha, but, yes, we agree that post_commit should be deprecated, you did it (I just fixed the test fallouts)
<vila> ha, sorry, mixed conversations, you were replying to my late reply here,
<vila> so, yes, post_commit is old, has been replaced by a better mechanism, never formally deprecated
<vila> the later is now done
<jelmer> great
<vila> officiously deprecated since 0.15 if you look at the comment I left
<vila> s/left/updated/
<jelmer> vila: thanks!
<jelmer> I'll approve your work then, and land :)
<vila> hehe
 * jelmer adds vila to the NEWS entry as well
<vila> jelmer: brain dumped my thoughts on your feature-flags proposal, about to leave for an appointment, should be back later
<vila> jelmer: oh, thanks for your review on config-explained, just one question:
<vila> I addd 'for modifcation' because I thought the parameters was a bit lost and obscure, would 'Where modifcations go' be clearer ?
<vila> or may be you know already too much about stacks to need these comments ;)
<vila> hmm, yeah, I added the comment first and the docstring later, now that I re-read the two, the comment is redundant
<mgz> vila: before you notice independently, yes, I added release notes in the wrong section ;_;
<vila> hehe ! Progress !
<jelmer> vila: thanks!
<mgz> ...and the reaper kills mumble
<jelmer> hmm
<jelmer> dark-cloaked bastard.
<vila> hmm, what a language, missing context I assume I wasn't the target ;)
<jelmer> vila: unless you're the person going around killing random processes on mgz's laptop when it runs OOM, no. :-)
<vila> oops, busted :)
<lamalex> is it possible to fetch just a directory of a bzr branch?
<lamalex> so say I want just the debian dir of lp:~ubuntu-desktop/libindicator/ubuntu
<maxb> lamalex: No, the data structures / protocols used just don't work that way
<Noldorin> hey poolie
<poolie> hi Noldorin, all
#bzr 2011-12-15
<Noldorin> poolie, hey.
<Noldorin> how's progress on bzr 2.5? :-)
<Noldorin> generally
<nixmaniack> how can I continue an interrupted cloning of bzr repo? I started with bzr branch lp:calibre but interrupted in between
<Noldorin> nixmaniack, interrupted how exactly?
<Noldorin> ctrl+c?
<Noldorin> process kill?
<nixmaniack> Noldorin, ctrl+c
<nixmaniack> i want to resume the process from where it stopped
<Noldorin> nixmaniack, yeah, i think that would just fuck it during a branch
<Noldorin> you can try bzr break-lock followed by bzr pull
<Noldorin> that *might* work
<Noldorin> or bzr update even for the 2nd command
<spiv> Unfortunately you can't resume an interrupted pull
<nixmaniack> bzr update didn't work, it gives me error
<Noldorin> spiv, a branch is like an init followed by a pull no?
<spiv> Noldorin: yeah
<nixmaniack> bzr: ERROR: No WorkingTree exists for "file:///home ....
<Noldorin> nixmaniack, yeah, so just wipe the directory and start again i say
<Noldorin> don't think there's a better solution sorry
<Noldorin> spiv, why the separate command then? just convenience/semantics, or does it actually do something cleverer? :-)
<nixmaniack> Noldorin, i would have to download so much data again! that's why i was trying for other solution
<Noldorin> nixmaniack, yeah, it sucks. you can't exactly blame bzr though. you pressed the keys ;-)
<Noldorin> unlucky, as i said
<spiv> (bzr can't commit an incomplete stream, because it almost certainly has references to records that didn't get received yet.  There's a bug about improving this situation, but it's tricky to do well and right.)
<spiv> nixmaniack: if you need incremental fetches, the easiest hack is to do e.g. "bzr branch -r100 lp:foo; cd foo; bzr pull -r200; bzr pull -r300; ..."
<spiv> (or in increments of 1000, or whatever)
<spiv> Noldorin: a bit of both
<spiv> Noldorin: but mainly convenience.
<nixmaniack> Noldorin, actually this should be handled in some way (i think). what if a persons connection gets inturrupted after 90% cloning (and suppose the repo is quite big)
<spiv> nixmaniack: yes, we agree
<spiv> nixmaniack: read and/or subscribe to the bug talking about it :)
<Noldorin> nixmaniack, oh sure, it's a pain. but it's not *that* important to most people
<Noldorin> i've done it before...
<Noldorin> and i'm angry until i realise it was me being silly
<Noldorin> server could go down though
<Noldorin> so in that case :-)
<spiv> nixmaniack: also, in many cases the better fix would be to not require the user fetch so much data :)
<spiv> nixmaniack: e.g. the shallow branching proposal
<Noldorin> what's that?
<Noldorin> shallow branching
<mamalala> hello! can anybody give me some help regarding getting a branch with bzr causing extreme network traffic?
<mamalala> bzr is downloading insanely high amounts of data for "small" stuff ... since i'm on umts internet, that really sucks
<nixmaniack> spiv, actually I don't understand much about VCS! I just Git (that to not very often) but the project on which i want work is on bazaar repo, and i'm stuck at cloning only!
<nixmaniack> and now being on mobile network i can't afford much traffic!
<Noldorin> mamalala, might want to define what umts is :-P
<mamalala> Noldorin: mobile internet connection, only 4.something mbits/sec
<Noldorin> ah
<Noldorin> sounds American
<Noldorin> hey that's still faster than 3G :-P
<mamalala> nah, i'm in germany actually ;)
<Noldorin> or at least the same
<Noldorin> hah
<Noldorin> okay fine
<Noldorin> not British though :-)
<mamalala> i'd like to grab the sources, doc's and libraries for kicad, and they use bazaar on launchpad
<mamalala> already got the sources, after hundreds of megabytes of bzr download traffic, for only a handfull of mbytes of actual sourcecode
<mamalala> so i'm wondering if there is a sane way to get stuff from bazaar?
<Noldorin> mamalala, that's because you grabbed the entire revision history :-P
<mamalala> right now i'm getting the doc's, and it already transferred > 100 mbytes ... and you can bet that the actual doc's aren't that big
<Noldorin> mamalala, you probably just want bzr export
<mamalala> ahh
<Noldorin> for the latest revision, only actual content
<mamalala> will try that, i'm totally new to that bazaar stuff
<mamalala> Noldorin: what would be the correct syntax for that then? what the kicad folks tell on their wiki to grab stuff is, for example: bzr branch lp:~kicad-developers/kicad/doc
<spiv> Noldorin: see the list archives, but the proposals for it are mostly along the lines of "local branch stacked on remote trunk + some amount of local caching"
<Noldorin> spiv, oh right, interesting.
<Noldorin> spiv, isn't that like a lightweigh checkout?
<spiv> Although if jelmer can finish my branch for making 'bzr branch --stacked' from a smart server faster, that would be a fair chunk of a basic version of that already.
<Noldorin> mamalala, just bzr export mylocaldir/ lp:...
<spiv> Noldorin: yes, but without the need to hit the network for every operation
<poolie> hi spiv
<spiv> Noldorin: e.g. seeing a diff of what you've changed
<Noldorin> spiv, ah interesting. so more apt for the distributed workflow then :-)
<mamalala> Noldorin: ah, thanks! i was a bit confused because that branch thingy automatically created a directory
<mamalala> stupid me ;)
<Noldorin> spiv, what's the diff between --stacked and --lightweight incidentally?
<spiv> Noldorin: and potentially if you say e.g. "bzr log -r -20.." it could not just fetch that from the network to show you the log, but also add that to the local cache so next time you do it is fast.
<spiv> Noldorin: --stacked is a branch
<spiv> Noldorin: so an independent line of development, can have its own commits etc.
<Noldorin> mamalala, you could also do bzr init, bzr clone -r 123 if you wanted the bzr metadata too.... i *think* that would only pull the latest revision? or maybe you want bzr merge. spiv can probably tell
<Noldorin> spiv, sounds cool
<spiv> Noldorin: but a bit like a shared repo: if its repo doesn't have some data bzr will automatically fetch it from the stacked-on repo instead.
<Noldorin> spiv, so lightweight checkouts are like the centralised version of stacked branches eh?
<spiv> Noldorin: (a bit like shared in that it's a mechanism for multiple things to share one resource for repo data)
<spiv> Noldorin: yes
<Noldorin> yeah
<spiv> Hey poolie
<mamalala> Noldorin: alright ... thing is, i simply want the doc's, code and lib's ... i don't care about updating the local repository in the future anyways, so any version control is useless for me here
<Noldorin> spiv, i guess you're working on shallow branching mainly for speed/efficiency reasons then?
<Noldorin> mamalala, yep yep, so export should work fine. let me know if you have luck
<mamalala> Noldorin: well, it's causing some traffic, but not telling me what it actually does ;)
<spiv> Noldorin: yes, although it's a natural way to work IMO
<mamalala> but seems there is a lot of overhead as well
<spiv> Noldorin: I usually don't care about the full history of something I want to hack on
<Noldorin> spiv, sure. just the logic is more complex/bug-prone.
<spiv> Noldorin: I mainly want my hacking to be fast, and as a secondary thing I want the full history to be available for the odd time when I want to dig into it.
<Noldorin> mamalala, sounds like you're doing somethign weird/on a really old version of bzr heh
<mamalala> only got 6 mbytes of data in the directory yet, but downloading at almost full bandwidth for a while ... which means still a lot of wasted traffic ... oh well
<spiv> Yeah.  Although we've already dealt with most of the hard logic, for stacking.
<Noldorin> mamalala, ask the devs. i think you have an edge case though. bzr has always proven efficient for me in such things
<Noldorin> spiv, currently there's no way to do local hacking on a remote branch without pulling the full history, eh?
<Noldorin> so i guess that's the crux
<spiv> mamalala: are you branching into a shared repository, or a standalone branch?
<spiv> mamalala: there's a known bug with branching into an empty shared repository
<Noldorin> also, hi again poolie. just wanted to update you that i'm planning to start hacking on that LP downloads feature soon..
<mamalala> spiv: good question ... i have no idea, i'm not involved in development there or anything ...
<mamalala> spiv: http://kicad.sourceforge.net/wiki/Downloads
<mamalala> spiv: that's the stuff i want to grab as sources (see bottom of the page)
<Noldorin> sourceforge offers bzr these days? :O
<mamalala> spiv: after way too much traffic i got the sources already, and now iÃd like to get the doc's and lib's as well ... but at the current state of affairs, i'm about to drop it ..
<mamalala> Noldorin: nah, i guess they just used sf for the wiki stuff ... there are no files or anything to download at sf for that project
<Noldorin> spiv, i mean, correct me if i'm wrong about that ^
<Noldorin> mamalala, ah fair enough. speaking of which, i was actually planning on starting work on a wiki feature for Launchpad at some point
<Noldorin> it's one feature really lacking. one of few
<mamalala> Noldorin: right now, from my pov, being able to just grab the actual source/whatever from a repository in a fast way is sorely lacking ;)
<Noldorin> mamalala, well did bzr export not succeed at least?
<mamalala> Noldorin: i cancelled it now ...
<Noldorin> mamalala, could well be the server that's (temporarily) fucked
<mamalala> Noldorin: it just sucked up all the bandwidth, and only got about 8 mbytes of data a minute ago
<mamalala> Noldorin: i had it running since you gave me the hint about export ... suring all that time only 8 mbytes of real data, while constantly using about 4mbit/s of bandwidth
<mamalala> thats just insane
<mamalala> if i had broadband dsl or something, i wouldn't really care ... but at such "slow" speeds, it makes no fun at all
<Noldorin> mamalala, as i said, fringe case most likely. never heard of that before. either the server, client, or repo is fucked :-P
<Noldorin> i know bzr to be excellent and efficient software in general
<Noldorin> seems you just have the luck now
<Noldorin> heh
<mamalala> Noldorin: i don't doubt that .. just in that case it really sucks ... but then, i also blame the kicad folks for being unable to provide a simply tarball of that stuff
<mamalala> simply -> simple
<Noldorin> mamalala, yeah, i always hate it too when i just want to grab the source but can't do it easily
<Noldorin> Launchpad lets you do it
<Noldorin> but i guess they use a custom host
<Noldorin> which increases the chance their bzr server is messed up too, perhaps
<mamalala> from what i know they use launchpad
<Noldorin> mamalala, then you can just download the latest revision
<Noldorin> point me to the LP project site
<Noldorin> and i'll tell you
<Noldorin> heh
<mamalala> hmm
<mamalala> good idea, if i would know where that project site is on launchpad
<mamalala> i only have the links on their wiki for use with bazaar
<mamalala> and that bazaar stuff seems to be on launchpad, since it uses lp:... as address
<mamalala> already tried to use bzr+ssh://<myid>@bazaar.launchpad.net/~kicad.... and that worked as well
<mamalala> but same slowness as with lp:
<fullermd> If you're logged in, lp: _is_ bzr+ssh://....
<mamalala> already created an account on launchpad for me, added my ssh key, etc...
<mamalala> fullermd: ok
<mamalala> guess i'll simply have to try again in a few days, in case something is messed up on their end ... and if nothing changes, i just give it up ...
<fullermd> At any rate, I wouldn't expect an export from remote to be too speedy.  Kinda off the beaten path.
<mamalala> fullermd: well, i really donÃt care about the speed itself, but the badwidth
<fullermd> Bandwidth is just the FFT of speed   ;>
<mamalala> fullermd: i only have a 5 gig flatrate on umts, after which it will throttle down to gprs speed
<mamalala> and that means that using up hundres of megabytes just to get a few mbytes of real data is simply a no-go for me ;(
<fullermd> It was (at least.  Maybe still is) often the case that an export or light checkout would involve more transfer than just doing a full branch.
<fullermd> But to be sure, neither tops the list when you have to count every byte that closely.
<mamalala> fullermd: well, i could live with a few megabytes excess traffic in this case ... but the traffic/usable-data ratio is just insane in this case
<fullermd> Do your fiddling on a shell server somewhere, maybe?
<Noldorin> alas, no more hacking for today
<Noldorin> night folks
<fullermd> Or at least could branch there and make yourself a tarball.
<mamalala> and i'm unable to get a real dsl line here, since there are no free lines available anymore where i live, so umts is my only option ;-/
<mamalala> fullermd: unfortunately not
<mamalala> fullermd: used to have my own server and fixed/static sdsl line in my previous location ... oh well, good old times
<fullermd> What branch is it you're trying to get?
<mamalala> fullermd: lp:~kicad-developers/kicad/doc and then lp:~kicad-lib-committers/kicad/library
<fullermd> http://bazaar.launchpad.net/~kicad-developers/kicad/doc/tarball/302 should be a tarball of the latest rev of the /doc branch.  If it works right.
<fullermd> And http://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/tarball/112 looks like the latest of library.
<mamalala> fullermd: hey, thanks! how did you derive that download link from that information?
<mamalala> fullermd: again, thanks a lot! that's very helpfull indeed
<fullermd> I went and poked at https://launchpad.net/~kicad-developers, hit the 'Code' link up top, which showed the branches (in this case, just the one)
<fullermd> Hit the branch, it shows the recent revs down the page.  Click the latest rest (302; the number, not the name beside it), and that gets you to http://bazaar.launchpad.net/~kicad-developers/kicad/doc/revision/302
<fullermd> Then there's a 'download tarball' link.
<fullermd> Then I just manually fiddled with the link to get to the other branch.
<mamalala> fullermd: oh boy, now i feel really stupid ;-D
<fullermd> Well, it's Hump Day.  Nobody's smart on hump day   ;p
<mamalala> didn't know that there were "real" webpages behind all that as well
<mamalala> hehe
<fullermd> That's all (or mostly, anyway) loggerhead.  Any branch on LP will have that interface available.
<fullermd> Or is it loggerhead?  I don't really know, I s'pose.  Still.  It's colored clicky stuff   :p
<fullermd> (and alternately, if you have a SF account, they still have shell servers, don't they?  Don't remember if they have access to the outside world though)
<mamalala> hmmm, already 85 mbytes downloaded and continuing ... doesn't look well either ...
<mamalala> ah, just finished
<fullermd> Could be a big tarball if it's got a bunch of images and such in it.
<mamalala> ok, that's definitely much less traffic than using bzr
<mamalala> fullermd: again, many thanks for helping an old stupid chap ;)
<fullermd> Hey, that's why they pay me the Big Bucks.
<mamalala> lucky you ;)
<fullermd> I think I'll put myself in for a 50% bonus just for this conversation, in fact.
<mamalala> haha
<mamalala> go for 100% ..
<fullermd> I don't want to sound greedy.  Especially right before christmas.
<mamalala> ah, great ... got the two tarballs already ... _much_ better than before
<fullermd> Anyway, I have to be helpful once in a while.  That way I can get away with the buffoonery I engage in the other 90% of the time.
<mamalala> fullermd: i'm with you on that, same here
<mamalala> maybe i should hope for a "bzr --just-grab-the-damn-tarball" option for christmas :D
<fullermd> I was thinking of going for world peace.  But then what would they put on the news?
<mamalala> i blame the broadband-effect for such things nowdays. big pipes everywhere makes people forget about caring about bandwidth
<mamalala> yea, world peace would be nice, but surely won't happen in the next few millenia
<fullermd> Well, it'll take you that long to run bzr export over your cell, right?   ;p
<mamalala> hahaha
<mamalala> actually it can get pretty fast, on good days i get about 7 mbit/sec, but on average it's around 4
<mamalala> but speed is only half the business if you have to look at traffic usage
<fullermd> Not too bad.  But man, 5 gig disappears faster than you can blink.
<mamalala> because being dropped down to gprs speed ain't no fun ... 64 kbit/sec
<mamalala> yeah
<mamalala> tell me ... when i had the sdsl line, it had a flatrate as well
<mamalala> i'm really missing that, especially the fixed ip's and stuff. it's really great to have your own server at home together with 8 ip's
<fullermd> Back when I ran ISP's, I had a block of 16 at home.
<fullermd> That was on dialup, though.  Still, it was nice.  When I left that business and got DSL, suddenly I had to learn about NAT.  That _sucked_.
<mamalala> hehe
<mamalala> well, sdsl is a bit different, at least here in germany
<mamalala> no nat or such crap involved
<mamalala> you get one ip, and tell them you need more, and then get 8
<fullermd> I've got cable with a cap.  But I don't get very near it.
<mamalala> flatrates are the most common stuff here in germany. pretty much everyone has them
<fullermd> Still.  According to my cricket graphs, I'm averageing something like 175kbps over the mid term.  That's a bit under 2 gig a day.
<fullermd> Very bursty usage to get that average, but...
<mamalala> friend of mine has cable-dsl at home, 50 mbit/sec, fixed ip, for something around 50 euros per month
<fullermd> I get about 20mbit down.  250 gig cap.
<mamalala> average dsl here is 8 or 16 mbits for around 30 euro-bucks including flatrate, but no fixed ip
<fullermd> Looks like I'm at 26 so far this month.  So I'll be around 50 total.  That would be unpleasant to try and pull off over cell...
<mamalala> ahh, 250 gig ... i would be happy if i had 20 or 30 gig included
<mamalala> 5 gigs is really borderline
<mamalala> oh well ...
<fullermd> Yeah, I'd hit that in about 3 days of my usage.
<fullermd> Maybe a little less, since that figure is just downstream.  But my upstream is a lot smaller anyway.
<mamalala> tell me... when i moved in here, found out that no lines are available, and then used umts the forst time... after one day i was down to gprs speed ;-/
<mamalala> nowdays i'm wondering what i did to use it up so quickly... probably all those downloads and stuff to get my net-based backups back to y local machine
<fullermd> Luckily, all my MUD data is compressed.
<mamalala> but then ... the average website is crap-full with flash and other useless waste, so just by surfing around the net you get a lot of wasted bandwidth
<mamalala> i really "love" those sites where these bozos use flash to implement basic navigation through the site, etc. what a load of crap
<fullermd> I especially love them, since I don't have flash.
<mamalala> hehe
<fullermd> Gives me a nice quick warning that the site is stupid and not worth bothering with.
<mamalala> true
<mamalala> well, i have flash installed, because some customers want to show me their latest-and-greatest...
<fullermd> I get that from time to time.  I tell them "Yes, that's a pretty big white box".
<mamalala> but then, somehow they all got rather quiet re: telling me about their flash stuff... might have something to do with me telling them what a load of bulldung that is
<mamalala> alright, i'm leaving now, poking around with that kicad stuff, hopefully getting me to make the transition from my current pcb software to this one
<mamalala> fullermd: again, many thanks for the help! i could send you a sixpack of nice, tasty german beer if you like :D
<fullermd> I'm sure that would be highly illegal.
<fullermd> Therefore, my address is...
<mamalala> hehe
<mamalala> fullermd: if you really want me to send you some beer, no problem ... just /query me, i'm almost 24/7 on freenode anyways (and have channel #mamalala as well)
<mamalala> ok, i'm off, good night everyone, and thanks again!
 * fullermd waves.
 * mamalala waves back
<poolie> hi fullermd
 * fullermd waves at poolie.
<fullermd> poolie: Out of curiosity, _is_ that "download a tarball" part of loggerhead proper, or something LP adds?
<poolie> it's in lh trunk
<fullermd> Shiny.
<poolie> in fact one of the remaining things to do is to add a direct link to it from the main lp ui
<wgz> happy un-morning
<vila> hey guys
<wgz> hey vila... bus soon
<vila> as in: see you in the bus ??? /me confused
<vila> :)
<wgz> as in, I need to catch it :)
<vila> wgz: http://paste.ubuntu.com/770910/ is the kind of traceback you fixed recently in builddeb ?
<mgz> morning!
<vila> mgz: http://paste.ubuntu.com/770910/ is the kind of traceback you fixed recently in builddeb ?
<vila> and re-hi by the way ;)
<mgz> vila: don't think I touched that path, as debian.changelog is in charge there and doing the right thing
<mgz> (debian policy states that changelogs are utf-8, if a package has other random bytes in there it's borked)
<vila> hmm, ok, I'll need to dig deeper then
<vila> I encounter this while running mass_import locally so I may need to upgrade some packages (I'm running oneiric though)
<mgz> it's a likely failure from a package with a bad changelog
<mgz> if you can pdb in there and go up, will be easy enough to find the part debian.changelog doesn't like
<vila> yeah, that's the plan, I run locally keeping all local branches for such debug purposes
 * vila facepalms, wrong order for news entry :)
<mgz> ...I need to fix my news anyway, will reorder at same time
<mgz> which bit are you looking at?
<vila> fixed, in my proposal for bug #904550
<ubot5> Launchpad bug 904550 in Bazaar "gpg signing key doesn't default to 'email' anymore" [Critical,In progress] https://launchpad.net/bugs/904550
<mgz> ...now that needs to land before I can fix my news? :)
<vila> mgz: won't be enough, you'll also need pqm patch from jelmer for 2.5-compat
<mgz> ah, or pqm won't let anything through at all?
<vila> pqm-submit will crash, see bug comments
<vila> hmm
<vila> well, bug comments are about bzr, see https://code.launchpad.net/~jelmer/bzr-pqm/bzr-2.5-compat/+merge/85775 for pqm-submit
<vila> mgz: ok, the debian changelog contains KÃ¼ster which emacs sees as iso-latin-1 in fityk_0.4.3p1-1.diff.gz
<vila> mgz: weird, that same import succeeded on jubany :-/
<mgz> vila: likely it has a different version of python-debian
<mgz> I have 0.1.18 which does not fall over in a bunch of cases newer versions do
<vila> you mean it's a regression in python-debian ?
<mgz> it's a behaviour change
<mgz> possibly bzr-builddeb needs to grow code to handle packages the that debian tools thing are broken in some way (by skipping revisions or such like)
<mgz> this is complicated by the fact the tools don't make an effort to raise sane errors
<vila> 0.1.14ubunt2 on jubany, 0.1.20ubuntu2 locally :-(
<mgz> ^s/thing/think/ obviously
<mgz> ThingPad
<vila> I don't skip the importer can afford to skip versions :-/
<vila> meh, we both  have trouble with think this morning... s/skip/think/
<vila> trying with a dirty hack: force latin_1 when UnicodeDecodeError is encountered :-{
<jml> I never thought I'd say this, but using bzrlib.tests.TestCase feels kind of primitive
<vila> jml: don't do that then :)
<jml> vila: I don't want to add another dependency to udd in this branch.
<mgz> using bzrlib.tests.TestCase means you already depend on testtools...
<vila> mgz: what do you know about the debian/changelog encodings ?
<vila> mgz: as in: what is/was allowed, what is/was used ?
<jelmer> vila: in historical revisions, pretty much anything is used
<vila> jelmer: oh  hi !
<jelmer> IIRC now the recommendation is to use utf8, but I'm not sure if that's a recommendation or mandatory
<jml> mgz: oh really?
<jelmer> 'morning vila
<mgz> <http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog>
<vila> jelmer: with recent versions of python-debian, latin_1 is used in once case and breaks import_dsc
<jelmer> vila: it uses chardet I think
<jml> handy!
<vila> huh, what's charder ?
<vila> det
<mgz> it's manditory now, but historically there wasn't any guidance and people can still accidentally do the wrong thing
<jelmer> vila: uses heuristics to determine the relevant encoding
<jml> mgz, vila:  what version of testtools is on production?
<vila> jelmer: ha, exactly what I was going to suggest, so what is chardet, a package ?
<mgz> >>> testtools.__version__
<mgz> (0, 9, 6, 'final', 0)
<vila> 0.9.6-0~bazaar1.0.IS.8.0
<vila> 0.9.6-0~bazaar1.0.IS.8.04
<jml> thanks!
<vila> damn mouse
<mgz> chardet is a bad idea, and you'd need to change debian.changelog which wouldn't really help the now
<mgz> encodings aren't the only way parsing a changelog can fail either
<vila> mgz: no, changelog can be provided with a unicode string so we can handle that
<mgz> if builddeb relies on sane package metadata, and the package metadata is borked, something has to give
<jml> I need to get on the case wrt packaging
<jml> using 0.9.6 is almost criminal neglect.
<jelmer> vila: yes, python-chardet
<vila> mgz,jelmer : the question is: what do we really need out of the changelog ?
<mgz> chardet *probably* gets utf-8 right, but adds a lot of overhead and is a heuristic
<mgz> so, can flip flop depending on content
<vila> the case at hand is an author with an latin_1 encoded name
<mgz> we're better off catching errors from places that need to parse changelogs and gracefully handling borked ones
<vila> yeah, with gracefully including: try again with a working encoding that can be as fine-grained as a line
<mgz> the case could equally be they forgot to enter their name, though some classes of errors may be better and more reliably caught by packaging tooling
<vila> mgz: right now, re-trying with latin_1 allowed me to continue up to the next call site trying to parse the changelog ;)
<vila> and note that ChangeLog() accepts an encoding parameter
<vila> and a content which can be either: a string (encoding will be used, that's where we fail), unicode (good), iterator of string or unicode
<mgz> you need to also not break older python-debian versions that had completely different handling
<jelmer> isn't python-debian supposed to handle this stuff for us though? What version of it is on jubany?
<mgz> it's an older and more reliable version on jubany :)
<vila> jelmer: a version that doesn't break, but the oneiric one I'm testing with locally breaks
<jelmer> hmm
<jelmer> I would argue we should fix python-debian instead, rather than trying to work around it
<mgz> __init__(self, file=None, max_blocks=None, allow_empty_author=False, strict=True)
<mgz> Set up the Changelog for use. file is the contects of the changelog.
<mgz> you see something different I guess vila?
<vila> file can be a string, unicode or iterator
<vila> I see an additional encoding='utf-8'
<mgz> ah, right, but not if you want it to work across versions :)
<mgz> passing unicoded containing non-ascii here will die.
<vila> I want it to work across versions,
<mgz> -s
<vila> argh
<vila> err, yes
<mgz> passing bytestrings containing non-utf8 on newer versions will die.
<vila> yes
<vila> with a UnicodeDecodeError
<mgz> ...can possibly sniff and work around, I did that in bzr-builder already
<vila> catching it and re-trying with an appropriate encoding is worth a try, if it's still fail... so be it
<vila> s//it still fails/
<vila> trying now with ç¨ç´â¼ºç¯ç¡æ´ç®ç¢ç®â¹µæ½£â½­ã·ã¤°ã¹
<vila> ghaa, the irony :)
<vila> that was http://paste.ubuntu.com/770997/ with some facetious gremlin in the loop
<mgz> no, that's bad, you can't pass unicode unconditionally
<mgz> you cann fall back to passing unicode, or trying to pass a different encoding name
<vila> can't pass an encoding name for compatibility with old versions, why can't I pass unicode ?
<mgz> because the old versions treat what you pass in as a byte string
<vila> basestring
<vila> or an iterator
<vila> at least with the lucid and oneiric versions under my eyes
<mgz> it depends how the changelog is used, for instance...
<mgz> >>> str(cb)
<mgz> Traceback (most recent call last):
<mgz>   File "<stdin>", line 1, in <module>
<mgz>   File "/usr/lib/pymodules/python2.6/debian/changelog.py", line 437, in __str__
<mgz>     cl += str(block)
<mgz> UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position 1332: ordinal not in range(128)
<mgz> if you need to write it back out again, it dies.
<mgz> if you just need to inspect you might be able to get away with it
<vila> hence my previous question ;) : what do we need the changelog for, from a quick read, it seems we extract some infos but I dunno what format is acceptable for that
<mgz> yeah, looking now
<mgz> most of the logic is in util
<mgz> there's also other Changelog creating function there
<vila> bah, s/max_blocks=False/max_blocks=None/ most stooped tyop ever
<mgz> all the code looks like it's doing enough hoop jumping with the values it's taking out
<mgz> okay, so I think the safest, but maybe not the best thing,
<mgz> would be to always decode from utf-8 where possible as you are
<mgz> fall back as needed,
<mgz> then re-encode to utf-8 for the older versions
<vila> err, not decode at all for older versions you mean (for that last part) ?
<vila> bah, may be too much, I don't think the parsed content is ever used to re-generate the changelog
<vila> jelmer: two things,
<vila> jelmer: thanks for your speedy reaction about gog_signing_key, I've put up a patch for review for bzr and approved your proposal for pqm
<vila> jelmer: I have a dirty patch (gee, that's my dirty day ;) for bzr log -r bzr-2.5b3..bzr-2.5b4
<vila> I almost forgot it
<mgz> vila: see 'safe'_decode at the top of bzr-builddeb
<mgz> it does basically your logic already, but expecting bytestrings back from Changelog attributes
<vila> ECONTEXT top of what ?
<mgz> util.py sorry.
<vila> yeah, was there, my bad
<vila> haha, sounds like an ad-hoc way already in use, will probably makes mgz cry though...
<mgz> yeah, but unfortunately something along the lines is required given the ad hoc nature of historical changelogs and the api change in python-debian
<vila> meh, you guys rock :)
<vila> jelmer, mgz : I can't even read my mail that you've already landed the fix ;)
<jelmer> :)
<vila> both fixes even !
<vila> and my dirty patch works !
<vila> jelmer: given http://paste.ubuntu.com/771034 where should I search to add tests ?
<jelmer> vila: hmm, another regression
<jelmer> BZR_EMAIL is only checked if there is something in the store
<jelmer> vila: tests/test_import_dsc.py I guess, but that file is scary
<vila> darn, default=None, so default_email is not triggered :-(
<vila> err, wait
<jelmer> vila: default_email doesn't look at BZR_EMAIL, only email_from_store does
<vila> but if nothing is in store, default_email should be called and them email_from_store should be called on the returned value
<vila> s/them/then/
<vila> where do you encounter that ?
<jelmer> vila: default_email raises NoWhoAmi if it doesn't find any values
<vila> test_import_dsc, ok, will look, will that be run against various python-debian ?
<jelmer> vila: I'm hitting this in the launchpad testsuite
<jelmer> vila: no, it only runs against the current python-debian
<vila> ok, will have to do
<vila> ha crap, no place to catch NoWhoami...
<vila> jelmer: any way to force a config setting instead of relying on BZR_EMAIL ?
<vila> bah, useless, won't work for people relying on BZR_EMAIL only
<vila> oh, easy
<jelmer> vila: I can fix it in Launchpad, it's a regression in general too though
<vila> default_email should check BZR_EMAIL too
<vila> yeah ^
<vila> email_for_store enforces the policy but default_email should still respect BZR_EMAIL
<vila> yeah and if EMAIL wasn't set in the bzr test suite I suspect we should have caught this earlier
<vila>     'EMAIL': 'jrandom@example.com', # set EMAIL as bzr does not guess
<jelmer> https://code.launchpad.net/~jelmer/bzr/config-store-BZR_EMAIL/+merge/85839
<vila> oh, really ?
<vila> hehe, yeah, spurious empty lines, just saw them :)
<vila> jelmer: approved, and commit message set
<jelmer> vila: thanks
 * mgz jumps in front of the queue with release notes changes
<jelmer> mgz: no you didn't :)
<vila> hehe
<jelmer> mgz: I resubmitted your post_connect transport hook btw, it works beautifully for counting the number of hpss connections.
<vila> jelmer: oh, about that, why kind of hang were you referring to in one of those proposals ?
<jelmer> vila: ask mgz :) it's one of his old branches from 2010, which used to hang, but no longer
<vila> mgz: oh, about that, why kind of hang were you referring to in one of those proposals ?
<vila> :)
<mgz> ...if I conflict now I'll cry ;_;
<vila> ...yeah, one of us should really ping some losa to get a copy of their locations.conf and fix it, AFAIK, the bzr version used there should be able to avoid most of the news conflicts
<mgz> vila: yes, that's a mp you should review (again, look at the discussion from the last one too)
<gnuoy`> vila, mgz, https://pastebin.canonical.com/57193/
<vila> . o O (I asked and all I got was more questions and more work ;)
<vila> mgz: justasec, I have a test to write to file a first proposal, then another test to write to file another proposal then I'm all yours :)
<vila> holly cow ! losas now shoot faster than I can read too !!! Thanks gnuoy` !
<vila> gnuoy`: not sure it's the right one though, there is no mention of bzr-2.x there
<mgz> vila: looks like the right one to me, has the post_commit_to going to bazaar-commits
<mgz> (helps that gnuoy is just across the table for low latency though :)
<vila> well, if it's the right one, no wonder it doesn't try to resolve the news conflicts !
<mgz> hm, is an old copy
<mgz> not clear where the modern one is though
<vila> news_merge_files = doc/en/release-notes/bzr-2.5.txt is needed
<vila> updated appropriately for each series
<vila> mgz: in the chroot ?
<vila> or outside  :) Depends where you are looking :)
<vila> the pqm host has been migrated some time (months) ago too, if it helps
<vila> eeerk, lunch time !
<mgz> vila, do you remember the rt # from when we needed to unbreak bzr-email?
<vila> 48346 ?
<vila> mgz: ^
<mgz> ta, annoyingly doesn't specify exactly what changes were made
<jml> https://code.launchpad.net/~jml/udd/binary-scan-mode/+merge/85853 up for review
<seiflotfy> hey guys i cant seem to push anything to lp
<jelmer> seiflotfy: hi
<seiflotfy> ssh_exchange_identification: Connection closed by remote host
<seiflotfy> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<jelmer> seiflotfy: somebody else just reported that as well, but also that it seemed to be a temporary glitch
<seiflotfy> i guess this is the wrong channel
<seiflotfy> ah ok
<kinkie> Hi all.. I have a strange issue on one of my bzr setups.. "bzr gcommit" will always insist on doing a local commit by default for a bzr+ssh-hosted branch. What may I check to have it default to a standard commit?
<jelmer> kinkie: It tries to use network manager to see if you are online I think
<jelmer> kinkie: do you have network manager installed but disabled?
<kinkie> Hi Jelmer, long time no see :) NetworkManager it should be installed and working, but I'm not on that machine so I can't be sure.
<kinkie> any way to trace this?
<james_w> jelmer, hi, have you seen http://paste.ubuntu.com/771186/ ?
<james_w> seems to only happen with older bzr?
<jelmer> kinkie: hey, it has been indeed. :)
<jelmer> kinkie: checking the code to see what it's doing exactly...
<jelmer> james_w: no, also looking at that..
<mgz> james_w: I get it locally as well
<james_w> it looks like we need self.wants_revision_history for this to work?
<james_w> or it's the local copies not being used?
<james_w> err, forget I ever said that last line
<mgz> I guess it's a regression from the revspec change recently jelmer did
<mgz> can probably just change builddeb to not need wants_revision_history
<jelmer> james_w: yeah, it's related to my deprecating wants_revision_history and updating bzr-builddeb to not request the full branch history
<jelmer> mgz: that's what I did, but apparently, one of the bzr things it hands off to expects the full branch history anyway
<mgz> ah, already did that, but not in a way that supports earlier bzrs
<james_w> jelmer, mgz, have any ideas better than http://paste.ubuntu.com/771206/ ?
<jelmer> james_w: we shouldn't be setting wants_revision_history to true. I'd rather look at the bzrlib version and then pass the history into RevisionInfo.from_revision_id as necessary
<james_w> ok
<mgz> james_w: for reference, <https://code.launchpad.net/~jelmer/bzr/revspec-no-full-revhistory/+merge/84189>
<jelmer> james_w: would you like me to look into providing a patch or are you working on it?
<james_w> jelmer, if you could that would be great, your obviously much more familiar with this code than I
<jelmer> kinkie: there should be a checkbox in the gcommit window (bottom-left corner) that determines whether to commit locally or not
<kinkie> yes
<kinkie> My problem is that on that one machine (it's a kubuntu 11.10) it's checked on by default.
<kinkie> but on another machine with the same kubuntu release it's working fine. Only difference between the two pc's I can think of, is that the one which is "failing" is connected over eth0, while the one that has the expected behaviour is running over wifi
<jelmer> kinkie: hmm, trying it locally I can reproduce it here as well
<jelmer> kinkie: shouldn't be a hard fix. I'll file a bug and submit a fix after I look at this bzr-builddeb issue James mentioned.
<kinkie> great, thank you very much
<kinkie> it's not a big deal, but it's annoying
<kinkie> also because there is no real command to say "flush my local queue to the local repository", I have to go through a real commit :\
<jelmer> james_w: which version of bzr are you using?
<jelmer> mgz: did you see the post_connect_transport_hook branch ?
<james_w> jelmer, 2.4.1
<vila> jelmer: just reviewed, the same issue still stands, it doesn't provide a reliable way to count smart connections
<mgz> jelmer: yes, thanks, I'm just trying out some tests on it now to see whether it does cover the same cases as the current monkey patching
<vila> mgz: it should but if you can add more tests (like, parametrized ones) that would be nice, one case I wonder about is smart http transport, is the hook called once or twice
<jelmer> vila: I care about counting the number of TCP connections, basically.
<mgz> vila: have you got your counter aggregating subunit filter?
<mgz> save me writing my own for this...
<vila> jelmer: hmm.. I wonder... If the code you're testing properly calls .clone() and pass possible_transports in the right places... you should encounter only false positives (i.e. connections that are created but not used, which in this case means there is no connection)
<vila> mgz: in tools/
<vila> mgz: subunit-sum
<vila> mgz: adding some regexp would be neat ;-p
<jelmer> vila: I mostly care about possible_transports being used where necessary
 * vila nods
<vila> jelmer: a less ambiguous hook name could do for now with proper warnings for users
<vila> then
<vila> jelmer: at worst you'll get false positives and we'll need to find a better way
<jelmer> vila: it would be nice to also address the original use case that mgz was trying to address
<jelmer> vila: is the post_connect hook actually called for smart transports? I didn't see any evidence of that.
<vila> jelmer: this original use case *is* addressed with the current proposal AFAICS
<vila> jelmer: it's called for RemoteTransport yes, that's the controversial call
<vila> jelmer: because it's called when the medium is created not after a connection is established
<vila> jelmer: of course you should stay away from bzr+http or you'll probably see twice as much connections
<jelmer> vila: it's still a transport connect though, isn't it?
<vila> no
<vila> there is no such thing as transport.connect()
<jelmer> vila: no, but there are transports that use connections
<jelmer> and what is considered a connection seems to be quite vague
<vila> hehe, indeed
<vila> and if you re-read the old comments on the proposal you'll see that I wanted feedback about whether medium could be dropped so all transports at least use the SharedConnection object in the same way
<vila> well, for the ones it applies to of course
<vila> the connection object (and its associated credentials) is specific to each kind of transport
<mgz> so, I screwed up the first run and am redoing it
<mgz> but I think I have something under smart covered at least, despite the fact it doesn't use ConnectedTransport
<mgz> it might not be completely correct, but was giving jelmer approximately correct numbers
<mgz> the issue of overcounting may well still be present.
<jelmer> I can always filter out RemoteTransport in my hook, if necessary
<mgz> okay, that's better@
<mgz> connected_transport_count: 220
<mgz> now for the other branch
<kinkie> gotta go.. see you!
<vila> mgz: overcouting because of the backing transport or because of not really connected smart transports ?
<vila> jelmer can filter if it's the former, the later may be worth investigating anyway
<vila> during tests, there is no good reason to create an unwanted transport
<mgz> the former I think, the latter I *think* I may have avoided
<mgz> connected_transport_count: 149
<mgz> so, the hook version is seeing a lot fewer
<mgz> shall dig into it and see if where the difference lies
<mgz> I suspect the current method is mostly overcounting from having things returned from get_transport that don't line up well with the underlying connections
<vila> current as in monkey-patching get_transport ?
<mgz> vila: yup
<mgz> which we know gets the same transport object multiple times in some cases
<mgz> but I've done an identity check for that in the count, so it must also get different but same-connection-backed objects
<mgz> else hook is missing real connection
<mgz> eg
<mgz> in bb.test_branch, test_branch_local_remote and test_branch_remote_remote are respectively:
<mgz> monkey: 4, 5
<mgz> hook: 3, 4
<vila> ok, the number are small enough to relate them to the objects created in the tests right ?
<om26er_> Hey everyone, when we do a 'bzr branch lp:somethings' where is the source tree placed before the completion?
<mgz> that's the plan
<vila> the test servers may use some transports too... both methods should catch them in the same way though
<vila> om26er_: nowhere
<om26er_> i am pulling a branch and seem launchpad have some problem so the download gets stuck in the middle and i have to bzr branch again but it gets stuck again :/
<vila> om26er_: known issue, the lp guys are working on it
<om26er_> oh sad for me :/
<om26er_> i hope its fixed soon
<vila> om26er_: known as in: something is going on since a couple of hours, first time I hear about a so long incident
<vila> om26er_: we all do :)
<om26er_> vila, thx :)
 * vila wonders whether the automatic reconnection may have aggravated the situation...
<vila> jelmer: sorry to bother you again about that but what is the bzr version used on codehosting right now ?
<jelmer> vila: snapshot of something early in the 2.5 cycle
<mgz> not deployed yet vila
<jelmer> vila: (and not a problem)
<mgz> and doubt there are enough beta users on client side to have an impact anyway
<jelmer> mgz: there are quite a few people running precies
<jelmer> *precise
<vila> mgz: of course it's deployed, it's part of 2.5b4
<vila> yup
<vila> it retries only once though so probably not enough to explain the pike
<mgz> as in, nothing is actively disconnecting people, but yeah
<vila> He did that on purpose ?
<jelmer> vila: ? who did?
<jelmer> and what ? :)
<vila> mgz, talking about " actively disconnecting people" and getting disconnected :-D
<vila> I wanted to ask if he get the news_merge stuff sorted out on pqm...
<vila> s/get/got/
<razam> is there a way to ignore a directory except for a subdirectory under it?  use case is a distribution's themes directory where i created my own theme under it
<jelmer> razam: You can just ignore everything in that directory and explicitly add the directory you do want to add.
<jelmer> "bzr ignore 'directory/*'"
<jelmer> "bzr add directory/thesubdirectory"
<jelmer> Noldorin: did you see bug 662448 ?
<razam> hmmm
<ubot5> Launchpad bug 662448 in Bazaar "docs should describe how to set up ssh keys" [Medium,In progress] https://launchpad.net/bugs/662448
<razam> interesting..
<razam> jelmer: thanks..
<zyga> jelmer, hi
<zyga> jelmer, fancy looking at a bzr-git bug?
<zyga> eh...
 * zyga just updated bzr-git to trunk and ... the bug is gone
<zyga> http://pastebin.ubuntu.com/771499/
<zyga> jelmer, if you are interested that's what happened ^^
<jelmer> zyga: yeah, that was recently fixed
<zyga> jelmer, thanks
<jelmer> zyga: hmm, you're using "bzr pull" into a git repository? Do you have local changes to your bzr-git branch to enable the experimental mappings?
<zyga> jelmer, I don't thinks so
<zyga> jelmer, tell me more, I want to be your beta user
<zyga> jelmer, i'm moving to git workflow with trunks in bzr (for team workflow)
<zyga> jelmer, I want to ensure I can hack in git, then publish in bzr
<Noldorin> hi jelmer
<Noldorin> jelmer, nope what is it?
<jelmer> Noldorin: bug about documentation for bzr+ssh on Windows, including a text document with notes
<jelmer> zyga: hmm, that's odd
<Noldorin> jelmer, relevant to me in what way though?
<jelmer> zyga: so, this is one of the things I would like to support in bzr-git, but it shouldn't be enabled by default
<zyga> jelmer, tell me more about that, how do I enable it
<jelmer> Noldorin: you were trying to set up a ssh server on Windows, right?
<jelmer> zyga: it seems you already have, which is what puzzles me
 * jelmer tries it locally
<zyga> hmm
<zyga> jelmer, how do I check
<Noldorin> jelmer, oh. succeeded days ago hehehe
<zyga> is it a branch format?
<Noldorin> jelmer, symlinks it doesn't like still though...but oh well
<Noldorin> that's to be expected
<jelmer> zyga: pulling and pushing from bzr into git shouldn't work yet, only "bzr dpush" (which is lossy)
<jelmer> zyga: to enable lossless push/pull you should have to change the default mapping format in bzr-git to 'experimental'
<jelmer> zyga: mapping.py, around line 443
<zyga> jelmer, I used dpush once
<zyga> jelmer, I just enabled that locally
<zyga> jelmer, let me try playing with my bzr/git trees
<zyga> jelmer, do I get this right: I can branch from bzr, push to git and pull back with all the state tracked?
<jelmer> zyga: well, that's the idea
 * zyga jumps in joy
<jelmer> zyga: I've just added a Big Fat Warning, since this is all this experimental
<zyga> I'll gladly report bugs and feedback
<jelmer> zyga: great
<zyga> hrw, ^^^^^^
<zyga> hrw, xmas came
<jelmer> zyga: btw, do you know about git-remote-bzr in bzr-git ?
<zyga> jelmer, nope
<jelmer> zyga: it basically exposes this functionality, but as a remote helper in git
<zyga> O :-)
<zyga> so I get a remote in git that works with bzr repos?
<zyga> :D
<jelmer> IOW, "git clone bzr::lp:dulwich"
<zyga> jelmer, I'm sorry I won't see you at the next linaro connect or UDS but I'll get you a big beer once we sprint together
<zyga> does it need any config on git part?
<jelmer> zyga: It's still slow as hell, since the emphasis in bzr-git has always been on importing from git into bzr, not the other way around
<jelmer> zyga: but it's gradually improving
<jelmer> zyga: :-)
<jelmer> zyga: you need to install git-remote-bzr in /usr/lib/git-core. The bzr-git Debian/Ubuntu package will do this for you
<zyga> http://paste.ubuntu.com/771537/
<zyga> ok
<zyga> I'm pretty sure I have that package, let me check
<zyga> yup, 0.6.5+bzr1465-1
<jelmer> zyga: you have a mismatching git-remote-bzr and bzr-git plugin in ~/.bazaar/plugins/git
<zyga> jelmer, I have trunk in .b/p/git
<zyga> hmm
<zyga> so what should I do
<jelmer> zyga: you'll need git-remote-bzr from lp:bzr-git as well in that case
<zyga> or -- how should I upgrade the other
<zyga> ok
<zyga> let me try
<zyga> ah, so it's in the same repo
<zyga> jelmer, can I setup.py install --user for your plugin to work
<zyga> and for git to pick up git-remote-bzr magically from my local path
 * zyga tries
<jelmer> zyga: I usually just create a symlink from ~/.bazaar/plugins/git to my checkout of lp:bzr-git
<jelmer> zyga: that means I don't have to touch setup.py at all
<zyga> that's what I have for bzr
<jelmer> zyga: I'm not sure if git looks at anything beyond /usr/lib/git-core. If you find out, please let me know :)
<zyga> but for git I need that script in my PATH
<zyga> beh, installing it did not install the script
<zyga> ok
<jelmer> zyga: right, setup.py doesn't install git-remote-bzr yet as I haven't found a good way of getting at the locations git uses
<zyga> it seems to have worked
<zyga> er... wait
<zyga> ok
<zyga> I've got this: unknown command "commit"
<zyga> and it's doing the branch it seems
<zyga> so, the good part is:
<zyga> you can add that to the scripts=[]
<zyga> and it seems to work when it's in ~/.local/bin (assuming your PATH looks there)
<zyga> jelmer, it failed :/
<zyga> http://pastebin.ubuntu.com/771550/
<jelmer> zyga: bug reports welcome, don't say I didn't warn you :-)
<jelmer> e.g. git clone bzr::lp:etckeeper works
<zyga> I see
<zyga> ok
<zyga> jelmer, ok, but that's secondary (filing bug now)
<zyga> if I can branch from bzr trunk on launchpad
<zyga> then push that to a git repo
<zyga> and pull back
<zyga> https://bugs.launchpad.net/bzr-git/+bug/904951
<ubot5> Ubuntu bug 904951 in Bazaar Git Plugin "Fails on git clone bzr::lp:lava-server" [Undecided,New]
<jelmer> zyga: thanks
<hrw> zyga: its not xmas. I do not want to use bzr to manage git repos
<hrw> but using git to manage bzr would be lovely
<hrw> jelmer: I read most of backlog now. if it works then beer from me as well
<hrw> jelmer: would it be possible to have information which git rev is which bzr rev? like git-svn does
<hrw> warning: Duplicated ref: refs/tags/1.68
<hrw> I did: git clone bzr::lp:ubuntu/armel-cross-toolchain-base (which I normally develop in git and it has bzr copy done from releases)
<jelmer> zyga, hrw: it's by no means useful for production yet
<jelmer> importing git repositories into bzr works pretty well, but the other way around still has lots of issues and hasn't been optimised
<hrw> sure
<hrw> jelmer: but if you need tester then I'm in
<jelmer> the main reason I work on it is so I can contribute to git projects with bzr, but improvements in bzr-git help for both our use cases
<jelmer> hrw: cool
<hrw> unknown command "commit"
<hrw> like zyga ;)
<hrw> jelmer: apport-bug bzr-git?
<hrw> jelmer: will you check bug 680833 too?
<ubot5> Launchpad bug 680833 in bzr-git (Ubuntu) ""git-apply" does not add new files" [Medium,Triaged] https://launchpad.net/bugs/680833
<hrw> bug 904963
<ubot5> Launchpad bug 904963 in bzr-git (Ubuntu) "unknown command "commit"" [Undecided,New] https://launchpad.net/bugs/904963
<hrw> zyga: mark it as 'affects me' so it will be confirmed?
<hrw> jelmer: 'git clone bzr::lp:ubuntu/armel-cross-toolchain-base' generates warnings about duplicated tags.
<hrw> jelmer: but 'git remote add bzr bzr::lp:ubuntu/armel-cross-toolchain-base;git remote update' does not
<hrw> will report
<hrw> but tomorrow
<hrw> have a nice rest of day
<zyga> hrw, you got it backwards
<zyga> :-)
<zyga> hrw, looks promising
<hrw> zyga: ?
<zyga> hrw, sorry, was reading backlog
<zyga> hrw, I too hope for git with bzr workflow
<Noldorin> hi poolie
<Noldorin> you around at present?
<SpamapS> Hm, so if I do BZR_DISABLE_PLUGINS='changelog_merge' bzr plugins  .. I do not see the changelog_merge plugin. But then later, if I do a merge of a packaging branch, it still uses the plugin...
<SpamapS> $ BZR_DISABLE_PLUGINS='changelog_merge' bzr merge ../fix-
<SpamapS> ask-for-passphrase
<SpamapS> dpkg-mergechangelogs: error: 2.0.37+cvs.JCW_PRE2_2037-1 is not a valid version
<jelmer> hey Noldorin
<jelmer> hi SpamapS
<SpamapS> jelmer: o/
<jelmer> SpamapS: FWIW mgz submitted a fix for bzr-builddeb for that issue, we should be uploading it to precise shortly
<jelmer> though BZR_DISABLE_PLUGINS should work..
<SpamapS> Yeah I'm a bit confused. :-P
<Noldorin> hi again jelmer
<jelmer> Noldorin: I think poolie isn't around today
<Noldorin> jelmer, remind me, how did you recommend i set up bzr+ssh on windows so that i get two different users sharing the same set of repos/directory?
<Noldorin> ah okay
<Noldorin> fair enough
<Noldorin> was going to set up LP to hack on my windows server. apparently it's difficult, but possible
<Noldorin> a local LP server that is
<jelmer> SpamapS: hmm, I can't really see how that would be the case. Are you sure you haven't made a typo or something like that?
<SpamapS> jelmer: thats kind of why I pasted the cmdline
<jelmer> SpamapS: ah, found it
<jelmer> SpamapS: changelog_merge is for Changelog-like files. the debian/changelog merger is in bzr-builddeb
<SpamapS> OH
<jelmer> SpamapS: so you want BZR_DISABLE_PLUGINS=builddeb
<SpamapS> much better
<SpamapS> usually its *awesome*
<SpamapS> but this time.. it was just #$@!ing things up :)
<jelmer> SpamapS: thanks, glad to know it's useful :-)
<jelmer> SpamapS: bug 842144
<ubot5> Launchpad bug 842144 in python-debian (Ubuntu) "bzr crashed with ValueError in _set_full_version(): Invalid version string '2.0.37+cvs.JCW_PRE2_2037-1'" [Medium,Triaged] https://launchpad.net/bugs/842144
<SpamapS> jelmer: ah fantastic
<Noldorin> jelmer, well? :-)
<jelmer> hmm, bug 842144
<jelmer> SpamapS: it's actually fixcommitted, but ubot doesn't seem to recognize that
<jelmer> Noldorin: sorry?
<Noldorin> jelmer, see my previous message(s) to you...
<Noldorin> think you may have missed them
<jelmer> Noldorin: I did see them, I'm just not sure what you're asking :)
<Noldorin> oh with what?
<Noldorin> hmm
<Noldorin> thought we talked abut this before
<Noldorin> maybe just mgz and lifeless and poolie
<Noldorin> heh
<jelmer> Noldorin: whether it's feasible to set up a Launchpad instance on Windows? I don't think that's possible without doing a lot of porting work.
<Noldorin> oh
<Noldorin> poolie suggested it was more doable than that
<Noldorin> hmm
<Noldorin> oh well
<Noldorin> what about the dir/repo shared between ssh users on bzr server? :-)
<jelmer> Noldorin: I don't think anybody has ever done that.. (Launchpad on Windows)
<Noldorin> ah
<Noldorin> hmm
<jelmer> Noldorin: Are you sure he wasn't talking about loggerhead?
<Noldorin> Ubuntu is standard i guess?
<jelmer> Noldorin: right, but I don't think a lot of people actually run their own launchpad instance
<Noldorin> yeah true heh
<jelmer> Noldorin: either way, #launchpad is probably more appropriate for that discussion :)
<Noldorin> i was going to do some hacking
<Noldorin> oops, yes
<Noldorin> sorry
<Noldorin> i merge the two channels in my mind sometimes
<Noldorin> many of the same people ;-)
<Noldorin> all Canonical
<Noldorin> brb
<coventry> What is the bzr equivalent of gitk?  I have found references to bzrk, which seems to have been subsumed by bzr-gtk, but I haven't found a clear description of how to invoke it.
<spiv> bzr viz
<coventry> Terrific, thank you.
<spiv> Or 'bzr qlog' if you have the qbzr plugin
<spiv> (Which is probably a bit more polished than bzr-gtk atm)
<spiv> (Also, I'm pretty sure the invocation has been 'bzr viz' since almost the very beginning of that code!)
<coventry> Probably I was confused because I was expecting a standalone program like gitk.  Thanks again.
#bzr 2011-12-16
<poolie> hi spiv, all
 * thumper looks for bzr guru
<thumper> who is awake
<jelmer> ok, I admit it.
<jelmer> I'm still awake
<thumper> hi jelmer :)
<jelmer> what's up thumper ? :-)
<thumper> I have an interesting process problem
<thumper> lets say I'm doing a bug fix
<thumper> based off trunk
<thumper> and after some investigation I have a small patch
<thumper> now, that patch is identified as being simple enough for an SRU
<thumper> so I'd like to make my branch now based of the SRU branch
<thumper> but I want my changes kept
<thumper> any ideas?
<jelmer> thumper: so you'd like to cherry pick your fix into an older release series?
<thumper> or just rebase the branch
<jelmer> or do you want to create a patch to go into the debian/patches directory of your SRU package?
<thumper> I suppose you could shelve, then pull override?
<thumper> we have a series branch for the SRU work
<jelmer> thumper: Are you doing any commits in the mean time?
<thumper> maybe...
<thumper> I'm trying to nut out a simple process
<jelmer> thumper: if not, I would just do "bzr merge -d sru --uncommitted trunk"
<thumper> for working on SRUable bug fixes
<thumper> jelmer: so making a new branch?
<jelmer> thumper: otherwise just "bzr merge -r-3..-1 trunk" if you want to cherrypick the last three commits - though that doesn't preserve the commit history
<jelmer> thumper: I would definitely make a new branch for the SRU work
<thumper> I'm not interested in the commit history for this case
<thumper> ok, too hard to rebase the existing?
<jelmer> thumper: rebasing works too, but the problem with rebasing is that you're applying all commits individually
<thumper> how does merge --uncommitted work when the other branch is based off a much older revision?
<jelmer> so if each one fails to apply, you have to resolve conflicts in each one.
<thumper> but it gives you the conflict markers et al?
<jelmer> thumper: yeah, --uncommitted should work in that case
<thumper> ok, cool
<thumper> thanks
<jelmer> thumper: you do get the conflicts, but you have to resolve them and run "bzr rebase-continue" for each commit that conflicts
<jelmer> thumper: if you have 2 commits that's probably not an issue
<jelmer> thumper: if you're backporting 40 commits it becomes more annoying :)
<thumper> jelmer: I'd probably rather avoid rebase...
<jelmer> (presuming most of them conflict, of course)
<jelmer> thumper: in that case using "bzr merge -rFROM..TO ../trunk" to cherrypick existing revisions, or "bzr merge --uncommitted" indeed seem like the best choices
<thumper> jelmer: thanks for that
<thumper> jelmer: -3..-1 only takes two commits right?
<thumper> the last and second last?
<jelmer> thumper: yes
<jelmer> thumper: "bzr help merge" also has a pretty good description
<thumper> kk, ta
<kinkie> Hi all
<vila> kinkie: hi
<vila> hi all !
<fullermd> Oh, vila's up.  Must be bedtime.
<vila> fullermd: huh ? Are you ill ?
<vila> :-p
<fullermd> Mentally or physically?  :p
<vila> Well, we're talking about some recent change so I guess it means the later :)
<vila> jelmer: ping, workflow question, I've landed the fix for bug #904704, should I: 1) mark the bug fix committed, 2) target 2.8, or both or something else ?
<ubot5> Launchpad bug 904704 in bzr-builddeb "non utf-8 encoded changelogs cannot be parsed with recent python-debian" [High,In progress] https://launchpad.net/bugs/904704
<ChrisCauser> Hi everyone. I've just got a regression in a script I have written when using bzr 2.5 and was wondering if anyone can help me out?
<vila> ChrisCauser: show us your script and we'll see what happens ;)
<ChrisCauser> vila: Thanks http://paste.ubuntu.com/771983/
<vila> ChrisCauser: but basically, yes, this a good place to ask
<ChrisCauser> I'm afraid I'm going to be horrifically vague because bzr 2.5 is on my home computer and I'm at work
<ChrisCauser> Basically, this is a bash prompt for bzr
<ChrisCauser> in 2.3 and 2.4, it works as you'd think
<ChrisCauser> in 2.5, I get [:] output, because I get a  NotABranchError being caught in line 51
<ChrisCauser> I get the same error if I use open_containing in line 39
<vila> k, was about to suggest that,
<ChrisCauser> The only oddness I can remember is that if I say open '/home/causer/working_copy', the error says that it cannot find a branch in '/home/causer/working_copy/'
<vila> which you disagree with because bzr can find a branch there otherwise right ?
<ChrisCauser> Also, if the cwd is '/home/causer/working_copy/sub_directory', the error says the url is '/home/causer/working_copy/' again (i.e. it sort of knows that it is a branch)
<ChrisCauser> yes, exactly
<vila> right, it finds a .bzr/branch dir
<vila> what kind of branch is that ? What does 'bzr info -v' says ?
<ChrisCauser> Hang on a second. I'll just install 2.5 on my work computer
<vila> line 40 is useless isn't it ?
<vila> hmm, using branch.nick *after* unlock is... blurry
<ChrisCauser> This script is full of historical artefacts. You are correct about line 40
<mthaddon> vila: howdy, have a python-testtools question for you
<mthaddon> vila: we have 0.9.6-0~bazaar1.0.IS.8.04 of python-testtools installed, but there's a 0.9.8-1~bazaar1-0.IS.10.04 lurking in lucid-cat-proposed - do you know if it's safe to promote that package so it gets installed on the servers?
<vila> mthaddon: hello !
<ChrisCauser> vila: http://paste.ubuntu.com/771990/
<vila> mthaddon: according to jml who is testtools ubermaster, quoting "using 0.9.6 is close to criminal",
<ChrisCauser> vila: This is the error I get http://paste.ubuntu.com/771991/
<mthaddon> vila: ok, cool - the reason I'm asking is because he has asked for 0.9.8 and I'm wondering if we can use it across the board - so that sounds like a yes - thx
<vila> mthaddon: so using 0.9.8 should be ok, but I defer to jml and mgz who knows the compatibility better than me
<vila> mthaddon: as far as bzr itself is concerned, yes
<mthaddon> thx
<jml> vila: the NEWS file has got all known compat issues. I'm pretty sure we're OK though
 * jml means to submit the latest release to Debian & backport 0.9.12 to lucid if possible
<vila> jml: thanks, my confidence was ~90%, going up to 99% if you say so
<vila> ChrisCauser: looking,
<vila> first things that comes to mind so far but not guaranteed to fix your issue: you want a try:finally to unlock when you're really done instead of ad-hoc, you want to make sure you properly initialize bzrlib
<vila> ChrisCauser: your script works for me
<jml> vila: double check the Changes section of 0.9.8 to be extra sure
<ChrisCauser> vila: What version of bzr are you using? I'm using the daily ppa
<vila> ChrisCauser: I've been running from source since... can't remember
<vila> revno 6376 right now
<vila> jml: loooking
<vila> mthaddon: Hold on !
<mthaddon> holding
<vila> mthaddon: there is a pending bug regarding upgrading pqm
<mthaddon> vila: you're saying we can't upgrade to 0.9.8 just yet on bzr's pqm instance?
<vila> mgzctl alarm ring
<vila> mthaddon: searching the bug, from memory, compat issue for older bzr series
<ChrisCauser> vila: Hmm. I'm on 6349. Python is 2.6. Well, I'll take a look myself and if I find anything, I'll let you know. Thanks for the help anyway
<vila> bug #839461
<ubot5> Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [High,Confirmed] https://launchpad.net/bugs/839461
<mthaddon> vila: but we're already on 0.9.6 on pqm, so it seems like we'd already be in trouble there
<vila> mthaddon: ok, so, basically, mgz will knows better than me or at least it will be easier for me to discuss with him
<vila> ouch
<vila> mthaddon: bumper to critical, I'll get in touch with you once mgz is up and running ;)(
<mthaddon> k, thx
<vila> ChrisCauser: gimme as sec
<ChrisCauser> vila: Thanks
<vila> ChrisCauser: what's your mininum python version requirement ?
<vila> mum, sry :)
<ChrisCauser> vila: For the script? I guess it's the minimum for bzr which is 2.6
<vila> lol, what an idiot, you're right of course :)
<ChrisCauser> :)
<vila> ChrisCauser: http://paste.ubuntu.com/772000/ is how I would spell it these days
<vila> ChrisCauser: does this make a difference ?
<ChrisCauser> vila: No, unfortunately. I'm looking at the source, and it seems like no _probers are being registered in the ControlDirFormat class. I'm trying to find out what a prober is now :S
<vila> a prober decides which format should be used based on whatever it feels appropriate: which files are there, what do they content, what kind of server, etc
<vila> not having probers means nothing can be used
<ChrisCauser> Ah, Ok. Well, apparently I have no probers, and ControlDirFormat.register_format is not being fired
<vila> hmm,add a 'print bzrlib.__file__' after import bzrlib to double-check which version you're using
<ChrisCauser> vila: Looks good: /usr/lib/pymodules/python2.6/bzrlib/__init__.pyc
<vila> and 'bzr version' tells you the same story or a different path ?
<vila> ChrisCauser: Also, try with BZR_PLUGIN_PATH=-site
<ChrisCauser> vila: Yes, it's the same. I have now got it working. I have to "import bzrlib.bzrdir" explicitly in the script
<vila> O_o
<vila> ChrisCauser: file a bug please
<vila> and what if you set BZR_PLUGIN_PATH ?
<vila> ChrisCauser: and anything interesting in .bzr.log ?
<ChrisCauser> .bzr.log looks pretty uninteresting
<ChrisCauser> BZR_PLUGIN_PATH makes no difference
<vila> hehe, well done vila, spot on !
<vila> at least we know the issue doesn't come from a plugin ;)
<vila> ChrisCauser: I'm out of ideas for now, but I not used to write scripts using bzrlib, try again later, jelmer and mgz may know better
<vila> ChrisCauser: if nothing else, 'with bzrlib.intialize()' should be enough, if it's not, t's a bug
<vila> 'I not used'... "I'm not used" and I need more coffee :)
<ChrisCauser> vila: Thanks a lot for all your help. I'm pretty sure the problem is that the prober being registered in bzrlib.bzrdir.__line__ == 1143 should be registered on initialize().
<ChrisCauser> Perhaps it was a speed consideration that it was left out
<ChrisCauser> Anyway, many thanks for all the hard sleuthing. I'll file a bug report
<vila> 1143 does not match, what's the line content /
<vila> ?
<vila> controldir.ControlDirFormat.register_prober(BzrProber) ????
<wgz> failing to get network operational this morning...
<wgz> vila: are we going to do another release off 2.2?
<vila> https://launchpad.net/bzr/+milestones says 2012-02-09 but is subject to change depending on bugs fixed
<ChrisCauser> vila: Yes, that's the one. I've filed a bug report
<ChrisCauser> https://bugs.launchpad.net/bzr/+bug/905218
<ubot5> Ubuntu bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Undecided,New]
<ChrisCauser> I hope it is detailed enough
<vila> wgz: so, a new 2.2 is pretty unlikely but I'd rather not discover a compat issue when trying to do a release to fix a critical issue...
<vila> wgz: my turn now :)
<vila> wgz: did you get some results for news_merge on pqm ?
<wgz> the only obvious locations.conf seemed to last modified 3 years ago
<wgz> while we have mthaddon it would be good to ask him if that's the current one or if the real thing is elsewhere
<vila> good point
<vila> let's talk about testools first then
<vila> what are the options ?
<wgz> well, I'm not too worried about upgrading it, various small things have broken and then been fixed across versions
<vila> is 2.2 compatible with  0.9.8-1~bazaar1-0.IS.10.04 (available according to mthaddon) or should we instead check for 0.9.12 and wait for jml to provide it for lucid ?
<vila> or separate pqm from the other ?
<wgz> if it turns out something fails with the new version, we just need to land whatever bzrlib change is required
<wgz> but 0.9.8 should be fine for 2.2
<wgz> whereas newer versions would require some test output fix backporting
<vila> can you double-check that and update bug #839461 ?
<ubot5> Launchpad bug 839461 in Bazaar "can't run selftest for 2.2 with recent subunit/testtools" [Critical,Confirmed] https://launchpad.net/bugs/839461
<wgz> sure
<vila> I just bumped it to critical waiting for a more precise diagnosis
<wgz> heh, I don't have a 2.2 tree here
<wgz> I think I deleted it as no longer relevent
 * wgz branches
<vila> mwhahah, you want to make our compat overlord cry ?
<wgz> well, I *run* a pre-2.2 version as my base bzr on this box
<wgz> okay, with trunk testtools, get three:
<wgz> AttributeError: 'module' object has no attribute 'ExtendedTestResult'
<wgz> will roll back to 0.9.8
<wgz> there's a change I fixed that in I could backport to 2.2
 * vila nods and notes that 0.9.12 seems possible (this will have my preference)
<wgz> no s- bt.test_selftest errors with 0.9.8
<wgz> I'll do a more extensive subset and see if there's anything else, but I expect it to be okay
<wgz> okay, two doctest isolation problems that weren't backported...
<wgz> dammit! was a laptop hardware bug
<wgz> can probably transfer to the right box now
<vila> wgz: "laptop hardware bug" ? Related to testtools ?
<mgz> yeay! and it's still morning
<mgz> no, related to me not being able to get on the network this morning
<mgz> enabling then disabling the wireless made the wired hardware start responding
<mgz> will have to remember that for next time.
<mgz> so I don't spend quite as long checking the cabling...
<wgz> http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8
<wgz> all known issues, nothing testtools related
<vila> so 0.9.8 is a valid alternative for bzr-2.2 ?
<wgz> yup.
<vila> jml, mthaddon : ^
<vila> jml: is that ok with you or do you need 0.9.12 somewhere (in which case, when ? ;)
<mthaddon> vila: that's great, thx
<mthaddon> vila: we'll go with 0.9.8 for now
<vila> wgz: I never know how to interpret (grok?) these pages
<wgz> click on the little coloured boxes
 * vila nods
<vila> but how can I conclude: nothing wrong here
<wgz> what I did was:
<vila> for the whole page without clicking on all red (only ?)
<wgz> 1) see there was no big red bar for any of the rows
<wgz> that would indicate a test module failed to import
<wgz> then I clicked on the little red and orange boxes, and saw they were all failures I know about already, mostly related to the selftest environment being slightly different
<vila> ha, ok
<wgz> ideally, you'd just look at the whole page and go "no red or orange!"
<wgz> but the testsuite isn't quite that solid
<vila> yeah, now I understand that I can't get that without practice ;)
<wgz> eg:
<wgz> http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#bb.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home
<wgz> this is a problem with the test, and the design of trace
<vila> hehe, I almost mentioned just that one :)
<wgz> the test wants to escape isolation and get real `bzr version` output
<vila> http://float.endofinternet.org/xmlbin/2.2_testtools_0.9.8#%28doctest%29bzrlib
<wgz> and fails if trace.enable_default_logging() hasn't been called
<wgz> ^that's an old doctest error that's fixed on trunk, basically it's spelt wrong and happened to work in some cases, again because of bad isolation
<vila> oh, ChrisCauser encountered an issue in a script even after calling bzrlib.initialize() bug #905218
<ubot5> Launchpad bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Undecided,New] https://launchpad.net/bugs/905218
<wgz> right, we have a bunch of issues that selftest doesn't catch by default because it generally runs in a fully set up environment
<wgz> the import tariff type tests are a way around that
<vila> a job for a subprocess test
<wgz> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5494 <- fix for that bzrlib doctest issue
<vila> and you're still based on 2.2 because this runs with ?
 * vila tries to refresh his memory ;)
<wgz> ...without testtools :)
<vila> :-D
<vila> . o O (This guy is schizophrenic, not only does he needs 2 nicks, he also manages to contribute (significantly) to a tool he doesn't use ;)
<wgz> ha, okay, with trunk the only new errors are in <http://zippedmartin.dyndns.org/xmlbin/newtestresult#bt.test_selftest>
<hrw> jelmer: like promised: bug 905275 reported
<ubot5> Launchpad bug 905275 in bzr-git (Ubuntu) "git clone bzr::lp:armel-cross-toolchain-base creates duplicated tags" [Undecided,New] https://launchpad.net/bugs/905275
<wgz> the bad part is the fix for that is from my testcase collection branch, so there's no direct backport possible
<vila> wgz: gut feeling == skip those tests for 2.2 and be done
<vila> wgz: if this is enough to allow us to use 0.9.12, the risk is negligible
<wgz> though... I do have one neat rev for it: <http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5340.12.7>
<vila> wgz: would be clearer with from bzrlib.testools.testresult import doubles
<vila> wgz: but small enough as it is for SRUs
<vila> err, but good enough as it is, being small, for SRUs
<vila> wgz: could you update the bug with a summary/bug task creation whatever you feel appropriate :)
<vila> wgz: and thanks a lot, that's far clearer now, death to FUD ! :)
<wgz> will just test 2.3/2.4 as well while here
<niemeyer> Hey all
<niemeyer> Quick question:
<niemeyer> Once one "bzr update -r N", how to tell which revision the current working tree currently represents?
<niemeyer> "bzr revno" still shows the tip
<wgz> `bzr revno --tree`
<vila> jelmer: toying around with your feature-flags branch, ./bzr selftest -s bt.test_bzrdir hangs in bzrlib.tests.test_bzrdir.TestHTTPRedirections_pycurl.test_loop tracked down to bzr-svn
<vila> jelmer: I'll switch to BZR_PLUGIN_PATH-site
<vila> jelmer: I'll switch to BZR_PLUGIN_PATH=-site
<jml> vila: 0.9.8 is a valid alternative. 0.9.12 is at the mercy of a willing volunteer to package
<jml> vila: which might end up being me, but others are welcome to go ahead.
<vila> jml: thanks for confirming
<wgz> bah, initialize is still a mess
<wgz> pass setup_ui=False and you get a traceback
<wgz> what's needed to get the old (quiet) behaviour bad again: <http://paste.ubuntu.com/772153/>
<vila> wgz: the more I think about library state, the more I believe it should provides a sensible default behavior when importing bzrlib and *then* allows calls to initialize() to override whatever you want
<wgz> yeah.
<vila> tests and bzr commands would then be executed into a with bzrlib.initialize() block setting the needed bits and restoring the previous state when leaving the block
<vila> should scale for threads too
<vila> this should also limit the places where you need to pass the state around to: commands, tree, branch and repo signgificant calls without requiring passing it across the whole API
<vila> meh and tests of course
<wgz> see r6210 as well
<vila> hehe, yeah, I know this one :)
<vila> I don't like the global_state=None approach hence my "provides a sensible default behavior when importing bzrlib"
<vila> in other words, let's initialize *something* cleanly and *then* give ways to tweak
<adiroiban> Hi. I am getting this error: 	
<adiroiban> bzrlib.errors.IllegalUseOfScopeReplacer: ScopeReplacer object 'StringIO' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory
<adiroiban> second time I call branch = bzrlib.branch.Branch.open_containing(self.url)[0]
<adiroiban> any idea what is wrong?
<wgz> we need more context to know what's going wrong, it's a symptom of lazy import misuse
<wgz> so, full traceback, and ideally the module with your code as well?
<adiroiban> I am trying to fix the buildbot, bzrpoller
<wgz> ah... it's an error in trace
<wgz> from bzrlib.lazy_import import lazy_import
<wgz> lazy_import(globals(), """
<wgz> from cStringIO import StringIO
<wgz> ...
<adiroiban> http://pastebin.ubuntu.com/772280/
<adiroiban> call is at line 287
<wgz> you can probably avoid it by doing `with bzrlib.initialize(): your_main()` in your script
<adiroiban> aha
<adiroiban> so the bzrlib.initialize() should be called only once?
<wgz> file a bug against bzr, because the bad code is in bzrlib.trace
<adiroiban> ok. I will file a bug. thanks!
<wgz> and yes, the fix is probably just to make init happen once at the right time
<wgz> include the full traceback in the bug, and say what you run to hit it
<adiroiban> any suggestion for the title?
<adiroiban> or just put any title that will be updated
<adiroiban> if required
<wgz> "IllegalUseOfScopeReplacer from replacement of StringIO" or something
<adiroiban> ok
<lamalex> Hi, is there any way to get bzr-builder to use pbuilder to build its package?
<jelmer> lamalex: at the moment, no
<jelmer> lamalex: though you should be able to use --no-build and then use pbuilder manually
<adiroiban> wgz: I tried wrapping the call to bzrlib.branch.Branch.open_containing in a with: bzr.initialize() block, and also tried to call bzr.initialize() just after the import bzrlib, but I get the same error
<wgz> adiroiban: could also just be a race, which we have a bug for already
<wgz> but it's config not trace that needs fixing, I guessed wrong
<adiroiban> wgz: unfortunately I am stuck with python 2.5 so I am using bzr 2.3.4
<wgz> so, try "from bzrlib import config; config.StringIO()" before spawning threads
<wgz> which will deal with that particular one at least
<adiroiban> it seems like config.StringIO() solve the problem...
<adiroiban> thanks!
<lamalex> jelmer, ah, that's a good idea
<lamalex> jelmer, i was looking through the source to try and find where it actually builds and i can only find where it builds the source package
<jelmer> lamalex: it doesn't build binary packages at all
<lamalex> oh, ha
<lamalex> but --no-build and pbuilder should work for building a binary package
<jelmer> vila: what's the easiest way to create a stack from a string?
<vila> jelmer: a store from a string and then a stack from a store like I did for your commit builder branch ?
<jelmer> vila: ah, thanks
<vila> bzrlib.tests.test_commit.py
<vila> jelmer: and hi ! :)
 * vila scrolls back for stacked questions
<vila> jelmer: ping, workflow question, I've landed the fix for bug #904704, should I: 1) mark the bug fix committed, 2) target 2.8, or both or something else ?
<ubot5> Launchpad bug 904704 in bzr-builddeb "non utf-8 encoded changelogs cannot be parsed with recent python-debian" [High,In progress] https://launchpad.net/bugs/904704
<vila> also, ChrisCauser encounter a weird issue: bug #905218
<ubot5> Launchpad bug 905218 in Bazaar "bzrlib.initialize() misses out the default prober" [Critical,Confirmed] https://launchpad.net/bugs/905218
<vila> jelmer: I thought the prober could ring a bell with you
<jelmer> vila: yep, target 2.8 and mark as fixcommitted
<jelmer> vila: yeah, that makes sense
<jelmer> vila: we don't import bzrlib.bzrdir necessarily
<jelmer> vila: so we don't register the prober for .bzr in some cases. We should probably import bzrlib.bzrdir from bzrlib.initialize()
<vila> but the end result is that open_workingtree ends up raising NotABranch because no prober is registered
<jelmer> vila: right, because we haven't registered the prober for .bzr/
<vila> a bit weird that importing workintree.py doesn't trigger importing bzrdir.py...
<vila> and also why wasn't it the case for bzr-2.4 ? (Probably more lazy loading related)
<jelmer> vila: yeah, more lazy loading
<jelmer> vila: there isn't much in bzrlib.workingtree that is bzr-specific
<jelmer> vila: so nothing uses bzrlib.bzrdir
<vila> yeah, wt.py vs wt4.py ?
<jelmer> vila: right - wt.py just contains the main API, which is shared by bzr and foreign formats
<jelmer> vila: I wonder what the better fix is, explicitly importing "bzrlib.bzrdir" at the top of wt.py, or adding "import bzrlib.bzrdir" to bzrlib.initialize?
<jelmer> I think in bzrlib.workingtree
<jelmer> as we're already doing something similar in bzrlib.branch and bzrlib.repository
<vila> or registering the bzr prober lazily somehwere ?
<vila> ha, that's probably best then
<ChrisCauser> jelmer: Thanks a lot for the help with #905218
<jelmer> ChrisCauser: np
<jelmer> we've been reducing the number of imports that bzr does at startup time, and that's now biting us
<ChrisCauser> jelmer: I guessed that was the problem, but on the flip side, I /really/ do appreciate the work in this area. Bzr is so much quicker now. I really notice it
<vila> jelmer: worth mentioning in the what's new ;)
<jelmer> vila: what is?
<vila> jelmer: more lazy loading => bzr quicker
<jelmer> vila: ah, yeah
<wgz> wow config_dir is called too many times... <http://float.endofinternet.org/xmlbin/dev_testtools_trunk#bb.test_version.TestVersion.test_main_version>
<jelmer> wgz: hmm, how can you tell?
<jelmer> ah, I see now
<jelmer> well, GlobalStore is called very often
<vila> If it's now called more often than GlobalConfig, I call it progress ;-)
<wgz> is there a reason test_osutils.TestGetuserUnicode tests use LOGNAME rather than USERNAME?
<wgz> I broke them because LOGNAME is meaningless on win.
<vila> welcome to environ and its standardS
<wgz> okay, I have a kinda-plan with directories
<wgz> on startup, bzr should resolve and prepare any well known locations it needs, then stash them somewhere obvious (ie... fix global_state)
<wgz> so, this is the 'home' config location, a cache directory, whereever we think .bzr.log should go... anything else?
<wgz> currently there are 6 or so bugs about locations of things, that would be easiest to fix in one big go rather than moving stuff around piecemeal
<jelmer> hmm
<jelmer> I wonder if there's an easy way to discover whether a file system supports the executable bit, other than trying to change it on a particular file
<mgz> would be nice if pathconf didn't suck
<mgz> alas, it does.
<Peng> jelmer: Could create a file once and then stat() it everafter.
<Peng> Hmm, that'd be a problem if it was moved onto a different fs that did or didn't support the exec bit...
<mgz> Peng: also, some C libs emulate the exec bit based on file extension
<jelmer> Peng: yes, and file systems that don't support the X bit have different defaults for the executable bit.
<mgz> rather than actually storing a bit with the file
<mgz> jelmer: so, it's easy to discount support in a few cases
<mgz> proving support is hard
<mgz> though not quite as hard as proving bug-free support :)
<mgz> you could cover the common cases if you can use (and trust) a syscall to give you the filesystem type
<mgz> I bet nfs makes life hard there though
<jelmer> mgz: I agree the sensible thing to do is:
<jelmer> * assume win32 doesn't support the executable bit
<jelmer> * on other platforms, assume the executable bit is support unless we can somehow determine that it definitely isn't
<vila> conf.set('xxx', ''), val = conf.get('xxx') , val == '""' >.<
<jelmer> yeah, a configuration option would indeed also be a possibility
<jelmer> I wish we had a per-tree configuration though..
<vila> nah, was mentioning the siliest bug ever, re-read
<vila> setting a conf option to '', re-reading it, get '""', not ''
<jelmer> ah :)
<mgz> heh
<vila> configobj apparently, been there since epoch
<vila> why we never ran into it....
<mgz> okay, I'm going to finish off the lazy_import threading branch
<mgz> won't help people marooned on bzr 2.3 like earlier, but the current code is insane compared to MvG's
<jelmer> mgz: cool
<jelmer> mgz: I think I found an alternative
<mgz> doing a fix for that dumb use of StringIO on 2.3 onwards is probably also worthwhile
<mgz> jelmer: do tell
<jelmer> mgz: it's not exactly ideal but better than what we have now
<jelmer> mgz: use stat('.bzr/format') to get st_dev
<jelmer> then use getmntent to find the file system type..
<mgz> and nfs won't be clever and lie
<mgz> ?
<jelmer> mgz: well, we'll get back "nfs" for nfs mounts
<mgz> if so, that's worth doing.
<jelmer> mgz: and there's no way of knowing what the underlying fs is, but we can just default to assuming it supports the executable bit
<jelmer> mgz: at least it means we'll get it right for FAT, etc
<mgz> well, or fall back to trying a dance
<mgz> if we can trust 'ext4' (ho ho) then at least the common case doesn't need funny business
<vila> and we'll keep assuming that's true for the whole wt
<mgz> ...can anyone think of a reason not to use trace.mutter from inside lazy_import resolution?
<jelmer> mgz: overhead?
<vila> trace lazy import
<mgz> only for duplicate resolution, so not all the time... will double check the loop issue
<jelmer> mgz: still there?
<mgz> jelmer: yup, just had a break for dinner
<mgz> did the basic simplifications I suggested for the lazy_import change
<mgz> but wonder if there isn't a proper race-aware way of doing this
<mgz> where the first thread to both get, and delete, scope, gets to do the work
<mgz> this could mean other threads are stuffed waiting for it to finish I guess, so deadlock
<mgz> meph.
<mgz> can still use that to work out if it's a race or a reuse though
<Noldorin> hey folks
<Noldorin> hi mgz
<mgz> hey Noldorin
<Noldorin> how's... things?
<Noldorin> saw the b4 release of 2.5 :-)
<Noldorin> looking good
<mgz> getting there :)
<Reggie> can anyone help a relative bzr novice out?  I have someone who pushed a change to remote repo A, and then merged that to remote repo B and then C.  The change should have only gone into C
<Reggie> what's the easiest way to remove it from A and B?
<Reggie>  I know I can overwrite the affected files with the files from current-1 and then do a normal commit but hoping there is an easier or more standard way to do it
<Reggie> thanks
<jelmer> hi Reggie
<Reggie> hi
<jelmer> Reggie: bzr uncommit is what you're looking for probably
<Peng> It sounded to me like it was too late for uncommitting.
<Reggie> dev commited locally and then pushed to remote branch
<wgz> <http://doc.bazaar.canonical.com/beta/en/user-guide/adv_merging.html#reverse-cherrypicking>
<wgz> <http://doc.bazaar.canonical.com/beta/en/user-guide/undoing_mistakes.html#undoing-the-last-commit>
<Reggie> then merged up to B and C locally and pushed them
<Reggie> now we need to remove the last changeset on the remote repos A & B
<wgz> whether you want to uncommit or merge a reversion depends on how public the branches in question are
<Reggie> these are not public
<Reggie> internally hosted
<wgz> if lots of people use them, they'd get confused if you rewrite history on them by removing the commit entirely
<Reggie> not an issue
<wgz> then uncommit and email to everyone saying "whoops" is generally fine
<Reggie> here is where I get confused.  I do a bzr uncommit and now I see the changed files (which is correct). what then?  the bzr uncommit doesn't effect the remote repo?
<Reggie> do I need to do the bzr uncommit on the remote repo?
<wgz> yeah, you just pass it as the location
<wgz> so, `bzr uncommit A` `bzr uncommit B`
<Reggie> will repo C get confused?  the change needs to be in C  (these repos are chained together)
<wgz> depends how you did the merge.
<wgz> you can branch all three locally, try it out and see
<wgz> then do it for real when you have the state you want
<Reggie> devs do merges on their local workstations.   they would typically push in folder A  then from inside folder B they would do  bzr pull; bzr merge ..\A;  bzr commit -m"merged"; bzr push
<Reggie> make sense?
<wgz> this is getting out of basic fixing a mistake, and into workflows
<wgz> what would the correct series of operations have been?
<Reggie> make change in C and push only to C
<Reggie> instead dev thought the fix should go all the way back to A
<Reggie> this is a single product versioned.  vesrion A, vesrion B, version C
<wgz> and C is newest.
<Reggie> yup
<wgz> uncommit on all three then do it right is fine then.
<Reggie> any big problem with overwriting the changed files with files from revision-1 and doing a new set of commits/pushes?
<wgz> if this happened some revisions back, you'd want to reverse the merge on A, merge up to B, merge up to C *then revert the tree but keep the merge*
<Reggie> I say that because repo C may be already been changed by others so uncommit there might be challenging
<wgz> if you can replay the new changes on C that's also fine, but deeper into history rewrite territory
<Reggie> yes, I think you just said what I was trying to say.  basically undo the change manually in A & B and then do what I call null-merge to C
<Reggie> the bad change is the very last change on A & B but it's not the last change on C
<wgz> that option is basically just `bzr merge -r-1..-2 -d A A; bzr commit A; bzr merge -d B A; bzr commit B; bzr merge -d C B; bzr revert C; bzr commit C`
<Reggie> right
<Reggie> :)
<wgz> `bzr revert *` rather.
<wgz> you want to keep the merge, but not the changes.
<Reggie> wgz, thanks.  really appreciate the help
<Noldorin> wgz, oh yeah, was going to ask. does bzr have 'service' plugins like hg does? like for notifying you when someone pushes?
<Noldorin> on a bzr server
<Noldorin> that is
<Noldorin> also, does LP specifically have them?
<wgz> bzr does, lp doesn't as far as I'm aware, but various things you can use for landing changes like pqm and tarmac can notify
#bzr 2011-12-17
<Noldorin> wgz, pqm/tarmac?
<Noldorin> wgz, wouldn't they have to poll, whatever they are?
<cyberkilla> Hello, quick question. I want to set up a central repository on a network share and have myself and others commit to it, but it never seems to save the files to the network share. Only the .bzr file is updated. Am I missing something here?
<cyberkilla> Just to clarify: Repository on network share (NAS), checkout code to edit locally, and commit back to the main repository on the network share. That's what I thought was possible with bzr, but it isn't working out.
<wilx> cyberkilla: You mean that the working copy is not updated?
<cyberkilla> wilx, yes, the network share only has ".bzr" in the folder. It never saves anything else.
<wilx> Well...
<wilx> AFAIK, you should not need a working copy for the central repo.
<cyberkilla> The tutorial on the bazaar website says to do a bzr push to get the initial code up into the repository, then bind to it, but it just creates a bzr file.
<cyberkilla> The thing is, the source code is 1.7MB and the .bzr file is 206 bytes. I, so I don't know what it has actually achieved. :(
<cyberkilla> wilx, I had assumed that myself. I had thought that perhaps it just kept all of the deltas in .bzr, and didn't need a working tree. The thing is, I don't think it is actually saving anything.
<cyberkilla> wilx, thanks for responding btw. I thought it would be a quick task, but it's fighting me at every step.
<wilx> Personally, I have not had any prolems with this...
<wilx> bzr push has worked for me always.
<cyberkilla> Do you push to a network share, or local drive?
<wilx> I was pushing over Samba to a share.
<cyberkilla> Does it only copy to .bzr, and nothing else?
<wilx> Well, I used the --no-trees switch.
<wilx> ...for the shared repo.
<cyberkilla> The bzr push command's manual entry says: "The target branch will not have its working tree populated because this is both expensive, and is not supported on remote file systems."
<cyberkilla> That suggests that it won't in fact copy the working tree (which I assume is the actual source code being versioned here)
<cyberkilla> So I'll only get the revision history. I just can't seem to grasp the concept of this. I followed the tutorial to the letter.
<wilx> Which tutorial exactly?
<cyberkilla> http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/publishing_a_branch.html
<cyberkilla> That's the one, I believe.
<fullermd> The working tree is the exploded out files that you can edit and read and compile and whatnot.
<fullermd> push just pushes the history [to remote locations].
<wilx> cyberkilla: Well, if you have followed that then you have used --no-trees option for the repository and hence it does not have any working copy.
<cyberkilla> fullermd, how do I commit changes to a central repository, so that others may checkout a branch, make changes, and commit back to the central repository? I'm sure it's my misunderstanding of how bzr works that is the problem, rather than bzr itself.
<vila> . o O (Why mention http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief when The main itself answers...)
<vila> s/main/man/ damn ruining jokes tyops
<cyberkilla> wilx, oh
<wilx> cyberkilla: The changes, files, metadata are all packed together in the .bzr directory.
 * fullermd points and laughs at vila.
<cyberkilla> wilx, well, that's what I had thought, but it's not including any of the changes :(
<wilx> cyberkilla: How have you propagated the changes to the central repo?
<fullermd> When you push, you push all the history, which is everything needed to _make_ the WT.  Anybody branching/pulling from it gets all that.
<wilx> Also, how have you committed them to your local branch.
<vila> cyberkilla: .bzr is a directory not a file, if it's empty it means you've never successfully pushed to it
<fullermd> It just doesn't split out the files on the remote side.
<cyberkilla> wilx, bzr init && bzr add && bzr commit -m "Initial import" && bzr push ____
<vila> cyberkilla: what does 'bzr info -v' says in the directory where you pushed ?
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<cyberkilla> vila, it's not empty, it has files. It's just that the total size of the directory is under 300 bytes in size, but the code is at least 1.7MB of PHP and PNGs
<vila> cyberkilla: then you never successfully pushed there
<vila> cyberkilla: so maybe you pushed elsewhere
<vila> cyberkilla: 'bzr info -v' should tell you where
<cyberkilla> vila, it creates the .bzr folder when you push, because it pushes the folder, creating it on the share. This is all very strange.
<fullermd> Did you do an init-repo around there before you pushed?
<vila> fullermd: nice catch ;)
<cyberkilla> fullermd, I did an init-repo in the folder that the folder being pushed was create in. e.g. R:\bzr\project and R:\bzr\project\trunk
<vila> cyberkilla: any .bzr under  R:\bzr\project ?
<cyberkilla> fullermd, I believe so, but I'll check...
<cyberkilla> fullermd, Yes, there is one.
 * fullermd takes all the credit and retires in victory.
 * vila bows
<cyberkilla> Is that a bad thing to do? :) I thought I was following the tutorial correctly:P
<vila> cyberkilla: so, the current theory is that your shared repo is at R:\bzr\project and your branch is at R:\bzr\project\trunk
<cyberkilla> vila, Yes
<vila> this means the .bzr folder for your branch is very small and will always be
<cyberkilla> Oh!
<vila> the revisions are stored in the repository, the .bzr folder there contains a 'repository' folder there which doesn't exist in your branch .bzr folder
<cyberkilla> vila, thank you for enlightening me :-)
<vila> cyberkilla: congratulations on identifying the 3 main bzr components so early ! With these pieces in mind, you're now ready to read http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInLength)
 * vila ducks and bows in direction of both wiki pages author
<cyberkilla> vila, am I right in thinking that I can point to R:\bzr\project\trunk to checkout a copy of the code, or is it more complicated than that?
<vila> cyberkilla: perfectly right
<vila> cyberkilla: read 'bzr help branch' and 'bzr help checkout' as they may imply different workflows
<cyberkilla> vila, excellent, I'll give it a try. Thanks again to the both of you.
<vila> cyberkilla: if you end up using lightweight checkouts though, think twice as misunderstanding them lead to a few traps (they are fine in themselves if used as appropriate)
<vila> cyberkilla: experimenting  with 'bzr qlog' is also great to visualize how revisions move from a branch to another
<fullermd> Yeah, vila used lightweight checkouts once, and look what it did to his tpying.
<cyberkilla> :)
<cyberkilla> I have a couple of years of revision history, but I don't think it'll be too big of an overhead to checkout in full.
<vila> fullermd: correction, I never used them as I feel I'm naked (no bragging implied, it's just too cold around there to be wearing only a leaf, a branch is required)
<cyberkilla> Actually, earlier today I tried bzr join to try to version the parent folder. You see, I used to use a standalone tree on project/src (another project), but inside of project were project/bin project/tools and I wanted to versiont those too.
<fullermd> Well, great.  Now I have to go bleach my mind's eye after that...
<cyberkilla> So, I did bzr init on ./project, then bzr join src to pull it in. Seemed to work, but then everything imploded and bzr add started adding .bzr.retired files, bzr update through python errors, and I decided I'd just start from scratch :p
<fullermd> You wouldn't do an add after a join.  Join is handwavingly like merging another branch into a subdir, so just like after a merge, you've got that as a pending change to commit.
<cyberkilla> fullermd, I tried it after committing gave me errors about unexpected file deltas, or something similarly confusing. I had probably did it in the wrong order. I have a backup, so all is not lost.
<cyberkilla> But for now, my problem is solved. Thanks again :)
<fullermd> Backup?!  Pfui.  Backups are for pessimists.
<cyberkilla> fullermd, I like to be in a position to mindlessly press buttons without there being dire consequences. :-P
<meoblast001> hi
<meoblast001> suppose i want to develop something outside the main branch, but i will be responsible for merging it into the main branch
<meoblast001> do i need to maintain 2 separate trees of the project?
<vila> meoblast001: you don't need to, but the workflow will be easier
<meoblast001> ah, ok
<vila> If the size is not an issue, you'd be better served by 2 working trees, and if they share their repository, the overhead is only the size of the working tree
<meoblast001> vila: share the same repository?
<meoblast001> ooh, if i store them in one working tree?
<vila> no, a working tree needs a branch, a branch needs a repository
<vila> but several branches can share the same repository
<meoblast001> oh
<vila> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<vila> meoblast001: how big is your working tree ? ('bzr info -v' will tell you)
<meoblast001> vila: it doesn't give it as a size
<meoblast001> just amounts of files
<meoblast001> would it be a good idea to have 2 branches, and 2 branches on the server... separate directories and working trees.. push my personal one to my personal branch on the server
<vila> yup, any file browser can give you the whole size (as well as the one of the .bzr directory)
<meoblast001> then, go to my main branch on my local machine, and merge in the remote personal directory when i'm ready
<meoblast001> and push that up to the main remote directory
<vila> yes
<meoblast001> and that would be a normal way of doing things where i shouldn't expect problems?
<meoblast001> also, 77.6 KB.. it's a small project so far
<Noldorin> hi folks
<Noldorin> does anyone know what the path in bzr+ssh URLs corresponds to on the fS?
<jelmer> Noldorin: hi
<Noldorin> hi jelmer
<jelmer> Noldorin: whatever the remote SSH server does
<Noldorin> jelmer, it's openssh sshd
<Noldorin> under cygwin
<jelmer> Noldorin: where does it end up if you ssh in manually?
<Noldorin> jelmer, the home directory which i configured :-)
<jelmer> Noldorin: and what is / ?
<jelmer> Noldorin: all paths will be relative to /, and ~ is translated to the home directory
<Noldorin> jelmer, how do i find out what / is ?
<jelmer> Noldorin: "ls /" ?
<Noldorin> jelmer, contains bin, dev, etc, home, lib, proc...
<Noldorin> usr
<Noldorin> var
<Noldorin> tmp
<jelmer> Noldorin: where / is depends on your server configuration, which will depend on cygwin
<Noldorin> jelmer, c:\cygwin probably...?
<Noldorin> jelmer, but bzr+ssh most deinfitely treats root as my home dir
<jelmer> Noldorin: does "ssh yourhost ls /" list the contents of your home dir?
<Noldorin> yes
<Noldorin> err
<Noldorin> wait a sec
<Noldorin> jelmer, can't do that with putty
<vila> meoblast001: sry, was afk, yes, perfectly normal
<meoblast001> ah, ok, thanks :)
<meoblast001> vila: i now have an interesting problem, btw
<meoblast001> well, it's nothing you can fix, nor i :P
<meoblast001> i use Bazaar on my personal projects, and Git at work now
<meoblast001> and now i find myself joining #git asking how to make Git do what Bazaar does, and joining #bzr asking how to make Bazaar do what Git does
<Noldorin> jelmer, so?
<vila> meoblast001: as long as you find a way to address your needs, I don't see where the problem is ;)
<meoblast001> yup :P
<Noldorin> jelmer, brb anyway
<jelmer> Noldorin: wb
<Noldorin> ty jelmer
<jelmer> Noldorin: Sorry, I have no idea of to use ssh on windows exactly
<Noldorin> jelmer, well it's exactly lke openssh but just running in cygwin ;-)
<Noldorin> so should be quite simple
<Noldorin> jelmer, shouldn't bzr+ssh urls be root-based though?
<Noldorin> as you said earlier
<Noldorin> even that's not happening
<Noldorin> so very weird
<jelmer> Noldorin: bzr basically runs "ssh YOURHOST bzr serve --directory=/ --allow-writes"
<jelmer> oh, and --inet
<Noldorin> jelmer, what's inet?
<Noldorin>   zzz
<Noldorin> *thinks jelmer is on a cycle of chat 1 minute, afk 10 mins, repeat*
<jelmer> Noldorin: inet means using stdin/stdout
<jelmer> Noldorin: (used for inetd on POSIX)
<Noldorin> ok
<Noldorin> i see
<Noldorin> jelmer, so can i change these default options maybe?
<jelmer> Noldorin: which default options?
<Noldorin> huh?
<Noldorin> the bzr serve ones
<jelmer> Noldorin: I don't see how that would help.
<Noldorin> jelmer, changing directory maybe?
<jelmer> Noldorin: the directory is already set to /
<Noldorin> jelmer, yeah but i want something like /cygdrive/c/projects don't i? :-P
<jelmer> Noldorin: does "bzr log bzr+ssh://host/cygdrive/c/projects/.../" work?
<jelmer> Noldorin: / should already mean paths are relative to the root.
<Noldorin> jelmer, but you're confusing the windows and cygwin roots...
<jelmer> Noldorin: bzr+ssh paths would be relative to the cygwin root
<Noldorin> yes that's my point
<Noldorin> :-P
<Noldorin> not what i want though
<Noldorin> one sec
<Noldorin> let me test
<jelmer> Noldorin: Sorry, I have a hard time following what you're trying to do and what exactly doesn't work..
<Noldorin> jelmer, that cmd (bzr log ) returns "not a branchj"
<Noldorin> jelmer, the problem seems to be that bzr is using paths relative to the home directory *regardless* of what i give it
<Noldorin> jelmer, and we've confirmed that a normal ssh in detects the correct route
<Noldorin> so sounds like a bzr bug to me :-(
<Noldorin> jelmer, some way to debug bzr maybe?
#bzr 2011-12-18
<jelmer> Noldorin: if you run "bzr serve --directory=/" in cygwin, can you use bzr:// using root-based URLs?
<Noldorin> hmm let's see :-)
<Noldorin> jelmer, what port does normal smart serv run on?
<Noldorin> jelmer, apparently it's a read-only transport?
<jelmer> Noldorin: yes, unless you specify --allow-writes
<Noldorin> ah
<Noldorin> on the server end eh?
<jelmer> it doesn't do authentication, so you probably want to do this on a world-facing machine
<Noldorin> yes indeed
<Noldorin> jelmer, not working any more
<Noldorin> really weird
<jelmer> Noldorin: what isn't?
<Noldorin> bzr serve
<Noldorin> very weird
<Noldorin> hmm one min
<Noldorin> jelmer, ok tested. interestingly, that inits the branch in the wrong dir too
<Noldorin> under the home dir
<Noldorin> instead of root cygwin dir
<Noldorin> so nothing to do with ssh it seems
<jelmer> Noldorin: are you specifying --directory=/ ?
<Noldorin> yep
<Noldorin> absolutely
<Noldorin> hm
<Noldorin> jelmer, any thoughts?
<jelmer> Noldorin: what's the URL you're specifying to connect?
<Noldorin> bzr://alex-serverb/test1
<Noldorin>  bzr serve --directory=/ --allow-writes
<Noldorin> on server
<jelmer> Noldorin: and "bzr ls /test1" on the server works?
<Noldorin> jelmer, correct
<jelmer> Noldorin: hmm, no idea in that case. Perhaps a cygwin-specific issue?
<Noldorin> maybe
<Noldorin> hm
<Noldorin> either way, quite annoying
<Noldorin> let's see...
<Noldorin> jelmer, maybe you could ocnfirm somehow?
<Noldorin> confirm*
<jelmer> Noldorin: sure
<Noldorin> jelmer, cheers. let me know when you get any more info :-)
<jelmer> Noldorin: ?
<jelmer> Noldorin: what do you need me to confirm?
<jelmer> I don't have cygwin (or Windows) here, I thought you were going to ask me for something else to confirm.
<jelmer> sorry
<Noldorin> why did you say sure then lol?
<Noldorin> i meant that it *does* work without cygwin
<Noldorin> all else the same
<Noldorin> brb
<jelmer> Noldorin: Yes, I'm sure it works without cygwin.
<jelmer> (and just confirmed)
<ggherdov> hi all. I'm looking for some docs on criss-cross merges (basically, what is the definition of criss-cross graph of branches?). bzr help criss-cross gave me a rough idea, in bzrlib/tests/test_merge.py there are some examples, but i'd like to get the general idea before digging into specific examples. Maybe a paper on three-way merge? any hint?
<jelmer> hi ggherdov
<ggherdov> hello jelmer
<jelmer> ggherdov: see also 'bzr help criss-cross'
<ggherdov> sure I did. Actually I came over this line in bzrlib/merger.py , class Merger :
<ggherdov> lcas = self.revision_graph.find_lca(revisions[0], revisions[1])
<ggherdov> if the list "lcas" have more than 1 elem,
<ggherdov> i.e. more least common ancestors,
<ggherdov> you get a criss cross (ie. a _is_criss_cross variable is set to True :-)
<ggherdov> I was now looking into the find_lca method, to get a grasp on the algorithm.
<jelmer> ggherdov: criss-cross isn't an algorithm but rather a situation that can occur during merge, are you asking about the lca merge algorithm?
<ggherdov> jelmer: my question was: "what is the definition of criss-cross?". From the code, apparently, is: when you have more than one LCA. Now my question is: what is the definition of LCA? and for that, I am reading the algo that finds them.
<jelmer> ggherdov: lowest common ancestor
<ggherdov> how is an ancestor "lower" or "higher"?
<ggherdov> I mean, it isn't just path's length,
<ggherdov> since you have two paths to consider: A is a (common) ancestor of X and Y, so there is a path A-->X and A-->Y. How do you measure the distance pf ancestor A to the couple (X,Y), to compare with another ancestor, say B?
<ggherdov> s/pf/of
<jelmer> ggherdov: distance would be the number of edges between X and A and X and B
<ggherdov> got it! it's in the file bzrlib.graph . Say that you have a bunch of ancestors. lowest common ancestor of two nodes are those ancestors such that none of their descendant is a common ancestor. pastebin of the comment in graph.py: http://pastebin.com/ijyzmSQs
<jelmer> right
<ggherdov> jelmer: isn't about distance, I was completely off road.
<jelmer> ggherdov: right, it's about the relationship - the number of commits in between is irrelevant
<ggherdov> Yeah. I am going to make a wikipedia entry right away :-D (joking)
<jelmer> heh
<jelmer> ggherdov: what are you trying to do?
<ggherdov> bah, nothing specific. Last week at work I got this warning about "hey - you are trying to merge but there is a criss-cross", which looked voodoo to me, and I wanted to see things clearer
<jelmer> ah, I see
<jelmer> ggherdov: Do you think there's anything specific in the help text "bzr help criss-cross" that could be improved?
<jelmer> *help text of
<ggherdov> I had the impression that it didn't tell me what was happening, i.e. what the hell is criss-cross. Let me read it again.
<ggherdov> no, I guess it was my inexperience. The help is good, it provides a practical explaination without a boring math definition:
<ggherdov> Criss-crosses occur in a branch's history if two branches merge the same thing
<ggherdov> and then merge one another, or if two branches merge one another at the same
<ggherdov> time
<ggherdov> the first is a "diamond" (clear criss cross), the second is a |X| (again clear criss cross).
<ggherdov> then the help continues:
<ggherdov> "Criss-crosses mean there is no good choice for a base"
<ggherdov> which is just right into the problem.
<ggherdov> maybe the point is that we're all a bit paranoid when merging (you are afraid of losing stuff silently), and anywhere you aren't 100 % in control you panic.
<jelmer> ggherdov: yeah, I know that feeling :-)
<ggherdov> :-)
<jelmer> I don't think I've actually had merge lose stuff. Perhaps that message should be just a note rather than a warning.
<ggherdov> Well, if there is even *just one* thoretically possible criss-cross situation where a bad thing can happen, i think that the warning is appropriate.
<jelmer> ggherdov: with the default merge algorithm, the worst that can happen is that you get more conflicts than you would with --lca
<ggherdov> I see. --lca triggers a different merge algorithm?
<jelmer> ggherdov: yep
<ggherdov> about the help: if anything, I would add a reference to some more specific documentation, like a technical paper or the code itself (like: to know more, read this paper / look into file XY)
<ggherdov> jelmer: do you know if algorithms in bazaar are developed by the canonical folks, or rather the implementation of some standard stuff you can find in google scholar? if the latter, a tiny link somewhere would be nice I think.
<jelmer> ggherdov: I'm not too familiar with the merge algorithm internals personally. I think it's a combination of both.
<ggherdov> ok I see.
<Noldorin> hey jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer, found out the solution
<Noldorin> jelmer, bzr+ssh is always relative to home directory it seems
<Noldorin> at least in cygwin
<Noldorin> it's designed this way
<Noldorin> but i can get around with it by a) creatign a cygwin symolic link
<Noldorin> b) creating a cygwin mount entry
<Noldorin> :-)
<jelmer> Noldorin: I'm pretty sure that's not design in bzr+ssh
<Noldorin> jelmer, well either way, bzr+ssh doesn't work hwo it should with bzr+ssh urls in cygwin
<Noldorin> but there is a solution
<Noldorin> as i said ;-)
<Noldorin> this works at least
<jelmer> Noldorin: well, good to hear you found a solution at least
<Noldorin> yeah :-)
<Noldorin> jelmer, it's not a bug in bzr itself, i agree. either an explicit feature, or just the result of how cygwin operates
<wgz> Noldorin: now you have it working, will you give in to my request to post about what you did on the bazaar list? :)
<Noldorin> wgz, i was going to write a blog post, but okay...
<Noldorin> what's the email?
<wgz> blog post and link to it is fine also.
<Noldorin> ok cool
<Noldorin> jelmer, wgz any idea whether bzr+ssh urls on windows servers run bzr within cygwin or not?
<jelmer> Noldorin: that depends on your ssh server
<Noldorin> jelmer, openssh as i said before ;-)
<Noldorin> but on windows of course
<Noldorin> it is the cygwin sshd server
<Noldorin> but
<Noldorin> not sure whether it's actually run in the cygwin context
<jelmer> Noldorin: natively compiled, or in cygwin?
<jelmer> Noldorin: bzr simply connects to the ssh port - whatever happens behind there is up to you
<Noldorin> jelmer, nothing is native in cygwin
<Noldorin> you're thinking of msys
<Noldorin> (mingw)
<jelmer> Noldorin: openssh can be compiled natively perhaps?
<Noldorin> nope
<Noldorin> definitely not on windows
<Noldorin> at least, no-one has tried it/released any source
<Noldorin> jelmer, bah, i just figured it out
<Noldorin> the problem is that the sshd uses cygwin fs
<Noldorin> but not bzr exe itself
<Noldorin> this explaisn everything :-(
<Noldorin> hmm
<jelmer> ahh
<wgz> yeah, it's within the cygwin shell so it sees those paths
<Noldorin> wgz, no, that's the thing. bzr *does not* run with the cygwin shell
<Noldorin> it runs natively on windows
<wgz> ah, if you call out to a native windows bzr, sure
<Noldorin> native windows bzr is by far the easiest solution on windows
<wgz> but the `bzr serve` command works from the cygwin shell
<Noldorin> it doesn't like python on windows, esp. regarding plugins and whatnot
<Noldorin> wgz, it works, but it uses the native win32 environment :-P
<Noldorin> ok, so with a normal windows hard link:
<Noldorin> it kind of works...but gives a remote lock error
<Noldorin> http://pastebin.com/NmH0CU2j
<Noldorin> any ideas? :-)
<wgz> need to see the server side log
<Noldorin> ok
<Noldorin> one sec
<wgz> likely you want a different BZR_REMOTE_PATH
<Noldorin> wgz, http://pastebin.com/2ixVJHVh
<Noldorin> no error there hmm
<wgz> need some debug flags thrown in as well
<Noldorin> wgz, tell me what to do :-)
<wgz> need fullermd really, he has more cunning tricks than me
<wgz> the basic issue is the chroot is in totally the wrong place apparently
<Noldorin> heh
<Noldorin> i see
<wgz> Noldorin: <http://doc.bazaar.canonical.com/beta/en/user-reference/debug-flags-help.html>
<Noldorin> wgz, well i'm happy to do some testing now, just give me orders.
<Noldorin> otherwise we'll wait until fullermd is around
<Noldorin> hmm
<Noldorin> wgz, which ones, and on client or server?
<wgz> in your config, set debug_flags to hpss and hpssdetail
<Noldorin> ok
<wgz> for the server, but but both wouldn't hurt
<wgz> and hpssvfs too I guess
<Noldorin> where is bzr.conf?
<Noldorin> bazaar.conf*
<wgz> run `bzr version` it will tell you what dir it's in
<Noldorin> wgz, no file in the config dir. create one called bazaar.conf?
<wgz> yeah, you want [DEFAULT] at the top too.
<Noldorin> kk
<wgz> if you run `bzr config debug_flags=hpss,hpssdetail,hpssvfs it's do it for you think
<Noldorin> yep just did that, ta
<wgz> then try the init again and paste the client and server logs again
<Noldorin> http://pastebin.com/uWrLUtsx
<Noldorin> (server)
<Noldorin> err wait
<Noldorin> that's someone else's paste
<Noldorin> weird
<Noldorin> http://pastie.org/3036664
<wgz> try again with /testreallyuniquenamethistime ?
<wgz> ...really I want to see what the underlying fs path is getting mapped to...
<wgz> wait, no, misread, that does create the dir
<Noldorin> cleint is same
<Noldorin> yeah
<Noldorin> it does
<Noldorin> the actual dir/repo/branch looks like it's created fine
<Noldorin> just the stupid remotelock error
<wgz> in what location?
<Noldorin> C:\projects
<wgz> need some way of getting the actual error/traceback on the server side...
<Noldorin> wgz, -Derror maybe?
<Noldorin> see the page you linked me to
<wgz> throw in "lock" and "strict_locks" and yeah, why not "error" as well.
<Noldorin> http://pastie.org/3036698
<Noldorin> wgz, there
<wgz> okay, that's helpfuly.
<wgz> -y
<wgz> looks like a lockdir bug.
<wgz> I wonder what cwd is from the perspective of bzr
<Noldorin> yeah
<Noldorin> hmm
<wgz> okay, it feels like something is holding open the '8fuv1clmc4.tmp' file preventing it from being renamed into place
<wgz> but it's a directory, so I'm not even sure if that can happen
<jelmer> hah, bzr run time is finally creeping towards 0.1s again
<wgz> yeah, we regressed that pretty badly.
 * jelmer has a nasty patch that copies urllib.quote and urllib.unquote into bzrlib.urlutils
<jelmer> it avoids import socket and ssl during normal operation though
<wgz> okay, I think I understand the lockdir issue
<wgz> jelmer: the other option would be something like the inspect_for_copy hack :)
<wgz> I don't think you should feel too bad about reimplementing bits of urllib though
<wgz> everyone else does.
<wgz> Noldorin: is there any antivirus/other filsystem scanning software on your server?
<wgz> LocalTransport.put_bytes_non_atomic etc are pretty bad
<wgz> not safe in face of signals, way too much platform workaround code
<wgz> ha, I wonder.
<Noldorin> wgz, not on the server i don't believe...
<Noldorin> no antivirus
<Noldorin> wgz, what do you think it is then?
<Noldorin> wb wgz
<Noldorin> did you get my messages?
<wgz> nope, sorry, paste me in pm?
<wgz> thanks.
<wgz> okay, so lockdir works like so
<wgz> create a folder with a temp name
<wgz> create a file inside the folder with info in it
<wgz> try to rename the folder to "held" to take the lock
<wgz> if that fails, assume someone else already has the lock
<Noldorin> right
<Noldorin> trying that now
<Noldorin> hmm
<wgz> however, it can fail for reasons other than "held" already existing
<Noldorin> wgz, i'm the only user using this btw
<Noldorin> oh wait, you're just explaining how it works
<Noldorin> okay...
<wgz> one way to get the error you had is just by another process having the info file open when the rename happens
<wgz> this is incorrectly reported as LockContention
<Noldorin> right
<wgz> actually debugging this without changing code is hard.
<Noldorin> yeah, so i thought
<wgz> can you run the bzr serve from a source tree?
<Noldorin> sure
<wgz> the problem is a lot of our code here is... not great
<Noldorin> hah
<Noldorin> wgz, you trying to say some bzr is the composite work of monkeys on typewriters? ;-)
<wgz> no, but the layering and platform specific hacks work against sanity in many respects
<Noldorin> okay
<Noldorin> wgz, so not all the codebase is bad huh? :-P
<Noldorin> wgz, running it from a specific branch...just on the bzr:// protocol eh?
<wgz> right, I should probably see if I can repo anything here, but I suspect not
<Noldorin> wgz, ooh, this is kind-of-good news
<Noldorin> a local bzr init in that directory fails
<Noldorin> with LockContention
<Noldorin> with a traceback
<wgz> pastebin?
<Noldorin> http://pastie.org/3037040
<wgz> it may also be a geniune permission error, given you're on a newer windows
<Noldorin> just check i have full control on that dir
<Noldorin> so unlikely
<wgz> what exists inside Shared-Projects\foo\.bzr\branch-lock ?
<wgz> if there are any files, pastebin me them
<wgz> (also see if, from Shared-Projects, you can do `bzr init newfoo`)
<Noldorin> wgz, no files
<Noldorin> identical
<Noldorin> result
<Noldorin> with that command
<wgz> okay, now
<wgz> set BZR_PDB=1
<wgz> then run the command again
<wgz> will get you into the debugger at hopefully, line 641 in lockdir
<wgz> if you then type "self._attempt_lock()" you should get the same exception as before
<wgz> we can then try stepping into that
<Noldorin> *** LockContention: Could not acquire lock "LockDir(file:///Z:/Alex/Shared-Projects/foo/.bzr/branch-
<Noldorin> lock)":
<Noldorin> wgz, i end up with that
<Noldorin> on self._attempt_lock
<wgz> ace.
<Noldorin> so what next? :-)
<teusje> looks like the bzr documentation for windows is very out of date
<teusje> isn't it Noldorin :)
<wgz> Noldorin: "debug self._attempt_lock()", then start hitting 's'
<wgz> till you get inside _attempt_lock
<wgz> then use 'n' till you get to the 'self.transport.rename' line
<Noldorin> teusje, most of the docs are platform-agnostic ;-)
<Noldorin> but some of it is old yes
<Noldorin> heh
<Noldorin> wgz okies
<teusje> :p
<teusje> windows default paths that don't exist anymore in windows vista/win 7 :p
<wgz> so, "n" is forwards, and "s" is forwards-and-in
<wgz> we want to go in to the rename
<Noldorin> got it
<Noldorin> wgz, step over and step into as we say on windows :-)
<wgz> get to the except clause, where we have the real error from os.rename
<Noldorin> wgz, just one s i think?
<Noldorin> not sure i'm inside it yet
<wgz> this should be in transport/local.py
<wgz> hit 's' if unsure
<Noldorin> k
<wgz> but can always redo if you accidentally jump over
<Noldorin> cool, how?
<Noldorin> PermissionDenied: Permissi...s denied)
<Noldorin> > z:\alex\shared-projects\bzrlib\lockdir.pyo(243)_attempt_lock()
<Noldorin> wgz, get that before i get to self.transport.rename
<wgz> that looks like the error from that line
<wgz> we need to get into the call, so more 's' and less 'n'
<Noldorin> wgz, do you fancy just teamviewer-ing in? might go a lot quicker this way
<Noldorin> how do i back up then?
<Noldorin> *awaits command*
<vila> Noldorin: format c:
 * vila ducks
<teusje> vila tries to be funny
<Noldorin> *anticipates vila's duck and clobbers him with a Windows 7 install DVD*
<vila> . o O (Only way to be is to try ;)
<wgz> Noldorin: j 241
<Noldorin> wgz, then just 's' until... ?
<wgz> right
<wgz> Noldorin: could do some desktop sharing thing if you want, I'd need to install things
<Noldorin> wgz, actually teamviewer can run locally without install, that's what nice about it :-)
<Noldorin> wgz firstly though, http://pastie.org/3037180
<wgz> ace.
<teusje> Noldorin that it is not supported on their windows xp that they use for writing documentation :p
<wgz> do "p path_from" and "p path_to"
<Noldorin> u'Z:/Alex/Shared-Projects/foo2/.bzr/branch-lock/j2robxgreu.tmp'
<Noldorin> and u'Z:/Alex/Shared-Projects/foo2/.bzr/branch-lock/held'
<Noldorin> respectively
<wgz> then you can do "os.exists(path_from)" and "os.exists(path_to)"
<Noldorin> teusje, heh
<wgz> I expect path_from to exist, and path_to not to.
<Noldorin> wgz, module has no attribute exists
<wgz> *os.path.exists, sorry
<Noldorin> wgz, you expectations were correct.
<Noldorin> your*
<wgz> ok, now "p os.listdir(path_from)"
<Noldorin> wgz, just u'info'
<wgz> then "f = open(os.path.join(path_from, 'info'))
<wgz> "p f.read()"
<wgz> "f.close()"
<Noldorin> 'hostname: Alex-ServerB\nnonce: 2a540tvz6rmuz5p97tvz\npid: 3900\nstart_time: 1324235155\nuser: Alex\
<Noldorin> n'
<wgz> "os.remove(os.path.join(path_from, 'info'))"
<Noldorin> done
<wgz> and it worked, heh.
<wgz> so, discounts the handle issue
<wgz> now, "os.rename(path_from, path_to)"
<Noldorin> *** WindowsError: [Error 5] Access is denied
<wgz> "os.stat(path_from)"
<wgz> "os.remove(path_from)"
<Noldorin> nt.stat_result(st_mode=16895, st_ino=0L, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=0L, st_at
<Noldorin> ime=1324235908L, st_mtime=1324235908L, st_ctime=1324235155L)
<Noldorin> *** WindowsError: [Error 5] Access is denied: u'Z:/Alex/Shared-Projects/foo2/.bzr/branch-lock/j2robx
<Noldorin> greu.tmp'
<wgz> cute.
<Noldorin> is that informative at least?
<Noldorin> heh
<wgz> "os.getcwd()"
<Noldorin> 'Z:\\Alex\\Shared-Projects'
<wgz> okay, so, everything is sane.
<Noldorin> heh
<Noldorin> what's going on then?
<wgz> except we have created a directory, that we can't rename or remove.
<Noldorin> hah
<Noldorin> nice
<wgz> have you got process explorer installed?
<Noldorin> wgz, i *literally* just started up procexp 2 seconds before you said that :-)
<Noldorin> to check for locks
<Noldorin> by other procs
<Noldorin> heh
<wgz> right, find handles with substring "Z:\Alex\Shared-Projects"
<Noldorin> wgz, no open handles on it
<Noldorin> none at all
<wgz> okay, so that discounts the theory.
<Noldorin> permissions look fine on it to :-S
<Noldorin> hrmm
<Noldorin> wgz, interestingly i have no prob deleting it from winexplorer
<Noldorin> what credentials is bzr.exe running with?...
<wgz> the code doesn't seem to be suprising either...
<wgz> potentally not the right ones, but letting you make a dir you can't remove doesn't sound like a standard persm issue ither
<wgz> ha, I mistyped an instruction earlier, than may have confused things
<wgz> want to try the screen sharing thing? what do I need to see your desktop rather than visa versa?
<Noldorin> wgz, sure, we can do that. teamviewer is already set up here
<Noldorin> wgz, actually, mind waiting 20 minsm as i need to eat?
<wgz> go for it.
<wgz> I shall ponder in the mean time.
<Noldorin> wgz, something tells me though that because Windows Explorer can delete the dir fine but Python can't, the Samba share on the directory is confusing it. maybe the Windows shell sends a notification to the Samba server to release it before deleting
<Noldorin> *shrug*
<Noldorin> be back soon!
<roryy> should directory names in entries in dirstate (in dirstate field _dirblocks) be unicode or bytes?
<wgz> they're utf-8 bytes.
<roryy> i'm looking at bug https://bugs.launchpad.net/bzr/+bug/185211
<ubot5> Ubuntu bug 185211 in Bazaar "renaming out of directory with unicode name fails with InconsistentDelta" [High,Confirmed]
<roryy> and i've run robert collins demo script with pdb
<roryy> they look like bytes to me
<roryy> but my python-fu is not super-strong, so I may be missing something
<wgz> oh, oh man
<wgz> nice bug rorry, that repo script is hilarious
<roryy> yeah, i dunno why all those weird characters
<wgz> looks a lot like a 'safe' unicode bug
<roryy> what does that mean?
<wgz> I bet you can double-decode as utf-8
<wgz> yep, win.
<wgz> >>> b = "\xc3\x83\xe2\x80\x9e\xc3\x83\xe2\x80\x93\xc3\x83\xc5\x93"
<wgz> >>> u = b.decode("utf-8")
<wgz> >>> b2 = u.encode("CP1252")
<wgz> >>> u2 = b.decode("utf-8")
<wgz> basically, a bug due to bad handling of which encoding is used for what
<wgz> the tricky part is the failure comes after the bug has already happened
<wgz> have you tried running the script with -Ddirstate added?
<roryy> no
<roryy> ah, track dirstate activity
<roryy> interesting that u2==u in this case
<roryy> oh, hang on
<roryy> did you mean u2=b2.decode() there?
<wgz> ah yes, my error
<wgz> >>> u2 = b2.decode("utf-8")
<roryy> ok, that is saner
<wgz> >>> u
<wgz> u'\xc3\u201e\xc3\u2013\xc3\u0153'
<wgz> >>> u2
<wgz> u'\xc4\xd6\xdc'
<roryy> i thought somehow cp1252 and utf-8 had a weird equivalence
<roryy> hmm, -Ddirstate doesn't obviously output anything
<wgz> it goes in .bzr.log
<roryy> ah-ha, thank you
<wgz> I suggest cutting down the filename to the shortest thing you need to reproduce the bug, then seeing if you can track when it turns into something that doesn't match what's on disk
<roryy> the error is triggered with just one non-ASCII character in the filename
<roryy> and in the entry, i see only 'abc' for the directory name, where I expected to see u'abcÃ'
<roryy> the -Ddirstate and trace.mutter look useful; might be easier than working with pdb
<Noldorin> hi wgz
<Noldorin> back
<wgz> hey Noldorin
<Noldorin> hi
<Noldorin> any more thoughts? :-)
<wgz> only for a different bug with a similar symptom I'm afraid
<wgz> want to try some more debugging?
<Noldorin> yes please
<wgz> okay, if you pm me the id thingy let's try teamviewer
<roryy> wgz: thanks for the help.  i'm off to sleep.
<wgz> night roryy
<wgz> bug 716507 ...not completely relevent
<ubot5> Launchpad bug 716507 in Bazaar "Error when attempting to add directory containing a "junction" on Windows" [Wishlist,Confirmed] https://launchpad.net/bugs/716507
<jelmer> wgz: btw, what are your thoughts on using __future__.unicode_literals?
<wgz> it's a bad idea.
<jelmer> wgz: because string handling in python3 isn't quite right either?
<wgz> just breaks too many basic things
<jelmer> wgz: well, we'll have to deal with that at some point, if we ever want to support python3
<wgz> the number of things that need to be str/unicode are fewer than those that need to be str/str
<wgz> that's 3/2 confusingly...
<jelmer> ah, hmm
<thumper> morning
<thumper> does anyone remember a simple way to use meld to see the diff between two branches?
<thumper> or am I going to have to look it up again :)
<poolie> hi all
<wgz> hey poolie
<poolie> hi wgz
<poolie> i'm riding a pangolin
<poolie> it's bit bumpy
<poolie> but good
<wgz> yeah, the guys on thursday were talking about that too
#bzr 2012-12-10
<ychaouche> Hi. Is there a tool that graphs bazaar branches ?
<ychaouche> is that what bzr graph-ancestry does ?
<ychaouche> do
<ychaouche> mmm; not sure
<mmrazik> ychaouche: maybe bzr qlog is what you are looking for?
<mmrazik> I believe its in qbzr package
<ychaouche> mmrazik: is this a a software package or a plugin ?
<ychaouche> my distribution doesn't have a qbzr package
<ychaouche> I'll google this
<mmrazik> ychaouche: I think both. Its a plugin but on ubuntu its in qbzr package
<mmrazik> the description of the package says: Graphical interface for Bazaar using the Qt toolkit
<ychaouche> oh I have that in my plugins
<ychaouche> How to obtain that sort of diagram ? http://pastie.org/5506487
<ychaouche> I want this :http://i.imgur.com/TLHgQ.png but I only this : http://i.imgur.com/BCcqy.png
<ychaouche> I only *see* this
<jelmer> ychaouche: your history is linear, that's why it's showing it to you that way
<ychaouche> jelmer: I don't understand
<ychaouche> I created a branch right ?
<ychaouche> or maybe you mean the only way to see the graphic split in two is when there are merges ?
<ychaouche> pulls, to be more precise ?
<vila> ychaouche: you seem to look at 'bzr qlog dev', try 'bzr qlog prod dev' i.e. look at the history of both branches at once
<ychaouche> vila: thanks. I wasn't sure since I thought everything was inside the dev branch (even the prod history), but apparently it's not ?
<ychaouche> vila: but still, I see just one line not two. So I guess this type of diagrams http://i.imgur.com/TLHgQ.png only applies for merges.
<ychaouche> Right ?
<vila> since you started the dev branch from the prod branch, the history of the prod branch is part of the history of the dev branch
<vila> have you tried 'bzr qlog prod dev' ?
<vila> if you still see a "single line" try committing something to prod, you will then see two "lines"
<vila> if you then merge prod into dev, you'll see that the two histories are different (even if after the merge, the *content* is the same)
<vila> even better, if you don't want to pollute your branches, try from scratch ;)
<ychaouche> vila: thanks, I tried on a "foo" repo and saw the two branches
<ychaouche> I'll try my first merge now
<ychaouche> fake marge
<ychaouche> merge
<ychaouche> is there a bzr developer channel or is it ok to discuss plugin code here ?
<vila> ychaouche: here is fine
<ychaouche> I don't know what is causing this : http://pastie.org/5506718
<ychaouche> How do I know what branch I'm in ? bzr info doesn't give this information. I can however find something called "branch nick" in bzr log. Is this the good way to obtain the branch name ?
<jelmer> ychaouche: 'bzr root'
<ychaouche> jelmer: that gives me the current working directory actually
<ychaouche> jelmer: bzr root == pwd
<ychaouche> in my case
<jelmer> ychaouche: that directory is apparently the branch you're in
<jelmer> ychaouche: that directory is apparently the branch you're in
<ychaouche> jelmer: yes but the branche name "dev" isn't mentionned anywhere
<ychaouche> look : http://i.imgur.com/8ZMkB.png
<ychaouche> that's because I created the branch in some other place and then put a copy in where the bzr root thinks it is.
<ychaouche> look at the screenshot it explains it better
<jelmer> ychaouche: I don't see why the branch name should be 'dev'
<ychaouche> jelmer: because I created it via bzr branch prod dev
<ychaouche> so it should be nicked dev, no ?
<jelmer> the 'branch nick:' bit in the log file just means that commit was made on a branch with the nick name 'dev'
<jelmer> you can set and retrieve the branch nick with the 'bzr nick' command
<ychaouche> chaouche@fictive ~/.zdesktop/zimlets-deployed/_dev/com_feeder_sugarbee $ bzr nick
<ychaouche> com_feeder_sugarbee
<ychaouche> that's even worse hah
<jelmer> ychaouche: you can set it yourself with 'bzr nick foo'
<ychaouche> ok let me ask the question differently : suppose you have a prod branch and a dev branch. Now you go to your test server, and you have code there. The question is : how do you know if that code is from the prod branch or from the dev branch ?
<ychaouche> that's the context of my question, maybe I didn't emphasis on that much.
<ychaouche> s/much/enough/
<jelmer> ychaouche: run 'bzr nick dev' in the dev branch and 'bzr nick prod' in the production branch
<ychaouche> and then ?
<ychaouche> or let met ask the question differently again : suppose you created a branch via bzr init foo. Then you copy foo to another location (for example from your laptop to the test server). Now someone else logs in the test server. Does he have anyway of getting the string "foo" using any bazaar commands ?
<ychaouche> if he cds to that directory ? (supposed you copied it under the name baz instead of foo)
<LarstiQ> hmm, ychaouche always disappears before I get online
<jelmer> LarstiQ: he is one of your alteregos ?
<LarstiQ> jelmer: haha, no :)
<Logan_> jelmer: Hey, could you possibly do: $ requeue_package.py --full bzrtools # ?
<Logan_> I need that so that the branch can be imported properly.
<jelmer> Logan_:  sorry, I'm no longer at Canonical and thus no longer have access to jubany
<Logan_> oh, sorry about that
<jelmer> Logan_: you probably want jam, mgz_ or vila
<Logan_> or james_w :P
<james_w> Logan_, done
<Logan_> james_w: thanks :)
#bzr 2012-12-11
 * superfly hears a ping drop ;-)
<superfly> *pin
<superfly> gee, a ping dropping too?
<superfly> anyway, when someone is around, I'm getting an error between my local branch and Launchpad which talks about "different serialisers"
 * superfly goes to see if he can find the exact error message
<jam> superfly: offhand, sounds like a *really* old bzr branch, that probably needs to be updated before it can interchange with the one you have now.
<superfly> jam: I was trying to upgrade, and that's what produced this error
<jam> superfly: upgrading remotely or locally?
<superfly> here we go... bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%2Bbranch-id/40441/.bzr/) is not compatible with RemoteRepository(bzr+ssh://bazaar.launchpad.net/%2Bbranch/openlp/2.0/.bzr/) different serializers
<superfly> jam: remotely, locally went fine
<superfly> I'm using a shared repo locally, but I know LP uses stacked branches
<jam> superfly: I'm guessing it is old enough that we don't support remote upgrading. If it is on Launchpad, you can just delete it and then re-push over it from your local upgrade.
<superfly> however, what that means in practice I am unsure of
<superfly> jam: OK, thanks. I'll try that
 * jelmer waves to w7z
<w7z> hey jelmer!
<jelmer> weekending it up? (-:
<w7z> just the normal joy of hangouts being worse on nix, so need The Other machine :)
<jelmer> w7z: ah :) say hi to John for me
<mvo> hello, when I try to branch " bzr branch lp:ubuntu/lucid-proposed/unattended-upgrades" I get a somewhat odd error: "bzr: ERROR: Revision {package-import@ubuntu.com-20111212140141-7wr15t1ycq9jchl0} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))"." - does that mean the branch is damaged on the server?
<mgz> mvo: http://package-import.ubuntu.com/status/unattended-upgrades.html
<mgz> symptom of someone having futzed with the history. can generally be manually fixed, but there are a limited pool of people able to do that for you.
<mvo> mgz: thanks - so thats not smething I could fix myself somehow?
<mgz> no, but you can reproduce locally using lp:udd if you follow the setup instructions there and verify a full import works
<mgz> that's then only a question of requeuing the package with the right flag rather than some of the other cases which require more violent fixing
 * mvo nods
<mvo> thanks
<InvertedVantage> hi everyone
<InvertedVantage> I'm at work so I'll be slow but I have a question
<InvertedVantage> I'm looking to implement an SVN solution at my office to help our team manage CAD files
<InvertedVantage> I was wondering what would occur if two people were to check out the same file, modify it, and both submit said files to the server? What if they submitted them at the same time? If they submitted them one after the other?
<InvertedVantage> How does SVN and Bazaar handle this? Thank you!
<jelmer> InvertedVantage: in both situations, one would get an error saying that their tree was out of date
<LeoNerd> In bzr atl east, whoever attempts to submit second gets told their .. what he said
<jelmer> they would have to run 'bzr up' to pull in the others changes and then commit again
<InvertedVantage> cool, thank you! We have a small team here of about 5 people, all working in the same office. Any recommendations for configuring the set up?
<InvertedVantage> And how does Bazaar store previous versions? We can roll back to a previous update if we ever need to, correct?
<jelmer> InvertedVantage: yep, you can roll back
<jelmer> InvertedVantage: I would recommend having a look at the workflows chapter in the bzr docs
<InvertedVantage> thank you so much :) I'll take a look once we're done with this project. You've been a huge help!
<InvertedVantage> cheers!
<Wiz_KeeD> hey guys
<Wiz_KeeD> how do i check a branches name?
<Wiz_KeeD> how do i know where i got it from so i can bzr branch in another location?
<Logan_> bzr info
<Wiz_KeeD> yay found it in the command list in the meantime
<Wiz_KeeD> thank you!
<Logan_> No problem. :)
<Wiz_KeeD> Logan_, it says bzr+ssh://bazaar.launchpad.net/+branch/magentoerpconnect/magento-module-oerp6.x-stable/
<Wiz_KeeD> how can i download that, i see it added bzr-ssh
<Wiz_KeeD> how do i branch it on my local machine?
<Logan_> It should be lp:magentoerpconnect/magento-module-oerp6.x-stable
<Wiz_KeeD> how can you figure?
<Logan_> But you can probably just branch that full URL as well.
<Wiz_KeeD> yeah i can doo that but which full url?
<Wiz_KeeD> this is what the first one says
<Wiz_KeeD>   parent branch: bzr+ssh://bazaar.launchpad.net/+branch/magentoerpconnect/magento-module-oerp6.x-stable/
<Logan_> Actually, I just tested it, and the shorthand is lp:magentoerpconnect/magento-module-oerp6.x-stable
<Wiz_KeeD> and this is the newly branched one   parent branch: http://bazaar.launchpad.net/~magentoerpconnect-core-editors/magentoerpconnect/module-magento-trunk/
<Wiz_KeeD> why's that?
<Wiz_KeeD> now what? :-s
<Logan_> If you just go to that URL in your browser, and hit "Back to branch summary" in the top left, it will show you how to branch it.
<Wiz_KeeD> well it's the same number of revisions
<Wiz_KeeD> just different parent branch in bzr info
<Wiz_KeeD> :-s
<Wiz_KeeD> that worries me a tad
<Logan_> They're actually the same branch, just a different way to access it.
<Wiz_KeeD> all 3
<Wiz_KeeD> i thought so since it's the same revision
<Wiz_KeeD> hmm
<stewart> hi! I'm having a bit of an issue.
<stewart> We have two major versions: let's call them 1.0 and 2.0
<stewart> we have developers implement feature/bugfix in 1.0, and propose merging a 1.0 tree and a 2.0 tree into the respective trunks
<stewart> and then we merge 2.0 one first, so that 1.0 is only ever a subset of 2.0 revisions
<stewart> but... in later merging the 1.0 branch, we get a simple merge commit that then has to be merged into 2.0
<stewart> and this causing a bunch of spurious conflicts.
<stewart> I'm wondering if there's a way to avoid that?
<stewart> actually... I think that question is wrong, and I instead had the wrong branch somewhere in my script.
#bzr 2012-12-12
<mwhudson> jelmer: samba 4!?
<superfly> jam: Thanks for the advice yesterday, I am sorted.
<jam> superfly: cheers!
<mmrazik> hello. I'm using (indirectly) tarmac to merge this MP: https://code.launchpad.net/~didrocks/ubuntu-wallpapers/new-pkg/+merge/138988 and I'm getting the following trace:
<mmrazik> http://pastebin.ubuntu.com/1427031/
<mmrazik> any idea? There is a file in the branch which has u'\xf8' in the filename
<mmrazik> mhm... export LANG=en_US.utf8 did the trick
<mgz> morning!
<superfly> aloha
<jelmer> mgz: wazaa!
<mgz> kwoor
<jelmer> mwhudson: I'm as surprised as you are
<mgz> jelmer: was that the right nick?
<mgz> I missed the relevent bit of the log...
<jelmer> mgz: yeah, response to mwhudson's surprised outcry over samba 4 :)
<mgz> jelmer: should `bzr diff --old file:,branch=trunk --new file:,branch=feature` work? I can't seem to persuade it to (using merge --preview does)
<mgz> ...you've not gone and released it, surely?
<mgz> you have! shocking.
<jelmer> mgz: we have, yesterday
<jelmer> http://stationary-traveller.eu/samba-4.0.0.html
<jelmer> mgz: in theory that should work, I think
<mgz> pretty much everything else does
<jelmer> mgz: you know about the co: syntax in 2.6?
<mgz> nope, have been using file:,branch=
<mgz> co: is an alias for that?
<jelmer> yep
<mgz> I'd say I didn't see the merge proposal, but I probably approved it, then forgot since
<jelmer> I think that might be the case
<ychaouche> Hi. I'm still looking for a way to know which branch I'm in. https://answers.launchpad.net/bzr/+question/216485
<mgz> ychaouche: `bzr info` tesll you
<ychaouche> mgz: it doesn't : http://pastie.org/pastes/5515023/text
<mgz> ...you're question isn't really specific enough then
<mgz> what exactly is the directory you're running that in?
<mgz> because after your example commands what you have is two directories in the cwd, one named 'dev' and one named 'prod'
<mgz> the branch you're in is neither of those, so, where did it come from?
<ychaouche> mgz: it's a copy of dev
<ychaouche> a physical copy, created with the cp command
<mgz> then the way you tell which branch it is, is it's the one you copied...
<ychaouche> cp ~/REPOS/BZR/sugarbee/dev ~/.zdesktop/zimlets-deployed/_dev_com_feeder_sugarbee
<ychaouche> mgz: that was not my original question
<ychaouche> I'm anticipating when code is put on the test server by someone else
<mgz> if you copy an abitrary directory structure, you can't tell apart from by inspection what it ise
<ychaouche> mgz: is there another way then ?
<ychaouche> a way to track branches ?
<mgz> the answer you want is probably to not use cp, but create an actual branch or checkout
<ychaouche> checkout
<ychaouche> ok
<mgz> eg, `bzr checkout --lightweight ~/REPOS/BZR/sugarbee/dev ~/.zdesktop/zimlets-deployed/_dev_com_feeder_sugarbee`
<ychaouche> ah ok
<mgz> and use `bzr update` to update it, or `bzr switch` to change the branch being used
<ychaouche> mgz: with my current setup (physical copy), suppose If i'm commiting something in the destination branch, it won't be commited also in the source branch, right ?
<ychaouche> because for bzr there's no relation between them
<mgz> right.
<ychaouche> good
<ychaouche> so i'll use physical copy back to the source, to simulate a commit, and then use checkout on the destination branch again to do things right.
<mgz> the correct way of doing that (temp hacks to live etc) would be to `bzr switch -b ~/REPOS/BZR/sugarbee/livehack` first
<mgz> in the checkout
<mgz> then you can commit without affecting trunk/whatever you're running from
<mgz> but also integrate the change back if needed later
<ychaouche> mgz: on the contrary, I want them to affect each other
<ychaouche> I want to replicate the svn way of doing things, for now. I know I can easily change the workflow later because it's easy to decentralize.
<mgz> in which case, the lightweight checkout already does what you want by default
<mgz> remember to run `bzr update` on both sides if you have two trees though
<ychaouche> mgz: no just one tree
<ychaouche> oh sorry no two working trees
<ychaouche> I'm not used to terminology yet ^^
<ychaouche> but since I'm checkouting from a branche, doesn't commiting in the checkouted branch also commits to the original branch ?
<ychaouche> I'll just have to update
<ychaouche> ok
<ychaouche> sorry, I'm a bit slow
<mgz> no problem :)
<ychaouche> yeah I didn't realize that the original branch is also a working tree, so it needs to be updated.
<mgz> see for reference: http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/core_concepts.html
<mgz> you can create those branches without trees (or remove the trees) if you want to be closer to the centralised model, depends if you have seperate deployment and development workspaces or want one tree for everything
<ychaouche> I'll answer you in a second, I have a question first : the help for the checkout command says with the --lightweight option the usual operations need access to the original branche, so I'm loosing the decentralizing work here. Right ?
<ychaouche> I want to keep my working tree "local"
<ychaouche> decentralized, and then "merge back" or I guess "push" to the branch I checkouted from
<ychaouche> I want to simulate a decentralized environement on my own machine, to be able to reproduce those operations when going test/live
<ychaouche> mgz: yeah I read the user-guide and the 5 minute intro already.
<ychaouche> But I'll read the lightweight checkout again.
<ychaouche> http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/using_checkouts.html#getting-a-lightweight-checkout
<ychaouche> and stacked branches
<mgz> ignore stacked branches, they're not what you want :)
<mgz> you can use checkouts in tandem with a decentralised workflow, it's just if there's *only* one branch and everything else is a checkout that you lose the win
<ychaouche> I'm not sure to fully understand what push does. Does it create an exact copy of the branch to another location ?
<ychaouche> It seems that in bazaar, every working tree is a branch
<mgz> it transfers data from the respository and updates the branch pointer to the same as the local branch
<mgz> it does not change the remote working tree, if one exists
<mgz> and no, working tree and branch are seperate concepts
<mgz> by default when you branch something you get all three of repository, branch, and tree
<ychaouche> mgz: this is how I intend to work http://i.imgur.com/T0uO7.png, in an answer to your previous question about wether I want centralized or decentralized model.
<ychaouche> Any comments appreciated, especially on how to improve this process if possible
<ychaouche> brb : lunch
<j^> so bzr not does ssl verification without SNI support? thats sad
<mgz> I can't parse that...
<mgz> ychaouche: you probably just want to deploy to the test server using bzr-upload or something and not have any branches actually living there
<j^> mgz: SNI = Server Name Indication allows multiple https vhosts per ip
<ychaouche> mgz: suppose I use bzr-upload or just plain tarball deploying to the test server without having any branche there. Suppose I make a hotfix on the testserver. How can I merge those hotfixes back to the prod branch ?
<ychaouche> A merge obviously doesn't work : http://pastie.org/pastes/5515954/text
<ychaouche> cfsb was created with a bzr export --format=tgz
<ychaouche> mgz: besides, if I'm not using a branche in the test server, we're back to the beginning of our problem which is : how do I know what branch is it ? dev or prod ? :)
<ychaouche> that's why I imagined having also a REPO in the server
<ychaouche> inside the repo, the name of the name of the folder IS the name of the branch, so I know at any given time what branch is in what directory. In the /srv/www/, the folder containing the branch is names arbitrarily, so the only way I know which branch it contains is when I'm checkouting from the local repository.
<ychaouche> I hope that explains a little better what I'm trying to do and what problems I'm addressing.
<ychaouche> so you can parse the diagram ;)
<jlf> good morning #bzr, i've been trying to find out how to show all files that were changed in a particular commit but i didn't see anything applicable in `bzr help commands' or the man page.  can anyone enlighten me?
<jpds> jlf: Sounds like: bzr status -r $REVISIONID.
<jlf> doesn't that show the state of my current tree with respect to $REVISIONID?
<mgz> jlf: if you pass a revision range (or use -c $REV) it's like a diff across those revisions
<mgz> ooh, and a bug... requires a working tree even when it doesn't
<jlf> mgz: that does it, thank you
<jlf> jpds: and thanks to you as well
<mgz> bug 392391
<ubot5> Launchpad bug 392391 in Bazaar "bzr status with a revision range requires a working tree" [Medium,Confirmed] https://launchpad.net/bugs/392391
<ychaouche> Need advice on establishing a good workflow https://answers.launchpad.net/bzr/+question/216615, please leave a message there. I have to go home now.
<ychaouche> TIA
#bzr 2012-12-13
<prophetadam> hey need some help setting up SSH2 for launchpad and bzr explorer as my pushs arne't working, would be much appreciated.
<prophetadam> using windows error message is: Run command: bzr push bzr+ssh://bazaar.launchpad.net/+branch/avaneya/
<prophetadam> Connected (version 2.0, client Twisted)
<prophetadam> bzr: ERROR: Connection error: Unable to authenticate to SSH host as
<prophetadam>   prophetadam@bazaar.launchpad.net
<prophetadam> supported auth types: ['publickey']
 * KombuchaKip waves at prophetadam
<prophetadam> hey!
 * prophetadam says hi!
 * prophetadam nods head
<prophetadam> i gotta go
<prophetadam> ill leave up.
<prophetadam> catch ya man
<prophetadam> woops wrong window
<prophetadam> any help would be great cheers.
<prophetadam> have since fixed problem, thanks anyways
<ychaouche> Hi. Is it possible to setup a completely serverless environement in a team ?
<hongyun> When push codes using bzr , there always shows an error:bzr: ERROR: Don't know how to handle SSH connections. Please set BZR_SSH environment variable. Can some one help?
<hongyun>  When push codes using bzr , there always shows an error:bzr: ERROR: Don't know how to handle SSH connections. Please set BZR_SSH environment variable. Can some one help?
<mgz> hongyun: if you run `ssh -V` what does it say?
<LarstiQ> ychaouche: sure
<ychaouche> LarstiQ: bbl lunch
<ychaouche> LarstiQ: in the meantime, I'm trying to simulate this on my own machine and document it in a text file, step by step http://i.imgur.com/0cElN.png
<ychaouche> any comments appreciated
<ychaouche> bbl lunch
<ychaouche> yaaay :) http://pastie.org/5520813
<ychaouche> How it happend https://gist.github.com/raw/4277273/5869a6c717b7ee59eee77f011ec745403bed0564/bzr-tut.txt
<ychaouche> So, how to solve the problem "cannot commit to branch X . It is bound to Y which is bound to Z" ?
<LarstiQ> ychaouche: do you have some more context for that?
<LarstiQ> ychaouche: one case I know of that occuring is with circular bindings
<ychaouche> LarstiQ: I think I have an idea. I copied a checkout to antoher location and checked out that checkout to yet again another location.
<LarstiQ> right
<LarstiQ> ychaouche: I'd recommend only checking out from branches, not other checkouts
<LarstiQ> while it can be done..
<ychaouche> So what I'll do is copy the branch to a location, then checkout that branch to another location.
<ychaouche> Right.
<ychaouche> Let me try that.
<LarstiQ> ychaouche: also, I'd bzr push/pull instead of using cp
<ychaouche> LarstiQ: push/pull needs internet connection on remote machines
<LarstiQ> ychaouche: no
<ychaouche> hum ?
<LarstiQ> ychaouche: you can also do it from and to a usb stick say
<ychaouche> LarstiQ: what would you put in the usb stick, a whole branch ?
<LarstiQ> ychaouche: yup
<ychaouche> I want to work that way (instead of usb key, download a tarball)
<LarstiQ> ychaouche: how do others get your work?
<ychaouche> LarstiQ: I'd like to give them tarballs by email
<ychaouche> the tarball contains my branch
<LarstiQ> righty
<ychaouche> they put in a temporary location
<ychaouche> and then merge to their branches
<LarstiQ> ychaouche: you might want to look at `bzr send -o`
<LarstiQ> ychaouche: so that you do not have to mail around entire branches
<LarstiQ> ychaouche: a bit more bookkeeping perhaps
 * LarstiQ heads home
<ychaouche> I think I'll learn how to use bzr send. I can't understand how to use bzr pull and bzr push yet.
<ychaouche> Is pull the equivalent of checkout + merge ?
<ychaouche> and push the equivalent of commit + merge ?
<ychaouche> no it's confusing.
<ychaouche> I don't know how to use send. It asks for a destination branch. Why is a destination branch required sincie I want to send my merges by e-mail anyway ?
<jelmer> ychaouche: it needs the destination branch to determine which revisions to include
<ychaouche> jelmer: then I really don't understand how to use it. I thought the context was : I'm working on a branch, a team member on a different location is working on the same branche and I want to *send* him my changes, my commits. So I'd use the send command, which would create "something" and I would send that guy that thing so that he could merge it to his own branche/checkout.
<ychaouche> anyway I have to go, I'll ask the same question next week :;(
<ychaouche> thanks to all who helped me today and happy week-end.
<jelmer> ychaouche: you would generally use it to send changes against a common mainline
<mortrca> I'm trying to run the bzr-email plugin, but I'm getting an error message "Unable to load 'bzr-email' in '/usr/lib64/python2.6/site-packages/bzrlib/plugins' as a plugin because the file path isn't a valid module name; try renaming it to 'email'."
<mgrandi> have you tried doing that?
<mortrca> I'm not sure what to rename to "email"
<mortrca> I renamed the directory (which was previously bzr-email)
<mortrca> and ran "sudo python setup.py install" again
<mortrca> but I'm still getting the error
<mortrca> Is there something else that I'm supposed to rename?
<mgrandi> i think its installing it to /usr/lib64/ blah blah to bzr-email
<mgrandi> try renaming the folder in that directory to email
<mortrca> mgrandi: I see two directories there, bar-email and email
<mortrca> Should I just remove the bar-email one?
<mortrca> *bzr-email
<mgrandi> yeah, try that
<mgrandi> save it to desktop incase you need it
<mortrca> mgrandi: Now I'm getting "Key 'upload_auto' already registered"
<mgrandi> so you are on linux, right, what os?
<mortrca> CentOS
<mgrandi> is there not a bzr email package?
<mgrandi> hmmm
<mgrandi> one sec
<mortrca> I don't believe so.
<mortrca> Do you know what that means?
<mgrandi> figuring it out
<mortrca> I don't know if that means it isn't working or if its just trying to be polite by informing me that "Key 'upload_auto' already registered"
<mortrca> mgrandi: I know now, it isn't working.
<mgrandi> one seccc
<mgrandi> so the ubuntu package seems to install it to
<mgrandi> drwxr-xr-x root/root         0 2012-05-29 01:55 ./usr/share/pyshared/bzrlib/plugins/email/
<mgrandi> so its supposed to be in 'email'
<mgrandi> can you paste the entire stack trace?
<mortrca> Sorry, you'll have to give me directions.
<mgrandi> so how are you getting the error?
<mgrandi> you install and it gives you that error?
<mortrca> "bzr plugins" returns an entry "email"
<mortrca> No, installation doesn't return any errors
<mgrandi> ok
<mgrandi> so where do you get key is already registered?
<mortrca> It only returns that message when it is doing something that should result in an email getting sent.
<mgrandi> ok, can oyu paste your bzr.log to somewhere? its in ~/.bzr.log
<mgrandi> like bpaste.net
<mortrca> mgrandi: hold on
<mortrca> mgrandi: http://bpaste.net/show/64267/
<mortrca> I don't know why it is trying to load "upload"
<mgrandi> yeah, thats a completely different plugin...
<mgrandi> apt says: bzr-upload - Bazaar plugin for uploading to web servers
<mortrca> I don't have or want that plugin
<mortrca> there isn't a directory in /usr/lib64/python2.6/site-packages/bzrlib/plugins called bzr_upload
<mgrandi> "/usr/lib64/python2.6/site-packages/bzrlib/plugins/bzr_upload/__init__.py
<mgrandi> does that exist?
<mgrandi> it says it does..
<jelmer> mortrca: the upload plugin needs to be in a directory called "upload", not "bzr_upload"
<mgrandi> why did it get installed to that directory then?
<mortrca> I figured it out.
<mortrca> I removed the stray bzr_upload plugin
<mgrandi> or just rename ot to be upload
<mgrandi> to*
<mortrca> and after renaming bzr-email to email again (running "setup.py install" changed it back) it isn't throwing any errors.
<mgrandi> yay!
<mgrandi> how did bzr get installed? why is it naming plugins wrong
<mortrca> I installed it from source
<mgrandi> well why is the source naming it wrong o.o
<mortrca> Is that a rhetorical question?
<mgrandi> well, no, i mean it installed the plugins worng and then it didn't work, you think it wouldn't do that
<mgrandi> haha
<mgrandi> but anyway glad you got it working
<mortrca> mgrandi:
<mortrca> oops
<mortrca> It isn't working
<mgrandi> what isnt?
<mortrca> mgrandi: I'm getting errors now
<mgrandi> what errors
<mortrca> I had "post_commit_sender = user@example.com" in branch.conf
<mortrca> (with a real address)
<mortrca> But when I tried to commit I got: "From: user@example.com: No such file or directoryanch - Stage:Fetching revisio..
<mortrca> bzr: ERROR: Server sent an unexpected error: ('error', 'BzrError', 'Failed to send email: exit status 1')"
<mgrandi> post the bzr log again, it gives more specific errors =P
<mgrandi> thx~
<mortrca> mgrandi: http://bpaste.net/show/64271/
<mgrandi>         result = self.config.get_user_option('post_commit_mailer')
<mgrandi> i think its failing cause you dont have a 'mailer' set up
<mgrandi> so its defaulting to 'mail'
<mgrandi> so set the program you want to use to mail in the conf file under post_commit_mailer
<mortrca> mgrandi: Why wouldn't 'mail' work?
<mgrandi> do you have mail installed?
<mortrca> Yes
<mortrca> and I have successfully sent emails with it
<mortrca> mgrandi: I need to go, but if you have any ideas I'll read them when I get back.
<mgrandi> i would try seing if invoiking mail manually does it
<mgrandi> mail -s "subject" -a "from: john doe" then typing it into stdin
<mgrandi> or try setting post_commit_mailer to smtplib
<mortrca> mgrandi: What do you mean by "typing it into stdin"?
<mgrandi> I would just try setting it to be smtplib, its built into python
<mgrandi> The reason its not working is that mail is returning a status code of "1", so its not completing correctly..
<mortrca> mgrandi: It worked.
<mortrca> I didn't get an error message
<mortrca> and I did get an email.
<mgrandi> by changing it to use stmplib?
<mgrandi> smtplib*
<mortrca> yes
<mgrandi> yay =)
<mortrca> Thank you so much
<mgrandi> yeah, i dunno much about mail, but it wasn't working i guess
<mortrca> You've been very patient.
<mgrandi> happy bzr-ing! =)
<mortrca> Thanks
#bzr 2012-12-14
<qengho> Hi ho. Suppose that a dozen commits ago I screwed something up, and I'd like to go repair it.  What's the best way?
<mgz> generally, just fix it and commit
<qengho> Yeah, I could append a new change, but if Joe wants to take only the first five commits, he doesn't get my fix that's on the end.
<mgz> if it's something along the lines of "accidentally committed your password" then, then you probably need to rewrite history
<qengho> I think I can do it with some ugly (bzr uncommit; bzr shelve -m ...;) and (bzr unshelve; bzr commit -m...), but getting the log message in and out isn't automatic, sadly.
<mgz> your joe example is the same regardless. people with older versions of software don't have the bug fixes (and bugs) since then
<LeoNerd> You can possibly pull it out a bit via   LOGMESSAGE=$(some scriptery here $(bzr log --line -r-1)); bzr uncommit; bzr shelve -m $LOGMESSAGE
<mgz> with dvcs you generally assume people know to pull
<qengho> There's no one else with the commits I'm talking about, mgz.
<mgz> what I'd do to rewrite is just `bzr branch -rLASTGOOD trunk pristine && bzr merge -rLASTGOOD..-1 -d pristine trunk` then fixup the changes and commit with a summary message noting it's a history rewrite
<mgz> if it's my own branch, I generally don't care too much about the intermeduary commits and their messages, but it's reasonably trivial to preserve them via a little scripting as LeoNerd suggested
<mgz> you just do -rLASTGOOD..(LASTGOOD+1) as the cherrypick+fixup then replay the subsequent changes afterwards
<mgz> the `bzr replay` command provided by rebase is enough for that
<mgz> sorry, bzr-rewrite
<qengho> Thanks, guys.
<mgz> having two branches is helpful because if you screw up you just nuke the new one and try again.
<LeoNerd> Yah.
<qengho> Not perfect, but a first try on pushing/popping.  lp:~cmiller/+junk/bzr-pushpop
#bzr 2012-12-16
<JPeterson> how do i show the last x log entries?
<JPeterson> ok when its more than what the branch contains it shows only the branch for the oldest entry
<JPeterson> bzr branches list only "* (default)" how do i show the diff with the main branch "branch nick: calibre"
<JPeterson> from "branch nick: repo"
<JPeterson> bzr log -r-2 show only the second to last commit
<JPeterson> ok i have to use bzr log -l2
<Enlik> when I needed to view difference between branches, I used (according to bzr diff --help) diff --old XXX --new XXX
<JPeterson> i SIGINTed a bzr commit and now bzr commit hangs without a messages, as if its waiting for stdin, but it doesnt seem to be
<JPeterson> because it doesnt read stdin
<JPeterson> bzr break-lock -v returns nothing
<JPeterson> also hangs
<Enlik> send some other signal to all of that process maybe (I'd try QUIT). And hope that interrupting bzr commit didn't break anything.
<JPeterson> a manual rm -rf .bzr/branch/lock/held released the lcok
<JPeterson> i cant figure out how rebase works from bzr rebase --help
<JPeterson> i want to edit the second to last commit
<JPeterson> i tried
<JPeterson> bzr rebase -r-2 .
<JPeterson> that returns
<JPeterson> Base branch is descendant of current branch. Pulling instead.
<JPeterson> here are the commands and question http://pastebin.com/9SFmWbUC
<jelmer> JPeterson: rebase doesn't allow you to edit commits, it just replays your current branch on top of another branch
<JPeterson> jelmer: how do i edit commit 2 in that example=?
<jelmer> JPeterson: what do you mean with "edit" exactly?
<JPeterson> change code or message
<jelmer> JPeterson: uncommit
 * jelmer gets some sleep
<JPeterson> jelmer: i tried bzr uncommit --force -r-3 as in the updated paste http://pastebin.com/9SFmWbUC but i don't know how to --continue and apply the following commits
<JPeterson> and i dont know how do i apply the message after uncommit
<JPeterson> i guess if there are no feature as easy to use as git rebase -i i will accept a more verbose commit history, for example with single letter follo up commits
<portablejim_> I am a git user that is trying out bzr. I have a repository set up with a trunk dir for the single branch I have. I want to clone/branch the whole repository. Is it as simple as creating the folder(s) then branch'ing the remote trunk in? Or is a bzr init-repo needed?
<bob2> can't parse that
<bob2> but 'bzr branch' only branches one branch
<bob2> if you want git-ish behaviour, may want multi-pull
<portablejim_> I have ./burncontrol/trunk/<stuff> . ./trunk is the branch. Is ./burncontrol special?
<bob2> "bzr branch ./burncontrol/trunk/ /tmp/bonghits" will clone trunk
<bob2> I don't know what you did to ./burncontrol
<bob2> maybe you made it the repo root
<portablejim_> A bzr init-repo.
<portablejim_> Ok, so I have a shared repository.
<portablejim_> From my research, to "clone" the repo I 1) bzr init-repo /new-path/burncontrol 2) run 'bzr branch' for each branch into the shared repo?
<portablejim_> Do I have to set up every computer I want to pull from as a server? (it is unnecessary with git)
 * portablejim_ fixes url and it works.
<ychaouche> Hi. Suppose I give a tarball with a .bzr in it. Do you have any means of determining wether I've given you a branch or a checkout ?
<lifeless> bzr info
<ychaouche> lifeless: http://pastie.org/5538133. Is that a branche or a checkout and how can you tell ?
<ychaouche> standalone tree => not checkout ?
<ychaouche> ah yes
<ychaouche> here it says checkout : http://pastie.org/5538137
<ychaouche> thanks lifeless
<lifeless> np
#bzr 2013-12-12
<Wiz_KeeD> hey guys
<Wiz_KeeD> anyone on?
<beuno> Wiz_KeeD, what's up?
<Wiz_KeeD> beuno, hello, nice to see someone up
<Wiz_KeeD> I am developing a python deployment script using fabric and I can issue ssh commands easy.So I wouldn't need the push-and-update plugin as I can run commands on ssh easy, but I would need to extract data like parent address and etc, read with the language and run the command
<Wiz_KeeD> I discovered I can do locally bzr push :parent
<Wiz_KeeD> which should push things up to the parent branch, but updating I cannot do from local I need to ssh and execute a command from the server like bzr update path?
<beuno> Wiz_KeeD, so you want a tree on the other end?
<Wiz_KeeD> yes beuno
<Wiz_KeeD> it is there I just need to update it
<Wiz_KeeD> sort of push my local modifications from localhost to server
<beuno> Wiz_KeeD, yeah, you would need to trigger anything related to the tree locally
<beuno> depending on what you want, you can use bzr-upload
<beuno> if you *just* want the tree
<Wiz_KeeD> how do I get the path from local to run it on remote
<Wiz_KeeD> hmm, what does bzr-upload do?
<beuno> it just uploads the tree
<beuno> but not the bzr metadata
<beuno> so it's used to deploy to servers, where you don't want your history
<Wiz_KeeD> oh and I keep getting bzr: warning: unsupported locale setting
<Wiz_KeeD> on everything I run
<Wiz_KeeD> beuno, that sounds nice but i need history as well as a backup method
<Wiz_KeeD> not like it takes up too much space you know
<Wiz_KeeD> bzr: ERROR: exceptions.AttributeError: 'RemoteRepository' object has no attribute 'get_ancestry'
<Wiz_KeeD> help :(
#bzr 2013-12-13
<Wiz_KeeD> hello guys, can someone help with this annoying error message?
<Wiz_KeeD> bzr: warning: unsupported locale setting
<Wiz_KeeD> could someone please help out with this issue? http://pastie.org/8549634
<Wiz_KeeD> Or can someone tell me how I can get the parent location from bzr?
<Wiz_KeeD> can anyone help please?
<Wiz_KeeD> AttributeError: 'RemoteRepository' object has no attribute 'get_ancestry'
<Wiz_KeeD> on bzr push-and-update
<jelmer> Wiz_KeeD: get_ancestry was removed in bzr 2.6 IIRC
<Wiz_KeeD> jelmer, I JUST read that
<Wiz_KeeD> how can I solve it? I am inside the plugin and can edit the code and the line that brings issues, though idk how to retreive the info
<jelmer> Wiz_KeeD: the easiest thing to do is probably to hunt down an old version of bzr and copy the implementation of get_ancestry from that
<Wiz_KeeD> ugh...i wouldn't know where to put it
<Wiz_KeeD> So not editing the plugin you recommend
<Wiz_KeeD> I have a laptop with 12.04 and a bzr version that works
<jelmer> Wiz_KeeD: you can copy the logic into the place where bzr-push-and-update is doing the get_ancestry call
<Wiz_KeeD> https://code.launchpad.net/~jelmer/bzr/rm-get-ancestry
<Wiz_KeeD> where do I find it jelmer ?
<jelmer> Wiz_KeeD: yes, that's the branch that removes it
<jelmer> another alternative is the reverse-apply that branch to your local copy of bzr
<Wiz_KeeD> i didn't get that last one
<Wiz_KeeD> are you the founder of bzr?
<Wiz_KeeD> or just a very dedicated and active developer?
<jelmer> Wiz_KeeD: no, I'm not one of the founders
<jelmer> I was a very active developer for a while
<Wiz_KeeD> AH I think i saw a launchpad post withyou saying that you are not involved anymore in the project, why is that?
<Wiz_KeeD> Hmm That branch just removes it I don't see the functionality that replaces it
<jelmer> Wiz_KeeD: see https://stationary-traveller.eu/pages/bzr-a-retrospective.html
<Wiz_KeeD> Could you help me patch the plugin or port the method into bzr 2.6? it's just a line I think
<jelmer> Wiz_KeeD: you can undo the removal by reverting that branch
<Wiz_KeeD> jelmer, but there might be a lot of speed improvements in 2.6
<Wiz_KeeD> and it's just one functionality for one plugin, I need nothing more
<jelmer> Wiz_KeeD: you can revert that individual branch
<jelmer> Wiz_KeeD: not sure if that will work cleanly though
<Wiz_KeeD> why's that?
<Wiz_KeeD> it's just used in one single place in the plugin
<jelmer> Wiz_KeeD: I'm not sure I follow
<Wiz_KeeD> http://pastie.org/8549733
<Wiz_KeeD> all I have to do is fix that line and the push-and-update plugin will work
<Wiz_KeeD> or at least I hope it will
<jelmer> Wiz_KeeD: yes, but fixing that line requires replacing it with another 5 or 6 lines
<jelmer> Wiz_KeeD: basically, with the code that was in the get_ancestry() function I removed
<Wiz_KeeD> ugh...
<Wiz_KeeD> damn
<Wiz_KeeD> well i'm stuck then
<jelmer> Wiz_KeeD: have you filed a bug? it shouldn't take more than 30 minutes to fix for a bzr dev
<Wiz_KeeD> I did
<Wiz_KeeD> pfff only two people work on that plugin
<Wiz_KeeD> https://bugs.launchpad.net/bzr-push-and-update/+bug/1260700
<ubot5> Ubuntu bug 1260700 in Plugin to Update Remote Trees "get_ancestry call removed in bzr 2.6 not updated for plugin" [Undecided,New]
<Wiz_KeeD> Maybe I can find  a temporary solution for this until it gets fixed jelmer ?
<jelmer> Wiz_KeeD: avoid using the plugin, but just run "ssh foo bzr up" manually?
<Wiz_KeeD> bzr up?
<Wiz_KeeD> update
<Wiz_KeeD> Hmm, I have a python script with fabric that does the push and update, but I need to get the location of the push branch in order to cast update on the server
<Wiz_KeeD> withou grepping and exploding the string and such?
<Wiz_KeeD> thank you for your help jelmer !
<Wiz_KeeD> out of curiosity, why did you quit?
<Wiz_KeeD> :)
<Wiz_KeeD> Can anyone tell me how to update a branch to the current revision
<Wiz_KeeD> bzr update updates the tree but that's it
<Wiz_KeeD> ah wait...
<jelmer> Wiz_KeeD: bzr pull
<jelmer> Wiz_KeeD: for that, see the page I linked earlier: https://stationary-traveller.eu/pages/bzr-a-retrospective.html
<Wiz_KeeD> I used push
<Wiz_KeeD> it gives the annoying message that the tree is not updated byt m3h...
<Wiz_KeeD> until this gets fixed https://bugs.launchpad.net/bzr-push-and-update/+bug/1260700
<ubot5> Ubuntu bug 1260700 in Plugin to Update Remote Trees "get_ancestry call removed in bzr 2.6 not updated for plugin" [Undecided,New]
<Wiz_KeeD> best I can do
<jelmer> Wiz_KeeD: sorry
<Wiz_KeeD> jelmer, for what?
<jelmer> Wiz_KeeD: not being able to help further
<Wiz_KeeD> it's okay you helped a lot
<Wiz_KeeD> Hope someone will get notified and fix it
<jelmer> (and being the person who removed that function in the first placE)
<Wiz_KeeD> if it scales bad and is a general bad idea to use, having code based on it is a bad idea
<scientes> how do i apply a bzr merge directive in git?
<scientes> === modified file 'cmdline/apt-get.cc'
<scientes> error: apt-get.cc: No such file or directory
<scientes> ./cmdline/apt-get.cc
<scientes> doesn't even apply with patch...
<jelmer> scientes: patch -p0 ?
<scientes> yeah turned out it was upstream churn
<scientes> thanks
#bzr 2013-12-15
<Guest76801> does someone knows why does it happens ?
<Guest76801> bzr: out of memory / Fetching revisions:Inserting stream:Estimate 210/39
<Guest76801> Use -Dmem_dump to dump memory to a file.
<SpacedOut> I'm new to bzr and confused, `bzr branches` always prints '* (default)', how can one checked out source tree hold multiple branches?
<SamB> SpacedOut: magic
<SamB> SpacedOut: it MIGHT be the "colo" plugin, or it might be something in core; I'm not too clear on the exact state of migrating that functionality into core
<SpacedOut> SamB: I'm used to git and being able to bounce between branches easily.  How about the command for bzr?  I tried `bzr init-repo base` and checked out something to different directories already.
<SamB> SpacedOut: also are you aware that bzr development is MUCH slower than it used to be? There have only been 17 merges to trunk in this entire year, according to "bzr log lp:bzr | less"
<SpacedOut> SamB: no I'm only using bzr to build a package from launch pad.  I tried git a long time ago and got hooked.
<SamB> ah
<SamB> SpacedOut: I seem to remember a "bzr switch" command existing
<SpacedOut> SamB: For comparison I count 23 releases for git in 2013, that doesn't count -rc tags either.
<SamB> heh
<SamB> as if comparing against bzr in 2012 wasn't bad enough!
#bzr 2014-12-08
<mark06> how can I mirror bzr commits to a git repository automatically?
<mark06> actually, I have a server with git repos that are mirrors of bzr branches
<mark06> I want a cron or similar that will automatically pull from bzr then push to github
<mark06> is there any existing solution for this, or do I need to write my own thing?
<mark06> main problem for me is ssh key password, I want the process to be automated
<mgrandi> i have a bzr plugin that just does a dumb commit to git on the post_commit hook
<mark06> how exactly "to git"
<mgrandi> currently bzr-git needs to be fixed to be used with bzr-1.6 to use the bzr dpush thing
<mark06> my git mirrors of bzr branches use git-bzr-ng already  https://github.com/termie/git-bzr-ng
<fullermd> I go the other way for stuff, and use git-bzr-ng (I think?) to mirror.
<mark06> indeed I use it, but as I said I want to automate the mirroring
<mgrandi> thats probably better then what im doing
<fullermd> Well, you just cron it...   what more do you need?
<mgrandi> all i'm doing is exporting to a folder then calling 'git commit -m '<>'
<mark06> fullermd: a working solution
<fullermd> Oh, well, I'd never thought of THAT   :p
<mgrandi> post commit hooks aren't terribly hard to write
<fullermd> What fails in it?
<mark06> fullermd: it's not that simple, I'll show you the script I'm writing in case I don't find an existing solution
<mark06> fullermd: http://vpaste.net/sMHhm
<mark06> I could put this in cron, but as I said above, I can't
<mark06> crond will get stuck reading ssh key password
<mgrandi> seems like you just need to fix that
<fullermd> Eh.  If an automated process needs access to a key, don't passphrase the key.
<mgrandi> and will have the same problem with bzr
<mgrandi> can you not have the agent remember the password? its different on every operating system...
<mark06> so I need to create a separate ssh key just for this cron job, then add to both launchpad and github, right?
<mgrandi> putty on windows asks for password at startup and then you don't need to remember it
<mgrandi> err type it
<mark06> the server is ubuntu
<mark06> yes I use putty on windows for both git and bzr
<mark06> if server reboots suddenly then mirror will stop working until I run ssh-agent again, if I would keep it running with cached key
<mark06> so in sum, the separate ssh key is the way to go here?
<fullermd> I'd say.  's just like passphrased SSL cert/keys; unless you want to manually intervene in any [re]start of the server, you just don't do it.
<mgrandi> or have ssh agent load the password from a file, if it can do that
<mark06> 's?
<fullermd> That would be pointless; if the passphrase is sitting around in the clear, it's no different than an unphrased key from a security perspective, so it just adds fragility and possible dangerous-illusion.
<fullermd> "It's" is way too long to type, so I contractify the contraction   :p
<mark06> yeah I'm worried about unprotected key, specially because it will give access to all my launchpad and github repos.... I wanted it to have access only to the repos I'm mirroring
<mark06> ah wait, not for launchpad
<mark06> I just pull from launchpad
<mgrandi> i dont think even github allows 'restricted' access for a ssh key
<mark06> yeah this is why I'm worried
<mgrandi> if it makes you feel any better this is just a problem with ssh, not necessarily any VCS =P
<mark06> it's so easy for them to implement
<fullermd> You could always just use rsh instead; then you don't have to worry about passphrasing keys.
<mark06> I don't care where the problem is
 * mark06 looks up rsh
<fullermd> ... well, that takes all the fun out of saying it...
<mark06> grr tldr http://en.wikipedia.org/wiki/Restricted_shell
<fullermd> Nah, http://en.wikipedia.org/wiki/Remote_Shell
<mgrandi> well if you have a passphrased key, then its still protected by your local login password
<mgrandi> if you set the permissions to be not world readable
<mgrandi> although that works for pass-less keys too
<fullermd> Vulnerable to root, or a root crack.  Also backups provide an attack vector.
<fullermd> Fortunately, that one can be closed by the simple expedient of not doing backups   :)
<fullermd> Widely adopted security mechanism, that.
<mgrandi> yeah, either way if they have local access you are screwed either way
<mgrandi> and its 4 am, why am i even up
<fullermd> Why wouldn't you be?  Heck, the sun isn't even up yet.
<mgrandi> well the sun is stupid
<mgrandi> stupid sun
<mgrandi> what have you ever done for me
<fullermd> Hey, it's done PLENTY for me!  I've had some nasty sunburns over the years...
<fullermd> Wait, maybe that's more "to" than "for".
<mgrandi> i live in a place where its sunny like 300+ days of the year
<mgrandi> IM OVER THE SUN
<mgrandi> but i need to get to bed, best of luck mark06
<mgrandi> peace
#bzr 2014-12-10
<mark06> why can't I make git bzr pull work here? see third repo http://vpaste.net/zPNEM
<mark06> it seems random, sometimes all repos will fail, but third one always fail when updated together with the oher tow
<mark06> *two
#bzr 2015-12-08
<anishkulkarni98> iam unable to use bzr on windows 10. new to bzr and launchpad
<anishkulkarni98> iam unable to use bzr on windows 10. new to bzr and launchpad
<anishkulkarni98> hello btw
#bzr 2016-12-14
<HomHomer> Quick question, can I install Bazaar with pip?
<HomHomer> Latest version is 2.7.0
<HomHomer> PyPI shows 2.6.0
<HomHomer> https://pypi.python.org/pypi/bzr/2.6.0
<HomHomer> I would like to thank Ubuntu for making a beautiful installer for Windows
<HomHomer> I have Python 2.7 and when I try to install Bazaar without Python bundle, it says it can't detect Python 2.7
<HomHomer> :)
<HomHomer> https://usercontent.irccloud-cdn.com/file/3wTKm3oB/screenshot.png
<HomHomer> Thanks, Ubuntu
<HomHomer> Obamaâ¦
