[00:02] <lifeless> jam: ping
[00:03] <lifeless> abentley: re smart server conflicts - good;
[00:03] <lifeless> abentley: I don't know re: 1.0 -> .dev, what patches are they ?
[00:04] <abentley> 1. the plan merge thing you reviewed  2. The warning for criss-cross. + docs
[00:05] <lifeless> yeah merge those to .dev
[00:05] <lifeless> and I'd mail martin once they land with revnos to merge to 1.0
[00:05] <lifeless> .dev is open AFAIK
[00:05] <abentley> Yeah, it's just more complicated later if we merge 1.0 into dev.
[00:06] <abentley> And it reduces the visibility of the merge requests for Martin.
[00:06] <lifeless> OTOH once they are in .dev they get experiential testing, and he can run 'missing bzr.dev;
[00:20] <abentley> jam: ping
[01:11] <jkakar> Does anyone know when bzrtools is expected in the Bazaar repositories for gutsy?
[01:12] <jkakar> As a suggestion, it would be very appreciated if bzr and bzrtools were released in tandem.  I know that creates more work, but it's disturbing to lose often-used commands for hours or days at release times.
[01:13] <lifeless> jkakar: its already there isn't it ?
[01:13] <lifeless> jkakar: http://bazaar-vcs.org/releases/debs/gutsy/ has bzrtools 1.0.0
[01:15] <jkakar> lifeless: I keep getting 'bzrtools: Depends: bzr (< 0.93~) but 1.0~rc1-3bazaar1 is to be installed' after fresh apt-get updates.
[01:18] <lifeless> ah, will fix.
[01:18] <lifeless> I hate this strict versioning; its bogus.
[01:20] <jam> lifeless, abentley : pong
[01:21] <jkakar> lifeless: Thanks!
[01:21] <thumper> he bazaar dudes
[01:21] <thumper> I have some fella saying that bzr doesn't have GUIs (on windows)
[01:21] <thumper> what do we have?
[01:21] <thumper> links would be good
[01:21] <thumper> s/he/hey/
[01:21]  * thumper needs to check more before pressing enter
[01:21] <jam> bzr-gtk
[01:22] <jam> works on Windows
[01:22] <jam> TortoiseBzr is at least in the works
[01:22] <thumper> jam: is it any good
[01:22] <jam> I know it "works"
[01:22] <jam> but I haven't used it myself
[01:22] <thumper> jam: eta on TortoiseBzr ?
[01:22] <fullermd> AFAIK, both -gtk and qbzr work OK, but are also both pretty manual to install and not as comprehensive as one would like.
[01:22] <thumper> fullermd: is qbzr able to work on windows?
[01:23] <jam> thumper: it should be
[01:23] <fullermd> That's what I understand from snooping on list/IRC discussions.
[01:23] <jam> You just need the QT 4 libs
[01:23] <thumper> how's the eclipse plugin?
[01:23] <jam> but there should be GPL QT 4 libs for windows
[01:23] <thumper> usable?
[01:23] <jam> thumper: a lot of active development recently
[01:23] <lifeless> jam: pong
[01:23] <jam> Verterok: thumper wants to know about bzr-eclipse
[01:23] <jam> lifeless: hey, just getting some family time before they sleep
[01:23] <thumper> who's working on TortoiseBzr ?
[01:23] <jam> do you want to talk by phone?
[01:24] <jam> thumper: it is part of the bzr-gtk package, so jelmer is at least aware of it
[01:24] <jam> I believe it was a google SoC thing
[01:24] <abentley> jam: I was thinking of working on a pack format using mpdiffs, but I got the impression you're going to do xdelta packs.
[01:24] <jam> but I can't remember his name off-hand
[01:24] <lifeless> jam: now is good
[01:24] <abentley> I don't want to duplicate the effort.
[01:24] <jam> lifeless: do you want by phone or by skype?
[01:24] <lifeless> skype
[01:24] <abentley> jam: Alexander Haro was working on TortoiseBzr
[01:25] <jam> lifeless: logging on now
[01:25] <jam> abentley: did he have an IRC nick?
[01:25] <abentley> I don't remember.
[01:26] <jam> abentley: talking with robert, will ping when done
[01:26] <abentley> 'kay
[01:26] <jelmer> tortoisebzr is not actually part of bzr-gtk, nautilusbzr is
[01:27] <jelmer> tortoisebzr was somewhat of a fork of bzr-gtk though
[01:51] <jam> abentley: back
[01:51] <abentley> Hey.
[01:52] <jam> so I certainly have some ideas of how to get there, but there are several steps to be done before we can really have an "optimal" pack layout
[01:52] <jam> like, just getting the non-redundant index data put into the real data
[01:52] <Odd_Bloke> What's the plan for 1.n versioning?  Will 1.0.n releases go on until a certain set of features are complete and then the next version will be declared 1.(n+1)?
[01:52] <jam> (the fact that this is a delta versus a fulltext, eol, compression parent, etc are all *only* in the index)
[01:52] <jam> Odd_Bloke: well, Martin posted 1.1 in January
[01:53] <abentley> Oh, I get what you mean.  Making the index be redundant data.
[01:53] <jam> which would hint at continuing the 1.(n+1) we have now
[01:53] <Odd_Bloke> Ah yeah, I recall now you mention it.
[01:53] <jam> abentley: right, that is one of the steps
[01:53] <jam> also, in talking with Robert, a good intermediate is to allow pack repos to mix their deltas
[01:53]  * Odd_Bloke returns to House.
[01:54] <jam> since as you commit you really only generate deltas from previous
[01:54] <abentley> Err, really?
[01:54] <jam> but after repacking you would probably want to generate reversed ones
[01:54] <abentley> what do you mean by mix?  Different formats?
[01:54] <jam> xdelta & knit deltas co-mingled was an idea
[01:54] <jam> partly because when you commit
[01:54] <jam> we would like a knob to turn on annotation building at commit time
[01:55] <jam> and for that, we would need to generate some form of line-delta
[01:55] <jam> which would be a shame to waste
[01:55] <jam> and do 2 deltas at commit time
[01:55] <jam> it might be okay
[01:55] <jam> but it is something to think about
[01:55] <abentley> Yes.
[01:55] <jam> Also, it would make it a lot easier to phase in a change
[01:56] <lifeless> spiv: ping; whats the bug regarding your web proxy?
[01:56] <abentley> Another thing I've talked about is having a comparison cache.
[01:56] <jam> if it had a way to migrate without spending 40-hours reformatting the data
[01:56] <jam> abentley: well, we would probably have that, and fill it at commit time
[01:56] <abentley> But with the C-optimized sequence matcher, comparisons are far less expensive.
[01:56] <jam> if the knob was turned on
[01:57] <abentley> So we seem to do fine without it.
[01:57] <jam> abentley: even for whole-file annotate
[01:57] <jam> gannotate is pretty slow last I checked
[01:57] <jam> but I haven't tried your new stuff
[01:57] <abentley> My new stuff is just for merging.
[01:58] <abentley> But I was talking about a comparison cache, not annotation cache.  We definitely need cached annotations.
[01:59] <jam> abentley: couldn't you use the comparison for annotation data?
[01:59] <jam> or I guess that has too small a view?
[01:59] <abentley> Well, we already are using cached comparisions about 3/4 of the time.
[01:59] <jam> (1 text to 1 previous text, not the full history for that file)
[02:00] <abentley> I think you can't annotate to the origin everytime and expect good performance.
[02:00] <jam> srue
[02:00] <jam> sure
[02:00] <jam> 10k to the origin is a long way to go
[02:01] <jam> what if the annotation cache was the 'fulltexts' and the rest was comparison cached
[02:01] <jam> just as a thought
[02:01] <jam> also, what is the overhead of doing an actual delta, versus the I/O of reading it in from a cache
[02:01] <jam> I seem to remember there wasn't much of a win depending on the circumstances
[02:02] <abentley> Yeah, right now I haven't seen a huge win for cached comparisions.
[02:02] <jam> I suppose it also depends if you have to extract the texts as well
[02:02] <abentley> I think we should start with cached annotations.
[02:02] <jam> if you don't have the I/O of getting the full text
[02:03] <jam> you wouldn't have the texts around to do a memory comparison
[02:03] <abentley> Yes, that does tend to negate the IO win of doing a comparision from scratch.
[02:03] <jam> so, the very first step for any of this
[02:03] <jam> is that we should merge in a truly experimental format
[02:03] <jam> into bzr.dev
[02:03] <jam> so that it can be played with
[02:03] <jam> we could do it all in a feature branch
[02:04] <jam> but those tend to rot a lot more than a bzr.dev branch
[02:04] <abentley> I think that's okay with me.
[02:06] <abentley> So what I'm interested in is implementing iter_files_bytes in a way that it can read everything in a single pass.
[02:07] <jam> so... iter_files_bytes, you're thinking of that for TT, and build_tree, right?
[02:07] <abentley> That means writing a new revision builder, which is affected by the delta format.
[02:07] <jam> which means that you will tend to want only 1 version for a given file-id
[02:07] <abentley> Well, also operations that use a lot of different revisions of a file.
[02:08] <jam> but you will want lots of file ids
[02:08] <jam> diff is the only other one that comes to mind for wanting multiple versions of a file
[02:08] <jam> and that is only 2 versions per file-id
[02:08] <jam> I guess annotate...
[02:08] <jam> but we would like to not have to do that as much from a raw iter_files_bytes point of viwe
[02:08] <abentley> And simple revision fetching.
[02:08] <jam> view
[02:08] <jam> abentley: but would you want to fetch as full texts?
[02:09] <abentley> iter_files_bytes returns an iterable.
[02:09] <abentley> So you can certainly take advantage of common lines.
[02:09] <jam> abentley: right, but wouldn't you want to fetch the deltas, etc, not the full text each time?
[02:10] <abentley> For annotate?
[02:10] <abentley> Oh, for installing revisions.
[02:10] <jam> abentley: not for annotate... for "simple revision fetching"
[02:10] <abentley> For simple revision fetching, you assume the repos have incompatible delta formats.
[02:11] <abentley> Like that fetch code you wrote recently.
[02:11] <jam> interesting, I'm curious how things would be buffered
[02:12] <jam> it does seem like *most* use cases are across a revision
[02:12] <abentley> Oh, probably using that handy LRU of yours.
[02:12] <jam> not across a file's history
[02:13] <abentley> True.  But I think the abstraction of just asking for a bunch of keys, not caring whether they're from the same file, is pretty nice.
[02:14] <Verterok> moin
[02:14] <jam> abentley: oh, I agree. I believe in moving away from VF as a concept, to putting more of that on Repo
[02:14] <Verterok> jam, thumper: hi
[02:14] <jam> hi Verterok
[02:14] <jam> how is bzr-eclipse going?
[02:15] <jam> is it in a "useable day-to-day" or still more experimental?
[02:15] <Verterok> it's not feature complete, but sure it's usable in a day to day basis.
[02:18] <lifeless> jkakar: uploading now
[02:19] <Verterok> jam, thumper: I recently write a draft of the roadmap at http://bazaar-vcs.org/BzrEclipse/Roadmap
[02:19] <spiv> lifeless: my proxy bug is 172701
[02:20] <thumper> Verterok: thanks
[02:20] <Verterok> np
[02:21] <jkakar> lifeless: Ta!
[02:23] <Verterok> thumper: I'll be around, shoot any questions that might araise :)
[02:23] <thumper> Verterok: so were are we now with bzr-eclipse?
[02:24] <Verterok> in which aspect? (integration with bazaar? integration with eclipse?)
[02:28] <Verterok> thumper: about the  java-bazaar integration, almost all relevant commands have a counterpart in the BazaarClient java library
[02:28] <jam> abentley: another small thing, I'm looking at the Mine page, and it seems to list some things that I've merged.
[02:28] <jam> like http://bundlebuggy.aaronbentley.com/request/%3C20071130201555.3F94855FFA@juju.arbash-meinel.com%3E
[02:28] <jam> Have you not updated from bzr.dev in a while?
[02:28] <jam> I was trying to clear out accepted but unmerged things
[02:28] <abentley> I've seen that too.
[02:28] <jam> but my list isn't reflecting it
[02:29] <abentley> I know it is doing the right thing some of the time.
[02:29] <Verterok> thumper: I'm still waiting for jython 2.5 :P
[02:29] <abentley> But sometimes it seems to missing things.
[02:29] <jam> Verterok: what happened with the JEPP (etc) wrapper for bzrlib?
[02:29] <jam> I know it happened for a Mono/.NET port
[02:29] <jam> as part of the Visual Studio integration
[02:29] <abentley> This is likely because I switched that operation to be internal.
[02:30] <abentley> But I'm not getting any failure reports or anything.
[02:30] <jam> k, it just would be easier for me if i could look at the list of things I haven't merged yet
[02:30] <jam> I can do it manually
[02:30] <jam> but I didn't want to step on anything
[02:30] <jam> in case you wanted to use it as a test case
[02:31] <abentley> No, please go ahead.
[02:31] <abentley> I'm aware of the problem.  Sorry for the inconvenience.
[02:31] <jam> abentley: could it be that the tip wasn't merged?
[02:31] <jam> I committed another rev on top of it and merged that
[02:32] <Verterok> jam: about jepp, I played a bit but it seems too complex to install from the user perspective, the CLI wrapper is a bit slower but works fine and only requires xmloutput plugin
[02:32] <abentley> It shouldn't be that, but I think my test cases are against the tip.
[02:36] <Verterok> jam: also jepp requires a LOT of work to get a usable interface, and jython 2.5 is comming (they have a new compiler that understand cpython bytecode ;) )
[02:37] <jam> Verterok: good to hear
[02:37] <jam> last I tried jython it was pretty limited
[02:37] <jam> It is a shame we probably won't ever get the bzrlib test suite to run there
[02:37] <jam> as we use 'os.chdir()' a lot to ensure each test is sandboxed
[02:38] <jam> (afaik, we use it 0 times in actual bzrlib code, but the test suite uses it a lot)
[02:39] <Verterok> sure it's a shame, maybe when time of jython 2.5 comes, I can put some work to make a custom os.chdir as a native jython module
[02:40] <jam> I thought it wasn't allowed because of Java limitations
[02:41] <Odd_Bloke> JNI could do something I would've thought...
[02:42] <Verterok> you'r right, I was thinking in a workaround and not a real fix to jython :D
[02:42] <Verterok> just to make the bzrlib test suite run
[02:47] <thumper> Verterok: I was meaning 0.1? 0.2? on your roadmap
[02:48] <Verterok> thumper: oh, ok. I'm currently working in the quickdiff integration
[02:48] <thumper> k
[02:49] <Verterok> the next thing to do is basic merge support and conflict resolution with the strutctured merge, and with this working I plan to make a new build
[02:52] <Verterok> s/strutctured merge/strutctured diff/
[03:09] <spiv> lifeless: call?
[03:10] <ubotu> New bug: #173807 in bzr "Branching from RepositoryFormat7 standalone branch from a smartserver fails" [Undecided,New] https://launchpad.net/bugs/173807
[03:15] <lifeless> spiv: yup
[03:17] <spiv> lifeless: ok, will call in a sec
[03:18] <lifeless> kk
[03:18] <edencane> Hi
[03:19] <edencane> I have a question about bzr versions
[03:19] <edencane> ...
[03:19] <edencane> Anyone?
[03:20] <lifeless> sure
[03:20] <edencane> Ok. I've got ubuntu 7.10 want to install bzr
[03:20] <echo-area> hello, I branched bzr's main repository, and after that, I need to take 2+ hours to update my repository (getting 200+ MB at 30 kB/s for a 80 MB repository), is this normal?
[03:20] <echo-area> thanks
[03:21] <lifeless> echo-area: thats not normal; our repository is only 50 mb total.
[03:21] <lifeless> echo-area: and updates should be a few seconds or a minute at most
[03:21] <lifeless> edencane: please, ask your question
[03:21] <edencane> Thanks.
[03:21] <echo-area> hmmm, what could be possible wrong in my case?
[03:22] <fullermd> lifeless: Actually, my bzr repo is about 75 meg.  It's got a handful of my revs in it, but they can't add up to 100k.
[03:22] <fullermd> echo-area: When did you branch it?
[03:23] <lifeless> fullermd: oh hmm, I'm considering core data.
[03:23] <echo-area> around Nov 20 I think
[03:23] <edencane> latest release is 0.92, yet when I add the repository to sources.list for use with aptitude, the available version is 1.0.0.candidate.1
[03:23] <lifeless> echo-area: ah, perhaps you missed the announcement that I sent out that bzr.dev is now in pack format.
[03:23] <edencane> Ive installed that version
[03:23] <fullermd> echo-area: Ah.  Try a 'bzr info' of your branch; I'll bet it'll say 'dirstate' for the format, and is trying to pull the new pack'd bzr.dev.
[03:24] <lifeless> echo-area: you should: let the current pull finish. Then 'bzr reconcile' and then 'bzr upgrade', using the bzr in the branch itself.
[03:24] <echo-area> OK thanks guys :)
[03:24] <lifeless> edencane: yup
[03:24] <edencane> So whats the deal with different version numbers
[03:24] <edencane> ?
[03:24] <lifeless> edencane: we're getting ready to release 1.0
[03:24] <edencane> Ok, great!
[03:25] <edencane> congrats
[03:25] <edencane> If I use 1.0 on a branch thats being used with 0,92 by other developers, will that cause inconsistencies?
[03:26] <lifeless> edencane: no, it will be fine.
[03:27] <lifeless> edencane: the main difference is that 1.0 will be default create new branches in 'packs' format. This is faster, but not supported on < 0.92, and not as well supported on 0.92 as in 1.0.
[03:27] <edencane> will that impact on doing a pushes and pulls or creating new branches?
[03:28] <spiv> edencane: when pushing or pulling a branch to a new location, so bzr needs to make a new copy, bzr will make that in the same format as the original.
[03:29] <spiv> edencane: so it should work just fine.
[03:29] <edencane> so if I push changes with 1.0 and theother pulls those changes we'll be fine?
[03:29] <spiv> edencane: 0.92 users will want to upgrade to 1.0 anyway, because of the bugfixes and optimisations ;)
[03:29] <spiv> edencane: right
[03:30] <edencane> Cooool
[03:30] <edencane> Thanks so much guys. That was great help, Best with the new release and cheers for an overall great product (-:
[03:37] <chiefinnovator> how do I back up bazaar?
[03:38] <beuno> chiefinnovator, all the information is stored in the .bzr directory
[03:38] <chiefinnovator> But it looks too small to be holding everything
[03:38] <Peng> chiefinnovator: Unless you're using a lightweight checkout, it is holding everything.
[03:38] <beuno> chiefinnovator, are you sure all your files are versioned?
[03:39] <chiefinnovator> well, I had a directory of existing files
[03:39] <chiefinnovator> and I did bzr init
[03:39] <chiefinnovator> and bzr add
[03:39] <beuno> chiefinnovator, and commit?
[03:39] <chiefinnovator> ohhh
[03:39] <beuno> :D
[03:40] <chiefinnovator> Yeah, that's better
[03:40] <chiefinnovator> thanks
[03:41] <chiefinnovator> So anything I do some work, I just do a commit when I'm done?
[03:41] <chiefinnovator> I'm just using it to track my own files
[03:41] <chiefinnovator> anytime*
[03:41] <Peng> Okay, running reconcile on bzr.dev made it go from 49 to 0 unreferenced text versions, and it used to say 108 inconsistent parents and now says nothing.
[03:41] <echo-area> fullermd: Sorry but where can I find your announcement?  Is it in https://lists.ubuntu.com/archives/bazaar/2007q4/thread.html ?  Thanks
[03:41] <Peng> Still 2 ghost revisions and 2 revisions missing parents.
[03:41] <beuno> chiefinnovator, yeap, just commit when you're done
[03:42] <beuno> remember, commiting is cheap with bzr, so you can be very granular about what you do
[03:42] <beuno> you will have a more useful history and easier to rollback
[03:42] <chiefinnovator> how do I rollback?
[03:42] <fullermd> echo-area: I think you mean lifeless, not me.  Check Nov 28th, if you mean the announcement I think...
[03:43] <edencane> Doing a bzr status on with 1.0 on 0.92 tree, If I do a bzr upgrade, will that affect the operation of another developer who is still using 0.92?
[03:43] <beuno> chiefinnovator, there are several ways, bzr uncommit (undo last commit) bzr revert (to a specific revision if you like), or bzr cat (to a specific file in a specific revision)
[03:43] <echo-area> Oh, thanks
[03:43] <chiefinnovator> thanks
[03:47] <Peng> edencane: Well, there are some issues with packs in 0.92. He should really upgrade.
[03:47] <abentley> jam: is it intentional that the C version of Patience only allows strings?
[03:47] <edencane> Thanks peng
[03:47] <Peng> edencane: (No data loss or anything, but "bzr cat" fails and so does pushing over bzr+ssh, and some other things are slow (which aren't all sped up in 1.0rc1).)
[03:49] <edencane> Ok.
[03:49] <edencane> Thanks again.
[04:00] <spiv> Peng: cool, that sounds like reconcile is working as expected for you.
[04:01] <Peng> spiv: Okay.
[04:02] <Peng> Urrgh. I shouldn't run "bzr check" before and after to see what reconcile does. It takes 5x as long.
[04:02] <Peng> Or 4x. I dunno.
[04:02] <Peng> check takes about 2x as long, and I do it twice . .
[04:04] <lifeless> check does more :)
[04:04] <lifeless> okies
[04:05]  * lifeless waves
[04:07] <igc> see ya lifeless
[04:09] <Peng> If reconcile doesn't find anything to do, the repo is left unmodified?
[04:10] <spiv> Peng: yeah, it should be.
[04:10] <Peng> Okies.
[04:15] <Peng> Hey, I have a .pack that is 1024.0 KB. Nice.
[04:16] <Peng> 1,048,531 bytes, with 1 MB being 576. :)
[04:22]  * igc lunch
[04:44] <Peng> jelmer: FWIW, running reconcile on bzr-svn fixes some inconsistent parents.
[06:01] <Peng> I wonder, would running reconcile over sftp be any faster than just uploading a new copy of the repo (I have a reconciled copy on my PC)?
[06:22] <fullermd> Peng: My Magic 8-Ball considers it unlikely.
[06:23] <fullermd> (based on no real knowledge; just guessing)
[06:24] <spiv> I would expect reconcile over sftp to be pretty slow.
[06:24] <spiv> I haven't measured, but I don't think that code is written to minimise round-trips.
[07:25] <lifeless> i386: hi
[07:25] <lifeless> when do you return ?>
[07:25] <i386> 11th :)
[07:25] <i386> still up for doing dinner?
[07:28] <lifeless> ya'
[07:28] <lifeless> on leave now
[07:33] <i386> oh right
[07:33] <i386> :)
[07:33] <i386> Im leaving Seattle tomorrow morning
[07:33] <i386> its a bit of a shit hole
[07:37] <i386> lifeless: how long are you on leave for?
[08:16]  * igc dinner
[13:44] <jelmer> Peng: thanks
[14:11] <jam-laptop> abentley: I don't think it is a requirement that the C version work only on strings
[14:11] <jam-laptop> My guess is that strings were the most important
[14:11] <jam-laptop> I wouldn't want to see it slow down much, but I could certainly see supporting tuples
[14:11] <jam-laptop> would be nice for annotated texts
[14:13] <jam-laptop> It is nice to have a simple "compare_lines" function that can use something fast like "memcmp"
[14:16] <jam-laptop> we could experiment with using "PyObject_Hash()" instead of a custom hash func
[14:16] <jam-laptop> and maybe PyObject_Compare
[14:39] <theSoftMan> hello all.. i am looking for some QBZR screenshots on windows systems...
[14:48] <luks> theSoftMan, http://bazaar-vcs.org/QBzr has some, but they are from old versions
[14:48] <luks> it easier to just install it :)
[14:48] <luks> it's
[14:50] <theSoftMan> i have try ti install but it does not work :-)
[14:50] <luks> file a bug report
[14:57] <luks> theSoftMan, http://users.musicbrainz.org/~luks/tmp/qbzr.png this is a screenshot of the dev version
[14:57] <luks> theSoftMan, what exactly didn't work for you?
[15:07] <theSoftMan> luks, when i lauch bzr a message appear to said that some modules are not found
[15:07] <theSoftMan> luks, i try to define some path variable but qbzr never start
[15:08] <theSoftMan> luks,
[15:08] <luks> bzr 0.92 and qbzr 0.7.1?
[15:08] <theSoftMan> luks yes sir :-)
[15:08] <luks> both installer using the windows installers?
[15:08] <luks> *installed
[15:09] <luks> that is, the bzr.exe one
[15:09] <luks> if you use your own python, you have to install pyqt4
[15:09] <luks> if you use bzr.exe, everything should be included in the installer
[15:11] <jam-laptop> abentley: I think I put together a patch to make it allow generic objects, (as long as they are hashable), I'll clean it up and post it to the list.
[15:23] <theSoftMan> luks, sorry i was disonnected... yes i use my one python installation 2.5
[15:24] <theSoftMan> luks, i will try to install pyqt4
[15:24] <theSoftMan> luks, thanks
[15:26] <theSoftMan> one more question : the 1.0 will be ok in hom many times ? in your humble opinion :-)
[15:40] <eschava> Hi guys. Could you suggest correct way to solve text conflicts using bzr-gtk ?
[16:45] <ubotu> New bug: #173941 in bzr "hard to programmatically break a lock" [Undecided,New] https://launchpad.net/bugs/173941
[16:55] <ubotu> New bug: #173944 in bzr "adding files below symlink causes error" [Undecided,New] https://launchpad.net/bugs/173944
[17:14] <jam-laptop> vila: ping
[17:14] <jam> I'm fixing the nick for once and all, bbiab
[17:17] <jam> vila: ping again
[17:21] <vila> pong
[17:24] <jam> hi vila, how is it going?
[17:24] <jam> I was wondering if you were going to be extra busy this week
[17:24] <jam> or if you would have time to work on your patch
[17:24] <vila> pretty nicely, new project starting, may be fun :)
[17:25] <vila> I will be extra busy, but I already take your remarks into account
[17:25] <vila> Hmmm, Did I sent the email or did I just made the commit ? Let me check
[17:26] <jam> Is this the one that you had to speculate your bug fixing effectiveness for the next 12 months?
[17:26] <jam> I saw the commit email, I guess
[17:26] <vila> yup
[17:26] <jam> so did you go with 10 as I mentioned ?
[17:26] <vila> hmmm, I think we went with 3/months ;-)
[17:27] <vila> but given the subject (argh, NDA), well, bugs can be pretty hard
[17:28] <vila> so it's still a bit stupid, but at least I get a mention added: "Any bug will first diagnosed before an evaluation is made for fixing"
[17:28] <jam> vila: no problem, what is your feeling on your changes for 1.0?
[17:28] <jam> I'd really like them, do you feel like it is logically small enough to do so?
[17:28] <vila> jam: just sent the email, I agree some real life testing should be good, but since we are still in RC, I pretty confident
[17:29] <vila> basically I went TDD on that one and the test suite was a real pleasure
[17:30] <vila> granted I had to rewrite most of the RangeFile tests, but that was pretty obvious.
[17:30] <vila> Once *that was done, I get pnlu trivial bugs and typos (of course) to fix.
[17:30] <vila> s/pnlu/only/
[17:30] <vila> hehe
[17:31] <fullermd> Somebody, help!  The irony is choking me!
[17:31] <vila> I just can't type about typos without doing at least one, and when I don't it's bad english
[17:33] <vila> Anyway, once the test suite passed, I had a bad surprise since our http tests servers are all speaking http/1.0, not 1.1, but that was a good thing finally since I ended up handling the http pipe even more cleanly that I was hoping
[17:33] <vila> jam: bbl. early dinner time
[17:33] <jam> vila: enjoy your food
[17:35] <somerville32> Are there any branch commit notification bots?
[17:41] <jam> somerville32: well, Launchpad will let you subscribe to branches.
[17:41] <jam> There is an atom-feed plugin
[17:41] <jam> there is bzr-email to send a message after commit
[17:41] <jam> but if you just want to poll a bunch of branches, and send emails when they change...
[17:41] <jam> I think there was something for that
[17:41] <fullermd> It was called 'hookless mail' or something like that.
[17:42] <dato> launchpad.net/bzr-hookless-email
[17:43] <somerville32> I host it on launchpad though
[17:43] <somerville32> So I'll just need a bot to parse the e-mails?
[17:44] <somerville32> Preferably, I'd like a bot that polls the branches and just sends a message to my channel (and preferably I'd like it already coded, haha)
[17:44] <jam> fullermd, dato: should bzr-hookless-email be listed on http://bazaar-vcs.org/BzrPlugins?
[17:44] <jam> somerville32: I know there is also a dbus plugin, which is meant to alert the local network when there are changes
[17:45] <jam> And lifeless was looking into an irc-notify plugin
[17:45] <jam> but was hesitant to finish that before he had a way to make it scale well
[17:45] <dato> somerville32: there is bzr-cia, but all people who commit there should install it themselves for it to be useful.
[17:45] <jam> (1000s of people announcing all there changes would get *really* noisy.)
[17:46] <fullermd> jam: No clue.  I just work her...   well, actually, I don't...
[17:46] <jam> you work him ?
[17:46] <fullermd> Only on weekends and special occasions.
[17:47] <jam> (bad choice of ellipsis)
[17:47] <dato> hehe
[17:47] <fullermd> (available for birthdays and bar mitzvahs by prior arrangement)
[17:49] <jam> hmm... it seems like bzr-hookless-email isn't strictly a plugin, as it provides its own 'main()' function.
[17:49] <somerville32> Is there a python module for interacting with bazaar-vcs?
[17:49] <fullermd> It strikes me more as a 'helper script' than a 'plugin' per se.
[17:49] <jam> somerville32: if you install 'bzr' then you get 'bzrlib' in python
[17:50] <jam> fullermd: but we certainly should link to it from bazaar-vcs.org somewhere
[17:50] <dato> jam: yes, it's an external watcher
[17:50] <jam> as people would want the functionality
[17:50] <dato> jam: which I sorely needed
[17:50] <fullermd> Probably, yah.
[17:50] <jam> dato: do you have it linked anywhere?
[17:50] <dato> nope; maybe I can add it to a subsection of BzrPlugins
[17:51] <dato> and maybe could be extended to perform random actions on branch updates
[17:51] <dato> like, with a plugin sistem O:-)
[17:52] <dato> actually, it would be interesting to have it running actual bzr hooks (email, cia, dbus) on the server
[17:52] <dato> 0 code duplication, etc. I wonder why I didn't think of that before
[17:53] <jam> dato: if you said something, I missed the last couple of messages, last I saw was "plugin system"
[17:53] <dato> 18:51 <dato> and maybe could be extended to perform random actions on branch updates
[17:53] <dato> 18:51 <dato> like, with a plugin sistem O:-)
[17:53] <dato> 18:52 <dato> actually, it would be interesting to have it running actual bzr hooks (email, cia, dbus) on the server
[17:53] <dato> 18:52 <dato> 0 code duplication, etc. I wonder why I didn't think of that before
[17:53] <dato> how does that sound?
[17:53] <jam> so, one thing you could do, is change some of those plugins to hook into 'post-pull'
[17:53] <jam> and then just have them installed on the server
[17:54] <jam> so that when you 'bzr pull' into the mirror branches
[17:54] <jam> it sends notifications
[17:54] <jam> as an idea, at least.
[17:54] <dato> pulling into what, when?
[17:54] <dato> the use case was notification for branches where people were pushing to
[17:55] <dato> where these people don't have bzr-email etc. installed or configured, or you can't rely on them doing so
[17:55] <jam> dato: so you mirror them ... :)
[17:55] <jam> or hook into post-push, and get that working for the bzr+ssh stuff
[17:55] <jam> I have tested that post-push doesn't fire (at the moment) over bzr+ssh
[17:56] <dato> well, I like watching the live branches in the server better, with inotify and stuff. it's very responsive in that case.
[18:02] <abentle1> jam: Bundle Buggy is working for me now, and I'm finished messing around with it.  Is it still down for you?
[18:08] <jam> abentley: It seems to be up for me
[18:44] <jkakar> lifeless: FYI, the bzrtools package is still not upgradeable.  It's failing in the same way it did yesterday: bzrtools: Depends: bzr (< 0.93~) but 1.0~rc1-3bazaar1 is to be installed
[18:50] <somerville32> oh noes :(
[18:50] <somerville32> I pushed to the wrong series.
[18:53] <zeasier> having some trouble with bzr where we changed some directories to symlinks and now the working tree won't update on our other branches
[18:55] <jam> zeasier: what is happening when you try to update
[18:55] <jam> I wonder if our commit code didn't properly delete things
[18:55] <jam> and now it things you have children underneath the symlink, or something odd like thaht
[18:55] <zeasier> we get a sequence of errors
[18:55] <jam> that
[18:56] <jam> zeasier: can you paste it ?
[18:56] <jam> !paste
[18:56] <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)
[18:56] <zeasier> trying to find one, one moment
[18:56] <zeasier> bzr: ERROR: Tree transform is malformed [(‘non-directory parent’, ‘new-1650’)]
[18:57] <zeasier> though we've found a work around for that
[18:57] <somerville32> Is it possible to go back and modify a commit message?
[18:57] <bialix> privet
[18:57] <zeasier> it has to do with the directories that were changed to symlinks
[18:57] <bialix> I have question about English
[18:58] <bialix> mini-tutorial title is "Bazaar in five minutes"
[18:58] <jam> somerville32: only right at the moment by using 'bzr uncommit' and then 'bzr commit' with a new message
[18:58] <beuno> somerville32, only uncommiting til that revision (thus, loosing al intermediate history/changes)
[18:58] <zeasier> if you remove the directory the update works fine (though i'd like to file a bug, if you all thing it's unique)
[18:58] <bialix> any suggestions how better translate "in 5 minutes"?
[18:58] <jam> zeasier: sounds unique to me
[18:59] <jam> bialix: is there a russian term for "in a short amount of time"
[18:59] <jam> or "give a quick summary of how to get going with X" ?
[18:59] <zeasier> i ran a bzr check and got, "10 inconsistent parents" at the end
[18:59] <jam> zeasier: I don't think the inconsistent parents is specifically related
[19:00] <jam> that is a checking for something differennt
[19:00] <zeasier> ah
[19:00] <jam> (revision parent... over history, not over the files)
[19:00] <zeasier> thing is after the work around i just told you we run into a 2nd problem
[19:00] <zeasier> bzr: ERROR: Key secureimages-20071030155234-zswi43l3yzmiegcj-182 is already present in map
[19:01] <zeasier> this is after we delete all the directories that have changed into links
[19:01] <bialix> jam: yes, we have stable idiom about 1 minute, 5 minutes. I mean what is synonym for this. is it means: "teach bzr in 5 minutes" or "5 minutes acquaintance with bzr" or?
[19:02] <zeasier> don't have a work around for that yet
[19:02] <beuno> bialix, seems close to "5
[19:02] <jam> zeasier: well, if you can paste a traceback, that would help (the tail of ~/.bzr.log)
[19:02] <bialix> jam: because in russian I can't say simply "bzr in short amount of time". the sentence is icomplete for russian
[19:02] <beuno> minutes acquaintance with bzr"
[19:03] <jam> bialix: it isn't a complete sentence in English, it is just a common idiom
[19:03] <zeasier> alright i'll get to that, one moment
[19:03] <bialix> hence and question
[19:03] <jam> bialix: maybe "get aquianted with bzr in 5 minutes"
[19:05] <zeasier> http://paste.ubuntu-nl.org/46862/
[19:05] <zeasier> that's only the trackback, let me know if you want stuff from futher up the log
[19:06] <bialix> or "5 minutes for acquiatance with bzr"? it's seems good variant in russian.
[19:06] <jam> zeasier: so ... off-hand it sounds like you have the same file versioned 2 times.
[19:06] <jam> bialix: well, that would be bad in english, but if it makes sense in russian :)
[19:06] <jam> acquianted
[19:06] <jam> acquainted
[19:07] <jam> finally, correct spelling :)
[19:07] <bialix> jam: we have song in one old movie about New Year, "five minutes, five minutes -- it's too much or too small?". I'll try to use something consonant.
[19:08] <somerville32> I love bazaar :]
[19:08] <zeasier> do bzr branches traverse syslinks? will bzr add . add something like i-am-a-link/subfile?
[19:08] <jam> zeasier: As I mentioned earlier, it sounds like when you changed dirs to symlinks, we didn't properly mark the children of the symlinks as removed.
[19:08] <jam> zeasier: 'bzr add .' will not
[19:08] <jam> 'bzr add link/foo' might
[19:08] <zeasier> ah
[19:08] <jam> zeasier: bug #173944
[19:09] <ubotu> Launchpad bug 173944 in bzr "adding files below symlink causes error" [Medium,Triaged] https://launchpad.net/bugs/173944
[19:09] <zeasier> i saw that one
[19:09] <zeasier> though our problem is a little different
[19:10] <zeasier> we added files in a directory then changed that directory to a link
[19:10] <jam> zeasier: right, I just wanted to mention that "bzr add link/foo" can do funny things
[19:10] <zeasier> yeah
[19:10] <jam> changing it underneath us... needs better testing
[19:10] <jam> the code that notices when a file/directory becomes a symlink
[19:10] <jam> needs to be a bit smarter about the repercussions
[19:10] <zeasier> i've been impressed with the softwares stability so far
[19:11] <zeasier> not too disapointed we screwed it up this way
[19:11] <zeasier> just want to contribute a bug you all can use
[19:13] <vila> jam: back
[19:13] <jam> zeasier: yeah, a few versions back we wouldn't let you change a directory into a symlink without a 'bzr rm; bzr add' change
[19:13] <jam> we got rid of that
[19:13] <jam> but obviously didn't catch all the edge cases.
[19:14] <zeasier> here's the commits that created the problem
[19:14] <zeasier> http://paste.ubuntu-nl.org/46863/
[19:14] <zeasier> is this enough to reproduce the issue?
[19:14] <zeasier> you can see the changed directories and a list of files in one of them
[19:15] <bialix> or maybe "get started with bzr in 5 minutes"?
[19:16] <dato> that sounds good to me
[19:16] <dato> and seems close to the meaning in English
[19:18] <vila> bialix: get in the bazaar in five minutes ?
[19:19] <jam> bialix: I think "get started with Bazaar in 5 minutes" the most
[19:19] <jam> zeasier: well, having a simple test script is the nicest, but that does look like it would be reproducible
[19:20] <zeasier> alright hopefully i'll get that bug filed by the end of today
[19:20] <jam> zeasier: what version of bzr are you using?
[19:20] <zeasier> we're using rc1
[19:20] <jam> (bzr --version)
[19:20] <jam> zeasier: did you do the commit with rc1?
[19:21] <zeasier> no
[19:21] <jam> do you know what version you used?
[19:21] <zeasier> timestamp: Thu 2007-11-29 17:45:48 -0500 through timestamp: Fri 2007-11-30 18:03:53 -0500
[19:22] <zeasier> from our commit log
[19:22] <jam> my simplistic test shows the child file as deleted
[19:22] <zeasier> we're using whatever the lastest release in your apt repo is
[19:24]  * dato wonders why bzr.dev claims it's 0.93
[19:26] <jam> dato: well, bzr-1.0 claims it is 1.0candidate1. just that bzr.dev claims 0.93.dev.0
[19:27] <dato> yes, I said bzr.dev ;)
[19:27] <jam> mostly because when 0.92 was finalized, we didn't know whether it would be 0.93 or 1.0... so we went conservative
[19:27] <jam> I'd be happy to review a patch :)
[19:28] <jam> zeasier: well, at the moment, I haven't been able to reproduce it with a very simple test
[19:28] <jam> so it *might* have been fixed
[19:28] <zeasier> yeah, i know that feeling
[19:28] <jam> but I have the feeling it might be a deeper seated bug
[19:28] <jam> having to do with your directory layout
[19:29] <zeasier> i might try to reproduce by uncommitting that branch and redoing those changes
[19:30] <zeasier> though i did find a work around for the 2nd error
[19:30] <zeasier> bzr: ERROR: Key secureimages-20071030155234-zswi43l3yzmiegcj-182 is already present in map
[19:30] <fullermd> You could do it without uncommit just by branching the previous rev and doing it in another copy.
[19:30] <zeasier> if we bzr rm instead of just rm it seems to go away
[19:31] <zeasier> bzr must of cleared out what ever the conflict way
[19:31] <batoms> if am at my computer at home and i want to branch from server A to server B does bzr have to download everything to my computer first from server A to then upload it to server B
[19:31] <batoms> or is there a way to make A and B communicate directly
[19:35] <beuno> batoms, can you ssh to one of the servers?
[19:35] <beuno> (seems to me that you want something like fxp protocol)
[19:35] <batoms> the servers are both launchpad....i haven;'t actually tried
[19:35] <batoms> bueno: something like fxp is what i had in mind
[19:35] <batoms> they repos use bzr+ssh protocol
[19:36] <ubotu> New bug: #173980 in bzr ""unknown branch format" for unknown repository" [Medium,Triaged] https://launchpad.net/bugs/173980
[19:36] <beuno> batoms, I'm not sure if you can ssh into launchpad que execute bzr branch in the shell, but you can try  :D
[19:36] <beuno> I know you can SSH to it, just not sure if you can run bzr on it
[19:36] <beuno> (would seem to me like you should't be able to)
[19:37] <jam> beuno: you can't ssh to it, only sftp or bzr+ssh
[19:37] <jam> batoms: at the moment, it has to download and re-upload everything
[19:37] <beuno> I know LP has the ability to mirror branches, won't that work for you?
[19:37] <jam> well, I don't think he wants to have LP mirror a branch to itself
[19:37] <jam> it is more of a "ask the server to branch for me"
[19:37] <jam> which has been requested in the past
[19:37] <jam> but hasn't been implemented yet
[19:38] <jam> I believe it is expected (or at least something to make creating new branches easier) in the next 6 months
[19:38] <batoms> jam: exactly what i'm looking for
[19:38] <batoms> guess i'll just have to sit throught it.....i'm on a slow satellite connection
[19:39] <beuno> jam, can't you register a new branch and specify it to checkout from a LP url?  that won't create a branch, but at least a checkout of it
[19:39] <jam> beuno: last I checked you couldn't change a mirrored branch into a hosted branch
[19:39] <batoms> bueno: i think it can mirror a branch but you can't then push to the new branch
[19:39] <jam> batoms: I've been offering a service up creating new branches (myself) by ssh'ing to london
[19:39] <jam> batoms: to help in instances like this
[19:40] <beuno> jam, but you can registed a new one, and when you do, it allows you to specify a mirror URL
[19:40] <beuno> s/registed/register
[19:40] <jam> batoms: what branches do you have/ what do you want to have?
[19:41] <jam> beuno: right, but as mentioned, that creates a "mirrored" branch, an you cannot manually "bzr push" to one of those
[19:41] <beuno> jam, ah, yes, right. Not that useful
[19:42] <batoms> bazaar.launchpad.net/~bauble/bauble/trunk to bazaar.launchpad.net/~bauble/bauble/0.7
[19:42] <batoms> i started the 0.7 branch already but it got cancelled before it was finished
[19:43] <jam> batoms: go ahead and delete ti
[19:43] <jam> it
[19:43] <batoms> so the directory is there but anything that might be inside it is garbage
[19:43] <jam> batoms: if you go to: https://code.edge.launchpad.net/~bauble/bauble/0.7
[19:43] <jam> it should have a "delete this branch" option
[19:43] <jam> well: https://code.launchpad.net/~bauble/bauble/0.7
[19:43] <jam> I'll upload it under my account, and then transfer it to you
[19:44] <batoms> deleted
[19:44] <batoms> jam: fantastic, yer a star
[19:45] <jam> batoms: in the mean-time, what version of bazaar are you using?
[19:45] <batoms> 0.92
[19:45] <batoms> .0
[19:45] <jam> ok.
[19:46]  * beuno wonders if sftp supports FXP-like commands
[19:46] <jam> you might try upgrading to packs (I think in 0.92 it was --knitpack-experimental, but in 1.0 it is --pack-0.92)
[19:46] <jam> beuno: I don't believe so
[19:46] <jam> I've looked into it in the past
[19:46] <batoms> jam: what is packs?
[19:47] <jam> batoms: it is a different repository format, which is a lot better when you have high-latency links
[19:47] <beuno> jam, it seems there a few clients out there that support it. LP probably doesn't though.
[19:47] <jam> beuno: I assume you don't mean: http://en.wikipedia.org/wiki/FXP
[19:47] <jam> (I found the correct link, but I thought that one was funnier)
[19:47] <beuno> jam, e resources on both servers.
[19:48] <beuno> ah
[19:48] <beuno> (pasted garbish)
[19:48] <beuno> :p
[19:48] <jam> It is "double leveraged to deliver twice the inverse of the daily performance"
[19:48] <jam> batoms: https://code.launchpad.net/~bauble/bauble/0.7
[19:48] <jam> should be correct
[19:48] <batoms> jam: so the only drawback with packs is that bzr clients <0.92 can't read them
[19:49] <jam> batoms: correct.
[19:49] <jam> oh, and you should change the author of that branch
[19:49] <jam> I forgot to do so before I transferred it to you
[19:49] <batoms> well since i'm the only developer for my project then that shouldn't be a problem
[19:49] <batoms> jam: thank alot
[19:50] <batoms> that saved me a ton of time
[19:50] <jam> batoms: also, there are a few rough edges in 0.92
[19:50] <jam> which should be greatly smoothed out in 1.0
[19:50] <jam> 1.0rc1 has a bit of polish already (and, in fact, makes it the default format)
[19:51] <beuno> jam, googling around makes me thing most sftp setups support fxp by default
[19:51] <beuno> looking for a client to test it with LP
[19:52] <jam> beuno: well LP is using a customized sftp server, using Twisted as the sftp implementation
[19:53] <jam> beuno: and googling for 'sftp fxp' doesn't give me much
[19:53] <batoms> gotta go, thanks again for the help
[19:55] <beuno> jam, I'll give it a try anyway, just to make sure
[19:55] <beuno> http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/fxp-short-reads.html
[19:55] <jam> sure
[19:56] <beuno> that makes me think it might work, mainly due the ssh's nature
[20:00] <jam> beuno: I think "FXP" in that case stands for FileTransferProtocol
[20:00] <jam> and is just referring to SFTP commands
[20:00] <jam> I don't think it is true cross-domain commands
[20:01] <beuno> jam, right, seems reasonable
[20:01] <jam> considering, as near as I can tell, all of the sftp commands are prefixed with FXP
[20:01] <jam> FXP_OPEN, etc
[20:01] <beuno> (seems all fxp implementations are on windows, so it doesn't give me much hope)
[20:04] <luks> heh, bzr used to have plugins in bash? (contrib/fortune)
[20:05] <jam> luks: we used to support arbitrary executables
[20:05] <jam> we might still support it
[20:05] <jam> though I've wanted to nuke that code for a while
[20:05] <jam> luks: I still see "ExternalCommand" in the codebase, though
[20:06] <jam> luks: so if you set "BZRPATH" to /usr/bin
[20:06] <jam> things could get interesting
[20:06] <jam> bzr cp
[20:06] <jam> bzr ln
[20:06] <jam> etc
[20:07] <jam> bzr python
[20:07] <jam> I guess
[20:08] <luks> bzr bzr :)
[20:08] <bialix> have another question about translations. I want to start russian translation project at launchpad. what kind of license i need to chose?
[20:08] <luks> `bzr bzr` errors with AtributeError: 'NoneType' object has no attribute 'startswith'
[20:08] <bialix> i mean russian translation of bzr docs
[20:10] <jam> bialix: well, bzr the codebase is GPL, but I don't know that we have settled on a documentation license
[20:10] <jam> bialix: ask the list, I guess
[20:24] <bialix> does launchpad already understands pack format?
[20:27] <thumper> bialix: yes
[20:27] <bialix> great
[20:27] <thumper> bialix: launchpad is currently running with 0.92
[20:27] <bialix> ok
[20:27] <beuno> thumper, really??  LP is running ? 0.92?
[20:28] <thumper> yes
[20:28] <beuno> ah, pretty cool
[20:28] <thumper> 1.0rc1 coming soon
[20:28] <bialix> why not waiting for 1.0 final?
[20:29] <thumper> bialix: if you look at the bottom of https://code.edge.launchpad.net/ you'll see "Launchpad uses Bazaar  0.92.0."
[20:30] <thumper> bialix: it may end up being that
[20:30]  * beuno is impressed with LP admins
[20:30] <jam> thumper: i just responded to your email
[20:30] <thumper> jam: ta
[20:30] <jam> thumper: can you give me the output of "locale" on that machine?
[20:30] <jam> I think it is just using a locale that doesn't support all unicode characters
[20:30] <jam> like iso-8859-1 instead of UTF-8
[20:31] <thumper> jam: I'll ask Tom
[20:31] <bialix> thumper: thanks, now I'm too know kung-fu :-)
[20:32] <thumper> jam: Tom isn't around right now, and the other person I'd normally ask is lifeless
[20:32] <thumper> jam: emailing might be more likely to get him in a timely manner
[20:32] <jam> thumper: not a big deal
[20:33] <jam> If you don't have access that is fine
[20:33] <jam> more curiousity
[20:33] <jam> or confirming what I already believe
[21:51] <bialix> have another question about english
[21:51] <bialix> Bazaar User Guide, section "Team collaboration, central style"
[21:52] <bialix> central or centralized?
[22:05] <zeasier> this is as close as i could get to the bug i was talking about
[22:05] <zeasier> https://bugs.launchpad.net/bzr/+bug/174027
[22:05] <ubotu> Launchpad bug 174027 in bzr "Replacing a directory with a symlink fails after status" [Undecided,New]
[22:06] <zeasier> doesn't seem exactly the same
[22:07] <zeasier> but it's close enough
[22:11] <ubotu> New bug: #174027 in bzr "Replacing a directory with a symlink fails after status" [Undecided,New] https://launchpad.net/bugs/174027
[22:46] <ig1> morning
[22:56] <poolie> hello
[23:00] <jkakar> It's interesting to note that my workflow is so dependent on bzr that I find doing "basic" things terrible without it.
[23:01] <jkakar> It's one thing to intellectually think, yeah, bzr has changed the way to do things.  It's another thing to *feel* it when bzr (or parts of it like bzrtools) aren't available.
[23:01] <jkakar> Oh... uh.. bzrtools still doesn't install on gutsy. :)
[23:01] <fullermd> The phrase you're groping for the use of is "It's not MY fault the rest of the world sucks."   :p
[23:02] <jkakar> fullermd: Hah, yeah, I think you're right. :)
[23:02] <dato> jkakar: if you mean with bzr 1.0rc1, you could grab the package from http://packages.debian.org/sid/bzrtools. should install fine.
[23:07] <jkakar> dato: Ah, thanks, that's a good idea.
[23:26] <jml> jkakar: my problem is that it's hard to explain that.
[23:26] <fullermd> jml: I like to use copious profanity and stomping around.
[23:26] <jml> jkakar: so that the svn projects I work on will get around to upgrading.
[23:27] <fullermd> (it doesn't really work either, but it's good for the soul)
[23:27] <jml> heh
[23:27] <jml> I was about to say that :)
[23:32] <jkakar> jml: I have a very hard time explaining it, too.
[23:33] <jkakar> jml: The experience I've had with Bazaar is that branch-based development is a better way to do things than shared-branch development.  I usually try to communicate the benefits of branch-based development and then talk about Bazaar as a tool to help effectively practice it.
[23:34] <jkakar> jml: So far the results are that the people I've talked seem to believe me about the benefits of branch-based development but want to use Subversion to implement it.
[23:34] <fullermd> Which would be kinda fun to watch from the outside, if they didn't drag you into it.
[23:35] <jkakar> jml: The other problem is that some of people are Windows developers and the lack of a solid GUI is a show-stopper.  CLIs are not acceptable and I don't think it's reasonable (or possible) to change that in a Windows-based environment.
[23:36] <jkakar> One of the other big problems I seem to run into when trying to advocate branch-based development is that existing projects often have deployment warts (particularly when it comes to databases) that make switching between branches hard.  Overcoming those problems is usually seen as expensive and, when you have no experience with branch-based development and why it's good, hard to justify.
[23:38] <abentley> Evening, all.
[23:49] <naitandu> hello everyone