[00:02] <lifeless> jfroy: pack doesn't alter what data is visible or how its indexed
[00:03] <lifeless> jfroy: all it does is shuffle it around on disk so that fewer I/O operations are needed to get at related data
[00:06] <jfroy> well it definitely fixed my problem
[00:06] <jfroy> I was able to pull the remote svn branch after packing my local repository
[00:06] <jfroy> whereas before the pack it would die on a missing revision exception.
[00:11] <lifeless> how confident are you that no other operations were done in between the failure and the pack
[00:12] <lifeless> include updates to svn/bzr-svn/bzr
[00:17] <lifeless> if pack does fixit there is a critical bug in bzr's repository code
[00:22] <SamB> lifeless: and not bzr-svn's ?
[00:22] <lifeless> SamB: bzr-svn implementation a repository proxy around libsvn
[00:23] <lifeless> SamB: it doesn't, as far as I know, rummage around through bzr's repository implementation internals
[00:23] <SamB> true
[00:23] <SamB> it doesn't mess with access to a native repository ...
[00:24] <lifeless> so if packaging a repository you're pulling into stops a bzr-svn bug happening, packing has changed the behaviour of [some] public interface || bzr-svn is poking under the hood badly
[00:25] <lifeless> I think the latter is unlikely and that leaves the former, assuming that jfroy has gathered the evidence accurately
[00:25] <lifeless> jfroy: next time this happens, can you take a backup of your bzr repo and your ~/.bazaar/bzr-svn cache die
[00:25] <lifeless> *dir*
[00:25] <lifeless> jfroy: then, try the pull again, if it fails again, pack and pull
[00:26] <lifeless> if that works, backup your backups and then put them back in place
[00:26] <lifeless> jfroy: and try the pull again, if it fails once more, we'll have a reproducable dataset to work with
[00:26] <lifeless> if the repo is private we'll write code for you to test
[00:27] <lifeless> if its not private you can schlep it to us
[00:27] <SamB> is schlepnet fast?
[00:28] <lifeless> it can be
[00:29] <jfroy> lifeless: will do
[00:32] <lifeless> thanks
[01:41] <Peng_> Is there an equivalent to "bzr revno" that shows the revid?
[01:41] <jelmer_> jfroy: hi
[01:41] <Peng_> Well, bzr lookup-revision $(bzr revno)
[01:43] <jelmer_> yeah, bzr only uses public interfaces
[01:47] <jelmer_> jfroy: which bug was it exactly that seemed to be fixed by a 'bzr pack' ?
[01:54] <jfroy> jelmer_: hey
[01:54] <jfroy> Sorry just checked IRC
[01:54] <jfroy> jelmer_: https://bugs.launchpad.net/bzr-svn/+bug/364416
[01:58] <lifeless> Peng_: bzr revision-info
[01:59] <Peng_> lifeless: Oh, nice.
[02:01] <jelmer_> jfroy: any chance you can comment on what seems to fix it in the bug report?
[02:03] <jfroy> sure
[02:03] <jfroy> but I don't know much
[02:03] <jfroy> I simply packed to "try see if it does anything", and it unexpectedly did.
[02:04] <jfroy> I didn't make a backup of the repository before packing, unfortunately.
[02:04] <jfroy> although...
[02:04] <jfroy> we may be in luck, actually.
[02:04] <jfroy> I backup my documents automatically
[02:05] <jfroy> I most likely can revert the repository to its state prior to packing
[02:05] <jfroy> and try the sequence all over again
[02:05] <jelmer_> jfroy: which repository format are you using?
[02:06] <jfroy> 1.14
[02:06] <jfroy> (-rich-root of course)
[02:12] <lifeless> jfroy: really? bzr info and paste the format details please
[02:12] <jfroy> lifeless: 1.14-rich-root or 1.9-rich-root
[02:12] <lifeless> ah actually nvm
[02:12] <lifeless> its 1.9 repo
[02:12] <jfroy> anyways, restoring from backup and trying again
[02:12] <lifeless> a new tree format is in 1.14 is all, it supports filters [yay]
[02:12] <jfroy> see if I can reproduce
[02:14] <jfroy> ahhh, backups :)
[02:16] <jfroy> Is there any flags I can use to spit out more info in the bzr.log?
[02:16] <jfroy> the repo is confidential, I won't be able to share it
[02:16] <lifeless> jfroy: for this operation, nothing offhand
[02:16] <jfroy> Although I can certainly paste logs and what not
[02:16] <lifeless> we may write some custom patches to debug
[02:17] <jfroy> jelmer_: I'll be using your bzr foreign branch and bzr-svn for this
[02:17] <jfroy> it's what I usually use
[02:22] <jfroy> eh this time it's still dying after the pack
[02:22] <jfroy> this is very odd
[02:23] <jfroy> mmmm
[02:23] <jfroy> interesting
[02:23] <jfroy> so after the pack, I still got the missing revision exception
[02:24] <jfroy> I then pulled the trunk branch (which was already in the repository)
[02:24] <jfroy> repacked
[02:24] <jelmer_> jfroy: at this point my bzr-foreign branch is basically bzr.dev with bzr+http removed
[02:24] <jfroy> and the the branch command worked
[02:24] <jfroy> so it may be the trunk pull that fixed it, not the pack
[02:25] <jfroy> let me try this again starting at the beginning...
[02:25] <jelmer_> k
[02:26] <jfroy> jelmer_: I think it does a few more things, no?
[02:26] <jelmer_> jfroy: no, the other things have been merged now
[02:26] <jfroy> push working to create new branches and printing the svn revno when pulling
[02:26] <jfroy> I see
[02:26] <jfroy> gotcha
[02:26] <jfroy> good to know
[02:26] <jelmer_> jfroy: it used to be more
[02:26] <jfroy> yeah
[02:26] <jfroy> was the fallback credential store stuff merged in too?
[02:26] <jfroy> I adopted the protocol in my keychain store and it's working great
[02:27] <lifeless> jfroy: the trunk pull is likely it
[02:27] <jfroy> It makes a lot more sense, yes
[02:27] <lifeless> yes, yes it does :)
[02:28] <jfroy> pack should not fundamentally change the content of the history
[02:28] <lifeless> right
[02:28] <jfroy> it just makes it tidier
[02:29] <jfroy> confirmed
[02:30] <jfroy> the trunk pull fixes the branch command
[02:31] <jfroy> I also confirmed I cannot pull the branch in a new repository without having trunk in it
[02:31] <jfroy> if trunk is not there, it always dies with a no such revision exception
[02:31] <jfroy> so it's unlikely that the svn cache is involved here either
[02:34] <lifeless> jfroy: are you pulling from svn
[02:34] <lifeless> or from bzr
[02:34] <lifeless> there is a bugfix in bzr (server side) for 'NoSuchRevision' pulling from a stacked branch
[02:35] <jfroy> pulling from svn
[02:35] <jfroy> in all cases
[02:35] <jfroy> jelmer_: confirmed, I just made a brand new repository
[02:36] <jfroy> tried to pull the svn branch in it, died with the usual error
[02:36] <jfroy> I then pulled the svn trunk in that repository and then pulled the svn branch again
[02:36] <jfroy> and that worked
[02:36] <jfroy> so it seems bzr-svn is failing to pull certain revisions it needs
[02:36] <jfroy> I've updated the bug with that finding.
[02:39] <jelmer_> thanks
[02:40] <jfroy> if you need revprop / file props to debug this when you get around to it, let me know
[02:56] <jelmer_> will do, thanks
[03:55] <jelmer_> lifeless: btw, did I mention dpush to remote git branches works now?
[03:56] <jelmer_> the only thing remaining now is 'proper' push
[03:58] <lifeless> ye
[03:59] <jelmer_> it would be nice if somebody could fix up hg support at some point
[04:01] <jelmer_> I think the API changed or something but it can't do much else than view revision history atm
[08:58] <pzico> hola, I have a stupid question that I couldn't figure out from "Bazaar in 5 minutes".. If I want to force checkout the latest revision of file abc.py in current folder, what is the command?
[08:59] <bob2> if you want the one corresponding to the currently checkout'd revision, bzr revert abc.py
[09:00] <bob2> (ie it will undo all uncommited local changes)
[09:00] <LarstiQ> pzico: Bazaar considers the entire tree 1 object. If you are using a checkout `bzr update` will make it up to date with the master location. If you're using a branch, `bzr pull` will pull in all the new revisions from your parent location.
[09:00] <LarstiQ> pzico: or possibly what bob2 said, from your wording it isn't clear to me what effect you're looking for
[09:03] <pzico> Well, I haven't yet learned to think "bazaar" way. So I just made simple project and used bzr init, add and commits.. now I just want to revert back to previous committed version..
[09:03] <pzico> and only for one of the files I have edited
[09:04] <LarstiQ> pzico: ah ok, if the most recent commit is the one you want to go back to `bzr revert abc.py`
[09:04] <pzico> It seems that the revert command did the job. Thanks.
[09:04] <LarstiQ> pzico: or if you would like to bring it to an arbitrary revision, `bzr revert -r 123 abc.py`
[09:04] <LarstiQ> cool
[09:54] <awilcox> Does anybody know of an Xcode plugin for Bazaar?
[13:51] <ronny> hmm
[13:52] <ronny> anyone aware of an api that kind of combiness Workingtrees iter_changes and list_files ?
[13:53] <ronny> i need renames and unknown files at once if possible
[14:25] <luks> ronny: TreeDelta?
[14:25] <luks> of working tree against the basis tree
[14:25] <ronny> currently im using wt.iter_changes(wt.basis_tree())
[14:26] <james_w> ronny: can't you ask for unknown in iter_changes?
[14:27] <james_w> want_unversioned=True
[14:27] <ronny> ah,
[14:28] <ronny> hmm
[14:28] <ronny> i have that, yet its still somehow missing something
[14:29]  * ronny rechecks his test helpers
[14:30] <ronny> hmm, i have include_unchanged and want_unversioned
[14:33] <ronny> do i have to invalidate a workingtree after a commit?
[14:35] <lifeless> ronny: how do you mean
[14:36] <ronny> hmm, i think im confusing something about the api here
[14:39] <ronny> ok, i think i found my error
[14:39] <ronny> lifeless: i didnt notice i had a broken test
[14:40] <vxnick> hi guys - a question: is there much difference between push/pull and commit/checkout when working on a remote repo with others?
[14:44] <ronny> oh darn
[15:43] <LeoNerd> vxnick: Not really.. they're basically the same... A "bound" branch is just one that pushes after it commits. etc...
[15:43] <vxnick> LeoNerd: thanks, I thought it might've been something like that
[17:31] <vxnick> guys - I think I'm going crazy here. I've created a shared repo and a trunk on a remote server, but can't checkout locally - I get the "bzr error not a branch" error
[17:35] <jelmer_> vxnick: are you checking out the branch location?
[17:35] <jelmer_> I mean, the location of trunk
[17:36] <vxnick> jelmer: I am indeed
[17:36] <vxnick> jelmer: I 'bzr init-repo project_name' and then 'bzr init trunk" within  that dir
[17:36] <jelmer_> vxnick: so the url ends in /trunk?
[17:36] <vxnick> jelmer: that's right
[17:37] <jelmer_> does bzr info work on the URL?
[17:37] <vxnick> nope
[17:37] <vxnick> not a branch
[17:38] <vxnick> oh dear
[17:38] <vxnick> the path was wrong
[17:38] <vxnick> *embarrassed*
[17:38] <vxnick> thanks for your help
[17:38] <jelmer_> np
[18:53] <vxnick> bzr-upload stores the remote location by default, but is there a way that I can switch between locations, perhaps by using some form of alias? I think I might have read about this somewhere but can't find anyhting
[18:53] <jkakar> Sometimes I wonder if 'bzr update' should automatically fall back to 'bzr pull' when the branch isn't bound.
[18:57] <cdecarlo> hi, I'm new to bzr and distributed vcs all together, I've created my first bzr repo with a friend an we are using the decentralized workflow, we wanted to use PQM as our gate keeper but I'm having trouble even getting started, is there a good how to available, I can't find one
[18:59] <james_w> vxnick: have a look at bzr-bookmarks, it allows you to refer to different locations by short names
[19:00] <vxnick> james_w: thanks
[19:00] <james_w> cdecarlo: I don't know of one I'm afraid
[19:19] <Laney> is --fixes lp:xxx just supposed to link the branch?
[19:20] <james_w> that's all it does currently
[19:20] <james_w> there are plans to be a bit more useful I believe
[19:20] <Laney> ok, I thought it would set fix committed too
[19:20]  * Laney does so
[19:58] <ronny> jelmer: ping?
[20:34] <dirkD> is it possible to manage permissions/access rights with a bazaar smart server?
[20:35] <LarstiQ> dirkD: yes
[20:35] <dirkD> LarstiQ: :O
[20:35] <dirkD> how?
[20:35] <dirkD> just with unix permissions?
[20:35] <dirkD> (i can't find it in the user guide)
[20:37] <luks> LarstiQ: I'd say "yes" is a kind of cheating, until the smart server still has VFS calls
[20:40] <dirkD> luks: i'm using bzr 1.14
[20:40] <dirkD> so... RPC calls?
[20:41] <luks> dirkD: you can ignore me, that was purely technical :)
[20:41] <luks> what kind of access rights do you want to setup?
[20:42] <dirkD> i want to give some users access to a branch, and some users not
[20:42] <dirkD> or groups...
[20:43] <luks> the easiest way is probably to use contrib/bzr_access
[20:43] <luks> assuming you want to use bzr+ssh
[20:43] <dirkD> indeed
[20:44] <dirkD> is there any documentation on bzr_access?
[20:44] <dirkD> (it's a plugin i assume? or a patch?)
[20:44] <luks> there are some examples in the file itself
[20:45] <luks> you basically give users ssh access and restrict the commands they can execute
[20:45] <dirkD> ah
[20:45] <luks> it's in the source code tarball
[20:49] <dirkD> luks: looks fine :)
[20:49] <dirkD> but they're talking about .ssh/authorized_key
[20:49] <dirkD> is that about ~/.ssh
[20:50] <dirkD> + ?
[20:50] <dirkD> so i do have to edit authorized_keys for every user?
[20:50] <dirkD> (or create a symlink to a system-wide one of course
[20:50] <dirkD> + )
[20:52] <luks> sorry, I don't know more about that
[20:52] <luks> maybe there is a global way, I don't know
[20:52] <dirkD> ok, thanks for your help
[20:52] <bluszcz> hello, how can i create plugin on the bzr server?
[20:53] <bluszcz> i've got bzr+ssh server - on the client side pre_commit works as expected, but i cannot make it run on server on (bzr co, bzr up, bzr ci -m "" flow)
[20:58] <bluszcz> is this possible?
[20:59] <CardinalFang> bluszcz: Plugins don't do that.  Consider the SFTP transport -- it *couldn't*.
[21:01] <luks> I think there is a post push hook
[21:02] <luks> hm, no, that's not the one
[21:02] <CardinalFang> On the client, maybe.
[21:02] <LarstiQ> luks: I see what you mean, and what I was thinking of is also not directly helpful (Launchpad/ClueBzr style smartserver)
[21:03] <bluszcz> hmmmm...
[21:03] <LarstiQ> luks: post_branch_tip_change or something like that
[21:03] <luks> yeah, that one
[21:03] <bluszcz> CardinalFang: plugin's don't do what? sorry, but i didn't understand
[21:03] <LarstiQ> bluszcz: `bzr help hooks` should mention which ones get run on the server
[21:03] <bluszcz> ok
[21:04] <luks> strange, I can see post_tip_change mentioned in tests, but not the code
[21:04] <bluszcz> i was reading BranchHook.__init__ ;)
[21:05] <LarstiQ> let me fish up how I run bzr-email on the server
[21:07] <bluszcz> ok, i read help hooks but still have no idea how to install server side hook
[21:07] <LarstiQ> bluszcz: in all ~user/.bazaar/locations.conf I have: [chroot-*:///srv/bzr/]\npost_commit_push_pull = True\npost_commit_url = bzr+ssh://server/srv/bzr\npost_commit_url:policy = appendpath\npost_commit_to = commits@
[21:07] <LarstiQ> etc
[21:08] <LarstiQ> bluszcz: the plugin you execute must be loaded by the bzr your users execute
[21:08] <LarstiQ> (on the server)
[21:08] <LarstiQ> bluszcz: other than that, that should be it
[21:08] <bluszcz> reading
[21:09] <bluszcz> hm, bit complicated
[21:09] <LarstiQ> true.
[21:09] <LarstiQ> some of that is due to how bzr-email works
[21:10] <LarstiQ> bluszcz: if you write your own plugin, the key thing is to make sure your plugin code gets loaded, and that you configure for the right branch
[21:10] <LarstiQ> if you do it for all branches, that last bit doesn't matter.
[21:15] <bluszcz> hm
[21:15] <bluszcz> my configuration is:
[21:15] <bluszcz> i've got ssh acount on my server
[21:15] <bluszcz> my user
[21:15] <bluszcz> ;)
[21:16] <bluszcz> there are branches
[21:16] <bluszcz> which are checkout locally and using it as i write above (locally make commit for remote branches)
[21:17] <bluszcz> generally at this time, i am not interested in any wide system/multi user solution, only "wide" in my needs is that i want to run some plugins on the server during commiting to that branches, all branches.
[21:19] <bluszcz> (reading http://bazaar-vcs.org/ConfiguringBz)
[21:24] <bluszcz> i found also this:
[21:24] <bluszcz> https://lists.canonical.com/archives/bazaar/2008q3/044390.html
[21:27] <bluszcz> pre_change_branch_tip (Branch)
[21:29] <LarstiQ> bluszcz: does that get run on the smartserver?
[21:31] <mwhudson> jelmer: so what's new and sexy about bzr-git 0.3.0 ?
[21:33] <bluszcz> yeah
[21:34] <lifeless> moin
[21:35] <bluszcz> bzr: ERROR: Received bad protocol version marker: 'sage 3 (bzr 1.6)\n\x00\x00\x00\x1dd16:Sof'
[21:35] <bluszcz> lol
[21:35] <bluszcz> server: Bazaar (bzr) 1.14.1
[21:35] <bluszcz> local: $ bzr version
[21:35] <bluszcz> Bazaar (bzr) 1.14.1
[21:35] <bluszcz> so, wtf?
[21:35] <lifeless> bluszcz: its been mangled
[21:36] <lifeless> bluszcz: you have something outputting to stdout while you login to your machine, if you're using bzr+ssh
[21:36] <lifeless> that will also break sftp
[21:38] <bluszcz> stdout from my local?
[21:38] <lifeless> the server
[21:39] <lifeless> what protocol are you using?
[21:39] <bluszcz> yes, pluging is talking to me
[21:39] <bluszcz> bzr+ssh, ssh2
[21:39] <lifeless> ok, if you do "ssh host: echo"
[21:39] <lifeless> do you get anything shown ?
[21:39] <lifeless> sorry, get rid of the : there
[21:39] <bluszcz> bluszcz@atomic [(nie maj 10) 22:39]:~/projekty/blogi
[21:39] <bluszcz> $ ssh bzr-bluszcz echo
[21:39] <bluszcz> bluszcz@atomic [(nie maj 10) 22:39]:~/projekty/blogi
[21:39] <bluszcz> $
[21:40] <bluszcz> only \n
[21:40] <lifeless> ok that looks fnie
[21:40] <lifeless> *fine*
[21:40] <lifeless> must be something else
[21:40] <bluszcz> yes, i now
[21:40] <bluszcz> how can i pass -vvv for ssh in bzr+shs?
[21:40] <bluszcz> ssh
[21:40] <lifeless> if you have a plugin, which execs something and that writes to stdout, it can also interrupt a bzr session
[21:41] <lifeless> because the bzr protocol is writing to stdout
[21:41] <bluszcz> hm
[21:41] <bluszcz> so, i should use stderr?
[21:41] <lifeless> oh yes
[21:41] <bluszcz> to write information about "your commit message is empty?"
[21:41] <lifeless> in a plugin on the server?
[21:41] <bluszcz> btw, lifeless  - nice nick ;)
[21:42] <bluszcz> lifeless: yes, on the server
[21:44] <lifeless> one sec I'm looking up a bug for you
[21:44] <bluszcz> ok
[21:44] <bluszcz> it looks like working now
[21:45] <bluszcz> :)
[21:45] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/364908
[21:45] <lifeless> thats a closely related issue
[21:46] <lifeless> however, if your plugin is actually stopping the commit/push, you should probably just raise an exception -  except that won't get formatted well. hm time for another bug
[21:46] <bluszcz> yea
[21:47] <bluszcz> raise "You should check first you *py files, or die"
[21:49] <lifeless> if this is a pre-tip-change hook
[21:49] <lifeless> there is a specific exception for that you can raise
[21:49] <lifeless> which I think gets formatted nicely
[21:49] <lifeless> errors.TipChangeRejected
[21:51] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/374605
[21:51] <lifeless> just filed that for you
[21:53] <bluszcz> :)
[21:54] <bluszcz> Robert Collins 2 minutes ago Changed in bzr:
[21:54] <bluszcz> importance: 	Undecided → High
[21:54] <bluszcz> status: 	New → Confirmed
[21:54] <bluszcz> things really goes fast
[22:03] <bluszcz> ok, now i have to read how to read file liste
[22:46] <bluszcz> ech, it has only:         # (params) where params is a ChangeBranchTipParams with the members # (branch, old_revno, new_revno, old_revid, new_revid)
[22:46] <bluszcz> no way i suppose to check the commited files
[22:47] <mwhudson> is it possible that getting a dev6 branch over http would use very large amounts of RAM?
[22:48] <bluszcz> dev6?
[22:48] <bluszcz> user ram on which element? client or server?
[22:49] <mwhudson> bluszcz: the development6 format
[22:49] <bluszcz> "uses"
[22:49] <lifeless> mwhudson: if it is file a bug
[22:49] <lifeless> mwhudson: it might if transcoding
[22:49] <mwhudson> lifeless: ok, finding out now
[22:49] <mwhudson> lifeless: it really really shouldn't be doing that
[22:49] <mwhudson> but i guess i can find out
[22:51] <[tpd]> Hey folks, does anyone here use bazaar for website deployment?
[22:51] <mwhudson> [tpd]: some people do, and they find the bzr-upload plugin useful
[22:52] <[tpd]> Ah, is that a standard way of doing it? I'm new to vcs.
[22:55] <mwhudson> [tpd]: it's what the plugin is for
[22:56] <[tpd]> I understand that, but is this how it "should be done"?
[22:56] <mwhudson> i don't know of any better way
[23:31] <bluszcz> how is the best way to gest list of modified files using bzrlib.?
[23:31] <lifeless> in a commit?
[23:31] <bluszcz> si
[23:31] <lifeless> bzr st -c rev
[23:31] <lifeless> oh, bzrlib
[23:31] <bluszcz> si
[23:32] <lifeless> tree1, tree2 = bzrlib.repository.revision_trees([rev1, rev2])
[23:32] <lifeless> changes = tree2.iter_changes(tree1)
[23:32] <bluszcz> checking, thanx
[23:33] <bluszcz> no such revision_trees hm
[23:34] <lifeless> sorry
[23:34] <lifeless> I meant 'repository.revision_trees'
[23:34] <lifeless> where repository is a bzrlib.repository.Repository object
[23:34] <lifeless> if you have a branch its branch.repository
[23:34] <lifeless> if y ou have a working tree its wt.branch.repository
[23:34] <bluszcz> working tree is easiest i think