=== Ursinha-afk is now known as Ursinha === cinerama_ is now known as cinerama [07:42] hello jelmer , hello all [07:47] Shoot, I'm demoted to 'all'? :( [07:53] hehe, you were part of all in 'hi all' already :) Since you ask me to introduce some variety I do my best at a time where my caffeine / blood ratio is still low... [07:54] There are many problems in the world caused by having too much blood in one's coffeestream... [07:55] Still, it's not THAT hard to rig up an IV, really. [07:55] 4 ? [07:56] As in 'intravenous'. [07:56] ha, IntraVenous ? [07:56] :) [07:56] morning vila [07:56] hey jam ! [07:57] jam: so, about your config need, [07:57] nothing forbids getting the option value once and pass it down to your objects [07:57] 'morning vila :) [07:58] (if you're still worried about accessing the *file*) [07:58] hi fullermd, Riddell_ [07:59] jelmer_: nice shot, the avatar (Ridell no _) died ;) [08:00] :) === med_out is now known as medberry [08:03] vila: so I don't know if you noticed what I said, which is that one of the ways GroupCompress objects are created is from _LazyContentManager, which can be instantiated by a NetworkRecordStream. None of which is directly coupled to a Repository. [08:03] anyway, I think I can make it work [08:04] Right now, I'm working on actually implementing the functionality *based* on the config item, so I have some time to think about it still [08:04] jam: there are two cases there I think [08:04] if it's connected to the repo, get it from there [08:04] if it's not there are again two cases :) [08:04] if it should end up in a repo, you probably know it ahead, so connect it [08:05] otherwise, either fallback to the global config or use a default value [08:23] hi everyone [08:24] fullermd: he really meant fullermd *and* everyone ;) [08:24] hey poolie === rvba_ is now known as rvba [08:25] Oh good. My ego was in danger of shrinking for a minute there. And then what would hold up the clouds? [08:26] Herakles ? [08:27] Pfft. Pretender. [08:28] vila: I'm pretty sure Atlas was the one holding up the world, Herakles was just a strong-man [08:30] jam: indeed, but Atlas asked Herakles to replace him for a while (and went party-ing for an unreasonable period and then Herakles wasn't wery happy about that...) [08:30] was he a waskaly wabbit? [08:30] :) [08:38] Well, Atlas managed to get whole lines of gym equipment named after him, so by some measures he come out ahead, anyway... [08:39] and some pretty awesome books. [08:40] and a now-defunct rocket launcher program. [08:40] Yeah. And what did Heracles get? A crappy TV show... [08:40] It just doesn't pay to hold planets for your friends. [08:41] sage advice, I'm sure that will save people some time. [08:41] 's why I share my genius like this. I'm a giver. [08:42] yeah, once again competition is bitten by collaboration ;) [08:45] Good choice for a Greek day, as I'm already sitting here listening to _Atalanta_ :p [08:52] :) [09:20] jam: quick check about our locking model: [09:21] branches/wt are write-locked for the duration of the whole operation but repos are only write-locked around the pack-names modifications [09:21] correct ? [09:21] operation == bzr command [09:22] well ~=, you see what I mean or feel free to be more precise ;) [09:22] vila: physically locked, yes [09:22] is there some hidden meaning to physically I may be missing ? [09:22] so when you do Object.lock_write(), Branches and WT change the state on disk [09:22] Repository does not [09:22] yup [09:23] Repository only holds the on-disk lock for the time to update pack-names [09:23] my question was: only one operation can get the lock [09:23] vila: right. It doesn't make sense to allow 2 people to push to a branch concurrently, since both would want to change the branch poitner. [09:23] sure [09:24] arguably some branch operations could be done in parallel, but it was never worth doing [09:24] (like setting a branch.conf entry vs updating branch's tip pointer) [09:24] what I'm after is: can I rely on the object lock to assume that the corresponding config file doesn't need an additional lock [09:24] this works for branch/wt but is still unclear for repos [09:25] vila: doesn't work for repos, but they don't currently have a config [09:25] indeed ;) [09:25] also, we don't *want* to block Repo for config settings (most likely) [09:25] * vila nods [09:25] we *want* repo to be multi-writer as much as possible [09:25] * vila nods [09:25] so that you can have 100 branches that get updates without blocking the repository [09:25] I don't know how that works with config [09:25] well [09:26] there is no repo option today [09:26] so there is no repo option that a bzr operation want to set [09:27] but we can imagine repo options that could be set directly via bzr config or by editing the file [09:28] so as long as the config file is never left in an inconsistent state by bzr itself, we always get a valid config file leaving only the issue that bzr can get an out-of-date option value (which is acceptable) [09:29] neglecting user errors while editing the file that is (which is addressed differently anyway) === joey is now known as canonical === canonical is now known as joey === hunger_ is now known as hunger [10:44] spiv, hi [10:49] jelmer: hola [10:49] spiv: I'm looking at adding a limit argument to Branch.fetch but I'm wondering what the most appropriate way is to do so [10:49] spiv, in particular, would it be better to pass the limit argument down as part of the fetch_spec or rather as a separate argument down to InterRepository.fetch() ? [10:50] Hmm, limit meaning what here? [10:51] If it means "no more than N ancestors of these tips", then I think that's a kind of fetch_spec. [10:51] yep, just a rough way of limiting the data transferred [10:52] hey spiv, on late? [10:52] (If you don't mind walking the history up front you can already do that via an appropriate SearchResult fetch_spec) [10:52] jam: yeah, a bit. V just went to bed. [10:52] Snoring like a proverbial baby :) [10:52] :) [10:52] spiv, that makes sense, I'll add it to the fetch_spec. Thanks :) [10:53] jelmer: so basically yes, I think this is something fetch_spec ought to do [10:54] I have a ugly patch atm that adds a new fetch spec (to make "bzr branch --stacked" from remote when it's about to build a working tree) much better. [10:55] Transfers 1/3 the bytes in 1/2 the round-trips. [10:56] So I'm definitely in favour of adding fetch_specs :) [10:56] that sounds nice :) [10:57] Basically it's a fetch spec for "the whole revision, i.e. inventory and all referenced texts (and chks)", which is the data that has to be retrieved to build a working tree if you have no data to start with. [10:58] We really should make get_stream_for_missing_keys not need VFS calls though [10:58] (Possibly in part by sending more of those keys in the stream in the first place!) [11:13] Hello everyone [11:13] I'm having a spot of bother with my bzr-svn [11:13] I'm 2.4 daily on ubuntu and when I push I get this [11:13] http://paste.ubuntu.com/606456/ [11:13] chriscauser, hi [11:14] It worked yesterday so I suspect it may have something to do with the update I installed this morning [11:15] chriscauser, what sort of bzr / bzr-svn are you running? [11:16] jelmer: Sorry, I thought it was in the crash report. bzr is 2.4.0dev3 [11:16] bzr-svn is 1.1.0~bzr3688~ppa376~lucid1 [11:17] chriscauser, you need a newer version of bzr-svn too if you're running a bzr snapshot [11:17] are you running both from the daily PPA? [11:17] yes [11:18] As far as I'm aware, there's nothing out of the ordinary on this box [11:18] (other than a daily PPA ;) ) [11:20] looks like the bzr-svn package in the PPA needs fixing [11:21] jelmer: Thanks [11:27] chriscauser, should be fixed now, but it'll take up to 24 hours for the package to rebuilt [11:27] *rebuild [11:27] jelmer: Thanks a lot. What would you recommend I do in the meantime ( [11:28] pin the version or download the tar?) [11:28] or just sit and wait :) [11:28] ? [11:28] chriscauser: there is no tarball to download, as you're running a nightly build :) [11:29] chriscauser: you can grab lp:bzr-svn though [11:29] jelmer: Duh, now why didn't I think of that! [11:30] spiv: still there? [11:30] spiv: I'm trying to figure out how to integrate this with SearchResult [11:31] jelmer: I probably wouldn't change SearchResult. This sounds like it'd be a new search or search result. [11:34] spiv: Where would you put it instead, FetchSpecFactory.make_fetch_spec() ? [11:36] jelmer: the other thing to consider between you and spiv, is how "wide" the result should be [11:36] jelmer: Thank you so much. The latest revision works absolutely fine now. [11:37] specifically, for "shallow" branches, you want to have all texts, even if they aren't part of the delta for a given rev [11:37] chriscauser: np, thanks for making me aware it's broken [11:37] however, for regular fetch + some ancestors, do you want all texts or not? [11:37] jam: The use case for this is the incremental fetches that Launchpad does for imports (but would also apply for mirrors) [11:38] jelmer: how is that different from just requesting a fetch at N and reporting back that you have N-1000 ? [11:38] (though it sounds like you don't want the 'fully-wide' content) [11:39] jam: we want more than just the mainline so N-1000 is too rough [11:39] jelmer: but don't you have text discovery already? [11:39] jam: also, it's imposibble to determine what N-1000 is for e.g. Git or Mercurial repositories [11:39] _walk_to_to_common_revisions [11:39] sort of thing [11:40] jam: that's server driven [11:40] jelmer: I don't understand why you want N - (100 old ancestors) without wanting evertyhing you don't have [11:41] jam: I do want everything I don't have, I just don't want all of it now [11:41] jelmer: but surely you want older stuff first [11:41] jam: ah, yes [11:41] jam: of course [11:41] jelmer: the search you were proposing was "give me the newest 100 revisions" not "give me the oldest 100 revisions that I don't have" [11:42] I understand why you want the latter, but that isn't easily constructed from a tip [11:42] also, how would you pass that to something like git ? [11:42] I thought it could only fetch everything from the tips it has [11:42] (it reports to you) [11:42] jelmer: Perhaps make_fetch_spec() would sometimes use this new fetch spec, but that seems like a largely orthogonal issue [11:43] jam: yes, it can only give you everything but bzr-git can limit the amount it fetches to the bzr repository [11:43] jelmer: by staging it? [11:44] jam: importing the git pack file to bzr is fairly slow (getting better, but not ideal yet) [11:44] jam: refetching the pack each time at the moment [11:44] jelmer: so it gets the full ancestry stream, and then strips it? [11:44] yeah [11:44] jelmer: AIUI the issue you're tackling is you have some code that would like to call "source.fetch(fetch_spec=)", and needs to be able to have a that means "limited to " [11:44] jam: It's not ideal, but this is what already happens on the Launchpad importds atm [11:45] jelmer: so the questions are a) what object is , and b) how do you make one? [11:45] jelmer: what *I* would like to see, even for bzr-core, is the ability for a fetch stream to say "you should have a complete snapshot up to rev X, feel free to commit it" [11:46] we can already interleave Revisions then inventories, then texts, then send more revisions (IIRC) [11:46] it would be nice to have revs, invs, texts, COMMIT, revs, invs, texts [11:46] that would also allow resumable "bzr branch" [11:46] jam: that'd be nice [11:47] and possibly make it cheaper to compute fetch streams [11:47] jelmer: one approach is "class MostRecentNRevsNotAlreadyInTarget(AbstractSearch): def __init__(self, n, target_repo): …" that just does a regular breadth-first walk in its .execute() and so returns a regular SearchResult [11:47] in that the streaming code could find what needs to be sent, but then break it up to commitable chunks [11:47] and then it doesn't have to look at all 5Million chk pages across all 100k revisions [11:47] jam: it's different from this though - the fetch limit goal is mainly there to avoid resource issues [11:47] jelmer: another approach is define a new SearchResult (rather than a new Search), along the lines of PendingAncestryResult [11:48] spiv: jelmer and I just realized that he wants OldestNRevsNotAlreadyInTarget() [11:48] which is quite different [11:48] spiv: Sorry for being vague - I'm after the oldest revs rather than the newest [11:48] or what jam said :) [11:48] jelmer: ah, interesting. [11:49] I could imagine something like OldestNRevsOfPendingAncestryResult [11:50] Where you specify not just the heads you want, but the heads you've already got [11:50] Normally we don't like calculating heads for the target because it's not cheap [11:51] But if you've just grabbed a OldestNRevsOfPendingAncestryResult stream you can keep track of the heads so far as you receive them. [11:52] spiv, ah, hmm [11:52] spiv: true, and you could also use an existing branch target as a Head to seed [11:52] It's a bit rough on the stream source (i.e. the server), it will have to keep walking back from the current tip all the way back to your heads each round. [11:52] right now fetch is missing Branch <=> Branch info [11:52] as it tends to just be done at the Repo level. I would *like* to at least hint at target heads. [11:52] But that's perhaps just the price someone has to pay for breaking the work up into chunks. [11:52] Though we'de need to do something with that. [11:53] Yeah, having more info about the target heads available there would be good. [11:55] lunchtime here, I'll have a closer look at it this afternoon [13:00] Hello/nick mrevell-lunch [13:01] Oops === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell === vila is now known as vila-afk === vila-afk is now known as vila === Ursinha is now known as Ursinha-afk [15:09] hi everybody [15:10] any experts here ? [15:10] qor non-experts ? [15:11] wel ... [15:11] i'd like to know what "pending merge tips" are [15:12] i believe the reason why they are in my directory is that ....... [15:13] the directory is a checkout from a local branch which is a "branch" of a public branch [15:13] and i wanted to merge the branch updates with my local changes but accidentally did a pull [15:14] now my locally commited changes disappeared from the log but they are still in the files [15:15] bzr diff shows all of them in one diff ... [15:15] ... bzr status -v shows all the commit messages [15:15] now another more important question: [15:21] ... [15:21] his commits are still there but he is not anymore so he can't know... [15:24] bugreport: were you called bugreporter a few minutes ago [15:24] ? [15:24] ... all ... dädädä ... [15:24] yes [15:24] .... merge tips [15:24] sorry [15:25] do you know anything about merge tips, villa [15:25] ? [15:25] (more personalized nicks are available and easier to recognize ;) [15:25] yes [15:26] when you do a merge, 'bzr status' reports the tip of the branch you merged so you can keep track of where you are [15:26] you triggered a merge when you did the pull in your checkout [15:26] "the tip of the branch I merged " ... yes ... [15:27] what i fail to understand is why my commits are not in bzr log output [15:27] so your previous commits were merged, you still need to commit to finish the merge [15:27] because they are pending [15:28] aaaah ... ok ... but ... [15:28] they will appear after you commit [15:28] well, [15:28] now when i do a merge, they will be "condensed" ... [15:28] no [15:28] or [15:28] no ? ..... [15:28] well, really no [15:28] but by default bzr log will only report the merge [15:29] do 'bzr log --include-merges' to see them [15:29] and where will the commit message of the merge commit show up and where the others ... [15:29] thanks [15:29] ok ... think i just got the answer from you [15:29] there all there, one level down [15:29] they are all... [15:30] have to read about include-merges ... [15:30] yeah, try 'bzr log --help' [15:31] ~ shows all revisions, also those not in the mainline ... [15:31] which means bzr pull also made the "remote" the mainline ... [15:31] sort of [15:31] can i make my local changes "mainline" again ? [15:32] (and how ?) [15:32] if you're sharing the remote branch with others, you don't want to do that [15:32] i don't have write access to remote [15:32] well, unless you can convince them that's you're the boss and they just have to listen ;) [15:33] am just trying to get my local branch ready to publish on launchpad [15:33] remote is on savannah.gnu.org [15:33] i think i could publish my stuff on launchpad ... ? can i ? [15:33] sure [15:34] :-) you have any suggestions on how i should proceed with that from here ... [15:35] hmm [15:35] i would finally do something like "bzr push lp:~bugreport-mailinator/grub/sector-ranges" ... or can i just publish to "+junk" ?? [15:35] better to publish in the project namespace [15:36] if only because you will be able to do a merge proposal against the project trunk [15:36] hmm [15:36] do have write access there (default / without any further actions ... [15:36] as long as savannah and lp agree about what the trunk is [15:36] i thought it's savannah but am not sure ... [15:37] they differ quiet a bit ... anyway ... in terms of bzr commands ... how to get my local changes branch to be "mainline" again here on my laptop ? [15:38] https://code.launchpad.net/~vcs-imports/grub/main seems to say that it's a mirror from gnu.org so that should be in sync [15:38] back to your goal: [15:38] you can: [15:39] (by "differ" i mean, there are commits inn launchpad/ubuntu which are not in the trunk on savannah ) [15:40] if you commit now, that will create a revisions whose parents will be (savanah tip, your last commit) [15:40] what you want is (your last commit, savannah tip) [15:40] exactly .... got me [15:40] hmm, [15:40] :-) difficult enough ? [15:41] the shortest way that comes to mind is to recreate a branch with a tip at your last commit [15:41] and merge savannah branch there, commit and you'll get the right pattern [15:41] now, to get back your tip... [15:42] you can just commit and see what revno you get there :) [15:42] there are other ways but this one is the simplest for you I think [15:42] hmm... [15:42] lets commit ... [15:43] it's +1 from before ... [15:43] so savannah-trunk+1 [15:43] look at 'bzr log --include-merges' now [15:44] +10 from my old tip [15:44] yup, commit always create a +1 revno by definition [15:44] forget about the numbering of your old tip, you broke it [15:44] old tip commitsss all have the same revno [15:44] :-) [15:45] they shouldn't, are you sure you used --include-merges ? [15:45] if in doubt, just pastebin the output [15:45] !paste [15:45] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [15:46] all right ... but i can switch branches and have the old commits seperate ... ? (if not it doesn matter much ... nothing interresting in the commit messages ... all just "wip" but out of interrest ... [15:46] http://paste.ubuntu.com/606520/ [15:47] yes you can (unless I totally misunderstood what happened) [15:47] right, so they don't have the same revno: 3245.1.1 is different from 3245.1.2 [15:47] :-) didn't read the output before ... [15:47] to get back your old branch just do: [15:48] bzr branch . -r3245.1.27 ../my-dear-old-branch [15:49] and, yeah, I'm sure the people you'll share this branch with will be more than happy to find commit messages providing a bit more info than wip ;-D [15:49] cool ... wroked [15:50] i have to write some ... and condense some commits ... make around 5-10 out of those ... [15:50] :-) ... you helped me a lot already ! thank you! .. [15:51] .. anyway if you know how to write nice commit messages onto those changes and reorganize them ... ?? [15:51] "git rebase -i" ... [15:52] haaaaa... that's why it's so popular ! [15:52] very likely [15:52] there is 'bzr shelve --interactive' I think [15:53] ok ... sounds good [15:53] not in my version though ... [15:54] (natty 2.3.1) [15:54] but shelve works for uncommitted changes, so you'll have to get them back first [15:54] (at leas not in help output ... [15:54] err, wth [15:54] :-) pull ? [15:56] hmm, no cherry pick instead probably [15:57] i.e. start with a branch from savannah and there do: [15:57] googling for "git rebase bzr" leads me to a plugin ... bzr-rewrite" [15:57] yup, but I don't think there is an --interactive option there, does it ? [15:58] http://marcin.juszkiewicz.com.pl/2010/10/06/bazaar-what-is-wrong-with-it/ [15:58] no idea ... [15:58] --interactive is imho not really appropriate on the rebase command, as it's a general way to reshape the revision graph [15:58] bzr merge ../my-dear-old-branch -r.. [15:58] go ahead with the cherry-pick solution ... sounds reasonable [15:58] I'm happy to have another command in bzr-rewrite that does a similar thing though [15:59] jelmer: Did I dream the shelve --interactive ? [15:59] vila, shelve is interactive by default, no? [16:00] bugreport: bzr diff will show your changes, bzr st will allow you to verify that there is no pending merges, you're just getting the changes without tracking the history [16:00] awilkins: dunno, I always use --all [16:00] awilkins: because I can't use the interactive mode under emacs (where I have alternative workflows that work better for me) [16:01] bugreport: so once you have the uncommitted changes, try 'bzr shelve' and follow the prompts ;) [16:02] vila: there is a bzr-interactive plugin that allows interactive shelving I think [16:02] i was about to check out ("merge") a fresh savannah trunk and the do "bzr merge ../my-dear-old-branch -r.." repetingly ... ?? [16:02] jelmer: haaaa, thanks, bugreport ^ [16:03] bugreport: you create a branch once, you repeat the merge ; hack;shelve;commit;unshelve; [16:03] ups --- i meant ("branch") of course ... [16:05] vila: it does a completely different thing from "git rebase -i" though [16:07] bugreport: branch and checkout are two different things but if the checkout led you to the trap, you may prefer branch and come back to checkout later (bzr reconfigure can help switch from one to the other) [16:07] well ... i will approach the task later on .... [16:08] i branched / not chekout actually ... [16:08] i was just not aware that pull would do a different kind of merge then merge ... [16:08] bugreport: or you may just push your branch to lp, not everybody cares about the intermediate commits [16:09] bugreport: pull should warn you to use merge if it can't pull in a branch [16:09] yea ... [16:09] bugreport: checkouts are different [16:09] ok - have to go - see you ... [16:09] and thanks again [16:09] bugreport: they are targeted at people used to the centralized workflow where the local changes don't show up on the mainline [16:10] hmmmm .... [16:10] i kind of dont like that "compatibility" in bzr [16:10] bugreport: just use plain branches then [16:11] * awilkins likes "lightweight" checkouts used to approximate gits co-located branches thing [16:11] bugreport: I suspect you *did* use a checkout to end up in this "mess" [16:11] awilkins: please :) Don't add confusion ;) [16:11] distriibuted is a new paradigm which is not really hard to get and you should switch when using a dscm [16:12] bugreport: not everybody has the luxury to do that [16:12] bugreport: *I* never use checkouts, but I don't forbid others to ;) [16:12] i have a shared repo on top and "savanna-trunk" and "my-branch" inside ... [16:12] bugreport: perfect setup :0 [16:12] shared repo created with "bzr init-something ..." [16:13] init-repo [16:13] :-) good to know it's approved [16:13] hehe [16:13] cu then ... bye [16:13] we want to make it easier to get it as the default one [16:13] cu [17:12] Hello all again. Sorry to pester (and I hope this is a quick one) but I don't know how to use bzr+svn with keyring auth for http simple. Is there a verbose flag that would tell me what it's trying on the auth front? [17:13] chriscauser_, hi [17:13] chriscauser_, GNOME keyring?> [17:13] jelmer: yes indeed. [17:14] chriscauser_, bzr can only use existing keyring credentials, it won't add new credentials to keyrings at the moment [17:15] jelmer: Ah, this might be it. It seems to checkout the repo just fine in svn though. [17:15] (as in I have put the credentials in the keyring already by doing an svn checkout) [17:16] chriscauser_: it should in any case prompt you, even if it can't already find the crednetials [17:16] also, I can't spell [17:18] jelmer: don't worry. I'm explaining it very badly. My problem is more of an annoyance than anything else. Any remote operation requires me to enter a password. svn checkout works fine because the pw is cached in the keyring. Is there a way of getting the same behaviour? [17:18] jelmer: It used to work when I had the pw stored in plaintext in ~/.subversion (obviously not ideal) [17:19] chriscauser_: I'm not sure [17:19] chriscauser_: If you can use svn with the keyring credentials then that obviously means that the credentials are there and valid [17:19] so I'm not sure why the keyring integration in bzr-gtk is not working properly [17:20] jelmer: Is there a debug that I can run? [17:20] chriscauser_, it's been a while since I've worked on the keyring stuff [17:20] chriscauser_, I'd recommend adding some pdb statements in the code in bzr-gtk to see what entry it is looking at [17:20] and then comparing that with what the gnome-keyring-manager thinks is present [17:23] jelmer: OK. I'll get back to you on this. [17:53] jelmer: I think I have it. svn seems to be storing the credentials in the keychain differently to how bzr-svn is expecting to read it. [17:53] I have got it working, and can give you a patch if you want [17:53] The only problem is I don't know if it is because subversion has changed the way it stores things (I'm on Lucid) so I may break things for other people [17:56] i have *.pyc in my ignore file, but pyc files still show in subdirectories? [17:56] do i do */*.pyc or something? [17:57] chriscauser_: I don't think it has - a patch would be great :) [17:58] is bzr written entirely in python? [18:02] jelmer: I'm forking bzr-svn and will create a merge proposal for you if that's OK with you. [18:02] chriscauser_: You mean bzr-gtk? [18:02] Buttons840: Do you mean whether "bzr status" shows them? [18:03] jelmer: Yes, you're clearly psychic because you understand what I mean, not what I write :) [18:04] chriscauser_: :) === deryck is now known as deryck[lunch] [18:07]