[00:01] jelmer: its not without its problems - it can only handle revisions that came from git as it stands for example. [00:02] anyway, i think im going to sleep at this point :] === sdboyer_ is now known as sdboyer [00:33] :( :( :( :( [00:33] I hit Ctrl-C during an up-thread --auto and now everything is screwed :( [00:35] switching down to trunk and doing up-thread manually all the way to the top seems to work ok. [00:35] (i.e. fix the problem of pending merges without working tree changes) [00:36] I hope I haven't actually screwed up the loom though [00:36] jml: interesting [00:36] jml: up-thread --auto probably wnats a KeyBoardInterrupt catch-and-rollback [00:36] it all started when I accidentally hit "bzr up-thread --auto" when I had uncommitted changes [00:36] and so hit C-c [00:38] hmm. bzr di -r branch:../trunk/ looks about right. [00:38] jml: bottom: might be easier :) [00:39] lifeless: but less reliable, given that the loom itself is now suspect. [00:40] jml: current-thread writes are atomic, and up-thread doesn't modify the bottom thread, so I don't see bottom: being faulty === rocky1 is now known as rocky [00:47] rocky, hi [00:47] rocky, any chance you can confirm that bug in bzr-svn you were hitting is fixed now? [00:49] ohh... [00:49] unfortunately i'm away from my workstation atm, but i'll certainly try it as soon as i can [01:02] jam: still around? === joshuabl1unt is now known as jblount [02:23] hi all [02:28] igc: hi [02:28] igc: are you up for a quick skype call? [02:28] thumper: sure [02:45] thumper: http://arstechnica.com/news.ars/post/20090107-dvcs-adoption-is-soaring-among-open-source-projects.html [02:53] I need to pop out for a minute to the chemist [02:53] brb [02:56] Tree transform is malformed [('versioning no contents', 'new-4')]??? [02:56] what does that mean? [03:12] hi all! [03:12] I'm trying to understand using launchpad for merging branches. [03:12] thumper: it's either a bug in bzr, or in code that's calling in to bzrlib [03:12] Should there be a big "MERGE" button that I'm looking for? [03:13] poolie: ta [03:13] emmajane: launchpad doesn't merge branches for you yet [03:13] emmajane: we have some kinda future plans, but it just isn't there yet [03:13] thumper, ah! probably why I can't find a button. :) [03:13] emmajane: exactly [03:14] thumper, I'm glad to know I'm just a futurist instead of plain ol' daft. ;) [03:14] heh [03:15] emmajane: lets just say I have a loom with about 8 threads dealing with this topic [03:15] that I haven't had time to get to [03:15] awww. [03:15] ('cause I'm a manager now) [03:15] So I guess I shouldn't wait for the button to appear tonight? ;) [03:15] and I don't get as much time to code as I'd like [03:15] (congrats on your promotion) [03:15] emmajane: sorry, no [03:16] emmajane: promotion was quite some time ago [03:16] but thanks [03:16] thumper, heh. so you're only just coming to grips with never being able to code again. ;) [03:16] well, I hope not never [03:16] just not as often as I'd like [03:17] * emmajane nods [03:17] so to merge I need to pull down the branch I want to merge into; merge; and then push back up? [03:17] * emmajane has never done this before. [03:17] emmajane: can you give me a concrete example? [03:18] https://code.edge.launchpad.net/~emmajane/ubuntu-desktop-course/udc-804/+merge/2799 [03:18] that's sort of concrete, eh? :) [03:18] * thumper looks [03:18] right [03:18] I'm very happy to RTFM if there's anything specific for launchpad. [03:19] -beta needs to go into main. [03:19] lifeless: can we catch up before you finish today, maybe at 4? [03:19] emmajane: ok, so you are a member of the team that owns the target branch, so that means you can do it [03:20] emmajane: did you want to move this to #launchpad? [03:20] thumper, can do. :) [03:24] poolie: shortly before owould be fine [03:24] and migod its hot out there === Mario__ is now known as pygi [03:26] isn't it just [03:32] anyone know of stats modules in the stdlib ? [03:33] e.g. to get stddev, IQR etc [03:41] can someone look at bzrlib.check.Check._check_one_revision [03:41] thumper: hi [03:41] lifeless: i'm pretty sure there is an SD function [03:41] in math? [03:41] poolie: hi, just helping emmajane on #launchpad [03:42] thumper: whenever you like [03:42] lifeless: in scipy according to google [03:42] it's not in math [03:43] yeah, I knew scipy would have everything I'd need [03:50] but its not stdlib :( [03:52] copy & paste? [03:52] lifeless: what about that function? [03:52] check_one [03:53] poolie: well several things [03:53] it calls check revision tree [03:53] which means we're extracting the inventory for every revision 3 times I think, maybe more [03:54] once there, once to generate the text key references, and once in check_weaves [03:55] check_revision_tree seems to check that the fileid iteration of the inventory only yields each id once; which seems rather redundant to me - its checking using too high an API pehaps [03:58] and then InventoryFile._check seems to double-check the sha1, which means we're extracting every file text twice (or more) [03:58] poolie: call? [03:58] so I'm saying it seems like check can be halved in time without huge effort [04:10] how hard would it be to add a debug option to bzr that shows bytes transferred? is there one already? [04:10] (or can I trick linux into doing this for me somehow?) [04:10] jml: -Dtransport possibly, also see vila's transport debugging plugin [04:12] lifeless: thanks [04:12] ethereal could, too [04:13] bob2: ELOWTECH [04:13] hehe [04:17] lifeless: yes that's all true [04:17] about check [04:17] poolie: thanks, useful confirmation [04:18] you want that call now? [04:18] poolie: ^ [04:19] lifeless: talking to thumper at the moment but straight after that would be good [04:19] ok [04:19] I want to finish sharp at 4 [04:21] k [04:54] * emmajane chuckles at poolie. I assure you it's mostly photos of knitting and looms. [04:54] i was seriously impressed by the looms [04:54] Thanks. :) [04:55] * emmajane is pretty hardcore into the fibre arts. [04:55] That's only because I'm a recovering bookbinder though. [05:04] Aren't photos of knits deprecated? :p [05:09] * emmajane chuckles. [05:14] emmajane: what was it that made you chuckle anyhow? [05:15] poolie, knitting and looms and bzr. It amuses me more than it should. [05:16] poolie, a friend of mine also runs a craft show called http://www.bazaarbizarre.org/cleveland.html === sdboyer_ is now known as sdboyer [05:58] Alright. On that happy note. I'm going to give up on the idea of eating supper (it's 1AM) and trundle off to sleep. http://emmajane.net/node/884 <-- thanks for the help (although it happened over yonder, it all started here). [07:08] hi all [07:09] Good morning. :) [07:54] hello vila, Peng [07:54] sleepy [08:44] night === thekorn_ is now known as thekorn [11:02] siretart: heya! In bug 317001 you say an unwriteable dir to watch cause bzr-hookless-email to traceback, I haven't yet managed to reproduce that (then again, I'm still sleepy) [11:02] Launchpad bug 317001 in bzr-hookless-email "ugly traceback when directory to watch is not writeable" [Undecided,New] https://launchpad.net/bugs/317001 [11:06] LarstiQ: yes. testcase: chown -R the branch to root:root and try as user [11:07] silly use case, I know, but we have system configuration managed in a bzr branch, and wondered if I can setup the monitoring (bzr-hookless-mail) as non-priviledged user [11:07] LarstiQ: btw, did you query me before? [11:08] siretart: not in a looong time [11:08] ok. then it was someone else :) [11:09] ah, there needs to be a branch in place *doh* [11:09] yes. I assume the plugin doesn't work else anyways.. [11:10] siretart: it does, it notices branches that get created after it starts watching [11:10] (not branches that get mv'ed in the hierarchy, but I've almost fixed that) [11:10] siretart: and of course it needs to open a branch to trigger that traceback, I was just being stupid [11:12] siretart: I'll push your changes up in a sec, thanks for the patch! [11:13] you're welcome! [14:15] guilhembi: ping === montabeau is now known as abeaumont [16:30] How do I have a branch un-ignore a file extension is ignored globally? [16:30] that is* [16:31] ericvw: I don't think there's a way to do that, but you can explicitly override the ignore by "bzr add " [16:32] it will version the file of course [16:32] jelmer: Okay, I will do that for now. Thanks! === mvo_ is now known as mvo === asac_ is now known as asac [18:11] how come sometimes i get: These branches have diverged. Try using "merge" and then "push". [18:11] and sometimes i don't [18:11] sometimes it will merge for me, and it's auto [18:11] here's an example [18:11] It will never merge for you. [18:12] The snarky answer is of course "because sometimes they're diverged, and sometimes they haven't" :p [18:12] files 1,2,3 exist in the repo, user A makes changes to file 1 and does a push, user B makes a change to file 2 and does a push [18:12] and bzr will complain branches have diverged [18:12] so now i have to do a merge [18:12] even though nothing is in conflict [18:12] It's a question of what revisions are where. [18:13] If all the revisions on the far side are in your local history, they're not diverged, and push can Just Run. [18:13] and then other times, person A will modify file 1, and person B will modify file 2, and then a pull is down, and the files are brought down and merged in [18:13] If there are revisions there that you don't have, though, you have divergeance. [18:13] mmm [18:13] so it has nothing to do with conflicts then [18:13] Kobaz: correct [18:14] Yah. Push doesn't do merges, or create new revisions; it just moved around revs that are already created. [18:14] Kobaz: the divergence is about wether both branches have different revisions from a certain point [18:14] Kobaz: do you know the `bzr missing` command? [18:15] yeah [18:16] so if there are missing revs, then you need a merge? [18:16] sorry, phone call interrupted [18:16] Kobaz: no [18:17] Kobaz: if missing reports extra revisions for one side only, yours, or theirs, then you can pull/push and do not need a merge. [18:17] Kobaz: but if missing shows extra revisions for _two_ sides, that is when divergence has occurred and you would need a merge [18:17] If the other side has revs you don't, you're out of date and can pull. If you have revs the other side doesn't, then it's out of date and you can push. [18:18] If you both have revs the other doesn't, then you have divergeance, and have to merge them. [18:18] * LarstiQ nods [18:18] (that's a rather simplified way of looking at it, but it works) [18:18] Kobaz: does that make sense? [18:19] sec [18:19] lifeless: oh oh, I got an Acer Aspire One, so now I have a laptop with working wireless ;) [18:22] okay, i see === thekorn_ is now known as thekorn [18:38] jam, second day using yout log alias, and it's 100 times more comfortable to use. Speed and presentation-wise === lamont` is now known as lamont === andreas__ is now known as ahasenack [19:27] hi um, bzr just told me that a file i have on launchpad.net has been locked for 900+ hours, and the error said to use " bzr break-lock lp-46717904:///~maco.m/5-a-day-data/main/.bzr/branch/lock [19:28] but when i do that, bzr then tells me that it's an unsupported protocol [19:28] why's it telling me to do something it can't do? [19:28] maco, try running bzr break-lock on the branch location [19:28] maco, that's a bug in the launchpad plugin [19:29] so remove the -##### stuff so it just says lp: like it normally does? [19:29] beuno: yeah, I like it a lot, too [19:30] a *long* time ago I proposed it as the default for "bzr log", but I think at that time we decided to be compatible with other systems [19:30] maco: yeah [19:30] maco, yeah [19:30] ok, thanks [19:30] bzr break-lock lp:~maco.m/5-a-day-data/main === nevans1 is now known as nevans [20:00] jelmer: A thought occurred to me while I was eating my lasagna tonight. [20:01] The bzr-svn logs show that there are lots of "get-dir" requests going back and forth to the SVN server, but they all seem to concern past revisions. [20:01] Shouldn't their results be cached? Surely that data is not expected to change over time, is it? === fta_ is now known as fta [20:23] Lo-lan-do: Those results specifically are not cached but some of the data that is inferred from them are [20:27] vila: ping === kiko is now known as kiko-afk [20:28] hi is it possible to follow symlinks? [20:30] jelmer: So... why not cache the rest and do without the round-trips? Or am I talking complete nonsense? [20:30] Lo-lan-do: Too much caching takes up too much disk space [20:30] Lo-lan-do: Also, I'm not sure why it's looking at those older revisions at all [20:35] Well, I'd be willing to sacrifice some more disk space if it means a commit to SVN takes significantly less than half an hour. [20:37] Lo-lan-do, let's figure out first why it's looking at those older revisions [20:37] also, a single get-dir call isn't supposed to be as slow as it appears to be for you [20:37] Sounds like a plan. How can I help? [20:38] should just be a single round-trip with about a kb of data [20:38] I guess the remote server is slow... [20:38] anyone? [20:38] dereine: your question doesn't make sense to me as-is, could you elaborate? [20:39] But even if it weren't, there's a scalability problem: the number of requests is O(number of revisions committed through bzr-svn) [20:39] If they catch you, they might call the cops... [20:39] i have a repo called config [20:39] where i link all my config files [20:39] but bzr only diffs the links itself and not the file behind it [20:40] dereine: Store the files under bzr and do the symlinks the other way round? [20:40] no other way? [20:41] Lo-lan-do, It shouldn't be of that order though [20:42] dereine: no other way [20:42] ok thx! btw bzr is awesome! [20:42] Hardlinks maybe. [20:43] Lo-lan-do: I doubt they won't be broken by bzr though. [20:43] LarstiQ: If you just use bzr as a backup mechanism and only do the restores by hand, myabe you can afford that. [20:44] Lo-lan-do: possibly [20:45] dereine: how are you using bzr that this becomes an issue? [20:45] i have ~/.config [20:46] no [20:46] ~/config, there i would like to collect all config files for example ~/.bashrc [20:46] and ~/.vimrc ... [20:46] but i don't want to have my home folder as repo [20:47] jelmer: git pack delta compression [20:49] dereine: ah, right [20:49] dereine: I do that with a ~/dotfiles branch, and then I symlink ~/.zshrc to ~/dotfiles/.zshrc etc [20:50] its still ok [21:34] what is the difference between init-repo and init? [21:35] One initialises a repository, the other initialises a branch. [21:35] mh i did not used init-repo [21:37] That's not strictly necessary. [21:37] A repo is just a way of storing data that saves disk space when several branches share some revisions. [21:39] for my config i only need one branch [21:39] * dereine still has to learn [21:39] Then no repo is needed. [21:39] so i pushed my current branch to a webspace [21:39] removed my local one [21:40] bzr branch the webspace one [21:40] so now i change a file locally [21:40] how can i get them to the server?, so how can i commit on the server [21:41] Either you commit locally then push, or you bind your local branch to the remote one and every commit you do locally will automatically be pushed. [21:41] what happens if i have no internet connection if i bind? [21:42] Then you can do bzr commit --local, and push only when you get back on the net. [21:42] ah nice [21:42] Or bzr unbind, work, commit, bzr push, bzr bind [21:42] wow [21:43] thats much better than any cvs stuff [21:43] You know, I think that kinda was the point :-) [21:43] Note that a bound branch is also known as a "checkout". [21:44] So when you do "bzr checkout $remotebranch", it behaves the same as a CVS or SVN checkout. Except you can do diff and log and annotate and whatnot even when you're not on the net. [21:45] the idea of working locally is just much better! [21:46] can you explain what https://launchpad.net/bzr-push-and-update does exactly? [21:47] Yeah. [21:47] When you're in a branch, you've got your files, and your .bzr dir. [21:48] That .bzr dir contains the history of the revisions so far. [21:48] exact [21:48] yes? [21:48] When you commit or log or diff, the command operates on that .bzr dir. [21:49] When you push to a branch, bzr mostly updates the stored revisions, ie the .bzr dir of that branch. [21:49] The actual (plaintext) files need to be updated separately. [21:50] If the branch is local, then they are updated automatically, but if the branch is remote then they're not. [21:50] they are only updated if someone merges them from the repo? [21:50] Yup, or if the branch is local. [21:51] a personal question, do you have your whole homefolder in a repo? [21:51] That plugin does the update for remote branches accessible through ssh. [21:52] nice [21:52] No. I have my ~/bin in a repo, and most of my ~/debian/* stuff, but I not the whole home dir. [21:53] just wonders. because i wait for 5 minutes for a push a branch with files(not .bzr) of one mb [22:02] jam: w.r.t. log --short FILE not working ... [22:03] I think we need to always include_merges inside calculate_view_revisions if there's a fileid given [22:03] sound right? [22:04] that should give us the correct projection onto the mainline [22:09] 'morning Ian [22:11] how can i save the repo , so that i only have to write bzr push? [22:12] bzr push --remember $remotelocation [22:12] wow incredible [22:12] Although I think it remembers automatically the first time you push [22:12] it does [22:13] hmm [22:13] *somebody* should fix progress indication [22:14] ...or make stuff so fast that it's unneeded :-) [22:14] * LarstiQ quickly goes to sleep [22:32] poolie, thanks for sending the standup notes again [22:32] beuno: apropos of not much, the directory listing for serve-branches should probably paginated [22:32] -d [22:33] Uh oh. [22:33] "mbp: several calls; today will bzrtools into ppa" [22:33] Hi, I've pushed a few python files onto a ssh server I'm running, and me and a few others will be working on these files on separate machines. I've read the user guide but I'm not quite I understand fully the difference between using branch and merge or checkout and update [22:33] He ran out of verbs already :( [22:34] Haffi___: Checkout gives you a [n additional] working tree on a branch. Branch gives you a new independent branch. [22:34] "There should be a newer version of Bzrtools available, e.g. 1.12." [22:34] abentley: is this true? [22:34] Haffi___: Update is how you bring a working tree up to date with its branch. Merge is how you integrate changes from 2 branches together. [22:35] fullermd: So if we're trying to keep things centralized, then we should use checkout and update? [22:35] (also, rain causes rainbows, and babies come from good home-cookin') [22:36] Haffi___: That way you'd have everybody working in lockstep on one branch (CVS/SVN style). [22:36] Now, that doesn't stop people from making their OWN branches and working in them locally, then later merging them into the checkout of trunk. [22:38] jml: No, it's a little early for 1.12. [22:38] hmm. [22:38] bzrtools 1.11 won't emit that for a dev version of 1.12. [22:39] But regarding concurrency, is it as safe? If I checkout the "latest" branch and work on a file, but in the meantime someone else has made changes to a file and pushed it to the branch when I send my changes in, does it matter shich method I use? [22:39] abentley: I somehow have 1.10... [22:39] I wonder how that got there [22:39] Haffi___: If you try to commit in a checkout and it's out of date, it won't let you; you'll have to 'update' first. [22:40] ahh ok. running from a branch. [22:40] * jml pulls to get the happiness [22:40] jml: So bzrtools 1.11 will work with it. [22:40] abentley: yeah, that works. thanks. [22:41] jml: np [22:41] Hm. I think it complained for me after bzr.dev changed... [22:41] I had to pull it before I could multi-pull my plugins. [22:42] jelmer: oh, thanks for saying so [22:42] glad you liked them [22:42] I lost the connection for a bit there... [22:42] * fullermd likes them too. [22:42] fullermd: What version were you on when you did that? [22:43] A rev or two back. Last pulled in Dec sometime. [22:43] r688 probably. [22:44] fullermd: Well, the version number would be 1.11 then, and that was compatible with 1.12dev [22:45] Hm. Well, I can't reproduce it. [22:45] Are the IRC logs kept public somewhere? [22:47] Oh well. I'll worry about it next time it happens, when I've forgotten about it ;) [22:48] jam used to have them somewhere. Dunno if he still does. [22:48] Only thing I said after your last was [22:48] Haffi___: If you try to commit in a checkout and it's out of date, it won't let you; you'll have to 'update' first. [22:49] and update is just merging your working tree with the parent branch? [22:49] Pretty much, yah. [22:49] fullermd, Haffi___: If you look in the topic, you can see: http://irclogs.ubuntu.com/ [22:49] http://irclogs.ubuntu.com/2009/01/14/%23bzr.html [22:49] right, thanks... :) [22:50] Topic? Well, shoot, why hide the info where nobody will ever look? :p [22:50] That only seems to update every-hour or so [22:51] I try to look at documentation and such before asking stupid questions, but sometimes you forget looking at the most obvious places [23:11] * ToyKeeper tries to remember how to explicitly set branches URLs for :parent and :submit [23:11] s/branches/branch/ [23:16] toytoy: --remember [23:16] er, ToyKeeper [23:17] Some commands have a --remember option, but the option name and the branch label don't match and the commands I want to use don't have --remember. [23:18] Parent would be pull, and submit... mmm... merge, I think? [23:18] yep. [23:18] Yeah, I've been confused by that before too. [23:18] why aren't they just called the "pull branch" and the "merge branch". [23:19] I'm still used to the way hg handles branch URLs... it'll use 'default-CMD' for the 'CMD' command, if it exists, or fall back to 'default' otherwise. It's simple and intuitive. [23:20] To set one, edit .hg/hgrc [23:21] Ah, found it. .bzr/branch/branch.conf ; '%s_location = URL' [23:22] I guess it doesn't allow arbitrary labels though, and 'submit_location' isn't the variable for the :submit branch. [23:24] Odd. :parent uses 'parent_location = ../trunk/' but :submit uses 'submit_branch = file:///full/path/to/trunk/' [23:26] as you said, it's not meant for arbitrary aliases. :) [23:26] If I have both 'submit_branch' and 'submit_location' set, bzr dies on commands like diff, even though 'submit_location' doesn't actually seem to get used for anything. [23:27] so don't set submit_location? :) [23:28] Well, yeah. It's just odd that it would be ignored when it's alone (since it's the wrong name), but cause a collision when the correct name is set. [23:28] I resolved the original issue I was having, and now am just looking to see what's fragile or internally inconsistent. [23:32] jelmer: around? [23:32] lifeless, somewhat [23:33] lifeless, what's up? [23:33] pack delta compression - how did you implement that [23:33] its xdelta right? [23:34] I'm not sure it's xdelta completely, but it sure did look like it [23:35] it's apply_delta() in dulwich/pack.py in dulwich fwiw [23:35] how fast is your implementation? does it need C bindings to libxdelta? where is it? [23:35] no, it's implemented in Python [23:35] lp:dulwich [23:35] dulwich/pack.py [23:35] the function is called apply_delta() [23:36] did you write a compressor? [23:36] there's a create_delta() as well, but I didn't write that - Jc2k did [23:36] AIUI xdelta has a turing complete [or nearly] component [23:36] is that used? [23:36] lifeless: i really don't think it's turing complete [23:37] imbw [23:37] but i don't think it can switch based on the content [23:37] written out by the delta [23:37] poolie: I have no idea, haven't read the specs, just going on memorys of jams comments [23:37] i guess it would be turing complete if you ran xdelta repeatedly on its own output [23:37] but that would be weird [23:38] lifeless, I don't think that's used [23:40] jelmer: thanks [23:41] lifeless, but speed is an issue with the current in-python implementation [23:42] I'm looking at ways to improve it at the moment [23:42] jelmer: I'm putting together a compressbench tool [23:42] jelmer: it needs a VersionedFile interfface [23:43] it's ok for small repositories (loudmouth, ~500 revs, takes a few minutes) [23:43] or rather a subset of it [23:43] but for e.g. Samba just figuring out what objects to fetch takes a loooong time [23:43] is it byte orientated? [23:44] lifeless, is what? [23:44] and do you string join? [23:44] the deltas [23:44] lifeless, the git deltas are byte-based, yes [23:44] do they work in bits bytes lines [23:44] bytes [23:44] do you string join in your decompressor? [23:45] string concatenate, yes [23:45] do you know the length of the output when you start decompression? [23:47] lifeless, sorry, the delta-applyer does string concatenate [23:47] the decompressor is a simple zlib decompresser [23:47] and the output length is not known beforehand [23:47] jelmer: well, I meant the delta applier [23:47] which is a form of decompression :P [23:48] lifeless, sure, but it makes the terminology a bit confusing [23:48] well [23:48] as all objects (whether they're deltas or plaintexts) are stored zlib-compressed [23:48] in the packs [23:48] k, well ignore the zlib step for this discussion [23:49] the length is still not known [23:49]