[00:00] morning [00:02] igc: fast-import is awesome [00:03] hello igc [00:03] igc: I'm importing an svn archive at the moment with a vendor-branch-like arrangement for upstream, and trying to arrange that the resulting bzr branch has native merge commits for each upstream merge. It's working amazingly well [00:03] (james_w gave me the last necessary clue in the form of import-marks) [00:04] cjwatson: I'm glad it's working for you [00:11] thanks cjwatson [00:20] jelmer: ping [00:20] lifeless, ponggg [00:20] bug 250480 [00:20] Launchpad bug 250480 in bzr-svn "Doesn't preserve non-lhs parents for file texts" [High,Triaged] https://launchpad.net/bugs/250480 [00:20] I agree with john that this is critical [00:20] I don't understand quite where the issue is re non-lhs parents and the error [00:21] from my analysis I thought that there were two inventories with different values and the same revid [00:21] which is also known as 'corrupt distributed DB' [00:21] but you seem to think its something else [00:21] ? [00:22] No, I agree with that analysis (for values == "file parent ids") [00:22] parent ids are not stored in the inventory [00:23] so I don't understand what you mean when you say you agree :) [00:24] The actual error suggests that bzr can't find the revision of a file text [00:24] however, that file text is a ghost in the branch fetched by bzr-svn [00:25] so there are three revisions bzr will look for [00:25] (and need) [00:25] and some N that it will need when fetching IFF the revision is also present [00:25] the three it needs are left/right/base [00:26] but another possibility is that the change rev in the inventory in the target repo is actually bogus; its a change that the repository does have and can't get hold of [00:26] or something along those lines [00:27] back in 30, got to do some stuff here [00:27] I guess I'm really saying: lets pin down *exactly* why bzr is asking for that revision, and whether there are *any* differences in data between the repositories [00:27] *other* than ghosts. Ghosts are ok, different xml-inventories or revision-xml's etc are not. [00:30] as far as I can tell, the particular revision it was asking for doesn't occur in svn or the svn-based branched *anywhere* [00:51] I thought I heard that bzrtools has been incorporated into 1.6 - is that true, or only some parts have been incorporated? [00:52] ultimately I'm trying to work out if the windows binary should package it? [00:53] Um, it hasn't been. [01:00] markh: it hasn't been incorporated, no. So please do package it. [01:03] spiv: ok, thanks [01:04] jam: wrt export masking, do you think plugins should use another pattern if they want their magic stuff exported? [01:05] jam: I could put the rule in a function that plugins could monkeypatch over to tune it *but* that feels pretty fragile myself [01:05] I think there are two use cases [01:06] one is adding arbitrary data (e.g. version-info output) during export [01:06] the other is masking data that shouldn't be in the user tree (e.g. .bzrignore) [01:06] I'd *prefer* we fix the latter by just not putting in the users tree [01:06] the former seems genuinely useful though [01:07] lifeless: I'm not changing the former, just generalising the latter so that anything starting with .bzr is not exported [01:08] igc: yes, I saw the patch. [01:09] spiv: --rich-root is not an alias at the moment, were you assuming it was? [01:10] jelmer: [01:10] $ bzr init --help | grep -A1 -- "--rich-root " [01:10] --rich-root New in 1.0. Better handling of tree roots. [01:10] Incompatible with bzr < 1.0 [01:11] beuno: awake? [01:11] jelmer: so I wasn't just assuming, I checked :) [01:12] spiv: that's not an alias, it's a knits-based format [01:12] Ah :( [01:14] it may be a good idea to get rid of it though, in favour of an alias... [01:17] jelmer: thanks for noticing my mistake [01:26] mwhudson, yeap, evening' [01:27] just got home [01:27] hi [01:27] beuno: hi, thanks for fixing loggerhead :) [01:28] mwhudson, I felt a bit responsible :) [01:28] beuno: so i am a little confused though [01:29] beuno: will the loggerhead we're running break with current bzr.dev ? [01:31] mwhudson, no, it works with bzr.dev [01:32] a few commits after b2 [01:32] beuno: good [01:32] when lifeless's enourmous patch landed it broke [01:32] so why did this method change? [01:32] oh right [01:32] then bzr.dev became more compatible again? [01:32] "versioned files" and the likes [01:33] compatible relative to what? :) [01:33] well [01:33] one of the things I was thinking of, is having that part patched in LH for a few versions, where it tried both methods [01:33] wasn't the patch you gave kiko reverting the change that was made to this method? [01:34] * mwhudson attempts to make sense [01:34] the loggerhead we're running does this: [01:34] w = self._branch.repository.weave_store.get_weave(file_id, self._branch.repository.get_transaction()) [01:34] rather than existing_keys = self._branch.repository.texts.get_parent_map(possible_keys) [01:34] mwhudson, yes, because you're running b2 in code host [01:35] mwhudson: the former won't work in b3 and abot [01:35] because .texts doesn't work with b2 [01:35] and it works from b3+ [01:35] beuno: will the loggerhead we're running break with current bzr.dev ? [01:35] mwhudson, no, it works with bzr.dev [01:35] mwhudson, ah, my mistake [01:35] it will [01:35] is this actually what you meant to say? [01:35] I warned matsubara [01:35] that it would [01:35] ah, ok [01:35] I misunderstood [01:36] I just bought a Wii and got distracted :) [01:36] ok, so this isn't ideal but at least i understand what's going on now :) [01:37] yeah, I offered to put together a patch that would probe one, and go to the other if it failed [01:37] but they chose reverting [01:37] okidoke [01:38] I still think it makes sense to do that for trunk [01:38] so we can be compatible with older bzr versions [01:40] yeah i guess so [01:43] * beuno is off to dinner [02:00] anybody have trouble saving commit message with emacs as editor? [02:01] I get: vc-bzr-registered: IO error reading c:/bzrfun/home/main/.bzr/checkout/dirstate: Permission Denied, when tring to save [02:02] bzr 1.5 [02:04] tsculpt: bzr will have an exlusive lock on the dirstate file [02:04] tsculpt: sounds like some emacs thing is trying to read that file directly (not such a great idea btw :P) [02:05] well, just trying to use emacs as commit editor [02:05] bzr commit [02:06] emacs comes up with the modified listing [02:06] I write my message, and try to save, and I get the error. [02:07] The vc-bzr-registered part makes me think emacs is doing something with it's built in vcs stuff? [02:10] ah, I notice it loads vc-bzr [02:36] hrmph - "bzr help commands" will list 94 commands by default on Windows!! [02:50] * igc lunch [05:20] igc: ping [05:20] hi lifeless [05:20] I'd like to chat about .bzrrules some [05:20] fire away [05:20] if you're up for it I could give you a ring [05:21] or else drop you a mail [05:21] or IRC works for me too [05:21] email might be best today [05:21] k [05:22] I will drop some thoughts to you directly [05:22] sure [07:01] I read that limbo post from http://bazaar-vcs.org/BzrVsGit and I realised thats a big problem for me [07:01] has anything been done about it in bzr? [07:02] what is a big problem for you? [07:03] which part? [07:03] you can alias 'commit' to 'commit --strict' if you don't want to forget to commit new files [07:03] the files that remain in limbo...those in a directory that aren't explicitly added to the repo to track [07:03] bob2, yeah but i prefer to automate alot of that [07:04] as in you want bzr to run 'bzr add .' before every commit? [07:04] i suppose [07:05] would that work? [07:05] <-- not a current bzrer [07:11] gambler: That would work, but is probably not a good idea. [07:11] gambler: [07:12] gambler: In particular it would mean that you wouldn't want to build in your working tree, since subsequent commits would then add the results of the build (plus random autotools files, etc). [07:12] you can `bzr ignore` those [07:12] well, you would ignore that .o configure.ac etc [07:13] bzr doesn't do globbing in .bzrignore, right? [07:13] it does [07:14] it supports full filenames, globbing and regexes [07:14] it optionally does res [07:14] Of course; my shell's being too smart for its own good. [07:14] so bzr add . bzr ignore *.class for my android project and I get automatic adds? [07:15] no [07:15] gambler: commit --strict is really a better idea [07:16] automating things is nice and all that, but some things are better to review [07:16] hey, you'll get a chance to review in the commit editor ;) [07:17] that's way too late, IMO :) [07:17] luks: thats how it starts...then why dont I write some unit tests, and X and Y and Z....and my productivity drops like a rock [07:17] If you do bzr alias commit="commit --strict" then bzr will automatically tell you if there are new files you haven't added or ignored yet. [07:18] ok..maybe ill try that [07:18] At which point you can decide what to do about them, and get on with work. That satisfies the criterion for "automated" pretty well for me :) [07:19] meh, the problem with all VCS is that it would be nice if all their interfaces were pure method calls, then I could design my workflow around them instead of the other way [07:19] I could script but then you run into problems making it robust [07:19] i script now [07:19] More automatic would probably mean automatically guessing what to do with individual files, which wouldn't make me comfortable. I can imagine that working fine for some people, though. [07:20] Well, bzr is completely scriptable in Python. [07:20] hmmm good point [07:20] It's even pretty easy to write a plugin to add new commands or extend existing ones. [07:25] im looking at bzrlib now...but im not really a python dude [07:35] Is there any way to go through a projects history and change my name everywhere? Right now it's just , but I want it to be 'Name '. [07:36] beuno: i hit a bug so i reverted [07:36] beuno: its not finding css/imagery again.. [07:37] Ryan52: no, revisions are immutable [07:38] Ryan52: something like that would need to create a completely new branch with different revision IDs [07:38] * Ryan52 thinks he would get in trouble for doing that :) [07:38] okay, thanks. [07:42] meh too much work [07:42] what is the status of the bzr plugin for eclipse...anyone here using it? [07:42] it works quite well [07:43] Verterok: is the main developer [07:43] gambler: I'm about to release a new build (with bunch of improvements) [07:44] Verterok, will it mind my adding and deleting of files? [07:45] gambler: it handle moves/deletes/renames [07:46] gambler: but the delete is equivalent to 'bzr rm --keep' (to avoid removing non-recoverable files) [07:47] (all files deleted by `bzr rm` are recoverable) [07:49] yay firefoxfail [07:49] if you could add in auto-adding of files that would be pure sex [07:51] luks: but if you have added (not yet committed) bzr rm --force delete them in a non-recoberable way :) [07:51] ugh [07:52] but why --force? [07:52] I'm not entirely happy with rm today [07:53] the basic tension is that unversion and rm are different operations [07:53] but we only have one command, because people usually want both operations to be undertaken [07:53] gambler: I don't fully understands the "auto-adding" thing :P [07:53] I don't think rm should be handled by a VCS [07:54] the old behavior (rm --keep) was my favorite [07:54] Verterok, auto-add any newly created files in the root directory, unless they are in the bzr ignore list. [07:55] Verterok, for renames....improvise :) [07:55] * fullermd has rm aliased to rm --keep. [07:55] Verterok, actually you can tie into Eclipse->Refactor-Rename [07:55] yeah, me too [07:56] gambler: mmm, there was a bug/feature request some time ago (java specific), about auto-adding newly reated classes. [07:56] and? [07:56] gambler: if I can provide an option so it can be enabled/disable, I'll be glad to add this feature [07:57] but I don't want that behaviour as default [07:57] gambler: renames are handled by the plugin [07:57] :) [07:57] i will love you forever [07:58] cant wait to try it. i am an insane refactorer and I need that [08:00] Verterok: if you find any glitches (or missing feature), please fill a bug so I can track and plan the features for the next milestone :) [08:00] s/Verterok/gambler/ :P [08:02] np..when will you release your next version [08:03] gambler: if all keep going as planned, in ~ 20hs :) [08:03] * Verterok need to sleep a few hours [08:04] ok...no rush. i've written myself a note to download it [08:04] I just finished a build from trunk, and testing it ATM === RAOF is now known as ROAF [08:15] all for today, seeya later [08:15] * Verterok heads to bed [08:16] c u [08:31] * igc dinner === ROAF is now known as RAOF [10:25] igc: hmm, so having said that I had a really good import (an svn branch for a Debian package which I'm gluing onto the side of the existing bzr branch for upstream) with bzr-fastimport, I realised that all my file-ids are screwed [10:26] igc: is there any way to get fast-import to say "this commit has 'from' or 'merge', therefore all files added in this revision should take their file-ids from that other branch"? [10:35] cjwatson: hi, I can't stay and chat sorry but a few things ... [10:36] how did you generate the stream? By hand? [10:36] igc: slightly hacked version of svn-fast-export.py [10:36] See the spec. You can certainly say 'get the file-ids' from another branch *assuminh* that branch is also in the stream already [10:36] (I stuck in a dictionary of commit identifiers to marks that I wanted to be merged) [10:37] hmm, did I miss it? I thought I looked [10:37] the other branch is not in the import stream; I'm referencing it by means of import-marks [10:38] fast-import won't look at the those revisions, it will just add the extra parents you request. [10:38] I believe we could extend fast-import to optionally look for them and import the file-ids. [10:38] cjwatson: spec is http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html [10:39] yeah, I'm reading that [10:39] hi igc [10:39] hi james_w [10:39] it seems to have a way to reference existing content from elsewhere, but not existing file-ids [10:40] cjwatson: so I won't be around but james_w knows the fastimport code pretty well and it's pretty hackable imo [10:40] yeah, I certainly don't mind hacking it (and already have done), but wanted to know if this was in place already [10:40] if it's not, I can always beat it up until it is [10:41] it does seem like it's what you'd want to be the default behaviour when 'merge' commands are present in the stream though [10:42] cjwatson: for a quick hack, around line 513 of processors/generic_processor.py could be extended to also look at all the revision ids listed in the marks [10:43] _gen_file_ids_cache [10:44] hmm, right, might have to do something interesting in the case where you have file added in svn branch, then deleted and copied-over-the-top [10:44] since then there'll be multiple file-ids to choose from for a given path [10:44] yeah, the cache should actually be replaced with something else as I understand it [10:45] personally; I'd just let bzr do all the heavy lifting [10:45] however, I think the replacement would actually be harder for you to hack to get what you want [10:45] hey lifeless [10:45] but apparently there were performance implications in doing that [10:45] I have the feeling I want to special-case it at the cache user end, since I only want this check in the cases of certain commits [10:46] bzr_file_id_and_new [10:46] like bzr_file_id_and_new(self, path, sourcerev=None) [10:46] snap :) [10:49] hi, do ignore files stack? I seem to have a global ignore file somewhere, can I assume that it'll still be checked when I add one to the branch I'm working in? [10:49] nazgjunk: ~/.bazaar/ignore, and yes [10:50] thanks [10:57] right [10:57] bug fixed [10:57] -> off [10:59] ahh that reminds me [10:59] * Jc2k goes to read gnome-bzr log === thekorn is now known as thekorn_ === abentley1 is now known as abentley === is_null_ is now known as is_null [12:46] igc: got busy on a bug; I'll try to mail you tomorrow; or perhaps voice would work better then; something [12:46] gnight all [12:46] sure lifeless; night === mars is now known as Guest65430 === vednis is now known as mars [15:47] hi, I'm trying to use bzr on a shared webhost. 'python' -> 2.3.4, which has the bz2 module, but there is also 'python2.4' which does not. [15:47] can I get bzr to use python 2.3? or should i try to install the bz2 module? [15:48] Hi. How can I fix this? http://paste.pocoo.org/show/80707/ [15:48] Doesn't work with bzr push lp:~dennda/memaker/experimental either [15:48] pfctdayelise: bzr will definitely not work with python 2.3 [15:49] dennda: bzr launchpad-login "your-launchpad-id" [15:49] dennda: bzr launchpad-login [15:50] or just use a ssh+bzr url directly [15:50] bzr+ssh I mean [15:53] I suppose people have read http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation [15:53] ? haskell is moving away from darcs - interesting discussion of git vs hg vs bzr [15:55] mlh, that page only lists git and mercurial as serious contenders [15:56] do you know why that is? [15:57] weird how 'Cherry-picking isn't very "native" to the data model' is a disadvantage of bzr, but not hg and git [16:04] jelmer: that's what one line says, but the rest of the page seems to contradict it [16:04] so .. not clear [16:05] * mlh sleeps [16:10] have you seen http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation ? [16:11] new potential customer... [16:12] heh :-) [16:14] ghc is not so small project and has (potential) influence on the whole haskell community [16:15] what are the commands for resetting/changing related branches (as listed in bzr info) [16:17] is it only available in locations.conf? [16:17] arnarl: you can either edit ~/.bazaar/locations.conf, or you can use --remember on the appropriate commands [16:18] so "pull --remember" will change the parent branch, "merge --remember" will change the submit branch [16:18] james_w: thnx! :-) [17:21] chadmiller: Ping, would you like to discuss the new issue privately? [17:21] Sure. [18:59] jelmer, around? [19:27] hello, how can one force bzr to make a file executable? [19:28] chmod a+x file [19:28] luks: let me explain [19:28] I have to assume somebody submits a text file containing a python script from windows [19:29] when I check out the branch, that file has 644 permission [19:30] I would like it to have 755 instead, so there must be probably a way to tell bzr that it shall set certain permissions during a commit [19:30] evanton: on windows it's more complicated, since bzr itself doesn't support it [19:30] there is a plugin that can be used to swith the executable flag on windows [19:31] https://launchpad.net/bzr-x-bit [19:31] do you think that chmodding the file in linux and commiting it into the branch from there instead would work? [19:31] evanton: of course [19:32] thank you [19:51] hey would any of the bzr-svn guys be able to look at bug 253376 [19:51] Launchpad bug 253376 in bzr-svn "Crash when network goes down during a checkout" [Undecided,New] https://launchpad.net/bugs/253376 [19:57] rexbron: just replied [19:59] jelmer: As I mentioned, if you remove the dir your checking into and re-run the command, it will pick up where it left off. So it's not that serious. Perhaps it is worth a mention on the bzr-svn known issues section [20:06] rexbron, I think it's worth mentioning, but rather in the bzr docs than in bzr-svn since neither the bug nor the workaround are specific to bzr-svn. [20:06] ok [20:32] jelmer, I'm working on a branch to fix loggerhead's setup, can you take a look at it and see if you need anything changed for Debian? [20:33] lp:~beuno/loggerhead/fix_setup [20:34] beuno, sure, give me a few minutes [20:34] jelmer, thanks :) [21:29] Is there any kind of plugin for bzr that allows you to modify history? Specifically, to change email/names of committers? [21:29] Or perhaps some way to modify check in dates? [21:30] theuiguy: not to my knowledge... modifying history is not really possible in a distributed system. [21:30] You could modify *your* history, but then you don't sync up w/ everyone else. [21:30] which could cause problems. [21:30] NfNitLoop: I see your point... in this particular case, there's only one branch right now [21:31] ah. Well then you could in theory do it, but my guess is that nobody has bothered to write/distribute code to do so for the above reasons. [21:32] theuiguy: there's nothing specifically for it [21:32] there's two things which could, but don't yet, bzr-rebase and fast-export/fast-import [21:32] How about a plugin to merge commits? [21:33] that would probably be the same tool [21:33] james_w: I was thinking bzr-rebase might do something like it, but I thought you needed to do it before your commit [21:34] interactive rebase can do the latter, I don't know if that's available yet though [21:36] Perhaps you could give me an alternative solution -- I'm told I can open source some code, but need to scrub email addresses that expose internal server names. [21:36] It already in bzr, with a relatively short revision history -- I think around 25 revisions. [21:37] I suppose I could just create a new branch with the latest code and go from there, but it's a shame to lose the history [21:39] theuiguy: ok, to change that I would suggest bzr-fast-export and bzr-fastimport. [21:39] you can export to a text file, sed the file to clean up the names as you wish, and then import again [21:39] it should work nicely [21:40] but the new branch will have absolutely no relation to the old one in bzr's eyes [21:40] it sounds like that shouldn't be a problem for you though [21:41] james_w: no, that sounds like it would work... just cleaning up the email addresses would be great. [21:41] Thanks! [21:54] Hi - I'm using the loom plugin to manage one my packaging branch. The HOWTO outlines how-to combine a thread (case where the code has been merged upstream), but I don't get how to delete a thread (the code is no longer relevant because upstream fixed it differently). How do I delete a thread ? [21:55] hey mathiaz [21:55] If I try to combine a thread, it still shows up in the thread above [21:55] james_w: Hi ! :) [21:55] I believe that's the same thing [21:56] you mean the code that you want to get rid of is still in the thread above? [21:56] james_w: I'm working on an openldap merge and the debian maintainer fixed a bug using a different patch [21:56] james_w: yes [21:56] mathiaz: you un merge it [21:56] mathiaz: go to the thread above and do bzr merge -r -1..thread: [21:56] erm no [21:56] go to the thread you want to cancel [21:56] then do that [21:57] lifeless: ok - good to know for the next time. As of now, I've already combine the thread [21:57] lifeless: so I guess I'll have to fix it manually [21:58] you can resurrect the thread I assume [21:58] hey lifeless [21:58] also pushing the branch to LP doesn't work === davi_ is now known as davi [21:59] I get the following message: http://paste.ubuntu.com/32335/ [21:59] hi james_w [22:00] mathiaz: I think that's fixed if you update your loom plugin to a newer version [22:00] james_w: I just did that [22:00] james_w: that's when I started to see that message [22:02] I'm at revision 86 for the loom pluging [22:05] Hi all. A bzr user in my group complains that "annotate" is much slower in 1.6b4 than in 1.5. For his example file it goes from 19 sec to 645 sec. [22:05] which branch format? [22:05] (bzr info) [22:10] ah damn I knew I'd forgotten something; get_matching_blocks acceleration [22:10] chadmiller: I'll whip up a patch today [22:10] lifeless: Cool. Thanks! [22:11] hey jelmer, I have a new problem related to the bug you looked at earlier [22:11] chadmiller: make sure he is running with the C extensions though [22:12] chadmiller: that will still matter even after my patch [22:12] Okay. I will. [22:14] mornings [22:14] goooooooood mornin' mwhudson [22:15] beuno: morning [22:15] beuno: I've been trying to marry the gnome-loggerhead with the new trunk [22:15] hey thumper [22:15] oh, cool, I was going to ping you about that [22:15] beuno: with limited success [22:16] does anyone know what this error means: bzr: ERROR: Invalid url supplied to transport: "Host empty in: http://:8080/" [22:16] thumper, that's odd [22:16] beuno: I might push what I have and get you to look where it's screwing up [22:16] beuno: we have mixed css [22:16] or possibly how to fix it? [22:16] thumper, have you changes anything to it, or is it what I originally pushed? [22:17] beuno: and I was trying to fit some loggerhead tabs into the gnome tab area [22:17] cszikszoy: hi, what command did you run to get that error? [22:17] beuno: there are changes [22:17] beuno: but fairly limited [22:17] thumper, ah, ok. If you can push or give me access to, I can resolve and re-push [22:17] bzr branch lp:do-plugins [22:18] mathiaz: how are you finding using loom for packaging? [22:18] beuno: I'll actually spend some time writing up what has changed as ISTR there was some heading hackery [22:18] cszikszoy: oh, that's odd [22:18] beuno: so you might get something in the next 8 hours [22:18] beuno: but not too soon [22:19] cszikszoy: thats very strange [22:19] james_w: well - up to now, I think it's ok - I classify it as yet-another-patch-system - but I like the merge help [22:19] i thought so too :) [22:19] cszikszoy: it means there is no hosy [22:19] *host* [22:19] james_w: there are still some rough edges (such as unable to push to lp) [22:19] thumper, cool. Another thing you may want to try, is start from the gnome branch I pushed with the new theme, and merge into that one [22:19] james_w: and I've just figured out how to delete a patch rather than combine it [22:20] mathiaz: that's true, I guess it is another patch system, but hopefully a better one. [22:20] james_w: hopefully there will such a command added to the loom plugin soon [22:20] * thumper nods to what beuno says [22:20] hmm, i'm having problems with converting a cvs repo (cvsps) with filenames in latin1 encoding :/ [22:20] mathiaz: would you file a bug for that command? [22:20] james_w: it seems that the difference comes with the merging support [22:20]