=== Alien_Freak [n=sam@adsl-69-209-211-93.dsl.chcgil.ameritech.net] has joined #bzr
ubotuNew 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/15173112:10
=== joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx] has joined #bzr
james_wKeybuk: I think that may be intended behaviour, I'm going to ask for clarification.12:25
Keybukjames_w: that implies that backporting a one line fix, with a minor conflict, can create a very very pessimal merge12:28
james_wKeybuk: yes, it does.12:28
=== danigm [n=danigm@] has left #bzr ["Saliendo"]
KeybukI find it hard to understand why this behaviour would be "intended"12:29
=== 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
jeremyblastlog -clear12:52
=== igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr
igcmorning all01:11
=== acuster [n=acuster@29.Red-81-41-242.staticIP.rima-tde.net] has joined #bzr
acusteraha, he's asleep. Sensible lad.01:16
=== 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
lifelesssomething whack with my link apparently01:23
lifelesssorry I was offline..01:23
keirlifeless, hey01:24
lifelesshi keir01:24
keirjam helped me add a bit to http://bazaar-vcs.org/DataStructures01:24
keiralso, 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
keirand same for .tix text indexes?01:26
lifelessI'd like to drop the history parent refs for .iix01:27
jelmerkeir: revisions can contain custom properties as well01:27
lifelessit only really needs delta parents, but I have not had time yet01:27
jelmerkeir: Never mind, missed the "at least"01:27
keirlifeless, great01:27
lifelesslooks like it won't happen for this format I suspect, but who knows01:28
keirjelmer, yes, i realize that01:28
keirso in the new packs, the inventory is just a knit of a XML file?01:28
keirbut stored in a pack file01:28
=== acuster [n=acuster@29.Red-81-41-242.staticIP.rima-tde.net] has joined #bzr
lifelesspacks haven't changed the way inventories are managed in the repository other than the same transform done to revisions, signatures and file content01:32
lifelessthat is the index is changed from a .kndx to many .iix's01:33
keirand one iix may have many inventories in it01:33
acusterHey all, what's the difference between bzr svn-import and bzr branch (with bzr-svn installed and from an svn repo)?01:33
lifelessright, one for each inventory knit record in the associated .pack01:34
lifelessacuster: bzr svn-import may help out01:34
jelmeracuster: svn-import clones all branches in a repository, branch just one01:34
acusteroh. Hey jelmer.01:35
acusterI tried a bzr co and got a core dump :-)01:35
lifelessjelmer: packs have partial index reads now01:35
lifelessjelmer: I haven't analysed your callgrind yet though01:36
jelmerlifeless: cool - what does that mean though ? :-)01:36
jelmeracuster: on a public repository?01:36
lifelessjelmer: if you only need one file read, you don't parse all the index data now01:37
jelmerlifeless: faster incremental push/pull?01:37
jelmerah, k01:37
acusteryeah. svn.geotools.org/geotools/trunk01:37
jelmerhttp:// .. ?01:37
acusterthe same one that was giving me a weird state after a branch (had a Removed: section)01:37
lifelessabentley: around? feeling better?01:38
acusterI don't think it does svn:// but am asking01:38
=== eolo999 [n=eolo999@host-62-10-124-70.cust-adsl.tiscali.it] has joined #bzr
acusterits an old version of subversion 1.1.401:40
=== jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr
eolo999hi, do you know how to branch with bzr+ssh on a non-default sshd port?01:40
acusterjelmer, actually, it looks like I tried to co into a blank directory (was not initialized as bzr). That gave:01:41
eolo999I changed my default sshd port due to bot attacks and now i can't branch using bzr+ssh protocol01:41
acusterpython: /build/buildd/subversion-1.4.3dfsg1/subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion `is_canonical(path, len)' failed.01:42
acusterand dumped core (not sure of what)01:42
jelmeracuster, what version of bzr-svn are you running?01:42
jelmeracuster: what was the exact command you were running?01:42
acustermkdir somedir01:43
acustercd somedir01:43
acusterbzr co http://svn.geotools.org/geotools/trunk/01:43
acusterand 0.90-1bazaar101:43
jelmeracuster: please try a more recent version01:44
jelmeracuster: 0.4.2-1 had some issues with http:// repositories01:44
acusteryour latest conflicts with the latest I can get01:44
acusterthat was the best I could do on feisty but perhaps there are packages elsewhere01:45
eolo999bzr+ssh always try to connect on port 22 or i can change it?01:45
jelmeracuster: the bazaar-vcs.org repository should have more recent packages01:45
Odd_Blokeeolo999: Have you tried 'bzr+ssh://<host>:<port>/...'?01:45
jelmereolo999: bzr+ssh://host:port/... doesn't work?01:45
eolo999tried... but i always mistype, go and check...01:46
=== eolo999 is checking
acusterjelmer, later than your .debs?01:46
eolo999i'm really sorry i wrote address.comi... as i told you: i ALWAYS mystype01:48
jelmeracuster: it has a more up-to-date version of the bzr package01:48
jelmersee http://bazaar-vcs.org/DistroDownloads01:48
acusterthank you01:49
lifelessabentley: so this merge base thing.01:49
Odd_Blokeeolo999: Heh, "mystype". ^_^01:49
lifelessI think we're picking worse merge bases that we did in 0.17ish times01:50
lifelessIIRC you identified a problem with the current logic01:50
lifelessbut my memory is hazy01:50
lifelessI mailed you a particular case that stood out for me, where it clearly took a history shortcut01:51
abentleyMy memory is hazy too.01:51
lifelessif you could look in your inbox, oh a week or so back01:51
abentleyOkay.  If you could run graph-ancestry on these things it would be helpful.01:53
lifelesssure thing01:53
abentleyThat's usually where I start.01:53
lifelessI don't know what your debug process is for this I guess01:53
=== lifeless digs around in sent mail
lifelessoct 5th01:54
lifelessI'll just paste the revids here for my easy access01:54
lifeless pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl01:55
abentleyHeh, on my mail client, that's oct 4th.01:55
lifeless:) in the old world :)01:55
eolo999thanks guys...bye01:56
=== eolo999 go to bed
abentleylifeless: Has your revision been merged into mainline?01:57
abentleyIs it the packs branch?01:57
lifelessI'll pull it to the knits version for you, one sec01:58
abentleyOh, I just stated a pull of the knits version.01:58
lifelessits just annotating the recent work, will be a few minutes01:58
lifelesshmm, it would be nice to show that in some senses01:59
abentleyLike a progress indicator?01:59
lifeless[== ]  Pull phase 0/202:00
lifelessnot enough info to understand why it is slow02:00
keiri remember way back in the day jam was working on a progress bar refactor02:01
=== 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
abentleyWell, when I really thought about it, it generalized to a "status" API.02:03
abentleyWhere status data about multiple operations could be transmitted, instead of this linear 0-1 scale.02:04
=== i386 [n=jdumay@] has joined #bzr
lifelessso jam-laptop what do you think you'll hack on now, between diapers that is02:06
abentleylifeless: 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
lifelessthat png breaks display02:08
=== p4tux [n=p4tux@] has joined #bzr
abentleylifeless: You can set --max-distance to reduce the graph complexity.02:08
lifelessyah doing so now :)02:08
abentleyI thought it was already defaulted, but maybe not.02:09
=== BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr
pooliegood morning abentley, lifeless02:10
lifelessabentley: if it is defaulted, its too big for me :)02:11
lifelessI did track the ancestry using log02:11
lifelessand it was definately a shortcut, as I mention in my mail02:11
lifelessthe push is maybe 10% done?02:12
lifelessif you have a packs branch you can probably pull it directly more easily ;)02:12
abentleyWell, what I want to know is do we have a bunch of LCAs.02:12
abentleyMy packs branch is quite out of date, I think02:12
lifeless>>> import bzrlib.repository02:13
lifeless>>> r = bzrlib.repository.Repository.open('..')02:13
lifeless>>> tips = ['robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv', 'pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl'] 02:13
lifeless>>> g = r.get_graph()02:14
lifelessI'm all set to answer any questions :)02:14
lifeless>>> g.heads(tips)02:14
lifelessset(['pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv'] )02:14
=== cbarrett [n=cbarrett@adium/cbarrett] has left #bzr []
abentleyg.find_lca('pqm@pqm.ubuntu.com-20071004174812-z1zg35r1vssltydl', 'robertc@robertcollins.net-20071003084403-e8j4dft472ww2ucv' )02:18
acusterbzr 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
lifelessset(['robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc'] )02:18
abentleyacuster: 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
=== pete__c [n=pete@032-437-364.area7.spcsdns.net] has joined #bzr
abentleylifeless: Do you think that's an accurate result?02:19
lifelessdoes 'bzr find-merge-base' show the actual merge base used ?02:20
abentleylifeless: Yes, I updated it when I changed the graph code.02:20
acusterabentley, is that smaller than the stuff fetched for a 'bzr branch' or the same?02:20
abentleyacuster: the same.02:21
jelmeracuster: just the last revision is possible using 'bzr checkout --lightweight'02:21
abentleylifeless: I think maybe you're misunderstanding the question?02:21
acusterbut I can't branch from the checkout right? checkouts are just dumb trees?02:21
abentleyacuster: You can actually branch from a checkout.02:22
lifelessabentley: should the merge base it chose be one of the lca's ?02:22
abentleyEven if it's just a dumb tree.02:22
acusterlol. so what is the difference?02:22
lifelessback shortly, need greasy food02:22
acusterjelmer, bzr 0.91-2 and 0.4.3 (in plugins/) doesn't crash02:22
lifelessabentley: ok, the conversion to knit data has completed02:22
abentleylifeless: no.  If those really are the LCAs, the algorithm will find *their* lca.02:23
jelmeracuster: ok, cool02:23
acusterthanks for your help02:23
abentleyacuster: 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
abentleylifeless: pulling02:24
acusterbut you can branch from a checkout and checkout from a branch? Cool. I did not expect that kind of flexibility02:25
lifelessabentley: its likely that there are two valid lca's there - this branch merges from many02:25
abentleyWhat does g.find_lca('robertc@robertcollins.net-20071003061506-2hbze42e1sokni8j', 'robertc@robertcollins.net-20070827041949-br263tkuxayldxoc') give you?02:28
abentleyI ran it myself, and it gives 'pqm@pqm.ubuntu.com-20070823005013-ada9x55rc31yiwou', which is the value from your email.02:42
abentleySo unless we're hitting a bug in the find_lca stage, the algorithm is behaving as intended.02:43
lifelessI think the problem then is this recursive definition02:46
lifelesseither of the first lca's is a reasonable base02:46
lifelesstheir common point is however much further back02:46
acusterokay, let's let the bzr branch run. Thanks all for your help. goodnight02:46
abentleylifeless: The problem is that neither one of them is a reasonable base.02:47
lifelessour old code would have picked one though ?02:47
lifelessand as a user, our old code felt much nicer02:47
abentleySilently discarding differences in the other.02:47
abentleyEach side makes different merge resolutions.  If you choose a too-recent merge base, one side's merge resolutions are silently discarded.02:50
lifelessif the base is merged into both sides, that's not the impact02:51
abentleyYes it is.02:51
abentleyIt's a damned-if-you-do, damned-if-you-don't situation.02:51
lifelessis there a mail/wiki/doc that lays this out?02:52
abentleyYeah.  1 sec.02:52
abentleyhttp://article.gmane.org/gmane.comp.version-control.monotone.devel/3256 http://article.gmane.org/gmane.comp.version-control.monotone.devel/326402:54
=== jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr
=== yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr
lifelessabentley: I see03:31
lifelessabentley: hmm I think03:31
lifelessabentley: so concretely, I've been dealing with the same conflicts when merging bzr.dev -> branch A -> B -> C -> packs03:33
lifelessand by the third and forth *repeated resolution* I'm entirely over them03:33
abentleySo you've got four branches in flight?03:34
lifelessnot right now, but earlier on when I had many patches outstanding03:34
lifelessearlier this week I had three03:34
lifelessbzr.dev, readv, index, repository03:34
abentleyWell, as long as you're always merging in one direction, that shouldn't give criss-cross.03:34
lifelessrepository gets merges direct from bzr.dev03:35
lifelessI also get conflicts in the other direction03:35
lifelesswhen I merge bzr.dev to repository, after something from e.g. readv was merged to bzr.dev03:36
lifelessthe reason repository gets merges from bzr.dev is that I only create these other branches when I realise I need to change some infrastructure03:36
lifelessso I then branch bzr.dev to e.g. readv03:36
abentleySo I internalized Nathaniel's observations a long time ago.  My solution was always "so don't do three-way".03:39
abentleyI really do feel like there's no good option, so I picked the one that didn't lead to silently discarding changes.03:39
=== jamesh__ is now known as jamesh
lifelessso the conceptual problem I have here03:41
lifelessis that a criss cross graph that doesn't have criss-cross changes should be safe03:42
lifelesswe're getting conflicts because, to use NEWS as an example,03:43
lifelessone side actually has added a single new entry03:43
=== BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr
=== jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr
poolieless failure04:27
=== bigdo1 is now known as bigdog_
=== BasicMac [n=BasicOSX@warden.real-time.com] has joined #bzr
=== BasicMac is now known as BasicOX
poolieok, i think the basis update is right, except it causes a somewhat obscure failure in  test_rio_version04:58
pooliethe problem is that with this change, the root directory is not given the right revision on a commit05:10
lifelessthere are tests for setting that I'm quite sure05:18
lifelessrephrasing, I think it should be settable via the update... method, so I'd look at the delta creation I guess05:19
=== abentle1 [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr
pooliesince the delta is the only thing i changed i guess that's where the problem is05:35
pooliehowever, there are no really direct tests for it, so i'm adding one05:35
lifelessthe delta returned by record_entry_contents ?05:35
pooliei'm just thinking out loud here, not necessarily trying to distract you, btw05:36
lifelessthere 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 write05:37
lifelessthats fine, its friday avo, I'm trivially distracted05:39
lifelessbtw, Portal is *cool*05:39
lifelessfinished it this morning before work :)05:39
poolieyep, i tried it briefly this morning :)05:39
pooliei'm trying to maintain self control05:39
lifelessdid you lookup your steam name?05:39
poolieok, so the RootCommitBuilder isn't giving back a delta for the root on the second commit05:50
lifelessthats right05:51
lifelessunless the root has changed05:51
poolieshould it get a new revision on each commit, or not ?05:52
pooliesome code seems to think that it should05:52
=== igc food
lifelessit should get a new rev on knit1 repos, but not on knit306:01
=== jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr
=== asak_ [n=alexis@201-1-4-222.dsl.telesp.net.br] has joined #bzr
poolieso CommitBuilder.record_entry_contents should be saying the root has changed06:34
pooliebut it does not06:34
pooliein fact it seems to leave the same revision id in there06:34
poolieso, it would seem that someone else is updating the root revision id at a later time06:35
poolieand, indeed there's a _check_root method that fudges it06:35
=== asak_ is now known as asak
lifelessthats how I've currently minimised the differences06:38
=== 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
ubotuNew bug: #151844 in bzr "bzr info (Windows)" [Undecided,New]  https://launchpad.net/bugs/15184407:05
igclifeless, pollie: anything you want reviewed today by me?07:13
igcpoolie: ^^07:13
igcrobert's bisection one looks the most important ...07:14
igcbut I gather poolie is already working on that07:14
pooliei already posted some changes07:15
igcsaw those07:15
poolielifeless, ok, so the bug seems to be repository.py +29607:17
poolieassuming that there's always no delta on the root07:17
pooliewhich is odd07:17
lifelessI think its 'no delta should be shown as always delta'07:23
lifeless(for non RootCommitBuilder)07:23
lifelessI have fine grained concurrency07:34
poolieok, i think i've fixed it07:36
pooliethe commit code could do with a good scrub07:36
lifelessheh, its been getting one07:36
pooliecan you tell me what this line is doing, about 269 of repo.py:07:38
poolie        if ie.revision is not None:07:39
poolie            if self._versioned_root or path != '':07:39
poolie                # not considered for commit07:39
poolieoh nm, i see07:39
lifelessthis is something I hope to fix shortly, by not passing ie's into record_entry at all07:39
lifelessbut what it is doign is carryign over unmodified entries07:39
lifeless(which the commit.py code signals by keeping the ie.revision attribute from the basis)07:40
lifelessand for non versioned roots this is fallacious07:40
lifelessigc: poolie: fine-grained-locking packs pushed07:41
=== i386 thinks Atlassian's fisheye should support bzr
lifelessigc: yes08:08
lifelessi386: yes08:08
i386we have git support internally08:09
poolieoh, you work there?08:09
poolielifeless, can you please fix the permissions on /srv/www.bazaar-ng.org/rsync/bzr/bzr.dev/.bzr/checkout/dirstate08:15
poolieand the containing directories08:15
lifelesssure, whats wrong with them ?08:18
pooliethey're owned by you and mode 064408:18
pooliethis seems kinda selfish :)08:18
lifelesschmod g+x enough ?08:19
poolieg+wX would be better08:20
pooliebecause i want to update the wt08:20
lifeless.bzr$ chmod g+wX -R .08:20
poolieand check the group too i guess08:20
lifelessgroup is bazng08:20
lifelesstheres files there jam owns too08:20
lifelessmerge-hashes for instance08:20
poolieand also the wt please08:21
lifelessdone, huge list of errors08:21
pooliebut fortunately jam's files seems group-writable08:24
poolieyou seem to have made some regular files g+x08:25
lifelessbzr revert ;)08:25
pooliewon't fix the controlfiles08:25
lifelessoh, but we don't care about them do we?08:26
pooliei guess it's harmless08:27
pooliejust wierd08:27
lifelesswierd is weird08:27
pooliefind .bzr -type f -perm +0111 -user $USER -exec chmod -x {} \;08:28
=== thumper-office is now known as thumper
igci386: I'm a big fan of JIRA and Confluence. bzr support in JIRA and FishEye would be sweet indeed.08:43
lifelessok, one patch sent08:44
lifelessworking on index patch cleanup now08:44
=== metze_asleep is now known as metze
i386igc: I think there is an issue on jira.atlassian.com for that08:53
i386go vote on it :)08:53
=== mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr
poolielifeless, do you have a rule-of-thumb number for how long a basis_inv.iter_entries takes?08:55
lifelessseconds? IIRC08:56
lifelessI saved 10 seconds at one point by removing one such loop, though it did stuff in the middle08:56
lifelessI haven't measured for entry in ..:pass08:57
poolieok, update_etc patch sent09:14
lifelesswicked cool09:19
lifelessjust finished the index changes from review, mailing now09:19
lifelesshave a good weekend09:23
lifelessgrab me on steam for games :)09:23
=== bialix [n=chatzill@] 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
poolienight all09:54
igcnight poolie10:04
igcin fact, night all - have a good weekend10:04
pooliegood night igc10:05
=== 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
lifelessmwhudson: hey12:06
lifelessmwhudson: please try packs again, indices are now partial-read enabled12:06
mwhudsonlifeless: ok12:07
mwhudsonprobably not going to get to that today12:07
sabdfllifeless: how goes the effort to land packs?12:12
=== danigm [n=danigm@] 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@] has joined #bzr
bialixsomeone familiar with git here?01:29
=== EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr
=== lightyear [n=lightyea@] has joined #bzr
lightyearhi there.01:38
lightyearI have a question about if it is possible with bazar or I should stop searching for the feature01:39
lightyearI 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
lightyearas I can see push is only updating the .bzr and not the working dir01:39
CardinalFanglightyear, Do you have any way to send files, in general?  FTP?  HTTP put?01:40
lightyeardo I have any possiblity to update the working copy remotely01:40
lightyearyep. Currently I do all with ftp01:40
lightyearand the syncing with push works in generally01:40
lightyearbut the working copy is not updated.01:40
lightyearis there a way to do this, CardinalFang ?01:41
datowithout shell access, I've never heard of a way01:41
CardinalFanglightyear, Well, I suppose you could send a snapshot of your checked-out tree also.  Not with BZR, but with something else.01:42
lightyearthe idea was, that I've only to commit the changes over ftp, because the connection is damn slow.01:42
lightyearso I've to copy that manually (doing release or the whole working-dir) outside of bazar.01:43
CardinalFangYeah, 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
lightyearso bazar is not even theoritically able to do this?01:44
CardinalFangNothing could, no.01:45
lifelessif you can do rsync01:45
lifelessthen there is a plugin that will rwsync the specific files across01:46
lightyearso. wait there would be a way without command-executing on the serveR?01:46
lightyearbut that can't be done over a ftp-connection because it is using the algo of rsync?01:47
CardinalFangYeah, I think rsync requires "rsync"-the-program to run on the remote end.01:47
lifelessthe problem with ftp is that its very hard to get full file system behaviour01:47
lifelessnight all01:47
=== NamNguyen [n=NamNguye@cm38.delta196.maxonline.com.sg] has joined #bzr
lightyearnight, lifeless01:48
lightyearthanks for the help01:48
lightyearafaik rsync can work over ftp....01:49
lightyearno. I need the deamon :(01:49
CardinalFangSo, 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:50
lightyearokay. thank you CardinalFang01:51
lightyearso bazar is not able to read the archive of the remote and do a checkout there. that is what I wanted to know.01:51
=== hsn_ [n=chatzill@234.114.broadband5.iol.cz] has joined #bzr
CardinalFangIt could, but bazaar isn't there.  It's here.01:52
hsn_how python determines Codec for encoding charset on Windows?01:53
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
hsn_it would be nice to have it displayed in bzr version01:53
lightyearCardinalFang, would it be possible, if I write a plugin for it?01:54
=== lightyear is able to write python code and is very interested in that kind of a feature
=== danigm [n=danigm@] has left #bzr ["Saliendo"]
bialixlightyear: it's possible to write plugin01:57
lightyearis it possible with the plugin api to write something like this is the question....01:58
bialixhsn_: looking at terminal settings01:58
=== fog [n=fog@debian/developer/fog] has joined #bzr
CardinalFanglightyear, 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 fine01:59
bialixhsn_: try this: python -c "import locale; print locale.getpreferredencoding()"02:01
bialixI don't know much about eclipse, probably it run bzr with dummy stdout, that use ascii encoding02:01
bialixif you run bzr from another program with redirecting all stdin/stdout/stderr to pipe or file, then bzr internally will use encoding from locale02:02
bialixso my best guess: something wrong happens when eclipse grab output of bzr02:03
bialixhsn_: you can use very simple plugin to look at encodings that see bzr02:04
bialixor 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:06
bialixin what command?02:07
hsn_bzr version --xml02:07
bialixC:\work\Bazaar\mydev\bzr.dev>bzr version --xml02:07
bialixbzr: ERROR: no such option: --xml02:07
hsn_you need bzrxml plugin02:08
bialixso, problem in this plugin02:08
bialixtry to run plain 'bzr --no-plugins version'02:08
hsn_nope, it will do without --xml too, because bzr with ascii codec complains about non-ascii characters in pathname02:09
bialixit's very common error here: try to print non-ascii strings to stdout02:09
bialixyou run with --no-plugins flag?02:09
bialixcan you try with --no-plugins?02:10
hsn_yes if i change bzr.bat02:11
bialixwhy for???02:11
hsn_add --no-plugins02:11
bialixyou cannot run bzr from eclipse as from command line?02:12
hsn_bzr.bat is executed by eclipse-bzr plugin, i dont have source code for plugin02:14
bialixdoes eclipse have some sort of command to run any arbitrary program?02:14
bialixbug 13110002:15
ubotuLaunchpad bug 131100 in bzr "`bzr --version` should care about encoding of stdout" [Medium,Fix released]  https://launchpad.net/bugs/13110002:15
bialixI fixed this bug for 0.9102:16
bialixand it really fixed02:16
bialixyou can fix bzrxml plugin yourself though02:16
hsn_why do you think that bug is in bzrxml?02:17
bialixbecause it's common error of many python programmers: pretend that "print" always print to real terminal02:18
bialixand never thought about non-ascii users02:18
bialixin bzr ML there is recent patch from Lukas that fixes similar problem02:19
hsn_testing it without bzrxml plugin02:19
hsn_bzr --no-plugins version seems to work from eclipse fine, i will do more tests02:22
bialixas you wish02:22
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:28
bialixfor filenames windows internally used unicode02:29
bialixbut you can get it in ANSI encoding (you called it gui)02:29
bialixyou can control encoding of terminal with 'chcp' command02:30
bialixit's very handy02:31
hsn_locale.getpreferedencoding() in command-line windows returns cp1250 but output seems to be in 852 encoding02:31
bialixjust select Lucida Console font for terminal02:31
bialixtry in terminal: chcp 125002:31
hsn_yes chcp 1250 in console changes bzr output to 1250 too02:32
bialixso now you too know kung-fu :-)02:33
hsn_ok. now how to fix bzrxml insert calling to some locale function?02:34
bialixyou read bzr ML?02:34
hsn_sometimes yes02:35
bialixone sec02:35
bialixyou need to add line: encoding_type = 'replace' in the body of cmd_version class in bzrxml plugin02:36
bialixand change all print 'foo'02:37
bialixto: print >>self.outf, 'foo'02:37
bialixthat's basically all02:37
=== keir [n=keir@206-248-157-128.dsl.teksavvy.com] has joined #bzr
bialixhsn_: may I ask you a question?02:41
bialixit seems you're novice in bzr02:41
hsn_i am using it since 0.14 or 0.1502:42
bialixoh, all 2007 :-)02:42
hsn_i used tla before02:42
bialixyou 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/day02:43
bialixok, thanks02:44
=== bigdo1 is now known as bigdog_
hsn_i am using bzr because its easier to use than git or hg02:46
bialixyou familiar with git?02:47
=== fog [n=fog@debian/developer/fog] has joined #bzr
hsn_i used it for a while, but it was too hard for ppl working with me to learn02:51
bialixI have a question about rebase02:52
bialixhow rebase deal with conflicts?02:52
datostops rebasing, and gets you back to the shell for you to resolve them02:52
datoand then you do `bzr rebase-continue`02:52
bialixit's rebase revision by revision?02:53
bialix(probably git rebase-continue)02:54
bialixit's ok02:54
datomissed the context and thought you meant rebase in bzr :)02:54
bialixI can't use svn fro the same reason02:54
datoso nothing I said applies to git02:54
bialixdoes we have rebase in bzr?02:55
datoby jelmer02:55
bialixnever tried it02:56
bialixjust interesting how git-rebase deal with conflicts02:57
bialixgit people push too much noise about rebase02:57
hsn_i never used rebase in git03:01
bialixhsn_: you said hg is also hard to use03:03
hsn_hg is easier to use than git03:03
hsn_there doesnt seems to be much interest in fixing hg bugs03:05
datoyou mean upstream is unresponsive? or what?03:05
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 soon03:09
=== keir [n=keir@206-248-159-112.dsl.teksavvy.com] has joined #bzr
=== abentley [n=abentley@bas2-toronto02-1279462552.dsl.bell.ca] has joined #bzr
bialixluks: ping03:16
=== jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr
=== jelmer_ is now known as jelmer
=== herzel104 [i=herzel@gateway/tor/x-78e09278caccec4d] has joined #bzr
=== jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr
=== jelmer_ is now known as jelmer
=== nir [n=nir@moinmoin/fan/nir] has joined #bzr
=== corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr
=== lightyear [n=lightyea@] has left #bzr ["einer]
=== keir_ [n=keir@76-10-155-123.dsl.teksavvy.com] has joined #bzr
=== bratsche [n=cody@adsl-68-94-23-66.dsl.rcsntx.swbell.net] has joined #bzr
=== niemeyer [n=niemeyer@200-138-54-64.ctame705.dsl.brasiltelecom.net.br] has joined #bzr
=== jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr
=== jelmer_ is now known as jelmer
=== p4tux [n=p4tux@] has joined #bzr
=== kaaloo [n=luis@ATuileries-153-1-54-188.w83-202.abo.wanadoo.fr] has joined #bzr
=== RichardL is now known as rml
=== orospakr [n=orospakr@] has joined #bzr
=== jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr
=== jelmer_ is now known as jelmer
=== jelmer is now known as bloa
=== bloa is now known as jelmer
=== mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr
=== keir_ is now known as keir
=== corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr
ubotuNew bug: #152008 in bzr "Ability to unmerge or revert a merge sensibly" [Undecided,New]  https://launchpad.net/bugs/15200805:40
=== rml [n=Skippy@] has joined #bzr
=== BasicOSX [n=BasicOSX@gatekeeper.real-time.com] has joined #bzr
=== fog [n=fog@debian/developer/fog] has left #bzr []
=== BasicOSX [n=BasicOSX@gatekeeper.real-time.com] has joined #bzr
=== herzel104 [i=herzel@gateway/tor/x-3b4978b55113563b] has joined #bzr
=== Vernius_ [n=tomger@p508ADCD6.dip.t-dialin.net] has joined #bzr
=== fredp_ [n=fred@] has joined #bzr
=== bratsche [n=cody@adsl-68-94-23-66.dsl.rcsntx.swbell.net] has joined #bzr
=== hsn_ [n=chatzill@234.114.broadband5.iol.cz] has joined #bzr
=== grimboy [n=grimboy@85-211-251-94.dsl.pipex.com] has joined #bzr
=== kaaloo [n=luis@rue92-3-82-232-48-241.fbx.proxad.net] has joined #bzr
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has left #bzr []
=== bialix [i=chatzill@] has joined #bzr
bialixluks: ping09:22
lukshi bialix09:25
bialixhi luks09:25
bialixhave a question about qdiff09:25
bialixcan you give a hint where text of diff decoded to/from utf-8?09:26
bialixI need to to do something with bug 14815909:26
ubotuLaunchpad bug 148159 in qbzr "qdiff and qannotate treats file content as utf-8" [Undecided,In progress]  https://launchpad.net/bugs/14815909:26
bialixI want to introduce new branch option 'default_encoding' and use it as hint for decoding files content09:27
bialixotherwise qdiff will use utf-809:27
luksit should be after running PatienceSequenceMatcher on it, but before passing it to Qt09:27
lukscurrently it's a bit hardcoded in diffview.py09:28
bialixtreediff = TreeDiff(self.tree1, self.tree2, self.specific_files, complete)09:28
bialixin TreeDiff class?09:28
luksI'll need to take a look at the code09:29
luksone moment09:29
bialixthere is FileDiff.make_diff method09:31
bialixmy best guess it should be done here09:31
luksI'd like to do as little unicode decoding as possible09:31
luksdecoding all lines of all files is a waste of CPU09:32
luksone more moment, still thinking :)09:34
bialixPatience sequence matcher invoked in FileDiff.make_diff09:34
=== asak [n=alexis@201-13-31-123.dsl.telesp.net.br] has joined #bzr
luksokay, decoding all lines in FileDiff.make_diff is probably the best option09:36
luksthere is a bunch of unused code (html_diff_lines) and the current side-by-side diff is calculated in diffview.py09:37
bialixI'm not dare enough to delete this code09:37
luksI'll have to refactor these things, and then can be the decoding optimized09:37
luksbut for now decoding all of them should be fine09:37
bialixbefore sequence matcher or after?09:38
bialixwhat 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
=== mvo [n=egon@p54A66DFB.dip.t-dialin.net] has joined #bzr
bialix            elif not old_lines and new_lines:09:38
bialix                self.groups = [[('insert', 0, 0, 0, len(new_lines))] ] 09:38
luksadd it after the whole block09:40
luksthese ifs are just to avoid sequence matching09:40
bialixah, try it now09:41
bialixthis place try to decode line to unicde fro utf-809:43
bialixFile "C:\work\Bazaar\plugins-repo\qbzr\diffview.py", line 157, in markup_intraline_changes09:43
bialixprobably this place you call hardcoded09:43
bialixand many others too09:44
luksyou can remove them09:45
lukseverything that calls .decode("utf-8", "replace") in diff.py or diffview.py09:45
bialixso, I do decoding in one place and remove all others from all places, right?09:46
bialixyou do decode to unicode a bit too often09:47
bialixI found 3 places so far for only one file09:47
bialixqdiff for one file09:47
bialixheh, it's finally working09:49
bialixso, you have some objections for new branch config option?09:49
luksyes, I have a habit of writing extramly ugly code if it's for myself :)09:49
luksno, not at all09:49
bialixI'm inclined to use branch-level option to allow different projects have different encodings09:50
bialixbecause qbzr is utf-8 :-)09:50
luksit's a shame that these configs are not propagated on push/pull09:51
bialixwell, another option is to have such option in revisions property09:52
bialixlike --fixes or --author09:52
bialixit's require some plugin hacking09:52
bialixor just qcommit can do this :-)09:52
luksI think I'd really prefer something like .bzrprops09:53
luksbut I don't mind using a branch config for now09:53
luksas long as the default is utf-8 :)09:54
bialix.bzrprops should be in past revisions, but my old revisions don't have it09:54
bialixit's the problem for me09:55
bialixit will be show-stopper to browse history09:55
luksoh, right09:55
bialixof course, default always be utf-809:55
bialixit's inevitable09:56
bialixluks: do you have in mind some roadmap for qbzr?09:56
luksno, the development was driven only by what I currently needed09:57
=== pf_moore [n=chatzill@arkenstone.demon.co.uk] has joined #bzr
bialixwell, so I'll try to scratch my itches and help you if possible09:58
luksI really didn't intend to create some generally usable tool09:59
bialixwhy not?09:59
luksI just wanted to use bzr, and but I was too used to tortoisesvn09:59
luksso I needed something similar10:00
bialixbefore bzr I used TortoiseCVS10:00
luksand I still consider it my own personal tool :)10:00
luksI tried to use bzr-gtk before, but it was just too weird10:01
luksbut I liked the idea of using a command line shell instead of windows explorer10:01
luks(with GUI for commit, etc.)10:01
bialixI'm happy with FAR and using bzr from command line a joy for me10:02
bialixbut I'm thinking about convenient log/diff viewer, and your QBzr fit my expectation on 100%10:02
bialixbut now I feel that qstatus will be very good thing10:03
bialixand I agree with you about gtk10:04
bialixon windows it's very unfriendly10:04
luksthe problems I had with it are not directly gtk-related10:05
bialixbut overall design?10:05
luksGUI design10:05
luksnot even GNOME uses dialogs like that10:06
luksbut I didn't feel like hacking a gtk app on windows10:06
bialixhmm, have no experiance with gnome10:06
luksand now I ended up using Qt on GNOME :)10:06
luksbecause it simply looks more native than bzr-gtk, even though gtk is the first class citizen in GNOME10:07
bialixI think it's a very funnily10:07
luksanother thing that annoyed me about bzr-gtk is the order of Ok and Cancel buttons10:08
luksdon't know why, but if I'm on GNOME I expect the buttons to follow the GNOME standard, and on Windows the Windows standards10:08
bialixyou're using standard windows scheme in QBzr10:08
luksand somehow have no problem switching between them10:09
luksbialix: no, it uses different scheme on each platform10:09
bialixare you sure with my latest changes?10:09
bialixbut... how???10:09
luksQDialogButtonBox handles that10:10
bialixit's magic10:10
bialixI never realize this10:10
luksso on GNOME I have [Cancel]  [Ok]  and on Windows [Ok]  [Cancel] 10:10
=== bialix starts thinking that Qt is really right thing
bialixluks: I'm planning to put QBzr in standard standalone windows installer with some others plugins10:13
lukswouldn't it be too big?10:13
bialixwith gtk it will be bigger as twice of qbzr10:13
bialixcurrently your installer is 3MB10:14
bialixbzr.exe installer is about 4.5 MB10:14
bialixso I'll have in the end about 7 MB installer10:15
bialixI'm also concerned about size10:15
bialixmay be there will be 2 standalone installers: bare bzr.exe and big pack with some popular plugins10:16
bialixand if you're planning to switch to bzr version scheme one day, I'm happy to include Queue.py std module to bzr.exe10:18
luksQueue.py is no longer required10:18
luksbut no, I don't plan to have releases synchronized with bzr10:19
bialixbut you planning to use multithreading...10:19
luksI'd rather keep backward compatibility than force users to specific version of bzr10:20
bialixbzrlib API is very fast changing sometimes. how you achieve backward compatibility?10:21
lukswell, most of the API is not changing10:21
bialixit's good10:23
CardinalFangIck.  Cloning from a remote repo.  I don't have enough space in /tmp to contain a whole repo.10:24
=== CardinalFang assumes it's /tmp that is the problem -- "No space left on device".
bialixluks: good night, thanks for help with qdiff, I'll prepare the patch10:25
CardinalFangremote.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:27
luksCardinalFang: currently no, but the next version should support streaming natively10:28
CardinalFangNameError: name "next version" is undefined10:29
CardinalFangIs that v2?  Or 0.9z?10:30
CardinalFangAh, cool.  Thanks.10:30
luksat least there is a patch for that, I assume it's going to be included10:31
CardinalFangI 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
luksno idea10:35
CardinalFangHmm, doesn't look like it.10:39
CardinalFangAw crap, it's not local.  The server makes a tarball too.  That's where I'm running out of space.  Crap.  Crap crap crap.10:51
=== grimboy [n=grimboy@85-211-255-243.dsl.pipex.com] has joined #bzr
=== weigon [n=jan@pD9E2BC90.dip.t-dialin.net] has joined #bzr
lifelessCardinalFang: if you apply the hpss patch from spiv, its on BB, to the client and server, then the tarball method won't be used11:29
CardinalFanglifeless, Thanks.11:30
weigonI don't get my head around why I should to a checkout instead of a branch11:37
weigonI have read http://bazaar-vcs.org/CheckoutTutorial but I'm not really sold11:38
Pengweigon: 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
weigonah, so I'm fine :)11:39
Pengweigon: Also, lightweight checkouts are useful for when you don't want a copy of the entire history.11:39
=== abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr
hsn_Peng: bzr update in checkout does equivalent of svn up ?11:52
Penghsn_: Yes.11:52
=== Peng waits to be proved wrong. :P
LeoNerdIt can even be abbreviated 'bzr up'11:54
hsn_testing it11:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!