| lifeless | igc: I'm popping up to the doctor | 00:01 |
|---|---|---|
| igc | lifeless: ok | 00:01 |
| lifeless | igc: I'm back on bzr now; if you need me in the next few hours you can SMS me | 00:01 |
| igc | thanks | 00:02 |
| === jfroy|work_ is now known as jfroy|work | ||
| meoblast001 | hi | 01:49 |
| meoblast001 | i'm considering writing a hook for my Bazaar server | 01:49 |
| meoblast001 | i need to know if this will work | 01:50 |
| meoblast001 | i know a guy who is willing to help me out on one of my projects, but i don't know if i can trust him because he specifically said he would replace all tab characters will 4 spaces and commit with that...... is there a way i could make a server hook that swaps all 4-space tabs with tab characters when he pushes? | 01:51 |
| meoblast001 | right now,i really can't trust him | 01:51 |
| meoblast001 | or at least deny his client from pushing if he uses 4-space tabs (that way at least he can't cause damage) | 01:51 |
| fullermd | Well. That would require rewriting all the revs, so he'd have to pull --overwrite afterward... | 01:55 |
| meoblast001 | is there a pre-push hook on the server? | 01:56 |
| fullermd | But if you can't trust him, why the putz would you let him push in the first place? | 01:56 |
| meoblast001 | that would allow me to end the push | 01:56 |
| meoblast001 | fullermd: i have no idea... i don't think i will | 01:56 |
| meoblast001 | i just want to know if i can just incase i ever do give him write access | 01:56 |
| * igc back in a few hours | 02:46 | |
| GungaDin | is there an easy way to check what branch another branch was branch off? | 02:48 |
| lifeless | meoblast001: there is a pre change hook yes | 02:51 |
| lifeless | see bzr help hooks | 02:51 |
| meoblast001 | lifeless: can i use that to completely kill the push? | 02:51 |
| lifeless | that is why I mentioned it | 02:52 |
| meoblast001 | ah, ok :) | 02:53 |
| meoblast001 | lifeless: you're both a Bazaar and Launchpad dev right? | 03:38 |
| lifeless | roughly | 03:40 |
| lifeless | I've written code for both | 03:40 |
| lifeless | not really active on lp codebase at the moment though | 03:40 |
| meoblast001 | the code viewer in LP, that browses code in Bazaar | 03:41 |
| meoblast001 | i'm thinking about scripting up something small like that in PHP for my server, so people can browse my sources | 03:41 |
| meoblast001 | does Bazaar have utilities for getting file sources at certain revisions? | 03:41 |
| lifeless | yes | 03:42 |
| lifeless | bzr cat | 03:42 |
| meoblast001 | ah, ok thanks :) | 03:42 |
| lifeless | bzr xmloutput might have something | 03:42 |
| lifeless | but personally, I'd suggest you just install loggerhead | 03:42 |
| meoblast001 | what does loggerhead do? | 03:42 |
| spm | meoblast001: loggerhead == "the code viewer in LP, that browses code in Bazaar" | 03:44 |
| meoblast001 | ah, is it a Python/Django script? | 03:44 |
| spm | django? not that I'm aware of. python yes. https://edge.launchpad.net/loggerhead/ | 03:46 |
| meoblast001 | ah, ok | 03:47 |
| meoblast001 | spm: does that use bzr cat? | 03:47 |
| meoblast001 | or is it a Bazaar plugin? | 03:47 |
| spm | meoblast001: perhas if we back up a bit and you ask what you're trying to get to? else we're just playing 1001 questions here :-) | 03:48 |
| meoblast001 | well, does Loggerhead use bzr cat, or does it actually consist of a Bazaar plugin to make it more efficient? | 03:49 |
| lifeless | meoblast001: its a bzr plugin | 04:09 |
| meoblast001 | ah, ok | 04:09 |
| lifeless | meoblast001: and standalone WSGI app | 04:09 |
| lifeless | using python-paste for serving | 04:09 |
| lifeless | I think django can speak wsgi too | 04:09 |
| meoblast001 | what advantage does that provide over using a pipe in PHP? | 04:09 |
| lifeless | its already written and feature complete? | 04:14 |
| lifeless | it uses bzr's library, so can keep state in memory, making it ~ 1000 times faster | 04:14 |
| Talidan | hey there, im a little confused about what bazaar is capable of doing | 04:27 |
| Talidan | btu for our project, we're basically looking for SVN with forks | 04:27 |
| Talidan | people can create their own fork of the main repo, and we (administrators) can cherry pick and merge specific changes from remote forks | 04:28 |
| RAOF | Talidan: bzr can do that (among other workflows) | 04:34 |
| RAOF | Talidan: http://wiki.bazaar-vcs.org/Workflows might help you. | 04:35 |
| Talidan | thanks RAOF, i'll check it out | 04:41 |
| eydaimon | I need merge revno 519, 521, and 522. Is there some way I can do it in a single merge? | 05:46 |
| TresEquis | Howdy, all | 06:26 |
| lifeless | hi | 06:26 |
| TresEquis | Any news on the nested-trees blueprint on launchpad? Look like it blocks support for implementing svn:externals in bzr-svn | 06:26 |
| TresEquis | https://blueprints.launchpad.net/bzr/+spec/nested-tree-support | 06:26 |
| TresEquis | Branch hasn't been updated in quite a while | 06:27 |
| lifeless | no news | 06:27 |
| lifeless | its essentially stalled | 06:27 |
| TresEquis | 2 years worth :( | 06:27 |
| lifeless | there are other projects like scmproj and bzr-externals that may interest you | 06:27 |
| TresEquis | I was looking at bzr-externals | 06:28 |
| lifeless | you've been able to do svn-externals like stuff for about 5 years now, using config-manager | 06:28 |
| TresEquis | would be cool if bzr-svn would use one of them to handle the mapping | 06:28 |
| lifeless | true | 06:28 |
| lifeless | the main thing is that noone is scratching the itch in the core | 06:29 |
| TresEquis | Its a blocker for using bzr against "big" SVN projects, which use externals a bunch | 06:30 |
| lifeless | sure | 06:30 |
| lifeless | you know how open source goes though :) | 06:30 |
| TresEquis | So far, the only one I have stumbled over, using bzr 2.1 and bzr-svn 1.0.2 | 06:30 |
| TresEquis | yup | 06:30 |
| sinasalek | Hi | 06:45 |
| lifeless | woo: Running [ 1% 3 test(s) ] Current test: bzrlib.tests.blackbox.test_add.TestAdd.test_add_control_dir(pre-views) | 06:48 |
| sinasalek | I'm about to select bazaar , however there is a feature i pretty much need which it seems that bazaar does not support. | 06:48 |
| sinasalek | Do you the status of partical checkout/branch , i know there is a roadmap but don't know when it will be released | 06:49 |
| lifeless | partial in what sense ? | 06:49 |
| sinasalek | like subversion update --depth | 06:49 |
| lifeless | I don't know what that deos. | 06:50 |
| lifeless | s/deos/does/ | 06:50 |
| sinasalek | When i want to checkout a large project in order to work only on an specific folder. i don't want to download the whole thing | 06:50 |
| sinasalek | Only that folder. | 06:50 |
| sinasalek | does it make sense know? | 06:51 |
| lifeless | there is a feature called 'views' that avoids putting the content for other folders on disk. | 06:51 |
| lifeless | However, bzr still downloads the same backend data for the repository content. | 06:51 |
| sinasalek | i'm aware of that, but i couldn't figure out how to use it with branch sub command | 06:53 |
| sinasalek | there nothing mentioned in documentation or man pages | 06:54 |
| lifeless | probably needs a patch to let you set the view when you branch | 06:55 |
| sinasalek | Yeah, that's the problem. what do suggest me to do? | 06:56 |
| lifeless | see if there is a bug open | 06:57 |
| lifeless | if there isn't, file one | 06:57 |
| lifeless | if you'd like, I can then mentor you on making the code change | 06:57 |
| sinasalek | Than lifeless i appreciate it. So you're saying that it's implemented ? | 07:00 |
| lifeless | no | 07:01 |
| lifeless | I'm saying that it needs to be implemented | 07:01 |
| lifeless | and we need a bug open to track it | 07:01 |
| lifeless | and its likely small, so if you want to do it, we can help you do it. | 07:02 |
| lifeless | spm: http://pqm.bazaar-vcs.org/ - check it out :) - thanks | 07:03 |
| spm | wooo! | 07:04 |
| lifeless | the line 'Running [ 19% 4408 test(s) ] Current test: bzrlib ... | 07:04 |
| lifeless | is the UI benefit here | 07:04 |
| lifeless | failures will include a subunit trace if we've done it right | 07:05 |
| lifeless | I'm going to send a failing merge after this | 07:05 |
| sinasalek | lifeless: I see | 07:06 |
| sinasalek | lifeless: i'll search the issue and come back. tx | 07:06 |
| lifeless | jelmer: ping | 07:30 |
| sinasalek | lifeless: i submitted a new issue.https://bugs.launchpad.net/bzr/+bug/556236 | 07:32 |
| ubottu | Ubuntu bug 556236 in bzr "branch --view feature is missing" [Undecided,New] | 07:32 |
| lifeless | vila: see the shiny shiny pqm progress bar ? | 09:59 |
| vila | lifeless: yup :) | 10:02 |
| === radoe_ is now known as radoe | ||
| * igc dinner | 10:35 | |
| mobby | Hi, just wondering if someone could help me please? I'm getting "Unable to find old fileid for..." errors when using bzr with an SVN repository in work. Any ideas why I would be getting this problem or what the problem means? | 11:11 |
| bialix | can you pastebin full traceback? | 11:14 |
| bialix | have you changed anything on your svn server? | 11:14 |
| bialix | maybe root id f svn server? | 11:14 |
| bialix | maybe root id of svn server? | 11:14 |
| mobby | well the repository recently went from 1.5 to 1.6 format but I was having the same problem before the migration | 11:15 |
| mobby | root id? sorry bit of a newbie to the finer workings of vcs :) | 11:16 |
| mobby | I've put a stack trace on pastebin, here http://pastebin.com/4g9Xz0ez | 11:23 |
| mobby | hopefully I've done that right :) | 11:23 |
| mobby | I changed some of the path names, filenames, etc as like I said it's an svn repo in work | 11:24 |
| mobby | you'll see in the traceback I'm doing an update, but I get the same error doing a checkout (lightweight) of a different path as well (albeit due to a different file). | 11:28 |
| bialix | mobby: it looks like the bug in bzr-svn | 11:36 |
| bialix | our bzr-svn wizard is not here right now | 11:37 |
| bialix | can you file a bug against bzr-svn on LP, please? | 11:37 |
| bialix | mobby: also, can you say how you get the working copy? with `svn co` or some bzr command? | 11:38 |
| mobby | Ok I'll raise a bug. I use "bzr checkout --lightweight http://....." I can't quite remember how I got hold of the one I'm doing the "update" in. I think it was using "bzr checkout ...." (I'll put this info in the bug) | 11:41 |
| mobby | thanks for your help | 11:41 |
| bialix | mobby: you can try to re-create working copy from the scratch in some empty folder | 11:42 |
| bialix | mobby: also there is cache of svn metadata in your bazaar config directory. maybe you need just delete it | 11:43 |
| mobby | oh ok, I'll try deleting that... | 11:43 |
| bialix | though this is just stab in the dark | 11:43 |
| mobby | I'm trying a new checkout and if that fails I'll try deleting the metadata and try again. Fingers crossed as I've been wanting to use bzr for a while now with our repo but keep hitting brick walls, usually due to our svn server which bzr isn't liking. | 11:53 |
| masklinn | small issue with bazaar & merges: a colleague merged a branch in our trunk, but it turned out that he'd incorrectly resolved conflicts/missed some and hadn't tested the merge correctly. Except he still pushed it. So we decided not to uncommit (because it's ugly) and we reverted the merge commit instead (with merge -r{commit-revision}..{revision-before-commit}). | 11:53 |
| masklinn | Broken code gone, but now when I try to rebase the old branch into the reverted trunk, whatever options I provide, it tells me the trunk is a parent of my branch (technically true) and just performs a pull | 11:53 |
| masklinn | is there a way out of that? | 11:53 |
| masklinn | s/into the/onto the/ | 11:54 |
| maxb | Other than hacking the bzr-rewrite source to remove that check, I can't think of one | 11:55 |
| masklinn | dammit | 11:56 |
| masklinn | mmm or maybe I can try a rebase on the revision right before the merge, it should change all revision ids, and then I rebase again to the current tip | 11:56 |
| mobby | bialix: Is that metadata the "subversion.conf" file or are there other cache files? | 12:00 |
| jelmer | masklinn: that revision is already present in the parent branch, that's why it's trying a pull | 12:00 |
| masklinn | jelmer: yeah I understand why it behaves as it does and why you'd usually want that, but that doesn't help me much as I'm specifically in a case where that's not what I want | 12:01 |
| maxb | masklinn: I have commented out this check in the past and things have worked fine | 12:09 |
| masklinn | maxb, ok, I'll try to do it in to steps first, and if that doesn't work I'll do the commenting thing | 12:09 |
| masklinn | s/to/two/ | 12:10 |
| lifeless | masklinn: please make sure there is a bug erport for what you need | 12:13 |
| masklinn | lifeless: are you sure? it's a fairly specific (and I'd hope rare) need | 12:13 |
| masklinn | and I'm not sure whether it'd be a bug in bazaar (bug: impossible to revert a "merge" revision, merged commits are still considered being in the history) or rebase (wishlist: be able to force rebase even when rebased revisions are already in target branch) | 12:14 |
| bialix | mobby: ask jelmer | 12:15 |
| mobby | bialix: ok thanks :) | 12:15 |
| mobby | jelmer: Hi, before you were here I asked the following question. I wonder if you could help me please? - I'm getting "Unable to find old fileid for..." errors when using bzr with an SVN repository in work. Any ideas why I would be getting this problem or what the problem means? | 12:16 |
| bialix | mobby: btw, are you using bzr.exe? from standalone windows installer? | 13:04 |
| mobby | bialix: yeah it's the standalone windows install | 13:12 |
| bialix | mobby: I'm not sure which libsvn version there is bundled. in the past it was 1.5 | 13:13 |
| jelmer | mobby: hi | 13:13 |
| mobby | jelmer: hi | 13:13 |
| bialix | so it's not really possible to work with 1.6 server | 13:13 |
| bialix | maybe it's not true anymore | 13:13 |
| jelmer | mobby: Can you pastebin the error? | 13:13 |
| mobby | http://pastebin.com/4g9Xz0ez | 13:13 |
| mobby | bialix: from the .bzr.log the svn version is 1.6.6 in bzr-svn. (I think) | 13:15 |
| jelmer | mobby: please file a bug, this is almost certainly a bzr-svn issue | 13:15 |
| bialix | mobby: ok, thx for the info | 13:15 |
| mobby | jelmer, bialix: ok will do. I've cleared the cache and I'm doing a new checkout, so far it is going on longer than before so the fix for the bug might be to clear the cache. I'll let you know how it goes. | 13:16 |
| mobby | s/fix/workaround/ | 13:16 |
| jelmer | I don't think clearing the cache will help, unless you've been changing existing revisions in your repository | 13:18 |
| mobby | jelmer: Not sure, I know our repo was upgraded from 1.5 format to 1.6 recently but I *think* I was having the same problem before that change. | 13:24 |
| lifeless | masklinn: a rebase bug | 13:25 |
| lifeless | there are bugs already for cherrypick merge | 13:25 |
| mobby | jelmer: hmm, after clearing the cache and doing a clean checkout using bzr I got a different error - bzr: ERROR: subvertpy.SubversionException: ("REPORT of '/PATHXXX/!svn/bc/601278': 200 OK (http://XXX)", 175002 ) | 13:26 |
| mobby | jelmer: I'll raise the other bug now anyway | 13:26 |
| mobby | jelmer: Bug raised here - https://bugs.launchpad.net/bzr-svn/+bug/556451. Hopefully it has the information you require. | 13:31 |
| ubottu | Ubuntu bug 556451 in bzr-svn "Unable to find old fileid error on checkout/update" [Undecided,New] | 13:31 |
| jelmer | mobby: thanks | 13:33 |
| mobby | jelmer: no problem :) | 13:35 |
| Lo-lan-do | Hi all | 13:43 |
| jelmer | hi Lo-lan-do | 13:44 |
| Lo-lan-do | jelmer: Question about bzr-svn… apparently branches stored in /branches/dir/subdir in the SVN repo don't get recognised by "bzr branches", is that known? | 13:45 |
| Lo-lan-do | I'd like to tell FusionForge hackers to feel free to host their branches in /branches/people/$login/$feature | 13:45 |
| Lo-lan-do | (Or even without the /branches component, ie straight in /people/$login/$feature) | 13:46 |
| Lo-lan-do | Am I likely to run into problems? | 13:46 |
| jelmer | Lo-lan-do: where /branches is inside of a Subversion repository? | 13:47 |
| Lo-lan-do | Yes | 13:47 |
| jelmer | Lo-lan-do: You won't run into problems trying to clone those branches later, but they e.g. won't be imported as separate branches by "bzr svn-import" | 13:48 |
| jelmer | Lo-lan-do: This is all because Subversion doesn't really have a notion of what a branch is | 13:49 |
| Lo-lan-do | I see. Yes, I know of that limitation, but I guess I can live with that. | 13:49 |
| jam | morning all | 14:02 |
| jam | So vila, about history-db, you mentioned there were bits you didn't understand, care to elaborate? | 14:03 |
| vila | jam: So, about Caching 'dotted_revnos' and merge_sort, first, what are you caching exactly for a given revision ? | 14:03 |
| vila | the same revision (in the worst case) can have a different revno in each branch | 14:04 |
| jam | vila: so yes, "worst case" the cache would be N revs * M branches, where M could get close to N | 14:05 |
| jam | however, I posted some results for both mysql and bzr | 14:05 |
| vila | yes, | 14:05 |
| jam | and importing the whole history, with each rev as a different "branch" | 14:05 |
| vila | that's the part I don't get | 14:05 |
| jam | take the history of bzr.dev | 14:06 |
| jam | walk all revisions | 14:06 |
| vila | you mean a branch the branch is the tip ? Something else ? | 14:06 |
| jam | consider this revision as the tip | 14:06 |
| jam | import and cache | 14:06 |
| vila | ok | 14:06 |
| jam | I optimize it slightly | 14:06 |
| jam | by walking backwards through history | 14:06 |
| jam | so I'll often get shared mainlines | 14:06 |
| vila | that doesn't give me the revno when this branch is merged though | 14:06 |
| jam | and only import 1 of a series | 14:06 |
| jam | vila: so #1, import the merge_sorted graph | 14:07 |
| jam | splitting it by mainline revno | 14:07 |
| lelit | hi all, a tailor user asked me about this problem: http://codepad.org/ru75we4F that happens on a big CVS repo, both with bzr 2.0.1 and with 2.1.1. Anybody knows if there is some kind of "finalization" I'm missing, when dealing with open_workingtree() objects? | 14:07 |
| jam | which *does* tell you what revisions were merged into a given mainline rev | 14:07 |
| jam | it doesn't tell you the info for that merged revision as the tip, though | 14:08 |
| jam | that comes later. | 14:08 |
| jam | vila: does that help? | 14:08 |
| vila | Right, so that's an intermediate result, | 14:09 |
| vila | and you use that to speed merge_sort by importing the "bottom" of the graph, right ? | 14:09 |
| jam | lelit: looking at "stat_and_sha1" the file_obj = ... is shortly followed by a "try/finally:file_obj.close()" | 14:10 |
| jam | So I don't think it would be leaking *those* file handles | 14:10 |
| jam | but it may be leaking elsewhere? | 14:10 |
| jam | vila: so... I *think* I haven't finished implementing "speed merge_sort" yet | 14:11 |
| jam | That's part of what I wanted to discuss, to see if my thoughts there made sense. | 14:11 |
| jam | *Right now* the current code is: | 14:11 |
| jam | for a given branch (bzr.dev): KG.merge_sort(), import everything | 14:12 |
| lelit | jam: the tailor side is doing this: http://progetti.arstecnica.it/tailor/browser/vcpx/repository/bzr.py#L365 | 14:12 |
| vila | jam: also, in your mail for mysql-6.0 --expand-all, you say: 32m import time | 14:12 |
| jam | with --expand-all | 14:12 |
| vila | 32 minutes ? | 14:12 |
| jam | I then walk backwards from tip | 14:12 |
| bialix | hi jam, vila | 14:12 |
| jam | morning bialix | 14:12 |
| vila | hey bialix | 14:12 |
| bialix | morning jam, there is afternoon :-P | 14:12 |
| jam | and if a given revision isn't already imported as a 'tip' (as identiified by tip_revision = merge_revision), then I do another KG.merge_sort(new_tip) and cache the result | 14:13 |
| jam | Without --expand-all, mysql imports in about 11s | 14:13 |
| jam | With --expand-all, it finds ~17k unique branches, and takes 32 minutes, yes | 14:13 |
| bialix | jam, after reading your cache db mail, I've suddenly realized we need for qlog only dotted revno of the tip of merged branch | 14:13 |
| bialix | I'm not sure what is KnownGraph stuff you and Gary merged recently | 14:13 |
| jam | but 17k * 11s >> 32 minutes | 14:14 |
| jam | bialix: not really related to what I'm doing now, I suppose tangentially | 14:14 |
| vila | haaa, imports is reading all the graph *today* | 14:14 |
| jam | vila: so you have to read the whole graph 1 time, but after that we can do better | 14:14 |
| bialix | jam: do we have any way to say "this revision is mainline", or this is also should be cached? | 14:15 |
| bialix | sorry to cross you and vila | 14:15 |
| jam | bialix: its ok. for an arbitrary revision? | 14:15 |
| bialix | jam: yes | 14:15 |
| bialix | jam: when you traverse merged branch you need to know where to stop, when you come back to mainline. is it correct? | 14:16 |
| jam | You can call Branch.revision_id_to_revno | 14:16 |
| jam | and if it raises an exception, the revision isn't on the mainline | 14:16 |
| vila | jam: I have trouble with the numbers you mention as I can't easily say which relates to our existing code and which depend on your wip | 14:16 |
| jam | bialix: there is quite a bit more too it, as some of the intermediate 'merged' revisions may have been merged earlier | 14:17 |
| jam | http://paste.ubuntu.com/410035/ | 14:17 |
| jam | bialix: with time going up | 14:17 |
| jam | you need to know that C is merged into E when you go to expand F | 14:17 |
| jam | because you don't display it | 14:18 |
| bialix | jam: I see | 14:18 |
| jam | http://paste.ubuntu.com/410036/ | 14:18 |
| jam | merge_sort is how we determine what revisions go where in the graph | 14:18 |
| jam | and then we put dotted_revnos from that fairly easily | 14:19 |
| bialix | actually qlog expand entire merged branch, which sometimes is not the best thing. but I see what you mean | 14:19 |
| jam | bialix: sure, but even then you need to know that C was merged | 14:19 |
| jam | somewhere | 14:19 |
| jam | and to determine that | 14:19 |
| jam | you currently have to walk backwards from all mainline revs | 14:19 |
| jam | in *case* it was merged there | 14:19 |
| jam | vila: so, the *counts* should be correct | 14:19 |
| vila | jam: I think loading the whole graph for a mysql branch < 2s, not 11s | 14:19 |
| bialix | jam: ok | 14:20 |
| jam | vila: importing the whole graph into the database is 11s | 14:20 |
| jam | "bzr walk-ancestry --method=bzr" was 2s | 14:21 |
| jam | --method=bzr-kg was 1.4s | 14:21 |
| jam | --method=db-dotted was 0.087s | 14:22 |
| Lo-lan-do | jelmer: Switching to /branches/$login_$branchname, I seem to run into "Operation denied because it would change the mainline history." when committing a merge, which I don't understand since I'm doing no such thing. | 14:22 |
| jam | vila: so the time to get data *out* of the db should be accurate, and the counts of objects *in* the db should be accurate for future reference | 14:22 |
| jam | (subject to tuning, etc :) | 14:22 |
| jam | the time to put data *in* the database is still being worked on | 14:22 |
| vila | ok, clearer, loading the db is not the most relevant, it should occur only one and then incrementally | 14:23 |
| jam | vila: so I think loading the db taking 11s the first time is probably going to stay | 14:23 |
| jelmer | Lo-lan-do: you're not pushing merges? | 14:23 |
| vila | hmm, may be not, well it depends, your focus is loggerhead only/first/dunno ? | 14:23 |
| jam | Loading an arbitrary real-world branch (today) requires grabbing get_known_graph().merge_sort() | 14:24 |
| jam | which has a similar ~1s overhead | 14:24 |
| Lo-lan-do | jelmer: I'm trying to commit a merge in a branch bound to SVN, so I probably am. | 14:24 |
| jam | but then loading the unmerged data into the db is quite fast | 14:24 |
| jam | --expand-all is sort of the ultimate "bring in as many branches as I can possibly find" | 14:24 |
| jam | meant to stress-test the system | 14:24 |
| jam | though you may want to run that in the future | 14:24 |
| jam | In the import code *today* I believe the bottleneck is calling KG.merge_sort() for each one | 14:25 |
| Lo-lan-do | jelmer: svn cp $svnrepo/trunk $svnrepo/branches/lolando_test, then a commit in a bzr branch bound to svnrepo/branches/lolando_test, then a merge of that into a checkout of $svnrepo/trunk, then commit. | 14:25 |
| jam | Once I finish what I'm looking at now | 14:25 |
| jam | both should be possible as an 'incremental update', and then you should be sub-second for all imports after the fisrt one | 14:25 |
| jam | (note that right now you are at around 44ms for --expand-all per branch, and I think 40ms of that is merge_sort) | 14:26 |
| jam | mysql is around 100ms per expanded-branch | 14:26 |
| jam | vila: do those numbers make sense to you? | 14:26 |
| vila | jam: that sounds sensible, my first interpretation is that you're demonstrating that the IOs are killing us, so batching them is good :) | 14:27 |
| vila | jam: the db size is still a problem though, may be not for loggerhead... well, at least lp should make it possible to have one by project | 14:28 |
| jam | vila: well, I was pretty surprised to see that "walk-ancestry" using the database was still 300ms or so, until you start walking 100 mainlines at a time, and it suddenly drops by an order of magnintude | 14:29 |
| vila | jam: your dn can be shared across all branches of project right ? | 14:29 |
| jam | vila: in theory it can be shared across all branches of all projects | 14:29 |
| jam | though like shared repos, you don't benefit as much | 14:29 |
| vila | jam: the numbers for walk_ancestry are for iterating the whole ancestry ? | 14:31 |
| jam | vila: yes | 14:31 |
| jam | 80ms to get the *entire* ancestry | 14:31 |
| jam | 30k revs | 14:31 |
| jam | or 68k revs for mysql | 14:32 |
| jam | though for the db numbers, that isn't always in 'revision_ids' | 14:32 |
| jam | you would have to probe one more table to get back to raw revision_ids | 14:32 |
| Lo-lan-do | jelmer: http://whiteboard.debian.net/d6d21f.wb has the log | 14:32 |
| jam | vila: so I'd like to discuss some of the algorithms for generating merge_sort, and see if they make sense to you | 14:40 |
| === kfogel is now known as emacs | ||
| === emacs is now known as kfogel | ||
| vila | jam: sure | 14:43 |
| jam | so I have some updated docs, and a start of an implementation in lp:~jameinel/+junk/bzr-history-db | 14:45 |
| jam | (currently on rev 45) | 14:45 |
| jam | there are a few ideas in there, I didn't really get it polished | 14:45 |
| jam | but the general idea is to figure out what revisions need to be adedd | 14:46 |
| jam | added | 14:46 |
| SamB_XP | aeddd | 14:46 |
| jam | (to the dotted_revno cache) | 14:46 |
| jam | and I thought of some interesting uses of gdfo and parent => child mappings | 14:46 |
| jam | the idea is that if all known children of a revision can be accounted for, then you can know that a rev was/wasn't merged | 14:48 |
| jam | rather than having to walk in pure gdfo order | 14:48 |
| vila | "accounted for" ? | 14:49 |
| vila | oh, and how do you handle ghosts ? | 14:49 |
| jam | http://paste.ubuntu.com/410050/ | 14:49 |
| jam | time going upwards for you | 14:49 |
| jam | sorry, missed a step, just a sec | 14:50 |
| jam | well, maybe I can work with that | 14:51 |
| jam | the idea is that X : B could be very long | 14:51 |
| jam | which would make E have a high gdfo | 14:51 |
| jam | however, thinking about it, it would still only be proportional to the diffs in the graph | 14:51 |
| jam | so that doesn't quite fit my case yet | 14:51 |
| jam | vila: at the moment ghosts are just treated as roots | 14:53 |
| jam | I plan on accounting for them by putting them in a 'ghosts' table | 14:53 |
| jam | since they are rare, I don't want to add a column on the 'revision' table for all the ones that aren't ghosts | 14:53 |
| jam | so one possiibility: http://paste.ubuntu.com/410052/ | 14:54 |
| jam | In this case, B is from a very old revision, so X has a few revs to it, but can have a much lower gdfo than C | 14:54 |
| jam | the idea is that the only known child of X is D | 14:55 |
| jam | so you know it wasn't merged before C | 14:55 |
| jam | and the only known child of parent_of(X) is X | 14:55 |
| jam | so again, you know it wasn't merged before | 14:55 |
| jam | which continues until you get to B | 14:55 |
| jam | at which point, you have to see if B was merged before, | 14:55 |
| jam | so you start walking the mainline | 14:55 |
| jam | however, I do wonder how the design works with: http://paste.ubuntu.com/410056/ | 14:56 |
| jam | (no merge) | 14:57 |
| jam | It will need to walk all the way back to A, and will load the dotted-revno info inbetween | 14:57 |
| jam | may be unavoidable, but I think with known_children you could instead just walk the mainline revs, and not their merged revs | 14:58 |
| vila | your db provide the children ? Or you build that as you walk the graph ? | 14:59 |
| jam | vila: the parent table intrinsically provides children | 15:00 |
| jam | SELECT child FROM parent WHERE parent =? | 15:00 |
| jam | vs | 15:00 |
| jam | SELECT parent FROM parent WHERE child = ? | 15:01 |
| jam | I believe I have 2 indexes on the table | 15:01 |
| jelmer | Lo-lan-do: it wants to copy from one of the merged branches I suspect | 15:01 |
| jelmer | Lo-lan-do: and keep that as mainline | 15:01 |
| jelmer | Lo-lan-do: please file a bug | 15:01 |
| vila | jam: well, then you have even more shortcuts than with gdfo :) | 15:02 |
| Lo-lan-do | jelmer: I've tried to do a svn commit in trunk just now, and now I can't bzr update the bound branch :-/ | 15:04 |
| Lo-lan-do | AssertionError: Tried registering <CachingRevisionMetadata for revision 9363, path trunk in repository '9d84d37e-dcb1-4aad-b103-6f3d92f53bf6'> as parent while None already was parent for <CachingRevisionMetadata for revision 9368, path trunk in repository '9d84d37e-dcb1-4aad-b103-6f3d92f53bf6'> | 15:04 |
| jam | vila: right | 15:04 |
| vila | jam: you're still loading the whole graph anyway right ? (by whole I mean the revisions reachable from tip) | 15:13 |
| jam | vila: the goal is to not do so | 15:16 |
| jam | I believe I can compute merge_sort by only loading "enough" revisions | 15:16 |
| jam | which is, the last merge sorted parent | 15:16 |
| jam | of all newly merged revisions | 15:16 |
| jam | and possibly a bit more context to get the numbers right | 15:16 |
| jam | I still haven't sorted all that out, but I think I have a feel for it | 15:16 |
| vila | jam: the thing I like with your approach is that it makes it easier to try various new tricks, some of them could be backported with a bit of luck | 15:24 |
| vila | jam: can we query the bzr indices from a starting key for batch of keys ? | 15:24 |
| jam | vila: not trivially | 15:27 |
| jam | though that is what _known_graph_ancestry tries to do | 15:27 |
| IslandUsurper | sorry for the interruption, but did cherrypicking ever cause a pending merge? I was surprised when it didn't just now | 15:32 |
| maxb | cherrypicking never does | 15:32 |
| maxb | It would be illogical for it to do so | 15:33 |
| jam | IslandUsurper: if you give a "cherrypick" range that actually includes a full ancestry, then it will record a pending merge | 15:33 |
| jam | if it is 'accidentally' not actually a cherrypick | 15:33 |
| IslandUsurper | yeah, that makes sense | 15:33 |
| jam | vila: I think I've found a couple holes in my new design | 15:39 |
| jam | I pushed up a test case in rev 46 that might show it | 15:39 |
| jam | specifically, when computing the second value in the dotted revno scheme, you pretty much *have* to load all children of the first revno | 15:39 |
| jam | because there can be shortcuts that bump the 'branch' number, that are hidden by more recent merges | 15:40 |
| jam | :( | 15:40 |
| jam | vila: what were you saying about changing how we number again ? :) | 15:40 |
| vila | jam: hehe, don't resign too fast :) | 15:42 |
| vila | jam: but yeah, since there is not much added value in our actual scheme, changing for one that would give the merged-in mainline revno, can't be a loss | 15:43 |
| jam | so one option is still "load all the ancestry between now and the parent you want to number from" | 15:43 |
| vila | jam: but if merge_sort is only 40ms for a complete graph, the problem to address is really to load the graph (or the needed part) faster (and preferably with an acceptable space cost ;) no ? | 15:46 |
| jam | vila: 40ms * 4k is minutes to expand all of bzr.dev. With incremental merge numbering we should be able to cut that by at least an order of magnitude | 15:47 |
| jam | the bigger issue | 15:47 |
| jam | is that I'd like to have a cache that gets updated with *commit* | 15:47 |
| vila | 4k ? | 15:47 |
| LeoNerd | Tiny bugreport: bzr should ignore SIGWINCH... I got a failure of "bzr pull" with "Interrupted system call" from resizing the window | 15:47 |
| jam | (4k branches in the history of bzr) | 15:47 |
| jam | so the 1-2s to load the ancestry of bzr.dev plays a much bigger deal there | 15:47 |
| jam | which is why I wanted an incremental algo | 15:48 |
| vila | I'm talking about a *single* merge_sort, isn't it 40ms *without* the loading part ? | 15:48 |
| jam | right | 15:48 |
| vila | right, gdfo is the easiest trick to manage at commit time :-) | 15:48 |
| vila | gdfo = mac(gdfo) + 1 :) | 15:48 |
| vila | s/mac/max/ | 15:48 |
| === deryck is now known as deryck[lunch] | ||
| vila | but the actual numbering scheme is the problem since it requires loading the whole graph | 15:49 |
| vila | even if you manage to "load all the ancestry between now and the parent you want to number from", you still have the case where some daggy-fixed from a merged branch and merge again | 15:50 |
| vila | s/some/someone/ | 15:50 |
| jam | vila: true, though even daggy fixes don't go back to revno 1 | 15:50 |
| vila | jam: indeed ! | 15:50 |
| jam | the painful one in bzr's history is aaron's *long* lived integration branch | 15:50 |
| jam | however, I do think those cases are the exception rather than the rule | 15:51 |
| jam | and having an incremental algo will be good | 15:51 |
| jam | just that i have to be aware of edge cases so I don't get them *wrong* | 15:51 |
| jam | and the algo can be fast as long as it detects when it needs to fall back | 15:53 |
| jam | so far, the 'detecting' part still looks expensive, which I'm unhappy about | 15:53 |
| vila | jam: I think that even branches that are merged multiple times could be addressed too with a different revno scheme, they'll get dotted revnos with different first parts | 15:53 |
| vila | jam: and again, using gdfo will help ensuring we number each revision based on its first landing (but gdfo may not be enough here, we may need a bit more help) | 15:55 |
| vila | jam: so, concerning roots, you haven't addressed the filling part yet right ? | 15:56 |
| jam | vila: ghosts/roots, no. But wipe and restart is a valid option. | 15:57 |
| jam | The parent graph is still correct in the db | 15:57 |
| jam | so you don't have to go back and touch branches again | 15:57 |
| jam | vila: note that gary told me earlier that qlog makes use of the fact that a "branch" maintains its second number | 15:58 |
| jam | well, first 2 numbers | 15:58 |
| vila | jam: yeah, I think it's not such a good idea, but a good shortcut because we don't have cheaper ancestry checks | 15:58 |
| vila | jam: and I would be delighted if he could magically find back the true branches in mysql mazes :) | 16:00 |
| vila | jam: I just noticed: "If a revision X is in the ancestry of tip T, then the dotted revno for X will be the same for all descendents of T." | 16:04 |
| vila | this is true *only* if T was a tip and is *still* on the mainline | 16:04 |
| vila | jam: have you tried reusing your db on different mysql branches ? | 16:05 |
| jam | vila: well I did --expand-all, which should be approx the same as "different branches" | 16:21 |
| jam | vila: and for the "same for all descendents", sure, but that is how I'm caching | 16:22 |
| vila | jam: ok, just wanted to make sure, there is really no mainline shared between mysql branches (apart from the initial import maybe) | 16:23 |
| jam | vila: see my results | 16:26 |
| jam | there is an average of only 68 rev divergence | 16:26 |
| jam | and the rest is 'shared mainline' | 16:26 |
| jam | vs bzr which has an average of 170 rev divergence | 16:26 |
| jam | put another way, even though the ancestry of mysql-6.0 is 2x that of bzr, the final size of the db was == bzr after filling out the dotted revno table | 16:26 |
| vila | jam: that's where I'm really surprised :) | 16:27 |
| jam | vila: yep, I was too | 16:27 |
| jam | I haven't probed enough to figure out why | 16:27 |
| vila | jam: as in: a bit too much to trust these numbers wit... yeah :) | 16:28 |
| vila | jam: what commands should I run in a given branch to get the same stats ? | 16:31 |
| jam | vila: generally 'bzr create-history-db --db=filename -d branch --expand-all' | 16:33 |
| jam | It *might* be broken right now, let me check | 16:34 |
| jam | ah, it should be fine if you don't use --incremental | 16:34 |
| jam | with --expand-all it should spit out some stats about how many revs were expanded, etc. And how many total entries you have | 16:35 |
| jam | which is how I figured the numbers | 16:35 |
| jam | you can also use "sqlite3 filename" and then do custom queries in there | 16:35 |
| === mobby is now known as mobby_ | ||
| vila | jam: random thought: at *merge* time it's cheap to record how "deep" the merged branch is (for external branches) or how many new revisions are merged from the other mainline | 16:41 |
| === mobby_ is now known as mobby | ||
| vila | jam: some hints may help devising a new incremental revno scheme | 16:42 |
| jam | vila: I'm not really sure what you are proposing. | 16:42 |
| jam | when merging, all branches are 1 deep | 16:42 |
| jam | all *merged* branches are 1 deep | 16:42 |
| jam | 'how many new revisions' is probably not all that easy | 16:43 |
| jam | graph-difference vs just finding a common ancestor | 16:43 |
| vila | jam: think merge-into and the consequences on the revnos | 16:43 |
| vila | jam: sure, but you have the relevant graph already loaded anyway | 16:43 |
| jam | at least most, probably | 16:43 |
| vila | jam: so we are in the "40ms for merge_sort" area, hence cheap | 16:44 |
| === deryck[lunch] is now known as deryck | ||
| NfNitLoop | Coworker came to bzr from git. He wanted to get rid of the last 3 revisions, so he did a 'bzr update -r -4'. Then did some work, and was surprised when he couldn't commit. | 16:55 |
| NfNitLoop | we fixed it with shelve and 3x 'bzr uncommit', but... | 16:55 |
| NfNitLoop | is there a better way to do that? | 16:55 |
| NfNitLoop | bzr pull? | 16:56 |
| james_w | yeah, that works | 16:56 |
| james_w | or bzr uncommit -r | 16:56 |
| NfNitLoop | Ok. What's the purpose of being able to do an update to a past revision, then? | 16:57 |
| NfNitLoop | seems weird if you can't commit to it. | 16:57 |
| zooko | Folks: there is a student applying for Google Summer of Code to work on the Tahoe-LAFS project and to integrate Tahoe-LAFS with a DVCS. | 16:59 |
| zooko | bzr is a candidate. | 16:59 |
| zooko | Would any bzr hackers be interested in mentoring or at least consulting? | 16:59 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| jelmer | NfNitLoop: you can if the branch is not bound I think | 17:05 |
| jelmer | zooko: Yeah, np | 17:05 |
| NfNitLoop | it was not a bound branch. | 17:06 |
| NfNitLoop | 'bzr up -r -4' seemed to update the working copy and even the current revision, but when he tried to commit it said that he couldn't because the working copy was out of date. | 17:07 |
| NfNitLoop | even though it's a standalone branch. (Well, within a shared repo.) | 17:07 |
| === salgado is now known as salgado-lunch | ||
| === beuno is now known as beuno-lunch | ||
| eydaimon | I need merge revno 519, 521, and 522. Is there some way I can do it in a single merge? | 17:30 |
| === salgado-lunch is now known as salgado | ||
| vila | What is the english expression about a round thing into a squared other thing ? | 18:24 |
| LeoNerd | Round peg, square hole? | 18:25 |
| LeoNerd | (or vice versa, really.. I expect either way works) | 18:25 |
| vila | yes ! But what is the sentence used ? | 18:25 |
| vila | trying to fit a round peg in a square hole ? | 18:26 |
| LeoNerd | Oh. something to the effect of "trying to fit.." yes. that | 18:26 |
| === beuno-lunch is now known as beuno | ||
| === IslandUsurperAFK is now known as IslandUsurper | ||
| jam | vila: are you still around? | 18:45 |
| jam | just to mention "square peg in a round hole" is the more common phrasing | 18:47 |
| jam | http://www.google.com/search?q=round+peg+square+hole | 18:47 |
| jam | (notice that I searched for round peg square hole and got the reverse) | 18:47 |
| jam | anyway, I had another idea about the partial graph, in case vila comes back around. | 18:47 |
| vila | jam: still there for a few minutes | 18:48 |
| jam | http://paste.ubuntu.com/410151/ | 18:48 |
| jam | vila: basic observation | 18:48 |
| vila | jam: and another random idea: you can add gdfo into your db right ? | 18:48 |
| jam | vila: gdfo is already in the db | 18:48 |
| jam | and I'm using it now | 18:48 |
| jam | basic observation: you don't need to load back to revno 0 | 18:49 |
| jam | you need to load back to revno x.y.? that you are based on | 18:49 |
| jam | That can potentially be a big difference | 18:49 |
| jam | when finding a new branch number based on 1.5000.1, you don't need the data for anything 1.<5000 (maybe) | 18:49 |
| vila | jam: you got it | 18:50 |
| vila | jam: and then, if you had a bit more info in the ancestry graph you may even get there without a cache | 18:51 |
| vila | jam: like: next merge point in my ancestry is at distance x | 18:51 |
| vila | jam: which should help addressing the problem of the last part of the revno (otherwise you have to walk it until its origin to start at 1) (for various definitions of origin) | 18:52 |
| vila | jam: but I'm still not sold about numbering in one way or the other (M: 5.1.1, L: 5.2.1, K: 5.1.2, etc) or (M: 5.1.2, K: 5.1.1) | 18:57 |
| balor | Gah, I can never remember what should be merged! Do I merge a THIS and OTHER on to BASE? | 19:03 |
| jam | vila: sure, I can see changing the numbering, but finding that while I need more-than-minimal but I need less-than-back to 1 makes it worth moving forward | 19:05 |
| jam | I just wanted to make sure someone else agreed with my logic | 19:05 |
| IslandUsurper | balor, THIS is your working tree, OTHER came from the merged branch, and BASE is what they have in common. So for each chunk, ask which change is more important, the one you had or the one you're getting. | 19:10 |
| IslandUsurper | the tricky ones have some of each | 19:11 |
| balor | So merge THIS and OTHER into each other | 19:12 |
| IslandUsurper | right | 19:12 |
| IslandUsurper | they're displayed together in the original filename | 19:12 |
| balor | So what's the point of BASE? What information does it give me? | 19:13 |
| balor | As I get common chunks in the same colour in Meld | 19:13 |
| IslandUsurper | if you diff BASE and either THIS or OTHER, you can see exactly what they changed | 19:14 |
| balor | ah | 19:14 |
| balor | thanks | 19:14 |
| vila | jam: sure, sure, I'm very happy you work on *that* (reducing the cases requiring loading all the history) | 20:16 |
| lifeless | jam: your logic ? | 20:24 |
| jam | full discussion is in the text file in my lp:~jameinel/+junk/history-db branch. | 20:29 |
| jam | basically, | 20:30 |
| jam | for simple children, you just need to know there isn't another child | 20:30 |
| jam | and then you can do X.Y.Z+1 | 20:30 |
| jam | for a new sub-branch | 20:31 |
| jam | you need to know if there is an X.Y+1 | 20:31 |
| jam | to know that, you need to check all descendants merged into trunk from X.Y.1 | 20:31 |
| jam | sorry | 20:31 |
| jam | all merges into trunk since X.Y.1 was merged | 20:31 |
| jam | however, you don't care about when X.Y-1.* was merged | 20:32 |
| jam | lifeless: ^^ | 20:32 |
| jam | maybe put another way | 20:33 |
| jam | if you are walking backwards, you need to load X.Y.Z if it is a parent of yours, so that you can do any of X.Y+1.Z, or X.Y.Z+1 | 20:33 |
| jam | to determine which | 20:33 |
| jam | you need to load the children of X.Y.Z | 20:33 |
| jam | if there are no other children, you can do X.Y.Z+1 and do no further loading | 20:33 |
| jam | if there is one | 20:33 |
| jam | then you need to load from X.Y.1 to determine any X.Y+1.1 that exist | 20:34 |
| jam | (+N if you prefer) | 20:34 |
| jam | The key is that you don't need to load from X | 20:34 |
| jam | since anything landed before X.Y.1 was landed, will have have a second number < Y. | 20:35 |
| lifeless | vila: can I purchase a review ? | 20:48 |
| lifeless | jam: bzr+ssh://bazaar.launchpad.net/~jameinel/%2Bjunk/history-db/ - not a branch | 20:48 |
| jam | lifeless: sorry bzr-history-db | 20:49 |
| jam | lp:~jameinel/+junk/bzr-history-db | 20:49 |
| lifeless | so, 'only the right hand side *children* of X can influence revision numbers X.*.*' ? | 20:50 |
| jam | lifeless: I'm pretty sure only lh children | 20:54 |
| jam | sorry | 20:54 |
| jam | you were saying X | 20:54 |
| jam | children of X with X in their LH history will be numbered based on it, yes | 20:55 |
| jam | the way the data is stored in the dotted_revno table today does affect things | 20:57 |
| jam | you need to know that a child of X is in the ancestry of the current branch | 20:57 |
| jam | just being a child doesn't affect X.*.* for *this* branch | 20:57 |
| lifeless | sorry, I should have said 'rh parents of X' | 20:57 |
| jam | lifeless: rh parents of X have no affect | 20:58 |
| jam | X is the ancestor of X.*.* | 20:58 |
| jam | it is, specifically, a LH ancestor | 20:59 |
| === ubott2 is now known as ubottu | ||
| lifeless | jam: https://code.edge.launchpad.net/~lifeless/bzr/commit/+merge/22848 | 21:21 |
| lifeless | jam: vila: https://bugs.edge.launchpad.net/bzr/+bug/530265 | 21:22 |
| lifeless | do you guys have a preference between | 21:22 |
| lifeless | *) a line to delete | 21:22 |
| ubottu | Launchpad bug 530265 in bzr "Not modifying a suggested commit message commits anyway" [Medium,Confirmed] | 21:22 |
| lifeless | *) a y/n prompt if the message is the unaltered template | 21:23 |
| jam | lifeless: If we are being interactive enough to pop up an editor | 21:23 |
| jam | I think it is ok to prompt for a "did you really want to commit an empty message" ? | 21:23 |
| jam | lifeless: the mutter() seems fine | 21:24 |
| jam | I'm trying to understand the revprops chacheng | 21:24 |
| jam | change | 21:24 |
| lifeless | oh | 21:24 |
| lifeless | I had it in my commit branch; it just reduces some cruft | 21:24 |
| jam | you are removing it from _commit, but adding it to the constructor? | 21:24 |
| lifeless | shorter parameter list | 21:24 |
| lifeless | its already in the constructor | 21:24 |
| lifeless | its an internal handoff within the object | 21:25 |
| lifeless | so just changing where it becomes an attribute, to spend less time passing it around | 21:25 |
| jam | it would seem reasonable to do that to all the other ones as well then... | 21:25 |
| jam | so... not a problem, but incomplete one way or another | 21:26 |
| lifeless | yup | 21:26 |
| lifeless | If I end up doing much more to commit I'll probably do the rest too | 21:26 |
| lifeless | its a bit ugly as it stands | 21:26 |
| jam | anyway :approve | 21:27 |
| lifeless | thanks | 21:28 |
| lifeless | re prompt/message | 21:28 |
| lifeless | I guess I feel that its cleaner to only interrupt the user once | 21:28 |
| lifeless | GUI's can check in the dialog | 21:29 |
| lifeless | hmmm | 21:29 |
| lifeless | jam: whats the current open bzr version on trunk ? | 21:32 |
| lifeless | assign to milestone is showing about 15 things, rather than 3 | 21:32 |
| lifeless | <- confused bear of small brain | 21:32 |
| jam | lifeless: either 2.2.0 or 2.2.0b2 I believe | 21:33 |
| lifeless | so commits in trunk will still be 2.2 ? | 21:33 |
| jam | well, 2.2b2 | 21:33 |
| jam | yes | 21:33 |
| lifeless | kk | 21:33 |
| lifeless | can we deactivate some of the others, do you think ? | 21:34 |
| jam | From looking at it, they are all stuff in the future | 21:47 |
| jam | not sure that we would disable them, but I suppose we could for now | 21:47 |
| jam | unlikely to target them explicitly, but it can be nice to know when they are expected | 21:47 |
| jam | (so not great in the bug UI, nice to have elsewhere) | 21:47 |
| === salgado is now known as salgado-afk | ||
| Talidan | Hi there, i was just reading http://wiki.bazaar-vcs.org/CherryPick | 22:22 |
| Talidan | Cherrypicking is vital to our project, the idea is that other users can mirror our branch, make changes | 22:22 |
| Talidan | and we can merge them if they're decent | 22:23 |
| Talidan | i was just wondering what's meant by "Bazaar does not track cherrypicked revisions, although this feature is firmly on the wish list. " | 22:23 |
| Talidan | ideally (currently im testing on launchpad) the person we merge from is credited with the change | 22:23 |
| lifeless | I don't see why you need cherrypicking given your description of your idea. | 22:24 |
| Talidan | well, we're thinking of migrating from GIT | 22:27 |
| Talidan | which was hosted at github | 22:27 |
| Talidan | there everyone (besides official mantainers) would open their own fork | 22:27 |
| lifeless | right | 22:27 |
| Talidan | andn push their changes to their own fork | 22:27 |
| Talidan | and if we thought they were decent, we'd merge them over | 22:28 |
| Talidan | my understanding is that it requires cherrypicking for bazaar | 22:28 |
| Talidan | Bearing in mind their fork might have loads of crap we dont want | 22:28 |
| lifeless | ah | 22:28 |
| Talidan | we only select the commits that we actually want | 22:28 |
| lifeless | so, you can use 'bzr merge -c rev' | 22:29 |
| lifeless | which will do a cherrypick merge | 22:29 |
| Talidan | i was just wondering what "does not track cherrypicked revisions" actually means | 22:29 |
| lifeless | and commit --author "foo bar <foo.bar@example.com>" | 22:29 |
| lifeless | it means we don't track them | 22:29 |
| Talidan | mind elaborating? | 22:30 |
| lifeless | uhm | 22:30 |
| lifeless | I'm not sure where the disconnect is | 22:30 |
| Talidan | track could mean a whole lot of things | 22:30 |
| lifeless | there is no record kept of the fact that a particular commit was a cherrypicked merge. | 22:31 |
| Talidan | Right, okay thanks | 22:31 |
| lifeless | you can do cherrypick merges easily | 22:31 |
| lifeless | (merge -c) | 22:31 |
| lifeless | and if you commit with --author they will be credited appropriately | 22:31 |
| lifeless | (in bzr merges never create commit objects, you need to do a commit after the merge) | 22:32 |
| mwhudson | jelmer: ayt? | 22:38 |
| Talidan | What windows GUI bzr client would you guys reccomend? | 22:40 |
| jelmer | mwhudson: I am now | 22:40 |
| Talidan | TortoiseSVN is the only Tortoise* i've had a good experience with, tortoisegit is a pile of rubbish, and tortoisehg is average | 22:40 |
| mwhudson | jelmer: have you tested the kernel import on staging since last week? | 22:41 |
| mwhudson | (with a new bzr-git & dulwich) | 22:41 |
| jelmer | mwhudson: I don't have a way to update the dulwich/bzr-git on staging afaik :-) | 22:42 |
| mwhudson | jelmer: well, "caused to be tested" then :) | 22:43 |
| mwhudson | jelmer: you have the same mechanism as me! | 22:43 |
| mwhudson | jelmer: do you think it would be a useful test at this stage? | 22:44 |
| lifeless | Talidan: I hear good things about bzr-explorer | 22:46 |
| Talidan | Thanks, i'll give it a go | 22:46 |
| jelmer | mwhudson: ah, asking a losa ? :-) | 22:48 |
| jelmer | mwhudson: There's one bug I noticed that I'd like to get fixed first (unusual modes disappearing doesn't seem to be handled right) | 22:49 |
| mwhudson | jelmer: yeah | 22:49 |
| mwhudson | jelmer: ok | 22:49 |
| mwhudson | jelmer: any idea how long that'll be? | 22:52 |
| jelmer | mwhudson: might be tonight, but there's a few other things I have to take care of first | 23:00 |
| mwhudson | jelmer: okidoke | 23:00 |
| * mwhudson continues applying the email shovel | 23:00 | |
| Talidan | i think it's an oversight to not have simple authentification given open source projects that dont need security but simplicity | 23:18 |
| Talidan | or wiat, does bzr support user/pass? | 23:20 |
| Talidan | i guess it's launchpad doesn't? | 23:20 |
| lifeless | bzr supports user/pass | 23:22 |
| lifeless | lp uses ssh and oauth | 23:22 |
| lifeless | bzr doesn't support oauth yet | 23:22 |
| lifeless | there is an interesting spec though | 23:22 |
| lifeless | that google and others have done for oauth IMAP and SMTP | 23:23 |
| lifeless | we could perhaps adapt that | 23:23 |
| lifeless | lp doesn't maintain cleartext passwords though, so it wouldn't be easy to turn on plain ol password supoprt | 23:24 |
| jelmer | lifeless: OAUTH over SASL, or using some different mechanism? | 23:28 |
| lifeless | jelmer: I haven't read the spec for how they did it in IMAP yet | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!