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