[12:10] <ubotu> New bug: #151731 in bzr "bzr merge puts entire ChangeLog from other branch into conflict, rather than just the diff cherry-picked" [Undecided,New]  https://launchpad.net/bugs/151731
[12:25] <james_w> Keybuk: I think that may be intended behaviour, I'm going to ask for clarification.
[12:28] <Keybuk> james_w: that implies that backporting a one line fix, with a minor conflict, can create a very very pessimal merge
[12:28] <james_w> Keybuk: yes, it does.
[12:29] <Keybuk> I find it hard to understand why this behaviour would be "intended"
[12:52] <jeremyb> lastlog -clear
[01:11] <igc> morning all
[01:16] <acuster> aha, he's asleep. Sensible lad.
[01:16] <acuster> ciao
[01:23] <lifeless> something whack with my link apparently
[01:23] <lifeless> sorry I was offline..
[01:24] <keir> lifeless, hey
[01:24] <lifeless> hi keir
[01:24] <keir> jam helped me add a bit to http://bazaar-vcs.org/DataStructures
[01:26] <keir> also, just to confirm: .iix is inventory index, and the two node refs are (history parent refs) then (delta parents)? and delta parents is empty if it's a fulltext?
[01:26] <keir> and same for .tix text indexes?
[01:27] <lifeless> yes
[01:27] <lifeless> I'd like to drop the history parent refs for .iix
[01:27] <jelmer> keir: revisions can contain custom properties as well
[01:27] <lifeless> it only really needs delta parents, but I have not had time yet
[01:27] <jelmer> keir: Never mind, missed the "at least"
[01:27] <keir> lifeless, great
[01:28] <lifeless> looks like it won't happen for this format I suspect, but who knows
[01:28] <keir> jelmer, yes, i realize that
[01:28] <keir> so in the new packs, the inventory is just a knit of a XML file?
[01:28] <keir> but stored in a pack file
[01:32] <lifeless> packs haven't changed the way inventories are managed in the repository other than the same transform done to revisions, signatures and file content
[01:33] <keir> ok
[01:33] <lifeless> that is the index is changed from a .kndx to many .iix's
[01:33] <keir> right
[01:33] <keir> and one iix may have many inventories in it
[01:33] <acuster> Hey all, what's the difference between bzr svn-import and bzr branch (with bzr-svn installed and from an svn repo)?
[01:34] <lifeless> right, one for each inventory knit record in the associated .pack
[01:34] <lifeless> acuster: bzr svn-import may help out
[01:34] <jelmer> acuster: svn-import clones all branches in a repository, branch just one
[01:35] <acuster> oh. Hey jelmer.
[01:35] <acuster> I tried a bzr co and got a core dump :-)
[01:35] <lifeless> jelmer: packs have partial index reads now
[01:36] <lifeless> jelmer: I haven't analysed your callgrind yet though
[01:36] <jelmer> lifeless: cool - what does that mean though ? :-)
[01:36] <jelmer> acuster: on a public repository?
[01:37] <lifeless> jelmer: if you only need one file read, you don't parse all the index data now
[01:37] <jelmer> lifeless: faster incremental push/pull?
[01:37] <jelmer> ah, k
[01:37] <acuster> yeah. svn.geotools.org/geotools/trunk
[01:37] <jelmer> http:// .. ?
[01:37] <acuster> the same one that was giving me a weird state after a branch (had a Removed: section)
[01:38] <acuster> yeah
[01:38] <lifeless> abentley: around? feeling better?
[01:38] <acuster> I don't think it does svn:// but am asking
[01:38] <abentley> Yeah.
[01:40] <acuster> its an old version of subversion 1.1.4
[01:40] <eolo999> hi, do you know how to branch with bzr+ssh on a non-default sshd port?
[01:41] <acuster> jelmer, actually, it looks like I tried to co into a blank directory (was not initialized as bzr). That gave:
[01:41] <eolo999> I changed my default sshd port due to bot attacks and now i can't branch using bzr+ssh protocol
[01:42] <acuster> python: /build/buildd/subversion-1.4.3dfsg1/subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion `is_canonical(path, len)' failed.
[01:42] <acuster> and dumped core (not sure of what)
[01:42] <jelmer> acuster, what version of bzr-svn are you running?
[01:42] <jelmer> acuster: what was the exact command you were running?
[01:42] <acuster> 0.4.2-1
[01:43] <acuster> mkdir somedir
[01:43] <acuster> cd somedir
[01:43] <acuster> bzr co http://svn.geotools.org/geotools/trunk/
[01:43] <acuster> and 0.90-1bazaar1
[01:44] <jelmer> acuster: please try a more recent version
[01:44] <jelmer> acuster: 0.4.2-1 had some issues with http:// repositories
[01:44] <acuster> your latest conflicts with the latest I can get
[01:45] <acuster> that was the best I could do on feisty but perhaps there are packages elsewhere
[01:45] <eolo999> bzr+ssh always try to connect on port 22 or i can change it?
[01:45] <acuster> aha
[01:45] <jelmer> acuster: the bazaar-vcs.org repository should have more recent packages
[01:45] <Odd_Bloke> eolo999: Have you tried 'bzr+ssh://<host>:<port>/...'?
[01:45] <jelmer> eolo999: bzr+ssh://host:port/... doesn't work?
[01:46] <eolo999> tried... but i always mistype, go and check...
[01:46] <acuster> jelmer, later than your .debs?
[01:48] <eolo999> i'm really sorry i wrote address.comi... as i told you: i ALWAYS mystype
[01:48] <jelmer> acuster: it has a more up-to-date version of the bzr package
[01:48] <jelmer> see http://bazaar-vcs.org/DistroDownloads
[01:49] <acuster> thank you
[01:49] <lifeless> abentley: so this merge base thing.
[01:49] <Odd_Bloke> eolo999: Heh, "mystype". ^_^
[01:49] <abentley> Mmm?
[01:50] <lifeless> I think we're picking worse merge bases that we did in 0.17ish times
[01:50] <lifeless> IIRC you identified a problem with the current logic
[01:50] <lifeless> but my memory is hazy
[01:51] <lifeless> I mailed you a particular case that stood out for me, where it clearly took a history shortcut
[01:51] <abentley> My memory is hazy too.
[01:51] <lifeless> heh
[01:51] <lifeless> if you could look in your inbox, oh a week or so back
[01:53] <abentley> Okay.  If you could run graph-ancestry on these things it would be helpful.
[01:53] <lifeless> sure thing
[01:53] <abentley> That's usually where I start.
[01:53] <lifeless> I don't know what your debug process is for this I guess
[01:54] <lifeless> oct 5th
[01:54] <lifeless> I'll just paste the revids here for my easy access
[01:55] <lifeless> robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv
[01:55] <lifeless>  pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl
[01:55] <abentley> Heh, on my mail client, that's oct 4th.
[01:55] <lifeless> :) in the old world :)
[01:56] <eolo999> thanks guys...bye
[01:56] <lifeless> bye
[01:57] <abentley> lifeless: Has your revision been merged into mainline?
[01:57] <lifeless> no
[01:57] <abentley> Is it the packs branch?
[01:57] <lifeless> yup
[01:57] <lifeless> http://people.ubuntu.com/~robertc/baz2.0/repository
[01:58] <lifeless> I'll pull it to the knits version for you, one sec
[01:58] <abentley> Oh, I just stated a pull of the knits version.
[01:58] <lifeless> its just annotating the recent work, will be a few minutes
[01:59] <lifeless> hmm, it would be nice to show that in some senses
[01:59] <abentley> Like a progress indicator?
[01:59] <lifeless> yeah
[02:00] <lifeless> [== ]  Pull phase 0/2
[02:00] <lifeless> not enough info to understand why it is slow
[02:01] <keir> i remember way back in the day jam was working on a progress bar refactor
[02:03] <abentley> Well, when I really thought about it, it generalized to a "status" API.
[02:04] <abentley> Where status data about multiple operations could be transmitted, instead of this linear 0-1 scale.
[02:06] <lifeless> so jam-laptop what do you think you'll hack on now, between diapers that is
[02:07] <abentley> lifeless: I think the problem with the graph code was that if it hits a null revision it can stop before it discovers some comon ancestors.
[02:07] <lifeless> wow
[02:08] <lifeless> that png breaks display
[02:08] <abentley> lifeless: You can set --max-distance to reduce the graph complexity.
[02:08] <lifeless> yah doing so now :)
[02:09] <abentley> I thought it was already defaulted, but maybe not.
[02:10] <poolie> good morning abentley, lifeless
[02:10] <abentley> Morning.
[02:11] <lifeless> abentley: if it is defaulted, its too big for me :)
[02:11] <lifeless> anyhow
[02:11] <lifeless> I did track the ancestry using log
[02:11] <lifeless> and it was definately a shortcut, as I mention in my mail
[02:12] <lifeless> the push is maybe 10% done?
[02:12] <lifeless> if you have a packs branch you can probably pull it directly more easily ;)
[02:12] <abentley> Well, what I want to know is do we have a bunch of LCAs.
[02:12] <abentley> My packs branch is quite out of date, I think
[02:13] <lifeless> okies
[02:13] <lifeless> >>> import bzrlib.repository
[02:13] <lifeless> >>> r = bzrlib.repository.Repository.open('..')
[02:13] <lifeless> >>> tips = ['robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv', 'pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl'] 
[02:14] <lifeless> >>> g = r.get_graph()
[02:14] <lifeless> I'm all set to answer any questions :)
[02:14] <lifeless> >>> g.heads(tips)
[02:14] <lifeless> set(['pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv'] )
[02:16] <abentley> sry.
[02:18] <abentley> g.find_lca('pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv' )
[02:18] <acuster> bzr co (using bzr-svn) should just get the last revision or is also building the same history as bzr branch?
[02:18] <lifeless> >>> g.find_lca(tips[0] , tips[1] )
[02:18] <lifeless> set(['robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc'] )
[02:19] <abentley> acuster: By default, it will be fetching the branch history.  You want that, unless you have very fast (LAN-speed) access to the server.
[02:19] <abentley> lifeless: Do you think that's an accurate result?
[02:20] <lifeless> does 'bzr find-merge-base' show the actual merge base used ?
[02:20] <abentley> lifeless: Yes, I updated it when I changed the graph code.
[02:20] <acuster> abentley, is that smaller than the stuff fetched for a 'bzr branch' or the same?
[02:21] <abentley> acuster: the same.
[02:21] <lifeless> robertc@robertcollins.net-20071004220007-6tb7pyeknkhpnfyq
[02:21] <jelmer> acuster: just the last revision is possible using 'bzr checkout --lightweight'
[02:21] <abentley> lifeless: I think maybe you're misunderstanding the question?
[02:21] <acuster> but I can't branch from the checkout right? checkouts are just dumb trees?
[02:22] <abentley> acuster: You can actually branch from a checkout.
[02:22] <lifeless> abentley: should the merge base it chose be one of the lca's ?
[02:22] <abentley> Even if it's just a dumb tree.
[02:22] <acuster> lol. so what is the difference?
[02:22] <lifeless> back shortly, need greasy food
[02:22] <acuster> jelmer, bzr 0.91-2 and 0.4.3 (in plugins/) doesn't crash
[02:22] <lifeless> abentley: ok, the conversion to knit data has completed
[02:23] <abentley> lifeless: no.  If those really are the LCAs, the algorithm will find *their* lca.
[02:23] <jelmer> acuster: ok, cool
[02:23] <acuster> thanks for your help
[02:24] <abentley> acuster: A branch is an independent line of development.  A checkout is a copy of the source tree, and when you commit in it, the results go into another branch.
[02:24] <abentley> lifeless: pulling
[02:25] <acuster> but you can branch from a checkout and checkout from a branch? Cool. I did not expect that kind of flexibility
[02:25] <lifeless> abentley: its likely that there are two valid lca's there - this branch merges from many
[02:28] <abentley> What does g.find_lca('robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc') give you?
[02:42] <abentley> I ran it myself, and it gives 'pqm@pqm.ubuntu.com-20070823005013-ada9x55rc31yiwou', which is the value from your email.
[02:43] <abentley> So unless we're hitting a bug in the find_lca stage, the algorithm is behaving as intended.
[02:45] <lifeless> back
[02:45] <lifeless> ok
[02:46] <lifeless> I think the problem then is this recursive definition
[02:46] <lifeless> either of the first lca's is a reasonable base
[02:46] <lifeless> their common point is however much further back
[02:46] <acuster> okay, let's let the bzr branch run. Thanks all for your help. goodnight
[02:47] <abentley> lifeless: The problem is that neither one of them is a reasonable base.
[02:47] <lifeless> our old code would have picked one though ?
[02:47] <abentley> Yes.
[02:47] <lifeless> and as a user, our old code felt much nicer
[02:47] <abentley> Silently discarding differences in the other.
[02:48] <lifeless> huh?
[02:50] <abentley> Each side makes different merge resolutions.  If you choose a too-recent merge base, one side's merge resolutions are silently discarded.
[02:51] <lifeless> if the base is merged into both sides, that's not the impact
[02:51] <abentley> Yes it is.
[02:51] <abentley> It's a damned-if-you-do, damned-if-you-don't situation.
[02:52] <lifeless> is there a mail/wiki/doc that lays this out?
[02:52] <abentley> Yeah.  1 sec.
[02:54] <abentley> http://article.gmane.org/gmane.comp.version-control.monotone.devel/3256 http://article.gmane.org/gmane.comp.version-control.monotone.devel/3264
[03:31] <lifeless> abentley: I see
[03:31] <lifeless> abentley: hmm I think
[03:33] <lifeless> abentley: so concretely, I've been dealing with the same conflicts when merging bzr.dev -> branch A -> B -> C -> packs
[03:33] <lifeless> and by the third and forth *repeated resolution* I'm entirely over them
[03:34] <abentley> So you've got four branches in flight?
[03:34] <lifeless> yah
[03:34] <lifeless> not right now, but earlier on when I had many patches outstanding
[03:34] <lifeless> earlier this week I had three
[03:34] <lifeless> bzr.dev, readv, index, repository
[03:34] <abentley> Well, as long as you're always merging in one direction, that shouldn't give criss-cross.
[03:35] <lifeless> well
[03:35] <lifeless> repository gets merges direct from bzr.dev
[03:35] <lifeless> I also get conflicts in the other direction
[03:36] <lifeless> when I merge bzr.dev to repository, after something from e.g. readv was merged to bzr.dev
[03:36] <lifeless> the reason repository gets merges from bzr.dev is that I only create these other branches when I realise I need to change some infrastructure
[03:36] <lifeless> so I then branch bzr.dev to e.g. readv
[03:39] <abentley> So I internalized Nathaniel's observations a long time ago.  My solution was always "so don't do three-way".
[03:39] <abentley> I really do feel like there's no good option, so I picked the one that didn't lead to silently discarding changes.
[03:41] <lifeless> so the conceptual problem I have here
[03:42] <lifeless> is that a criss cross graph that doesn't have criss-cross changes should be safe
[03:43] <lifeless> we're getting conflicts because, to use NEWS as an example,
[03:43] <lifeless> one side actually has added a single new entry
[04:27] <poolie> woot
[04:27] <poolie> one
[04:27] <poolie> less failure
[04:41] <lifeless> :)
[04:58] <poolie> ok, i think the basis update is right, except it causes a somewhat obscure failure in  test_rio_version
[05:10] <lifeless> cool
[05:10] <poolie> the problem is that with this change, the root directory is not given the right revision on a commit
[05:18] <lifeless> uhm
[05:18] <lifeless> there are tests for setting that I'm quite sure
[05:19] <lifeless> rephrasing, I think it should be settable via the update... method, so I'd look at the delta creation I guess
[05:35] <poolie> since the delta is the only thing i changed i guess that's where the problem is
[05:35] <poolie> however, there are no really direct tests for it, so i'm adding one
[05:35] <lifeless> hmm
[05:35] <lifeless> the delta returned by record_entry_contents ?
[05:36] <poolie> i'm just thinking out loud here, not necessarily trying to distract you, btw
[05:37] <lifeless> there are some direct tests for the deltas' returned by record_entry_contents, though there are several layers there involved in making the tests easy to write
[05:39] <lifeless> thats fine, its friday avo, I'm trivially distracted
[05:39] <lifeless> btw, Portal is *cool*
[05:39] <lifeless> finished it this morning before work :)
[05:39] <poolie> yep, i tried it briefly this morning :)
[05:39] <poolie> i'm trying to maintain self control
[05:39] <poolie> :)
[05:39] <lifeless> did you lookup your steam name?
[05:39] <poolie> yby30
[05:50] <poolie> ok, so the RootCommitBuilder isn't giving back a delta for the root on the second commit
[05:51] <lifeless> thats right
[05:51] <lifeless> unless the root has changed
[05:52] <poolie> should it get a new revision on each commit, or not ?
[05:52] <poolie> some code seems to think that it should
[06:01] <lifeless> it should get a new rev on knit1 repos, but not on knit3
[06:34] <poolie> so CommitBuilder.record_entry_contents should be saying the root has changed
[06:34] <poolie> but it does not
[06:34] <poolie> in fact it seems to leave the same revision id in there
[06:35] <poolie> so, it would seem that someone else is updating the root revision id at a later time
[06:35] <poolie> and, indeed there's a _check_root method that fudges it
[06:38] <lifeless> right
[06:38] <lifeless> thats how I've currently minimised the differences
[07:05] <ubotu> New bug: #151844 in bzr "bzr info (Windows)" [Undecided,New]  https://launchpad.net/bugs/151844
[07:13] <igc> lifeless, pollie: anything you want reviewed today by me?
[07:13] <igc> poolie: ^^
[07:14] <igc> robert's bisection one looks the most important ...
[07:14] <igc> but I gather poolie is already working on that
[07:15] <poolie> i already posted some changes
[07:15] <igc> saw those
[07:17] <poolie> lifeless, ok, so the bug seems to be repository.py +296
[07:17] <poolie> assuming that there's always no delta on the root
[07:17] <poolie> which is odd
[07:23] <lifeless> well
[07:23] <lifeless> I think its 'no delta should be shown as always delta'
[07:23] <lifeless> (for non RootCommitBuilder)
[07:33] <poolie> mm?
[07:34] <lifeless> wooties
[07:34] <lifeless> I have fine grained concurrency
[07:36] <poolie> ok, i think i've fixed it
[07:36] <poolie> the commit code could do with a good scrub
[07:36] <lifeless> heh, its been getting one
[07:38] <poolie> can you tell me what this line is doing, about 269 of repo.py:
[07:39] <poolie>         if ie.revision is not None:
[07:39] <poolie>             if self._versioned_root or path != '':
[07:39] <poolie>                 # not considered for commit
[07:39] <poolie> oh nm, i see
[07:39] <lifeless> this is something I hope to fix shortly, by not passing ie's into record_entry at all
[07:39] <lifeless> but what it is doign is carryign over unmodified entries
[07:40] <lifeless> (which the commit.py code signals by keeping the ie.revision attribute from the basis)
[07:40] <lifeless> and for non versioned roots this is fallacious
[07:40] <lifeless> ok
[07:41] <lifeless> igc: poolie: fine-grained-locking packs pushed
[07:41] <lifeless> bbiab
[08:08] <lifeless> igc: yes
[08:08] <lifeless> meh
[08:08] <lifeless> i386: yes
[08:09] <i386> we have git support internally
[08:09] <i386> (sucks)
[08:09] <poolie> oh, you work there?
[08:15] <poolie> lifeless, can you please fix the permissions on /srv/www.bazaar-ng.org/rsync/bzr/bzr.dev/.bzr/checkout/dirstate
[08:15] <poolie> and the containing directories
[08:18] <lifeless> sure, whats wrong with them ?
[08:18] <poolie> they're owned by you and mode 0644
[08:18] <poolie> this seems kinda selfish :)
[08:19] <lifeless> chmod g+x enough ?
[08:20] <poolie> g+wX would be better
[08:20] <poolie> because i want to update the wt
[08:20] <lifeless> .bzr$ chmod g+wX -R .
[08:20] <poolie> and check the group too i guess
[08:20] <lifeless> group is bazng
[08:20] <lifeless> theres files there jam owns too
[08:20] <lifeless> merge-hashes for instance
[08:21] <poolie> and also the wt please
[08:21] <poolie> hrm
[08:21] <lifeless> done, huge list of errors
[08:24] <poolie> but fortunately jam's files seems group-writable
[08:25] <poolie> you seem to have made some regular files g+x
[08:25] <lifeless> bzr revert ;)
[08:25] <poolie> won't fix the controlfiles
[08:26] <lifeless> oh, but we don't care about them do we?
[08:27] <poolie> i guess it's harmless
[08:27] <poolie> just wierd
[08:27] <poolie> weird
[08:27] <lifeless> wierd is weird
[08:27] <lifeless> :)
[08:28] <poolie> find .bzr -type f -perm +0111 -user $USER -exec chmod -x {} \;
[08:43] <igc> i386: I'm a big fan of JIRA and Confluence. bzr support in JIRA and FishEye would be sweet indeed.
[08:44] <lifeless> ok, one patch sent
[08:44] <lifeless> working on index patch cleanup now
[08:53] <i386> igc: I think there is an issue on jira.atlassian.com for that
[08:53] <i386> go vote on it :)
[08:55] <poolie> lifeless, do you have a rule-of-thumb number for how long a basis_inv.iter_entries takes?
[08:56] <lifeless> uhm
[08:56] <lifeless> seconds? IIRC
[08:56] <lifeless> I saved 10 seconds at one point by removing one such loop, though it did stuff in the middle
[08:57] <lifeless> I haven't measured for entry in ..:pass
[09:14] <poolie> ok, update_etc patch sent
[09:19] <lifeless> wicked cool
[09:19] <lifeless> just finished the index changes from review, mailing now
[09:23] <lifeless> have a good weekend
[09:23] <lifeless> grab me on steam for games :)
[09:54] <poolie> night all
[10:04] <igc> night poolie
[10:04] <igc> in fact, night all - have a good weekend
[10:05] <poolie> good night igc
[12:06] <lifeless> mwhudson: hey
[12:06] <lifeless> mwhudson: please try packs again, indices are now partial-read enabled
[12:07] <mwhudson> lifeless: ok
[12:07] <mwhudson> probably not going to get to that today
[12:12] <sabdfl> lifeless: how goes the effort to land packs?
[01:29] <bialix> hi
[01:29] <bialix> someone familiar with git here?
[01:38] <lightyear> hi there.
[01:39] <lightyear> I have a question about if it is possible with bazar or I should stop searching for the feature
[01:39] <lightyear> I have remote-server (webspace) without any ssh or shell acces and want to commit the latest changes to the working dir over there.
[01:39] <lightyear> as I can see push is only updating the .bzr and not the working dir
[01:40] <CardinalFang> lightyear, Do you have any way to send files, in general?  FTP?  HTTP put?
[01:40] <lightyear> do I have any possiblity to update the working copy remotely
[01:40] <lightyear> yep. Currently I do all with ftp
[01:40] <lightyear> and the syncing with push works in generally
[01:40] <lightyear> but the working copy is not updated.
[01:41] <lightyear> is there a way to do this, CardinalFang ?
[01:41] <dato> without shell access, I've never heard of a way
[01:42] <CardinalFang> lightyear, Well, I suppose you could send a snapshot of your checked-out tree also.  Not with BZR, but with something else.
[01:42] <lightyear> the idea was, that I've only to commit the changes over ftp, because the connection is damn slow.
[01:43] <lightyear> so I've to copy that manually (doing release or the whole working-dir) outside of bazar.
[01:44] <CardinalFang> Yeah, I get it.  On the remote server, though, unless you have a way to execute arbitrary commands, then there's no way to send only metainfo and have it explode into a snapshot.
[01:44] <lightyear> so bazar is not even theoritically able to do this?
[01:45] <CardinalFang> Nothing could, no.
[01:45] <lifeless> if you can do rsync
[01:45] <lightyear> can't
[01:46] <lifeless> then there is a plugin that will rwsync the specific files across
[01:46] <lightyear> so. wait there would be a way without command-executing on the serveR?
[01:47] <lightyear> but that can't be done over a ftp-connection because it is using the algo of rsync?
[01:47] <CardinalFang> Yeah, I think rsync requires "rsync"-the-program to run on the remote end.
[01:47] <lifeless> the problem with ftp is that its very hard to get full file system behaviour
[01:47] <lifeless> night all
[01:47] <CardinalFang> g'night.
[01:48] <lightyear> night, lifeless
[01:48] <lightyear> thanks for the help
[01:49] <lightyear> afaik rsync can work over ftp....
[01:49] <lightyear> no. I need the deamon :(
[01:50] <CardinalFang> So, lightyear, if you can run programs on the far end, then your problem is solved.  Else, you have to schlep all the bits.  The far end is a dumb data-store.  You get out only what you put in.
[01:51] <lightyear> okay. thank you CardinalFang
[01:51] <lightyear> so bazar is not able to read the archive of the remote and do a checkout there. that is what I wanted to know.
[01:52] <CardinalFang> It could, but bazaar isn't there.  It's here.
[01:53] <hsn_> how python determines Codec for encoding charset on Windows?
[01:53] <hsn_> it would be nice to have it displayed in bzr version
[01:54] <lightyear> CardinalFang, would it be possible, if I write a plugin for it?
[01:57] <bialix> lightyear: it's possible to write plugin
[01:58] <lightyear> is it possible with the plugin api to write something like this is the question....
[01:58] <bialix> hsn_: looking at terminal settings
[01:59] <CardinalFang> lightyear, I'm afraid you've misunderstood.  This isn't a bazaar problem.  Your endpoint is crippled.  You could write a plugin that wraps one of dozens of tools that upload trees of files, or you could just run one of those programs directly.
[01:59] <hsn_> bialix: because when i run bzr under eclipse it seems to use incorrect ascii encoding. from command line it works fine
[02:01] <bialix> hsn_: try this: python -c "import locale; print locale.getpreferredencoding()"
[02:01] <bialix> I don't know much about eclipse, probably it run bzr with dummy stdout, that use ascii encoding
[02:02] <bialix> if you run bzr from another program with redirecting all stdin/stdout/stderr to pipe or file, then bzr internally will use encoding from locale
[02:03] <bialix> so my best guess: something wrong happens when eclipse grab output of bzr
[02:04] <bialix> hsn_: you can use very simple plugin to look at encodings that see bzr
[02:06] <bialix> or could look in .bzr.log :-)
[02:06] <hsn_> bzr is using 'ascii' encoding under eclipse. Its in error message from bzr 'ascii' codec can not encode...
[02:07] <bialix> in what command?
[02:07] <hsn_> bzr version --xml
[02:07] <bialix> C:\work\Bazaar\mydev\bzr.dev>bzr version --xml
[02:07] <bialix> bzr: ERROR: no such option: --xml
[02:08] <hsn_> you need bzrxml plugin
[02:08] <bialix> so, problem in this plugin
[02:08] <bialix> try to run plain 'bzr --no-plugins version'
[02:09] <hsn_> nope, it will do without --xml too, because bzr with ascii codec complains about non-ascii characters in pathname
[02:09] <bialix> it's very common error here: try to print non-ascii strings to stdout
[02:09] <bialix> you run with --no-plugins flag?
[02:10] <hsn_> no
[02:10] <bialix> can you try with --no-plugins?
[02:11] <hsn_> yes if i change bzr.bat
[02:11] <bialix> why for???
[02:11] <hsn_> add --no-plugins
[02:12] <bialix> you cannot run bzr from eclipse as from command line?
[02:14] <hsn_> bzr.bat is executed by eclipse-bzr plugin, i dont have source code for plugin
[02:14] <bialix> does eclipse have some sort of command to run any arbitrary program?
[02:15] <bialix> bug 131100
[02:15] <ubotu> Launchpad bug 131100 in bzr "`bzr --version` should care about encoding of stdout" [Medium,Fix released]  https://launchpad.net/bugs/131100
[02:16] <bialix> I fixed this bug for 0.91
[02:16] <bialix> and it really fixed
[02:16] <bialix> you can fix bzrxml plugin yourself though
[02:17] <hsn_> why do you think that bug is in bzrxml?
[02:18] <bialix> because it's common error of many python programmers: pretend that "print" always print to real terminal
[02:18] <bialix> and never thought about non-ascii users
[02:19] <bialix> in bzr ML there is recent patch from Lukas that fixes similar problem
[02:19] <hsn_> testing it without bzrxml plugin
[02:22] <hsn_> bzr --no-plugins version seems to work from eclipse fine, i will do more tests
[02:22] <bialix> as you wish
[02:28] <hsn_> you understand how Windows are using its 2 encoding? They use one for gui programs and second for command line programs. What kind of encoding is used for Filenames?
[02:29] <bialix> for filenames windows internally used unicode
[02:29] <bialix> but you can get it in ANSI encoding (you called it gui)
[02:30] <bialix> you can control encoding of terminal with 'chcp' command
[02:31] <bialix> it's very handy
[02:31] <hsn_> locale.getpreferedencoding() in command-line windows returns cp1250 but output seems to be in 852 encoding
[02:31] <bialix> just select Lucida Console font for terminal
[02:31] <bialix> try in terminal: chcp 1250
[02:32] <hsn_> yes chcp 1250 in console changes bzr output to 1250 too
[02:33] <bialix> so now you too know kung-fu :-)
[02:34] <hsn_> ok. now how to fix bzrxml insert calling to some locale function?
[02:34] <bialix> you read bzr ML?
[02:35] <hsn_> sometimes yes
[02:35] <bialix> one sec
[02:35] <bialix> http://bundlebuggy.aaronbentley.com/request/%3C5288a560710120333t50ad35eagccd51987e20adea5@mail.gmail.com%3E
[02:36] <bialix> you need to add line: encoding_type = 'replace' in the body of cmd_version class in bzrxml plugin
[02:37] <bialix> and change all print 'foo'
[02:37] <bialix> to: print >>self.outf, 'foo'
[02:37] <bialix> that's basically all
[02:41] <bialix> hsn_: may I ask you a question?
[02:41] <hsn_> yes
[02:41] <bialix> it seems you're novice in bzr
[02:42] <hsn_> i am using it since 0.14 or 0.15
[02:42] <bialix> oh, all 2007 :-)
[02:42] <hsn_> i used tla before
[02:43] <bialix> you don't read ML because it's not interesting or because it too devel-centric?
[02:43] <hsn_> no, because my time is limited and there are too much messages/day
[02:44] <bialix> ok, thanks
[02:46] <hsn_> i am using bzr because its easier to use than git or hg
[02:47] <bialix> you familiar with git?
[02:51] <hsn_> i used it for a while, but it was too hard for ppl working with me to learn
[02:52] <bialix> I have a question about rebase
[02:52] <bialix> how rebase deal with conflicts?
[02:52] <dato> stops rebasing, and gets you back to the shell for you to resolve them
[02:52] <dato> and then you do `bzr rebase-continue`
[02:53] <bialix> it's rebase revision by revision?
[02:54] <bialix> (probably git rebase-continue)
[02:54] <dato> oh
[02:54] <dato> sorry
[02:54] <bialix> :-)
[02:54] <bialix> it's ok
[02:54] <dato> missed the context and thought you meant rebase in bzr :)
[02:54] <bialix> I can't use svn fro the same reason
[02:54] <dato> so nothing I said applies to git
[02:55] <bialix> does we have rebase in bzr?
[02:55] <dato> plugin
[02:55] <dato> by jelmer
[02:55] <bialix> ah
[02:56] <bialix> never tried it
[02:57] <bialix> just interesting how git-rebase deal with conflicts
[02:57] <bialix> git people push too much noise about rebase
[03:01] <hsn_> i never used rebase in git
[03:03] <bialix> hsn_: you said hg is also hard to use
[03:03] <hsn_> hg is easier to use than git
[03:03] <bialix> but?
[03:05] <hsn_> there doesnt seems to be much interest in fixing hg bugs
[03:05] <dato> you mean upstream is unresponsive? or what?
[03:09] <hsn_> i want to say that if i compare speed of hg releases and speed of bugfixing, its very unlikely to get some bugs fixed soon
[03:16] <bialix> luks: ping
[05:40] <ubotu> New bug: #152008 in bzr "Ability to unmerge or revert a merge sensibly" [Undecided,New]  https://launchpad.net/bugs/152008
[09:22] <bialix> luks: ping
[09:25] <luks> hi bialix
[09:25] <bialix> hi luks
[09:25] <bialix> have a question about qdiff
[09:26] <bialix> can you give a hint where text of diff decoded to/from utf-8?
[09:26] <bialix> I need to to do something with bug 148159
[09:26] <ubotu> Launchpad bug 148159 in qbzr "qdiff and qannotate treats file content as utf-8" [Undecided,In progress]  https://launchpad.net/bugs/148159
[09:26] <luks> hmm
[09:27] <bialix> I want to introduce new branch option 'default_encoding' and use it as hint for decoding files content
[09:27] <bialix> otherwise qdiff will use utf-8
[09:27] <luks> it should be after running PatienceSequenceMatcher on it, but before passing it to Qt
[09:28] <luks> currently it's a bit hardcoded in diffview.py
[09:28] <bialix> treediff = TreeDiff(self.tree1, self.tree2, self.specific_files, complete)
[09:28] <bialix> in TreeDiff class?
[09:29] <luks> I'll need to take a look at the code
[09:29] <luks> one moment
[09:31] <bialix> there is FileDiff.make_diff method
[09:31] <bialix> my best guess it should be done here
[09:31] <luks> I'd like to do as little unicode decoding as possible
[09:32] <luks> decoding all lines of all files is a waste of CPU
[09:32] <bialix> so?
[09:34] <luks> one more moment, still thinking :)
[09:34] <bialix> Patience sequence matcher invoked in FileDiff.make_diff
[09:36] <luks> okay, decoding all lines in FileDiff.make_diff is probably the best option
[09:37] <luks> there is a bunch of unused code (html_diff_lines) and the current side-by-side diff is calculated in diffview.py
[09:37] <bialix> I'm not dare enough to delete this code
[09:37] <luks> I'll have to refactor these things, and then can be the decoding optimized
[09:37] <luks> but for now decoding all of them should be fine
[09:38] <bialix> before sequence matcher or after?
[09:38] <luks> after
[09:38] <bialix> what about this code:
[09:38] <bialix>             if old_lines and not new_lines:
[09:38] <bialix>                 self.groups = [[('delete', 0, len(old_lines), 0, 0)] ] 
[09:38] <bialix>             elif not old_lines and new_lines:
[09:38] <bialix>                 self.groups = [[('insert', 0, 0, 0, len(new_lines))] ] 
[09:40] <luks> add it after the whole block
[09:40] <luks> these ifs are just to avoid sequence matching
[09:41] <bialix> ah, try it now
[09:43] <bialix> this place try to decode line to unicde fro utf-8
[09:43] <bialix> File "C:\work\Bazaar\plugins-repo\qbzr\diffview.py", line 157, in markup_intraline_changes
[09:43] <bialix> probably this place you call hardcoded
[09:44] <bialix> and many others too
[09:45] <luks> you can remove them
[09:45] <luks> everything that calls .decode("utf-8", "replace") in diff.py or diffview.py
[09:46] <bialix> so, I do decoding in one place and remove all others from all places, right?
[09:46] <luks> yes
[09:47] <bialix> you do decode to unicode a bit too often
[09:47] <bialix> I found 3 places so far for only one file
[09:47] <bialix> qdiff for one file
[09:49] <bialix> heh, it's finally working
[09:49] <bialix> so, you have some objections for new branch config option?
[09:49] <luks> yes, I have a habit of writing extramly ugly code if it's for myself :)
[09:49] <luks> no, not at all
[09:50] <bialix> I'm inclined to use branch-level option to allow different projects have different encodings
[09:50] <bialix> because qbzr is utf-8 :-)
[09:51] <luks> it's a shame that these configs are not propagated on push/pull
[09:52] <bialix> well, another option is to have such option in revisions property
[09:52] <bialix> like --fixes or --author
[09:52] <bialix> it's require some plugin hacking
[09:52] <bialix> or just qcommit can do this :-)
[09:53] <luks> I think I'd really prefer something like .bzrprops
[09:53] <luks> but I don't mind using a branch config for now
[09:54] <luks> as long as the default is utf-8 :)
[09:54] <bialix> .bzrprops should be in past revisions, but my old revisions don't have it
[09:55] <bialix> it's the problem for me
[09:55] <bialix> it will be show-stopper to browse history
[09:55] <luks> oh, right
[09:55] <bialix> of course, default always be utf-8
[09:56] <bialix> it's inevitable
[09:56] <bialix> luks: do you have in mind some roadmap for qbzr?
[09:57] <luks> no, the development was driven only by what I currently needed
[09:58] <bialix> well, so I'll try to scratch my itches and help you if possible
[09:59] <luks> I really didn't intend to create some generally usable tool
[09:59] <bialix> why not?
[09:59] <luks> I just wanted to use bzr, and but I was too used to tortoisesvn
[10:00] <luks> so I needed something similar
[10:00] <bialix> before bzr I used TortoiseCVS
[10:00] <luks> and I still consider it my own personal tool :)
[10:01] <luks> I tried to use bzr-gtk before, but it was just too weird
[10:01] <luks> but I liked the idea of using a command line shell instead of windows explorer
[10:01] <luks> (with GUI for commit, etc.)
[10:02] <bialix> I'm happy with FAR and using bzr from command line a joy for me
[10:02] <bialix> but I'm thinking about convenient log/diff viewer, and your QBzr fit my expectation on 100%
[10:03] <bialix> but now I feel that qstatus will be very good thing
[10:04] <bialix> and I agree with you about gtk
[10:04] <bialix> on windows it's very unfriendly
[10:05] <luks> the problems I had with it are not directly gtk-related
[10:05] <bialix> but overall design?
[10:05] <luks> GUI design
[10:06] <luks> not even GNOME uses dialogs like that
[10:06] <luks> but I didn't feel like hacking a gtk app on windows
[10:06] <bialix> hmm, have no experiance with gnome
[10:06] <luks> and now I ended up using Qt on GNOME :)
[10:07] <luks> because it simply looks more native than bzr-gtk, even though gtk is the first class citizen in GNOME
[10:07] <bialix> I think it's a very funnily
[10:08] <luks> another thing that annoyed me about bzr-gtk is the order of Ok and Cancel buttons
[10:08] <luks> don't know why, but if I'm on GNOME I expect the buttons to follow the GNOME standard, and on Windows the Windows standards
[10:08] <bialix> you're using standard windows scheme in QBzr
[10:09] <luks> and somehow have no problem switching between them
[10:09] <luks> bialix: no, it uses different scheme on each platform
[10:09] <bialix> are you sure with my latest changes?
[10:09] <luks> yes
[10:09] <bialix> but... how???
[10:10] <luks> QDialogButtonBox handles that
[10:10] <bialix> wow
[10:10] <bialix> it's magic
[10:10] <bialix> I never realize this
[10:10] <luks> so on GNOME I have [Cancel]  [Ok]  and on Windows [Ok]  [Cancel] 
[10:10] <bialix> cool
[10:13] <bialix> luks: I'm planning to put QBzr in standard standalone windows installer with some others plugins
[10:13] <luks> hmm
[10:13] <luks> wouldn't it be too big?
[10:13] <bialix> with gtk it will be bigger as twice of qbzr
[10:14] <bialix> currently your installer is 3MB
[10:14] <bialix> bzr.exe installer is about 4.5 MB
[10:15] <bialix> so I'll have in the end about 7 MB installer
[10:15] <bialix> I'm also concerned about size
[10:16] <bialix> may be there will be 2 standalone installers: bare bzr.exe and big pack with some popular plugins
[10:18] <bialix> and if you're planning to switch to bzr version scheme one day, I'm happy to include Queue.py std module to bzr.exe
[10:18] <luks> Queue.py is no longer required
[10:19] <luks> but no, I don't plan to have releases synchronized with bzr
[10:19] <bialix> but you planning to use multithreading...
[10:19] <luks> maybe...
[10:20] <luks> I'd rather keep backward compatibility than force users to specific version of bzr
[10:21] <bialix> bzrlib API is very fast changing sometimes. how you achieve backward compatibility?
[10:21] <luks> well, most of the API is not changing
[10:23] <bialix> it's good
[10:24] <CardinalFang> Ick.  Cloning from a remote repo.  I don't have enough space in /tmp to contain a whole repo.
[10:25] <bialix> luks: good night, thanks for help with qdiff, I'll prepare the patch
[10:27] <CardinalFang> remote.RemoteRepository._get_tarball downloads a tarball into a "tempfile"-created temp file.  Could it instead (uncompress+) untar the stream as it goes, instead of making a file and then operating on the file?
[10:28] <luks> CardinalFang: currently no, but the next version should support streaming natively
[10:29] <CardinalFang> NameError: name "next version" is undefined
[10:30] <CardinalFang> Is that v2?  Or 0.9z?
[10:30] <luks> 0.92
[10:30] <CardinalFang> Ah, cool.  Thanks.
[10:31] <luks> at least there is a patch for that, I assume it's going to be included
[10:34] <CardinalFang> I see in tempfile.py that it reads from env variables.  Is there a way to poke the environment for only bzr, e.g., with ~/.bazaar/bazaar.conf .
[10:34] <CardinalFang> ?
[10:35] <luks> no idea
[10:39] <CardinalFang> Hmm, doesn't look like it.
[10:51] <CardinalFang> Aw crap, it's not local.  The server makes a tarball too.  That's where I'm running out of space.  Crap.  Crap crap crap.
[11:29] <lifeless> CardinalFang: if you apply the hpss patch from spiv, its on BB, to the client and server, then the tarball method won't be used
[11:30] <CardinalFang> lifeless, Thanks.
[11:37] <weigon> I don't get my head around why I should to a checkout instead of a branch
[11:38] <weigon> I have read http://bazaar-vcs.org/CheckoutTutorial but I'm not really sold
[11:39] <Peng> weigon: You should use a branch. The only reason to use a checkout is if you absolutely can't retrain your brain to use bzr commands instead of svn commands. :)
[11:39] <weigon> ah, so I'm fine :)
[11:39] <Peng> weigon: Also, lightweight checkouts are useful for when you don't want a copy of the entire history.
[11:52] <hsn_> Peng: bzr update in checkout does equivalent of svn up ?
[11:52] <Peng> hsn_: Yes.
[11:54] <LeoNerd> It can even be abbreviated 'bzr up'
[11:59] <hsn_> testing it