[12:02] <jam-laptop> such as filesystem permissions
[12:02] <jam-laptop> and or ssh login permissions
[12: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-laptop> also, someone can certainly edit things on their own machine
[12:02] <jam-laptop> it is just when you go to copy it elsewhere
[12:03] <abdelrahman> so, this works for the hosted version on bazaar-vcs.org?
[12:03] <jam-laptop> I'm not sure what you mean by the "hosted version"
[12:04] <abdelrahman> I don't know if I am understood correctly..can I host code on bazaar-vcs?
[12:04] <abdelrahman> or it is just the project page ..
[12:05] <jam-laptop> abdelrahman: you can host on Launchpad
[12:05] <jam-laptop> or you can host on anything that gives you sftp/ftp/etc access
[12:05] <jam-laptop> (such as SourceForge or other free sites)
[12:05] <abdelrahman> I need something that would allow me to restrict access to the code for the time being
[12:06] <abdelrahman> I know sourceforge doesn't
[12:06] <jam-laptop> abdelrahman: so you don't want people to be able to read the code?
[12:06] <abdelrahman> for the time being yes
[12:06] <jam-laptop> All the free sites I know of (off hand) are for hosting public stuff
[12:07] <jam-laptop> I know LP is working on having 'private' branches
[12:07] <jam-laptop> but I don't think that is available yet
[12:07] <jam-laptop> You may not need to host the project somewhere, though.
[12:08] <jam-laptop> for example: https://answers.launchpad.net/bzr/+question/15152
[12:08] <jam-laptop> You can have a local branch, and they have their own branch
[12:08] <jam-laptop> and you can send changes back and forth over email
[12:08] <jam-laptop> rather than needing to have the code uploaded to an http site
[12:09] <abdelrahman> but in this case, both machines have to be up and running at the same time !
[12:10] <jam-laptop> abdelrahman: no they don't
[12:10] <jam-laptop> you send the patches over email
[12:13] <jam-laptop> the idea is that each side just keeps a copy of what the other side has
[12:13] <jam-laptop> so it knows what to send
[01:00] <igc> morning all
[01:26] <lifeless> sabdfl: yes, thats why annotate is slower
[01:27] <lifeless> sabdfl: we'll be added a cache that is cheaper to maintain than that that was present in packs
[01:27] <lifeless> sabdfl: and will make it toggleable
[01:27] <lifeless> sabdfl: so big projects - turn the cache off
[01:27] <lifeless> s/big/projects where commit speed matters more than anything else
[01:28] <Peng> Don't projects where commit speed matters more than anything else use hg?
[01:29] <AfC> I did some cherry-picking backporting yesterday
[01:29] <AfC> It wasn't necessary, but it was real world, and I wanted to try what, in effect, I am putting my contributors through.
[01:31] <AfC> I 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 messages
[01:32] <AfC> (sic)
[01:32] <lifeless> AfC: 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 on
[01:32] <AfC> Does 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 messages
[01:33] <AfC> lifeless: ah
[01:33] <AfC> lifeless: brilliant
[01:33] <lifeless> Peng: no, thats the point of this performance sprint
[01:33] <Peng> lifeless: I know. :)
[01:33] <AfC> lifeless: (it's sometimes difficult to tell what is deliberate and what is not-done-yet)
[01:33] <lifeless> jam-laptop: morning
[01:33] <lifeless> AfC: I can understand that :(
[01:33] <lifeless> jam-laptop: should we have a chat about things-to-do ?
[01:36] <lifeless> sabdfl: where you using a copy of launchpad in pack format?, or just the packs code on a regular launchpad branch?
[01:37] <lifeless> sabdfl: also, what revno of the packs branch ?
[01:39] <lifeless> blah
[02:01] <igc> I'm having a look at the executable flag bug right now
[02:04] <lifeless> igc: did you look at packs last night ?
[02:04] <igc> lifeless: I run into problems grabbing the latest pack code
[02:04] <igc> I'm got the latest pack.knits though ...
[02:05] <igc> and I'm looking at it now ...
[02:05] <igc> well after I look into this issue wrt executable fliags
[02:05] <lifeless> oh, what sort of problem ?
[02:05] <igc> I'm got I feeling I know when that is
[02:05] <igc> the problem pulling the packs code I sent to the ML
[02:06] <igc> looks like poolie is having it as well
[02:06] <igc> lifeless: it's buried in my email re bzr.dev problems btw
[02:10] <lifeless> I'm guessing its a bug in your reannotate code
[02:10] <igc> lifeless: I'm thinking that the executable bit bug on Windows is actually due to changes made in 2862 ...
[02:11] <igc> in particular, path_content_summary in workingtree.py
[02:12] <igc> I'll dig a bit more
[02:15] <lifeless> igc: well, I think the bzr.dev problem is more severe
[02:15] <lifeless> and I strongly suspect you caused it :(
[02:15] <igc> ok - I'll look into that instead
[02:15] <lifeless> I've replied to the thread
[02:16] <lifeless> basically, that revision was introduced in a pack repo
[02:16] <lifeless> so the knit version of it went through your unannotated->annotated code path
[02:16] <lifeless> and apparently code serialised incorrectly
[02:16] <lifeless> ipso facto there is a bug
[02:16] <igc> ok - your reply hasn't arrived yet
[02:17] <lifeless> its <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] <lifeless> I'd expect many more problems if that *was* the case
[02:18] <igc> I remember the annotated knit changes pretty well so I'll dig into it now
[02:19] <lifeless> we're going to have to identify all possible corrupt revisions
[02:19] <lifeless> and write some logic that can be run to purge them
[02:19] <lifeless> or find and dump them
[02:19] <igc> yup
[03:07] <lifeless> bbiab, picking up tickets for uds
[03:57] <poolie> igc, hi
[03:57] <igc> poolie: I think I know what it is
[03:57] <igc> just now literally
[03:57] <poolie> can i call?
[03:57] <igc> do you have a shared repo with one branch packs and others knits?
[03:57] <igc> yes
[04:12] <poolie> igc, you should try
[04:12] <poolie> rsync -avPz people.ubuntu.com:~robertc/packs.knits .
[04:12] <poolie> in some appropriate directory
[04:17] <gdoubleu> anyone here have experience installing the trac-bzr plugin?  I am getting the following error: TracError: Unsupported version control system "bzr"
[04:17] <gdoubleu> tracbzr is importable on the python prompt, In trac.ini I've set repository_type = bzr and I've set repository_dir
[04:17] <gdoubleu> I've added a [component]  section and added tracbzr.* = enabled
[04:17] <gdoubleu> restarted apache
[04:17] <gdoubleu> I turned on DEBUG level logging, but see no output other than the traceback
[04:18] <gdoubleu> This is with Trac 0.10.3.1 and TracBzr-0.2
[04:19] <gdoubleu> I 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 without
[04:24] <poolie> gdoubleu, sorry, i don't
[04:24] <poolie> abentley is (one of) the authors, he's sometimes around at this time of day
[04:57] <poolie> lunch for me too
[04:59] <igc> back now - rsync finished too
[05:12] <lifeless> back
[05:12] <lifeless> poolie: its ~robertc/public_html/pack-repository.knits that you want
[05:13] <lifeless> igc: ^
[05:13] <igc> thanks llifeless
[05:14] <igc> my pull of packs.knits is good - 2813 is the latest version there I have
[05:27] <lifeless> public_html/baz2.0/dot_bzr_pack
[05:27] <lifeless> public_html/baz2.0/dot_bzr_pack2
[05:27] <lifeless> they are different editions of the repository, at points where I converted
[06:35] <poolie> lifeless, about that hypothesis:
[06:35] <poolie> when you changed the pack format from being annotated to not,
[06:35] <poolie> did you change the format string or not?
[06:35] <lifeless> no
[06:36] <poolie> ok, thanks
[06:41] <igc> poolie: I can branch from the main bzr.dev trunk into a fresh repo without problems
[06:47] <igc> lifeless: yes - I think the damage is isolated to us
[06:47] <igc> maybe not for identical reasons ...
[06:48] <igc> or identical sequences of events but the net effect is ..
[06:48] <igc> some unannotated things in an annotated repo
[08:04] <poolie> heh
[08:05] <poolie> would you believe, the first revision to have this problem is
[08:05] <poolie> revno: 2786
[08:05] <poolie> revision-id: robertc@robertcollins.net-20071002070507-wjjfev3by9eufdga
[08:05] <poolie> parent: robertc@robertcollins.net-20070925220517-giar8zbt8r6fyjmi
[08:05] <poolie> committer: Robert Collins <robertc@robertcollins.net>
[08:05] <poolie> branch nick: repository
[08:05] <poolie> timestamp: Tue 2007-10-02 17:05:07 +1000
[08:05] <poolie> message:
[08:05] <poolie>   Change the packs format to be unannotated.
[08:05] <igc> that's a while ago
[08:05] <poolie> lifeless, ping?
[08:05] <lifeless> hi
[08:05] <poolie> may i call?
[08:06] <lifeless> sure
[08:06] <lifeless> I just piked running the review meeting
[08:34] <poolie> lifeless, do you expect to make any format changes other than the format string?
[08:34] <lifeless> I think we have a good enough format to make it widely available
[08:34] <lifeless> I think there are many changes to make, just not this week.
[08:35] <poolie> because despite that outstanding item i'd like to use it myself for my new repo
[08:36] <lifeless> well
[08:36] <lifeless> if you're happy to manually change the string
[08:36] <lifeless> gopher it
[08:36] <poolie> i think i can just about manager that
[08:36] <poolie> heh, freudian slip :)
[08:37] <lifeless> rofl
[08:38] <lifeless> spiv: grrr. I don't like this current relpath behaviour
[08: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] <lifeless> thats from relpath
[08:38] <lifeless> I would like to get '../packs' as the answer, not an exception :(
[08:39] <poolie> lifeless, i've noticed in a couple of places, including packs
[08:39] <poolie> that it would be easier if you could have a transport pointing at a file, rather than needing a (transport, relpath) pair
[08:39] <poolie> this came up again with knits
[08:40] <lifeless> hmm
[08:41] <lifeless> I think theres room for something like that, but not a full transport IMO
[08:41] <lifeless> its the old 'are directories files' question
[08:41] <poolie> maybe not precisely a transport
[08:42] <poolie> i'm just observing there seems to be an incipient object there
[08:42] <lifeless> agreed
[08:50] <lifeless> jml: don't forget to link the minutes into the meeting page
[08:55] <ubotu> New bug: #153191 in bzr "command to get annotation for one line" [Wishlist,Confirmed]  https://launchpad.net/bugs/153191
[08:55] <jml> lifeless: oops. other pages have an automatic thing.
[09:03] <lifeless> hi jam-laptop
[09:03] <lifeless> jam-laptop: is it you, or your laptop?
[09:04] <poolie> typing break..
[09:10] <lifeless> poolie: have you run spivs reconcile ?
[09:10] <lifeless> poolie: you should do that before you move to pack format
[09:13] <lifeless> later all
[09:32] <vila> hmm, can't remember who I should ping for a request in loggerhead mrevell or mwhudson ?
[09:35] <vila> anyway, 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 URL
[09:37] <vila> bialix 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] <vila> where should I report that ?
[09:38] <vila> mwhudson: are you the one I should ping about loggerhead or is it mrevell ?
[09:39] <mwhudson> it's me
[09:40] <vila> lol, just made a test, you read my mind :-)
[09:40] <ubotu> New bug: #153201 in bzr "bzr v0.91 - ERROR: Unable to delete transform temporary directory ../.bzr/checkout/limbo." [Undecided,New]  https://launchpad.net/bugs/153201
[09:40] <vila> anyway, 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 URL
[09:40] <vila> bialix 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:41] <vila> I just realized http://codebrowse.launchpad.net/~jw+debian/bzr/bzr.0.90/revision?start_revno=2700 works already :)
[09:41] <mwhudson> :)
[09:41] <vila> that will solve my immediate problem may be better than (revno, path)
[09:42] <vila> mwhudson: codebrowse.launchpad.net is public right ? Not restricted to launchpad beta testers ?
[09:42] <mwhudson> vigneswari: https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/138021
[09:42] <ubotu> Launchpad bug 138021 in launchpad-bazaar "loggerhead should generate links based on revision numbers and file paths" [Undecided,Confirmed] 
[09:42] <mwhudson> vila, even, sorry
[09:42] <mwhudson> vila: yes, totally public
[09:43] <vila> great !
[09:43] <vila> great !
[09:43] <vila> I subscribed to the bug so I can monitor the changes, is it still considered ? No urgent need, just curious
[09:46] <vila> mwhudson: ^
[09:47] <mwhudson> yes, it's something i'd like to do
[09:47] <mwhudson> not scheduled yet, as you can see
[09:50] <vila> mwhudson: ok, good to know, I'm too busy to even dream scratching that one, but please receive my moral support :)
[09:50] <mwhudson> vila: ok :)
[10:22] <alla> So.. what's a good reason for picking bzr over hg?
[10:31] <poolie> alla, 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 support
[10:31] <poolie> however, i haven't used hg recently
[01:24] <mlh> via reddit: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
[02:36] <mrevell> abentley: ping
[03:12] <mrevell> abentley: ping
[03:13] <Lo-lan-do> jelmer: You around?
[03:13] <jelmer> Lo-lan-do, hi
[03:13] <Lo-lan-do> Hi
[03:13] <abentley> mrevell: pong
[03:14] <Lo-lan-do> Sorry to bother you again... did you have time to look at the bzr-svn pushing bug?
[03:14] <mrevell> hi 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:15] <jelmer> Lo-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 so
[03:15] <Lo-lan-do> That would be great :-)
[03:16] <Lo-lan-do> (But I can bug you about bitlbee for a change, if you prefer :-)
[03:17] <abentley> mrevell: 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] <mrevell> abentley: Thanks :-)
[03:18] <mrevell> abentley: Do you think we should avoid mention of bundles in that section? Is it a distraction?
[03:20] <abentley> I'm inclined to think that detail isn't important for a 5-minute tutorial, but do what you think makes sense.
[03:22] <mrevell> Let's go with merge directives. I'll reply to your post on the list.
[04:26] <weigon> can I merge changesets between two unrelated trees (at least diff | patch with keeping the commit msg) ?
[04:27] <weigon> I have a bzr tree from svn2bzr and another one from bzr-svn and want to merge between them
[05:06] <_jaalto> What is the last version that supported Python 2.3? I need one for the OS, which isn't upgradeable
[05:09] <jelmer> _jaalto: Python2.4 has always been the earliest python version supported
[05:09] <dato> revno: 982
[05:09] <dato> committer: Martin Pool <mbp@sourcefrog.net>
[05:09] <dato> timestamp: Wed 2005-07-27 10:11:28 -0300
[05:09] <dato> message: - we need python2.4 now, so update the statup check for that
[05:10] <dato> so practically as jelmer said
[05:11] <jelmer> weigon: You should be able to do something like that using rebase
[05:11] <weigon> now that you say it ... right.
[05:12] <weigon> now I "diff | patch + commit"ed it by hand
[05:12] <jelmer> weigon: sorry :-/ are you migrating between the two?
[05:12] <_jaalto> jelmer: 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:13] <weigon> jelmer: first I svn2bzr'ed the tree locally and committed against it for testing and playing around
[05:14] <jelmer> _jaalto: r982 started warning about needing 2.4, I bet it's been a while before that that 2.4-specific features were used
[05:14] <jelmer> _jaalto: afaik it's more like 0.0.7
[05:14] <weigon> now I wanted to 'rebase' the changes against the original svn-tree
[05:14] <jelmer> _jaalto: r540 refers to it depending on set() from python2.4
[05:14] <weigon> so, setting up a svn-bzr bridge with bzr-svn and applying the same patches against the svn-tree
[05:15] <jelmer> weigon: ah - yes, rebase should be able to do that
[05:16] <weigon> I will try it out as an exercise
[05:16] <jelmer> _jaalto: 0.0.7 is r1175
[05:16] <jelmer> weigon: you should probably use bzr-rebase 0.1, trunk is broken atm
[05:16] <_jaalto> jelmer: ok
[05:17] <jelmer> _jaalto: what OS are you trying to run it on?
[05:17] <_jaalto> jelmer: SunOS/Solaris, It's production environment and Blastwave package for Python is only 2.3.5
[05:18] <jelmer> :-/
[05:18] <_jaalto> No fun at all
[05:43] <Verterok> moin
[06:47] <Verterok> maybe I jut felt asleep
[06:48] <beuno> Verterok, :D
[06:48] <bwinton> How is the trunk broken?
[06:49] <bwinton> Is it something with annotated knits?
[06:52] <bwinton> jam: you there?
[06:52] <jam-laptop> bwinton: yes
[06:52] <bwinton> Do you have a couple of minutes to talk about the outfile.write patch?
[06:53] <jam-laptop> sure, I'm going over it more line by line now
[06:53] <bwinton> So, it sounds like print has some hideously complex behaviour built in to that trailing comma...
[06:54] <jam-laptop> yeah
[06:54] <jam-laptop> if it ends in 'whitespace' it won't print a new whitespace
[06:54] <jam-laptop> It isn't horribly complex, but it is a bit surprising
[06:54] <bwinton> I'm surprised...  ;)
[06:54] <CardinalFang> Python 3 should help with some of that.
[06:55] <bwinton> Here's hoping.
[06:55] <jam-laptop> Well, since they get rid of "print" as a command ... :)
[06:55] <jam-laptop> I especially hate how it gets really messy if you are printing with arguments
[06:55] <jam-laptop> something like
[06:55] <bwinton> But there's no telling what they're going to add as a parameter...  "magical_trailing_space=True"  :)
[06:56] <jam-laptop> print >>foo, "string one %s" % (something,),
[06:56] <jam-laptop> I think the last comma is in the right spot
[06:56] <jam-laptop> but what about
[06:56] <bwinton> Heh.  I'm so glad that that one didn't appear in the lines I was changing.
[06:56] <jam-laptop> print >>foo, "string one %s" % (something,), another_thing, another,
[06:56] <jam-laptop> Which I think is legal
[06:56] <jam-laptop> even if it is awful
[06:56] <CardinalFang> Yeah, does "," bind after "%"?
[06:57] <bwinton> So, 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> i.e.
[06:57] <bwinton>             for i in mininc:
[06:57] <bwinton>                 f.write(i + ' ')
[06:57] <bwinton>             f.write('\n')
[06:57] <jam-laptop> Well it does, but there won't be any spaces in the 'i'
[06:57] <jam-laptop> Just because we know what 'mininc' contains
[06:57] <bwinton> for some value of "we".  :)
[06:58] <jam-laptop> I am a little concerned about when there is only 1
[06:58] <jam-laptop> So it might be better to do:
[06:58] <jam-laptop> f.write(' '.join(mininc))
[06:58] <jam-laptop> or
[06:58] <jam-laptop> f.write(' '.join(str(i) for i in mininc))
[06:58] <CardinalFang> f.write(" ".join(mininc) + "\n")    ?
[06:58] <CardinalFang> :)
[06:58] <bwinton> But surely a test would catch that case, no?
[06:58] <jam-laptop> maybe
[06:58] <jam-laptop> I would guess if a test doesn't fail
[06:58] <jam-laptop> then we don't actually care about the trailing space
[06:59] <jam-laptop> but that doesn't mean it should be there :0
[06:59] <CardinalFang> Stay out of my head, j-l.
[06:59] <bwinton> FAIL: test_bundle.V4WeaveBundleTester.test_alt_timezone_bundle
[06: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] <bwinton> is there a "bzr selftest -v --fail_on_first" type of option?
[06:59] <jam-laptop> bwinton: --one
[07:00] <jam-laptop>   -1, --one             Stop when one test fails.
[07:00] <CardinalFang> Those srite() syscalls are way more expensive than creating a new string, I bet.
[07:00] <bwinton> Cool.
[07:00] <jam-laptop> CardinalFang: yeah, but then again, I don't care much about optimizing the old weave.py code
[07:00] <bwinton> bzr: ERROR: Unable to import paramiko (required for sftp support): No module named paramiko
[07:00] <bwinton> :P
[07:04] <bwinton> Okay, that looks better...
[07:04] <bwinton> (I've merged both of your suggested changes.)
[07:05] <jam-laptop> bwinton: I have a couple more I'll send you in a second
[07:05] <jam-laptop> Most notably
[07:05] <jam-laptop> you don't need a trailing '\' to continue onto the next line
[07:05] <jam-laptop> when you are inside ()
[07:05] <jam-laptop> And 'stream.write(\' looks funny
[07:06] <bwinton> Yeah, I thought about that, but the original code had it...  It was a tough call.
[07:06] <bwinton> I'm happy to change it, though.
[07:07] <jam-laptop> It had it because
[07:07] <jam-laptop> print 'foo' \
[07:07] <bwinton> D'oh!
[07:07] <jam-laptop> cannot wrap a line
[07:07] <bwinton> It's true, but the next line started with a (, which could have been moved to the previous line...
[07:09] <bwinton> What'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:10] <jam-laptop> it is technically 79 characters
[07:10] <jam-laptop> we can be lenient here and there
[07:10] <jam-laptop> but we do try to stay <= 79
[07:10] <bwinton> Anything else while I'm here?
[07:11] <bwinton> (Yes, I'm trying to reply to your tweak vote before you send it.  ;) )
[07:12] <jam-laptop> bwinton: that is all I saw
[07:12] <jam-laptop> well, everything I saw is in the tweak :)
[07:12] <bwinton> Cool.  I'll throw those in and resubmit.
[07:14] <bwinton> Is revision.revno a string or an int?
[07:15] <bwinton> And the same for revision.rev.revision_id?
[07:25] <jam-laptop> .revno is an integer
[07:25] <jam-laptop> .revision_id is a string
[07:25] <jam-laptop> .revision_id should be a utf-8 encoded string (for what it is worth)
[07:25] <bwinton> Can I just use %s for both of them?
[07:25] <jam-laptop> though all current examples are restricted to ASCII
[07:25] <jam-laptop> bwinton: '%s' is python's universal "do whatever it takes to makethis a string"
[07:25] <jam-laptop> so yes, you can always use '%s'
[07:26] <jam-laptop> (%d exists so you can do %4.4d type formatting)
[07:39] <bwinton> Okay, so I think I have one last question before this passes all the tests...
[07:39] <bwinton> Line 1070(-ish) of the patch looks like this:
[07:39] <bwinton>              elif l[-1]  == '\n':
[07:39] <bwinton>                  assert l.find('\n', 0, -1) == -1
[07:39] <bwinton> -                print >>f, '.', l,
[07:39] <bwinton> +                f.write('. ' + l + ' ')
[07:39] <bwinton> But that's probably not correct, given the behaviour of the trailing comma...
[07:51] <bwinton> I 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] <bwinton> Does that sound near-correct to you?
[07:51] <jam-laptop> Remove the trailing space seems correct to me.
[07:51] <jam-laptop> I would be happier with
[07:51] <jam-laptop> assert l.count('\n') == 1
[07:51] <jam-laptop> But that is a different change
[07:51] <bwinton> Yeah.
[07:51] <bwinton> Well, that wasn't quite it.  The next error I'm getting is:
[07:51] <bwinton> ERROR: test_bundle.V4WeaveBundleTester.test_binary_bundle
[07:51] <bwinton>     sequence item 0: expected string, int found
[07:51] <jam-laptop> that sounds like
[07:51] <jam-laptop> write(''.join(mininc))
[07:51] <jam-laptop> you probably need the
[07:51] <jam-laptop> write(''.join(str(i) for i in mininc))
[07:51] <jam-laptop> Which can also be written as
[07:51] <jam-laptop> write(''.join([str(i) for i in mininc] ))
[07:51] <bwinton> I 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.4
[07:51] <jam-laptop> Because we already use generators elsewhere
[07:51] <jam-laptop> And we use "@" syntax
[07:51] <jam-laptop> (decorators)
[07:51] <bwinton> Yeah?  I haven't noticed any of those...  What do we use them for?
[07:51] <jam-laptop> @needs_write_lock
[07:51] <jam-laptop> and
[07:51] <jam-laptop> @needs_read_lock
[07:51] <jam-laptop> is all over Branch.py
[07:51] <jam-laptop> @staticmethod
[07:51] <jam-laptop> @classmethod
[07:51] <jam-laptop> are also rather common
[08:17] <Verterok> beuno: there are only three unitttests left: log, annotate and info. I plan to finish by thrusday/friday
[08:17] <Verterok> beuno: s/unittests/testcases/g
[08:19] <beuno> Verterok, great, those might come in handy when we try and get the code into bzr itself
[08:30] <Verterok> beuno: yes, hope they'll
[08:31] <Lo-lan-do> jam-laptop is made of food.  And electronics.
[08:39] <jam-laptop> actually 'jam' is made of food, 'laptop' is made of electronics
[08:40] <beuno> heh
[08:51] <Lo-lan-do> Yes, that was more or less what I was hinting at.
[08:51] <Lo-lan-do> I guess I shouldn't try to be witty when I'm sleepy.
[08:51] <Odd_Bloke> You get a jam-laptop if you spread jam on your laptop keyboard and close the lid. .
[08:51] <jam-laptop> not quite as good as a PB&J, but it has a bit of crunch to it
[08:57] <gotgenes> What is the recommended tool for migrating repositories from SVN to bzr?
[08:57] <jam-laptop> I think the #1 converter is bzr-sv
[08:57] <jam-laptop> bzr-svn
[08:57] <gotgenes> I see there's Tailor, svn2bzr, and bzr-svn
[08:58] <jam-laptop> followed closely by svn2bzr
[08:58] <jam-laptop> Tailor is a far distant third or fourth or fifth even
[08:58] <jam-laptop> gotgenes: If it is an open source project, you can also use Launchpad to do the conversion
[08:58] <jam-laptop> with the advantage that they will keep it up to date
[08:58] <jam-laptop> but I have the feeling it is your own personal stuff
[08:59] <gotgenes> jam-laptop: it is a couple of personal repositories, only a few of which are software
[08:59] <jam-laptop> I believe bzr-svn receives the most attention
[08:59] <jam-laptop> but it doesn't let you do some things that svn2bzr does
[09:00] <jam-laptop> (it is focused more on providing a way to inter-operate with svn, than to just convert)
[09:00] <jam-laptop> so svn2bzr will let you filter out stuff you don't want any more, etc.
[09:00] <gotgenes> Well I want all of the repositories, that's for sure
[09:00] <gotgenes> what does "ids: non-deterministic" mean?
[09:02] <jelmer> I think svn2bzr does deterministic ids these days
[09:04] <gotgenes> jelmer: are these revision IDs? or file IDs?
[09:05] <jelmer> both
[09:05] <gotgenes> and does it really matter if it's deterministic?
[09:05] <jam-laptop> If you want 2 people to convert and get the same results, yes
[09:05] <jam-laptop> If it is just you planning on switching from using svn
[09:05] <jam-laptop> to using bzr
[09:05] <jam-laptop> then no
[09:05] <jam-laptop> If you were planning on continuing to use bzr
[09:05] <jam-laptop> and svn at the same time
[09:05] <jam-laptop> then yes
[09:06] <jelmer> jam-laptop: afaik the only difference between svn2bzr and svn-import at this point is the fact that svn2bzr doesn't depend on python-subversion
[09:06] <jam-laptop> For *you* I'm guessing the answer is no
[09:06] <jelmer> svn-import also does filtering these days
[09:06] <jam-laptop> jelmer: how do you reconcile filtering with determinism?
[09:06] <jelmer> jam-laptop: you can filter which branches to convert
[09:06] <jam-laptop> Sure, but not what revisions in those branches
[09:07] <jam-laptop> like you can't filter out the accidental commit of a CD ISO
[09:07] <jelmer> jam-laptop: svn2bzr doesn't allow more filtering than that, either
[09:07] <jam-laptop> I thought svn2bzr worked on svndump
[09:07] <jelmer> afaik
[09:07] <gotgenes> These are my personal repos so it sounds like deterministic IDs should matter
[09:07] <jam-laptop> and you could edit that as you wanted
[09:07] <jelmer> sure, but you can do that with bzr-svn as well
[09:07] <jam-laptop> gotgenes: jam-laptop: For *you* I'm guessing the answer is no
[09:07] <jam-laptop> I didn't realize bzr-svn worked from an svndump
[09:08] <jam-laptop> and it makes me a little concerned with the extra deterministic ids...
[09:08] <jelmer> jelmer: it can, but will simply load the svndump and then work on the resulting repository
[09:08] <jelmer> jam-laptop: svn2bzr also does deterministic ids
[09:08] <jam-laptop> any time you can change the source and get the same id makes me a bit concerned
[09:08] <jam-laptop> but hey
[09:08] <jelmer> so I don't see how bzr-svn's situation is worse..
[09:08] <jam-laptop> It most likely won't be *my* repository which gets  corrupted accidentally
[09:09] <gotgenes> I would prefer an uncorrupted repo, as well
[09:09] <jelmer> jam-laptop: there's not really a way to work around people modifying their svndumps or svn repositories without changing the repository UUID
[09:10] <jelmer> jam-laptop: unless I would use a sha1 of the entire tree contents + revision metadata as revision id
[09:10] <jelmer> jam-laptop: heck, even Subversion clients break if you change the contents of the server by dumping it out and loading it in again
[09:11] <jam-laptop> sure
[09:11] <jam-laptop> but SVN has only 1 place that breaks
[09:11] <jam-laptop> if I merge a patch from you
[09:11] <jam-laptop> after you have a different conversion
[09:11] <jam-laptop> it can break my repository
[09:11] <jam-laptop> anyway, hopefully people don't mess with things too badly
[09:11] <jam-laptop> it is pretty rare to have random people doing the conversion
[09:12] <jam-laptop> versus everyone working from an 'official' one.
[09:12] <jelmer> jam-laptop: I think that's why bzr should check the sha1 of the remote repository
[09:13] <jelmer> (against the local stored sha1)
[09:13] <jelmer> in the case of a merge, just the base revision sha1 should be sufficient I think
[09:14] <jelmer> even in the non-bzr-svn case, that would be useful
[09:15] <jelmer> for example, if I clone some-evil-users' branch into my local repository
[09:15] <jelmer> but he had an evil copy of a revision that was already in bzr.dev, but which I hadn't pulled from there yet
[09:15] <jelmer> and I then pull from bzr.dev
[09:15] <jelmer> I end up with a corrupt revision, but without any errors
[09:19] <james_w> jelmer: hi. Is it true that bzr-svn never has to handle an svn revision with mulitple parents.
[09:20] <james_w> I am looking at InterFromSvnRespository.
[09:20] <jelmer> james_w: it does have to handle those, but there is at most one non-ghost parent
[09:21] <james_w> jelmer: thanks.
[09:21] <james_w> I am looking at implementing InterFromGitRepository, and so it needs the multiple parent case.
[09:21] <jelmer> james_w: is this in bzr-git?
[09:22] <james_w> I'm stuck on what to tell the target repository to do to transfer the revisions.
[09:22] <james_w> jelmer: yes.
[09:22] <jelmer> cool
[09:23] <james_w> that's one reason why I'm looking at it, with your experience it should be easier to do.
[09:23] <james_w> The InterRepos in bzr core are mostly specialised. I am looking at the Generic one now to see what I should od.
[09:30] <james_w> jam-laptop: do you have a moment for a few pointers on interrepo operations?
[09:38] <gotgenes> Where is the documentation for bzr-svn?
[09:47] <siretart> hi james_w
[09:49] <jam-laptop> in a bit
[10:09] <jam-laptop> james_w: how can I help
[10:15] <james_w> jam-laptop: sorry, I was eating.
[10:15] <jam-laptop> bah, no eating for anyone but me
[10:15] <jam-laptop> :)
[10:16] <james_w> Having 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_Bloke> If jam-laptop eats, he'll just become 'jam'...
[10:16] <james_w> hi siretart. How are you?
[10:16] <jam-laptop> james_w: This is after you've copied over the file texts?
[10:16] <jam-laptop> But yes, that should work
[10:17] <jam-laptop> though I think it *might* be better to call add_inventory() first
[10:17] <james_w> ah, file texts. Whats the API to copy them?
[10:18] <jam-laptop> I've done it a couple different ways,
[10:18] <jam-laptop> I'm not sure that we have a great way to do it
[10:18] <jam-laptop> but doing
[10:18] <james_w> and, 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-laptop> weave = repo.get_weave_or_empty(file_id)
[10:18] <jam-laptop> weave.add_lines(...)
[10:19] <jam-laptop> bzr-hg might have a decent way to explain it
[10:19] <jam-laptop> in the InterRepoX.fetch() function
[10:19] <jam-laptop> at least, that is what I've copied for some things that I've done.
[10:19] <james_w> ah, I hadn't even thought about file_ids yet.
[10:19] <jam-laptop> Part of it is finding the 'parent revisions' so that you get the file graph correct
[10:19] <jam-laptop> james_w: bzr-hg just uses "hg:path/to/file"
[10:19] <jam-laptop> for the file id
[10:20] <jam-laptop> since that *is* the hg file id
[10:20] <jam-laptop> though it won't follow renames, etc
[10:20] <jam-laptop> but prior to 0.9.2 or so, neither did hg
[10:20] <jam-laptop> you *might* want to use something like
[10:20] <jam-laptop> git:<hash of path>
[10:20] <jam-laptop> (the problem with raw path is that it gets really long on some projects)
[10:21] <jam-laptop> I've run into file-ids that were longer than the 256 character limit per filename on Linux
[10:21] <jam-laptop> (you can have a really long total path, but each chunk needs to be shorter than ???)
[10:21] <james_w> thanks for the tip.
[10:22] <jam-laptop> so 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-laptop> svn has properties (on just about everything)
[10:23] <james_w> I'm not sure I follow.
[10:23] <jam-laptop> You want a way such that bzr-git can detect that this git revision matches that bzr revision
[10:24] <jam-laptop> so that you can push, and have pull be a no-op
[10:24] <james_w> ah yes, I see.
[10:24] <jam-laptop> (see jelmer's "True Push" bzr-svn support)
[10:24] <jam-laptop> One thing you could consider...
[10:24] <jam-laptop> having a versioned file that records the mapping
[10:24] <james_w> There is talk of 'notes' which are annotations to revisions, but it is not merged yet.
[10:25] <james_w> (annotations is an overloaded word, hence the choice of 'notes').
[10:26] <james_w> if that is not merged or not applicable then I will try the versioned file.
[10:26] <james_w> The other possibility is attributes, but I don't think they fit well.
[10:26] <siretart> james_w: thanks! - looking forward to UDS :)
[10:27] <james_w> siretart: me too.
[10:27] <james_w> siretart: I have submitted https://blueprints.launchpad.net/ubuntu/+spec/bzr-for-packaging-tutorial
[10:28] <siretart> james_w: interesting. Subscribing myself as essential :)
[10:45] <james_w> siretart: thanks. Would you be willing to help with it?
[10:47] <siretart> james_w: of course! - I think we should take some time to discuss details in person at UDS
[10:47] <siretart> james_w: I assume you have noticed the recent discussion on the dpkg devel list?
[10:49] <GaryvdM> Is  John Meinel arround?
[10:49] <GaryvdM> I don't know what nick he uses.
[10:49] <radix> jam-laptop
[10:49] <GaryvdM> Ah!
[10:49] <jam-laptop> hi GaryvdM
[10:49] <GaryvdM> Hi
[10:50] <GaryvdM> I tested you patch for bug 149113
[10:50] <ubotu> Launchpad bug 149113 in bzr ""KeyError: None" in Dirstate._entry_to_line when commiting" [Critical,Confirmed]  https://launchpad.net/bugs/149113
[10:50] <jam-laptop> thanks, any luck?
[10:50] <GaryvdM> I get ERROR: exceptions.TypeError: 'tuple' object does not support item assignment
[10:50] <GaryvdM> line 335 of bzrlib\repository.py
[10:50] <GaryvdM> content_summary[2]  = False
[10:51] <jam-laptop> foey
[10:51] <jam-laptop> I'll fix that, then
[10:54] <jam-laptop> I'm working on a test case anyway, I'll post it when I get it
[10:56] <GaryvdM> Thanks
[10:57] <james_w> siretart: no I haven't, let me look.
[10:58] <siretart> james_w: JoeyH has proposed a patch for managing source packages in dpkg
[10:58] <siretart> james_w: Kamion has then ported his patch for bzr
[11:06] <james_w> siretart: 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_w> siretart: 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:07] <siretart> I'll help you with that as good as I can! :)
[11:08] <james_w> great :). Have you seen we already have a slot in te provisional timetable?
[11:13] <siretart> james_w: that's not decided yet. the schedule will be updated daily, even after conference start
[11:13] <siretart> so don't pay too much attention at the current schedule
[11:14] <james_w> oh 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_w> night siretart.
[11:33] <james_w> jam-laptop: thanks for your help.
[11:33] <jam-laptop> james_w: happy to help
[11:34] <james_w> I'll think about file-ids, and leave true-push until later I think.
[11:34] <lifeless> jam-laptop: hi
[11:34] <jam-laptop> hi
[11:34] <jam-laptop> james_w: certainly, walk before you can run
[11:34] <jam-laptop> just keep it in mind
[11:34] <lifeless> re exec bit on win32
[11:34] <jam-laptop> since it may be easier to do it up front
[11:34] <jam-laptop> rather than after the fact
[11:35] <lifeless> changing commit builder is the wrong place; it will not be duplicated in other repo commit builders
[11:35] <jam-laptop> lifeless: actually I have a test which requires them to
[11:35] <lifeless> commit builder is repo specific serialisation, not tree specific, and this bug is tree specific
[11:35] <jam-laptop> but I still feel it is wrong
[11:35] <jam-laptop> but you had a specific comment saying that None was the right thing to return
[11:35] <james_w> jam-laptop: yes, I agree. Thanks for putting it in my head.
[11:36] <lifeless> I wanted to avoid having to do a lookup in path_content_summary
[11:36] <lifeless> certainly the fix should only execute any code on win32
[11:36] <lifeless> e.g. be a variation of a method chosen at load time
[11:36] <lifeless> or be a decorator put on on win32
[11:36] <lifeless> I'd be ok with a decorator around the commit builder
[11:37] <lifeless> and I'd be ok with a path_content_summary_win32 that does a lookup, with
[11:37] <lifeless> path_content_summary = _path_content_summary_win32
[11:37] <lifeless> at the class level, on win32
[11:37] <jam-laptop> so, I'm a little confused....
[11:37] <jam-laptop> It seems like we are using the WT.path_content_summary for WT4 trees
[11:37] <jam-laptop> since the WT4 version
[11:37] <jam-laptop> returns entry.executable
[11:37] <jam-laptop> which *should* be correct
[11:38] <jam-laptop> Or are the tests only failing for WT3 trees
[11:38] <lifeless> I know bialix often uses wt3 trees
[11:38] <lifeless> because of locking problems in ?win98?
[11:38] <jam-laptop> yeah, and I guess he had ~1000 failures
[11:38] <jam-laptop> lifeless: and some issues with locking failures on WinNT+
[11:39] <jam-laptop> I know 'merge' used to have a problem with double locking the tree
[11:39] <jam-laptop> I think Aaron fixed that, though
[11:39] <lifeless> so today
[11:39] <lifeless> I'm going to finish the pack object cleanup
[11:39] <lifeless> and send in a branch for review
[11:39] <lifeless> change the format string to a supported one
[11:39] <lifeless> register the branch as visible etc
[11:39] <lifeless> Mark had a performance glitch he's asked me to lookat
[11:39] <lifeless> abentley: you pointed mark at packs the other day?
[11:40] <lifeless> abentley: which branch of mine did you point him at ?
[11:40] <abentley> http://people.ubuntu.com/%7Erobertc/pack-repository.knits/
[11:40] <lifeless> k, thanks
[11:41] <abentley> And then someone else pointed him at the pack version.
[11:41] <lifeless> jam-laptop: you asked me about things to hack on; did you want to chat about that ?
[11:41] <lifeless> jam-laptop: or was my answer sufficient
[11:41] <GaryvdM> jam-laptop: I think you forgot to attach the patch in your latest mail.
[11:41] <jam-laptop> GaryvdM: thanks for the heads up
[11:42] <jam-laptop> lifeless: I would like to chat about it at some point
[11:42] <jam-laptop> I'm just trying to finish this one up
[11:42] <jam-laptop> as I see it as a fairly large regression
[11:43] <lifeless> indeed it is
[11:43] <lifeless> regression's R us
[11:44] <GaryvdM> jam-laptop: Is http://bzr.arbash-meinel.com/branches/bzr/0.92-dev/dirstate_error_149113/ the same as the missing patch?
[11:44] <jam-laptop> GaryvdM: yes
[11:44] <jam-laptop> It should also be registered in LP
[11:44] <lifeless> abentley: 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-laptop> though that may not have updated yet
[11:44] <jam-laptop> GaryvdM: I'm also thinking to fix it in a different way
[11:45] <GaryvdM> Ok - I'll still give it a test.
[11:45] <lifeless> abentley: (if we don't go back to a unique root)
[11:46] <lifeless> jam-laptop: well, I'm around all day (har har), so am happy to chat at your convenience
[11:46] <abentley> lifeless: Well, per-file LCAs does help, but not in every case.
[11:46] <lifeless> I'm not going to really start work for another hour and a bit, at 9.
[11:47] <abentley> So I'd focus on making annotate-merge better.
[11:47] <lifeless> abentley: 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 ancestor
[11:47] <abentley> Annotate 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:48] <lifeless> yup
[11:48] <lifeless> so, I'll start using that always
[11:48] <lifeless> and see if it plays nicer
[11:48] <lifeless> bbiab
[11:48] <abentley> I know it has some wacky corners, but we haven't really figured them out yet.
[11:49] <abentley> i.e. what's causing them.
[11:49] <abentley> I'm still confident that we only need to annotate back to a common base.
[11:52] <GaryvdM> jam-laptop: That branch does work.
[11:53] <jam-laptop> GaryvdM: good to hear
[11:53] <jam-laptop> As robert and I agree, it is fixing it in the wrong place
[11:53] <jam-laptop> but at least it works for now :)
[11:53] <jam-laptop> I'm trying to fix it more correctly
[11:55] <GaryvdM> Cool
[12:00] <lifeless> remind me why we ever missed that knits would perform badly ?
[12:00] <jam-laptop> hmm.. I take it back, it is a weird interaction with WT4
[12:00] <jam-laptop> otherwise we wouldn't be getting the Dirstate failure
[12:00] <jam-laptop> when it tries to set_state_from_inventory
[12:00] <jam-laptop> and ie.executable is None
[12:00] <jam-laptop> which is just weird....
[12:00] <lifeless> its probably a badly formed inventory
[12:01] <GaryvdM> I'm looking for some advice on how to implement something.
[12:01] <lifeless> ie.executable = None is invalud for kind is 'file'
[12:01] <GaryvdM> I want to create my own type of tree
[12:01] <jam-laptop> lifeless: well, record_entry_contents is setting ie.executable
[12:01] <lifeless> jam-laptop: to non-None?
[12:01] <jam-laptop> which is why I was fixing it there
[12:01] <jam-laptop> lifeless: well it was setting it to content_summary[2]  unilaterally
[12:01] <lifeless> GIGO though
[12:01] <lifeless> I think thats fine
[12:02] <lifeless> GaryvdM: go on
[12:02] <jam-laptop> sure, but I can't quite find the GI when it is WT4