jam-laptopsuch as filesystem permissions12:02
jam-laptopand or ssh login permissions12:02
jam-laptop(but generally it is at the level of a 'branch' not at the level of individual files inside that branch)12:02
jam-laptopalso, someone can certainly edit things on their own machine12:02
jam-laptopit is just when you go to copy it elsewhere12:02
abdelrahmanso, this works for the hosted version on bazaar-vcs.org?12:03
jam-laptopI'm not sure what you mean by the "hosted version"12:03
abdelrahmanI don't know if I am understood correctly..can I host code on bazaar-vcs?12:04
abdelrahmanor it is just the project page ..12:04
jam-laptopabdelrahman: you can host on Launchpad12:05
jam-laptopor you can host on anything that gives you sftp/ftp/etc access12:05
jam-laptop(such as SourceForge or other free sites)12:05
abdelrahmanI need something that would allow me to restrict access to the code for the time being12:05
abdelrahmanI know sourceforge doesn't12:06
jam-laptopabdelrahman: so you don't want people to be able to read the code?12:06
abdelrahmanfor the time being yes12:06
jam-laptopAll the free sites I know of (off hand) are for hosting public stuff12:06
jam-laptopI know LP is working on having 'private' branches12:07
jam-laptopbut I don't think that is available yet12:07
jam-laptopYou may not need to host the project somewhere, though.12:07
jam-laptopfor example: https://answers.launchpad.net/bzr/+question/1515212:08
jam-laptopYou can have a local branch, and they have their own branch12:08
jam-laptopand you can send changes back and forth over email12:08
jam-laptoprather than needing to have the code uploaded to an http site12:08
abdelrahmanbut in this case, both machines have to be up and running at the same time !12:09
jam-laptopabdelrahman: no they don't12:10
jam-laptopyou send the patches over email12:10
jam-laptopthe idea is that each side just keeps a copy of what the other side has12:13
jam-laptopso it knows what to send12:13
=== AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr
=== kiko is now known as kiko-zzz
=== abentley [n=abentley@bas8-toronto63-1096669972.dsl.bell.ca] has joined #bzr
=== igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr
igcmorning all01:00
=== thumper-office [n=tim@canonical/launchpad/thumper] has joined #bzr
=== weigon [n=jan@pD9E2B7D5.dip.t-dialin.net] has joined #bzr
=== Vernius_ [n=tomger@p508ABAF2.dip.t-dialin.net] has joined #bzr
=== poolfool [n=poolfool@techsat21.itnes.com] has left #bzr []
lifelesssabdfl: yes, thats why annotate is slower01:26
lifelesssabdfl: we'll be added a cache that is cheaper to maintain than that that was present in packs01:27
lifelesssabdfl: and will make it toggleable01:27
lifelesssabdfl: so big projects - turn the cache off01:27
lifelesss/big/projects where commit speed matters more than anything else01:27
PengDon't projects where commit speed matters more than anything else use hg?01:28
=== Peng ducks.
AfCI did some cherry-picking backporting yesterday01:29
AfCIt wasn't necessary, but it was real world, and I wanted to try what, in effect, I am putting my contributors through.01:29
AfCI must still be battling the "Bazaar's idea of revisions" != "changesets" thing, as I am having a hard time justifying to myself why the revisions I backported with `bzr merge -r 123` don't show up as a pending merge of revisions with perfectly good commit messages01:31
lifelessAfC: they will, when we have enough breathing room on the performance side to come back to the 'doing the best possible job' stuff we actually pride ourselves on01:32
AfCDoes seem a bit of an inconsistency, though - you merge a branch and you (sic) shlurp in all its diffs and commit messages, but if I cherry pick a revision or three I get its diffs but not those revisions commit messages01:32
=== yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr
AfClifeless: ah01:33
AfClifeless: brilliant01:33
lifelessPeng: no, thats the point of this performance sprint01:33
Penglifeless: I know. :)01:33
AfClifeless: (it's sometimes difficult to tell what is deliberate and what is not-done-yet)01:33
lifelessjam-laptop: morning01:33
lifelessAfC: I can understand that :(01:33
lifelessjam-laptop: should we have a chat about things-to-do ?01:33
lifelesssabdfl: where you using a copy of launchpad in pack format?, or just the packs code on a regular launchpad branch?01:36
lifelesssabdfl: also, what revno of the packs branch ?01:37
=== bratsche [n=cody@adsl-68-94-44-74.dsl.rcsntx.swbell.net] has joined #bzr
=== Peng wanders off.
=== n2diy [n=darryl@wlk-barre-208-103-148-25.dynamic-dialup.coretel.net] has joined #bzr
igcI'm having a look at the executable flag bug right now02:01
lifelessigc: did you look at packs last night ?02:04
igclifeless: I run into problems grabbing the latest pack code02:04
igcI'm got the latest pack.knits though ...02:04
igcand I'm looking at it now ...02:05
igcwell after I look into this issue wrt executable fliags02:05
lifelessoh, what sort of problem ?02:05
igcI'm got I feeling I know when that is02:05
igcthe problem pulling the packs code I sent to the ML02:05
igclooks like poolie is having it as well02:06
igclifeless: it's buried in my email re bzr.dev problems btw02:06
lifelessI'm guessing its a bug in your reannotate code02:10
igclifeless: I'm thinking that the executable bit bug on Windows is actually due to changes made in 2862 ...02:10
igcin particular, path_content_summary in workingtree.py02:11
igcI'll dig a bit more02:12
lifelessigc: well, I think the bzr.dev problem is more severe02:15
lifelessand I strongly suspect you caused it :(02:15
igcok - I'll look into that instead02:15
lifelessI've replied to the thread02:15
=== orospakr [n=orospakr@bas4-ottawa23-1177561309.dsl.bell.ca] has joined #bzr
lifelessbasically, that revision was introduced in a pack repo02:16
lifelessso the knit version of it went through your unannotated->annotated code path02:16
lifelessand apparently code serialised incorrectly02:16
lifelessipso facto there is a bug02:16
igcok - your reply hasn't arrived yet02:16
lifelessits <possible> that the bug is in packs, like something claiming to be annotated when its not, but I have no reason to believe that that is the case.02:17
lifelessI'd expect many more problems if that *was* the case02:17
igcI remember the annotated knit changes pretty well so I'll dig into it now02:18
lifelesswe're going to have to identify all possible corrupt revisions02:19
lifelessand write some logic that can be run to purge them02:19
=== bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr
lifelessor find and dump them02:19
lifelessbbiab, picking up tickets for uds03:07
=== yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr
=== gdoubleu [n=gdoubleu@adsl-70-240-15-171.dsl.austtx.swbell.net] has joined #bzr
=== weigon [n=jan@pD9E2815A.dip.t-dialin.net] has joined #bzr
=== poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr
poolieigc, hi03:57
igcpoolie: I think I know what it is03:57
igcjust now literally03:57
pooliecan i call?03:57
igcdo you have a shared repo with one branch packs and others knits?03:57
=== bratsche [n=cody@adsl-68-94-43-63.dsl.rcsntx.swbell.net] has joined #bzr
poolieigc, you should try04:12
pooliersync -avPz people.ubuntu.com:~robertc/packs.knits .04:12
pooliein some appropriate directory04:12
gdoubleuanyone here have experience installing the trac-bzr plugin?  I am getting the following error: TracError: Unsupported version control system "bzr"04:17
gdoubleutracbzr is importable on the python prompt, In trac.ini I've set repository_type = bzr and I've set repository_dir04:17
gdoubleuI've added a [component]  section and added tracbzr.* = enabled04:17
gdoubleurestarted apache04:17
gdoubleuI turned on DEBUG level logging, but see no output other than the traceback04:17
gdoubleuThis is with Trac and TracBzr-0.204:18
gdoubleuI wasn't sure if the TracBzr-0.2-py2.4.egg needed to be copied into the trac environment's plugins directory, but I've tried it with and without04:19
=== bac_afk [n=bac@cpe-065-190-191-245.nc.res.rr.com] has joined #bzr
pooliegdoubleu, sorry, i don't04:24
=== orospakr [n=orospakr@bas4-ottawa23-1096745581.dsl.bell.ca] has joined #bzr
poolieabentley is (one of) the authors, he's sometimes around at this time of day04:24
=== igc food
poolielunch for me too04:57
igcback now - rsync finished too04:59
lifelesspoolie: its ~robertc/public_html/pack-repository.knits that you want05:12
lifelessigc: ^05:13
igcthanks llifeless05:13
igcmy pull of packs.knits is good - 2813 is the latest version there I have05:14
lifelessthey are different editions of the repository, at points where I converted05:27
=== bigdo2 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr
=== poolfool [n=mchaffin@c-71-196-179-226.hsd1.co.comcast.net] has joined #bzr
=== AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr
=== Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr
=== BasicOSX [n=BasicOSX@] has joined #bzr
poolielifeless, about that hypothesis:06:35
pooliewhen you changed the pack format from being annotated to not,06:35
pooliedid you change the format string or not?06:35
poolieok, thanks06:36
igcpoolie: I can branch from the main bzr.dev trunk into a fresh repo without problems06:41
=== poolfool [n=mchaffin@c-71-196-179-226.hsd1.co.comcast.net] has left #bzr []
igclifeless: yes - I think the damage is isolated to us06:47
igcmaybe not for identical reasons ...06:47
igcor identical sequences of events but the net effect is ..06:48
igcsome unannotated things in an annotated repo06:48
=== kaaloo [n=luis@rue92-3-82-232-48-241.fbx.proxad.net] has joined #bzr
=== BasicOSX [n=BasicOSX@] has joined #bzr
=== tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr
=== n2diy_ [n=darryl@wlk-barre-208-103-147-190.dynamic-dialup.coretel.net] has joined #bzr
=== thumper-office [n=tim@canonical/launchpad/thumper] has joined #bzr
pooliewould you believe, the first revision to have this problem is08:05
poolierevno: 278608:05
poolierevision-id: robertc@robertcollins.net-20071002070507-wjjfev3by9eufdga08:05
poolieparent: robertc@robertcollins.net-20070925220517-giar8zbt8r6fyjmi08:05
pooliecommitter: Robert Collins <robertc@robertcollins.net>08:05
pooliebranch nick: repository08:05
poolietimestamp: Tue 2007-10-02 17:05:07 +100008:05
poolie  Change the packs format to be unannotated.08:05
igcthat's a while ago08:05
poolielifeless, ping?08:05
pooliemay i call?08:05
lifelessI just piked running the review meeting08:06
poolielifeless, do you expect to make any format changes other than the format string?08:34
lifelessI think we have a good enough format to make it widely available08:34
lifelessI think there are many changes to make, just not this week.08:34
pooliebecause despite that outstanding item i'd like to use it myself for my new repo08:35
=== hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr
lifelessif you're happy to manually change the string08:36
lifelessgopher it08:36
pooliei think i can just about manager that08:36
poolieheh, freudian slip :)08:36
=== vigneswari [n=vigneswa@] has joined #bzr
lifelessspiv: grrr. I don't like this current relpath behaviour08:38
lifeless    Path "/tmp/testbzr-gAkSjl.tmp/tmpAD2mCE/work/.bzr/repository/packs" is not a child of path "/tmp/testbzr-gAkSjl.tmp/tmpAD2mCE/work/.bzr/repository/upload"08:38
lifelessthats from relpath08:38
lifelessI would like to get '../packs' as the answer, not an exception :(08:38
=== nir_ [n=nir@moinmoin/fan/nir] has joined #bzr
poolielifeless, i've noticed in a couple of places, including packs08:39
pooliethat it would be easier if you could have a transport pointing at a file, rather than needing a (transport, relpath) pair08:39
pooliethis came up again with knits08:39
lifelessI think theres room for something like that, but not a full transport IMO08:41
lifelessits the old 'are directories files' question08:41
pooliemaybe not precisely a transport08:41
pooliei'm just observing there seems to be an incipient object there08:42
=== Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr
lifelessjml: don't forget to link the minutes into the meeting page08:50
ubotuNew bug: #153191 in bzr "command to get annotation for one line" [Wishlist,Confirmed]  https://launchpad.net/bugs/15319108:55
=== kaaloo [n=luis@ATuileries-153-1-99-247.w90-24.abo.wanadoo.fr] has joined #bzr
jmllifeless: oops. other pages have an automatic thing.08:55
=== jam-laptop [n=jameinel@adsl-75-51-62-134.dsl.chcgil.sbcglobal.net] has joined #bzr
lifelesshi jam-laptop09:03
lifelessjam-laptop: is it you, or your laptop?09:03
poolietyping break..09:04
=== pbor [n=urk@host50-85-dynamic.0-79-r.retail.telecomitalia.it] has joined #bzr
lifelesspoolie: have you run spivs reconcile ?09:10
lifelesspoolie: you should do that before you move to pack format09:10
lifelesslater all09:13
=== kaaloo [n=luis@ATuileries-153-1-99-247.w90-24.abo.wanadoo.fr] has joined #bzr
=== weigon [n=jan@pD9E2815A.dip.t-dialin.net] has joined #bzr
=== mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr
=== bialix [n=chatzill@77-109-16-115.dynamic.peoplenet.ua] has joined #bzr
vilahmm, can't remember who I should ping for a request in loggerhead mrevell or mwhudson ?09:32
=== mvo [n=egon@p54A674EB.dip.t-dialin.net] has joined #bzr
vilaanyway, we have decided to track the specs with bb instead of the wiki (roughly), when using launchpad blueprints, it's now a bit difficult to set the right specification URL09:35
vilabialix gave a hint when using an URL right into a branch hosted on launchpad, but the urls are ugly and quite impossible to predict (they use revid and file-id), I'd like to use (revno, path)09:37
=== mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr
vilawhere should I report that ?09:37
vilamwhudson: are you the one I should ping about loggerhead or is it mrevell ?09:38
mwhudsonit's me09:39
vilalol, just made a test, you read my mind :-)09:40
=== mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr
ubotuNew bug: #153201 in bzr "bzr v0.91 - ERROR: Unable to delete transform temporary directory ../.bzr/checkout/limbo." [Undecided,New]  https://launchpad.net/bugs/15320109:40
vilaanyway, we have decided to track the specs with bb instead of the wiki (roughly), when using launchpad blueprints, it's now a bit difficult to set the right specification URL09:40
vilabialix gave a hint when using an URL right into a branch hosted on launchpad, but the urls are ugly and quite impossible to predict (they use revid and file-id), I'd like to use (revno, path)09:40
vilaI just realized http://codebrowse.launchpad.net/~jw+debian/bzr/bzr.0.90/revision?start_revno=2700 works already :)09:41
vilathat will solve my immediate problem may be better than (revno, path)09:41
vilamwhudson: codebrowse.launchpad.net is public right ? Not restricted to launchpad beta testers ?09:42
mwhudsonvigneswari: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/13802109:42
ubotuLaunchpad bug 138021 in launchpad-bazaar "loggerhead should generate links based on revision numbers and file paths" [Undecided,Confirmed] 09:42
mwhudsonvila, even, sorry09:42
mwhudsonvila: yes, totally public09:42
vilagreat !09:43
vilagreat !09:43
vilaI subscribed to the bug so I can monitor the changes, is it still considered ? No urgent need, just curious09:43
vilamwhudson: ^09:46
mwhudsonyes, it's something i'd like to do09:47
mwhudsonnot scheduled yet, as you can see09:47
vilamwhudson: ok, good to know, I'm too busy to even dream scratching that one, but please receive my moral support :)09:50
mwhudsonvila: ok :)09:50
=== fog [n=fog@debian/developer/fog] has joined #bzr
=== kaaloo [n=luis@ATuileries-153-1-99-247.w90-24.abo.wanadoo.fr] has joined #bzr
=== mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr
=== jrydberg [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr
=== g0ph3r [n=g0ph3r@p57A0852B.dip0.t-ipconnect.de] has joined #bzr
allaSo.. what's a good reason for picking bzr over hg?10:22
=== LeoNerd [n=leo@cel.leonerd.org.uk] has joined #bzr
=== bratsche [n=cody@adsl-68-94-16-159.dsl.rcsntx.swbell.net] has joined #bzr
=== mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr
=== igc dinner
pooliealla, i think we do better merging in some cases, and we support storing branches on sftp or ftp servers, and i believe bzr has better windows support10:31
pooliehowever, i haven't used hg recently10:31
=== n2diy__ [n=darryl@] has joined #bzr
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
=== fredp|away is now known as fredp
=== Mez is now known as Mez|Away
=== Mez|Away is now known as Mez
=== cfbolz [n=cfbolz@p54ABB48D.dip0.t-ipconnect.de] has joined #bzr
=== cfbolz [n=cfbolz@p54ABB48D.dip0.t-ipconnect.de] has joined #bzr
=== mvo [n=egon@p54A674EB.dip.t-dialin.net] has joined #bzr
=== kiko-zzz is now known as kiko
=== NamNguyen [n=NamNguye@cm38.delta196.maxonline.com.sg] has joined #bzr
=== kaaloo [n=luis@ATuileries-153-1-99-247.w90-24.abo.wanadoo.fr] has left #bzr []
=== kaaloo [n=luis@ATuileries-153-1-99-247.w90-24.abo.wanadoo.fr] has joined #bzr
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
=== niemeyer [n=niemeyer@200-138-54-64.ctame705.dsl.brasiltelecom.net.br] has joined #bzr
mlhvia reddit: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/01:24
=== cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr
=== asak [n=alexis@201-13-113-17.dsl.telesp.net.br] has joined #bzr
=== mrevell is now known as mrevell-lunch
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #bzr
=== EtienneG [n=etienne@modemcable178.77-70-69.static.videotron.ca] has joined #bzr
=== mw [n=mw@] has joined #bzr
=== pbor [n=urk@host50-85-dynamic.0-79-r.retail.telecomitalia.it] has joined #bzr
=== mrevell-lunch is now known as mrevell
mrevellabentley: ping02:36
=== bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr
=== abentley [n=abentley@bas2-toronto02-1279462552.dsl.bell.ca] has joined #bzr
=== bigdo2 is now known as bigdog_
=== kaalo1 [n=luis@ATuileries-153-1-88-186.w83-202.abo.wanadoo.fr] has joined #bzr
mrevellabentley: ping03:12
Lo-lan-dojelmer: You around?03:13
jelmerLo-lan-do, hi03:13
abentleymrevell: pong03:13
Lo-lan-doSorry to bother you again... did you have time to look at the bzr-svn pushing bug?03:14
mrevellhi abentley - do you have a few minutes to help me come up with a good way to describe merge directives for the five minute guide?03:14
jelmerLo-lan-do, not yet - but I just got back to working on bzr-svn so there hopefully should be some news in the next day or so03:15
Lo-lan-doThat would be great :-)03:15
Lo-lan-do(But I can bug you about bitlbee for a change, if you prefer :-)03:16
abentleymrevell: A merge directive is a machine-readable request to perform a particular merge.  It usually contains a patch preview of the merge, and either contains the necessary revisions, or provides a branch where they can be found.03:17
mrevellabentley: Thanks :-)03:17
mrevellabentley: Do you think we should avoid mention of bundles in that section? Is it a distraction?03:18
abentleyI'm inclined to think that detail isn't important for a 5-minute tutorial, but do what you think makes sense.03:20
mrevellLet's go with merge directives. I'll reply to your post on the list.03:22
=== grimboy [n=grimboy@85-211-254-198.dsl.pipex.com] has joined #bzr
=== fog [n=fog@debian/developer/fog] has left #bzr []
weigoncan I merge changesets between two unrelated trees (at least diff | patch with keeping the commit msg) ?04:26
weigonI have a bzr tree from svn2bzr and another one from bzr-svn and want to merge between them04:27
=== cprov is now known as cprov-lunch
=== mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr
=== _jaalto [n=root@a81-197-175-198.elisa-laajakaista.fi] has joined #bzr
=== bratsche [n=cody@adsl-68-94-24-52.dsl.rcsntx.swbell.net] has joined #bzr
_jaaltoWhat is the last version that supported Python 2.3? I need one for the OS, which isn't upgradeable05:06
jelmer_jaalto: Python2.4 has always been the earliest python version supported05:09
datorevno: 98205:09
datocommitter: Martin Pool <mbp@sourcefrog.net>05:09
datotimestamp: Wed 2005-07-27 10:11:28 -030005:09
datomessage: - we need python2.4 now, so update the statup check for that05:09
datoso practically as jelmer said05:10
jelmerweigon: You should be able to do something like that using rebase05:11
weigonnow that you say it ... right.05:11
weigonnow I "diff | patch + commit"ed it by hand05:12
jelmerweigon: sorry :-/ are you migrating between the two?05:12
_jaaltojelmer: Not at all, I've installed bzr to Python 2.3, just don't remember the version. Does r982 refer to release 0.16?05:12
weigonjelmer: first I svn2bzr'ed the tree locally and committed against it for testing and playing around05:13
jelmer_jaalto: r982 started warning about needing 2.4, I bet it's been a while before that that 2.4-specific features were used05:14
jelmer_jaalto: afaik it's more like 0.0.705:14
weigonnow I wanted to 'rebase' the changes against the original svn-tree05:14
jelmer_jaalto: r540 refers to it depending on set() from python2.405:14
weigonso, setting up a svn-bzr bridge with bzr-svn and applying the same patches against the svn-tree05:14
jelmerweigon: ah - yes, rebase should be able to do that05:15
weigonI will try it out as an exercise05:16
=== marianom [n=marianom@ubuntu/member/marianom] has joined #bzr
jelmer_jaalto: 0.0.7 is r117505:16
jelmerweigon: you should probably use bzr-rebase 0.1, trunk is broken atm05:16
_jaaltojelmer: ok05:16
jelmer_jaalto: what OS are you trying to run it on?05:17
_jaaltojelmer: SunOS/Solaris, It's production environment and Blastwave package for Python is only 2.3.505:17
_jaaltoNo fun at all05:18
=== asak_ [n=alexis@201-1-43-54.dsl.telesp.net.br] has joined #bzr
=== asak_ is now known as asak
=== michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr
=== cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr
=== Verterok [n=ggonzale@mx.snoop.com.ar] has joined #bzr
=== gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has left #bzr []
=== kiko is now known as kiko-fud
=== bratsche [n=cody@adsl-68-94-61-115.dsl.rcsntx.swbell.net] has joined #bzr
=== BasicOSX [n=BasicOSX@] has joined #bzr
=== bratsche_ [n=cody@adsl-68-94-23-193.dsl.rcsntx.swbell.net] has joined #bzr
=== BasicOSX [n=BasicOSX@] has joined #bzr
=== kiko-fud is now known as kiko
=== cfbolz [n=cfbolz@p54ABB213.dip0.t-ipconnect.de] has joined #bzr
=== kaaloo [n=luis@ATuileries-153-1-88-186.w83-202.abo.wanadoo.fr] has joined #bzr
=== p4tux [n=p4tux@] has joined #bzr
Verterokmaybe I jut felt asleep06:47
beunoVerterok, :D06:48
bwintonHow is the trunk broken?06:48
bwintonIs it something with annotated knits?06:49
bwintonjam: you there?06:52
jam-laptopbwinton: yes06:52
bwintonDo you have a couple of minutes to talk about the outfile.write patch?06:52
jam-laptopsure, I'm going over it more line by line now06:53
bwintonSo, it sounds like print has some hideously complex behaviour built in to that trailing comma...06:53
jam-laptopif it ends in 'whitespace' it won't print a new whitespace06:54
jam-laptopIt isn't horribly complex, but it is a bit surprising06:54
bwintonI'm surprised...  ;)06:54
CardinalFangPython 3 should help with some of that.06:54
bwintonHere's hoping.06:55
jam-laptopWell, since they get rid of "print" as a command ... :)06:55
jam-laptopI especially hate how it gets really messy if you are printing with arguments06:55
jam-laptopsomething like06:55
bwintonBut there's no telling what they're going to add as a parameter...  "magical_trailing_space=True"  :)06:55
jam-laptopprint >>foo, "string one %s" % (something,),06:56
jam-laptopI think the last comma is in the right spot06:56
jam-laptopbut what about06:56
bwintonHeh.  I'm so glad that that one didn't appear in the lines I was changing.06:56
jam-laptopprint >>foo, "string one %s" % (something,), another_thing, another,06:56
jam-laptopWhich I think is legal06:56
jam-laptopeven if it is awful06:56
CardinalFangYeah, does "," bind after "%"?06:56
=== CardinalFang programs too much C.
bwintonSo, along the same lines when I'm writing out the "i"s, does it matter if there's a trailing space there?06:57
bwinton            for i in mininc:06:57
bwinton                f.write(i + ' ')06:57
bwinton            f.write('\n')06:57
jam-laptopWell it does, but there won't be any spaces in the 'i'06:57
jam-laptopJust because we know what 'mininc' contains06:57
bwintonfor some value of "we".  :)06:57
jam-laptopI am a little concerned about when there is only 106:58
jam-laptopSo it might be better to do:06:58
jam-laptopf.write(' '.join(mininc))06:58
jam-laptopf.write(' '.join(str(i) for i in mininc))06:58
CardinalFangf.write(" ".join(mininc) + "\n")    ?06:58
bwintonBut surely a test would catch that case, no?06:58
jam-laptopI would guess if a test doesn't fail06:58
jam-laptopthen we don't actually care about the trailing space06:58
jam-laptopbut that doesn't mean it should be there :006:59
CardinalFangStay out of my head, j-l.06:59
bwintonFAIL: test_bundle.V4WeaveBundleTester.test_alt_timezone_bundle06:59
bwinton     . <file file_id="newfile-20071016165753-jq7208edlvy372tb-174" name="newfile" parent_id="root-id" revision="tz-1" text_sha1="40a09aa320b3f12f99593ccd887eea724c34dd4b" text_size="20" />06:59
bwintonis there a "bzr selftest -v --fail_on_first" type of option?06:59
jam-laptopbwinton: --one06:59
jam-laptop  -1, --one             Stop when one test fails.07:00
CardinalFangThose srite() syscalls are way more expensive than creating a new string, I bet.07:00
jam-laptopCardinalFang: yeah, but then again, I don't care much about optimizing the old weave.py code07:00
bwintonbzr: ERROR: Unable to import paramiko (required for sftp support): No module named paramiko07:00
=== mw [n=mw@] has joined #bzr
bwintonOkay, that looks better...07:04
=== bratsche [n=cody@adsl-68-94-7-12.dsl.rcsntx.swbell.net] has joined #bzr
bwinton(I've merged both of your suggested changes.)07:04
=== kaaloo [n=luis@ATuileries-153-1-88-186.w83-202.abo.wanadoo.fr] has left #bzr []
jam-laptopbwinton: I have a couple more I'll send you in a second07:05
jam-laptopMost notably07:05
jam-laptopyou don't need a trailing '\' to continue onto the next line07:05
jam-laptopwhen you are inside ()07:05
jam-laptopAnd 'stream.write(\' looks funny07:05
bwintonYeah, I thought about that, but the original code had it...  It was a tough call.07:06
bwintonI'm happy to change it, though.07:06
=== bwinton [n=bwinton@mail.phantomfiber.com] has left #bzr []
=== bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr
jam-laptopIt had it because07:07
jam-laptopprint 'foo' \07:07
jam-laptopcannot wrap a line07:07
bwintonIt's true, but the next line started with a (, which could have been moved to the previous line...07:07
bwintonWhat's the line length limit?07:09
bwinton(Those lines are 82 characters, and I'ld like to know if I can just join them up...)07:09
jam-laptopit is technically 79 characters07:10
jam-laptopwe can be lenient here and there07:10
jam-laptopbut we do try to stay <= 7907:10
bwintonAnything else while I'm here?07:10
bwinton(Yes, I'm trying to reply to your tweak vote before you send it.  ;) )07:11
jam-laptopbwinton: that is all I saw07:12
jam-laptopwell, everything I saw is in the tweak :)07:12
bwintonCool.  I'll throw those in and resubmit.07:12
bwintonIs revision.revno a string or an int?07:14
bwintonAnd the same for revision.rev.revision_id?07:15
jam-laptop.revno is an integer07:25
jam-laptop.revision_id is a string07:25
jam-laptop.revision_id should be a utf-8 encoded string (for what it is worth)07:25
bwintonCan I just use %s for both of them?07:25
jam-laptopthough all current examples are restricted to ASCII07:25
jam-laptopbwinton: '%s' is python's universal "do whatever it takes to makethis a string"07:25
jam-laptopso yes, you can always use '%s'07:25
jam-laptop(%d exists so you can do %4.4d type formatting)07:26
bwintonOkay, so I think I have one last question before this passes all the tests...07:39
bwintonLine 1070(-ish) of the patch looks like this:07:39
bwinton             elif l[-1]  == '\n':07:39
bwinton                 assert l.find('\n', 0, -1) == -107:39
bwinton-                print >>f, '.', l,07:39
bwinton+                f.write('. ' + l + ' ')07:39
bwintonBut that's probably not correct, given the behaviour of the trailing comma...07:39
bwintonI think I could just remove the trailing space, since we know that l ends with '\n', because of the first line I quoted.07:51
bwintonDoes that sound near-correct to you?07:51
jam-laptopRemove the trailing space seems correct to me.07:51
jam-laptopI would be happier with07:51
jam-laptopassert l.count('\n') == 107:51
jam-laptopBut that is a different change07:51
bwintonWell, that wasn't quite it.  The next error I'm getting is:07:51
bwintonERROR: test_bundle.V4WeaveBundleTester.test_binary_bundle07:51
bwinton    sequence item 0: expected string, int found07:51
jam-laptopthat sounds like07:51
jam-laptopyou probably need the07:51
jam-laptopwrite(''.join(str(i) for i in mininc))07:51
jam-laptopWhich can also be written as07:51
jam-laptopwrite(''.join([str(i) for i in mininc] ))07:51
bwintonI like the generator expression better, assuming it's in the versions of python we support...07:51
bwinton(Uh, which versions of Python does Bazaar support?)07:51
jam-laptop>= 2.407:51
jam-laptopBecause we already use generators elsewhere07:51
jam-laptopAnd we use "@" syntax07:51
bwintonYeah?  I haven't noticed any of those...  What do we use them for?07:51
jam-laptopis all over Branch.py07:51
jam-laptopare also rather common07:51
=== 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
Verterokbeuno: there are only three unitttests left: log, annotate and info. I plan to finish by thrusday/friday08:17
Verterokbeuno: s/unittests/testcases/g08:17
beunoVerterok, great, those might come in handy when we try and get the code into bzr itself08:19
=== beuno eyeballs the bzr devs
=== jam-laptop hides behind food
Verterokbeuno: yes, hope they'll08:30
=== Verterok join beuno's
=== beuno waits patiently for jam-laptop's food to run out
Lo-lan-dojam-laptop is made of food.  And electronics.08:31
jam-laptopactually 'jam' is made of food, 'laptop' is made of electronics08:39
Lo-lan-doYes, that was more or less what I was hinting at.08:51
Lo-lan-doI guess I shouldn't try to be witty when I'm sleepy.08:51
Odd_BlokeYou get a jam-laptop if you spread jam on your laptop keyboard and close the lid. .08:51
jam-laptopnot quite as good as a PB&J, but it has a bit of crunch to it08:51
=== kaaloo [n=luis@rue92-3-82-232-48-241.fbx.proxad.net] has joined #bzr
=== gotgenes [n=chris@hc6521fbb.dhcp.vt.edu] 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
gotgenesWhat is the recommended tool for migrating repositories from SVN to bzr?08:57
jam-laptopI think the #1 converter is bzr-sv08:57
gotgenesI see there's Tailor, svn2bzr, and bzr-svn08:57
jam-laptopfollowed closely by svn2bzr08:58
jam-laptopTailor is a far distant third or fourth or fifth even08:58
jam-laptopgotgenes: If it is an open source project, you can also use Launchpad to do the conversion08:58
jam-laptopwith the advantage that they will keep it up to date08:58
jam-laptopbut I have the feeling it is your own personal stuff08:58
gotgenesjam-laptop: it is a couple of personal repositories, only a few of which are software08:59
jam-laptopI believe bzr-svn receives the most attention08:59
jam-laptopbut it doesn't let you do some things that svn2bzr does08:59
jam-laptop(it is focused more on providing a way to inter-operate with svn, than to just convert)09:00
jam-laptopso svn2bzr will let you filter out stuff you don't want any more, etc.09:00
gotgenesWell I want all of the repositories, that's for sure09:00
gotgeneswhat does "ids: non-deterministic" mean?09:00
jelmerI think svn2bzr does deterministic ids these days09:02
gotgenesjelmer: are these revision IDs? or file IDs?09:04
gotgenesand does it really matter if it's deterministic?09:05
jam-laptopIf you want 2 people to convert and get the same results, yes09:05
jam-laptopIf it is just you planning on switching from using svn09:05
jam-laptopto using bzr09:05
jam-laptopthen no09:05
jam-laptopIf you were planning on continuing to use bzr09:05
jam-laptopand svn at the same time09:05
jam-laptopthen yes09:05
jelmerjam-laptop: afaik the only difference between svn2bzr and svn-import at this point is the fact that svn2bzr doesn't depend on python-subversion09:06
jam-laptopFor *you* I'm guessing the answer is no09:06
jelmersvn-import also does filtering these days09:06
jam-laptopjelmer: how do you reconcile filtering with determinism?09:06
jelmerjam-laptop: you can filter which branches to convert09:06
jam-laptopSure, but not what revisions in those branches09:06
jam-laptoplike you can't filter out the accidental commit of a CD ISO09:07
jelmerjam-laptop: svn2bzr doesn't allow more filtering than that, either09:07
jam-laptopI thought svn2bzr worked on svndump09:07
gotgenesThese are my personal repos so it sounds like deterministic IDs should matter09:07
jam-laptopand you could edit that as you wanted09:07
jelmersure, but you can do that with bzr-svn as well09:07
jam-laptopgotgenes: jam-laptop: For *you* I'm guessing the answer is no09:07
jam-laptopI didn't realize bzr-svn worked from an svndump09:07
jam-laptopand it makes me a little concerned with the extra deterministic ids...09:08
jelmerjelmer: it can, but will simply load the svndump and then work on the resulting repository09:08
jelmerjam-laptop: svn2bzr also does deterministic ids09:08
jam-laptopany time you can change the source and get the same id makes me a bit concerned09:08
jam-laptopbut hey09:08
jelmerso I don't see how bzr-svn's situation is worse..09:08
jam-laptopIt most likely won't be *my* repository which gets  corrupted accidentally09:08
gotgenesI would prefer an uncorrupted repo, as well09:09
jelmerjam-laptop: there's not really a way to work around people modifying their svndumps or svn repositories without changing the repository UUID09:09
jelmerjam-laptop: unless I would use a sha1 of the entire tree contents + revision metadata as revision id09:10
jelmerjam-laptop: heck, even Subversion clients break if you change the contents of the server by dumping it out and loading it in again09:10
jam-laptopbut SVN has only 1 place that breaks09:11
jam-laptopif I merge a patch from you09:11
jam-laptopafter you have a different conversion09:11
jam-laptopit can break my repository09:11
jam-laptopanyway, hopefully people don't mess with things too badly09:11
jam-laptopit is pretty rare to have random people doing the conversion09:11
jam-laptopversus everyone working from an 'official' one.09:12
jelmerjam-laptop: I think that's why bzr should check the sha1 of the remote repository09:12
jelmer(against the local stored sha1)09:13
jelmerin the case of a merge, just the base revision sha1 should be sufficient I think09:13
jelmereven in the non-bzr-svn case, that would be useful09:14
jelmerfor example, if I clone some-evil-users' branch into my local repository09:15
jelmerbut he had an evil copy of a revision that was already in bzr.dev, but which I hadn't pulled from there yet09:15
jelmerand I then pull from bzr.dev09:15
jelmerI end up with a corrupt revision, but without any errors09:15
james_wjelmer: hi. Is it true that bzr-svn never has to handle an svn revision with mulitple parents.09:19
james_wI am looking at InterFromSvnRespository.09:20
jelmerjames_w: it does have to handle those, but there is at most one non-ghost parent09:20
james_wjelmer: thanks.09:21
james_wI am looking at implementing InterFromGitRepository, and so it needs the multiple parent case.09:21
jelmerjames_w: is this in bzr-git?09:21
james_wI'm stuck on what to tell the target repository to do to transfer the revisions.09:22
james_wjelmer: yes.09:22
=== jelmer is also interested in bzr-git
james_wthat's one reason why I'm looking at it, with your experience it should be easier to do.09:23
james_wThe InterRepos in bzr core are mostly specialised. I am looking at the Generic one now to see what I should od.09:23
=== cfbolz [n=cfbolz@p54AB84FC.dip0.t-ipconnect.de] has joined #bzr
james_wjam-laptop: do you have a moment for a few pointers on interrepo operations?09:30
=== BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr
=== BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr
gotgenesWhere is the documentation for bzr-svn?09:38
siretarthi james_w09:47
=== bac_afk is now known as bac
jam-laptopin a bit09:49
=== Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr
=== poolfool [n=poolfool@techsat21.itnes.com] has joined #bzr
jam-laptopjames_w: how can I help10:09
james_wjam-laptop: sorry, I was eating.10:15
jam-laptopbah, no eating for anyone but me10:15
james_wHaving looked a bit more it seems like calling Repository.add_revision() for each revision in the ancestory that we care about, with the inv kw parameter set to the inventory for that revision is sufficient, am I correct?10:16
Odd_BlokeIf jam-laptop eats, he'll just become 'jam'...10:16
james_whi siretart. How are you?10:16
jam-laptopjames_w: This is after you've copied over the file texts?10:16
jam-laptopBut yes, that should work10:16
jam-laptopthough I think it *might* be better to call add_inventory() first10:17
james_wah, file texts. Whats the API to copy them?10:17
jam-laptopI've done it a couple different ways,10:18
jam-laptopI'm not sure that we have a great way to do it10:18
jam-laptopbut doing10:18
james_wand, yes it appears as though add_inventory would be more efficient, as there is a check for whether the inv is present the other way.10:18
jam-laptopweave = repo.get_weave_or_empty(file_id)10:18
jam-laptopbzr-hg might have a decent way to explain it10:19
jam-laptopin the InterRepoX.fetch() function10:19
jam-laptopat least, that is what I've copied for some things that I've done.10:19
james_wah, I hadn't even thought about file_ids yet.10:19
jam-laptopPart of it is finding the 'parent revisions' so that you get the file graph correct10:19
jam-laptopjames_w: bzr-hg just uses "hg:path/to/file"10:19
jam-laptopfor the file id10:19
jam-laptopsince that *is* the hg file id10:20
jam-laptopthough it won't follow renames, etc10:20
jam-laptopbut prior to 0.9.2 or so, neither did hg10:20
jam-laptopyou *might* want to use something like10:20
jam-laptopgit:<hash of path>10:20
jam-laptop(the problem with raw path is that it gets really long on some projects)10:20
jam-laptopI've run into file-ids that were longer than the 256 character limit per filename on Linux10:21
jam-laptop(you can have a really long total path, but each chunk needs to be shorter than ???)10:21
james_wthanks for the tip.10:21
jam-laptopso does git provide a way to do a reverse mapping?10:22
jam-laptop(to make it easy to push bzr revisions into git)10:22
jam-laptopsvn has properties (on just about everything)10:22
james_wI'm not sure I follow.10:23
jam-laptopYou want a way such that bzr-git can detect that this git revision matches that bzr revision10:23
jam-laptopso that you can push, and have pull be a no-op10:24
james_wah yes, I see.10:24
jam-laptop(see jelmer's "True Push" bzr-svn support)10:24
jam-laptopOne thing you could consider...10:24
jam-laptophaving a versioned file that records the mapping10:24
james_wThere is talk of 'notes' which are annotations to revisions, but it is not merged yet.10:24
james_w(annotations is an overloaded word, hence the choice of 'notes').10:25
james_wif that is not merged or not applicable then I will try the versioned file.10:26
james_wThe other possibility is attributes, but I don't think they fit well.10:26
siretartjames_w: thanks! - looking forward to UDS :)10:26
james_wsiretart: me too.10:27
james_wsiretart: I have submitted https://blueprints.launchpad.net/ubuntu/+spec/bzr-for-packaging-tutorial10:27
siretartjames_w: interesting. Subscribing myself as essential :)10:28
=== cprov is now known as cprov-afk
james_wsiretart: thanks. Would you be willing to help with it?10:45
siretartjames_w: of course! - I think we should take some time to discuss details in person at UDS10:47
siretartjames_w: I assume you have noticed the recent discussion on the dpkg devel list?10:47
=== GaryvdM [n=chatzill@dsl-243-166-153.telkomadsl.co.za] has joined #bzr
GaryvdMIs  John Meinel arround?10:49
GaryvdMI don't know what nick he uses.10:49
jam-laptophi GaryvdM10:49
GaryvdMI tested you patch for bug 14911310:50
ubotuLaunchpad bug 149113 in bzr ""KeyError: None" in Dirstate._entry_to_line when commiting" [Critical,Confirmed]  https://launchpad.net/bugs/14911310:50
jam-laptopthanks, any luck?10:50
GaryvdMI get ERROR: exceptions.TypeError: 'tuple' object does not support item assignment10:50
GaryvdMline 335 of bzrlib\repository.py10:50
GaryvdMcontent_summary[2]  = False10:50
jam-laptopI'll fix that, then10:51
jam-laptopI'm working on a test case anyway, I'll post it when I get it10:54
=== grimboy [n=grimboy@] has joined #bzr
james_wsiretart: no I haven't, let me look.10:57
siretartjames_w: JoeyH has proposed a patch for managing source packages in dpkg10:58
siretartjames_w: Kamion has then ported his patch for bzr10:58
=== BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr
=== herzel104 [i=herzel@gateway/tor/x-e059c0a442b8c846] has joined #bzr
james_wsiretart: thanks for the pointer, it's interesting. I don't really get it yet, but if Joey wrote it, then I would say that it is probably useful.11:06
james_wsiretart: and I'm very keen to discuss things at UDS, I don't have any other activities to do there yet, so I'm going to try and get as many people interested as possible.11:06
siretartI'll help you with that as good as I can! :)11:07
=== bwinton [n=bwinton@mail.phantomfiber.com] has left #bzr []
james_wgreat :). Have you seen we already have a slot in te provisional timetable?11:08
siretartjames_w: that's not decided yet. the schedule will be updated daily, even after conference start11:13
siretartso don't pay too much attention at the current schedule11:13
=== bac_afk [n=bac@cpe-065-190-191-245.nc.res.rr.com] has joined #bzr
=== siretart heads to sleep. good night!
james_woh yes, I realise that, it was just the first time that I had seen there was already a slot assigned to discuss these issues.11:14
james_wnight siretart.11:14
james_wjam-laptop: thanks for your help.11:33
jam-laptopjames_w: happy to help11:33
james_wI'll think about file-ids, and leave true-push until later I think.11:34
lifelessjam-laptop: hi11:34
jam-laptopjames_w: certainly, walk before you can run11:34
jam-laptopjust keep it in mind11:34
lifelessre exec bit on win3211:34
jam-laptopsince it may be easier to do it up front11:34
jam-laptoprather than after the fact11:34
lifelesschanging commit builder is the wrong place; it will not be duplicated in other repo commit builders11:35
jam-laptoplifeless: actually I have a test which requires them to11:35
lifelesscommit builder is repo specific serialisation, not tree specific, and this bug is tree specific11:35
jam-laptopbut I still feel it is wrong11:35
jam-laptopbut you had a specific comment saying that None was the right thing to return11:35
james_wjam-laptop: yes, I agree. Thanks for putting it in my head.11:35
lifelessI wanted to avoid having to do a lookup in path_content_summary11:36
lifelesscertainly the fix should only execute any code on win3211:36
lifelesse.g. be a variation of a method chosen at load time11:36
lifelessor be a decorator put on on win3211:36
lifelessI'd be ok with a decorator around the commit builder11:36
lifelessand I'd be ok with a path_content_summary_win32 that does a lookup, with11:37
lifelesspath_content_summary = _path_content_summary_win3211:37
lifelessat the class level, on win3211:37
jam-laptopso, I'm a little confused....11:37
jam-laptopIt seems like we are using the WT.path_content_summary for WT4 trees11:37
jam-laptopsince the WT4 version11:37
jam-laptopreturns entry.executable11:37
jam-laptopwhich *should* be correct11:37
jam-laptopOr are the tests only failing for WT3 trees11:38
lifelessI know bialix often uses wt3 trees11:38
lifelessbecause of locking problems in ?win98?11:38
jam-laptopyeah, and I guess he had ~1000 failures11:38
jam-laptoplifeless: and some issues with locking failures on WinNT+11:38
jam-laptopI know 'merge' used to have a problem with double locking the tree11:39
jam-laptopI think Aaron fixed that, though11:39
lifelessso today11:39
=== abentley [n=abentley@bas8-toronto63-1096734725.dsl.bell.ca] has joined #bzr
lifelessI'm going to finish the pack object cleanup11:39
lifelessand send in a branch for review11:39
lifelesschange the format string to a supported one11:39
lifelessregister the branch as visible etc11:39
lifelessMark had a performance glitch he's asked me to lookat11:39
lifelessabentley: you pointed mark at packs the other day?11:39
lifelessabentley: which branch of mine did you point him at ?11:40
=== kiko is now known as kiko-zzz
lifelessk, thanks11:40
abentleyAnd then someone else pointed him at the pack version.11:41
lifelessjam-laptop: you asked me about things to hack on; did you want to chat about that ?11:41
lifelessjam-laptop: or was my answer sufficient11:41
GaryvdMjam-laptop: I think you forgot to attach the patch in your latest mail.11:41
jam-laptopGaryvdM: thanks for the heads up11:41
jam-laptoplifeless: I would like to chat about it at some point11:42
jam-laptopI'm just trying to finish this one up11:42
jam-laptopas I see it as a fairly large regression11:42
lifelessindeed it is11:43
lifelessregression's R us11:43
GaryvdMjam-laptop: Is http://bzr.arbash-meinel.com/branches/bzr/0.92-dev/dirstate_error_149113/ the same as the missing patch?11:44
jam-laptopGaryvdM: yes11:44
jam-laptopIt should also be registered in LP11:44
lifelessabentley: what should we do about better merges then; I agree you are right that three-way, full-tree base selection, with many-branches-in-play is dangerous when conflicting decisions are being made.11:44
jam-laptopthough that may not have updated yet11:44
jam-laptopGaryvdM: I'm also thinking to fix it in a different way11:44
GaryvdMOk - I'll still give it a test.11:45
lifelessabentley: (if we don't go back to a unique root)11:45
lifelessjam-laptop: well, I'm around all day (har har), so am happy to chat at your convenience11:46
abentleylifeless: Well, per-file LCAs does help, but not in every case.11:46
lifelessI'm not going to really start work for another hour and a bit, at 9.11:46
abentleySo I'd focus on making annotate-merge better.11:47
lifelessabentley: there is a question; its going to be slow on packs, but you had the idea we only needed to annotate the differing lines, and only back to the common ancestor11:47
abentleyAnnotate merge is similar to picking a merge base for every line in the file, so it's like per-file merge bases taken to an extreme.11:47
lifelessso, I'll start using that always11:48
lifelessand see if it plays nicer11:48
abentleyI know it has some wacky corners, but we haven't really figured them out yet.11:48
abentleyi.e. what's causing them.11:49
abentleyI'm still confident that we only need to annotate back to a common base.11:49
GaryvdMjam-laptop: That branch does work.11:52
jam-laptopGaryvdM: good to hear11:53
jam-laptopAs robert and I agree, it is fixing it in the wrong place11:53
jam-laptopbut at least it works for now :)11:53
jam-laptopI'm trying to fix it more correctly11:53
=== bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr
lifelessremind me why we ever missed that knits would perform badly ?12:00
jam-laptophmm.. I take it back, it is a weird interaction with WT412:00
jam-laptopotherwise we wouldn't be getting the Dirstate failure12:00
jam-laptopwhen it tries to set_state_from_inventory12:00
jam-laptopand ie.executable is None12:00
jam-laptopwhich is just weird....12:00
lifelessits probably a badly formed inventory12:00
GaryvdMI'm looking for some advice on how to implement something.12:01
lifelessie.executable = None is invalud for kind is 'file'12:01
GaryvdMI want to create my own type of tree12:01
jam-laptoplifeless: well, record_entry_contents is setting ie.executable12:01
lifelessjam-laptop: to non-None?12:01
jam-laptopwhich is why I was fixing it there12:01
jam-laptoplifeless: well it was setting it to content_summary[2]  unilaterally12:01
lifelessGIGO though12:01
lifelessI think thats fine12:01
lifelessGaryvdM: go on12:02
jam-laptopsure, but I can't quite find the GI when it is WT412:02

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