| jelmer | mwhudson: there isn't really an alternative, you can't seek in the mercurial bundle files | 00:19 |
|---|---|---|
| mwhudson | jelmer: fair enough | 00:20 |
| jelmer | 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:21 |
| mwhudson | hm | 00:23 |
| mwhudson | jelmer: it seems a bit like when revision_id is passed to FromHgRepository.fetch, some extra revisions are imported | 00:24 |
| mwhudson | beyond the one requested | 00:24 |
| mwhudson | jelmer: does this sound possible to you? | 00:26 |
| mwhudson | i guess this means source._hgrepo.changegroup is returning more than we're asking for | 00:29 |
| jelmer | mwhudson: hmm | 00:30 |
| mwhudson | heads() returns a 1 element set, missing is a 1-element set but we go around the loop in _unpack_changesets twice | 00:31 |
| jelmer | 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 |
| jelmer | mwhudson: can you file a bug? | 00:31 |
| mwhudson | jelmer ok | 00:33 |
| mwhudson | jelmer: https://bugs.edge.launchpad.net/bzr-hg/+bug/544701 | 00:41 |
| ubottu | Ubuntu bug 544701 in bzr-hg "pull -r $rev doesn't limit revisions converted" [Undecided,New] | 00:42 |
| micahg | what's the proper way to retag a branch | 01:01 |
| RAOF | bzr tag -d $MYTAG; bzr tag -r$I_WANT_TO_TAG_THIS_REVISION $MYTAG, from memory. | 01:04 |
| micahg | RAOF: right, but when I push I get a conflicting tag errro | 01:04 |
| micahg | do I have to push --overwrite? | 01:04 |
| RAOF | I remember just pushing, but maybe I'd also added some revisions. | 01:05 |
| RAOF | I'm unsure here; I only remember it Just Working. | 01:06 |
| micahg | RAOF: ok, thanks we worked around it anyways | 01:08 |
| GungaDin | How can I branch off a revision that was already branch off my branch? | 01:44 |
| GungaDin | or rather, how do I check out a branch by one of its revision ids? | 01:46 |
| lifeless | GungaDin: branch -r XXXXX source | 02:11 |
| === jamesh__ is now known as jamesh | ||
| mkanat | mwhudson: Thanks! We're waiting on Francis for some administrative details before I continue, FYI. | 04:06 |
| mwhudson | mkanat: i'm not sure the latest info is very useful :/ | 04:06 |
| mkanat | mwhudson: Okay. I'll take a look at it once we handle the administrative stuff. | 04:35 |
| poolie | GungaDin: still here? did you get an answer? | 04:41 |
| poolie | you can do 'bzr branch -rN FROM TO' | 04:41 |
| GungaDin | yeah, managed already | 05:00 |
| GungaDin | thx | 05:00 |
| dcoles | Hmm... You think that there's any chance LP would support access to Bazaar repos with a git client? | 05:05 |
| RAOF | It's technically possible, but ...uuurgh :) | 05:06 |
| dcoles | bzr-git almost makes this look feasible, and the bazaar repositoires are rich enough to be a backend for git | 05:06 |
| RAOF | Right; they store more info than git does. | 05:06 |
| dcoles | RAOF: I agree. I'm a bazaar fan myself | 05:06 |
| RAOF | It's possible to do this locally; bzr serve --git, for example. | 05:06 |
| dcoles | I just think it would a technically "cool" thing to be able to do on a LP level | 05:07 |
| dcoles | Heh. Well, mostly (it crashes at the moment for me) | 05:07 |
| RAOF | 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 |
| mwhudson | i think the performance would be pretty terrible currently | 05:08 |
| dcoles | Going to try and work out why when I get a spare couple of hours | 05:08 |
| dcoles | mwhudson: That being the performance of bzr-upload-pack and bzr-receive-pack when emulating a git repo? | 05:09 |
| * mkanat knows that pack-to-2a conversion is slooooow. | 05:10 | |
| mwhudson | dcoles: basically yes | 05:12 |
| mwhudson | maybe going bzr->git will be faster than t'other way around | 05:12 |
| * dcoles relises he's late for class - runs | 05:20 | |
| poolie | igc, hi | 05:21 |
| poolie | igc, i'm going to make 2.0.5 and 2.1.1 tarballs | 05:22 |
| echo-area | 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:35 |
| echo-area | 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:37 |
| echo-area | 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 |
| echo-area | :( That's a typo. I mean, So branches appear to be better | 05:43 |
| igc | poolie: sounds good | 05:51 |
| poolie | echo-area: if you expect it to continue changing, a branch is better | 06:00 |
| poolie | if it's "this is 2.0.5" and it won't normally change, that's better | 06:00 |
| poolie | if you need to change it in another branch, use 'bzr tag -d PLACE " | 06:00 |
| poolie | igc, so your packaging changes only apply to 2.2 right? | 06:01 |
| poolie | we couldn't run them kind of externally against 2.0? | 06:01 |
| igc | polie: right | 06:01 |
| poolie | i suppose it would be risky even if it worked | 06:01 |
| igc | too risky IMO | 06:01 |
| echo-area | poolie: thanks. | 06:12 |
| echo-area | deletion of tags doesn't get propagated, is this intentional? | 06:42 |
| fullermd | Sorta. Any change to tags doesn't propogate unless you force it, since there's no way to know what changed. | 06:49 |
| echo-area | fullermd: By "force it", do you mean --overwrite? That seems to only work for revision changes of tags. | 06:52 |
| echo-area | 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 | 06:55 |
| fullermd | Oh, tags are very useful. And the shortcomings here in their behavior are bugs in a broad sense. | 07:08 |
| fullermd | 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:09 |
| echo-area | fullermd: the usual use-case for tags is as a more friendly way of refering tags, right? | 07:14 |
| echo-area | refering revisions, I mean | 07:15 |
| * igc dinner | 07:54 | |
| fullermd | echo-area: Well... that's what they _are_. | 09:02 |
| echo-area | fullermd: So what are the use case you refered to :) | 09:30 |
| echo-area | use cases | 09:31 |
| fullermd | Oh, things like tagging releases, or before/after tags on big reorganizations. | 09:32 |
| fullermd | They tend to be set, and that's it; they don't move or get removed or anything after the fact. | 09:32 |
| fullermd | Contrasted to tags of the LATEST_STABLE_VERSION sort, which do, on a regular basis. | 09:33 |
| fullermd | 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:33 |
| echo-area | oh, so bzr tag --force tag-name is really only used when a typo happens, right? | 09:35 |
| fullermd | Generally, yah. | 09:37 |
| fullermd | 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:38 |
| fullermd | So since the boundaries of the current system don't get hit very often... | 09:39 |
| * bialix waves at fullermd | 09:40 | |
| fullermd | Hey bialix :) | 09:43 |
| bialix | Ж-) | 09:43 |
| bialix | :-) | 09:43 |
| bialix | it was a smilie | 09:43 |
| fullermd | Smilies are delicate. It's easy for them to be damaged in transit when they have to cover 10k miles or so. | 09:44 |
| tumbleweed | 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:47 |
| fullermd | 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 |
| tumbleweed | yes, that's the only solution I have | 09:48 |
| wgrant | I've done that before, IIRC. | 09:49 |
| wgrant | But you have to specify all the rebase args manually. | 09:49 |
| tumbleweed | rebase --onto seems to indicate that it will do the right thing, but it says "No revisions to rebase." | 09:50 |
| wgrant | tumbleweed: bzr rebase --onto ONTO_REV -rFROM_REV..? | 09:50 |
| tumbleweed | wgrant: nope | 09:52 |
| wgrant | tumbleweed: What does it not do? | 09:52 |
| tumbleweed | wgrant: it doesn't do anything. "Rebasing on ...\nNo revisions to rebase" | 09:53 |
| wgrant | tumbleweed: Works fine for me. | 09:55 |
| echo-area | fullermd: got it. I was trying to understand the current policy on tag propagation, it was a bit strange to me. | 09:56 |
| fullermd | 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:57 |
| tumbleweed | wgrant: http://paste.pocoo.org/show/192816/ | 09:59 |
| wgrant | tumbleweed: Try '-r4..' | 10:01 |
| tumbleweed | oh, I tried 3..4 but not 4.. | 10:01 |
| echo-area | fullermd: thanks :) | 10:02 |
| tumbleweed | wgrant: thanks, that should do the trick | 10:04 |
| wgrant | tumbleweed: Excellent. | 10:05 |
| === mrevell is now known as mrevell-lunch | ||
| flawrence | 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? | 12:34 |
| === mrevell-lunch is now known as mrevell | ||
| GaryvdM | Hi. I want to hack on a project that is in hg. Is bzr-hg usable yet. Should I use it? | 13:25 |
| jelmer | GaryvdM: doesn't roundtrip yet | 13:29 |
| jelmer | GaryvdM: and dpush is.. unstable | 13:30 |
| GaryvdM | jelmer: Ok. I would want roundtrip, so I'll use hg for now :-( | 13:32 |
| bialix | heya GaryvdM, jelmer | 14:40 |
| jelmer | 'lo bialix | 14:41 |
| bialix | 'lo ? | 14:41 |
| bialix | hello? | 14:41 |
| bialix | jelmer: ^ | 14:41 |
| jelmer | yep :-) | 14:41 |
| bialix | will know now | 14:42 |
| GaryvdM | Hi bialix | 14:42 |
| bialix | GaryvdM: there is regressions in the qbzr trunk | 14:42 |
| bialix | you already saw perhaps | 14:43 |
| GaryvdM | https://bugs.launchpad.net/bugs/545016 ? | 14:43 |
| ubottu | Ubuntu bug 545016 in qbzr "qrevert selection doesn't get picked up" [Critical,Confirmed] | 14:43 |
| bialix | yep | 14:44 |
| GaryvdM | bialix: I will look into it a little later | 14:46 |
| bialix | that's ok, | 14:47 |
| Morbus | 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:07 |
| guilhembi | vila: ping | 15:15 |
| vila | guilhembi: pong | 15:18 |
| Morbus | self.branch.nick, to answer my own question. | 15:18 |
| * Morbus waves. | 15:18 | |
| GaryvdM | Hi jam. | 15:25 |
| GaryvdM | jam: If I recall correctly, the stumbling block with storing gdfo for revisions was knowing if ghosts have been fetched. | 15:25 |
| GaryvdM | jam | 15:25 |
| GaryvdM | jam: Why not store the known ghosts? | 15:26 |
| jam | GaryvdM: the current issues that I know of are: | 15:30 |
| jam | 1) You have to figure out how we want to store it | 15:30 |
| jam | (in an existing index, in a new index, etc, etc.) | 15:30 |
| jam | 2) When fetching you have to check to see if any ghosts are fetched | 15:30 |
| jam | which means (as you mention) recording them | 15:30 |
| jam | and in such a fashion that there is low overhead to query | 15:30 |
| jam | all stuff that can be done | 15:31 |
| jam | but *doing* it :) | 15:31 |
| GaryvdM | jam: Ah - I see | 15:31 |
| jam | 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 |
| jam | (bzr rebuild-gdfo) | 15:31 |
| jelmer | gdfo ? | 15:32 |
| jam | jelmer: greatest-distance-from-origin | 15:32 |
| jam | simplifies a lot of stuff like 'heads' checking | 15:32 |
| jelmer | ahh | 15:32 |
| jam | might make it possible to improve revno generation | 15:32 |
| jam | but that is a bit unclear atm | 15:32 |
| fullermd | Godzilla Destruction For Oneiromancy? | 15:32 |
| jelmer | fwiw heads checking is important for bzr-git / bzr-hg | 15:32 |
| jam | jelmer: put another way, the primary benefit of KnownGraph.heads() is that it has gdfo, while Graph.heads() does not | 15:33 |
| jam | secondary is that it is done in C, but the first is an O() change, the latter is a constant factor change | 15:33 |
| jam | Graphs.heads() is O(N^2) in some edge cases I believe, KG.heads() is O(delta) (I think always) | 15:34 |
| jam | 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:34 |
| jam | 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 |
| vila | 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:35 |
| vila | welcome back jam :) | 15:36 |
| GaryvdM | 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 |
| vila | Yeah, no time to work on this | 15:36 |
| fullermd | vila: You got my response overnight? | 15:37 |
| vila | fullermd: no | 15:37 |
| GaryvdM | Hi vila | 15:37 |
| fullermd | Oh. Hm. I don't even remember what it was about... | 15:37 |
| * fullermd digs. | 15:37 | |
| vila | fullermd: where FreeBSD put its crash files | 15:38 |
| vila | ? | 15:38 |
| fullermd | 16:16 <fullermd> vila: Yes, that's where crashdumps get copied to on boot, unless you change it. | 15:38 |
| vila | fullermd: ok, I figured that \, | 15:38 |
| jelmer | jam: Thanks | 15:38 |
| vila | 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 |
| jam | GaryvdM: no, more how to compute the revnos given a limited scope of ancestry | 15:39 |
| jam | I've done some work on it in the past, and it didn't show a huge gain | 15:40 |
| jam | but that was without gdfo | 15:40 |
| * fullermd takes credit for fixing it :) | 15:40 | |
| vila | jam: | 15:40 |
| vila | bah | 15:40 |
| jam | however, the current revno *system* is also at fault | 15:40 |
| jam | numbering from merge point versus branch point could improve it | 15:40 |
| jam | etc | 15:40 |
| jam | hi vila | 15:40 |
| jam | long time no see :) | 15:41 |
| vila | numbering from branch point can be trivially solved if people accept to number backwards :-) | 15:41 |
| vila | jam: glad to see you back, I wasn't sure how long were your vacations | 15:41 |
| vila | err, I meant numbering from merge point of course | 15:42 |
| jam | vila: well 'trivially' is one way to put it | 15:43 |
| vila | well, almost trivially, there is still the problem of the branch merged several times :) | 15:43 |
| GaryvdM | jam, vila: hmm - backward numbering would cause some issues with qlog because it uses the revision numbers to group merge lines together. | 15:43 |
| GaryvdM | That would break in the case where a branch is merged several times. | 15:44 |
| jam | GaryvdM: right, though there is always the question of which view is more useful :) | 15:44 |
| vila | GaryvdM: Well, if you had cheap ancestry checks you could them instead of relying on revnos which reflect them | 15:45 |
| === salgado is now known as salgado-lunch | ||
| jam | vila: though if it becomes a combinatorial problem, it will never be cheap | 15:45 |
| jam | even if checking ancestry is O(1), doing NxN comparisons is still N^2 | 15:45 |
| jam | it is just is better than N^2 * N^2 :) | 15:45 |
| jam | the really good thing about the current merge_sorted code is that it really is close to O(N) | 15:46 |
| jam | it just happens to be N when you really want O(local) | 15:46 |
| vila | jam: sure but N being size(history) doesn't help :) | 15:46 |
| vila | yup | 15:47 |
| jam | certainly | 15:47 |
| jam | though I wonder if caching the merge-sorted graph would be a better use than *just* gdfo | 15:47 |
| jam | IIRC, igc experimented with this with pretty good results | 15:47 |
| jam | because of stability guarantees, you could see some benefit by caching based on current tip | 15:48 |
| jam | etc | 15:48 |
| jam | (so cache every 100th rev, based on that rev tip, etc) | 15:48 |
| jam | Again, I'm not sure about how mysql benefits, because of their push policy | 15:48 |
| jam | but you could certainly find cases that would benefit | 15:48 |
| jam | going back 1000 revs is better than 65k | 15:48 |
| vila | the big problem with revno-cache is that it isn't invalidated when it should (AIUI) | 15:49 |
| jam | though again, you need a partial algorithm that can build on an existing one | 15:49 |
| jam | vila: I thought it was invalidated whenever the head changed | 15:49 |
| jam | or are you meaning ghosts? | 15:49 |
| vila | jam: I'm not sure all head changes are taken into account (pull --overwrite for example) | 15:50 |
| jam | I thought when it read the cache it just said "if cur_tip != cacched_tip: rebuild" | 15:51 |
| GaryvdM | Some people had issues with it because it would write the cache when a read operation. | 15:51 |
| vila | 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:52 |
| vila | 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 |
| ubottu | 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 |
| jam | vila: ugh, me no likey that code | 15:57 |
| vila | hehe | 15:57 |
| jam | but I did work on it recently, let me see if I can restore from memory dump | 15:57 |
| vila | :-/ | 15:57 |
| GaryvdM | 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 |
| vila | jam: I know, want bzr revno to assist ? :) | 15:57 |
| vila | jam: 4954 | 15:58 |
| vila | jam: fixed bug #494269 | 15:58 |
| ubottu | Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269 | 15:58 |
| jam | _new_root is the transaction id representing the '/' in the directory | 15:58 |
| jam | (in the working tree, etc) | 15:58 |
| vila | GaryvdM: shudder | 15:59 |
| jam | GaryvdM: well, if you are using the "get_known_graph" stuff, then you *are* using our current gdfo code | 15:59 |
| jam | (which is also under the covers wrt Branch.get_revision_id_to_dotted_revno()) | 16:00 |
| jam | however, that doesn't do partial loading | 16:00 |
| vila | 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 |
| jam | it *does* to semi-optimized full loading | 16:00 |
| jam | s/to/do | 16:00 |
| jam | 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 |
| ubottu | 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 |
| ubottu | Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269 | 16:01 |
| jam | transform.fixup_new_roots() | 16:02 |
| jam | added to _alter_files() | 16:02 |
| GaryvdM | 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 |
| vila | the traceback I've got here is from do_merge() :-/ | 16:03 |
| GaryvdM | *gdfo | 16:03 |
| jam | sure | 16:03 |
| jam | my point is that the merge code should probably be calling that | 16:03 |
| jam | if it is poking at the transform object directly | 16:03 |
| vila | GaryvdM: sure, then my remarks from Barcelona still stand, now, it's up to you to decide what you want and when :-/ | 16:04 |
| jam | vila: somewhere near the end of _compute_transform | 16:04 |
| jam | I'm not sure before/after resolve_conflicts | 16:05 |
| jam | it *does* have a 'self.fix_root()' call | 16:05 |
| GaryvdM | vila: Ok, got you. | 16:05 |
| jam | It *might* be better to replace that with a different call to tt.fixup_new_roots() ? | 16:05 |
| jam | I'm just trying to give hints, though. | 16:05 |
| jam | GaryvdM: you need dotted revno caching | 16:05 |
| jam | not just gdfo caching | 16:05 |
| jam | aka, build a dotted revno from less than all ancesry | 16:06 |
| jam | ancestry | 16:06 |
| jam | and my initial point | 16:06 |
| jam | is that given the current numbering scheme | 16:06 |
| jam | that isn't always possible | 16:06 |
| jam | long-lived integration branches require you to go back far enough to the initial branch point | 16:06 |
| jam | the "branch merged several times" issue | 16:07 |
| jam | I *do* have code for lazily computing dotted revnos | 16:07 |
| mgedmin | bound branches + bzr gui notification daemon (which is installed by default apparently) == my every commit issues *two* notifications with the same text | 16:07 |
| jam | it does not take into account gdfo | 16:07 |
| jam | and so suffers from race conditions while tracking ancestry stuff, and is O(N^2) | 16:08 |
| jam | gdfo *would* help there | 16:08 |
| vila | 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 |
| jam | however, the revno numbering scheme still has the 'go back to branch point' issues | 16:08 |
| jam | vila: there is always eventually a level that could be cached | 16:08 |
| GaryvdM | jam: I see. | 16:08 |
| jam | it may be 1000 revisions ago | 16:08 |
| jam | but that is << 65k | 16:08 |
| === deryck is now known as deryck[lunch] | ||
| jam | GaryvdM: also, you can have 'multiple paths to NULL' issues | 16:09 |
| jam | bzr certainly has that | 16:09 |
| vila | jam: certainly, but which ? the tip revno itself is going up and down with a significant amplitude.... | 16:09 |
| jam | with merging several plugins | 16:09 |
| jam | if you find one of those revs | 16:09 |
| jam | you have to walk the whole graph back to 0 | 16:09 |
| jam | to be sure none of those revs were ever merged earlier | 16:09 |
| jam | (gdfo is 1 for all the plugin rev0 that were merged) | 16:10 |
| jam | *rev1 | 16:10 |
| jam | vila: 'significant' relative to the 2000 already there? | 16:10 |
| jam | +- 100 is still <10% of 2000 | 16:10 |
| jam | if you are saying it is going 1000 to 3000 | 16:10 |
| jam | then that is different | 16:10 |
| jam | my point is that if the cache were at stages | 16:11 |
| GaryvdM | vila, jam: I think I'm going to have a look at igc's plugin then. | 16:11 |
| jam | 0 => 100 here, 100 => 200 here, etc | 16:11 |
| jam | GaryvdM: though the other argument is that these are all edge cases, versus the common 'small feature branch' | 16:11 |
| jam | it does depend on what you are benchmarking | 16:12 |
| jam | the main reason I didn't push harder for the lazy revno stuff | 16:12 |
| jam | is that merge_sorted is O(N), while lazy_revno was O(N^2) | 16:12 |
| jam | and had the chance to make N still go to all_revs | 16:12 |
| jam | so it made common cases faster | 16:12 |
| GaryvdM | jam: I'm looking at big branches like mysql, OOo | 16:12 |
| jam | but made edge cases *much* worse | 16:12 |
| jam | OOo is a very special case, though, since it is (IIRC) almost completely linear | 16:13 |
| jam | same with emacs | 16:13 |
| jam | I guess not that special, since it does happen repeatedly :) | 16:13 |
| vila | GaryvdM: qlog is usable on mysql branches, *I* use it at least for diagnosis (and it helps me a lot) | 16:13 |
| GaryvdM | vila: I would like it to show you the main line in < 1 sec. | 16:14 |
| vila | GaryvdM: don't display revnos in the initial display then :-P | 16:14 |
| vila | GaryvdM: Or just cheat starting from last_revision_info() and decrementing, but that will work only if you display a single branch | 16:15 |
| jam | GaryvdM: well, "time b.get_revision_id_to_revno_map()" for me for a mysql tree is 2.6s | 16:16 |
| GaryvdM | vila: yes, I have thought about the second option. | 16:16 |
| jam | you could pretty easily change the code to just show the mainline quickly | 16:16 |
| jam | and load that in the background | 16:16 |
| jam | sorry, TIMEIT says it is 1.29s to load the whole graph and produce the merge_sorted result on my machine | 16:17 |
| jam | that is for 68k total revs and 2778 mainline | 16:17 |
| jam | GaryvdM: I think cheating is actually pretty sensible | 16:18 |
| jam | so I'll call it "cheating" | 16:18 |
| jam | it also gives you a great opportunity to only load the last N revisions, which is whatever fits on the first page | 16:18 |
| jam | but still load them 'in bulk' | 16:18 |
| * GaryvdM runs bzr qlog mysql --lsprof | 16:18 | |
| jam | GaryvdM: just to mention that IME, --lsprof gives you ~accurate timing of C functions, but python functions are slower by ~2x | 16:19 |
| GaryvdM | jam: That sort of cheet would also help with OOo. | 16:20 |
| jam | so the issue with OOo and emacs is that they are soon not going to be perfectly linear in the new revs | 16:20 |
| jam | but you still end up paying to load 100k old revs | 16:20 |
| jam | oh, and loading the whole graph for emacs is slower than the equivalent of mysql | 16:21 |
| jam | for whatever reason 68k 'bushy' revs load a lot faster than 68k 'linear' ones | 16:21 |
| jam | my guess is because you only have 1 rev that you can look for at any given time | 16:21 |
| jam | and you may/may not have very good clustering | 16:21 |
| jam | the fast-load code path exploits facts like 'john@arbash-meinel' tends to commit many times in a row | 16:22 |
| jam | which probably doesn't happen as often in the emacs case | 16:22 |
| jam | since people wait to commit to cvs because it disrupts other people | 16:22 |
| jam | so you have more 'big' patches, and more author cycling | 16:22 |
| jam | at least, that is my guess | 16:22 |
| fullermd | So... the solution is for john@a-m to do more emacs dev? O8-} | 16:23 |
| jam | fullermd: the solution is to rebase the whole ancestry of emacs, sorting it by author :) | 16:23 |
| fullermd | Ah! Makes perfect sense. Easy to handle copyright issues then! | 16:24 |
| bialix | jam: hi, do you know how the rss feeds get updated on bazaar.canonical.com site? | 16:25 |
| jam | bialix: cron script, IIRC | 16:25 |
| bialix | our latest qbzr release still not shown on the main page | 16:25 |
| jam | bialix: what is the latest? 0.18.4? | 16:26 |
| bialix | jam: it seems cron does not work | 16:26 |
| bialix | yep, 0.18.4 | 16:26 |
| jam | the newest entry on that page that I see is: 04-Mar-2010 | 16:26 |
| jam | it is certainly possible the updater has failed | 16:26 |
| jam | I don't maintain it personally, I think poolie would have a better idea | 16:26 |
| jam | vila: what Time is it in France now? (Other than being past EOD for you :) | 16:27 |
| bialix | ok, I will try to ping poolie | 16:27 |
| jam | We hit daylight savings time, so I have to adjust my "vincent should be working now" clock | 16:27 |
| vila | 17:27, so not past EOD yet :) | 16:27 |
| jam | vila: when do you hit daylight savings? | 16:27 |
| vila | You first have to adjust it for *you* DST and then later on you'll have to do it for my DST :) | 16:27 |
| vila | jam: No idea :) | 16:28 |
| jam | I think the standard is in a couple weeks, closer to april 1st | 16:28 |
| bialix | usually last sunday of march? no? | 16:28 |
| vila | I actually enjoy sunny days and that's good enough :) | 16:28 |
| vila | 28 march as per bialix and confirmed at http://www.timeanddate.com/worldclock/timezone.html?n=195 | 16:29 |
| vila | :-D | 16:29 |
| * GaryvdM going home. Will be back on line in 30 min. | 16:30 | |
| * GaryvdM going home a little later | 16:31 | |
| vila | GaryvdM: :) | 16:32 |
| bialix | going home is for wimps? | 16:34 |
| bialix | real geeks send yourself to home via e-mail | 16:34 |
| fullermd | You don't need to send yourself home, you just create a symbol table alias of yourself in Home. | 16:35 |
| GaryvdM | vila: Are mysql still using 0.14? | 16:36 |
| vila | GaryvdM: bzr ? format ? They use --1.9 AFAIK, migration to 2a pending but in the pipe | 16:38 |
| bialix | qbzr 0.14 | 16:39 |
| GaryvdM | Sorry - I ment format 1.14 | 16:39 |
| GaryvdM | I shall upgrade my local branch from 1.14 to 1.19 | 16:40 |
| * bialix wants to talk about scmproj, snapshots and nested trees | 16:43 | |
| bialix | vila: can I ask your advice? | 16:43 |
| vila | bialix: Don't ask to ask :) I'll do my best | 16:44 |
| bialix | that EOD thing scaries me | 16:44 |
| bialix | ok, so I have a problem I don't decide how to handle yet | 16:44 |
| bialix | I've implemented snapshots for scmproj | 16:45 |
| bialix | 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 |
| vila | great | 16:45 |
| bialix | I can even go from older state to newer state | 16:45 |
| bialix | but not in the reverse direction | 16:45 |
| bialix | because I'm using pull under the hood | 16:46 |
| jam | GaryvdM: one smal issue, I'm not sure how --lsprof-file works wrt threads... | 16:46 |
| bialix | vila: so I can use pull --overwrite perhaps, but I have doubts | 16:46 |
| GaryvdM | jam: We don't have any threads in qbzr yet. | 16:46 |
| jam | GaryvdM: 1.9, not 1.14 | 16:46 |
| jam | there is no 1.19 | 16:46 |
| jam | just a 1.14 is a wt thing | 16:47 |
| GaryvdM | Bla, so confused | 16:47 |
| GaryvdM | 1.9 introduced btree? | 16:47 |
| bialix | vila: if some component has tip revision which is not the same as recorded in the snapshot | 16:47 |
| bialix | vila: I don't feel safe to simply overwrite it | 16:47 |
| vila | bialix: you need some sort of check against that like we do in commit | 16:48 |
| bialix | 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 |
| bialix | vila: what you do in commit? | 16:48 |
| vila | bialix: add a check that there is no uncommitted changes | 16:48 |
| === beuno is now known as beuno-lunch | ||
| bialix | vila: right, I forgot about uncommitted changes | 16:49 |
| dark_soul | 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 |
| vila | bialix: wt.has_changes() | 16:49 |
| bialix | vila: so this one more check | 16:49 |
| vila | dark_soul: what do you call 'so long', I generally see updates done in less than 5 minutes (even 2 minutes) | 16:50 |
| dark_soul | 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 |
| dark_soul | not sure if its because other files take longer to populate? | 16:50 |
| vila | 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:50 |
| bialix | 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 |
| vila | dark_soul: if you mean that for the *same* commit some files show the update and some don't then file a bug | 16:51 |
| bialix | vila: I don't know is the rev 10 already pushed somewhere | 16:52 |
| bialix | vila: I don't feel safe to pull --over -r7 in that case | 16:52 |
| GaryvdM | 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 |
| dark_soul | 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 |
| vila | bialix: yup | 16:52 |
| bialix | vila: I wonder if this case somehow addressed in the real nested trees | 16:52 |
| GaryvdM | dark_soul: url? | 16:52 |
| vila | bialix: no idea, I didn't look at the actual implementation, but it should | 16:54 |
| bialix | abentley: ping, I have question about bzrtools: clean-tree --ignored: I need to make it aware of ignored nested branches. What the best way for me to address this problem? Introduce new command-line option? | 16:54 |
| dark_soul | okay..odd now all of them are showing. weird | 16:54 |
| abentley | bialix, it's now in core, not bzrtools. | 16:55 |
| bialix | abentley: clean-tree? | 16:55 |
| abentley | bialix, yes. | 16:55 |
| jam | GaryvdM: I'd be happy to | 16:56 |
| bialix | abentley: somehow I've missed this | 16:56 |
| GaryvdM | jam: Thanks. | 16:56 |
| bialix | abentley: anyway, the question remains the same | 16:56 |
| abentley | bialix, right. Could you explain a little more? These are nested trees that you've included in .bzrignore, but don't want to delete? | 16:57 |
| dark_soul | oh..i think i know what i did wrong...or it could be a bug | 16:57 |
| bialix | vila: so, what is your advice here: do only safety check for revno, and allow user to force pull via command-line flag? | 16:57 |
| bialix | abentley: I have scmproj plugin which emulates nested trees | 16:57 |
| jam | GaryvdM: a trivial run seems to indicate it takes 2+s to load PyQt | 16:57 |
| bialix | abentley: it doing some just by keeping collection of nested branches | 16:57 |
| dark_soul | you know the website where you browse your file. you got two url which is divided by the ":" (slice) .. | 16:58 |
| jam | though I guess it is faster the second time | 16:58 |
| dark_soul | if i click anything to the left..it shows the code..if i click anything to the right, it will not show the code | 16:58 |
| abentley | bialix, I don't think you would need to ignore those branches. bzr should just skip them anyway. | 16:58 |
| bialix | abentley: those nested branches are ignored usually from root branch, otherwise they become visible in the status | 16:58 |
| === salgado-lunch is now known as salgado | ||
| GaryvdM | jam: I would so like to try fix that! | 16:58 |
| vila | bialix: yup --force | 16:59 |
| bialix | abentley: if I don't ignore them I see them every time, and it's irritate | 16:59 |
| jam | GaryvdM: what is the "exec_" loop? | 16:59 |
| GaryvdM | Qt main event loop | 17:00 |
| jam | and why "exec_" and not "exec()" ? | 17:00 |
| abentley | bialix, I agree. I don't think status should show them, since add won't add them. | 17:00 |
| bialix | vila: ok, thanks for the help :-) | 17:00 |
| GaryvdM | jam: I think exec is a python keyword? | 17:00 |
| jam | it is, but I thought it had to be standalone | 17:01 |
| vila | dark_soul: do you have some url for us ? Tt could help understanding you | 17:01 |
| bialix | abentley: yes, you're right. but as short term solution I think I can just teach clean-tree to not delete them without special permission from user. Is is sounds reasonable? | 17:01 |
| dark_soul | vila: yes..give me a sec..i got a meeting. brb | 17:01 |
| jam | hmm.. I guess I'm wrong, or at least they changed the name. I would have sworn I used to call .exec()... | 17:02 |
| jam | no biggie | 17:02 |
| jam | I guess I just thought it was something new | 17:02 |
| Boingo-OSI | Hello all. I am trying to figure out the correct setup for bzr in the following senario... There is a central development server that multiple users would access and commit to. The central server needs to have a working copy running (PHP based website). At certain intervals, the code will be uploaded (using bzr upload) to the production server. I can figure it all out except the working copy on the server so that when a person commits, those change | 17:02 |
| abentley | bialix, I think it's reasonable to skip ignored trees by default, but I think it would be better to just fix status. | 17:02 |
| jam | GaryvdM: http://paste.ubuntu.com/400075/ | 17:03 |
| jam | so this seems to be the bulk of it | 17:03 |
| jam | which is taking 15s to "load_graph_all_revisions" | 17:03 |
| jam | 7s for 'process_graph_parents' and 8s in 'compute_loaded_graph' | 17:04 |
| bialix | abentley: re fixing status: to do so bzr should check every unknown directory for the presence of tree/branch. is not this will be performance penalty? | 17:04 |
| jam | note, as far as --lsprof issues | 17:04 |
| jam | running with --lsprof takes 18s | 17:04 |
| jam | without takes 6 | 17:04 |
| jam | so there is some significant overhead associated with profiling | 17:04 |
| GaryvdM | load_graph_all_revisions and process_graph_parents should be made faster with KnownGraph | 17:05 |
| jam | ah, and the other problem is that you are directly using MergeSorter? | 17:06 |
| jam | hmm... maybe not | 17:06 |
| jam | it seems that tsort.merge_sort does | 17:06 |
| jam | though we made tsort.topo_sort() use KnownGraph | 17:07 |
| abentley | bialix, I suppose it could be, but unless it's a significant penalty, I think the UI improvement justifies it. | 17:07 |
| jam | GaryvdM: I think I remember why... the api is different | 17:07 |
| bialix | abentley: ok | 17:07 |
| jam | KnownGraph.merge_sort() returns objects | 17:08 |
| GaryvdM | jam: If you look at compute_loaded_graph, alot of time is spent in various __init__ calls. Would pyrex speed this up? | 17:08 |
| jam | tsort.merge_sort() returns a list | 17:08 |
| bialix | abentley: oh, clean-tree moved to core in 1.13. Now I recall this change, but somehow I forgot it later | 17:08 |
| jam | GaryvdM: potentially, though also that is probably one of those lsprof fallicies | 17:09 |
| jam | __init__ seems to be *much* more expensive under lsprof | 17:09 |
| GaryvdM | jam: oh | 17:09 |
| jam | I won't guarantee it | 17:09 |
| * GaryvdM started on using knowngraph. Digs that out. | 17:09 | |
| jam | but I've had some real-world experience that tells me that pyrex code looks *tremendously* better under lsprof, but isn't always as much better in real-world | 17:09 |
| jam | ah, the other reason that tsort.merge_sort isn't implemented in terms of KnownGraph is because the pure-python implementation of KG uses the tsort implementation of merge_sort ... :) | 17:10 |
| === deryck[lunch] is now known as deryck | ||
| * bialix licks stamp and send oneself away via mail | 17:13 | |
| GaryvdM | jam: I hope I'll get knowngraph used in qlog before then. | 17:16 |
| * GaryvdM really of home now. | 17:16 | |
| === beuno-lunch is now known as beuno | ||
| === salgado_ is now known as salgado | ||
| jam | GaryvdM: are you back now? | 18:19 |
| jam | I just sent an update to qbzr which you might find interesting | 18:19 |
| === radoe_ is now known as radoe | ||
| jam | mostly I wish python's gc didn't get in the way so often... | 18:19 |
| vila | jam: so reagrding bug #375898, the idea is to merge a whole subtree into the trunk *and* still allowing additional merges | 18:21 |
| ubottu | 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 | 18:21 |
| jam | vila: sure. I'm guessing there are 2 possible issues | 18:21 |
| jam | 1) not handling different root ids getting moved around | 18:21 |
| jam | 2) having TREE_ROOT in both trees, and not knowing what to do | 18:21 |
| vila | jam: ISTM that's exactly the job of bzr-merge-into since bzr core seems to delete the old root-id | 18:21 |
| vila | jam: I'm looking at what happens at the first merge right now | 18:22 |
| GaryvdM | Hi jam | 18:24 |
| vila | jam: I tried using bzr-merge-into but it fails with ERROR: The file id "xxxxxx" is not present in the tree None. | 18:25 |
| jam | tree None sounds funny | 18:26 |
| vila | yeah, I'm so laughing :) | 18:26 |
| jam | so, my initial guess is that both branches are going to have TREE_ROOT as their root id | 18:26 |
| vila | no | 18:26 |
| jam | which means we have to move the files over, but don't have a good place to put them | 18:26 |
| vila | err, let me re0check that | 18:27 |
| vila | get_root_id() returns different values for this_tree and other_tree during the merge | 18:28 |
| vila | and neither is TREE_ROOT | 18:28 |
| GaryvdM | jam: Thanks alot. It will probably take me a while to work through that. | 18:28 |
| vila | jam: to summarize before I EOD : 1) doing 'bzr -r0.. ../other' will not keep track of the root id (AFAICS) | 18:30 |
| vila | jam: that doesn't sound like a good way to make future merges working | 18:30 |
| vila | so 2) bzr merge-into sounds like the right way to do that, from there, will the future merges just work ? | 18:31 |
| vila | jam: does the above sound correct ? | 18:31 |
| jam | GaryvdM: short answer, KnownGraph is about a 2x improvement, gc.disable() is also a 2x improvement, combined you get 4x | 18:40 |
| jam | vila: (1) is probably true, as the old root id gets thrown away, and everything is dumped into '.' | 18:40 |
| jam | (2) is probably also true, but IIRC there were some bugs in it wrt root-ids | 18:40 |
| jam | GaryvdM: oh and without gc.disable() KG is actually a performance loss... | 18:41 |
| jam | (so gc.disable() when using KG is actually a 4x shift..., because KG allocates more objects) | 18:43 |
| jam | the primary difference | 18:45 |
| jam | is that if the merged-into tree adds a file at the root of the layout | 18:45 |
| jam | then it should work transparently to merge that into the combined branch | 18:45 |
| jam | vila: ^^ | 18:45 |
| jam | which may also be why it is breaking | 18:45 |
| jam | (adding a file at the root, but there is nowhere to put it in the target tree) | 18:46 |
| * fullermd wishes bug 374734 were moving :( | 18:48 | |
| ubottu | Launchpad bug 374734 in bzr "upgrading many branches is tricky" [High,Confirmed] https://launchpad.net/bugs/374734 | 18:48 |
| GaryvdM | jam: How come you wraped this in it's own function? | 20:19 |
| GaryvdM | def make_kg(): return KnownGraph(self.graph_parents) | 20:19 |
| GaryvdM | kg = make_kg() | 20:19 |
| jam | just so it would show up in lsprof | 20:19 |
| jam | pyrex constructors don't otherwise | 20:19 |
| GaryvdM | Oh - ok | 20:20 |
| Gnx | I'd need some help, I still can't figure out bzr/sftp is not working at all for this client | 20:25 |
| GaryvdM | Gnx: error message? | 20:37 |
| Gnx | Connected (version 2.0, client OpenSSH_4.3p2) | 20:38 |
| Gnx | Disconnect (code 2): Protocol error: packet 5 in interactive | 20:38 |
| Gnx | thats all | 20:38 |
| Gnx | I've tried sftp and ssh with other programs, no problems | 20:39 |
| Gnx | also this just started one day for no apparent reason | 20:39 |
| Gnx | reinstalled bzr too | 20:39 |
| dwt | Hi there, I'm trying to get bzr to remember multple push locations (preferably as default) | 20:43 |
| dwt | but I don't get from the documentation how to do this | 20:43 |
| dwt | is this actually possible? | 20:43 |
| dwt | (what I want is to push to both my private public repo on my webpage as well as to the google code repo at the same time when I say push) | 20:44 |
| dwt | or if that is not possible, have an easy way to say something like bzr push upstream | 20:44 |
| dwt | or something like that | 20:44 |
| dwt | (to further complicate matters, upstream is actually a svn repo :) | 20:45 |
| fullermd | No, there's only one push location. | 20:45 |
| fullermd | You could use something like the bookmarks plugin to get shortcuts for multiple locations. | 20:46 |
| dwt | fullermd: well, woth a try | 20:52 |
| dwt | thanks | 20:52 |
| dwt | it says it only works on linux/windows | 20:53 |
| dwt | leets see if that's true (I'm on mac) | 20:53 |
| fullermd | The plugin? | 20:54 |
| * fullermd would be surprised. | 20:54 | |
| dwt | yes | 20:54 |
| dwt | me too | 20:54 |
| dwt | :) | 20:54 |
| fullermd | (if it had such restrictions, that is) | 20:54 |
| dwt | http://wiki.bazaar-vcs.org/BzrPlugins however is quite explicit | 20:54 |
| dwt | :) | 20:54 |
| dwt | is there a process to update that page | 20:54 |
| dwt | or could you just update it? | 20:54 |
| fullermd | Oh, well, it only counts platforms that matter. Who cares about Mac? :p | 20:55 |
| dwt | ;) me me me! | 20:55 |
| dwt | Wasn't there a law somewhere that stated something like | 20:55 |
| dwt | "Though shalt not make fun of your loyal users"? | 20:55 |
| dwt | I seem to remember that... ;) | 20:55 |
| fullermd | ... what would be the fun of THAT? | 20:56 |
| dwt | ;) | 20:57 |
| fullermd | If you can confirm it works, I can add the thingy. | 20:57 |
| GaryvdM | Gnx: Sorry, I'm not sure. | 21:10 |
| dark_soul | okay guys..remember me with the source code not showing up when i click on it via web? | 21:11 |
| dark_soul | i was caught in a looong meeting | 21:11 |
| dark_soul | so in bazaar.launchpad.net... when i click on anything after the "viewing" and select a source code file to view, it shows nothing | 21:12 |
| dark_soul | but if i click any path before the "viewing" and select a source code file it shows | 21:13 |
| dark_soul | not sure if its a bug or if its by design | 21:13 |
| dwt | fullermd: still trying… :) | 21:13 |
| dark_soul | if thats the case, then anything after the "viewing" should be unclickable. | 21:13 |
| === salgado is now known as salgado-brb | ||
| GaryvdM | dark_soul: May be better to ask this in #launchpad | 21:17 |
| dwt | fullermd: seems to be working fine so far | 21:17 |
| dwt | I wonder, can I get bzr to remember my username and password there too? | 21:17 |
| dwt | (preferably in the keychain like the default push location does) | 21:18 |
| dark_soul | okay | 21:31 |
| mwhudson | hm | 21:46 |
| mwhudson | which ppa do i need to get a new bzr on lucid? | 21:46 |
| GaryvdM | mwhudson | 21:58 |
| GaryvdM | mwhudson: lucid has the latest | 21:58 |
| mwhudson | hmm | 21:58 |
| mwhudson | what's going on then, i only have bzr 2.1.0dev5 | 21:59 |
| mwhudson | time to fight apt a bit i guess | 21:59 |
| GaryvdM | according to https://edge.launchpad.net/ubuntu/lucid/+package/bzr , it should be 2.1.0 | 21:59 |
| GaryvdM | and http://packages.ubuntu.com/lucid/bzr | 22:00 |
| mwhudson | GaryvdM: bzr.dev is well onto 2.2.0dev$foo by now though, surely? | 22:00 |
| GaryvdM | mwhudson: no 2.2 release yet (due this week), so maybe daily ppa | 22:02 |
| mwhudson | the daily ppa seems to have ground to a halt | 22:03 |
| mwhudson | or i'm looking in the wrong place | 22:03 |
| mwhudson | james_w: do you know why https://edge.launchpad.net/~bzr-nightly-ppa/+archive/ppa hasn't had any uploads for months? | 22:04 |
| james_w | mwhudson: I broke the script and never got round to fixing it | 22:04 |
| james_w | I could do that now if you would like to use it | 22:05 |
| mwhudson | it would make my life slightly easier, if it's not too much work | 22:05 |
| james_w | sure | 22:05 |
| mwhudson | thanks | 22:05 |
| james_w | the reason you don't have lucid's package is that the wherever you got 2.1.0dev5 is doing there versioning wrong | 22:06 |
| mwhudson | i think it's from the ~bzr-nightly-ppa :) | 22:06 |
| mwhudson | the debian version is 2.1.0+b1+4961+129~8.10 | 22:07 |
| james_w | oops | 22:07 |
| GaryvdM | jam: test_kg + further changes merged. :-) Thanks | 22:24 |
| Boingo-OSI | Hopefully somebody can help me.... I am trying to get a working tree in a shared repository. It seems that no matter what I do I cannot get the working tree to show up in the repository. Or is this even possible? | 22:36 |
| bob2 | it is easy to do on repository creation (and is the default iirc) | 22:37 |
| Boingo-OSI | Then I am doing something wrong. | 22:37 |
| Boingo-OSI | I have tried it via command line and explorer and both times, when I commit from a checkout, the repository is updated, but no working tree is visible. | 22:38 |
| bob2 | well, you didn't say if you made the repo with working trees or not | 22:38 |
| bob2 | no idea what explorer does, but bzr init-repo seems to default to having them | 22:38 |
| Boingo-OSI | I am fairly sure I did. I did init-repo and init-repo --trees | 22:39 |
| Boingo-OSI | Am I crazy? Is is possible for the repo to have visible, on the file system, the working tree from any commits? | 22:40 |
| Boingo-OSI | Or am I asking something that it can't do? | 22:40 |
| bob2 | that's the default | 22:40 |
| bob2 | (note that 'bzr push' won't update the working trees, unless you're running bzr locally) | 22:41 |
| Boingo-OSI | But "remote" repo in this canse can be local correct? | 22:41 |
| GaryvdM | Boingo-OSI: run bzr checkout to get wt in existing treeless branch | 22:42 |
| Boingo-OSI | I want the working tree both localy and in the remote shared repository. | 22:42 |
| GaryvdM | Boingo-OSI: Ah *remote shared repository* | 22:42 |
| Boingo-OSI | Hopefully I am explaining myself correctly. | 22:43 |
| bob2 | if remote means "accessed via anything other than file:///", then bzr push will not update it | 22:43 |
| poolie | hi | 22:43 |
| GaryvdM | Boingo-OSI: maybe https://launchpad.net/bzr-push-and-update will help (needs ssh access) | 22:44 |
| Boingo-OSI | Am I looking for push? | 22:44 |
| Boingo-OSI | I was thinking of update->work->commit | 22:44 |
| Boingo-OSI | And bind. | 22:45 |
| Boingo-OSI | Or am I way off base? | 22:45 |
| GaryvdM | Boingo-OSI: similar problem to push | 22:45 |
| Boingo-OSI | Oh. | 22:45 |
| GaryvdM | Boingo-OSI: bzr can't update a remote working tree | 22:45 |
| Boingo-OSI | So is it possible at all to have a working tree on a remote shared repo? | 22:45 |
| Boingo-OSI | Oh. | 22:45 |
| === spiv_ is now known as spiv | ||
| Boingo-OSI | Maybe I am appoaching this all wrong? | 22:46 |
| GaryvdM | Boingo-OSI: Either run update on the remote machine (that is what bzr-push-and-update does) | 22:46 |
| GaryvdM | Boingo-OSI: Or use bzr-upload | 22:46 |
| Boingo-OSI | Well, bzr-upload is also being used. | 22:47 |
| Boingo-OSI | At least how I was thinking. | 22:47 |
| Boingo-OSI | I have a distributed team working on a PHP web project. | 22:47 |
| Boingo-OSI | I was thinking of having everyone use a central repo. | 22:47 |
| Boingo-OSI | When you commit it shows up "live" on the development server. | 22:48 |
| Boingo-OSI | Then, eventually, we use bzrupload to send the stable version to the production server. | 22:48 |
| GaryvdM | Boingo-OSI: You can set bzr-upload to automaticly upload when someone commit/pushes to the central branch | 22:48 |
| Boingo-OSI | So in my thinking, the working tree on the remote shared repo would be used to serve the actual dev enviroment. | 22:49 |
| GaryvdM | Boingo-OSI: have a central dev branch, and a central live branch | 22:49 |
| Boingo-OSI | GaryvdM: COuld you elaborate? | 22:50 |
| GaryvdM | Boingo-OSI: set bzr-upload to auto upload to their respective Locations. | 22:50 |
| Boingo-OSI | I thought bzr-upload was one way? | 22:51 |
| GaryvdM | bzr upload --auto -d central_dev_branch devserver and... | 22:51 |
| Boingo-OSI | Or do you mean have the branch with no working tree and then bzr-upload to the dev server's http folder? | 22:51 |
| GaryvdM | bzr upload --auto -d central_live_branch liveserver | 22:52 |
| GaryvdM | yes | 22:52 |
| Boingo-OSI | Ah, so separate them. | 22:52 |
| Boingo-OSI | I was trying to combine them. | 22:52 |
| GaryvdM | when you are happy with dev, push dev to live | 22:53 |
| Boingo-OSI | Interesting. | 22:53 |
| Boingo-OSI | That could work. | 22:53 |
| GaryvdM | Or in my case, I merge dev in to live, because my live has changes to config files. | 22:54 |
| Boingo-OSI | Yes, as would mine. | 22:54 |
| GaryvdM | Hi poolie | 22:54 |
| Boingo-OSI | So, to summarize and make sure I have it straight.... the remote shared repo is not web accessible. In it there are at least 2 branches, dev and live. Work is done on the dev branch, with an auto bzr-upload to the dev server's web accessible folder. When ready, the dev branch is merged into the live branch which is then auto uploaded to the live server. | 22:56 |
| Boingo-OSI | GaryvdM: I am still a bit new at doing it all this way, so pardon the newb question, but how do you keep your config files from clobering eachother. | 22:58 |
| GaryvdM | Boingo-OSI: sounds like you have got it | 22:59 |
| Boingo-OSI | My experience with bzr, up until now, so far is a single developer working from a shared ftp with a single branch. | 22:59 |
| Boingo-OSI | So I am still getting my head wrapped around multiple branches. | 22:59 |
| === salgado is now known as salgado-afk | ||
| GaryvdM | Boingo-OSI: re: handling the config files: in the live branch, change the config files, and then commit. From then on, you will need to merge the dev branch in to the live branch (you won't be able to pull because it will give you a message about the branches been diverged) | 23:02 |
| GaryvdM | Boingo-OSI: tip: If you have qbzr, run bzr qlog path_to_dev path_to_live | 23:03 |
| GaryvdM | Boingo-OSI: screen shot on the way | 23:03 |
| GaryvdM | Boingo-OSI: Sorry, cancel the screenshots, I don't have those branches on this pc. | 23:04 |
| Boingo-OSI | lol, thanks anyway. | 23:05 |
| Boingo-OSI | GaryvdM: Can I bug you with a few more questions? | 23:14 |
| Kilroo | I should probably stop trying to come up with convoluted ideas for how to get bzr to work with the svn repositories that my coworkers have shot all to hell and just be glad that my ideas for using it with our raw ftp sites work. | 23:14 |
| GaryvdM | sure | 23:14 |
| jam | GaryvdM: so the final use of KnownGraph you'll probably want to change, just because you'll probably want to use it *more* | 23:14 |
| jam | however, it is a bit of an improvement to start with | 23:14 |
| GaryvdM | jam: The loading of the graph? | 23:15 |
| jam | that would be one | 23:15 |
| Boingo-OSI | Ultimately, there will be lots of devs and lots of live servers, one for each client that the software is being customized for. A lot of the code between the different clients will be shared. What would you see as an ideal initial layout for the repo/projects/branches? | 23:15 |
| jam | the other would be using it for stuff like your "fixups" of the graph, etc | 23:15 |
| jam | basically, I would see it replacing your "graph_parents" if we can make that work | 23:16 |
| GaryvdM | "fixups"? | 23:16 |
| Boingo-OSI | i.e.: ClientA and ClientB are both using customized versions of the base project. But even the base project has a dev and live server. | 23:17 |
| GaryvdM | Boingo-OSI: Wow. Sounds complicated. You can say, have a branch called custom1 that clientA and clientB merge from, but not client C | 23:19 |
| jam | GaryvdM: you call something that iterates over the graph and plays with a bit | 23:20 |
| GaryvdM | Boingo-OSI: If you run bzr qlog in the shared repo, you will see how the branches relate, and it should help you to understand what is going on. | 23:20 |
| Boingo-OSI | GaryvdM: Not sure if it is or not. A lot of the code is the same. For instance, ClientA and B are just modifying CSS and config files from the base project. | 23:21 |
| Boingo-OSI | GaryvdM: Well, there are no branches yet, I am trying to figure out the best way to lay them out. | 23:21 |
| Boingo-OSI | GaryvdM: Then again, ClientC might have an entire add-on to the base that A and B don't have. | 23:22 |
| GaryvdM | jam: yes | 23:22 |
| GaryvdM | Boingo-OSI: It's difficult for me to say, not knowing your code. Play with it a bit. May be have a branch for each client. qlog is your friend. | 23:24 |
| meoblast001 | hi, in the commit information that appears when i make a commit, it has some "unknown:"s | 23:38 |
| meoblast001 | are those completely disregarded? | 23:38 |
| maxb | ? | 23:39 |
| maxb | oh, you mean file status | 23:39 |
| meoblast001 | yeah | 23:39 |
| maxb | It's just reminding you that they exist, in case you forgot to add them | 23:39 |
| maxb | Other than that, they are disregarded | 23:39 |
| meoblast001 | i find myself deleting a ton of files before every commit, and if Bazaar doesn't even do anything with those, i can leave them there | 23:40 |
| bob2 | 'bzr log -v' shows you waht was committed | 23:40 |
| meoblast001 | i just don't want them going into the repository | 23:40 |
| meoblast001 | all the auto-generated files, such as configure | 23:40 |
| bob2 | bzr only commits things you ask it to | 23:40 |
| meoblast001 | ok, thanks | 23:40 |
| maxb | You should explicitly tell bzr to ignore known autogenerated stuff | 23:43 |
| meoblast001 | how can that be done? | 23:43 |
| maxb | bzr ignore :-) | 23:43 |
| meoblast001 | ah | 23:44 |
| meoblast001 | thanks | 23:44 |
| maxb | Do read 'bzr help ignore' carefully | 23:45 |
| meoblast001 | ok | 23:46 |
| igc | morning | 23:49 |
| meoblast001 | good morning igc | 23:49 |
| poolie | hi higc | 23:53 |
| poolie | igc, what's new? | 23:54 |
| igc | hi poolie | 23:54 |
| Boingo-OSI | Thanks everyone for all the help. | 23:55 |
| igc | poolie: building chms for 2.x and reviewing some of vila's patches today | 23:55 |
| poolie | cool | 23:56 |
| poolie | if we do 2.2b1 tomorrow can we use your scripts to package it? | 23:56 |
| igc | poolie: that's the plan. I'll give them a dry run today | 23:57 |
| igc | and fix up any rough edges | 23:57 |
| poolie | ok, | 23:57 |
| poolie | do they need to be merged in or is it entirely external? | 23:57 |
| igc | poolie: nothing needs to be merged to bzr | 23:58 |
| poolie | jam, i didn't totally understand your reservations about lazy-commands | 23:58 |
| igc | poolie: I'm still deciding whether to merge the new code into the windows-installers trunk or put it into a fresh project | 23:58 |
| poolie | is it just that you want more of the same, or do you think it's wrong? | 23:58 |
| jam | just wondering if we could be even lazier | 23:59 |
| igc | hi jam! | 23:59 |
| jam | so you don't have the runtime overhead of registering | 23:59 |
| poolie | what do you mean? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!