[00:14] <lifeless> nick125: there is an 'integrating with bzr' wiki page btw
[00:15] <beuno> nick125, http://bazaar-vcs.org/Integrating_with_Bazaar
[00:15]  * nick125 is reading
[00:43] <nick125> Does bazaar have some way to push via HTTP with something like a CGI script?
[00:46] <nick125> That's one of the main things that I liked about mercurial (one of the things I didn't like about mercurial was the random data corruption that would occur when you would use two different mercurial versions)
[00:47] <mwhudson_> nick125: there is some support for smart behaviour over http, yes
[00:47] <mwhudson_> i'm not sure how useful it is yet
[00:48] <lifeless> nick125: bzr+http
[00:49] <nick125> *looks*
[00:49] <nick125> lifeless: Do you happen to have a link?
[00:52] <lifeless> its in the docs
[00:53] <lifeless> on an http url bzr 1.4 will autodetect bzr+http if its available
[00:57]  * nick125 looks at the big "THIS IS EXPERIMENTAL AND INSECURE" notice
[00:57] <nick125> hmm
[00:57] <spiv> That notice is gone in bzr.dev.
[00:58] <lifeless> spiv: call ?
[00:58] <mwhudson_> spiv: i hope that means its secure now :)
[00:58] <lifeless> poolie is organising office stuff; I have offered to be the teddy bear de jour
[00:59] <spiv> lifeless: sure
[00:59] <nick125> What other ways exist to push with bzr without SSH?
[00:59] <lifeless> bzr+http
[00:59] <lifeless> ftp
[01:00] <lifeless> wedbav
[01:00] <lifeless> any vfs
[01:01] <bob2> ssh/sftp seem to be the most mature and simplest, tho
[01:06] <lifeless> oh yeah, sftp too :P
[01:06] <lifeless> but sftp kinda needs ssh :)
[01:06]  * nick125 is kind of leary about giving random people SSH access to his server
[01:07] <LeoNerd> You can create sftp-only accounts
[01:07] <LeoNerd> You set the shell to something special. sftp doesn't actually use a shell anyway, it's a different subsystem of ssh
[01:08] <nick125> LeoNerd: So I can set the shell to /bin/false (or something like that), and sftp would still work?
[01:08] <LeoNerd> Um.. possibly. I don't know the details, I just know it's possible
[01:09] <jdong> nick125: I think that's roughly correct. OpenSSH's sftp subsystem in recent versions can even set up a chroot to restrict where they may navigate to
[01:09] <jdong> nick125: on my secured shells recently, I've been utilizing Apparmor profiles to provide restricted access. this can also be an acceptable option
[01:09] <lifeless> nick125: you can even use a virtual SFTP server e.g. the conch one or I think paramiko has one too
[01:10] <nick125> hmmm
[03:01]  * nick125 sets up bazaar and paramiko
[03:02] <poolie> hello
[03:02] <poolie> welcome nick125
[03:02] <nick125> hiya poolie
[03:06] <nick125> So, paramiko is a sftp server that doesn't require users to have shell access?
[03:18] <nick125> blah
[03:19] <nick125> I'm trying to figure out how to get a centralized repository that people will push and pull from...I don't think I want to do a shared repository, since I have a bunch of devs that want to work offline.
[03:21] <Odd_Bloke> nick125: A shared repository is just a performance and storage enhancement, it doesn't affect your workflow.
[03:21] <nick125> Unless I'm misunderstanding the concept of shared repositories (it sounds to me that a shared repository keeps the history on the server)
[03:21] <lifeless> nick125: shared repositories simply allow multiple branches to use a single shared history db
[03:21] <lifeless> nick125: does not affect offline/branches/etc
[03:22] <nick125> Ahh.
[03:22] <nick125> The documentation makes it sound like that it stores the entire history on the server and only leaves a local copy.
[03:23] <lifeless> which docs in particular ?
[03:23] <nick125> the centralized workflow one
[03:23] <nick125> I probably misread it.
[03:23] <lifeless> (what you describe is what lightweight checkouts do)
[03:23] <lifeless> an orthogonal feature
[03:27]  * nick125 hates having to come up with names for projects
[03:40] <ubotu> New bug: #213172 in bzr ""bzr status" output problems" [Undecided,New] https://launchpad.net/bugs/213172
[04:16] <ubotu> New bug: #213182 in bzr "TestLockDir.test_35_wait_lock_changing is timing-dependent" [Undecided,New] https://launchpad.net/bugs/213182
[04:26] <ubotu> New bug: #213184 in bzr "'conflicting tags' could be more helpful" [Undecided,New] https://launchpad.net/bugs/213184
[04:26] <ubotu> New bug: #213185 in bzr "tag conflicts do not change exit code" [Undecided,New] https://launchpad.net/bugs/213185
[04:30] <ubotu> New bug: #213186 in bzr-gtk "gannotate broken with bzr.dev" [Undecided,New] https://launchpad.net/bugs/213186
[04:33]  * mwhudson wtfs
[04:33] <mwhudson> reality check please:
[04:34] <mwhudson> am i right that it's pretty strange that "cd a; bzr merge ../b" gives conflicts in different files to "cd b; bzr merge ../a" ?
[04:35] <mwhudson> (with --lca)
[04:36] <mwhudson> though the conflicts are different with merge3 too
[04:37] <mwhudson> (some of the conflicts look totally bogus too)
[04:38] <Odd_Bloke> LCA has an edge case which it doesn't deal with, but I can't remember what it is...
[04:46] <poolie> mwhudson: unless there are working tree changes it does sound strange
[04:46] <mwhudson> i guess i'll just send abentley a mail, given that this is an issue with two launchpad branches
[04:46] <poolie> i don't think it's guaranteed that they're symmetrical
[04:47] <lifeless> poolie: it should be; we walk back to a single lca
[04:47] <mwhudson> i guess i'll send the mail to the internal list then :)
[04:48] <abentley> Odd_Bloke: The edge case is that it fails to detect a conflict when one side deletes lines and the other side changes them to something else.
[04:49] <abentley> mwhudson: Please do.
[04:50] <bitmonk> hi, so like, i installed bzr and bzr-svn packages in ubuntu, but am having trouble branching an svn repo. the documentation is rather light in the bzr-svn wiki, any pointers?
[04:50] <abentley> I can tell you, it's been frustrating over the years to get reports of strange merge behavior with Launchpad branches, and not be able to do anything about it.
[04:50] <mwhudson> (there is some criss-cross merging around)
[04:50] <mwhudson> abentley: i'm sure
[04:51] <bob2> bitmonk: "bzr branch svn_url blah" - do you get an error?
[04:51] <bitmonk> bzr: ERROR: Not a branch: svn+https://svn.plone.org/svn/archetypes/Archetypes/trunk
[04:51] <bitmonk> same for https://
[04:51] <mwhudson> hm
[04:51] <bitmonk> indeed.. i haven't had it working for a while, but got it working from source a couple times on my mac or something..
[04:51] <bitmonk> i have had it working, so i have a rough memory of what works..
[04:52] <lifeless> abentley: just think, now you can dig all those reports up and analyse them :)
[04:52]  * mwhudson finds himself wondering if there is a way of restricting 'bzr viz' to revisions touching a particular file
[04:52] <abentley> lifeless: yay!
[04:53] <abentley> lifeless: Have you had seen bug 212908 ?
[04:53] <ubotu> Launchpad bug 212908 in bzr "fetch all from a repo with identical contents fails with pack repos" [High,Triaged] https://launchpad.net/bugs/212908
[04:54] <spiv> mwhudson: that would be lovely feature
[04:54] <spiv> mwhudson: I don't think it exists yet, sadly.
[04:55] <abentley> Since VersionedFiles can provide a Graph, it shouldn't be hard now.
[04:55] <abentley> Because viz is now using Graphs.
[04:57] <lifeless> abentley: are your two statements to me related?
[04:58] <abentley> lifeless: No.
[04:58] <lifeless> abentley: I've seen that bug, I presume you had a plugin or something to trigger it?
[04:58] <bob2> bitmonk: does 'bzr plugins' show svn listed?
[04:58] <abentley> Reconfigure triggers it.
[04:58] <lifeless> oh, ok.
[04:58] <abentley> At least in my new patch, it does.
[04:59] <abentley> But we have also occasionally seen reports of the same error in the wild.
[04:59] <lifeless> I can guess at the cause; its really a LBYL avoidance optimisation
[04:59] <abentley> So this may be the cause of them.
[04:59] <mwhudson> oh, i think the different merge results with --merge3 were because of unknown files or something
[04:59] <bitmonk> bob2: yessir
[04:59] <lifeless> abentley: rather than checking keys exist in packs, we copy them when we are asked too. By design multiple packs can have the same key.
[05:00] <abentley> This isn't a key-level problem-- it's a file-level problem.
[05:00] <bob2> bitmonk: hm, dunno then - try asking on the mailing list, I guess
[05:00] <abentley> It comes from trying to create a file in a pack that already has a file with the same name.
[05:00] <lifeless> abentley: thats a key level problem
[05:00] <lifeless> abentley: the name is the checksum of the .pack
[05:00] <bitmonk> bob2: will do, no hurry i s'pose
[05:01]  * mwhudson sends a mail
[05:01] <lifeless> abentley: it means we've copied the exact same data in twice.
[05:01] <abentley> Are you saying the filename of a pack is its key?
[05:01] <lifeless> (or got a md5 collision)
[05:01] <mwhudson> fortunately, it's not actually a real problem for me, the bogus seeming conflicts are trivial
[05:02] <abentley> No, I think you're forgetting that fetch with no argument ids doesn't copy contents, it copies files.
[05:02] <abentley> So if the source file has foo.pack, the target file has foo.pack, regardless of the keys inside it.
[05:03] <abentley> I mean source repo, target repo.
[05:03] <lifeless> abentley: one sec, talking with poolie
[05:04] <abentley> So it's all about what the names of files in a repo are, not what their contents are.
[05:05] <abentley> (Now of course, we would *hope* that the repository is not corrupt, but that's not actually relevant...)
[05:06] <lifeless> InterPackRepos.fetch does not copy files
[05:06] <lifeless> when revision_id is None, it does self.source.all_revision_ids()
[05:07] <lifeless> why are you saying we copy files ?
[05:07] <lifeless> line 2726 of repository.py in bzr.dev
[05:09] <bob2> bitmonk: does http:// work?
[05:10] <bitmonk> good question, trying
[05:12] <abentley> I have line 2758
[05:13] <abentley> ubotu: paste
[05:13] <ubotu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic)
[05:13] <abentley> http://paste.ubuntu-nl.org/62385/
[05:14] <abentley> lifeless: ^^
[05:14] <lifeless> abentley: that is consistent with my analysis
[05:14] <lifeless> abentley: packers copy contents not files
[05:15] <lifeless> abentley: when revision_id is None, revision_ids becomes the source's all_revision_ids() set
[05:16] <lifeless> abentley: but like I said, we don't try to eliminate duplicate revisions because that is costly and unneeded.
[05:16] <abentley> My apologies if I misunderstood.
[05:16] <lifeless> abentley: this is simply an expected md5 collision: we are copying the same content to a repository that has that content laid out the same way in a .pack. The right thing to do is to complete bug #
[05:16] <abentley> It looked as though it was copying the source's all_packs(), not their contents.
[05:17] <abentley> Bug # ?
[05:18] <AfC> There is no bug number. That's part of the bug :)
[05:18] <lifeless> I can see the confusion :)
[05:18] <lifeless> I'm looking it up
[05:18] <lifeless> lp is slow
[05:19] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/165293
[05:19] <ubotu> Launchpad bug 165293 in bzr "collisions through uploading same-named .pack files not handled correctly" [High,Confirmed]
[05:20] <lifeless> fetch with no revision_id parameter should be extremely rare - limited to upgrade in fact
[05:20] <lifeless> why does reconfigure use it ?
[05:21] <abentley> lifeless: It is deleting a repository.
[05:21] <abentley> So it fetches all the contents into a new repository.
[05:22] <lifeless> right
[05:22] <lifeless> as a backup ?
[05:23] <lifeless> and is it doing it twice for some reason ?
[05:23] <lifeless> (we can't filter on all_revision_ids() here, because if you need _all_ data you need signatures for absent revisions, inventories with no revisions etc.)
[05:24] <abentley> Because the new repository is going to be used for the branch from now on-- e.g. a heavyweight checkout being converted into a lightweight one, or a standalone tree being converted into a sharing tree.
[05:25] <lifeless> so when you say new repository, do you mean 'existing other repository' ?
[05:25] <abentley> yes.
[05:25] <lifeless> ok
[05:26] <abentley> So the test cases set up two repositories with identical content.
[05:26] <abentley> And then reconfigure itself does the fetch()
[05:26] <lifeless> fixing the md5 collision handling to not error on collisions with identical content will fix this bug
[05:26] <lifeless> but reconfigure in this case will be overly slow
[05:26] <abentley> If you fix it or in general?
[05:27] <lifeless> the cause  of the error is a situation we expect to encounter, but rarely
[05:27] <lifeless> and is not an error when it happens, we just currently group it with actual errors.
[05:27] <lifeless> however, copying a *lot* of data that we do have will be slow
[05:28] <lifeless> pack repos allow keys to be duplicated in different .pack files because that allows better concurrency when two people write to a repository at the same time
[05:32] <lifeless> testing a workaround for you
[05:35] <lifeless> abentley: try this: http://paste.ubuntu-nl.org/62387/
[05:38] <abentley> lifeless: that fixes my test case.
[05:40] <abentley> Reconfigure tests pass too, with my workaround removed.
[05:45] <lifeless> abentley: cool
[05:55] <lifeless> OperationalError: ('(OperationalError) database is locked', <bound method Root.index of <bundlebuggy.controllers.Root object at 0x8ed078c>>) u'SELECT mergerequest.id AS mergerequest_id, mergerequest.date AS mergerequest_date, mergerequest.summary AS mergerequest_summary, mergerequest.branch_location AS mergerequest_branch_location, mergerequest.head_revision AS mergerequest_head_revision, mergerequest.text_type AS mergerequest_text_type, 
[05:55] <lifeless> *sorry*
[05:55] <lifeless> I had no idea it was that long; I imagine IRC truncated it but still
[05:56] <poolie>  /kick lifeless :)
[05:57] <lifeless> spiv: whats up with  http://bundlebuggy.aaronbentley.com/request/%3C20080228144229.GF3192@steerpike.home.puzzling.org%3E?
[05:57] <lifeless> poolie: http://bundlebuggy.aaronbentley.com/request/%3C1207267732.5960.150.camel@lifeless-64%3E
[06:07] <bitmonk> bob2: still no love with http:// :/
[06:09] <lifeless> spiv: u have a review
[06:09] <spiv> lifeless: thanks
[06:10] <spiv> lifeless: so you just think s/list/tuple/ in that?
[06:11] <lifeless> If that passes tests yes.
[06:11]  * spiv nods
[06:11] <lifeless> you'll need to change the code obviously as you can't mutate the tuple once you make it
[06:11] <lifeless> so list(thing)
[06:11] <lifeless> ...
[06:11] <lifeless> new = tuple(correct_options0
[06:12] <lifeless> spiv: calling it orig_options is confusing too; so perhaps options = list(self....)
[06:12] <spiv> Ok, makes sense.
[06:12]  * spiv finds out if tests pass
[06:49] <poolie> spiv it looks like you should merge http://bundlebuggy.aaronbentley.com/request/%3C20080228144229.GF3192@steerpike.home.puzzling.org%3E
[06:50] <spiv> poolie: yeah, it's on my radar.  lifeless just pinged me about that earlier :)
[09:26] <jamesh> hi fog
[09:27] <fog> hi james
[11:50] <luisbg> how do I unlock a branch?
[11:50] <spiv> "bzr break-lock"
[11:51] <luisbg> it seams to be in the host
[11:51] <luisbg> Unable to obtain lock lp--1228238676:///lock
[11:51] <luisbg> held by luisbg@bazaar.launchpad.net on host vostok [process #25367]
[11:51] <luisbg> :(
[11:54] <james_w> luisbg: hi
[11:54] <luisbg> hey james_w
[11:54] <james_w> you want to run "bzr break-lock sftp://whatever"
[11:54] <luisbg> ok
[11:54] <luisbg> let me see
[11:54] <james_w> unfortunately with launchpad you may need to run this a few times.
[11:56] <luisbg> a lot
[11:56] <luisbg> still stuff locking it
[11:57] <luisbg> done and pushed after like 10 runs
[11:57] <luisbg> :)
[11:57] <luisbg> thanks!!
[11:57] <james_w> no problem.
[12:18] <dato> what was the command providing --custom revision format?
[12:18] <dato> the thingie that is recommended instead of $Expansion$
[13:06] <ignas> how do i get a branch for some specific revision using bzrlib?
[13:06] <ignas> without making a checkout preferably
[13:07] <ignas> i want to pass the result as "other" to branch.missing_revisions
[13:15] <pickscrape> Hi, I've encountered a bug in bzr+svn that I think I can fix myself. Could anyone point me at any docs on bzr+svn hacking?
[13:15] <pickscrape> (i.e. which tree to work against, where/how to email a merge request/patch etc)
[13:17] <bob2> the bzr svn page on the wiki at least has some of that information
[13:18] <pickscrape> It links to three branches (trunk, 0.4 and 0.3), doesn't say which to use to hack on, shows how to run the unit tests, and where to raise bugs
[13:22] <ignas> emm, why is revision_tree method of a tree
[13:22] <ignas> "not implemented" but not marked as such in the docs
[13:23] <ignas> it always raises an error (at least that's what code says)
[13:23] <ignas> but has an elaborate docstring
[13:23] <ignas> that leads one to think that the method does somethingh
[13:25]  * ignas had this idea that using bzrlib would make listing of all the new changes since some revision easier than using bzr from the command line...
[13:30] <spiv> ignas: there will be a subclass that implements th\at
[13:30] <spiv> ignas: although most classes don't tend to be constructed directly, you usually get them by calling methods on repository/branch/etc.
[13:31] <ignas> yeah, that's what i tried doing
[13:32] <ignas> tree.revision_tree("revision-I-want")
[13:33] <bartzitz> hello, i have a central repository (remote server), and i need to run a hook (shell script) on that server after each commit. how do i do this?
[13:34] <ignas> so - how do I list all the changes in a branch since some revision?
[13:34]  * ignas looked at show_log and it is a little bit complicated
[13:34] <bartzitz> ignas: bzr log -r<revno>..
[13:35] <bartzitz> ignas: -v will show modified files as well
[13:35] <ignas> i need it not including the revno
[13:35] <ignas> which is why i tried using bzrlib to do that
[13:35] <bartzitz> ignas: maybe i haven't got what are you trying to do?
[13:36] <ignas> i need a list of all the changes since some tag (only new revisions) listed on a web page
[13:36] <ignas> at the moment i am using popen to run "bzr missing"
[13:37] <ignas> but that requires making a checkout from the tag
[13:37] <ignas> which makes the operation kind of slow
[13:38] <bartzitz> ignas: bzr log -r tag:<your tag>..
[13:38] <ignas> includes the revision that was tagged as well
[13:40] <bartzitz> ignas: hmm, no ideas for now
[13:40] <bartzitz> ignas: do you know how to set up a hook on a remote shared repo?
[13:41] <ignas> nope
[13:41] <ignas> why would i want to do that?
[13:41] <bartzitz> ignas: i need it :)
[13:41] <ignas> oh ;)
[13:41] <bartzitz> ignas: just asking
[14:00] <ignas> is there an easy way to perform actions on bzr log messages using bzrlib?
[14:01] <ignas> i want all the log messages since some revision
[14:01] <ignas> in some data structure
[14:01] <ignas> and the only thing i could find that does something like that was show_log function, but it's way too complicated for what I want
[14:01] <ignas> and outputs stuff into stdout from what I can see, instead of giving me a list
[14:02] <dato> ignas: I think revision objects have a .message attribute
[14:03] <ignas> ok, how do i get all the revision messages since some revision?
[14:04] <ignas> or does revision_history() return them ordered ?
[14:04] <james_w> ignas: yes, revision_history is ordered
[14:06] <ignas> and how do i get a revision object from a revision_id?
[14:08] <pickscrape> Is there a way to resume a bzr checkout operation that has died?
[14:09] <spiv> ignas: repo.get_revision
[14:09] <spiv> ignas: where 'repo' is a Repository, e.g. from Repository.open('path/to/repo'), or from branch.repository.
[15:33] <pickscrape> Anyone know how to resume a failed checkout operation?
[15:36] <james_w> pickscrape: "bzr pull" may be able to do it, I think it depends when it failed.
[15:38] <pickscrape> Bingo. :) I had to specify the URL of the svn repository again, but it appears to be working fine.
[15:38] <pickscrape> Thanks for that.
[15:38] <pickscrape> My bzr-svn fix appears to have worked too. Anyone know where I should email the bundle containing the fix to?
[15:39] <jelmer> pickscrape: please send it to me (jelmer@samba.org)
[15:39] <pickscrape> Will do.
[15:40] <pickscrape> jelmer: should the patch be against 0.4 or trunk?
[15:40] <jelmer> pickscrape: 0.4 please
[15:40] <jelmer> pickscrape: just "bzr send" should Do The Right Thing[tm] if you have bzr >= 1.3
[15:41] <pickscrape> I guessed right then :)
[15:41] <pickscrape> Just making sure my name etc is configured right for the commit.
[15:41] <ignas> where can I find example of how to change 1 file and commit it to a branch using bzrlib without having a checkout
[15:42] <ignas> if that's possible
[15:42] <ignas> oh and tagging, yes, tagging
[15:43] <james_w> I don't think you can do it without a checkout
[15:43] <james_w> at least not easily.
[15:43] <ignas> where can i read about the hard way?
[15:43] <james_w> I doubt you can I'm afraid
[15:43] <ignas> because i am already doing it with bzr co + shell script
[15:44] <james_w> I'd have no real idea how to do it, I'd just know that you probably have to write a CommitBuilder, or perhaps somesort of Tree.
[15:44] <ignas> i can see the CommitBuilder object
[15:45] <ignas> but where do i find the information on how to use it
[15:45] <james_w> I don't know I'm afraid.
[15:45] <ignas> all my attempts at googling for this stuff end up in unrelated mailing list posts or bug reports ...
[15:46] <jelmer> ignas: It should be possible by obtaining a CommitBuilder from the branch you would like to commit to
[15:46] <jelmer> ignas: and then calling the methods on the object that is returned to you
[15:46] <ignas> yeah, have that
[15:46] <ignas> the methods are not very obvious
[15:46] <ignas> i think "cb.new_inventory" is what i need
[15:47] <ignas> but i am not really sure
[15:47] <jelmer> ignas: Basically the idea is you call record_entry_contents() for each entry in the inventory
[15:47] <jelmer> ignas: (even the unchanged ones)
[15:48] <jelmer> ignas: then, call modified_file_text() / modified_link() / modified_directory() for each entry that was modified
[15:48] <jelmer> ignas: then commit(message)
[15:49] <ignas> modified_file_text is a method of what?
[15:49] <jelmer> commitbuilder
[15:49] <ignas> hmm, can't see it
[15:50] <ignas> python prompt is giving me attribute not found on it
[15:50] <jelmer> ignas: Ah, looks like that's been removed
[15:51] <ignas> i see
[15:52] <ignas> is there some place i can read about it? or did no one ever tried doing that before?
[15:52] <ignas> how do you do such things in tests? or do you just modify the tree that you have checked out?
[15:53] <jelmer> ignas: Please ignore me, it looks like modified_*() has been removed
[15:53] <jelmer> ignas: Ah, you have to pass in a tree to record_entry that commitbuilder will get the text from
[15:53] <jelmer> ignas: or something that has a get_file_text() method
[15:54] <jelmer> ignas: lifeless and I wrote CommitBuilder a couple of years back, afaik there is no documentation (yet)
[15:55] <ignas> :D
[15:55] <ignas> not like you had time ;)
[15:56] <jelmer> (-:
[16:00] <ignas> so i should get a basis_tree, use some bzr magic to modify versions.txt.in in there, iterate through it's inventory and pass all the entries to CommitBuilder.record_entry_contents, passing that new tree as the tree parameter?
[16:01] <jelmer> ignas: yep
[16:01] <pickscrape> jelmer: Patch sent.
[16:02] <ignas> jelmer: thanks, i'll try ;)
[16:06] <jelmer> pickscrape: Any chance you can also add an entry to NEWS and a test in tests/test_svk.py ?
[16:07] <pickscrape> Oh, sure.
Should I uncommit my change then, do the additional changes and then recommit?</bzr-newbie>
[16:08] <jelmer> pickscrape: no, you should be able to just commit on top of your current commit
[16:08] <pickscrape> OK. Figured you might prefer a 'cleaner' history, but I can do that.
[16:09] <pickscrape> Was the method used appropriate or are there cleaner ways of doing it?
[16:10] <jelmer> pickscrape: I mainly care about the cleanless of the mainline history. No matter how many revisions you commit, there will only be one merge commit on mainline for your changes.
[16:11] <pickscrape> Ah, I get you.
[16:11] <jelmer> pickscrape: In other words, "bzr log" will show one merge commit and your commits indented below that
[16:12] <jelmer> pickscrape: The change itself looked fine
[16:55] <pickscrape> jelmer: I'm having trouble with the test. it's written, but when I try to run it I get "NameError: global name 'parse_svk_features' is not defined"
[16:56] <pickscrape> jelmer: Muppet alert (ignore me).
[17:03] <ignas> jelmer: i have managed to retrieve the content of the file, but how do I change it?
[17:03] <ignas> i have the branch, the tree, and the entry
[17:04] <ignas> or must I create a new entry instead?
[17:10] <jelmer> ignas: When you call record_entry_contents set ie.revision to None
[17:10] <jelmer> (see the docstring of record_entry_contents())
[17:15] <ignas> hmm, still not sure about it, i mean - it seems that record_entry_contents takes the new content using tree.get_file(ie.file_id)
[17:15] <ignas> my question is - how do I put the new content into the tree
[17:18] <ubotu> New bug: #213425 in bzr "push over sftp crashed" [Undecided,New] https://launchpad.net/bugs/213425
[17:19] <pickscrape> jelmer: Further patch with NEWS entry and unit test added.
[17:22] <jelmer> ignas: You have to override get_file() somehow
[17:22] <ignas> oh
[17:24] <Peng> The bug from that bug is running as root? :X
[17:24] <jelmer> pickscrape: Thanks, merged :-)
[17:26] <pickscrape> Sweet. :)
[17:33] <ignas> jelmer: hmm if I try record_entry_contents on the entry i get a "file already under version control" error
[17:33] <ignas> because the file path is the same
[17:33] <ignas> and it tries to add the entry to the new_inventory
[17:35] <ignas> i kind of assumed that when you record the root entry all the sub entries get added recursivelly, but it seems that the assumption was wrong too
[17:36] <Peng> bzrlib/osutils.py is lazy-importing functions. Isn't that a no-no?
[17:38] <abentley> Peng: no, that's usually okay.
[17:39] <abentley> Functions are usually called, not used like variables.
[17:40] <abentley> The first time you call a lazily-loaded function, the real function is substituted.
[17:40] <abentley> If you happened to pass the function as an argument, that would be more of an issue.
[17:43] <lamalex> Hey, if I've got a working tree with changes that aren't in the main branch, will bzr pull overwrite what I've got?
[17:46] <jelmer> ignas: and you're adding it with the same file id?
[17:46] <ignas> no, i god an error about the id being in the inventory already
[17:46] <ignas> so  i tried changing the id
[17:54] <asabil> lamalex: no, if there are any conflicts they will be reported
[17:54] <Peng> jelmer: I've got another bzr-svn traceback for you. :) http://paste.pocoo.org/show/38420/
[17:55] <Peng> jelmer: Latest bzr-svn 0.4 and bzr.dev as of 5 minutes ago.
[17:55] <jelmer> Peng: the 0.4 branch is b0rked at the moment
[17:55] <Peng> jelmer: "bzr svn-import http://svn.pyyaml.org/". Trying to branch an individual, err, branch also fails around the same place.
[17:55] <Peng> jelmer: Heh, ok.
[17:55] <Peng> jelmer: Was it borked on the 1st?
[17:55] <jelmer> Peng: yep, has been broken for a couple of days
[17:56] <Peng> jelmer: Nice. Ok.
[17:56] <jelmer> Peng: I added a warning message a couple of hours ok
[17:56] <jelmer> s/ok/ago/
[17:56] <Peng> The "experimental" warning?
[17:56] <jelmer> yep
[17:56] <Peng> But that's always been there. :P
[17:57] <jelmer> I occasionally add or remove it
[17:57] <Peng> So, should I downgrade? What to?
[17:58] <jelmer> Peng: for stability, use a release
[17:59] <Peng> Bah, what's the fun of that.
[17:59] <Peng> Can I at least use the bzr branches of the releases? :)
[18:00] <jelmer> bzr pull --overwrite tag:bzr-svn-0.4.9 :-)
[18:02] <jelmer> s/tag/-rtag
[18:03] <Peng> s/pull --overwrite/revert/
[18:03] <Peng> :)
[18:03] <Peng> Way boring though.
[18:03] <Peng> Hmmm.
[18:06] <Peng> Lightweight checkout++.
[18:30] <panosl> Hello. Trying to push a branch to a ssh repository: `bzr push bzr+ssh://myuser@myserver:6114/path/to/repo` returns an error: bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\n"
[18:31] <panosl> googling doesn't bring anything up
[18:32] <james_w> panosl: what's the version of bzr on the remote end?
[18:33] <ligemeget> Hi all, when I try 'bzr merge' in the relevant folder (to update from the main branch) I get an error which says: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
[18:33] <ligemeget> What does that mean?
[18:33] <panosl> 0.11 (ubuntu server), and my end is 1.2 (leopard)
[18:34] <james_w> ligemeget: you are using a checkout of a branch over http, which you are not allowed to write to.
[18:34] <jelmer> panosl: This is the bug that's fixed by bzr 1.3.1
[18:34] <james_w> ligemeget: do you know if you did a lightweight checkout?
[18:34] <ligemeget> james_w: Yes I did
[18:35] <ligemeget> to save time - I didn't need any history
[18:35] <james_w> jelmer: is it? I thought that was over http.
[18:35] <panosl> Only updating my end?
[18:35] <panosl> I can't update the server software
[18:35] <james_w> ligemeget: ok, you probably want the switch command
[18:35] <ligemeget> james_w: 'bzr switch'?
[18:35] <jelmer> james_w: Oh, ok. I thought it was meant to fix errors like this as well
[18:36] <jelmer> panosl: Looks like I'm wrong
[18:36] <james_w> ligemeget: bzr switch bzr+ssh://ligemeget@bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy/
[18:36] <james_w> (assuming your lp username matches your IRC nick)
[18:36] <james_w> jelmer: it looks like the remote end doesn't understand the request.
[18:37] <james_w> panosl: I think you need to upgrade the version on the remote end, I'm not positive though.
[18:37] <ligemeget> Warning: Permanently added 'bazaar.launchpad.net,91.189.94.254' (RSA) to the list of known hosts.
[18:37] <ligemeget> Permission denied (publickey).
[18:37] <ligemeget> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[18:38] <james_w> ligemeget: have you given launchpad your ssh public key?
[18:38] <ligemeget> james_w, ehh... I'm not sure..
[18:39] <ligemeget> yes, my profile https://launchpad.net/~lhademmor lists an SSH key
[18:39] <james_w> ah, did you replace your username in the command I gave you?
[18:39] <gioele> hi
[18:39] <ligemeget> yes
[18:40] <james_w> ligemeget: ok, does "ssh lhademmor@bazaar.launchpad.net" work?
[18:40] <james_w> hi gioele
[18:41] <ligemeget> james_w: no. Permission denied (publickey).
[18:41] <gioele> how short is the bzr release cycle? launchpad shows a 1.5 branch and a 1.4rc release
[18:42] <james_w> ligemeget: ok, is your ssh key at ~/.ssh/id_rsa or ~/.ssh/id_dsa or something else?
[18:42] <james_w> gioele: one month
[18:42] <james_w> 1.4rc isn't released yet, I think it's just someone planning ahead.
[18:43] <ligemeget> apparently none of those two. I have no idea where it is
[18:46] <james_w> ligemeget: it's probably named something else in ~/.ssh
[18:46] <james_w> if you can find it I can tell you how to make ssh use it automatically.
[18:46] <gioele> ligemeget: ~/.ssh/identity?
[18:47] <dato> ligemeget: what happens if you run ssh-add?
[18:47] <ligemeget> dato: nothing
[18:48] <ligemeget> There is only ~/.ssh/known_hosts in there
[18:49] <dato> ligemeget: and how did you obtain the fingerprint you placed in your launchpad page?
[18:50] <ligemeget> dato, I can't remember actually - it must be a long time ago
[18:50] <dato> well, how about generating a new key then?
[18:51] <gioele> is there a way to rebuild the bzr documentation? the online docs are scarce and outdated
[18:52] <ligemeget> dato, fine. How do I do that?
[18:52] <dato> gioele: they... are? I thought they were rebuilt nightly or something (http://doc.bazaar-vcs.org)
[18:52] <james_w> ligemeget: ssh-keygen
[18:53] <dato> ligemeget: /win 24
[18:53] <dato> er, no :)
[18:53] <ligemeget> james_w: "Enter file in which to save the key (/home/mp/.ssh/id_rsa):" - what do I enter?
[18:53] <james_w> just hit Enter, if you use the default everything will fall in to place.
[18:54] <ligemeget> passphrase?
[18:54] <ligemeget> (should I enter one or not)
[18:54] <james_w> yes, you should really.
[18:55] <gioele> dato: I mean the API: http://starship.python.net/crew/mwh/bzrlibapi/
[18:55] <ligemeget> james_w, okay I've generated a key. What do I do now?
[18:56] <gioele> My week of hacking has been a pain, so few functions are documented
[18:57] <dato> gioele: ah, sorry. dunno who's responsible for that, sorry.
[18:57] <gioele> and the few documented functions do not document the type of the input parameters and of the return values
[19:00] <james_w> gioele: I think it's mwhudson_ who created those.
[19:00] <james_w> ligemeget: you need to tell launchpad about it.
[19:01] <james_w> ligemeget: https://launchpad.net/~lhademmor/+editsshkeys
[19:30] <ligemeget> james_w, done
[19:35] <ligemeget> Still can't merge though..
[19:39] <james_w> ligemeget: you did the switch?
[19:39] <ligemeget> yep
[19:39] <ligemeget> it said something about switching to branch ssh+bzr or something
[19:40] <james_w> bzr+ssh:// hopefully.
[19:40] <james_w> can you "bzr update"?
[19:41] <james_w> ligemeget: ah, hang on, which branch are you trying to merge?
[19:41] <james_w> this may be a bug, if the URL in the error message is the branch that you are merging from then it is a bug.
[19:41] <james_w> if not then it is the problem that I thought.
[19:43] <ligemeget> james_w, well I was trying to update ubuntu-doc (the Ubuntu Documentation) as a whole (hardy branch I think)
[19:43] <james_w> ligemeget: what was the command you ran originally?
[19:45] <ligemeget> james_w, 'bzr merge'
[19:45] <ligemeget> (from the relevant directory of course)
[19:46] <james_w> ok, can you tell me what the branches listed at the bottom of "bzr info" are?
[19:46] <james_w> or, what saved branch it told you it was using.
[19:48] <ligemeget> bzr info gives 'Location:
[19:48] <ligemeget>   light checkout root: .
[19:48] <ligemeget>    checkout of branch: bzr+ssh://lhademmor@bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/ubuntu-hardy/'
[19:48] <ligemeget> The same as in the errormessage except that ~ has become %7E
[19:49] <james_w> ok, what was the branch you were a checkout of before, do you know?
[19:49] <james_w> I fear I may have lead you up the garden path as I didn't think through what was causing the error.
[19:49] <ligemeget> ...I'm not sure I understand that last question
[19:53] <james_w> what was the URL you used originally when you ran "bzr checkout"?
[19:58] <ligemeget> I never ran bzr checkout
[19:58] <ligemeget> or what
[19:58] <ligemeget> wait
[20:00] <ligemeget> https://code.launchpad.net/ubuntu-doc <-- the hardy one listed on this page
[20:19] <lamont> hrm... what was the magic test to see if bzrtools is non-b0rked?
[20:38] <james_w> lamont: you mean upgrades on hardy?
[20:39] <lamont> I mean on the dapper/edgy backports I just built
[20:39]  * lamont found 'bzr shelve' :)
[20:43] <james_w> ah, ok
[20:44] <james_w> "bzr selftest bzrtools" is pretty good too.
[23:10] <phanatic> jelmer: ping
[23:10] <jelmer> phanatic: pong
[23:11] <phanatic> jelmer: may i pm you?
[23:11] <jelmer> phanatic: sure, always :-)
[23:19] <phanatic> jelmer: did you get my lines?
[23:39] <jelmer> sorry was busy with some other stuff