[00:19] mwhudson: there isn't really an alternative, you can't seek in the mercurial bundle files [00:20] jelmer: fair enough [00:21] in other news, now that lp:django is upgraded I've asked the whygitisbetterthanx folks to update their info: http://github.com/schacon/whygitisbetter/issues#issue/4 [00:23] hm [00:24] jelmer: it seems a bit like when revision_id is passed to FromHgRepository.fetch, some extra revisions are imported [00:24] beyond the one requested [00:26] jelmer: does this sound possible to you? [00:29] i guess this means source._hgrepo.changegroup is returning more than we're asking for [00:30] mwhudson: hmm [00:31] heads() returns a 1 element set, missing is a 1-element set but we go around the loop in _unpack_changesets twice [00:31] mwhudson: I guess when we ask for a branch containing a revision we shouldn't assume that the tip of that branch is our revision [00:31] mwhudson: can you file a bug? [00:33] jelmer ok [00:41] jelmer: https://bugs.edge.launchpad.net/bzr-hg/+bug/544701 [00:42] Ubuntu bug 544701 in bzr-hg "pull -r $rev doesn't limit revisions converted" [Undecided,New] [01:01] what's the proper way to retag a branch [01:04] bzr tag -d $MYTAG; bzr tag -r$I_WANT_TO_TAG_THIS_REVISION $MYTAG, from memory. [01:04] RAOF: right, but when I push I get a conflicting tag errro [01:04] do I have to push --overwrite? [01:05] I remember just pushing, but maybe I'd also added some revisions. [01:06] I'm unsure here; I only remember it Just Working. [01:08] RAOF: ok, thanks we worked around it anyways [01:44] How can I branch off a revision that was already branch off my branch? [01:46] or rather, how do I check out a branch by one of its revision ids? [02:11] GungaDin: branch -r XXXXX source === jamesh__ is now known as jamesh [04:06] mwhudson: Thanks! We're waiting on Francis for some administrative details before I continue, FYI. [04:06] mkanat: i'm not sure the latest info is very useful :/ [04:35] mwhudson: Okay. I'll take a look at it once we handle the administrative stuff. [04:41] GungaDin: still here? did you get an answer? [04:41] you can do 'bzr branch -rN FROM TO' [05:00] yeah, managed already [05:00] thx [05:05] Hmm... You think that there's any chance LP would support access to Bazaar repos with a git client? [05:06] It's technically possible, but ...uuurgh :) [05:06] bzr-git almost makes this look feasible, and the bazaar repositoires are rich enough to be a backend for git [05:06] Right; they store more info than git does. [05:06] RAOF: I agree. I'm a bazaar fan myself [05:06] It's possible to do this locally; bzr serve --git, for example. [05:07] I just think it would a technically "cool" thing to be able to do on a LP level [05:07] Heh. Well, mostly (it crashes at the moment for me) [05:08] There are at least two problems that I know of, one technical, one social. The technical one being that it would hammer the server, the social one being that I think launchpad would like to promote the use of bzr and make it possible to use bzr to access everything. [05:08] i think the performance would be pretty terrible currently [05:08] Going to try and work out why when I get a spare couple of hours [05:09] mwhudson: That being the performance of bzr-upload-pack and bzr-receive-pack when emulating a git repo? [05:10] * mkanat knows that pack-to-2a conversion is slooooow. [05:12] dcoles: basically yes [05:12] maybe going bzr->git will be faster than t'other way around [05:20] * dcoles relises he's late for class - runs [05:21] igc, hi [05:22] igc, i'm going to make 2.0.5 and 2.1.1 tarballs [05:35] hi, a question about tags. If the revision of a tag is changed, it can't be pushed/pulled because of tag conflicts. Is the following the right thing to do: 1) Ensure all changes have been merged, i.e. make two branches converged; 2) bzr push --overwrite or bzr pull --overwrite [05:37] in fact, I'm using tags to point some revisions in history. Is this even the right usage of tags? Should I use branches for this purpose, instead of tags? [05:43] an advantage of using branches over using tags, imho, is that later changes can be merged into branches, but for tags this is impossible. So tags appear to be better, right? [05:43] :( That's a typo. I mean, So branches appear to be better [05:51] poolie: sounds good [06:00] echo-area: if you expect it to continue changing, a branch is better [06:00] if it's "this is 2.0.5" and it won't normally change, that's better [06:00] if you need to change it in another branch, use 'bzr tag -d PLACE " [06:01] igc, so your packaging changes only apply to 2.2 right? [06:01] we couldn't run them kind of externally against 2.0? [06:01] polie: right [06:01] i suppose it would be risky even if it worked [06:01] too risky IMO [06:12] poolie: thanks. [06:42] deletion of tags doesn't get propagated, is this intentional? [06:49] Sorta. Any change to tags doesn't propogate unless you force it, since there's no way to know what changed. [06:52] fullermd: By "force it", do you mean --overwrite? That seems to only work for revision changes of tags. [06:55] fullermd: But I got your idea. Changes to tags are not recorded as much as changes to files/directories, so I think I'll avoid using tags [07:08] Oh, tags are very useful. And the shortcomings here in their behavior are bugs in a broad sense. [07:09] But the usual use-cases for tags don't involve very much touching after their laid, so the pain level impelling fixes is very low. [07:14] fullermd: the usual use-case for tags is as a more friendly way of refering tags, right? [07:15] refering revisions, I mean [07:54] * igc dinner [09:02] echo-area: Well... that's what they _are_. [09:30] fullermd: So what are the use case you refered to :) [09:31] use cases [09:32] Oh, things like tagging releases, or before/after tags on big reorganizations. [09:32] They tend to be set, and that's it; they don't move or get removed or anything after the fact. [09:33] Contrasted to tags of the LATEST_STABLE_VERSION sort, which do, on a regular basis. [09:33] The latter don't tend to get used much, so the pain they trigger isn't a high enough level to have thrust anybody toward implementing versioned tags. [09:35] oh, so bzr tag --force tag-name is really only used when a typo happens, right? [09:37] Generally, yah. [09:38] Having versioned tags would make the more dynamic cases work better. I don't think there's any movement _against_ adding them, but it's a fair bit of work. [09:39] So since the boundaries of the current system don't get hit very often... [09:40] * bialix waves at fullermd [09:43] Hey bialix :) [09:43] Ж-) [09:43] :-) [09:43] it was a smilie [09:44] Smilies are delicate. It's easy for them to be damaged in transit when they have to cover 10k miles or so. [09:47] is there any neat way to rebase a branch onto an older revision? i.e. to convert a bug fix against trunk into a suitable branch for merging into a previous release by rebasing against the common ancestor? [09:48] If it's just one or a few revs, I'd probably just cherrypick it; it would probably work as well as trying to rebase, and it'd be simpler. [09:48] yes, that's the only solution I have [09:49] I've done that before, IIRC. [09:49] But you have to specify all the rebase args manually. [09:50] rebase --onto seems to indicate that it will do the right thing, but it says "No revisions to rebase." [09:50] tumbleweed: bzr rebase --onto ONTO_REV -rFROM_REV..? [09:52] wgrant: nope [09:52] tumbleweed: What does it not do? [09:53] wgrant: it doesn't do anything. "Rebasing on ...\nNo revisions to rebase" [09:55] tumbleweed: Works fine for me. [09:56] fullermd: got it. I was trying to understand the current policy on tag propagation, it was a bit strange to me. [09:57] echo-area: Yeah. Since there's no history, any time the two ends differ we can't know why. The only thing we can non-destructively do is add a tag that the 'far' side is missing. [09:59] wgrant: http://paste.pocoo.org/show/192816/ [10:01] tumbleweed: Try '-r4..' [10:01] oh, I tried 3..4 but not 4.. [10:02] fullermd: thanks :) [10:04] wgrant: thanks, that should do the trick [10:05] tumbleweed: Excellent. === mrevell is now known as mrevell-lunch [12:34] hi, it appears that the last few OS X 10.6 releases of bzr have been compiled for 64-bit only. is that correct? If so, which version should I download for my 32-bit intel mac running 10.6? === mrevell-lunch is now known as mrevell [13:25] Hi. I want to hack on a project that is in hg. Is bzr-hg usable yet. Should I use it? [13:29] GaryvdM: doesn't roundtrip yet [13:30] GaryvdM: and dpush is.. unstable [13:32] jelmer: Ok. I would want roundtrip, so I'll use hg for now :-( [14:40] heya GaryvdM, jelmer [14:41] 'lo bialix [14:41] 'lo ? [14:41] hello? [14:41] jelmer: ^ [14:41] yep :-) [14:42] will know now [14:42] Hi bialix [14:42] GaryvdM: there is regressions in the qbzr trunk [14:43] you already saw perhaps [14:43] https://bugs.launchpad.net/bugs/545016 ? [14:43] Ubuntu bug 545016 in qbzr "qrevert selection doesn't get picked up" [Critical,Confirmed] [14:44] yep [14:46] bialix: I will look into it a little later [14:47] that's ok, [15:07] g'day. i'm using emailer.py and i'd like to add the branch to the subject line. would that just be self.branch(), you think? [15:15] vila: ping [15:18] guilhembi: pong [15:18] self.branch.nick, to answer my own question. [15:18] * Morbus waves. [15:25] Hi jam. [15:25] jam: If I recall correctly, the stumbling block with storing gdfo for revisions was knowing if ghosts have been fetched. [15:25] jam [15:26] jam: Why not store the known ghosts? [15:30] GaryvdM: the current issues that I know of are: [15:30] 1) You have to figure out how we want to store it [15:30] (in an existing index, in a new index, etc, etc.) [15:30] 2) When fetching you have to check to see if any ghosts are fetched [15:30] which means (as you mention) recording them [15:30] and in such a fashion that there is low overhead to query [15:31] all stuff that can be done [15:31] but *doing* it :) [15:31] jam: Ah - I see [15:31] you could probably live without (2) for the short term, and expect users to explicitly address it when they think it is wrong [15:31] (bzr rebuild-gdfo) [15:32] gdfo ? [15:32] jelmer: greatest-distance-from-origin [15:32] simplifies a lot of stuff like 'heads' checking [15:32] ahh [15:32] might make it possible to improve revno generation [15:32] but that is a bit unclear atm [15:32] Godzilla Destruction For Oneiromancy? [15:32] fwiw heads checking is important for bzr-git / bzr-hg [15:33] jelmer: put another way, the primary benefit of KnownGraph.heads() is that it has gdfo, while Graph.heads() does not [15:33] secondary is that it is done in C, but the first is an O() change, the latter is a constant factor change [15:34] Graphs.heads() is O(N^2) in some edge cases I believe, KG.heads() is O(delta) (I think always) [15:34] gdfo gives you a hint if rev X could possibly be a parent or child of Y, since a child gdfo is *always* > a parents [15:35] GaryvdM: last I talked to vila about it, he wanted to experiment in a plugin, and see where it got to. However, I think there have been enough things to work on, that he hasn't done much [15:35] KnownGraph loads the whole graph and *then* calculate gdfos, when we start *storing* gdfo, then we'll be able to incrementally load the graph for several operations (a different revno scheme can also be used and not require loading the whole graph as we do today) [15:36] welcome back jam :) [15:36] jam: When you say that it is unclear atm whether gdfo will improve revno generation, is that uncertainty coming form the reading of index? [15:36] Yeah, no time to work on this [15:37] vila: You got my response overnight? [15:37] fullermd: no [15:37] Hi vila [15:37] Oh. Hm. I don't even remember what it was about... [15:37] * fullermd digs. [15:38] fullermd: where FreeBSD put its crash files [15:38] ? [15:38] 16:16 vila: Yes, that's where crashdumps get copied to on boot, unless you change it. [15:38] fullermd: ok, I figured that \, [15:38] jam: Thanks [15:39] fullermd: there weren't enough space left for the last one so I didn't understood at first what was going on, and once I cleaned up, I got, of course, no more crash [15:39] GaryvdM: no, more how to compute the revnos given a limited scope of ancestry [15:40] I've done some work on it in the past, and it didn't show a huge gain [15:40] but that was without gdfo [15:40] * fullermd takes credit for fixing it :) [15:40] jam: [15:40] bah [15:40] however, the current revno *system* is also at fault [15:40] numbering from merge point versus branch point could improve it [15:40] etc [15:40] hi vila [15:41] long time no see :) [15:41] numbering from branch point can be trivially solved if people accept to number backwards :-) [15:41] jam: glad to see you back, I wasn't sure how long were your vacations [15:42] err, I meant numbering from merge point of course [15:43] vila: well 'trivially' is one way to put it [15:43] well, almost trivially, there is still the problem of the branch merged several times :) [15:43] jam, vila: hmm - backward numbering would cause some issues with qlog because it uses the revision numbers to group merge lines together. [15:44] That would break in the case where a branch is merged several times. [15:44] GaryvdM: right, though there is always the question of which view is more useful :) [15:45] GaryvdM: Well, if you had cheap ancestry checks you could them instead of relying on revnos which reflect them === salgado is now known as salgado-lunch [15:45] vila: though if it becomes a combinatorial problem, it will never be cheap [15:45] even if checking ancestry is O(1), doing NxN comparisons is still N^2 [15:45] it is just is better than N^2 * N^2 :) [15:46] the really good thing about the current merge_sorted code is that it really is close to O(N) [15:46] it just happens to be N when you really want O(local) [15:46] jam: sure but N being size(history) doesn't help :) [15:47] yup [15:47] certainly [15:47] though I wonder if caching the merge-sorted graph would be a better use than *just* gdfo [15:47] IIRC, igc experimented with this with pretty good results [15:48] because of stability guarantees, you could see some benefit by caching based on current tip [15:48] etc [15:48] (so cache every 100th rev, based on that rev tip, etc) [15:48] Again, I'm not sure about how mysql benefits, because of their push policy [15:48] but you could certainly find cases that would benefit [15:48] going back 1000 revs is better than 65k [15:49] the big problem with revno-cache is that it isn't invalidated when it should (AIUI) [15:49] though again, you need a partial algorithm that can build on an existing one [15:49] vila: I thought it was invalidated whenever the head changed [15:49] or are you meaning ghosts? [15:50] jam: I'm not sure all head changes are taken into account (pull --overwrite for example) [15:51] I thought when it read the cache it just said "if cur_tip != cacched_tip: rebuild" [15:51] Some people had issues with it because it would write the cache when a read operation. [15:52] may be, I also seem to remember that loading the cache for big histories became the bottleneck at one point, but I didn't closely follow [15:57] jam: I'm working on bug #375898 and could use some help, I'm a bit unclear about what TreeTransform._new_root is used for [15:57] Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [High,Confirmed] https://launchpad.net/bugs/375898 [15:57] vila: ugh, me no likey that code [15:57] hehe [15:57] but I did work on it recently, let me see if I can restore from memory dump [15:57] :-/ [15:57] One of the things I wanted to do is integrate qlog with igc's history cache. Vila: At Barcelona, you convinced me to wait on that as there was something better coming in the core (which I later assumed to be gdfo caching.) If gdfo caching is not happening atm, maybe I should maybe relook at qlog history cache integration? [15:57] jam: I know, want bzr revno to assist ? :) [15:58] jam: 4954 [15:58] jam: fixed bug #494269 [15:58] Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269 [15:58] _new_root is the transaction id representing the '/' in the directory [15:58] (in the working tree, etc) [15:59] GaryvdM: shudder [15:59] GaryvdM: well, if you are using the "get_known_graph" stuff, then you *are* using our current gdfo code [16:00] (which is also under the covers wrt Branch.get_revision_id_to_dotted_revno()) [16:00] however, that doesn't do partial loading [16:00] GaryvdM: summary: If you think that's critical for qlog, then go for it, but starting using KnownGraph may be a bett... what jam says :) [16:00] it *does* to semi-optimized full loading [16:00] s/to/do [16:01] vila: so one thing about bug #375898 and bug #494269... transform actions often have to call a new function when they are almost ready to be finished [16:01] Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [High,Confirmed] https://launchpad.net/bugs/375898 [16:01] Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269 [16:02] transform.fixup_new_roots() [16:02] added to _alter_files() [16:03] vila: qlog is not using KnownGraph, and it should be, but I'm really looking for a solution that does not have to load the whole graph, so gdfa *caching*. [16:03] the traceback I've got here is from do_merge() :-/ [16:03] *gdfo [16:03] sure [16:03] my point is that the merge code should probably be calling that [16:03] if it is poking at the transform object directly [16:04] GaryvdM: sure, then my remarks from Barcelona still stand, now, it's up to you to decide what you want and when :-/ [16:04] vila: somewhere near the end of _compute_transform [16:05] I'm not sure before/after resolve_conflicts [16:05] it *does* have a 'self.fix_root()' call [16:05] vila: Ok, got you. [16:05] It *might* be better to replace that with a different call to tt.fixup_new_roots() ? [16:05] I'm just trying to give hints, though. [16:05] GaryvdM: you need dotted revno caching [16:05] not just gdfo caching [16:06] aka, build a dotted revno from less than all ancesry [16:06] ancestry [16:06] and my initial point [16:06] is that given the current numbering scheme [16:06] that isn't always possible [16:06] long-lived integration branches require you to go back far enough to the initial branch point [16:07] the "branch merged several times" issue [16:07] I *do* have code for lazily computing dotted revnos [16:07] bound branches + bzr gui notification daemon (which is installed by default apparently) == my every commit issues *two* notifications with the same text [16:07] it does not take into account gdfo [16:08] and so suffers from race conditions while tracking ancestry stuff, and is O(N^2) [16:08] gdfo *would* help there [16:08] GaryvdM: and note that jam's remarks are for branches with append_revisions_only or similar workflows, in the mysql workflow were this isn't true, there is just nothing worth to cache (or too hard to define) [16:08] however, the revno numbering scheme still has the 'go back to branch point' issues [16:08] vila: there is always eventually a level that could be cached [16:08] jam: I see. [16:08] it may be 1000 revisions ago [16:08] but that is << 65k === deryck is now known as deryck[lunch] [16:09] GaryvdM: also, you can have 'multiple paths to NULL' issues [16:09] bzr certainly has that [16:09] jam: certainly, but which ? the tip revno itself is going up and down with a significant amplitude.... [16:09] with merging several plugins [16:09] if you find one of those revs [16:09] you have to walk the whole graph back to 0 [16:09] to be sure none of those revs were ever merged earlier [16:10] (gdfo is 1 for all the plugin rev0 that were merged) [16:10] *rev1 [16:10] vila: 'significant' relative to the 2000 already there? [16:10] +- 100 is still <10% of 2000 [16:10] if you are saying it is going 1000 to 3000 [16:10] then that is different [16:11] my point is that if the cache were at stages [16:11] vila, jam: I think I'm going to have a look at igc's plugin then. [16:11] 0 => 100 here, 100 => 200 here, etc [16:11] GaryvdM: though the other argument is that these are all edge cases, versus the common 'small feature branch' [16:12] it does depend on what you are benchmarking [16:12] the main reason I didn't push harder for the lazy revno stuff [16:12] is that merge_sorted is O(N), while lazy_revno was O(N^2) [16:12] and had the chance to make N still go to all_revs [16:12] so it made common cases faster [16:12] jam: I'm looking at big branches like mysql, OOo [16:12] but made edge cases *much* worse [16:13] OOo is a very special case, though, since it is (IIRC) almost completely linear [16:13] same with emacs [16:13] I guess not that special, since it does happen repeatedly :) [16:13] GaryvdM: qlog is usable on mysql branches, *I* use it at least for diagnosis (and it helps me a lot) [16:14] vila: I would like it to show you the main line in < 1 sec. [16:14] GaryvdM: don't display revnos in the initial display then :-P [16:15] GaryvdM: Or just cheat starting from last_revision_info() and decrementing, but that will work only if you display a single branch [16:16] GaryvdM: well, "time b.get_revision_id_to_revno_map()" for me for a mysql tree is 2.6s [16:16] vila: yes, I have thought about the second option. [16:16] you could pretty easily change the code to just show the mainline quickly [16:16] and load that in the background [16:17] sorry, TIMEIT says it is 1.29s to load the whole graph and produce the merge_sorted result on my machine [16:17] that is for 68k total revs and 2778 mainline [16:18] GaryvdM: I think cheating is actually pretty sensible [16:18] so I'll call it "cheating" [16:18] it also gives you a great opportunity to only load the last N revisions, which is whatever fits on the first page [16:18] but still load them 'in bulk' [16:18] * GaryvdM runs bzr qlog mysql --lsprof [16:19] GaryvdM: just to mention that IME, --lsprof gives you ~accurate timing of C functions, but python functions are slower by ~2x [16:20] jam: That sort of cheet would also help with OOo. [16:20] so the issue with OOo and emacs is that they are soon not going to be perfectly linear in the new revs [16:20] but you still end up paying to load 100k old revs [16:21] oh, and loading the whole graph for emacs is slower than the equivalent of mysql [16:21] for whatever reason 68k 'bushy' revs load a lot faster than 68k 'linear' ones [16:21] my guess is because you only have 1 rev that you can look for at any given time [16:21] and you may/may not have very good clustering [16:22] the fast-load code path exploits facts like 'john@arbash-meinel' tends to commit many times in a row [16:22] which probably doesn't happen as often in the emacs case [16:22] since people wait to commit to cvs because it disrupts other people [16:22] so you have more 'big' patches, and more author cycling [16:22] at least, that is my guess [16:23] So... the solution is for john@a-m to do more emacs dev? O8-} [16:23] fullermd: the solution is to rebase the whole ancestry of emacs, sorting it by author :) [16:24] Ah! Makes perfect sense. Easy to handle copyright issues then! [16:25] jam: hi, do you know how the rss feeds get updated on bazaar.canonical.com site? [16:25] bialix: cron script, IIRC [16:25] our latest qbzr release still not shown on the main page [16:26] bialix: what is the latest? 0.18.4? [16:26] jam: it seems cron does not work [16:26] yep, 0.18.4 [16:26] the newest entry on that page that I see is: 04-Mar-2010 [16:26] it is certainly possible the updater has failed [16:26] I don't maintain it personally, I think poolie would have a better idea [16:27] vila: what Time is it in France now? (Other than being past EOD for you :) [16:27] ok, I will try to ping poolie [16:27] We hit daylight savings time, so I have to adjust my "vincent should be working now" clock [16:27] 17:27, so not past EOD yet :) [16:27] vila: when do you hit daylight savings? [16:27] You first have to adjust it for *you* DST and then later on you'll have to do it for my DST :) [16:28] jam: No idea :) [16:28] I think the standard is in a couple weeks, closer to april 1st [16:28] usually last sunday of march? no? [16:28] I actually enjoy sunny days and that's good enough :) [16:29] 28 march as per bialix and confirmed at http://www.timeanddate.com/worldclock/timezone.html?n=195 [16:29] :-D [16:30] * GaryvdM going home. Will be back on line in 30 min. [16:31] * GaryvdM going home a little later [16:32] GaryvdM: :) [16:34] going home is for wimps? [16:34] real geeks send yourself to home via e-mail [16:35] You don't need to send yourself home, you just create a symbol table alias of yourself in Home. [16:36] vila: Are mysql still using 0.14? [16:38] GaryvdM: bzr ? format ? They use --1.9 AFAIK, migration to 2a pending but in the pipe [16:39] qbzr 0.14 [16:39] Sorry - I ment format 1.14 [16:40] I shall upgrade my local branch from 1.14 to 1.19 [16:43] * bialix wants to talk about scmproj, snapshots and nested trees [16:43] vila: can I ask your advice? [16:44] bialix: Don't ask to ask :) I'll do my best [16:44] that EOD thing scaries me [16:44] ok, so I have a problem I don't decide how to handle yet [16:45] I've implemented snapshots for scmproj [16:45] it means now I can record the state of all nested branches (components) in the project and then later get the exact copy of the project [16:45] great [16:45] I can even go from older state to newer state [16:45] but not in the reverse direction [16:46] because I'm using pull under the hood [16:46] GaryvdM: one smal issue, I'm not sure how --lsprof-file works wrt threads... [16:46] vila: so I can use pull --overwrite perhaps, but I have doubts [16:46] jam: We don't have any threads in qbzr yet. [16:46] GaryvdM: 1.9, not 1.14 [16:46] there is no 1.19 [16:47] just a 1.14 is a wt thing [16:47] Bla, so confused [16:47] 1.9 introduced btree? [16:47] vila: if some component has tip revision which is not the same as recorded in the snapshot [16:47] vila: I don't feel safe to simply overwrite it [16:48] bialix: you need some sort of check against that like we do in commit [16:48] vila: is it correct assumption to check every component is it "clean" , i.e. component's tip revision is the same as in the snapshot, and only then do pull --overwrite [16:48] vila: what you do in commit? [16:48] bialix: add a check that there is no uncommitted changes === beuno is now known as beuno-lunch [16:49] vila: right, I forgot about uncommitted changes [16:49] why do some files take so long to show up via launchpad after a commit?...i pushed a bunch of file and its obviously there cause i can download it but when i click to view it, there's nothing [16:49] bialix: wt.has_changes() [16:49] vila: so this one more check [16:50] dark_soul: what do you call 'so long', I generally see updates done in less than 5 minutes (even 2 minutes) [16:50] vila: well its update and its there...but some when you click on it to view the source code via the web interface, it shows nothing. some have it some dont [16:50] not sure if its because other files take longer to populate? [16:50] dark_soul: also, it depends whether or not you have write access because lp use a mirror internally for read-only operations and that's the mirroring that can be delayed [16:51] vila: more precisely about snapshots and components: if I have component alpha and his current snapshotted revision is 9, but in the reality on the disk it has revision 10, and I want to update project to the state where alpha was at 7. [16:51] dark_soul: if you mean that for the *same* commit some files show the update and some don't then file a bug [16:52] vila: I don't know is the rev 10 already pushed somewhere [16:52] vila: I don't feel safe to pull --over -r7 in that case [16:52] jam: please can we look at qlog together at uds and help me see if there are any performance improvement that can be made (other than the above mentioned cheat.) I'm think that some pyrex code may help. [16:52] vila: it is the same commit..to clarify, it is updated..you can download the file and everything is there. it's only when you click to view the file via the web, some show and some dont [16:52] bialix: yup [16:52] vila: I wonder if this case somehow addressed in the real nested trees [16:52]