=== Alien_Freak [n=sam@adsl-69-209-211-93.dsl.chcgil.ameritech.net] has joined #bzr [12:10] 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 === joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx] has joined #bzr [12:25] Keybuk: I think that may be intended behaviour, I'm going to ask for clarification. [12:28] james_w: that implies that backporting a one line fix, with a minor conflict, can create a very very pessimal merge [12:28] Keybuk: yes, it does. === danigm [n=danigm@82.159.240.59.static.user.ono.com] has left #bzr ["Saliendo"] [12:29] I find it hard to understand why this behaviour would be "intended" === fog [n=fog@debian/developer/fog] has left #bzr [] === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === cprov is now known as cprov-out [12:52] lastlog -clear === igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr [01:11] morning all === acuster [n=acuster@29.Red-81-41-242.staticIP.rima-tde.net] has joined #bzr [01:16] aha, he's asleep. Sensible lad. [01:16] ciao === acuster [n=acuster@29.Red-81-41-242.staticIP.rima-tde.net] has left #bzr ["bye"] === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr [01:23] something whack with my link apparently [01:23] sorry I was offline.. [01:24] lifeless, hey [01:24] hi keir [01:24] jam helped me add a bit to http://bazaar-vcs.org/DataStructures [01:26] 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] and same for .tix text indexes? [01:27] yes [01:27] I'd like to drop the history parent refs for .iix [01:27] keir: revisions can contain custom properties as well [01:27] it only really needs delta parents, but I have not had time yet [01:27] keir: Never mind, missed the "at least" [01:27] lifeless, great [01:28] looks like it won't happen for this format I suspect, but who knows [01:28] jelmer, yes, i realize that [01:28] so in the new packs, the inventory is just a knit of a XML file? [01:28] but stored in a pack file === acuster [n=acuster@29.Red-81-41-242.staticIP.rima-tde.net] has joined #bzr [01:32] 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] ok [01:33] that is the index is changed from a .kndx to many .iix's [01:33] right [01:33] and one iix may have many inventories in it [01:33] Hey all, what's the difference between bzr svn-import and bzr branch (with bzr-svn installed and from an svn repo)? [01:34] right, one for each inventory knit record in the associated .pack [01:34] acuster: bzr svn-import may help out [01:34] acuster: svn-import clones all branches in a repository, branch just one [01:35] oh. Hey jelmer. [01:35] I tried a bzr co and got a core dump :-) [01:35] jelmer: packs have partial index reads now [01:36] jelmer: I haven't analysed your callgrind yet though [01:36] lifeless: cool - what does that mean though ? :-) [01:36] acuster: on a public repository? [01:37] jelmer: if you only need one file read, you don't parse all the index data now [01:37] lifeless: faster incremental push/pull? [01:37] ah, k [01:37] yeah. svn.geotools.org/geotools/trunk [01:37] http:// .. ? [01:37] the same one that was giving me a weird state after a branch (had a Removed: section) [01:38] yeah [01:38] abentley: around? feeling better? [01:38] I don't think it does svn:// but am asking [01:38] Yeah. === eolo999 [n=eolo999@host-62-10-124-70.cust-adsl.tiscali.it] has joined #bzr [01:40] its an old version of subversion 1.1.4 === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr [01:40] hi, do you know how to branch with bzr+ssh on a non-default sshd port? [01:41] jelmer, actually, it looks like I tried to co into a blank directory (was not initialized as bzr). That gave: [01:41] I changed my default sshd port due to bot attacks and now i can't branch using bzr+ssh protocol [01:42] python: /build/buildd/subversion-1.4.3dfsg1/subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion `is_canonical(path, len)' failed. [01:42] and dumped core (not sure of what) [01:42] acuster, what version of bzr-svn are you running? [01:42] acuster: what was the exact command you were running? [01:42] 0.4.2-1 [01:43] mkdir somedir [01:43] cd somedir [01:43] bzr co http://svn.geotools.org/geotools/trunk/ [01:43] and 0.90-1bazaar1 [01:44] acuster: please try a more recent version [01:44] acuster: 0.4.2-1 had some issues with http:// repositories [01:44] your latest conflicts with the latest I can get [01:45] that was the best I could do on feisty but perhaps there are packages elsewhere [01:45] bzr+ssh always try to connect on port 22 or i can change it? [01:45] aha [01:45] acuster: the bazaar-vcs.org repository should have more recent packages [01:45] eolo999: Have you tried 'bzr+ssh://:/...'? [01:45] eolo999: bzr+ssh://host:port/... doesn't work? [01:46] tried... but i always mistype, go and check... === eolo999 is checking [01:46] jelmer, later than your .debs? [01:48] i'm really sorry i wrote address.comi... as i told you: i ALWAYS mystype [01:48] acuster: it has a more up-to-date version of the bzr package [01:48] see http://bazaar-vcs.org/DistroDownloads [01:49] thank you [01:49] abentley: so this merge base thing. [01:49] eolo999: Heh, "mystype". ^_^ [01:49] Mmm? [01:50] I think we're picking worse merge bases that we did in 0.17ish times [01:50] IIRC you identified a problem with the current logic [01:50] but my memory is hazy [01:51] I mailed you a particular case that stood out for me, where it clearly took a history shortcut [01:51] My memory is hazy too. [01:51] heh [01:51] if you could look in your inbox, oh a week or so back [01:53] Okay. If you could run graph-ancestry on these things it would be helpful. [01:53] sure thing [01:53] That's usually where I start. [01:53] I don't know what your debug process is for this I guess === lifeless digs around in sent mail [01:54] oct 5th [01:54] I'll just paste the revids here for my easy access [01:55] robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv [01:55] pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl [01:55] Heh, on my mail client, that's oct 4th. [01:55] :) in the old world :) [01:56] thanks guys...bye [01:56] bye === eolo999 go to bed [01:57] lifeless: Has your revision been merged into mainline? [01:57] no [01:57] Is it the packs branch? [01:57] yup [01:57] http://people.ubuntu.com/~robertc/baz2.0/repository [01:58] I'll pull it to the knits version for you, one sec [01:58] Oh, I just stated a pull of the knits version. [01:58] its just annotating the recent work, will be a few minutes [01:59] hmm, it would be nice to show that in some senses [01:59] Like a progress indicator? [01:59] yeah [02:00] [== ] Pull phase 0/2 [02:00] not enough info to understand why it is slow [02:01] i remember way back in the day jam was working on a progress bar refactor === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr [02:03] Well, when I really thought about it, it generalized to a "status" API. [02:04] Where status data about multiple operations could be transmitted, instead of this linear 0-1 scale. === i386 [n=jdumay@202.47.1.18] has joined #bzr [02:06] so jam-laptop what do you think you'll hack on now, between diapers that is [02:07] 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] wow [02:08] that png breaks display === p4tux [n=p4tux@189.169.95.23] has joined #bzr [02:08] lifeless: You can set --max-distance to reduce the graph complexity. [02:08] yah doing so now :) [02:09] I thought it was already defaulted, but maybe not. === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr [02:10] good morning abentley, lifeless [02:10] Morning. [02:11] abentley: if it is defaulted, its too big for me :) [02:11] anyhow [02:11] I did track the ancestry using log [02:11] and it was definately a shortcut, as I mention in my mail [02:12] the push is maybe 10% done? [02:12] if you have a packs branch you can probably pull it directly more easily ;) [02:12] Well, what I want to know is do we have a bunch of LCAs. [02:12] My packs branch is quite out of date, I think [02:13] okies [02:13] >>> import bzrlib.repository [02:13] >>> r = bzrlib.repository.Repository.open('..') [02:13] >>> tips = ['robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv', 'pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl'] [02:14] >>> g = r.get_graph() [02:14] I'm all set to answer any questions :) [02:14] >>> g.heads(tips) [02:14] set(['pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv'] ) [02:16] sry. === cbarrett [n=cbarrett@adium/cbarrett] has left #bzr [] [02:18] g.find_lca('pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv' ) [02:18] bzr co (using bzr-svn) should just get the last revision or is also building the same history as bzr branch? [02:18] >>> g.find_lca(tips[0] , tips[1] ) [02:18] set(['robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc'] ) [02:19] acuster: By default, it will be fetching the branch history. You want that, unless you have very fast (LAN-speed) access to the server. === pete__c [n=pete@032-437-364.area7.spcsdns.net] has joined #bzr [02:19] lifeless: Do you think that's an accurate result? [02:20] does 'bzr find-merge-base' show the actual merge base used ? [02:20] lifeless: Yes, I updated it when I changed the graph code. [02:20] abentley, is that smaller than the stuff fetched for a 'bzr branch' or the same? [02:21] acuster: the same. [02:21] robertc@robertcollins.net-20071004220007-6tb7pyeknkhpnfyq [02:21] acuster: just the last revision is possible using 'bzr checkout --lightweight' [02:21] lifeless: I think maybe you're misunderstanding the question? [02:21] but I can't branch from the checkout right? checkouts are just dumb trees? [02:22] acuster: You can actually branch from a checkout. [02:22] abentley: should the merge base it chose be one of the lca's ? [02:22] Even if it's just a dumb tree. [02:22] lol. so what is the difference? [02:22] back shortly, need greasy food [02:22] jelmer, bzr 0.91-2 and 0.4.3 (in plugins/) doesn't crash [02:22] abentley: ok, the conversion to knit data has completed [02:23] lifeless: no. If those really are the LCAs, the algorithm will find *their* lca. [02:23] acuster: ok, cool [02:23] thanks for your help [02:24] 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] lifeless: pulling [02:25] but you can branch from a checkout and checkout from a branch? Cool. I did not expect that kind of flexibility [02:25] abentley: its likely that there are two valid lca's there - this branch merges from many [02:28] What does g.find_lca('robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc') give you? [02:42] I ran it myself, and it gives 'pqm@pqm.ubuntu.com-20070823005013-ada9x55rc31yiwou', which is the value from your email. [02:43] So unless we're hitting a bug in the find_lca stage, the algorithm is behaving as intended. [02:45] back [02:45] ok [02:46] I think the problem then is this recursive definition [02:46] either of the first lca's is a reasonable base [02:46] their common point is however much further back [02:46] okay, let's let the bzr branch run. Thanks all for your help. goodnight [02:47] lifeless: The problem is that neither one of them is a reasonable base. [02:47] our old code would have picked one though ? [02:47] Yes. [02:47] and as a user, our old code felt much nicer [02:47] Silently discarding differences in the other. [02:48] huh? [02:50] Each side makes different merge resolutions. If you choose a too-recent merge base, one side's merge resolutions are silently discarded. [02:51] if the base is merged into both sides, that's not the impact [02:51] Yes it is. [02:51] It's a damned-if-you-do, damned-if-you-don't situation. [02:52] is there a mail/wiki/doc that lays this out? [02:52] Yeah. 1 sec. [02:54] http://article.gmane.org/gmane.comp.version-control.monotone.devel/3256 http://article.gmane.org/gmane.comp.version-control.monotone.devel/3264 === jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr [03:31] abentley: I see [03:31] abentley: hmm I think [03:33] abentley: so concretely, I've been dealing with the same conflicts when merging bzr.dev -> branch A -> B -> C -> packs [03:33] and by the third and forth *repeated resolution* I'm entirely over them [03:34] So you've got four branches in flight? [03:34] yah [03:34] not right now, but earlier on when I had many patches outstanding [03:34] earlier this week I had three [03:34] bzr.dev, readv, index, repository [03:34] Well, as long as you're always merging in one direction, that shouldn't give criss-cross. [03:35] well [03:35] repository gets merges direct from bzr.dev [03:35] I also get conflicts in the other direction [03:36] when I merge bzr.dev to repository, after something from e.g. readv was merged to bzr.dev [03:36] 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] so I then branch bzr.dev to e.g. readv [03:39] So I internalized Nathaniel's observations a long time ago. My solution was always "so don't do three-way". [03:39] I really do feel like there's no good option, so I picked the one that didn't lead to silently discarding changes. === jamesh__ is now known as jamesh [03:41] so the conceptual problem I have here [03:42] is that a criss cross graph that doesn't have criss-cross changes should be safe [03:43] we're getting conflicts because, to use NEWS as an example, [03:43] one side actually has added a single new entry === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr [04:27] woot [04:27] one [04:27] less failure === bigdo1 is now known as bigdog_ [04:41] :) === BasicMac [n=BasicOSX@warden.real-time.com] has joined #bzr === BasicMac is now known as BasicOX [04:58] ok, i think the basis update is right, except it causes a somewhat obscure failure in test_rio_version [05:10] cool [05:10] the problem is that with this change, the root directory is not given the right revision on a commit [05:18] uhm [05:18] there are tests for setting that I'm quite sure [05:19] rephrasing, I think it should be settable via the update... method, so I'd look at the delta creation I guess === abentle1 [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr [05:35] since the delta is the only thing i changed i guess that's where the problem is [05:35] however, there are no really direct tests for it, so i'm adding one [05:35] hmm [05:35] the delta returned by record_entry_contents ? [05:36] i'm just thinking out loud here, not necessarily trying to distract you, btw [05:37] 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] thats fine, its friday avo, I'm trivially distracted [05:39] btw, Portal is *cool* [05:39] finished it this morning before work :) [05:39] yep, i tried it briefly this morning :) [05:39] i'm trying to maintain self control [05:39] :) [05:39] did you lookup your steam name? [05:39] yby30 [05:50] ok, so the RootCommitBuilder isn't giving back a delta for the root on the second commit [05:51] thats right [05:51] unless the root has changed [05:52] should it get a new revision on each commit, or not ? [05:52] some code seems to think that it should === igc food [06:01] it should get a new rev on knit1 repos, but not on knit3 === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr === asak_ [n=alexis@201-1-4-222.dsl.telesp.net.br] has joined #bzr [06:34] so CommitBuilder.record_entry_contents should be saying the root has changed [06:34] but it does not [06:34] in fact it seems to leave the same revision id in there [06:35] so, it would seem that someone else is updating the root revision id at a later time [06:35] and, indeed there's a _check_root method that fudges it === asak_ is now known as asak [06:38] right [06:38] thats how I've currently minimised the differences === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr [07:05] New bug: #151844 in bzr "bzr info (Windows)" [Undecided,New] https://launchpad.net/bugs/151844 [07:13] lifeless, pollie: anything you want reviewed today by me? [07:13] poolie: ^^ [07:14] robert's bisection one looks the most important ... [07:14] but I gather poolie is already working on that [07:15] i already posted some changes [07:15] saw those [07:17] lifeless, ok, so the bug seems to be repository.py +296 [07:17] assuming that there's always no delta on the root [07:17] which is odd [07:23] well [07:23] I think its 'no delta should be shown as always delta' [07:23] (for non RootCommitBuilder) [07:33] mm? [07:34] wooties [07:34] I have fine grained concurrency [07:36] ok, i think i've fixed it [07:36] the commit code could do with a good scrub [07:36] heh, its been getting one [07:38] can you tell me what this line is doing, about 269 of repo.py: [07:39] if ie.revision is not None: [07:39] if self._versioned_root or path != '': [07:39] # not considered for commit [07:39] oh nm, i see [07:39] this is something I hope to fix shortly, by not passing ie's into record_entry at all [07:39] but what it is doign is carryign over unmodified entries [07:40] (which the commit.py code signals by keeping the ie.revision attribute from the basis) [07:40] and for non versioned roots this is fallacious [07:40] ok [07:41] igc: poolie: fine-grained-locking packs pushed [07:41] bbiab === i386 thinks Atlassian's fisheye should support bzr [08:08] igc: yes [08:08] meh [08:08] i386: yes [08:09] we have git support internally [08:09] (sucks) [08:09] oh, you work there? [08:15] lifeless, can you please fix the permissions on /srv/www.bazaar-ng.org/rsync/bzr/bzr.dev/.bzr/checkout/dirstate [08:15] and the containing directories [08:18] sure, whats wrong with them ? [08:18] they're owned by you and mode 0644 [08:18] this seems kinda selfish :) [08:19] chmod g+x enough ? [08:20] g+wX would be better [08:20] because i want to update the wt [08:20] .bzr$ chmod g+wX -R . [08:20] and check the group too i guess [08:20] group is bazng [08:20] theres files there jam owns too [08:20] merge-hashes for instance [08:21] and also the wt please [08:21] hrm [08:21] done, huge list of errors [08:24] but fortunately jam's files seems group-writable [08:25] you seem to have made some regular files g+x [08:25] bzr revert ;) [08:25] won't fix the controlfiles [08:26] oh, but we don't care about them do we? [08:27] i guess it's harmless [08:27] just wierd [08:27] weird [08:27] wierd is weird [08:27] :) [08:28] find .bzr -type f -perm +0111 -user $USER -exec chmod -x {} \; === thumper-office is now known as thumper [08:43] i386: I'm a big fan of JIRA and Confluence. bzr support in JIRA and FishEye would be sweet indeed. [08:44] ok, one patch sent [08:44] working on index patch cleanup now === metze_asleep is now known as metze [08:53] igc: I think there is an issue on jira.atlassian.com for that [08:53] go vote on it :) === mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr [08:55] lifeless, do you have a rule-of-thumb number for how long a basis_inv.iter_entries takes? [08:56] uhm [08:56] seconds? IIRC [08:56] I saved 10 seconds at one point by removing one such loop, though it did stuff in the middle [08:57] I haven't measured for entry in ..:pass [09:14] ok, update_etc patch sent [09:19] wicked cool [09:19] just finished the index changes from review, mailing now [09:23] have a good weekend [09:23] grab me on steam for games :) === bialix [n=chatzill@77.109.23.189] has joined #bzr === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === pbor [n=urk@host25-25-dynamic.60-82-r.retail.telecomitalia.it] has joined #bzr === mvo [n=egon@p54A66DFB.dip.t-dialin.net] has joined #bzr === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr [09:54] night all [10:04] night poolie [10:04] in fact, night all - have a good weekend [10:05] good night igc === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr === i386 [n=james@ppp239-169.static.internode.on.net] has joined #bzr === g0ph3r [n=g0ph3r@p57A0B85A.dip0.t-ipconnect.de] has joined #bzr === Starting logfile irclogs/bzr.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #bzr === Topic for #bzr: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.91 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d === Topic (#bzr): set by poolie at Wed Sep 26 07:07:44 2007 === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr === jelmer_ is now known as jelmer [12:06] mwhudson: hey [12:06] mwhudson: please try packs again, indices are now partial-read enabled [12:07] lifeless: ok [12:07] probably not going to get to that today [12:12] lifeless: how goes the effort to land packs? === danigm [n=danigm@82.159.240.59.static.user.ono.com] has joined #bzr === Roua1 [n=Raidenn@dsl-240-35-129.telkomadsl.co.za] has joined #bzr === Roua1 [n=Raidenn@dsl-240-35-129.telkomadsl.co.za] has left #bzr [] === bialix [n=chatzill@77.109.23.189] has joined #bzr [01:29] hi [01:29] someone familiar with git here? === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr === lightyear [n=lightyea@90.163.23.135] has joined #bzr [01:38] hi there. [01:39] I have a question about if it is possible with bazar or I should stop searching for the feature [01:39] 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] as I can see push is only updating the .bzr and not the working dir [01:40] lightyear, Do you have any way to send files, in general? FTP? HTTP put? [01:40] do I have any possiblity to update the working copy remotely [01:40] yep. Currently I do all with ftp [01:40] and the syncing with push works in generally [01:40] but the working copy is not updated. [01:41] is there a way to do this, CardinalFang ? [01:41] without shell access, I've never heard of a way [01:42] lightyear, Well, I suppose you could send a snapshot of your checked-out tree also. Not with BZR, but with something else. [01:42] the idea was, that I've only to commit the changes over ftp, because the connection is damn slow. [01:43] so I've to copy that manually (doing release or the whole working-dir) outside of bazar. [01:44] 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] so bazar is not even theoritically able to do this? [01:45] Nothing could, no. [01:45] if you can do rsync [01:45] can't [01:46] then there is a plugin that will rwsync the specific files across [01:46] so. wait there would be a way without command-executing on the serveR? [01:47] but that can't be done over a ftp-connection because it is using the algo of rsync? [01:47] Yeah, I think rsync requires "rsync"-the-program to run on the remote end. [01:47] the problem with ftp is that its very hard to get full file system behaviour [01:47] night all [01:47] g'night. === NamNguyen [n=NamNguye@cm38.delta196.maxonline.com.sg] has joined #bzr [01:48] night, lifeless [01:48] thanks for the help [01:49] afaik rsync can work over ftp.... [01:49] no. I need the deamon :( [01:50] 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] okay. thank you CardinalFang [01:51] so bazar is not able to read the archive of the remote and do a checkout there. that is what I wanted to know. === hsn_ [n=chatzill@234.114.broadband5.iol.cz] has joined #bzr [01:52] It could, but bazaar isn't there. It's here. [01:53] how python determines Codec for encoding charset on Windows? === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr [01:53] it would be nice to have it displayed in bzr version [01:54] CardinalFang, would it be possible, if I write a plugin for it? === lightyear is able to write python code and is very interested in that kind of a feature === danigm [n=danigm@82.159.240.59.static.user.ono.com] has left #bzr ["Saliendo"] [01:57] lightyear: it's possible to write plugin [01:58] is it possible with the plugin api to write something like this is the question.... [01:58] hsn_: looking at terminal settings === fog [n=fog@debian/developer/fog] has joined #bzr [01:59] 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] bialix: because when i run bzr under eclipse it seems to use incorrect ascii encoding. from command line it works fine [02:01] hsn_: try this: python -c "import locale; print locale.getpreferredencoding()" [02:01] I don't know much about eclipse, probably it run bzr with dummy stdout, that use ascii encoding [02:02] 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] so my best guess: something wrong happens when eclipse grab output of bzr [02:04] hsn_: you can use very simple plugin to look at encodings that see bzr [02:06] or could look in .bzr.log :-) [02:06] bzr is using 'ascii' encoding under eclipse. Its in error message from bzr 'ascii' codec can not encode... [02:07] in what command? [02:07] bzr version --xml [02:07] C:\work\Bazaar\mydev\bzr.dev>bzr version --xml [02:07] bzr: ERROR: no such option: --xml [02:08] you need bzrxml plugin [02:08] so, problem in this plugin [02:08] try to run plain 'bzr --no-plugins version' [02:09]