| slangasek | mhall119: yes, '-- -k<keyid>' | 00:09 |
|---|---|---|
| slangasek | (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:09 |
| poolie | hi slangasek | 00:10 |
| slangasek | poolie: hey there | 00:18 |
| slangasek | so I have a fun challenge for someone here :) | 00:19 |
| poolie | :) | 00:19 |
| slangasek | Linux-PAM upstream recently migrated their VCS from CVS to git | 00:21 |
| slangasek | and I had a full import of the CVS history into my bzr... | 00:21 |
| slangasek | and now I need to make bzr believe that the git history is the same | 00:21 |
| slangasek | how do I do that? ;) | 00:21 |
| jelmer | that's the parallel import problem again :-/ | 00:22 |
| slangasek | so, what solutions have you guys come up with? :) | 00:23 |
| slangasek | doesn't have to be particularly automated; I'm willing to do some grunt work here for a one-time fix-up | 00:26 |
| slangasek | 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:27 |
| poolie | hm | 00:32 |
| poolie | so you have a lot of packaging branches, or other branches, based off that their previous import? | 00:32 |
| poolie | thanks for fixing all the import branches, and for the sru, jelmer | 00:33 |
| poolie | and for denting about it, for that matter | 00:33 |
| slangasek | poolie: a fair number of branches, yes | 00:33 |
| poolie | the pragmatic thing now would probably be to rebase them | 00:34 |
| poolie | itcould be nice to have a way to tell it to treat some revisions as aliases for others | 00:34 |
| poolie | perhaps, rebase them, and file bugs about any aspects of rebasing that don't work well | 00:35 |
| slangasek | 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 |
| slangasek | but I'll give it a go and see what happens | 00:38 |
| poolie | i'd find it useful to at least know what happens | 00:38 |
| poolie | generally speaking the parallel import problem jelmer grimaced at is something we will improve in future releases | 00:39 |
| slangasek | poolie: so, I can't get bzr rebase to do anything useful :) | 03:49 |
| slangasek | 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 :) | 03:50 |
| lifeless | slangasek: you may find replay is better | 04:05 |
| slangasek | not so far as I've been able to understand it so far | 04:06 |
| lifeless | bzr's rebase is a bit tightly coupled to the idea of resetting an in-progress branch | 04:06 |
| slangasek | replay just gives me a glorious number of conflicts | 04:08 |
| slangasek | 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:11 |
| lifeless | something like replaying your first interesting commit on the matching commit from the git imported branch | 04:12 |
| lifeless | sadly hwat you want to do is not well supported yet | 04:12 |
| slangasek | 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:14 |
| slangasek | 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:15 |
| slangasek | Path conflict: <deleted> / debian | 04:21 |
| slangasek | that one seems non-negotiable | 04:21 |
| slangasek | I suppose I might be able to redo the join | 04:21 |
| slangasek | 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:32 |
| lifeless | slangasek: yeah, read them in, change them, write them out - which is what bzr-rewrites commands provide *an* interface to | 04:42 |
| lifeless | the problem is getting to do what you want | 04:42 |
| lifeless | slangasek: I don't have an easy canned recipe for you though | 04:42 |
| slangasek | how about pointers to the right documentation to the part of the bzr internals I need to be hooking into? :) | 04:43 |
| slangasek | 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:43 |
| mwhudson | 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 |
| mwhudson | would be horrible and fragile, but might work | 04:44 |
| lifeless | so in theory generating an appropriate rewrite map for bzr-rewrite | 04:44 |
| lifeless | and using that from its library would DTRT | 04:45 |
| lifeless | bzr-rewrite started life as a revisionid-rewriter for bzr-svn | 04:45 |
| mwhudson | ah right, i guess that's a more tasteful way of achieving the same end | 04:46 |
| * slangasek nods and has a look | 04:47 | |
| slangasek | thanks :) | 04:47 |
| lifeless | the frustrating thing about bzr-rebase is its -so close- and yet so far | 04:48 |
| poolie | hi vila? | 07:27 |
| poolie | vila, it would be great if there was a test fixture that set one config variable just temporarily | 07:28 |
| poolie | or a context manager | 07:28 |
| poolie | or is there such a thing? | 07:29 |
| vila | poolie: hi | 07:59 |
| poolie | hey there | 07:59 |
| poolie | i'm just finishing 220464 | 07:59 |
| vila | hmm | 07:59 |
| poolie | i'm going to just turn that behaviour off by default | 07:59 |
| vila | first thing that comes to mind is: one config variable in *which* context ? | 07:59 |
| poolie | well, that's a good question | 07:59 |
| poolie | for my purposes, i just need something that will be seen by the code under test | 08:00 |
| vila | that's a good answer :) | 08:00 |
| poolie | it looks like i can just modify GlobalConfig because that's already isolated | 08:00 |
| vila | hmm | 08:00 |
| vila | if that fits your needs, go for it | 08:01 |
| vila | 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:01 |
| vila | i.e. I doubt we encounter cases where an option *cannot* be set in GlobalConfig | 08:02 |
| poolie | my other question was whether the option registry type thing is landed | 08:02 |
| poolie | i could just look :) | 08:02 |
| vila | yes | 08:03 |
| vila | err | 08:03 |
| vila | yes it has landed | 08:03 |
| vila | not yes you can look :) | 08:03 |
| poolie | ok | 08:05 |
| poolie | perhaps since this is already so big i should do that in a follow on | 08:06 |
| poolie | are we going with a style like 'bzrlib.lockdir.break' or 'locks.break'? | 08:07 |
| poolie | i might have argued for the former but for something people have to type it now seems too long | 08:07 |
| poolie | i like the second though, because it will group things together | 08:08 |
| vila | same here, I think I summarized that in devnotes after jelmer's review | 08:08 |
| vila | 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:09 |
| poolie | wfm | 08:10 |
| vila | my initial goal was to clearly tear the various name spaces apart but in retrospect that was too much | 08:11 |
| vila | collisions are guarded by the registry so we are pretty safe | 08:11 |
| poolie | so i could move the documentation and the default into the registry? | 08:17 |
| vila | yes. If you want the default value to be taken into account, you need to use GlobalStack, not GolbalConfig though | 08:18 |
| vila | fixing tyops of course ;) | 08:18 |
| vila | hmm | 08:19 |
| vila | 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:20 |
| poolie | ok, so i've made the option off | 08:22 |
| poolie | i might send it in | 08:22 |
| maxb | jelmer: First time I've ever seen "review needsfixing" and "merge approve" used together! :-) | 08:31 |
| jam | morning all | 08:32 |
| poolie | news-file merge doesn't seem really to be working on pqm | 08:32 |
| poolie | hi max, jelmer | 08:32 |
| poolie | vila, ok, sent | 08:33 |
| poolie | and, i think that's it for me for now | 08:33 |
| maxb | 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 |
| vila | poolie: \o/ | 08:34 |
| vila | poolie: enjoy your week-end | 08:34 |
| poolie | max, yes | 08:35 |
| jam | poolie: I'm pretty sure it isn't configured in pqm since we moved to the new layout | 08:36 |
| jam | (news-file merge) | 08:36 |
| vila | poolie: the news conflicts I've seen recently strongly hint that indeed it's not configured properly | 08:37 |
| vila | 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) | 08:38 |
| === hunger_ is now known as hunger | ||
| vila | mgz: ping | 09:50 |
| jam | 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:56 |
| vila | really ? It's *that* simple ? That would be nice and be easy to fix then | 09:57 |
| jam | vila: I don't know 100%, but that is at least a start | 09:58 |
| vila | jam: juggling eggs right now, could you check with a losa ? | 09:59 |
| stewart | hi all! | 11:22 |
| stewart | i'm pretty sure there's at least one bug with a shared repo and several processes branching a RepositoryFormatKnitPack1 into it | 11:22 |
| stewart | (e.g. what you'd typically do for a jenkins setup of having the /jenkins working dir be a bzr repo) | 11:23 |
| Riddell | stewart: so report a bug? | 11:31 |
| stewart | Riddell, yeah, i should really do that :) | 11:31 |
| stewart | Riddell, i'm also going to upgrade the repository formats of those branches, and that'll certainly fix it | 11:31 |
| Kamping_Kaiser | hi, are new bugs forwarded to this channel? | 11:48 |
| Riddell | Kamping_Kaiser: no but they get triaged by bazaar developers | 11:50 |
| === CardinalFang__ is now known as CardinalFang | ||
| Kamping_Kaiser | Riddell: thanks. i wont expect to see it here when i report it then :) | 11:52 |
| Riddell | 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 |
| ubot5 | Error: Launchpad bug 777507 could not be found | 11:52 |
| Riddell | so I guess the resolution is either to do an SRU or just tell the guy to checkout the branch and use that | 11:53 |
| Riddell | 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:54 |
| vila | 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 |
| ubot5 | Ubuntu bug 63080 in linux-source-2.6.22 (Ubuntu) "snd-intel-hda requires options to work on AD1986A" [Undecided,Won't fix] | 11:58 |
| vila | good bot, but no sugar :) | 11:59 |
| Kamping_Kaiser | 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 |
| Kamping_Kaiser | 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:17 |
| spiv | stewart: yes, there is | 12:23 |
| spiv | stewart: https://bugs.launchpad.net/bzr/+bug/709349 | 12:24 |
| ubot5 | Ubuntu bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [High,In progress] | 12:24 |
| spiv | stewart: The Twisted buildbot has encountered the same problem(s). | 12:24 |
| Kamping_Kaiser | 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 |
| vila | Kamping_Kaiser: what about /tmp ? | 12:28 |
| Kamping_Kaiser | vila: 1.4gb untill this filled it. i'll clear it out and try again | 12:33 |
| Kamping_Kaiser | (its a tempfs) | 12:33 |
| vila | Kamping_Kaiser: right, probably where the problem is coming from then | 12:33 |
| vila | Kamping_Kaiser: overriding TMP (or TMPDIR ?) may address the issue for this command | 12:34 |
| Kamping_Kaiser | vila: i'l try them out, thanks | 12:37 |
| vila | 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:38 |
| Kamping_Kaiser | 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 |
| Kamping_Kaiser | maybe tomorrow :/ | 12:40 |
| vila | Kamping_Kaiser: you mean filing the bug or re-trying with the variables ? | 12:41 |
| Kamping_Kaiser | vila: re-trying with teh variables | 12:41 |
| vila | k | 12:41 |
| Kamping_Kaiser | 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 |
| vila | !paste | 12:42 |
| ubot5 | 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 |
| vila | That paste ? | 12:42 |
| Kamping_Kaiser | it was paste.debian.net, i can try that one if you'd like | 12:43 |
| vila | If you intend to re-run tomorrow, try this one if you think it may help confirm/infirm TMP support, otherwise better wait | 12:43 |
| Kamping_Kaiser | ubuntu paste accepted it... all 18000 lines. http://paste.ubuntu.com/623335/ | 12:46 |
| Kamping_Kaiser | anyway. i'll let you know how hte others go. thanks again for your help vila | 12:47 |
| vila | good paste site ;) But yeah, no way be conclusive about TMP support without either trying or reading the source :-/ | 12:49 |
| Kamping_Kaiser | definitely disk space, failed at a later point that time. now trying with TMP="~/bzr-temp" | 13:02 |
| jelmer | Riddell, hi | 13:08 |
| jelmer | Riddell, in ~jr/bzr-explorer/unstable you seem to have updated the version string but not merged in a new version | 13:09 |
| vila | Kamping_Kaiser: gee, tomorrow already ? Your days are short :) | 13:09 |
| Kamping_Kaiser | vila: very fast clocks | 13:15 |
| vila | ha, I see, one more overclocking freak :) | 13:15 |
| Kamping_Kaiser | hehe | 13:16 |
| Kamping_Kaiser | back in the day *reminices* | 13:16 |
| === medberry is now known as med_out | ||
| Kamping_Kaiser | vila: \o/ TMP worked, sans a directory creation bug | 13:37 |
| Kamping_Kaiser | vila: you are a god among men :D | 13:37 |
| vila | just lucky ;) And owing to our elders defining TMP... ;) | 13:38 |
| Kamping_Kaiser | :) | 13:39 |
| dreamkxd | Hello, I am Yonggang Luo | 13:46 |
| dreamkxd | Calling for Jelmer Vernooij | 13:46 |
| jelmer | hi | 13:47 |
| jelmer | dreamkxd, that's me | 13:47 |
| dreamkxd | OK, do you see my comments? | 13:47 |
| dreamkxd | OK, I explain my idea again, | 13:48 |
| dreamkxd | Suppose trunk is the first directory we created, we called it the start folder, named with "default" | 13:48 |
| jelmer | dreamkxd, yeah, replying now | 13:49 |
| dreamkxd | We know under svn, there is an copy operating. we can using it to tracking new branches, and new tags. | 13:49 |
| dreamkxd | almost every tags and branches is created like this, if it's not, we can using config file to show that. | 13:50 |
| dreamkxd | After this, we have some rules. | 13:50 |
| dreamkxd | 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 |
| jelmer | dreamkxd, how do you know which folder is the "default" folder? | 13:51 |
| jelmer | dreamkxd, also, this requires looking at the entire history. Some repository have over 1 million revisions | 13:52 |
| dreamkxd | Yes, we suppose trunk is the default folder. | 13:52 |
| dreamkxd | 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:53 |
| dreamkxd | 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 |
| jelmer | dreamkxd: at least for the default behaviour, O(history) is unacceptable | 13:54 |
| jelmer | dreamkxd: what about situations where the original trunk was removed and a new trunk is created? | 13:54 |
| jelmer | dreamkxd: also, are there any situations you've found where the existing behaviour doesn't work? | 13:54 |
| dreamkxd | 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 |
| jelmer | dreamkxd, in other words, what's the problem you're trying to fix? | 13:55 |
| jelmer | dreamkxd: That's not a good reason to make it even slower though.. :) | 13:55 |
| dreamkxd | Now, It's will getting it's faster, | 13:55 |
| dreamkxd | indeed, i've ever using hgsubversion to convert llvm, and it's OK, at least on the time:) | 13:56 |
| dreamkxd | but bzr-svn toggled.... | 13:56 |
| jelmer | 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 |
| dreamkxd | you means bzr svn-import ?.... | 13:56 |
| Riddell | 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 |
| jelmer | Riddell: is the new dependency only since bzr-explorer 1.3.0? | 13:57 |
| dreamkxd | 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 |
| dreamkxd | Well, I am not meas only import the trunk.... but also retains the branches and tags informations.... | 13:58 |
| jelmer | dreamkxd: Have you tried? I don't see anything in the repository that could confuse bzr-svn | 13:59 |
| dreamkxd | Err.... | 13:59 |
| jelmer | dreamkxd: "bzr svn-import http://llvm.org/svn/llvm-project/llvm/" is what I would try | 13:59 |
| jelmer | or http://llvm.org/svn/llvm-project/llvm/trunk | 13:59 |
| jelmer | I mean "bzr branch http://llvm.org/svn/llvm-project/llvm/trunk" | 13:59 |
| dreamkxd | Yes, that's what I was tried.. | 13:59 |
| jelmer | dreamkxd: did that create incorrect branches? | 14:00 |
| dreamkxd | bzr svn-import http://llvm.org/svn/llvm-project/llvm/ that's I wanted. | 14:00 |
| dreamkxd | So, can you give me an list of branches?... | 14:00 |
| dreamkxd | Then I can tell you what's lost. | 14:01 |
| dreamkxd | Because I was failed:( | 14:01 |
| jelmer | dreamkxd: Sorry, can you be more specific? How did it fail? | 14:01 |
| jelmer | what was missing? | 14:02 |
| dreamkxd | It's running for an long time, about 8 hours, I didn't finished it, and then I closed it.... | 14:02 |
| mgz | vila: pong | 14:03 |
| dreamkxd | 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:03 | |
| mgz | eheh | 14:04 |
| vila | 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 |
| mgz | that's the bad thing about pings vs just saying what you were thinking of | 14:04 |
| mgz | right, I need to track down a bug, then I think I can just propose | 14:04 |
| vila | 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 |
| dreamkxd | 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 |
| vila | mgz: a better test coverage can come later | 14:05 |
| mgz | ah, that's a different one. I did bug jelmer a bit about it. | 14:05 |
| dreamkxd | Well, we'd better using gtalk,, freenode is not suite for long conversation.... | 14:05 |
| jelmer | dreamkxd, not when finding the layout | 14:05 |
| vila | mgz: ha, right, he's busy right now :) | 14:05 |
| vila | dreamkxd: it is. and the logs are archived which is better for our collective unconscious :) | 14:06 |
| jelmer | vila: I think you mean it's not.. at least, my gtalk logs aren't accessible by anyone but me :) | 14:07 |
| vila | jelmer: hehe, I meant freenode is suited :) | 14:07 |
| dreamkxd | Er, my input box only one line,sign.... | 14:07 |
| dreamkxd | Is there any freenode client?.... | 14:08 |
| vila | dreamkxd: what are you using ? | 14:08 |
| dreamkxd | Chrome ,,, http://webchat.freenode.net/ | 14:08 |
| dreamkxd | sign.... | 14:08 |
| vila | dreamkxd: oh, webchat, which OS ? | 14:08 |
| dreamkxd | Chrome 12, under WinOS. | 14:10 |
| dreamkxd | def find_branchpaths(self, layout, from_revnum, to_revnum, project=None): | 14:10 |
| dreamkxd | This function is O(history) time... | 14:10 |
| dreamkxd | If I wan't to using the history, I need to do something here. | 14:11 |
| dreamkxd | 23369kB 56kB/s / copying revision 4776/130322 | 14:11 |
| jelmer | 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 |
| dreamkxd | that's my progress. | 14:11 |
| jelmer | 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 |
| dreamkxd | e....OK. | 14:12 |
| dreamkxd | 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 |
| dreamkxd | 1.if directory A copied from directory B, and B is an existed branch or tag, then A is an branch or tag | 14:16 |
| abentley | vila, thanks for your reviews. | 14:17 |
| dreamkxd | 3.ignore the branches that comes from outsite | 14:17 |
| dreamkxd | That's all... | 14:18 |
| abentley | 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 |
| vila | abentley: thanks for the hard work, impressive, hope you don't mind adding comments, they cruelly lack | 14:18 |
| vila | err, crossed on the wire, was replying to your first comment | 14:19 |
| abentley | 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 |
| dreamkxd | 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 |
| vila | abentley: well, that's a shame then, because you modified code without modifying comments | 14:19 |
| abentley | vila: Like I said, comments get stale. | 14:20 |
| vila | ... | 14:20 |
| dreamkxd | Is there question? | 14:20 |
| abentley | vila: so it's better not to need any. | 14:21 |
| vila | abentley: in an ideal world, sure | 14:21 |
| vila | and even there I strongly doubt comments are useless | 14:21 |
| jelmer | dreamkxd: I'm not following, you're proposing creating branch on whether they were derived from the original trunk branch right? | 14:21 |
| dreamkxd | Now only derived from original trunk branch, but also derived from other already existed branches.. | 14:22 |
| vila | 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:22 |
| abentley | vila: I certainly can. | 14:23 |
| dreamkxd | It'slike an set, we inserting element into it, and delete element from it. | 14:23 |
| jelmer | dreamkxd, see http://pastebin.ubuntu.com/623402/ | 14:23 |
| vila | abentley: why bother writing cover letters then ? | 14:23 |
| abentley | vila: And if it doesn't, it's badly written. | 14:23 |
| abentley | vila: To express motivation. | 14:23 |
| jelmer | 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 |
| dreamkxd | llvm/branches/Apple | 14:23 |
| vila | abentley: pff, your code doesn't express motivation ? | 14:23 |
| dreamkxd | That's the problem, under Apple, there is a lot branches.. | 14:24 |
| dreamkxd | Apple is not an branch, but an branch container:) | 14:24 |
| abentley | vila: my code doesn't express motivation for the change I propose, it expresses motivation of the changed version. | 14:24 |
| dreamkxd | http://pastebin.ubuntu.com/623402/ | 14:24 |
| dreamkxd | http://llvm.org/svn/llvm-project/llvm/branches/Apple/ | 14:24 |
| dreamkxd | And in this repo, there is other kinds of examples:) | 14:25 |
| dreamkxd | such as http://llvm.org/svn/llvm-project/cfe/branches/Apple/whitney-IB/src/tools/ | 14:26 |
| dreamkxd | The path http://llvm.org/svn/llvm-project/cfe/branches/Apple/whitney-IB is an branch of llvm | 14:26 |
| dreamkxd | but the path http://llvm.org/svn/llvm-project/cfe/branches/Apple/whitney-IB/src/tools/clang/ is an branch of cfe. | 14:26 |
| dreamkxd | These problems is what I want to solved. | 14:27 |
| vila | 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 |
| jelmer | dreamkxd: Ah, ok. That makes sense | 14:27 |
| vila | abentley: if you disagree with the comments I proposed, explain why | 14:27 |
| abentley | 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 |
| vila | abentley: if you think you can do that with only code, great | 14:27 |
| abentley | 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 |
| dreamkxd | Now, I have already got an peace of python code implement the following functions. | 14:28 |
| jelmer | 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 |
| dreamkxd | Yes, I wan't to do that.. | 14:29 |
| dreamkxd | But I need to access to the history:) | 14:29 |
| jelmer | dreamkxd: You should be able to create your layout in repository_guess_layout() and pass in the logwalker there | 14:30 |
| dreamkxd | And now I've toggle where to get the log into it... | 14:30 |
| vila | 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:31 |
| vila | I won't even pretend (and I said so) that my *proposed* comments are accurate or complete | 14:33 |
| abentley | 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. | 14:33 |
| === zyga is now known as zyga-food | ||
| vila | but I wasn't aggressive damn it ! I felt that this method was important and there is *no* comments there in trunk. | 14:36 |
| vila | How is it said in English ? | 14:36 |
| abentley | 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. | 14:37 |
| === maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failures: 486 | ||
| abentley | vila: You say "I think this method should have comments because it is important" in English. | 14:38 |
| dreamkxd | Well, is there anyway to specify the layout you want to use? | 14:38 |
| vila | But why did you take for you when I was saying that the lack of comments was cruel for *me* ? | 14:38 |
| jelmer | dreamkxd: It's an option to "bzr svn-import", or you can set it in your bzr configuration ("layout = trunk1") | 14:39 |
| vila | 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 |
| vila | abentley: especially when I said great job ? | 14:39 |
| abentley | If the lack of comments was cruel to you, then I was being cruel to you. | 14:40 |
| dreamkxd | bzr svn-import layout=trunk1? | 14:40 |
| jelmer | dreamkxd: bzr svn-import --layout=trunk1 | 14:40 |
| vila | 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:40 |
| vila | abentley: I felt I couldn't write the comments myself, gave it a try and ask you to polish them | 14:41 |
| dreamkxd | OK, thanks, well is there any way that I need not build and install bzr-svn and then using of it? | 14:41 |
| vila | abentley: and roughly your reply was: comments are useless, if you can't understand the code, you're an idiot | 14:41 |
| abentley | vila: Okay, let's stipulate for now that the right approach is to add comments rather than clarifying the code. | 14:42 |
| abentley | vila: No, my response is that if you can't understand the code, the code isn't clear enough. | 14:42 |
| jelmer | dreamkxd: If you have the plugin installed in your home directory you can modify it there directly | 14:43 |
| abentley | " The code should be clear enough by itself, and if it's not, it should be made clearer" | 14:43 |
| jelmer | dreamkxd, alternatively, you can set the BZR_PLUGINS_AT environment variable to point at the location where the plugin is | 14:43 |
| dreamkxd | Well, if I directly copy the bzr-svn folder into bzrlib plugin folder, will that working?... | 14:44 |
| jelmer | dreamkxd, that should work too | 14:44 |
| vila | 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 |
| dreamkxd | Ok, thanks... | 14:44 |
| dreamkxd | 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:45 |
| abentley | vila: let's stipulate that adding comments is the right approach for this code, and talk about the comments themselves. | 14:46 |
| vila | abentley: also, the clearest code sometimes is just not obvious and adding comments makes it easy to read again | 14:46 |
| vila | abentley: great | 14:46 |
| abentley | vila: I don't understand the motivation for the docstring changes to _inventory_altered. Could you explain that? | 14:47 |
| vila | abentley: It's unclear to me what part of the transformations are captured here | 14:47 |
| vila | abentley: are they all ? If not which ones are and which aren't ? | 14:48 |
| abentley | All trans_ids that need an inventory entry change are there. | 14:48 |
| vila | abentley: Imagine I have no idea about which transformations requires an inventory change | 14:50 |
| dreamkxd | I was already do this layout_registry.register_lazy("perfect", "bzrlib.plugins.svn.layout.perfect", "PerfectLayout") | 14:51 |
| abentley | 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 |
| vila | 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:51 |
| vila | abentley: well, the idea is to help people *get* this pre-requisite knowledge | 14:52 |
| vila | so probably something between the two | 14:52 |
| abentley | vila: The knowledge is not particular to TreeTransforms, however. It's about knowing what an inventory entry reflects. | 14:53 |
| vila | true, we don't want a full book either :) | 14:53 |
| abentley | 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 |
| jelmer | 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 |
| jelmer | s/to the layout/to the history/ | 14:54 |
| abentley | vila: It's not a summary, it's just a list of paths and trans_ids. | 14:54 |
| vila | abentley: sure, this was more a placeholder | 14:55 |
| vila | but list of paths and trans_ids doesn't tell me much about what they represent | 14:55 |
| dreamkxd | You means directly create CustomLayout under function repository_guess_layout? | 14:55 |
| abentley | 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 |
| dreamkxd | such as return CustomLayout (repository._log) | 14:56 |
| jelmer | dreamkxd: I think you mean PerfectLayout rather than CustomLayout? | 14:56 |
| dreamkxd | Yes, PerfectLayout | 14:56 |
| jelmer | dreamkxd, Also, presumably all the analysis would happen there, and you wouldn't need to access the history again after that | 14:56 |
| vila | 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 |
| Riddell | how come requeue_package.py doesn't work for me on jubany? http://paste.kde.org/80443/ | 14:57 |
| dreamkxd | But, I need all history ..., did logwalker_guess_layout will iterate the whole history? | 14:57 |
| abentley | vila: so by "represent", you really mean "why would a trans_id be included in this list"? | 14:58 |
| vila | 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 |
| vila | yup | 14:58 |
| jelmer | dreamkxd, well, that's what you intended right? | 14:58 |
| === zyga-food is now known as zyga | ||
| vila | 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:00 |
| dreamkxd | 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 |
| dreamkxd | That's means, I need iterate EVERY svn revision LOG at least ONE time. | 15:01 |
| jelmer | dreamkxd: I guess another thing you could do is in Repository.get_layout() check for a config variable | 15:03 |
| jelmer | dreamkxd, and if that variable is set, return PerfectLayout(self._log) | 15:03 |
| vila | 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 |
| dreamkxd | And remove the statement layout_registry.register_lazy("perfect", "bzrlib.plugins.svn.layout.perfect", 310 "PerfectLayout") ? | 15:03 |
| jelmer | dreamkxd, yes | 15:04 |
| vila | abentley: and yes, this may require other knowledge not explained here, but that doesn't mean good hints can't be provided | 15:04 |
| abentley | vila: it feels like an extremely high burden of documentation. | 15:04 |
| abentley | vila: like a manual for laymen for doing heart surgery. | 15:04 |
| vila | hehe | 15:05 |
| vila | not at all | 15:05 |
| dreamkxd | OK, I see, I think my proposition can not be guess:) so just direct using of it:) | 15:05 |
| vila | I wrote the proposed ones quite quickly and I'm sure you can fix/complete them without spending hours on them | 15:05 |
| abentley | No, really, it does. I expect people who hack on TT to know what _removed_contents is. | 15:05 |
| abentley | _removed_contents is documented, and I'll happily improve the documentation if needed. | 15:06 |
| vila | what are you aiming for ? | 15:09 |
| vila | Convince me that all my proposed comments are not needed ? | 15:09 |
| abentley | vila: sorry. I am reacting to your suggestion "Imagine someone not knowing TT at all...". | 15:10 |
| vila | <shudder> Sorry, I don't know how to express that in English as well as I can do it in French :-( | 15:11 |
| vila | 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:12 |
| vila | 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 |
| abentley | vila: What do you think of this as a docstring: http://pastebin.ubuntu.com/623446/ | 15:14 |
| vila | The former occurs more often than the later as you can read code without understanding it most of the time | 15:15 |
| vila | abentley: +1 +1 | 15:15 |
| === vednis is now known as mars | ||
| vila | abentley: so, when is the filtering needed in: + changed_id = set(t for t in self._new_id | 15:21 |
| vila | + if self._new_id[t] != self.tree_file_id(t)) | 15:21 |
| vila | abentley: I mean, I can see that if the id is the same it's not changed, but when is it needed ? | 15:22 |
| abentley | vila: The filtering is so that we don't return spurious entries, and do more work than needed to update the tree. | 15:23 |
| vila | but which entries are spurious ? | 15:24 |
| chrisvj | hi | 15:24 |
| abentley | vila: entries where the file id was deleted, and then restored to the original value. | 15:24 |
| chrisvj | does anyone have any idea why bazaar stops downloading files at 59%? | 15:24 |
| vila | 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 |
| vila | s/take/&*me*/ | 15:25 |
| maxb | If someone ~canonical-bazaar has a moment, please bzr pull jubany's bzr-builddeb and requeue_package.py --all-of-type dipy ? | 15:26 |
| abentley | vila: similar to changed_kind = (t for t in changed_kind if self.tree_kind(t) != self.final_kind(t)) | 15:26 |
| vila | abentley: hehe, who knows why I understood this one more easily... | 15:27 |
| vila | maxb: how safe is that ? :D | 15:30 |
| maxb | vila: Pretty safe, we already did the big pull, this pull should only be a handful of revisions | 15:31 |
| vila | maxb: 2 indeed, I'm unclear about the needed dependencies for jr's hook ? | 15:31 |
| Riddell | vila: none needed, it won't use it unless bzr >= 2.4 | 15:32 |
| Riddell | vila: do you run commands on jubany as pkg_import? | 15:33 |
| vila | ha, good, you tested it against 2.3.1 ? | 15:33 |
| vila | Riddell: yes, you should do a su first | 15:33 |
| vila | well, sudo su - | 15:33 |
| Riddell | vila: yes it checks for the bzr version | 15:34 |
| vila | Riddell: would you try to help maxb there or should I just finish this ? | 15:34 |
| Riddell | vila: I don't have sudo permission so I can't do anything :( | 15:34 |
| vila | k | 15:34 |
| vila | pull done | 15:34 |
| maxb | Also, the hook should not be invoked because the importer doesn't invoke editors? Or did I misunderstand? | 15:35 |
| vila | maxb: and requeue done | 15:35 |
| maxb | thanks | 15:35 |
| mgz | I spent yesterday replacing code using python modules with Qt things. | 15:39 |
| Riddell | mgz: oh? | 15:39 |
| * vila blinks | 15:39 | |
| vila | mgz: can you elaborate on that ?? | 15:39 |
| vila | mgz: I'm not sure where to put the comma... | 15:40 |
| vila | or the parentheses | 15:40 |
| mgz | it was an interesting experience. just a little gui a friend had written with pyqt and it turned out using as little python as possible generally made for better code. | 15:40 |
| mgz | QProcess does async reading properly, and handles unicode commandlines, subprocess doesn't. | 15:41 |
| mgz | QDirIterator avoids having to filter inside os.walk and is more efficient | 15:42 |
| mgz | QString has a builtin normalized method so don't need unicodedata.normalize | 15:42 |
| mgz | QSettings is a bit easier to use than ConfigParser and I'm mor confident it does sensible things with unicode | 15:43 |
| Riddell | Qt devs know API is everything for libraries | 15:43 |
| mgz | I'm down to `import datetime, os, sys` at the top. | 15:44 |
| barry | any code hosting/bzr experts online that could do a quick mumble with mvo and myself? | 15:44 |
| Riddell | can I recommend QDateTime? :) | 15:44 |
| jelmer | barry, sure | 15:45 |
| mgz | I looked at it :) it's literally one line for getting a timestamp though so didn't seem worth changing. | 15:45 |
| barry | jelmer: awesome, thanks | 15:45 |
| vila | barrym jelmer: Mind if I listen ? | 15:45 |
| barry | vila: of course not! | 15:46 |
| vila | thanks | 15:46 |
| abentley | vila: http://pastebin.ubuntu.com/623473/ | 15:47 |
| vila | abentley: THANK YOU !!!! | 15:47 |
| abentley | vila: Any improvements still needed? | 15:48 |
| vila | abentley: let see... | 15:48 |
| vila | abentley: nah, kidding, that's great ! | 15:48 |
| jelmer | barry: I'm in Bazaar | 15:49 |
| mgz | QProcess was the big win, I'm fed up with subprocess not doing what I want. Helps that there's an event/callback thing built in anyway. | 15:50 |
| barry | jelmer: can you hear us? | 15:51 |
| jelmer | barry, I can hear you | 15:51 |
| jelmer | barry, not sure how to talk myself yet though.. | 15:51 |
| mgz | open your mouth! | 15:52 |
| mgz | irc make people forget... | 15:52 |
| abentley | vila: re self.addCleanup(fork.lock_write().unlock), that's an improvement but I'd rather write self.useContext(write_locked(fork)) | 15:59 |
| vila | abentley: sure, I'm not sold on the new trick myself | 16:01 |
| abentley | vila: did you merge my changes into trunk? | 16:01 |
| abentley | vila: for some reason, my diff is lacking the changes from before. | 16:02 |
| vila | abentley: I didn't | 16:02 |
| vila | abentley: otp | 16:03 |
| abentley | vila: okay, it's that submit_branch behaviour. | 16:03 |
| vila | abentley: err, I misread, self.useContext() ? Is this from testtools ? | 16:16 |
| abentley | vila: I believe it's only in Launchpad, but the implementation is simple. | 16:17 |
| vila | Ha ok, yeah, sounds nice | 16:17 |
| abentley | vila: val = foo.__enter__(); self.addCleanup(foo.__exit__, None, None, None); return val | 16:18 |
| vila | hehe | 16:19 |
| vila | abentley: you'll have to talk slowly while we get up to speed with 2.6 ;) | 16:19 |
| vila | abentley: -fixups approved, want me to submit to pqm ? | 16:22 |
| abentley | vila: no, I'll do it. | 16:22 |
| vila | k | 16:22 |
| abentley | vila, jam: you guys seem to disagree about whether a test that proves no error is raised should have an explicit assertion. | 16:32 |
| Riddell | I now have access to pkg_import on jubany, requeue-package still doesn't work, what am I doing wrong? http://paste.kde.org/80473/ | 16:32 |
| vila | abentley: the double with ? | 16:32 |
| abentley | In test_apply_retains_root_directory, I have no assertion and vila complains. | 16:32 |
| abentley | In the shelf_ui test, I have assertions that no exception is raised and jam complains. | 16:33 |
| vila | hehe | 16:33 |
| vila | abentley: is the shelf_ui one the onw with the double with ? | 16:35 |
| abentley | vila: yes. | 16:35 |
| vila | abentley: I had to play with it to understood how it works, it seems to me *both* with are required or the test will be wrong | 16:36 |
| vila | err, to understand | 16:36 |
| abentley | vila: yes, but you can remove both, which is what jam asked for. | 16:37 |
| vila | abentley: I agree with you and disagree with jam here | 16:37 |
| vila | Adding 'InconsitentDelat not raised' makes it clearer (and the comment may help understand how this construct works ;) | 16:38 |
| jelmer | abentley: btw, what's the relation of your fix to bug 82555 ? | 16:38 |
| ubot5 | Launchpad bug 82555 in Bazaar "Merging to an empty branch doesn't work" [Medium,Confirmed] https://launchpad.net/bugs/82555 | 16:38 |
| vila | well, not only clearer but also stronger, AssertionError is quite wide | 16:38 |
| vila | otherwise | 16:38 |
| abentley | jelmer: I don't think it's related. | 16:39 |
| jelmer | abentley: ok - thanks | 16:39 |
| abentley | vila: Yes, but that would allow other InconsistentDeltas to be raised, and I don't think we want that. | 16:39 |
| abentley | vila: e.g. what if the text changes, and then it starts raising? | 16:40 |
| vila | huh ? | 16:40 |
| vila | what text ? | 16:40 |
| abentley | vila: The text of the error. But I'm thinking of the inner with statement. | 16:41 |
| abentley | I think it's fine in the outer one. | 16:41 |
| vila | ha ok, yeah, I meant addind the text in the outer one | 16:41 |
| vila | adding, gee, tyops festival | 16:41 |
| abentley | vila: I find your comment change unclear "if there's no 'other', or it's not versioned (unversioned being one such case), we leave it alone." | 17:02 |
| abentley | vila: unversioned is the only case where it's not versioned. | 17:02 |
| vila | what about files created but not yet added ? | 17:04 |
| abentley | vila: they're unversioned / not versioned. | 17:04 |
| vila | unvesioned implied it *was* versioned but is not anymore | 17:04 |
| stewart | spiv, thanks for bug URL there. isn't high priority to us as we can upgrade bzr repo formats everywhere (and it's not the only cause of any build/test failure :) - but good to know is already known | 17:05 |
| vila | abentley: IIRC correctly this changes is needed because otherwise unshelving a file added but not yet committed fails | 17:07 |
| abentley | vila: I would think "unversioned" can also mean "not versioned", not the past tense of "to unversion". Maybe my bzr jargon has gone a bit fuzzy. | 17:07 |
| vila | abentley: hehe he is still probably better than my English ;) | 17:08 |
| abentley | vila: But why would you want to talk about "unversioning" in the context of tree state? Does it matter why the file is not versioned? | 17:09 |
| vila | my point here is that not versioned wasn't an obvious to justify switching from other-name None to a other_tree.has_id() | 17:10 |
| vila | shudder | 17:10 |
| vila | my point here was that "not versioned" wasn't an obvious reason to justify switching from other_name is None to a other_tree.has_id() | 17:10 |
| vila | so I revert the change to see which test was failing without it, understood the change and thought it may be clearer | 17:11 |
| vila | now... | 17:11 |
| abentley | vila: I don't understand. | 17:11 |
| abentley | If you want to know whether a file is versioned, you wouldn't use has_id? | 17:12 |
| vila | well, the code didn't it :) | 17:12 |
| vila | and the specific failure was about a file which *was* versioned | 17:13 |
| === 15SAAQWPK is now known as jamestunnicliffe | ||
| vila | so I thought the subtle difference may easily be missed | 17:13 |
| vila | but may be unvesioned is not the right word | 17:14 |
| abentley | vila: I can make you tests where the file was never versioned. | 17:14 |
| vila | gah | 17:14 |
| vila | sure | 17:14 |
| vila | oh, you mean the bug was larger ? | 17:14 |
| vila | and specifying unversioned add no value since all cases were other wasn't versioned were failing ? | 17:15 |
| abentley | vila: I mean that merge cares about states, not changes, and so "unversion" is an alien concept to it. | 17:15 |
| vila | err, sort of, or you wouldn't need parents | 17:15 |
| abentley | vila: I can only make "unversioned" make sense if it means "not versioned", and then it's redundant. | 17:16 |
| vila | abentley: not versioned includes never versioned | 17:17 |
| abentley | vila: right. "never versioned" and "unversioned" are distinctions that merge does not care about. | 17:18 |
| abentley | vila: so it doesn't make sense to talk about them. | 17:19 |
| vila | huh ? | 17:20 |
| vila | Why did you introduce versioned then ? | 17:20 |
| abentley | vila: "versioned", meaning "has a file id" is a state, and merge does care about it. | 17:21 |
| vila | It seems to me you're nit-picking here, if merge cares about A it cares about not A as well | 17:24 |
| abentley | vila: Sure, it cares about whether a file is versioned, or not versioned, but it doesn't care whether it's unversioned or never versioned. | 17:25 |
| vila | abentley: where are we disagreeing then ? | 17:28 |
| abentley | vila: because your change to the comment doesn't seem to add any information. | 17:28 |
| vila | ha, right | 17:29 |
| vila | The reason I added it was that I didn't realize unversioned was part of not versioned, | 17:30 |
| abentley | vila: "has no file id"? | 17:30 |
| vila | so may be the whole comment should be rewritten to an even simpler form | 17:30 |
| vila | yup, something like that: there is no other, bye | 17:31 |
| vila | so yeah, 'has no file id, we leave it alone' | 17:31 |
| vila | will wfm | 17:32 |
| abentley | wfm | 17:33 |
| abentley | vila: re 87 you said "it looks like this is as side-effect of your change that is not described in the cover letter." Cover letter said "fixup_new_roots does not generate a conflict if a new root is added and the old root is not deleted." is that not it? | 17:36 |
| vila | I think the test is about a conflict with a regular file, not the root, the context was (roughly): | 17:37 |
| vila | 1) a directory and its contained files are merged, | 17:37 |
| vila | 2) lives goes on | 17:37 |
| vila | 3) a file is added in the directory | 17:37 |
| vila | 4) the directory is merged again | 17:37 |
| vila | where should the file go ? | 17:37 |
| vila | ha crap, | 17:37 |
| vila | 1.1) the merged directory is renamed | 17:38 |
| vila | I don't remember the specifics but I think the file from the first merge are tracked correctly but we are not able to reparent the new file | 17:39 |
| vila | So it's not really the same problem that adding a new root, it's more about tracking where the root went | 17:39 |
| abentley | vila: it might be because we now apply the OTHER root_id. | 17:39 |
| abentley | vila: In cases where there's an id conflict. | 17:40 |
| vila | I don't think we apply the new root but instead re-parent the merged files in the existing one | 17:41 |
| vila | so basically before your change we were putting the new file into root but with a conflict that were warning the user that he had to move the file in the right place, | 17:42 |
| abentley | vila: at line 164, the outcome will now be different. | 17:42 |
| vila | err, which file / | 17:42 |
| vila | ? | 17:42 |
| abentley | vila: At that point, test_merge_from_branch | 17:42 |
| abentley | Sorry, file is bzrlib/tests/per_workingtree/test_merge_from_branch.py | 17:42 |
| vila | line 164 is in make_outer_tree ? | 17:43 |
| abentley | vila: right. | 17:43 |
| abentley | vila: the merge from null | 17:43 |
| abentley | vila: That will replace outer's root id with inner's. | 17:44 |
| vila | argh, gtg :-( | 17:44 |
| abentley | vila: okay. Have a nice weekend. | 17:45 |
| vila | the case I was referring to is a merge in an existing branch not an empty one | 17:45 |
| vila | abentley: you too | 17:45 |
| vila | abentley: may be the *test* had a bad focus | 17:47 |
| abentley | vila: I can rewrite it so it fails like it used to. | 17:47 |
| abentley | vila: I mean conflicts, not fails. | 17:48 |
| vila | abentley: if that means not merging from null:, this may be the way to go | 17:49 |
| * vila really off | 17:49 | |
| maxb | james_w: Hello, are you potentially around and able to make the sysvinit import happen? | 18:57 |
| maxb | https://bugs.launchpad.net/udd/+bug/708655/comments/6 if you are | 18:58 |
| ubot5 | Ubuntu bug 708655 in Ubuntu Distributed Development "sysvinit package import failing" [Undecided,In progress] | 18:58 |
| james_w | maxb, I am potentially around | 19:02 |
| maxb | Sorry for picking on you - this needs someone who is in ~ubuntu-branches | 19:03 |
| james_w | no problem | 19:03 |
| james_w | happy to help | 19:03 |
| james_w | maxb, are there debian branches too? | 19:04 |
| maxb | no, not on launchpad | 19:04 |
| maxb | Which is odd, yes | 19:04 |
| === maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failures: 485 | ||
| james_w | maxb, branches renamed | 19:15 |
| maxb | ok.... | 19:16 |
| maxb | Are you also able to do the rest at some point, or shall I accost someone else for the jubany bits? | 19:23 |
| jseabold | We have a developer who merged trunk into his branch, but the revision in trunk merged into the branch was deleted. He has pushed several commits since. Can I back out these changes with shelve and remerge with the correct revision in trunk? | 19:49 |
| james_w | maxb, it's just import-package fixes that you need from lp:udd 455 right? | 19:52 |
| james_w | just wondering if we need a mass-import restart before continuing | 19:52 |
| maxb | james_w: No recent changes to mass-import, it can be left running | 19:53 |
| james_w | maxb, requeued | 19:54 |
| maxb | Yay | 19:54 |
| === tchan1 is now known as tchan | ||
| === zyga is now known as zyga-food | ||
| james_w | maxb, it's chewing on it and importing something in dapper currently | 20:08 |
| maxb | Great, I expect it to take several hours | 20:08 |
| maxb | sysvinit has a LOT of ubuntu revisions :-) | 20:08 |
| james_w | maxb, thanks for your persistence on this :-) | 20:09 |
| === yofel_ is now known as yofel | ||
| maxb | low priority: requeue_package.py --all-of-type enigmail (they'll all fail again, but it will group them in with the same failure signature as a larger group) | 20:59 |
| james_w | maxb, done | 21:04 |
| maxb | thanks | 21:04 |
| james_w | sysvinit is still on dapper :-) | 21:04 |
| maxb | I'm not too concerned about that - I remember watching the logs of my test import. It spend aaaaages on dapper | 21:05 |
| james_w | edgy \o/ | 21:26 |
| === med_out is now known as med_BOS | ||
| maxb | james_w: it looks like the --all-of-type enigmail did not actually take effect? | 21:50 |
| james_w | maxb, oops, sorry, I didn't read the output and I got the command wrong :-) | 21:52 |
| james_w | done now | 21:52 |
| maxb | thanks | 22:00 |
| === med_BOS is now known as medberry | ||
| === medberry is now known as med_out | ||
| === zyga-food is now known as zyga | ||
| brady | help | 23:35 |
| brady | my bzr uploads a ~300mb pack file everytime I push. is this normal? the files being versioned are ~800mb. | 23:37 |
| brady | i noticed that the main repository uses repository format 2a and my branch uses format 7. not sure if this is optimal either. | 23:39 |
| lifeless | 2a is good | 23:45 |
| lifeless | pack files in 2a contain (possibly many) entire compressed files. | 23:45 |
| lifeless | this is for data safety and integrity | 23:45 |
| brady | i am only changing a few files, and they are relatively small. | 23:45 |
| lifeless | there is a plan to have a network-push facility that will send deltas | 23:46 |
| brady | yet, when I push ....the entire 300mb pack file is uploaded to the server | 23:46 |
| brady | oh, ok. so this is normal behavior. | 23:46 |
| lifeless | 'packing' which happens automatically combines pack files | 23:46 |
| lifeless | and different versions of files stored inside a /single/ pack are *very* tightly delta-compressed | 23:46 |
| brady | it's just a bunch of php files | 23:47 |
| lifeless | brady: well, if you are only changing small files, not its not expected that you would be pushing 300MB each time | 23:47 |
| lifeless | brady: its the weekend now for the core bzr devs - I suggest asking on the mailing list, or even filing a bug. | 23:47 |
| brady | lifeless: thanks | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!