[00:17] <poolie> ok
[01:06] <lifeless> jelmer: hi
[01:35] <meoblast001> why isnt the bzr server at launchpad.net working
[01:36] <mwhudson> it's not?
[02:10] <indigo> is there a command to pull uncommitted changes from one working tree to another?
[02:10] <indigo> say i started to make some changes and decided i should have made a branch
[02:10] <indigo> my memory says yes, but not enough to find it in the docs.
[02:11] <bob2> merge can
[02:11] <bob2> you could also 'switch' that working tree to a branch
[02:11] <beuno> bzr merge --uncommitted
[02:11] <indigo> that's the one
[02:11] <indigo> thanks
[05:09] <Spaz> o_O
[05:09] <Spaz> /usr/lib/python2.6/site-packages/Crypto/Hash/SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
[05:09] <Spaz>   from sha import *
[05:09] <Spaz> /usr/lib/python2.6/site-packages/Crypto/Hash/MD5.py:6: DeprecationWarning: the md5 module is deprecated; use hashlib instead
[05:09] <Spaz>   from md5 import *
[05:09] <Spaz> with bzr
[05:09] <Spaz> has this been fixed yet?
[05:23] <spiv> Spaz: I think so; certainly bzr.dev seems to try hashlib first.
[05:25] <mwhudson> Spaz: that looks like a problem in pycrypto, not bzr
[05:25] <Spaz> huh
[05:26] <spiv> mwhudson wins today's prize for reading comprehension
[05:27] <spiv> Arguably bzr should be suppressing all DeprecationWarnings.
[05:28] <spiv> They aren't much use to end users, they're really messages to developers.
[05:29] <spiv> So it'd be reasonable for "bzr selftest" to report them, but maybe nothing else should.
[05:29] <spiv> (unless you look in ~/.bzr.log or pass a -Ddeprecations flag)
[06:25]  * spiv finishes for the day
[07:11] <vila> hi all
[07:52] <poolie1> hello vila!
[07:53] <vila> hi poolie ! I thought you were already gone in vacations...
[07:54] <poolie1> i was yesterday, but just for one day
[07:54] <vila> haaaa, ok
[09:22] <schizoschaf> is there a book on bazaar?
[09:24] <bob2> no
[12:17] <AfC> Is somebody working on a book on bazaar?
[12:34] <noodles_20> AfC: not that I'm aware of.
[12:35] <loxs> hello folks, does bazaar provide a way for customized user permissions, like this is possible with svn?
[12:35] <AfC> loxs: Execute bit has been supported since the beginning.
[12:35] <AfC> loxs: are you looking for more than that?
[12:36] <spiv> loxs: you mean access control on the repository itself?
[12:36] <AfC> spiv: (oh, right)
[12:36] <loxs> yes. the central one... I want to be able to give various users permissions to only commit code to a particular directory/file
[12:38] <spiv> loxs: the simplest solution is to use ordinary user accounts and filesystem permissions to restrict write access per branch. (or per project, if you use a shared repository per project, as is common.)
[12:41] <spiv> loxs: depending on what you're looking for, you *might* be interested in using a tool like PQM (https://launchpad.net/pqm) as a gatekeeper that vets commits to a central branch, e.g. to make sure all commits pass "make check"
[12:44] <spiv> loxs: I don't know of any out-of-the-box ways to restrict write access of just particular directories/files within a branch.  You could probably configure or extend PQM to do something like that, if PQM's workflow suits your use case.
[12:44] <spiv> loxs: but it'd probably be simplest to make separate branches for those parts of your tree, and use regular filesystem permissions.
[12:47] <spiv> If commits to the central branch are exclusively done over bzr+ssh, you could write a plugin for the server that installs a pre_change_branch_tip hook function to vet the commit.
[12:49] <spiv> While a server-side pre_change_branch_tip hook should work well in theory, I don't think there's much infrastructure to make writing those sorts of hook functions convenient yet.  (it's not well documented how to write a hook function that gets a list of files that are touched by the proposed revision, for instance)
[12:49]  * spiv -> bed
[12:50] <loxs> thanks folks
[13:23] <lfaraone> hi, what's the difference between branch and checkout?
[13:32] <luks> lfaraone: the commands or the terms in general?
[13:33] <lfaraone> luks: both.
[13:33] <luks> let's start with the terms first, then :)
[13:33] <luks> a checkout is the area you work with, it's basically the working tree with some local metadata
[13:34] <luks> every checkout is linked to a branch, and this branch can be either local or remote
[13:34] <luks> so that if you commit the working tree, it will update the linked branch
[13:35] <luks> and it's also possible to have 'bound branch', which is a branch that will update another remote branch on commit
[13:35] <lfaraone> ah.
[13:35] <luks> so, when you run 'bzr checkout --lightweight', it will create a local checkout bound to a remote branch
[13:35] <lfaraone> Now a more practical question: I'm trying to do work on a svn branch, but it has 6959
[13:36] <lfaraone> revisions, and this is over ssh. can I check out the most recent rev?
[13:36] <luks> and 'bzr checkout' will create a local checkout, local branch and the branch is bound to another remote branch
[13:36] <lfaraone> s/branch/repo/
[13:36] <luks> with bzr-svn?
[13:36] <lfaraone> luks: yeah.
[13:37] <luks> then just 'bzr branch svn+ssh://host/path/to/svn/repo'
[13:37] <luks> (or whatever is the scheme svn uses for ssh named)
[13:37] <lfaraone> luks: I don't want to download the complete branch history, I only need the most recent rev.
[13:38] <lfaraone> luks: it's going to take an age that way.
[13:38] <luks> lfaraone: you can try 'bzr checkout --lightweight ...', but I doubt it will be any faster
[13:38] <luks> lfaraone: or just use svn, if you don't intend to commit to it :)
[13:39] <lfaraone> luks: heh...
[13:39] <luks> bzr-svn needs to know the metadata about the whole history
[13:39] <luks> so at minimum that needs to be downloaded
[13:40] <luks> how do you want to use bzr with no history, though?
[14:31] <Tak> why is it that sometimes I can just pull, and other times I have to pull and then update? (for source-level changes to be reflected in my working branch)
[14:31] <jelmer> that should only happen if you are pulling into a remote branch
[14:31] <jelmer> or if "bzr pull" crashes
[14:32] <Tak> does it make a difference if I'm using bzr-svn?
[14:32] <jelmer> no
[14:32] <Tak> how about olive?
[14:33] <jelmer> You use olive to pull, you mean?
[14:33] <Tak> yes
[14:33] <Tak> well, in this latest instance
[14:33] <jelmer> perhaps it's a bug in olive then
[14:33] <Tak> I've had it happen before as well; can't remember whether I used olive on the previous occasions or not
[15:05] <loxs> is there a way to tell bzr to "destructively" update my working tree? I mean, overwrite all the conflicts with the upstream branch?
[15:06] <luks> working tree or branch?
[15:07] <loxs> working tree.... I don't want any conflicts. I just want to synchronise with the upstream branch
[15:07] <luks> what command did you run?
[15:07] <luks> (that produced the conflicts)
[15:07] <loxs> bzr up
[15:07] <luks> oh, I don't know then
[15:08] <loxs> I had changed files and I don't want the changes
[15:08] <luks> I think just bzr revert should do the job, but I don't use checkouts much, so Im not sure
[15:08] <loxs> ah, you are right
[15:08] <loxs> thanks
[15:13] <jelmer> asabil: hi
[15:13] <asabil> hi jelmer
[15:13] <jelmer> asabil: What happened to your "branch description" patch?
[15:13] <jelmer> Did it make it in?
[15:13] <asabil> I don't remember so
[15:13] <asabil> that was over a year ago
[15:14] <asabil> the main issue was that it was handled in the same way as branch nicks at that time
[15:14] <jelmer> nm, just found it: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C6b4de4d80709132323o2c9603ebscce92c066f473919%40mail.gmail.com%3E
[15:15] <asabil> :)
[15:17] <jelmer> looks like it's mainly waiting for formatting fixes
[15:18] <jelmer> do you intend to finish it?
[15:40] <asabil> jelmer: well I cannot promise anything
[16:51] <awilkins> slashdot.org
[16:51] <awilkins> oops
[17:16] <jam> vila: ping
[17:16] <vila> jam: pong
[17:16] <jam> How's it going?
[17:17] <vila> fine :)
[17:17] <jam> I BB:tweak'd your --forward patch
[17:17] <jam> And was wondering what you thought of the feedback
[17:17] <vila> About to call it a day, but deep into content conflicts while a bug bzr check is sucking my CPU cycles :)
[17:17] <vila> s/bug//
[17:18] <vila> Just a sec
[17:20] <vila> "direction" into 'get_view_revisions': I agree with your doubts, but the results are correct...
[17:20] <jam> as long as you have tested it directly I'm happy enough with that
[17:21] <jam> I can see how it would work because of the "by-depth" stuff
[17:21] <vila> but still, reverse_by_depth make heads explode when coding _:?
[17:22] <vila> otherwise, full agreement with the other remarks and thanks for catching them !
[17:23] <vila> This is where review rocks IME, you hack-hack-hack and the result becomes clearer... for the reviewer :)
[17:24] <vila> anyway, thanks for the review, I'll recheck filter_revisions_touching_file_id before submitting (playing with it right now for another need :)
[17:37] <loxs> is cygwin the only way to allow windows machines to connect to bazaar repositories vie sftp?
[17:37] <loxs> or ssh+bzr
[17:38] <jam> no
[17:38] <jam> loxs: If you have 'paramiko' installed we don't need cygwin at all
[17:38] <jam> (and it is bzr+ssh, for what it's worth)
[17:38] <jam> The standalone win32 installer should include paramiko
[17:39] <jam> Available here: https://edge.launchpad.net/bzr/1.9/1.9
[17:39] <jam> or as a direct link: http://edge.launchpad.net/bzr/1.9/1.9/+download/bzr-setup-1.9.exe
[17:39] <Tak> is bzr-svn part of the windows installation now?
[17:40] <noodles_20> Any bzr people who knows how to restore a branch when seeing "Supplied history does not follow left-hand parents" errors? splodge has a question on #launchpad...
[17:41] <jam> noodles_20: 'bzr reconcile' fixes it (albeit it also tries to fix a bunch of other stuff at the same time). I think you can also "bzr push --overwrite ." to have the local branch clean itself up. Though it also sounds like it is an older format branch, so "bzr upgrade" may be recommended.
[17:41] <noodles_20> thanks jam.
[17:41] <Tak> splodge: are you the same splodge from UDC forums?
[17:42] <splodge> Yep
[17:42] <Tak> sweet!
[17:42]  * Tak <=
[17:42]  * splodge feels popular all of a sudden.
[17:42] <jam> Tak: it should be in the newer installers, yes
[17:42] <jam> (only the all-in-one installer, not the "install into an existing python install")
[17:43] <Tak> I'll give it a try, then - I've been sitting on bzr 1.4 because that was the latest one with a bzr-svn installer
[17:44] <jam> I think 1.7 has it, but I'm sure that 1.9 does as well
[18:23] <Tak> bzr-svn does indeed appear to Just Work with the 1.9 win32 standalone installer
[18:56] <derekS> has anyone ever seen this error: UnicodeEncodeError: 'ascii' codec can't encode character u'\xae' in position 103: ordinal not in range(128)
[18:56] <derekS> i am trying to pull
[19:14] <jam> derekS: Presumably you are updating to a revision which now includes a non-ascii character
[19:14] <jam> but your system claims that the filesystem doesn't support it.
[19:14] <jam> derekS: As part of the exception, I would expect us to report what we think fs_enc is
[19:14] <jam> do you see that line?
[19:15] <jam> I believe I've also seen at least something similar when fs_enc is UTF-8, but you have a file that is in latin-1 encoding
[19:15] <jam> we fail because we can't understand the filename, as it isn't actually valid given your fs_enc
[19:28] <derekS> jam: checking
[19:29] <derekS> not seeing it, i lost it in the scroll buffer when i looked at the bzr.log
[19:30] <derekS> let me try to pull it again
[19:30] <derekS> btw this is the cygwin build
[19:30] <derekS> version 1.8
[19:37] <synic> how can you tell what repository is being accessed in a hook?
[19:59] <jam> derekS: cygwin only supports ASCII, so we can't add support for anything else on top of it
[19:59] <jam> I think there are some random patches out there to update cygwin to support utf8
[20:00] <jam> My suggestion would be to use the windows native build
[20:00] <jam> It is significantly faster because it doesn't go through the cygwin overhead
[20:00] <jam> (bzr status is 2s for me under cygwin, and 0.5s using the win32 native client)
[20:00] <jam> I generally use cygwin as a shell, and normally don't have problems running native bzr at the same time
[20:01] <jam> The only problems are when I would type ~/path/from/home since that breaks between win32 native and cygwin
[20:01] <mwhudson> synic: usually the hook takes arguments that let you find out, which hook are you interested in?
[20:14]  * mwhudson grrs at bzrlib's docstrings
[20:18] <synic> mwhudson: post_psuh
[20:18] <synic> er.. push
[20:20] <mwhudson> synic: well push_result.source_branch.repository ?
[20:20] <mwhudson> as in http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#hooks
[20:20] <synic> thanks
[20:35] <asac> hi. bzr-svn + authentication? is there any trick to make that work?
[21:02] <synic> a post hook is supposed to run on the server if the connection was started with bzr+ssh, right?
[21:02] <synic> er,, a post_push
[21:03] <synic> I can't seem to get this one to work
[21:05] <mwhudson> i think post_push is a client side hook
[21:06] <synic> hrmm
[21:06] <mwhudson> post_change_branch_tip runs on the server though
[21:06] <mwhudson> (pre_change_branch_tip too)
[21:08] <synic> alright
[21:10] <loxs> is there any problem if I use one repository to store branches from different projects?
[21:13] <hsn_> loxs: no
[21:14] <loxs> hsn_, so then it's ok if I give all my developers their own repository, and they can store all their branches from all our projects in that repository?
[21:19] <hsn_> loxs: yes. just `bzr check` operation takes some time on large repos
[21:19] <loxs> thanks
[21:22] <synic> mwhudson: when printing branch.repository, I get KnitPackRepository('chroot-166445772:///send-admin/.bzr/repository/')
[21:23] <synic> how can I programatically get the "send-admin" from it?
[21:23] <mwhudson> um, i guess from repository.transport.base
[21:23] <mwhudson> (which i think will be the string 'chroot-166445772:///send-admin/.bzr/repository/'
[21:24] <mwhudson> then parse it as a url, take the path and strip .bzr/repository off it
[21:24] <mwhudson> synic: but mostly educatedly guessing here, not really sure
[21:24] <synic> yeah, that works
[21:24] <synic> but I have to use repo._transport
[21:33] <Kobaz> is there a way to combine all your local branch commits into one commit, before doing a push
[21:35] <mwhudson> Kobaz: well, i guess you can merge your new commits onto a fresh copy of the push target before you push
[21:38] <Kobaz> that works
[21:45] <phoenix3051> Is there away to limit the amount of bandwidth bzr using when branching across a network?
[22:04] <poolie> jam, spiv, call in a minute?
[22:07] <pygi> hi hi
[22:42] <synic> anyone about?  I've written a plugin to limit who can access a repository via bzr+ssh.  Right now, an exception is thrown (errors.PermissionDenied) if the user doesn't have access, but it creates an InternalError on the client side
[22:42] <synic> is there a way to tell the server just to send something like: bzr: ERROR: Not a branch:
[22:44] <mwhudson> synic: _usually_ a permissiondenied on the server side is correctly translated to one on the client side (these days)
[22:45] <mwhudson> synic: can you pastebin the client side traceback?
[22:48] <synic> yeah
[22:49] <synic> http://rafb.net/p/bLjMHZ58.html
[22:50] <mwhudson> synic: maybe check with spiv, but it looks like a bug
[22:51] <synic> well, it accomplishes the goal, but yeah, it does appear to the user as a bug within bzr
[22:51] <synic> and asks them to file a bug report
[22:51] <synic> probably because of how I designed the plugin
[22:53] <mwhudson> synic: you might also want to try with a newer bzr client
[22:53] <mwhudson> there have been related bugs fixed since 1.6.1 i think
[22:53] <synic>  ah.
[22:53] <synic> well, all in all, though, that gitosis port works.
[22:54] <mwhudson> cool
[22:59] <spiv> synic: I'm pretty sure bzr.dev (and probably 1.9) will handle that better.
[22:59] <synic> yeah, trying it now
[23:01] <synic> bzr: ERROR: Permission denied: "test": : You do not have read access for this repository.
[23:01] <synic> yeah, that looks tons better
[23:01] <mwhudson> cool
[23:02] <synic> thanks :)
[23:02] <slangasek> jelmer: have you had any luck yet with that bzr-svn bug (grub merge)?
[23:02] <spiv> synic: you're welcome :)
[23:09] <synic> man, the bzrlib code is so cool ... compared to what I'm used to reading anyway.  Hah.
[23:13] <mkanat> After a cvsps-import, I'm getting: bzr: ERROR: Revision {('cvs-1:lpsolit-20081021203555-abgb5fh0dqaorsib',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xb797eb6c>".
[23:13] <mkanat> What's up with that?
[23:15] <mkanat> Anybody? :-) jam?
[23:18] <mkanat> I also get: /usr/lib/python2.4/site-packages/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///home/mkanat/cvs-import/selenium-import/bzr/selenium/.bzr/repository/>) was not explicitly unlocked
[23:36] <nekohayo> ping, lifeless?