[00:09] mhall119: yes, '-- -k' [00:09] (can also be set in an env variable; this is actually just passed through to dpkg-buildpackage in both cases, bzr doesn't use it) [00:10] hi slangasek [00:18] poolie: hey there [00:19] so I have a fun challenge for someone here :) [00:19] :) [00:21] Linux-PAM upstream recently migrated their VCS from CVS to git [00:21] and I had a full import of the CVS history into my bzr... [00:21] and now I need to make bzr believe that the git history is the same [00:21] how do I do that? ;) [00:22] that's the parallel import problem again :-/ [00:23] so, what solutions have you guys come up with? :) [00:26] doesn't have to be particularly automated; I'm willing to do some grunt work here for a one-time fix-up [00:27] but I'd prefer not to do this as a rebase, since there are plenty of merge points in the history which I guess would make that painful [00:32] hm [00:32] so you have a lot of packaging branches, or other branches, based off that their previous import? [00:33] thanks for fixing all the import branches, and for the sru, jelmer [00:33] and for denting about it, for that matter [00:33] poolie: a fair number of branches, yes [00:34] the pragmatic thing now would probably be to rebase them [00:34] itcould be nice to have a way to tell it to treat some revisions as aliases for others [00:35] perhaps, rebase them, and file bugs about any aspects of rebasing that don't work well [00:38] not having used it before, I'm nervous about what bzr rebase is going to do with these branches that have been repeatedly merged from upstream [00:38] but I'll give it a go and see what happens [00:38] i'd find it useful to at least know what happens [00:39] generally speaking the parallel import problem jelmer grimaced at is something we will improve in future releases [03:49] poolie: so, I can't get bzr rebase to do anything useful :) [03:50] it either gives me "Branches have no common ancestor, and no merge base revision was specified", or "Base branch is descendant of current branch. Pulling instead" depending on how I misuse it :) [04:05] slangasek: you may find replay is better [04:06] not so far as I've been able to understand it so far [04:06] bzr's rebase is a bit tightly coupled to the idea of resetting an in-progress branch [04:08] replay just gives me a glorious number of conflicts [04:11] lifeless: my branch history starts with the CVS-imported upstream branch, branches from that to add the packaging branch, and repeatedly merges the upstream branch into the package branch over time. What commands should I be using to get the replay I want? [04:12] something like replaying your first interesting commit on the matching commit from the git imported branch [04:12] sadly hwat you want to do is not well supported yet [04:14] my first interesting commit also happens to be a merge resulting from 'bzr join' of the upstream CVS repo with my svn package history ;) [04:15] so when I do 'bzr replay -r694 ../pam.debian' and get a bunch of conflicts for all the upstream files, is that expected, or is that a sign I'm running the wrong command? [04:21] Path conflict: / debian [04:21] that one seems non-negotiable [04:21] I suppose I might be able to redo the join [04:32] lifeless: given that I know I have a 1:1 correlation between git revisions and bzr revisions, is there any way to directly rewrite the revision ids? [04:42] slangasek: yeah, read them in, change them, write them out - which is what bzr-rewrites commands provide *an* interface to [04:42] the problem is getting to do what you want [04:42] slangasek: I don't have an easy canned recipe for you though [04:43] how about pointers to the right documentation to the part of the bzr internals I need to be hooking into? :) [04:43] that's got to be a better use of my time than trying to manually resolve merge conflicts for every file in the tree [04:44] you might be able to use fast-import and some sed to translate the imported-from-cvs revision id to the imported from git revision ids? [04:44] would be horrible and fragile, but might work [04:44] so in theory generating an appropriate rewrite map for bzr-rewrite [04:45] and using that from its library would DTRT [04:45] bzr-rewrite started life as a revisionid-rewriter for bzr-svn [04:46] ah right, i guess that's a more tasteful way of achieving the same end [04:47] * slangasek nods and has a look [04:47] thanks :) [04:48] the frustrating thing about bzr-rebase is its -so close- and yet so far [07:27] hi vila? [07:28] vila, it would be great if there was a test fixture that set one config variable just temporarily [07:28] or a context manager [07:29] or is there such a thing? [07:59] poolie: hi [07:59] hey there [07:59] i'm just finishing 220464 [07:59] hmm [07:59] i'm going to just turn that behaviour off by default [07:59] first thing that comes to mind is: one config variable in *which* context ? [07:59] well, that's a good question [08:00] for my purposes, i just need something that will be seen by the code under test [08:00] that's a good answer :) [08:00] it looks like i can just modify GlobalConfig because that's already isolated [08:00] hmm [08:01] if that fits your needs, go for it [08:01] My gut feeling is that this may break in edge cases (intersection between where the option can be declared and its default value) but nothing really serious [08:02] i.e. I doubt we encounter cases where an option *cannot* be set in GlobalConfig [08:02] my other question was whether the option registry type thing is landed [08:02] i could just look :) [08:03] yes [08:03] err [08:03] yes it has landed [08:03] not yes you can look :) [08:05] ok [08:06] perhaps since this is already so big i should do that in a follow on [08:07] are we going with a style like 'bzrlib.lockdir.break' or 'locks.break'? [08:07] i might have argued for the former but for something people have to type it now seems too long [08:08] i like the second though, because it will group things together [08:08] same here, I think I summarized that in devnotes after jelmer's review [08:09] eseentially it goes one step further by removing 'bzr.' for options everybody share and leave plugins decide to prefix with their name if/when needed [08:10] wfm [08:11] my initial goal was to clearly tear the various name spaces apart but in retrospect that was too much [08:11] collisions are guarded by the registry so we are pretty safe [08:17] so i could move the documentation and the default into the registry? [08:18] yes. If you want the default value to be taken into account, you need to use GlobalStack, not GolbalConfig though [08:18] fixing tyops of course ;) [08:19] hmm [08:20] depending on whether your tests inherit from TestCase or TestCaseWithTransport you can even use _load_from_string for the former but that's maybe the fixture you're after ? [08:22] ok, so i've made the option off [08:22] i might send it in [08:31] jelmer: First time I've ever seen "review needsfixing" and "merge approve" used together! :-) [08:32] morning all [08:32] news-file merge doesn't seem really to be working on pqm [08:32] hi max, jelmer [08:33] vila, ok, sent [08:33] and, i think that's it for me for now [08:34] Hi poolie. Thanks for the udd reviews. Are you happy for me to land them, though you didn't toggle the MP status as well as commenting? [08:34] poolie: \o/ [08:34] poolie: enjoy your week-end [08:35] max, yes [08:36] poolie: I'm pretty sure it isn't configured in pqm since we moved to the new layout [08:36] (news-file merge) [08:37] poolie: the news conflicts I've seen recently strongly hint that indeed it's not configured properly [08:38] spiv knows better and commented that something weird was going on there as he didn't manage to make it work with losas (with weird == *I* don't remember/understand the details) === hunger_ is now known as hunger [09:50] mgz: ping [09:56] vila: I think the main issue is that news-merge is configured to merge NEWS and not "bzr-2.2.txt bzr-2.3.txt, etc." [09:57] really ? It's *that* simple ? That would be nice and be easy to fix then [09:58] vila: I don't know 100%, but that is at least a start [09:59] jam: juggling eggs right now, could you check with a losa ? [11:22] hi all! [11:22] i'm pretty sure there's at least one bug with a shared repo and several processes branching a RepositoryFormatKnitPack1 into it [11:23] (e.g. what you'd typically do for a jenkins setup of having the /jenkins working dir be a bzr repo) [11:31] stewart: so report a bug? [11:31] Riddell, yeah, i should really do that :) [11:31] Riddell, i'm also going to upgrade the repository formats of those branches, and that'll certainly fix it [11:48] hi, are new bugs forwarded to this channel? [11:50] Kamping_Kaiser: no but they get triaged by bazaar developers === CardinalFang__ is now known as CardinalFang [11:52] Riddell: thanks. i wont expect to see it here when i report it then :) [11:52] canonicalers: what shall I do about bug 777507 ? it's a problem in qbzr in maverick, the fix is already backported to qbzr/0.19 branch [11:52] Error: Launchpad bug 777507 could not be found [11:53] so I guess the resolution is either to do an SRU or just tell the guy to checkout the branch and use that [11:54] I'm not sure why this bug is marked private, there doesn't seem to be anything very private about it, but he seems to have done so explicitly [11:58] jam: thanks for the reviews, can you look at https://code.launchpad.net/~gagern/bzr/bug112390-kind-marker-optional/+merge/63080 again now that Martin answered your previous review ? [11:58] Ubuntu bug 63080 in linux-source-2.6.22 (Ubuntu) "snd-intel-hda requires options to work on AD1986A" [Undecided,Won't fix] [11:59] good bot, but no sugar :) [12:17] while bzr import-dsc is running, where is the import cache stored? ( i assume ther is one). i'm waiting for linux-2.6 to import an its taking its sweet time. [12:17] on the subject of speed, does anyone else have speed issues trying to tab complete import-dsc? i have a 4-5second lag from hitting tab to the complete happening [12:23] stewart: yes, there is [12:24] stewart: https://bugs.launchpad.net/bzr/+bug/709349 [12:24] Ubuntu bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [High,In progress] [12:24] stewart: The Twisted buildbot has encountered the same problem(s). [12:28] hi all. bzr import-dsc has failed, claiming to be out of disk. but its on a filesysem with 91GB free. http://paste.debian.net/119421/ is the output. i'm running again with --verbose atm [12:28] Kamping_Kaiser: what about /tmp ? [12:33] vila: 1.4gb untill this filled it. i'll clear it out and try again [12:33] (its a tempfs) [12:33] Kamping_Kaiser: right, probably where the problem is coming from then [12:34] Kamping_Kaiser: overriding TMP (or TMPDIR ?) may address the issue for this command [12:37] vila: i'l try them out, thanks [12:38] Kamping_Kaiser: if import-dsc doesn't respect them, it may be worth filing a bug (your use case is damn valid), I don't know the implementation well enough to say [12:40] vila: it takes 15-20 min to fail, so i'll tinker with those variables and let you know how i get on [12:40] maybe tomorrow :/ [12:41] Kamping_Kaiser: you mean filing the bug or re-trying with the variables ? [12:41] vila: re-trying with teh variables [12:41] k [12:42] i tried to patebin the failing run, but pastebin won't take > 90KB of text (scary, i didn't think it was that big) [12:42] !paste [12:42] 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. [12:42] That paste ? [12:43] it was paste.debian.net, i can try that one if you'd like [12:43] If you intend to re-run tomorrow, try this one if you think it may help confirm/infirm TMP support, otherwise better wait [12:46] ubuntu paste accepted it... all 18000 lines. http://paste.ubuntu.com/623335/ [12:47] anyway. i'll let you know how hte others go. thanks again for your help vila [12:49] good paste site ;) But yeah, no way be conclusive about TMP support without either trying or reading the source :-/ [13:02] definitely disk space, failed at a later point that time. now trying with TMP="~/bzr-temp" [13:08] Riddell, hi [13:09] Riddell, in ~jr/bzr-explorer/unstable you seem to have updated the version string but not merged in a new version [13:09] Kamping_Kaiser: gee, tomorrow already ? Your days are short :) [13:15] vila: very fast clocks [13:15] ha, I see, one more overclocking freak :) [13:16] hehe [13:16] back in the day *reminices* === medberry is now known as med_out [13:37] vila: \o/ TMP worked, sans a directory creation bug [13:37] vila: you are a god among men :D [13:38] just lucky ;) And owing to our elders defining TMP... ;) [13:39] :) [13:46] Hello, I am Yonggang Luo [13:46] Calling for Jelmer Vernooij [13:47] hi [13:47] dreamkxd, that's me [13:47] OK, do you see my comments? [13:48] OK, I explain my idea again, [13:48] Suppose trunk is the first directory we created, we called it the start folder, named with "default" [13:49] dreamkxd, yeah, replying now [13:49] We know under svn, there is an copy operating. we can using it to tracking new branches, and new tags. [13:50] almost every tags and branches is created like this, if it's not, we can using config file to show that. [13:50] After this, we have some rules. [13:51] 1.if directory A copied from directory B, and B is an existed branch or tag, then A is an branch or tag, this is the most frequently condition [13:51] dreamkxd, how do you know which folder is the "default" folder? [13:52] dreamkxd, also, this requires looking at the entire history. Some repository have over 1 million revisions [13:52] Yes, we suppose trunk is the default folder. [13:53] Yes, but that's worth, we only convert it one time, and that's necessary, compare to the fact time about converting the content, the revision log is much more quicker [13:54] So we just ignore the speed problem first:) we won't converting the whole repo day by day:) we need suffer one time:) [13:54] dreamkxd: at least for the default behaviour, O(history) is unacceptable [13:54] dreamkxd: what about situations where the original trunk was removed and a new trunk is created? [13:54] dreamkxd: also, are there any situations you've found where the existing behaviour doesn't work? [13:55] Indeed, I think the current bzr-svn is not as fast as we think, at least at the last time when I using bzr-svn import llvm, it's struggled:( [13:55] dreamkxd, in other words, what's the problem you're trying to fix? [13:55] dreamkxd: That's not a good reason to make it even slower though.. :) [13:55] Now, It's will getting it's faster, [13:56] indeed, i've ever using hgsubversion to convert llvm, and it's OK, at least on the time:) [13:56] but bzr-svn toggled.... [13:56] dreamkxd, have you tried bzr-svn trunk? launchpad doesn't seem to have problems with llvm and it worked fine on my machine too [13:56] you means bzr svn-import ?.... [13:57] jelmer: my main concern with that bzr-explorer packaging branch was to update the bzr dependency, but I could do the package update too [13:57] Riddell: is the new dependency only since bzr-explorer 1.3.0? [13:58] What's your command, I may have an try:) Anyway, llvm is complicated, I don't think at the current stage, bzr-svn will convert it well.. [13:58] Well, I am not meas only import the trunk.... but also retains the branches and tags informations.... [13:59] dreamkxd: Have you tried? I don't see anything in the repository that could confuse bzr-svn [13:59] Err.... [13:59] dreamkxd: "bzr svn-import http://llvm.org/svn/llvm-project/llvm/" is what I would try [13:59] or http://llvm.org/svn/llvm-project/llvm/trunk [13:59] I mean "bzr branch http://llvm.org/svn/llvm-project/llvm/trunk" [13:59] Yes, that's what I was tried.. [14:00] dreamkxd: did that create incorrect branches? [14:00] bzr svn-import http://llvm.org/svn/llvm-project/llvm/ that's I wanted. [14:00] So, can you give me an list of branches?... [14:01] Then I can tell you what's lost. [14:01] Because I was failed:( [14:01] dreamkxd: Sorry, can you be more specific? How did it fail? [14:02] what was missing? [14:02] It's running for an long time, about 8 hours, I didn't finished it, and then I closed it.... [14:03] vila: pong [14:03] OK, I'll try it again, now I was using subvertpy 0.8.1 and tip of bzr-svn and stable bzr 2.3.3 [14:03] * vila swaps in . o O (What was it ?) [14:04] eheh [14:04] mgz: oh yeah, about leaks, I kind of lost track about what I should ping you what, is it the cleanup hook stuff [14:04] that's the bad thing about pings vs just saying what you were thinking of [14:04] right, I need to track down a bug, then I think I can just propose [14:05] mgz: about this specific topic, since you started by trying to fix a bad cleanup, how about just talking with jelmer about it ? [14:05] BTW, I think the old way of bzr-svn is still O(history) D:\CI\bld\brepo>bzr svn-import svn://localhost/llvm/ Using repository layout: trunk1 2084kB 44kB/s | copying revision 304/130322 [14:05] mgz: a better test coverage can come later [14:05] ah, that's a different one. I did bug jelmer a bit about it. [14:05] Well, we'd better using gtalk,, freenode is not suite for long conversation.... [14:05] dreamkxd, not when finding the layout [14:05] mgz: ha, right, he's busy right now :) [14:06] dreamkxd: it is. and the logs are archived which is better for our collective unconscious :) [14:07] vila: I think you mean it's not.. at least, my gtalk logs aren't accessible by anyone but me :) [14:07] jelmer: hehe, I meant freenode is suited :) [14:07] Er, my input box only one line,sign.... [14:08] Is there any freenode client?.... [14:08] dreamkxd: what are you using ? [14:08] Chrome ,,, http://webchat.freenode.net/ [14:08] sign.... [14:08] dreamkxd: oh, webchat, which OS ? [14:10] Chrome 12, under WinOS. [14:10] def find_branchpaths(self, layout, from_revnum, to_revnum, project=None): [14:10] This function is O(history) time... [14:11] If I wan't to using the history, I need to do something here. [14:11] 23369kB 56kB/s / copying revision 4776/130322 [14:11] dreamkxd, that function is used in a specific codepath which only kicks in if there are bzr-svn file properties in the repository [14:11] that's my progress. [14:12] dreamkxd, that's while copying the revisions; I'm all for making that faster, but I don't see what it's got to do with the repository layout stuff.. [14:12] e....OK. [14:16] 2.if directory A copied from directory B, and there eixst an branch or B/X that under directory B, then we have an new branch or tag A/X [14:16] 1.if directory A copied from directory B, and B is an existed branch or tag, then A is an branch or tag [14:17] vila, thanks for your reviews. [14:17] 3.ignore the branches that comes from outsite [14:18] That's all... [14:18] vila: re: new_ids / changed_ids, we care about files whose inventory entries have changed, but a transform could remove the old file_id, and then restore the same file_id, and then we shouldn't care about it. [14:18] abentley: thanks for the hard work, impressive, hope you don't mind adding comments, they cruelly lack [14:19] err, crossed on the wire, was replying to your first comment [14:19] vila: I do mind adding comments. Comments get stale. The code should be clear enough by itself, and if it's not, it should be made clearer. [14:19] example :cfe/branches/cfe-1203/tools/llvm copied from llvm/trunk then tools/llvm should not be an branch, and also those files should not be contained in cfe? [14:19] abentley: well, that's a shame then, because you modified code without modifying comments [14:20] vila: Like I said, comments get stale. [14:20] ... [14:20] Is there question? [14:21] vila: so it's better not to need any. [14:21] abentley: in an ideal world, sure [14:21] and even there I strongly doubt comments are useless [14:21] dreamkxd: I'm not following, you're proposing creating branch on whether they were derived from the original trunk branch right? [14:22] Now only derived from original trunk branch, but also derived from other already existed branches.. [14:22] abentley: comments are for readers, you can't argue that reading one method gives enough contexts to understand it however perfect the code is [14:23] vila: I certainly can. [14:23] It'slike an set, we inserting element into it, and delete element from it. [14:23] dreamkxd, see http://pastebin.ubuntu.com/623402/ [14:23] abentley: why bother writing cover letters then ? [14:23] vila: And if it doesn't, it's badly written. [14:23] vila: To express motivation. [14:23] dreamkxd: I'd like to discuss the problem first before discussing the solution - what's the problem you're trying to solve, can you give an example of a repository that breaks? [14:23] llvm/branches/Apple [14:23] abentley: pff, your code doesn't express motivation ? [14:24] That's the problem, under Apple, there is a lot branches.. [14:24] Apple is not an branch, but an branch container:) [14:24] vila: my code doesn't express motivation for the change I propose, it expresses motivation of the changed version. [14:24] http://pastebin.ubuntu.com/623402/ [14:24] http://llvm.org/svn/llvm-project/llvm/branches/Apple/ [14:25] And in this repo, there is other kinds of examples:) [14:26] such as http://llvm.org/svn/llvm-project/cfe/branches/Apple/whitney-IB/src/tools/ [14:26] The path http://llvm.org/svn/llvm-project/cfe/branches/Apple/whitney-IB is an branch of llvm [14:26] but the path http://llvm.org/svn/llvm-project/cfe/branches/Apple/whitney-IB/src/tools/clang/ is an branch of cfe. [14:27] These problems is what I want to solved. [14:27] abentley: right, this discussion is useless then, you won't convince me that comments aren't needed especially in in an read where so many of us could't understand the code motivation without comments, feel free to start a discussion on the mailing list [14:27] dreamkxd: Ah, ok. That makes sense [14:27] abentley: if you disagree with the comments I proposed, explain why [14:27] vila: We are getting off track, because I have a different coding philosophy than you, and "cruelly lack" was too strong for me to let it pass. [14:27] abentley: if you think you can do that with only code, great [14:28] vila: I can tell you that "Summarize all changes to the inventory" is less accurate than "Get the trans_ids and paths of files needing new inv entries." [14:28] Now, I have already got an peace of python code implement the following functions. [14:29] dreamkxd: You should be able to create a custom layout class with a custom "layout guess" function to see if your approach will work better [14:29] Yes, I wan't to do that.. [14:29] But I need to access to the history:) [14:30] dreamkxd: You should be able to create your layout in repository_guess_layout() and pass in the logwalker there [14:30] And now I've toggle where to get the log into it... [14:31] abentley: "cruelly lack" is how I view the actual state, I consider that this code has been written by the bzr team, I don't throw stones at you, I want to make it easier to understand for mere mortals which may not be part of this team and lack the background (also in this case, I lack a lot of background) [14:33] I won't even pretend (and I said so) that my *proposed* comments are accurate or complete [14:33] vila: If you'd phrased it less aggressively, I'd have accepted those changes that are accurate and we probably wouldn't be having this discussion. === zyga is now known as zyga-food [14:36] but I wasn't aggressive damn it ! I felt that this method was important and there is *no* comments there in trunk. [14:36] How is it said in English ? [14:37] vila: "cruel" is an emotionally intense word. If you use it about someone else's work, you are likely to get a reaction like mine. === maxb changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failures: 486 [14:38] vila: You say "I think this method should have comments because it is important" in English. [14:38] Well, is there anyway to specify the layout you want to use? [14:38] But why did you take for you when I was saying that the lack of comments was cruel for *me* ? [14:39] dreamkxd: It's an option to "bzr svn-import", or you can set it in your bzr configuration ("layout = trunk1") [14:39] abentley: right, thanks for the correction, but next time ask me what I mean if you think I'm aggressing or insulting you. WHy on earth would I do that ? [14:39] abentley: especially when I said great job ? [14:40] If the lack of comments was cruel to you, then I was being cruel to you. [14:40] bzr svn-import layout=trunk1? [14:40] dreamkxd: bzr svn-import --layout=trunk1 [14:40] abentley: these two reviews were some of the most interesting I did lately and required me to think hard and try various tricks to understand what was happening [14:41] abentley: I felt I couldn't write the comments myself, gave it a try and ask you to polish them [14:41] OK, thanks, well is there any way that I need not build and install bzr-svn and then using of it? [14:41] abentley: and roughly your reply was: comments are useless, if you can't understand the code, you're an idiot [14:42] vila: Okay, let's stipulate for now that the right approach is to add comments rather than clarifying the code. [14:42] vila: No, my response is that if you can't understand the code, the code isn't clear enough. [14:43] dreamkxd: If you have the plugin installed in your home directory you can modify it there directly [14:43] " The code should be clear enough by itself, and if it's not, it should be made clearer" [14:43] dreamkxd, alternatively, you can set the BZR_PLUGINS_AT environment variable to point at the location where the plugin is [14:44] Well, if I directly copy the bzr-svn folder into bzrlib plugin folder, will that working?... [14:44] dreamkxd, that should work too [14:44] abentley: well, both are valuable, I share the value that code should be crystal clear but... well, we're just humans for once and then there are cases where comments are just easier to explain either why *this* implementation is better than others or just give some context without requiring the reader to load the whole problem/solution in his head [14:44] Ok, thanks... [14:45] My bzr-svn playground is https://code.launchpad.net/~luoyonggang/bzr-svn/perfect-layout .. I will commit to there first, it's it's stable enough, I'll request for merge:) [14:46] vila: let's stipulate that adding comments is the right approach for this code, and talk about the comments themselves. [14:46] abentley: also, the clearest code sometimes is just not obvious and adding comments makes it easy to read again [14:46] abentley: great [14:47] vila: I don't understand the motivation for the docstring changes to _inventory_altered. Could you explain that? [14:47] abentley: It's unclear to me what part of the transformations are captured here [14:48] abentley: are they all ? If not which ones are and which aren't ? [14:48] All trans_ids that need an inventory entry change are there. [14:50] abentley: Imagine I have no idea about which transformations requires an inventory change [14:51] I was already do this layout_registry.register_lazy("perfect", "bzrlib.plugins.svn.layout.perfect", "PerfectLayout") [14:51] vila: there are two possible answers. Either we should document every kind of change that requires an inventory update, or we should say that is prerequisite knowledge for working on this code. [14:51] abentley: also, one of my hesitations was 'new' in 'needing new inv entries'. Is it new as in needs to be created or new as in needs to be updated [14:52] abentley: well, the idea is to help people *get* this pre-requisite knowledge [14:52] so probably something between the two [14:53] vila: The knowledge is not particular to TreeTransforms, however. It's about knowing what an inventory entry reflects. [14:53] true, we don't want a full book either :) [14:54] vila: In any case "Summarize all changes to the inventory." seems false, since we're not returning any information about the inventory itself. [14:54] dreamkxd: That wouldn't really help in this case - I think you want to change repository_guess_layout as that's a location where you actually have access to the layout [14:54] s/to the layout/to the history/ [14:54] vila: It's not a summary, it's just a list of paths and trans_ids. [14:55] abentley: sure, this was more a placeholder [14:55] but list of paths and trans_ids doesn't tell me much about what they represent [14:55] You means directly create CustomLayout under function repository_guess_layout? [14:56] vila: I don't know what you mean by "represent". If you mean you don't know what a trans_id represents, that is definitely prerequisite knowledge for TreeTransform. [14:56] such as return CustomLayout (repository._log) [14:56] dreamkxd: I think you mean PerfectLayout rather than CustomLayout? [14:56] Yes, PerfectLayout [14:56] dreamkxd, Also, presumably all the analysis would happen there, and you wouldn't need to access the history again after that [14:57] no, I have an imcomplete understanding of what a trans_id is, I'm talking about the whole list with respect to the current transformations [14:57] how come requeue_package.py doesn't work for me on jubany? http://paste.kde.org/80443/ [14:57] But, I need all history ..., did logwalker_guess_layout will iterate the whole history? [14:58] vila: so by "represent", you really mean "why would a trans_id be included in this list"? [14:58] abentley: if the inline comments are valid they defines that. I don't know if there is a good way to capture that [14:58] yup [14:58] dreamkxd, well, that's what you intended right? === zyga-food is now known as zyga [15:00] abentley: when you don't know TT, it's not obvious to translate: _removed_contents means deleting and/or unversioning for example (may be not the best one other attributes are needed to get the full answer but... well) [15:01] Yes, that's I wanted, I need to iterate every revision's log, and If I there is no cache, every time running bzr svn-import, I need to iterate on SVN log, if there is cache, then I only need to iterate when guess, but after guess, if new revisions appeared, I also need to iterate on it:) [15:01] That's means, I need iterate EVERY svn revision LOG at least ONE time. [15:03] dreamkxd: I guess another thing you could do is in Repository.get_layout() check for a config variable [15:03] dreamkxd, and if that variable is set, return PerfectLayout(self._log) [15:03] abentley: yet another way to think about it: Imagine someone not knowing TT at all and encountering _inventory_altered for the first time. What will help him understand the code without giving imprecise and hard to maintain hints ? [15:03] And remove the statement layout_registry.register_lazy("perfect", "bzrlib.plugins.svn.layout.perfect", 310 "PerfectLayout") ? [15:04] dreamkxd, yes [15:04] abentley: and yes, this may require other knowledge not explained here, but that doesn't mean good hints can't be provided [15:04] vila: it feels like an extremely high burden of documentation. [15:04] vila: like a manual for laymen for doing heart surgery. [15:05] hehe [15:05] not at all [15:05] OK, I see, I think my proposition can not be guess:) so just direct using of it:) [15:05] I wrote the proposed ones quite quickly and I'm sure you can fix/complete them without spending hours on them [15:05] No, really, it does. I expect people who hack on TT to know what _removed_contents is. [15:06] _removed_contents is documented, and I'll happily improve the documentation if needed. [15:09] what are you aiming for ? [15:09] Convince me that all my proposed comments are not needed ? [15:10] vila: sorry. I am reacting to your suggestion "Imagine someone not knowing TT at all...". [15:11] Sorry, I don't know how to express that in English as well as I can do it in French :-( [15:12] Assume I agree with you about TT (as all code) requiring )some* pre-requisite but that I disagree about where to stop/start commenting ? And that I'm searching a middle ground [15:14] Comments can be as hard to write as code (IMHO), I try to write them as a way to facilitate the code *reading* (as opposed to understanding) [15:14] vila: What do you think of this as a docstring: http://pastebin.ubuntu.com/623446/ [15:15] The former occurs more often than the later as you can read code without understanding it most of the time [15:15] abentley: +1 +1 === vednis is now known as mars [15:21] abentley: so, when is the filtering needed in: + changed_id = set(t for t in self._new_id [15:21] + if self._new_id[t] != self.tree_file_id(t)) [15:22] abentley: I mean, I can see that if the id is the same it's not changed, but when is it needed ? [15:23] vila: The filtering is so that we don't return spurious entries, and do more work than needed to update the tree. [15:24] but which entries are spurious ? [15:24] hi [15:24] vila: entries where the file id was deleted, and then restored to the original value. [15:24] does anyone have any idea why bazaar stops downloading files at 59%? [15:25] abentley: wow, *that* is what I'd like to find in the comment because it will take a long time to find it otherwise [15:25]