| poolie | jml, hm, that doesn't seem to exist | 00:09 |
|---|---|---|
| jml | hush, I'm being excellent. | 00:09 |
| jml | http://paste.ubuntu.com/353202/ | 00:09 |
| === bob2_ is now known as bob2 | ||
| === bob2 is now known as Guest58725 | ||
| jml | poolie, :( | 00:10 |
| jml | poolie, I can't find it on Launchpad. Maybe I made it all up. | 00:11 |
| jml | I distinctly remember blogging about it. | 00:11 |
| poolie | i remember you telling me | 00:11 |
| spiv | Array['hosted', 'mirrored', NULL, 'remote'])[Branch.branch_type] ? Surely proper SQL style would involve a table join ;) | 00:11 |
| === Guest58725 is now known as bob2 | ||
| poolie | spiv thanks for flagging the issue with 2.0 in https://code.edge.launchpad.net/~jameinel/bzr/2.0.4-unregister-mem-trans/+merge/16980 | 00:17 |
| poolie | but i think you should actually have bounced it | 00:17 |
| spiv | poolie: hmm, ok | 00:19 |
| poolie | to me the benefit is nonzero but small | 00:20 |
| poolie | do you agree? | 00:20 |
| spiv | poolie: I think either way will be fine, really. In absolute terms the risks and rewards for 2.0 are both very low. | 00:20 |
| poolie | the worst that's likely to happen is test suite breakage i suppose | 00:21 |
| spiv | I don't feel strongly, so I went with trusting jam's judgement. | 00:21 |
| poolie | it's possible there will be some gc-related effect | 00:21 |
| poolie | well, that is a good default | 00:21 |
| poolie | :) | 00:21 |
| spiv | If you feel more strongly than me, please add a review ;) | 00:21 |
| poolie | i did | 00:21 |
| poolie | i'm just wondering if we should either discuss or clarify the 2.0 guidelines | 00:21 |
| spiv | Yeah. | 00:22 |
| * poolie looks | 00:22 | |
| spiv | It's the sort of thing I'd be more relaxed about at the start of 2.0's life, I think. | 00:22 |
| poolie | i think for the stable branch | 00:23 |
| poolie | having low risk and low reward is not enough | 00:23 |
| poolie | it needs to have a high reward | 00:23 |
| poolie | because it's not just the risk, but also that a larger diff is harder to push through an SRU | 00:23 |
| spiv | I think as time goes on the rewards for doing things to a stable branch tends to go down (less and less users, and the users that it has are happy or they would have jumped to the next branch), but the risks don't really drop in the same way. | 00:24 |
| poolie | true | 00:24 |
| spiv | But also it does help us to keep the delta between stable and trunk minimal. | 00:24 |
| poolie | if john really wanted to do it in 2.0 i wouldn't necessarily veto it | 00:24 |
| poolie | but i would want at least a specific rationale for putting it in | 00:24 |
| poolie | that's good too | 00:24 |
| poolie | hm | 00:25 |
| poolie | though | 00:25 |
| poolie | the thing where the delta is most going to matter, i think, is api changes that will limit your ability to merge patches across | 00:25 |
| poolie | but of course they're also harder to put into the stable branch | 00:25 |
| poolie | i suppose one could do additive-only api changes | 00:25 |
| poolie | and then do the deprecation/removal of the old api, if any, in trunk | 00:26 |
| spiv | Yeah. Although reducing superficial conflicts from e.g. changing "MemoryTransport" to "memory.MemoryTransport" is nice too... that's not a big deal if there's just one, but multiple overlapping superficial conflicts can be a significant hassle to fix. | 00:26 |
| poolie | true | 00:27 |
| poolie | spiv, how about something like http://pastebin.ubuntu.com/353217/ | 00:39 |
| spiv | poolie: +1 | 00:42 |
| igc | back | 00:54 |
| bendj | Hi. Is there any particular (dis)advantage to bzr-managing a local dev box + a remote svr using bzr's sftp upload/checkout capabilities, versus mounting the remote server locally via sshfs (fuse over ssh)? | 00:58 |
| lifeless | bendj: better to use bzr+ssh/sftp | 01:00 |
| igc | thanks jml! | 01:06 |
| bendj | lifeless: Why 'better'? Are there specific features capabilities that are available with one approach, but not the other? sshfs mounts, in general, are much more handily managed locally ... | 01:07 |
| lifeless | sshfs mounts present a very odd picture of the latencies involved | 01:08 |
| lifeless | and don't really act like local resources - for instance file locks won't work. | 01:08 |
| lifeless | bzr+ssh urls will perform /much/ faster | 01:08 |
| jml | igc, np. it was fun to get my sql ninja on. | 01:09 |
| jml | igc, I just wish that turning an SQL query into a Launchpad page was less work. | 01:10 |
| igc | jml: :-) | 01:11 |
| bendj | lifeless: Huh, I was pretty convinced that file locks over ssfs ARE supported. or do you mean bzr's file locking, in particular? really surprised to hear bzr+ssh is "much faster" ... i mount all over the web via sshfs, and have never really seen performance issues. then again, admittedly i have NOT benchmarked. hmm. worth investigating & learning more, sounds like ... | 01:14 |
| mwhudson | james_w: hello | 01:36 |
| mwhudson | james_w: how stable do you regard the BaseRecipeBranch api in bzr-builder to be? | 01:36 |
| james_w | mwhudson: hi | 01:38 |
| james_w | it can be as stable as you like :-) | 01:38 |
| james_w | I can offer guaranteed API stability if that's all you are looking for | 01:38 |
| james_w | but that may mean new APIs for new things, so it depends on why you are interested I guess | 01:39 |
| mwhudson | james_w: i'm writing code that translates RecipeBranch &c objects into database objects and back | 01:39 |
| mwhudson | if new stuff appears in bzr-builder, this code will have to change | 01:40 |
| mwhudson | no way around that in any case | 01:40 |
| james_w | yeah | 01:40 |
| james_w | it sounds like API stability isn't the issue as such | 01:41 |
| mwhudson | no, i guess not | 01:41 |
| mwhudson | data structure stability | 01:41 |
| james_w | is holding off landing things until LP is ready a better solution? | 01:41 |
| james_w | we are going to want to make some data structure changes, but they will probably come with recipe format changes, which may give us some flexibility | 01:42 |
| jelmer | hi mwhudson, james_w | 01:43 |
| james_w | hi jelmer | 01:44 |
| mwhudson | james_w: i wouldn't wait on lp for stuff really | 01:44 |
| mwhudson | james_w: i can always refuse to have anything to do with formats > 0.2 | 01:44 |
| mwhudson | which is probably a good idea in any case | 01:44 |
| james_w | jelmer: how's your flight looking? | 01:45 |
| james_w | mwhudson: that's what formats are there for :-) | 01:46 |
| mwhudson | james_w: indeed | 01:46 |
| james_w | once I see some of your work next week then I'll have a better grasp on what your needs are, which should help | 01:46 |
| james_w | I'm not out to break LP though, so I'll try and make sure that changes that I make are accommodating to you | 01:46 |
| mwhudson | thanks | 01:46 |
| mwhudson | i guess all i'd like to avoid, or at least know about, are pending fundamental refactorings in how recipes are represented | 01:47 |
| james_w | that's easy enough to do | 01:47 |
| james_w | nothing pending in that part currently, except talk of inheritance | 01:48 |
| mwhudson | james_w: recipe inheritance you mean? | 01:48 |
| james_w | yeah | 01:49 |
| mwhudson | ok | 01:50 |
| mwhudson | well, i'll deal with that when it happens | 01:50 |
| mwhudson | at the least, it will be a format bump, right? | 01:50 |
| james_w | yeah | 01:50 |
| james_w | but now, I must sleep | 01:50 |
| james_w | mwhudson: when do you arrive in Wellington? | 01:51 |
| james_w | or are you there already now? | 01:51 |
| mwhudson | james_w: probably only monday morning, or maybe sunday night | 01:51 |
| mwhudson | james_w: sleep well! | 01:51 |
| james_w | ok, I'll see you then | 01:55 |
| james_w | have a good day | 01:55 |
| jelmer | james_w: I'm flying tomorrow at 8 in the evening. What about you? | 02:00 |
| jelmer | james_w: g'night | 02:00 |
| * jelmer gets some sleep as well | 02:00 | |
| james_w | jelmer: 9pm for me, fingers crossed | 02:00 |
| james_w | night | 02:01 |
| jelmer | g'night! | 02:01 |
| mwhudson | hee | 02:37 |
| mwhudson | where's the bug? http://pastebin.ubuntu.com/353256/ | 02:40 |
| mwhudson | i guess it's in find_branches | 02:40 |
| mwhudson | heh ** 2 | 02:42 |
| * mwhudson finds https://code.edge.launchpad.net/~ian-clatworthy/bzr-builder/fix-find-branches/+merge/15137 | 02:42 | |
| chromakode | hey #bzr, I would like to uncommit a merge, but restore the subcommits that were merged. is there an easy way to do this? | 02:45 |
| mwhudson | chromakode: i'm not sure i understand | 02:47 |
| mwhudson | chromakode: what commands did you run and what would you like to have done? | 02:47 |
| chromakode | mwhudson, unfortunately, someone on my team pulled from trunk, merged their changes, and pushed back to trunk, without proper review | 02:47 |
| mwhudson | note that if you just run "bzr uncommit" you'll get into a situation with pending merges | 02:48 |
| chromakode | oh, really! | 02:48 |
| mwhudson | chromakode: ah, that old fun | 02:48 |
| chromakode | I didn't know that | 02:48 |
| chromakode | before the merge, there were 3 commits by a reviewer -- they're now wrapped up in the merge | 02:48 |
| mwhudson | append_revisions_only = True ftw | 02:48 |
| chromakode | so, I didn't know that factoid... perhaps I can figure it out with that new knowledge | 02:48 |
| chromakode | what/where is that? | 02:48 |
| mwhudson | in the .bzr/branch/branch.conf file | 02:49 |
| mwhudson | let me see if it's documented somewhere | 02:49 |
| chromakode | thank you! | 02:49 |
| mwhudson | chromakode: hm, i found this https://lists.ubuntu.com/archives/bazaar/2008q3/046797.html | 02:50 |
| mwhudson | chromakode: and "bzr help configuration" has some stuff | 02:51 |
| mwhudson | but first, you need to recover from the mess | 02:51 |
| chromakode | reading :) | 02:51 |
| chromakode | yes. so, now I have 3 commits on my merge queue | 02:51 |
| chromakode | how do I unmerge them? | 02:51 |
| chromakode | note: there's also a commit on head *before* the merge that also needs to go | 02:52 |
| chromakode | the log looks like: | 02:52 |
| chromakode | * bad merge | 02:52 |
| chromakode | * bad commit | 02:52 |
| chromakode | I want: | 02:52 |
| chromakode | 3 x * old commit from merge | 02:52 |
| mwhudson | i think something like this | 02:53 |
| mwhudson | bzr log --show-ids -l 4 and copy the revid of "bad commit" somewhere | 02:53 |
| chromakode | got it | 02:53 |
| mwhudson | then bzr log --include-merges and somewhere near the top you should see the old commits that you want back on the mainline | 02:54 |
| chromakode | yep. | 02:54 |
| mwhudson | that'll have a revno like 60.1.3 | 02:54 |
| mwhudson | bzr pull --overwrite -r $revno . | 02:55 |
| chromakode | aha! | 02:55 |
| mwhudson | will bring that bad to tip | 02:55 |
| mwhudson | then i think you can bzr merge -r revid:$bad_commit_revid . | 02:55 |
| chromakode | yes! | 02:55 |
| mwhudson | and commit that properly | 02:55 |
| mwhudson | s/bad/back/ | 02:56 |
| chromakode | I think that single pull --overwrite did the trick! | 02:59 |
| mwhudson | well, it will have obliterated the changes your teammate made | 03:00 |
| mwhudson | but looking back, perhaps that's what you wanted | 03:00 |
| jml | hi | 03:03 |
| jml | if I do a merge that changes a whole heap of files, and then I accidentally edit some files before committing, is there a good way of finding out changes I made that weren't part of the merge? | 03:04 |
| mwhudson | jml: do the merge in another copy of the branch, then diff -r branch: | 03:05 |
| jml | mwhudson, that's a good idea. | 03:06 |
| mwhudson | jml: or perhaps better, do the merge in another copy of the branch, commit it, and then pull from there into the version you made changes in | 03:06 |
| jml | mwhudson, ooh, I like that. | 03:06 |
| mwhudson | you risk conflicts i guess, but they're probably ones you should know about | 03:06 |
| jml | right | 03:08 |
| === mwhudson_ is now known as mwhudson | ||
| === mwhudson_ is now known as mwhudson | ||
| chromakode | mwhudson, back -- yes, that's exactly what I wanted | 03:21 |
| chromakode | mwhudson, they pushed it to their own branch before I obliterated them | 03:21 |
| chromakode | thanks very much for the help mwhudson. you really saved me a lot of time. :) | 03:21 |
| mwhudson | chromakode: cool, np | 03:22 |
| * mwhudson wonders if bzr.dev r4943 will break launchpad | 03:45 | |
| === abentley1 is now known as abentley | ||
| Peng | Wow. | 03:47 |
| mwhudson | probably | 03:47 |
| Peng | Looks like bzr+http and Loggerhead don't use it, so I should be okay. | 03:49 |
| * igc lunch | 03:55 | |
| === oubiwann_ is now known as oubiwann | ||
| Peng | Yeah, they're ok. | 03:57 |
| poolie | igc, nice work on the imports! | 04:02 |
| lifeless | spiv: I really want to fix the exception handling in def _run_pre_change_branch_tip_hooks(self, new_revno, new_revid): | 04:49 |
| lifeless | spiv: are you still attached to it? | 04:49 |
| lifeless | spiv: by fix, I mean delete. | 04:49 |
| spiv | lifeless: lemme look again | 04:49 |
| lifeless | spiv: please do - and compare to '_run_post_change_branch_tip_hooks' right above it. | 04:49 |
| spiv | lifeless: so the main thing I guess I care about is that TipChangeRejected is still passed through in such a way that a server-side hook can cleanly transmit it to the client. | 04:50 |
| spiv | lifeless: and I doubt you'll break that | 04:50 |
| spiv | lifeless: so sure | 04:51 |
| lifeless | spiv: thats a matter of raising that exception :) | 04:51 |
| lifeless | spiv: more than anything else, AFAICT. | 04:51 |
| spiv | Right. And there are tests about functionality too. | 04:51 |
| spiv | So if you *do* break it somehow, you'll know :) | 04:51 |
| === Adys_ is now known as Adys | ||
| lifeless | well, PQM will. But yes :) | 04:52 |
| spiv | I think I'm still mildly in favour of having some sort of distinction between core code and plugins in cases like this so that we can better report errors (and attribute them to the right software), but not enough to cling to keeping this inconsistent with the rest of bzr. | 04:53 |
| lifeless | spiv: I think we can do that without any formal distinction | 04:54 |
| lifeless | stack introspection for instance, will be better done *without* rethrowing. | 04:54 |
| igc | poolie: np | 04:55 |
| spiv | Don't expect me to consider stack introspection to be cleaner than anything ;) | 04:55 |
| lifeless | spiv: I think we'd need that to get solid results always, anyway. | 04:56 |
| poolie | igc, i'm going to do the two small bugs i opened against bzr-website | 04:56 |
| igc | poolie: I saw the gdesklets one. What's the other? | 04:56 |
| poolie | mention gnu | 04:56 |
| igc | poolie: cool. could you also change Contribute/Plugins to ... | 04:57 |
| igc | the new guide ... | 04:57 |
| igc | http://doc.bazaar.canonical.com/plugins/en/plugin-development.html | 04:58 |
| poolie | is this in the wiki? | 04:59 |
| igc | poolie: the current link points into the Wiki: http://bazaar-vcs.org/WritingPlugins | 05:02 |
| igc | poolie: which just redirects to the new guide | 05:02 |
| igc | poolie: I just want to cut out the extra click | 05:03 |
| igc | poolie: the tutorial is part of the Plugins Guide now | 05:03 |
| poolie | ok | 05:04 |
| poolie | you're talking about the link in the web page footer? | 05:04 |
| poolie | i can do that | 05:04 |
| igc | yup | 05:04 |
| poolie | ok, it's fixed in trunk but there's a permissions breakage causing it not to update on the live site | 05:23 |
| === abentley1 is now known as abentley | ||
| lifeless | spiv: I think we need to use introspection because there are many ways a plugin could taint an action | 05:31 |
| lifeless | spiv: hooks are one special case, but not necessarily even the most common source of user experienced errors. | 05:31 |
| spiv | Sure. | 05:31 |
| lifeless | spiv: https://code.edge.launchpad.net/~lifeless/bzr/hooks/+merge/17005 | 05:32 |
| lifeless | my yak for the day | 05:32 |
| lifeless | spiv: thanks | 05:35 |
| spiv | No worries. | 05:36 |
| lifeless | are automirror's internals ~= to my sketch ? | 05:39 |
| lifeless | spiv: because I bet its a post push hook, not a pre | 05:39 |
| spiv | lifeless: oh, post tip change, yeah. I didn't realise your code used pre. | 05:40 |
| lifeless | no worries ;) | 05:41 |
| spiv | :) | 05:42 |
| spm | damn I am tempted to mis quote you two out of context. all that smiles and no worries; all we need is a "she'll be right mate!"... | 05:42 |
| spiv | spm: or a "no wuckas"? | 05:43 |
| spm | spiv: ok, I admit they're very low, but I do have *some* standards | 05:43 |
| lifeless | spm: Good on ya mate | 05:47 |
| spm | /ignore lifeless | 05:47 |
| lifeless | hah | 05:48 |
| * spm wipes the tears of laughter from his eyes and tries to recall wtf he was doing.... | 05:48 | |
| poolie | yay | 05:49 |
| * poolie closes bugs | 05:49 | |
| poolie | igc, do i recall correctly that some measurements last year found bzr doing better than git over a dumb http server | 05:54 |
| igc | poolie: in bzr 1.x, yes | 05:55 |
| igc | poolie: I think we may have gone backwards over dumb http in 2.x but I'm not sure | 05:55 |
| poolie | web site is updating again now | 06:03 |
| poolie | spiv, hi, still around? | 06:29 |
| spiv | poolie: yep | 06:29 |
| poolie | in that bug 504102, the problem seems to be that the remotebzrdirformat in the registry is getting its network_name set | 06:30 |
| ubottu | Launchpad bug 504102 in bzr "test_format_initialize_find_open has some isolation problems" [High,In progress] https://launchpad.net/bugs/504102 | 06:30 |
| poolie | this seems wrong | 06:30 |
| poolie | would i be right in thinking it should only be set when you're talking about the format of some specific bzrdir? | 06:30 |
| spiv | Which registry? The bzrlib.bzrdir.format_registry? | 06:31 |
| poolie | hm, apparently BzrDirFormat._known_formats | 06:32 |
| spiv | But yes, that's my understanding too. | 06:32 |
| poolie | i'm not sure how that meshes with the format registry | 06:32 |
| spiv | The per_bzrdir load_tests explicitly adds remote bzrdirs to the list of scenarios. | 06:33 |
| spiv | So I'm not sure that the registry is involved. | 06:33 |
| poolie | ah | 06:33 |
| spiv | A remotebzrdirformat instance from that load_tests might still be inappropriately shared or mutated, though. | 06:33 |
| poolie | so it's not the registry, but rather the single instance of that format in the scenario list | 06:33 |
| poolie | i think all those tests will get a copy of the format | 06:34 |
| poolie | we could give them a format_class instead | 06:34 |
| spiv | Possibly the solution is simply to specify the default network_name at load_tests time? | 06:34 |
| poolie | hm | 06:34 |
| poolie | if the format object can be mutated (implicitly by calling other things on it) | 06:35 |
| lifeless | Yeah we assumed formats were immutable | 06:35 |
| poolie | then it seems like asking for trouble for multiple tests to share an instance of it | 06:35 |
| lifeless | I think copying the Remote format in each scenario would make sense here. | 06:35 |
| poolie | mm | 06:35 |
| poolie | alternatively we could make them actually immutable again | 06:35 |
| poolie | that may be harder | 06:35 |
| lifeless | poolie: Remote formats are proxies though, so its hard. | 06:36 |
| lifeless | mmm | 06:36 |
| spiv | (let's go shopping) | 06:36 |
| lifeless | couple of other random thoughts: | 06:36 |
| poolie | hm | 06:36 |
| lifeless | - its possibly a bug, a test that should dup the format and writes to it: easy answer: fix that one test. | 06:36 |
| poolie | they can only actually know this if they're connected to a particular instance of a bzdir | 06:36 |
| lifeless | - generally we get a RemoteFormat* via factory methods, so there isn't a reason for production code to be altering the scenario format object. | 06:37 |
| poolie | lifeless: using the format to initialize a branch implicitly mutates it | 06:37 |
| lifeless | poolie: oh MEEP | 06:37 |
| poolie | mm | 06:37 |
| lifeless | poolie: I consider that a bug | 06:37 |
| lifeless | sorry for introducing it | 06:37 |
| poolie | it looks ugly to me at least | 06:38 |
| poolie | easier to reason about these things if they're immutable | 06:38 |
| spiv | Perhaps initialising a branch should give that branch a copy of the remote bzrdir format? | 06:38 |
| lifeless | immutable I think is hard here, but altering the parameter format should be unnecessary and can cause bugs. | 06:38 |
| spiv | What lifeless just said :) | 06:39 |
| lifeless | More generally immutable objects in python don't seem to work well: python is not geared for such idioms, with the notable exception of strings (and there too we run into performance and space issues) | 06:45 |
| poolie | mm | 06:46 |
| poolie | so we may be able to just remove the sideeffect of setting the name when it's created | 06:47 |
| poolie | if nothing relies on that we should be ok | 06:47 |
| lifeless | We'll want the format the branch uses to have the name set if we know it | 06:47 |
| poolie | lifeless: this is the kind of thing i mean about the tension between the Format and the class of the instance | 06:47 |
| lifeless | probably its passing in a format it should duplicate | 06:47 |
| lifeless | poolie: well, RemoteFormat is a proxy object anyway; I don't see that this adds to that tension | 06:48 |
| poolie | well | 06:49 |
| poolie | it's kind of half a proxy object | 06:49 |
| poolie | obviously it can be a proxy for an actual remote bzrdir | 06:49 |
| poolie | it can also be exist in the abstract without one | 06:49 |
| lifeless | poolie: I've recently in another project had cause to do format markers on disk again, and I used the split style we do in bzr again - I find it really easy and clear to work with - it made two separate hierarchies with separate concerns. | 06:49 |
| poolie | to me that is a reflection of the tension | 06:49 |
| poolie | well | 06:50 |
| poolie | we have this bug | 06:50 |
| lifeless | poolie: RemoteRepository can't exist in abstract; Remote*Format can - but then so can BzrDirMeta1Format | 06:50 |
| lifeless | it has state and can be parameterised. | 06:50 |
| poolie | i think the bugs we see here show that the code is not clear about what the object represents | 06:51 |
| lifeless | doing that (BzrDirMeta1Format parameterisation) in the class would be really unpleasant, I think - it would make what shouldn't be global, global state) | 06:51 |
| lifeless | poolie: Have a good weekend :) | 06:51 |
| lifeless | poolie: [I'm still sick, can't really make a good case for or against anything atm, and this isn't a shallow discussion.] | 06:52 |
| poolie | yeah, thanks | 06:52 |
| poolie | no | 06:52 |
| poolie | don't worry, i'm not going to pull it out now | 06:52 |
| spiv | poolie: which method is mutating the format do you know? initialise_on_transport? | 06:53 |
| lifeless | poolie: oh I know :) You'd have to replace all the things that work well at the moment with something cleaner, to pull it out :) | 06:53 |
| poolie | _initialize_on_transport_ex_rpc | 06:53 |
| spiv | poolie: huh | 06:53 |
| spiv | poolie: that method already goes to the trouble to make a new RemoteBzrDirFormat object | 06:53 |
| spiv | poolie: so really it should be mutating that, not self, I think | 06:54 |
| lifeless | sometimes a bug is just a bug | 06:54 |
| lifeless | spiv: ack | 06:54 |
| poolie | line ~3263 | 06:54 |
| poolie | that's what i changed | 06:54 |
| lifeless | spiv: ah, I see. I was stupid. | 06:55 |
| spiv | lifeless: it happens :) | 06:55 |
| lifeless | spiv: it uses its own state to make the rpc call. It shouldn't. | 06:55 |
| spiv | lifeless: right | 06:55 |
| poolie | right | 06:55 |
| poolie | it's used as both the archetype of the thing you want to create (in which case it can be partly populated) | 06:56 |
| poolie | and the actual value of a thing, in which case it should be fully populated | 06:56 |
| poolie | there's not necessarily anything wrong with this... | 06:56 |
| lifeless | http://pastebin.com/f5b89a4ba | 06:56 |
| poolie | but, with object aliasing etc, it seems a bit dangerous | 06:56 |
| lifeless | should fix i t | 06:56 |
| poolie | yes, thanks, i did that 20 minutes ago | 06:57 |
| lifeless | poolie: cool | 06:57 |
| poolie | i'm waiting to see if it passes | 06:57 |
| poolie | btw, what's the difference between known_formats and format_registry? | 06:58 |
| lifeless | offhand: known_formats == svn, hg, bzr, git, cvs | 06:59 |
| lifeless | format_registry == bzrmeta1 format logic | 06:59 |
| lifeless | nope thats wrong | 07:00 |
| poolie | it's something like that but i'm not sure if it really needs to be in a not-quite-a-registry | 07:01 |
| lifeless | I think known_formats is perhaps just what we had before format_registry | 07:01 |
| poolie | i think the format_registry is the registry of pre-baked combinations | 07:01 |
| lifeless | yes | 07:01 |
| poolie | as opposed to the list of BzrDirFormats | 07:01 |
| lifeless | that bit I'm sure of | 07:01 |
| lifeless | there is a commment explaining something about it | 07:02 |
| lifeless | it might be a thing to remove / turn into a separate object, but I'd need to page it in, look at what it has in it properly. | 07:02 |
| poolie | nm | 07:02 |
| poolie | was just wondering | 07:02 |
| poolie | i think this is passing so while it runs i will poke at tribunal | 07:02 |
| poolie | have a good weekend | 07:02 |
| lifeless | Another WAG - it will have BzrMetaDirFormat1, BzrDirFormat4, BzrDirFormat5 etc | 07:02 |
| poolie | i can see the different things that are registered | 07:03 |
| poolie | i guess i wondered if it really matters | 07:03 |
| lifeless | poolie: the comment it has is about performance probing for stuff. No idea if thats still relevant. | 07:03 |
| lifeless | igc: I hope you don't land that --bind change - I really didn't see consensus on the list. | 07:12 |
| lifeless | oh, ugh. I just replied to a 5 year old mail. | 07:20 |
| * lifeless blushes | 07:20 | |
| poolie | https://code.edge.launchpad.net/~mbp/bzr/504102-test-isolation/+merge/17006 is the patch, still running i think | 07:21 |
| lifeless | poolie: approved already :) | 07:22 |
| poolie | yoy | 07:23 |
| poolie | yay* | 07:23 |
| lifeless | jml: ping | 07:25 |
| lifeless | jml: I'd like to make your weekend hacking nicer; to that end care to approve my two testresources merges? ;) | 07:25 |
| lifeless | you know what I'd love. | 07:25 |
| lifeless | implicit per-product PPA's. | 07:26 |
| poolie | yes | 07:26 |
| poolie | would be great | 07:26 |
| lifeless | with product relationships permitted to get product->product dependent PPA's. | 07:26 |
| poolie | i'd like a view of all bugs tagged hottest100 across all projects | 07:26 |
| lifeless | e.g. ppa:bzr/releases would depend on bzr-git/releases, if bzr-git was a relationship | 07:26 |
| vila | hi all | 07:26 |
| poolie | hi vila | 07:27 |
| lifeless | I think that would be awesome. | 07:27 |
| poolie | i was just thinking of you in bug 504640 | 07:27 |
| ubottu | Launchpad bug 504640 in bzr "selftest hang in test_bzrdir.TestHTTPRedirections_readonly.test_loop" [Low,Confirmed] https://launchpad.net/bugs/504640 | 07:27 |
| poolie | lifeless: if by 'depend' you mean 'virtually include' that would be even cooler perhaps | 07:27 |
| * vila curses vbox for crashing again :-( | 07:28 | |
| vila | poolie: sounds a lot like the issues I encountered while debugging the leaking tests, say 90% | 07:29 |
| poolie | but it's not really important | 07:29 |
| vila | poolie: was it a full test run or a partial one ? --parallel involved or not ? (Not that it really matters, but it's always good to know a bit about the context) | 07:30 |
| poolie | oh | 07:31 |
| poolie | full, nonparallel, with -f | 07:31 |
| lifeless | poolie: I do | 07:33 |
| poolie | shouldn't 'bazaar-ng' have been a clue? :-) | 07:40 |
| lifeless | poolie: figured they had an old list ref | 07:43 |
| eLowar | greetings... what's the best way to safely backup a (live) Bazaar repository? | 07:46 |
| === jamesh_ is now known as jamesh | ||
| Peng | eLowar: Using Bazaar itself would probably be best, except for the possibility of corruption. | 07:54 |
| spiv | eLowar: http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/backup.html | 07:55 |
| Peng | Oh. | 07:55 |
| spiv | Peng: I know, actual documentation addressing things users care about, weird huh? ;) | 07:56 |
| Peng | Trying to take all the fun out of figuring out solutions, huh? | 07:58 |
| spiv | Peng: not sure, give me a sec to find the docs on that topic ;) | 08:03 |
| eLowar | thanks a bunch | 08:19 |
| Peng | spiv: Maybe there's a blueprint! | 08:21 |
| eLowar_ | oh and sorry for running off like this ;) I'm at work and we were trying to find this documentation, so I can't stay and chat right now :) | 08:22 |
| eLowar_ | cheerio | 08:22 |
| spiv | eLowar: that's ok, glad we could help :) | 08:22 |
| * igc dinner | 08:32 | |
| vila | poolie: so, about leaking tests, another way to look at it is to realize that the hang you encountered is one aspect of it. The irony is that the more bugs I fix in this area, the more likely it becomes to trigger hangs. That means all the related bugs should be fixed or we shouldn't touch it at all (and hope we keep being lucky to avoid it on pqm) :-/ | 08:32 |
| vila | poolie: I was close to fixing them all (famous last words) when I realized that while running full test runs without --parallel (which change the context enough to change the overall behaviour in various ways ...) | 08:34 |
| lifeless | vila: that while [...] what ? | 08:43 |
| vila | that, while | 08:44 |
| lifeless | vila: I still can't parse it | 08:52 |
| lifeless | vila: In english, the that that you have before the while implies a clause to which the that will bind | 08:52 |
| lifeless | . | 08:53 |
| vila | When I stopped working on that, I had the full test passing with --parallel=fork (and 8 threads) | 08:54 |
| vila | From there I wanted to run witout --parallel=fork to get data on how tests were still leaking (the report doesn't work with --parallel) | 08:54 |
| vila | The runs hang | 08:54 |
| vila | that (while ...) | 08:55 |
| lifeless | ok | 08:55 |
| lifeless | so what report? we could do it in --parallel probably | 08:55 |
| vila | yeah, that seems to be our best protection so far | 08:56 |
| jszakmeister | Hello all | 09:13 |
| bialix | hello all | 09:36 |
| vila | lifeless: ghaa, I totally misread you remark, so the report that failed is the one about the leaking tests which presumably is lost into the test reporting (search for leak in tests/__init__.py, that's the first occurrence) | 09:51 |
| ChrisMorgan | "Treeless" when creating a branch means that you don't get the working copy, doesn't it? | 09:55 |
| bob2 | yes | 09:55 |
| bialix | hi vila | 09:58 |
| vila | hey bialix | 09:58 |
| lifeless | vila: can I suggest a refactoring | 09:59 |
| lifeless | vila: change the leak implementation to use tags | 09:59 |
| lifeless | so the result object accumulates tagged tests as leaking | 09:59 |
| lifeless | and the leak detection sets tags. Assuming that that is possible. | 09:59 |
| lifeless | that would flow through subunit fine. | 10:00 |
| ChrisMorgan | Thanks | 10:00 |
| vila | lifeless: ok, pasted in my associated BRANCH.TODO, I'll look into it when I get there | 10:01 |
| ChrisMorgan | Also, I've got my own project which has two main chunks; a Python library (which goes in site-packages or somewhere in PYTHONPATH) and the actual Django projects (a sample one and then one for each client I get so I can keep 'em all). How am I best to initialise my bzr repository? | 10:06 |
| ChrisMorgan | subtrees somewhere or something like that? | 10:06 |
| ChrisMorgan | I've got half the buzzwords but haven't figured them all out entirely yet | 10:06 |
| bob2 | a branch for each | 10:06 |
| ChrisMorgan | Even though it's all the one project really? | 10:07 |
| bob2 | sounds like they're not one the project | 10:07 |
| ChrisMorgan | I thought maybe the client ones should each be in a branch of their own but I thought I might do the library and sample one in the same or something | 10:07 |
| lifeless | ChrisMorgan: sounds to me like the python library is one project; and each django thing is another separate project. | 10:09 |
| ChrisMorgan | I'd be able to branch of one repository and then push to a different one... that'd work well with separate branches | 10:09 |
| lifeless | ChrisMorgan: s/repository/branch/ there. | 10:09 |
| lifeless | ChrisMorgan: repository != branch | 10:09 |
| ChrisMorgan | Oh no... I'm confusing my talk :S | 10:10 |
| ChrisMorgan | *sigh* :-) | 10:10 |
| ChrisMorgan | I know what I meant at least, and so did you :-) | 10:10 |
| ChrisMorgan | Could I use a shared /repository/ for these branches though? | 10:10 |
| lifeless | of course | 10:11 |
| lifeless | there aren't any limits on sharing | 10:11 |
| ChrisMorgan | Do I need to do anything special with my bzr init? | 10:11 |
| lifeless | no | 10:11 |
| ChrisMorgan | Do you think I should use development or 2a? | 10:12 |
| lifeless | use the default your bzr has | 10:12 |
| lifeless | unless you have specific reason not to | 10:12 |
| ChrisMorgan | OK | 10:12 |
| ChrisMorgan | Now how do I create separate branches in the repository? | 10:13 |
| ChrisMorgan | I've never gone through and created a project in Bazaar... only used the Inkscape one before this. | 10:13 |
| ChrisMorgan | And they're using knit :/ | 10:13 |
| lifeless | ChrisMorgan: bzr init path | 10:13 |
| jszakmeister | Is there a way to dump the contents of a pack file (in a semi-readable fashion)? | 10:14 |
| lifeless | jszakmeister: with python, yes | 10:14 |
| lifeless | bzrlib.pack has the API | 10:14 |
| jszakmeister | Thanks! | 10:14 |
| ChrisMorgan | lifeless: so, bzr init-repo myproject, bzr init myproject/lib, bzr init myproject/sampleclient, bzr init myproject/[companyname], etc.? | 10:18 |
| ChrisMorgan | Could I do bzr init myproject/clients/sample etc. if I just create the clients directory? | 10:18 |
| ChrisMorgan | Or would I need to init clients first... | 10:18 |
| jszakmeister | Okay... next question: is there an easy to see some sort of formatted output of each record in the pack? :-) | 10:19 |
| jszakmeister | I'm trying to understand this ghost revision stuff a little more and I'm not quite understanding how this error is being generated: | 10:21 |
| jszakmeister | bzr: ERROR: Revision {StaticTuple('1@7e532cae-f599-4488-b39e-a91bcf8c4cdd:%2Ffile.txt', 'john@szakmeister.net-20100108092733-qdawmc2foo77br14')} not present in "<bzrlib.groupcompress.GroupCompressVersionedFiles object at 0x15cb4f0>". | 10:21 |
| jszakmeister | If I cat the revisions, none of them point to john@szakmeister.net-20100108092733-qdawmc2foo77br14 | 10:21 |
| jszakmeister | But that information is obviously recorded somewhere. :-) | 10:22 |
| * ChrisMorgan wonders whether Bazaar or some other version control system could be twisted to version the contents of a database rather than the filesystem | 10:22 | |
| ChrisMorgan | jszakmeister: I presume no matches for just qdawmc2foo77br14 either? | 10:23 |
| jszakmeister | Nope. | 10:23 |
| lifeless | ChrisMorgan: mkdir myproject/clients and otherwise, yes. | 10:23 |
| ChrisMorgan | OK, thanks lifeless :-) | 10:24 |
| ChrisMorgan | Thank you, you and bob2 have been very helpful :-) | 10:24 |
| lifeless | jszakmeister: it will be in an inventory | 10:25 |
| lifeless | jszakmeister: in the parents graph, I expect | 10:25 |
| jszakmeister | Where can I find that? | 10:26 |
| lifeless | repository.inventories.get_parent_map | 10:26 |
| jszakmeister | Okay, I'll give that a whirl. | 10:27 |
| jszakmeister | Before I do, lemme ask another question... | 10:27 |
| jszakmeister | currently, bzr-svn is setting the parent on one of the files to point to that revision... | 10:28 |
| jszakmeister | in a merge commit... should it be doing that? | 10:28 |
| jszakmeister | bzr check seems to dislike it: | 10:29 |
| jszakmeister | 1 inconsistent parents | 10:29 |
| jszakmeister | * 1@7e532cae-f599-4488-b39e-a91bcf8c4cdd:%2Ffile.txt version john@szakmeister.net-20100108092741-ei1r6ocf3zfl6e6u has parents ('john@szakmeister.net-20100108092733-qdawmc2foo77br14',) but should have () | 10:29 |
| lifeless | its a revision that you are missing; you should pull it into your repo and it will stop being a ghost | 10:30 |
| jszakmeister | Well, it's not that easy. | 10:30 |
| jszakmeister | If someone branches svn trunk, does all their work in bzr, and then merges it back to svn trunk... you end up with this problem. | 10:31 |
| jszakmeister | IOW, it's quite easy to end up in this state. | 10:32 |
| ChrisMorgan | If I want to just straight rename a branch in my shared repository - my product has a current code name but I'm not decided on its final name yet and might like to rename it - what's the command for that? I presume there is some way I can do that short of something like branch company/product, push company/newname. | 10:33 |
| bob2 | mv | 10:33 |
| bob2 | real mv not bzr mv | 10:33 |
| Peng | Of course, you're still stuck with any branch nicks stored in history. | 10:34 |
| ChrisMorgan | And that continues to work even though the branch information is stuck in the repository rather than the branch? (Or is it?) | 10:34 |
| bob2 | the revision data is in the repository | 10:35 |
| bob2 | the branch data is in the branch | 10:35 |
| Peng | ChrisMorgan: What are you asking? | 10:35 |
| ChrisMorgan | Peng: repository with branch a/b, want to rename the branch to q/b | 10:36 |
| ChrisMorgan | OK bob2, I thought with a shared repository the branch info was all stored in the repo rather than the branch? | 10:36 |
| Peng | ChrisMorgan: What do you mean by "branch info"? | 10:36 |
| Peng | ChrisMorgan: I think you're misunderstanding something. | 10:37 |
| ChrisMorgan | all the history etc. of files | 10:37 |
| ChrisMorgan | Am I? :-( | 10:37 |
| ChrisMorgan | Please correct me :-) | 10:37 |
| Peng | ChrisMorgan: Yeah, revisions are stored in the repo. | 10:37 |
| ChrisMorgan | So if I rename the branch --- | 10:37 |
| ChrisMorgan | What happens? | 10:37 |
| Peng | ChrisMorgan: Bazaar doesn't care about what the name of the directory is. (Except for the default branch nick.) As long as you don't move it outside the shared repository, you can call it whatever you want to. | 10:38 |
| ChrisMorgan | Could you for example in Launchpad just 'mv inkscape.dev inkscape.devel' and have it continue on chugging with everything moved across to lp:inkscape/inkscape.devel? | 10:38 |
| ChrisMorgan | Default branch? | 10:38 |
| ChrisMorgan | Don't think I've heard any mention of that... | 10:38 |
| Peng | ChrisMorgan: On-disk, all a branch is is a pointer to the most recent revision ID and some meta data (like the parent location and tags). | 10:38 |
| Peng | ChrisMorgan: default (branch nick) | 10:39 |
| Peng | ChrisMorgan: Not (default branch) nick | 10:39 |
| ChrisMorgan | Oh dear... I'm more confused now :-) | 10:39 |
| ChrisMorgan | Never mind, I'll search for it | 10:39 |
| ChrisMorgan | I'm off to bed now anyway. | 10:40 |
| Peng | Sorry. :< | 10:40 |
| ChrisMorgan | I'll continue on asking tomorrow then for anything I still don't understand :-) | 10:40 |
| Peng | ChrisMorgan: I just meant the name of the branch that's recorded in history. | 10:40 |
| Peng | ChrisMorgan: Which is just a little bit of meta data that doesn't actually matter. | 10:40 |
| ChrisMorgan | Peng: OK | 10:40 |
| ChrisMorgan | I'll blindly name branches and hope I can rename them later :-) | 10:40 |
| ChrisMorgan | Bye now. | 10:40 |
| Peng | ChrisMorgan: You can, but you can't change the nicks stored in history. | 10:40 |
| Peng | ChrisMorgan: See you. :) | 10:41 |
| ChrisMorgan | Where's it stored though? | 10:41 |
| Peng | ChrisMorgan: As part of each revision. | 10:41 |
| Peng | ChrisMorgan: Look at "bzr log". | 10:41 |
| ChrisMorgan | OK, thanks | 10:41 |
| ChrisMorgan | Bye now for real ;-) | 10:41 |
| Peng | :) | 10:41 |
| jszakmeister | lifeless: and it's even more problematic when there is another person on a different team who doesn't have access to our bzr mirror (firewalls, policy, etc) | 10:46 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| marek_ | hi, can i upload only specified trunk? i already dowloaded upload plugin | 14:32 |
| rubbs | marek_: what do you mean? you only want to upload a specific directory? | 14:36 |
| lornajane | I want to start using bzr-svn, but I have two problems. Firstly, I haven't used bzr much. Secondly, its an ubuntu 8.04 server. Can anyone help me begin? | 14:47 |
| lornajane | the packaged bzr-svn is 0.4.9-1, which I think is quite out of date | 14:49 |
| maxb | lornajane: You'll definitely want to add the ~bzr ppa, where you can get the latest released version of bzr and some associated plugins | 14:54 |
| rubbs | lornajane: you could try to use the ppa that the bzr team maintains. https://launchpad.net/~bzr/+archive/ppa | 14:54 |
| rubbs | bzr-svn is in it | 14:55 |
| rubbs | maxb: you beat me ;) | 14:55 |
| lornajane | ah, thanks people | 14:56 |
| rubbs | np. | 14:57 |
| === nailuj24 is now known as nailuj | ||
| === nailuj is now known as nailuj24 | ||
| rubbs | also if you are new to bzr you could also check out the tutorials. | 14:57 |
| rubbs | we have a new admin doc too... if it's not in the official it's in the beta release of documentation. It should still work for the current versions too | 14:58 |
| rubbs | I'll see if I can dig up a link for you | 14:58 |
| lornajane | the tutorials looked good, one reason I thought I could give it a try | 14:59 |
| rubbs | http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/index.html | 15:18 |
| rubbs | sorry for the long delay got a phone call | 15:18 |
| lornajane | no worries at all, I appreciate your input! | 15:19 |
| rubbs | np... | 15:21 |
| rubbs | oh, that link is to the "beta" documention, but just about everything (if not everything) will work with the currently supported version. The documentation was added after that lastest release, and they probably won't backport it. | 15:22 |
| lornajane | no worries, if something doesn't work I can dig or ask for help. I'm only doing really really basic stuff, making changes and comitting them to svn, but want some of the offline features as I am on the road alot | 15:23 |
| rubbs | you'll probably like bzr and bzr-svn then. | 15:25 |
| lornajane | I hope so. I know a lot of people using git, but I think bzr will suit me better | 15:26 |
| rubbs | I'm just starting to learn git (work is finally getting a VCS) and I can say that for many things I like bzr better. but Git is a good one too. | 15:27 |
| lornajane | I'm a very confident SVN user, but I will probably only use a few features of either git or bzr ... I'm more confident on getting help with bzr which is what swung it | 15:28 |
| rubbs | good to hear. I and others are glad to hear that. we are trying hard to make it easy to get into bzr. | 15:31 |
| lornajane | the docs are brilliant, the users I've met are friendly - I can't ask for more than that :) | 15:32 |
| LeoNerd | How do I show a diff of a shelved change without actually unshelving it? | 15:37 |
| LeoNerd | bzr unshelve --dry-run only prints the summary, the filenames... | 15:37 |
| === beuno is now known as beuno-lunch | ||
| maxb | LeoNerd: I think first you implement the code to do that :-/ | 16:02 |
| LeoNerd | Ahhh... hrm | 16:04 |
| Kinnison | LeoNerd: then you contribute it upstream because that'd be handy for me | 16:04 |
| LeoNerd | Heh.. as if my TODO list wasn't big enough already :P | 16:06 |
| LeoNerd | Well, actually it's more of a TODO tree.. and it's both deep and wide.. I'm on a 4th level dependency | 16:06 |
| fullermd | It's hard sometimes to see the TODO forest for the TODO trees. | 16:07 |
| === beuno-lunch is now known as beuno | ||
| dobey | i just want to say how happy i am that bzr is designed the way it is | 16:48 |
| dobey | thanks | 16:52 |
| === deryck is now known as deryck[lunch] | ||
| ezod | hello, quick question | 17:36 |
| ezod | if i have a branch, bound to a remote branch, and i do a commit --local | 17:37 |
| ezod | is there a better way to subsequently push that commit to the (bound) remote branch than bzr push <url>? | 17:37 |
| ezod | i.e. without respecifying the url that it is already bound to in branch.conf? | 17:37 |
| ezod | coming from git, i would have thought bzr push with no argument would do the trick | 17:37 |
| beuno | ezod, once you push, it will remember the location from then on | 17:38 |
| ezod | yes, it does (url lives in branch.conf), but just "bzr push" still says "bzr: ERROR: No push location known or specified." | 17:39 |
| ezod | oh | 17:39 |
| ezod | i see what you mean | 17:39 |
| ezod | the "saved push location" | 17:39 |
| beuno | yes | 17:39 |
| beuno | I agree that not having a good default sucks a bit | 17:40 |
| ezod | would it not make sense for that to be populated with the current bound location? | 17:40 |
| beuno | well, yes | 17:40 |
| beuno | I think so | 17:40 |
| beuno | but other devs tend to disagree (for good reasons as well) | 17:40 |
| ezod | at least, if it's not already been populated otherwise | 17:40 |
| ezod | ah | 17:40 |
| beuno | bring it up on the mailing list, we can take another stab at the subjectx! | 17:40 |
| ezod | wilco, thanks :) | 17:40 |
| ezod | even like, bzr push --bound or something would be nice | 17:41 |
| ezod | as my current workflow involves digging in branch.conf for the url | 17:42 |
| beuno | I think you can do something with revisionspec | 17:42 |
| * beuno looks it up | 17:42 | |
| fullermd | bzr push :bound | 17:45 |
| beuno | that's it | 17:45 |
| === abentley1 is now known as abentley | ||
| ezod | oh, well that's excellent | 17:46 |
| ezod | thanks | 17:46 |
| fullermd | There are aliases for all the saved locations. :bound, :push, :parent, etc. | 17:48 |
| ezod | very convenient | 17:48 |
| ezod | so :X for X_location in branch.conf i suppose | 17:49 |
| ezod | great | 17:49 |
| vila | ezod: I generally use bzr bind :push, but that's just to contradict fullermd ;-D | 17:55 |
| orattue | is it possible to update a checkout to a specific revision number? e.g. checkout is on revno 10, latest revision of trunk is 20. Can I update my checkout to say revno 15? | 18:26 |
| beuno | orattue, I think update doesn't take a revision | 18:27 |
| orattue | so I would have to branch | 18:27 |
| orattue | hmm | 18:27 |
| beuno | on a branch, sure | 18:27 |
| beuno | bzr pull -r REVNO | 18:27 |
| === deryck[lunch] is now known as deryck | ||
| fullermd | It will in 2.1. But prior to that, yeah, you're down to creating a new branch to fling around with pull. | 18:38 |
| maxb | Hi. Does anyone know why bzr reconfigure has --with-trees and --with-no-trees instead of just --trees and --no-trees? | 19:00 |
| maxb | Is it because the option parser would construe the latter as a single boolean, and reconfigure needs tri-state logic? | 19:01 |
| jam | maxb: My guess is that whoever wrote the option wanted "--with-trees" to indicate an action | 19:01 |
| jam | as "--trees" doesn't really say that you are adding anything | 19:01 |
| * maxb was wondering about adding options to control append_revisions_only | 19:02 | |
| Lostinspace_46 | I am running Karmic. I have tried every permutation of this command...[cp src/bzr-2.0.0-0ubuntu1 public_html/my-repository/binary/] that is bzr2.0.0 and bzr_2.0.0. I keep getting this msg...cp: cannot stat `src/bzr-2.0.0-0ubuntu1'. I am brand new to this, and have no idea what is wrong. Can someone help? | 19:03 |
| jam | Lostinspace_46: let's start by finding out what you are trying to do with this copy | 19:04 |
| jam | are you trying to publish a deb file? | 19:04 |
| jam | are you trying to install a ppa? | 19:05 |
| Lostinspace_46 | jam not quite, I am trying to create a repository as per http://mediakey.dk/~cc/howto-create-your-own-debian-or-ubuntu-package-repository/ | 19:05 |
| jam | Lostinspace_46: I think you are starting pretty far down the road | 19:06 |
| jam | that guide assumes you've already created 'deb' files | 19:06 |
| jam | and are just publishing them | 19:06 |
| jam | as a debian repo | 19:06 |
| jam | You need to go look for a guide as to how to create a deb package first | 19:06 |
| Lostinspace_46 | jam well in a way I am. I am tired of fighting dependencies, so I decided it would be easier to repack "from site" as debs and put them in a repository so I can use deb installer. | 19:08 |
| Lostinspace_46 | "from site" pkgs that is | 19:09 |
| jam | Lostinspace_46: Do you have a bzr deb that you are trying to set up this way? | 19:11 |
| jam | At a minimum, I would expect it to end in ".deb" | 19:11 |
| jam | (this also is a bit off-topic for #bzr, but we can try to help) | 19:11 |
| Lostinspace_46 | jam Why is it off topic? That's not an arguement, I just don't understand. And if you know a better place to ask, I will. | 19:13 |
| jam | #bzr is a place to ask questions about the Bazaar Version Control System | 19:13 |
| jam | not really debian packaging and repositories | 19:13 |
| jam | (or ubuntu using debs, etc) | 19:13 |
| jam | #ubuntu might be better | 19:13 |
| Lostinspace_46 | jam Hmm, I think I follow. I'll try #ubuntu. Thanks for the help. | 19:15 |
| rubbs | my job just decided to finally get a VCS (I've been fighting for this since I got here) and they chose git. (decision made without me really) I'm very used to bzr. how feasible is it to do development with bzr-git? is there a git tutorial for bzr users? I've tried asking on #git, but no-one's answering. I"m not expecting anyone to know this stuff off the top of their heads, but I thought I'd ask. | 19:35 |
| ronny | bzr-git mostly works, it cant yet do normal push tho, as git lacks metadata support, so you'll have to use dpush+rebasing | 19:45 |
| rubbs | is there any tutorial on how that works? coming from bzr I've never rebased (or needed to). | 19:46 |
| jam | rubbs: I believe jelmer uses bzr-git to develop dulwich (the python git bindings) | 19:46 |
| jam | rubbs: it amounts to using "dpush $UPSTREAM" rather than "push" | 19:46 |
| rubbs | jam: ok, cool thanks. | 19:46 |
| jam | which, IIRC, will rewrite your local branch to be based on the new git commits | 19:47 |
| jam | It does mean there is some headaches if you do a lot of merging on the bzr side | 19:47 |
| rubbs | mmm... well maybe I'll try some trial stuff on a test repo or two to see if I can get my work flow to work. If not I'll just learn git. It couldn't hurt to know them both. | 19:48 |
| mtaylor | hey ho... | 21:06 |
| mtaylor | bzr: ERROR: CHKInventoryRepository('http://bazaar.launchpad.net/~drizzle-developers/drizzle/development/.bzr/repository/') | 21:06 |
| mtaylor | is not compatible with | 21:06 |
| mtaylor | KnitPackRepository('http://bazaar.launchpad.net/~elambert/drizzle/gearman_replication_applier/.bzr/repository/') | 21:06 |
| mtaylor | elambert:drizzle elambert$ bzr upgrade --2a lp:~elambert/drizzle/gearman_replication_applier | 21:07 |
| mtaylor | bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format. | 21:07 |
| bjesus | anyone knows how the see the current revision in my working tree? | 21:24 |
| bob2 | bzr revno | 21:24 |
| bob2 | or do you want the revid? | 21:24 |
| bjesus | nope, i've got a lightweight checkout which isn't always updated. revno gives me the latest revision on the master branch | 21:24 |
| bjesus | what's the revid? | 21:24 |
| bob2 | a globally unique identifier | 21:25 |
| bob2 | revnos are only useful within a particular branch | 21:25 |
| bjesus | well no, i guess that i want the revno, but i want to know the latest current revno, not the latest available. when running bzr revno from my lightweight checkout it connects to the server and tells gives me the latest revision | 21:26 |
| fullermd | revno --tree | 21:26 |
| bjesus | says there's not such option... is it new or something? | 21:27 |
| fullermd | Not terribly. 1.17, NEWS says. | 21:28 |
| bjesus | um... centos latest is 1.7.1... i'll try to update, thanks. | 21:28 |
| fullermd | Guh. | 21:29 |
| bjesus | thanks fullermd. i compiled 2.0.3 from source and it worked. but, now i still asks me for password, even though it shouldn't connect to the remote server at all. why is that? is there a way to skip it? | 21:40 |
| m3ga | having some trouble writing a bzr pre-commit hook plugin. can someone please have a look at this : http://paste.lisp.org/display/93159 | 21:45 |
| m3ga | and explain whats wrong? | 21:45 |
| m3ga | i have written any python since 2003. most use C, C++, ocaml and haskell | 21:46 |
| fullermd | bjesus: Well, it has to have a branch context to give you a revno. | 21:51 |
| bjesus | fullermd: why? I mean, last time i did 'bzr update' it wrote the revision it updated to, so why can't i see it again? | 21:52 |
| bjesus | fullermd: anyway, i need to see that revision without a password. would writing a hook be good? | 21:53 |
| fullermd | Because a revno only has meaning in the context of a particular branch (technically, a particular head), because it's related to the position in the branch. | 21:53 |
| maxb | bjesus: It wrote the revision id ( a string like launchpad@pqm.canonical.com-20081022214747-h2sphj9zcuh1c1cq ) but to look that up to get the number, it needs to talk to the branch | 21:53 |
| fullermd | You could get the revid without connecting probably, with revision-info | 21:53 |
| fullermd | And the revno may be different now than it was when you update'd. | 21:54 |
| lifeless | m3ga: findall doesn't take a regex, it takes a string for the regex | 21:54 |
| lifeless | m3ga: if you have a regex, you call regex.match, or whatever. | 21:54 |
| m3ga | re.search gives the same error | 21:55 |
| bjesus | fullermd: nope, revision-info also askes for the password. can i write a hook that creates a text file with the revno each time i do 'bzr update'? | 21:55 |
| lifeless | you are doing | 21:55 |
| bjesus | just checked, seems like there's only post_pull but no post_update... :( | 21:56 |
| lifeless | re [the module].findall [the convenience function] (copyright_re [the regex object], ...) | 21:56 |
| fullermd | Oh, it shows the revno too. Mmm. | 21:56 |
| lifeless | m3ga: thats wrong - use the object directly! | 21:56 |
| lifeless | copyright_re.findall(... | 21:56 |
| lifeless | m3ga: or | 21:56 |
| lifeless | m3ga: do re.findall(thestringyouwantcompiletoaregex,...) | 21:57 |
| fullermd | I've got an alias for revid that uses 'version-info', but I'm not sure whether that checks tree or branch. | 21:57 |
| fullermd | (and probably isn't smart enough to pre-optimize what info it looks up anyway) | 21:57 |
| fullermd | bjesus: The problem is, that revno from then may not be of any use to you. | 21:57 |
| m3ga | copyright_re.findall (content) -> bzr: ERROR: exceptions.TypeError: expected string or buffer | 21:58 |
| lifeless | m3ga: ok, so what is content | 21:58 |
| m3ga | content = future_tree.get_file_lines (file_id) | 21:58 |
| lifeless | that will be a list of lines | 21:58 |
| lifeless | content = ''.join(future_tree.get_file_lines (file_id)) | 21:58 |
| lifeless | actually,there is a helper in osutils somewhere, but the above will get you going | 21:59 |
| bjesus | fullermd: revno is of use for me. why do you think it isn't? you are right though, version-info does gives me the current revno. but, it also asks for my password... | 21:59 |
| m3ga | yay! compile time types would have been nice :-) | 21:59 |
| m3ga | thanks lifeless | 21:59 |
| fullermd | bjesus: Because the revno of that revision in that branch at the time you updated may not be its revno now. | 22:04 |
| bjesus | why not? how can it be changed? | 22:05 |
| fullermd | It can potentially change any time the head of the branch moves. | 22:05 |
| lifeless | m3ga: np | 22:06 |
| fullermd | It may happen all the time, or it may hardly ever happen, depending on the workflows you're using. | 22:06 |
| lifeless | unless you set append_only | 22:07 |
| lifeless | which you can if you want revnos to be stable | 22:07 |
| fullermd | It may be that caching it would "usually" tell you something useful, in your setup, but there's no way to be sure other than checking. | 22:07 |
| fullermd | Well, that would be one permutation of 'workflow' :p | 22:07 |
| bjesus | i don't get it. I've got A and B doing bzr commit and bzr update to C. both A and B a are lightweight checkouts, and C is just a server, no work being done there. When doing bzr commit', bzr tells me "commited revision xxxx". and it never changes... | 22:07 |
| m3ga | lifeless: quite honestly, coming back to python after not using it for over 5 years is just as confusing as using haskell for the first time | 22:07 |
| lifeless | m3ga: If you want to write bzr-haskell [bindings], that would be fine with me :) | 22:08 |
| bjesus | what's append_only? | 22:08 |
| fullermd | If two lightweight checkouts are the only way revs ever get into it, it would probably be pretty difficult for the numbers to change. | 22:08 |
| fullermd | bjesus: http://wiki.bazaar.canonical.com/MatthewFuller/AboutMainline is a moderate-length discussion of the numbering. | 22:08 |
| m3ga | lifeless: NO! | 22:08 |
| lifeless | bjesus: its a setting which prevents revnos that are allocated ever changing [in a given branch] | 22:08 |
| lifeless | bjesus: for instance, if you want to see a revno change in your setup, the 'uncommit' comand will do that: | 22:09 |
| lifeless | it will pop the most recent commit off your branch, and then when you commit again you'll 'reuse' the revno. | 22:09 |
| bjesus | and do think that if i'd set append_only on, it wouldn't ask me for the password? | 22:09 |
| lifeless | fullermd: ^ simplest explanation I know of: its clear, selfcontained, doesn't need discussion of merges mainlines etc | 22:10 |
| * fullermd files that away for reuse. | 22:10 | |
| lifeless | bjesus: its asking for the password because you're doing operations over the network. | 22:10 |
| fullermd | No, that setting just makes it take extraordinary effort to cause the revnos to change. It doesn't change bzr needing the branch context to figure them out. | 22:11 |
| bjesus | okay... and if i'll do with the revid, which as i far as i can understand is unique and never changes - would then there would be an option to see the current revid without networking? | 22:11 |
| fullermd | Not through the UI, I don't think. You could get it by manually poking under the covers. | 22:11 |
| lifeless | bjesus: if you're using lightweight checkouts, every operation that inspects the tree will connect to the network. | 22:12 |
| lifeless | bjesus: with no exceptions. | 22:12 |
| fullermd | Either with a little bzrlib usage in python, or by writing a stupid parser that knows just enough of the dirstate format to yank it out in your Language Of Choice. | 22:12 |
| lifeless | fullermd: bzrlib won't permit it either, not while using any of the support abstractions | 22:13 |
| fullermd | Oh? You can't just open the tree without it looking for the branch? | 22:13 |
| lifeless | fullermd: correct | 22:13 |
| fullermd | That sounds bogus. | 22:13 |
| bjesus | so there's no way to know when the checkout was last updated without network if using lightweight checkouts? | 22:14 |
| lifeless | fullermd: it wants a branch object, that could be a thunk. | 22:14 |
| lifeless | bjesus: thats correct | 22:14 |
| bjesus | yeah, tried bzr lib before. it asked me for the password too... | 22:14 |
| lifeless | bjesus: in fact, there's no way to know at all, because we don't store 'when an update was done', only 'revision parents' - which is a totally different thing. | 22:14 |
| lifeless | so you can figure out what the parents are, and they can be used to get a lower bound on the time of the last commit | 22:15 |
| fullermd | Well, you could guess "when" from timestamps. But you presumably don't really want to know "when", you want some pointer to "what revision". | 22:15 |
| lifeless | or at least on the time on the machine that did the last commit which has been pulled into the tree | 22:15 |
| bjesus | well yeah but i don't care much. be it either when or what revision, i just need to know something about what files i have on my lightweight checkout, whichout connecting... | 22:16 |
| fullermd | Of course, you couldn't even figure the dates of the commits without talking across the network on a light co. | 22:16 |
| lifeless | bjesus: I missed your initial problem statement. What are you trying to achieve? | 22:17 |
| m3ga | is there a neater way of failing out of a pre-commit hook than raising a ValueError? | 22:20 |
| bjesus | simple. i've got a web application in a bzr branch on server A. it isn't being used there, it isn't even running. just the code is there. Server B and C are running the application, and sometimes i change something in the code in one of them. I can do a lot of commits on server C, and before upgrading server B, i want to know it's state. So i want my web application to be able to tell the current revision, so i can just go to myapp.com/revision and it would y | 22:20 |
| bjesus | the revision it's running. but i can't find any way to get that revision without entering the password, and i don't want to use ssh keys here. | 22:20 |
| lifeless | m3ga: raising an exception is correct | 22:21 |
| lifeless | m3ga: ValueError is ok, BzrError with a format string might print nicer on the console | 22:21 |
| lifeless | bjesus: it cut off at 'would y | 22:22 |
| lifeless | ' | 22:22 |
| bjesus | would yank the revision it's running. but i can't find any way to get that revision without entering the password, and i don't want to use ssh keys here | 22:22 |
| m3ga | where do i import BzrError from? | 22:23 |
| fullermd | So, you could cache the revid (or suck it out of dirstate) somehow, and it would always be right. You could cache the revno somehow, and it would maybe be right. | 22:23 |
| fullermd | It sounds like you're running out of the branch directly, rather than having the files installed by some sort of build process you kick off, so you couldn't jam something in there. | 22:23 |
| fullermd | If keyword support was more mature, you could use that. | 22:23 |
| bjesus | yeah, i'm running out of branch directly since it's an application which is constantly changing. from what i've checked, seems like keyword support isn't there it and mostly works with bzr export. what do you mean "cache the revid"? how? got any pointers? | 22:26 |
| fullermd | Not really. If I had to ugly-do it today, I'd bung up a few lines of code to scrape it out of dirstate. | 22:27 |
| bjesus | umm... seems like getting the revid from dirstate isn't hard - it's quite a the top. i can't find revid there but maybe i'll go this way.. | 22:29 |
| bjesus | *can't find revno there | 22:29 |
| fullermd | It isn't. | 22:29 |
| fullermd | (AFAIK, and I'd be surprised) | 22:29 |
| bjesus | yup, it isn't. thanks a lot anyway, i'll see what i can do from here :) | 22:30 |
| lifeless | m3ga: bzrlib.errors | 22:42 |
| lifeless | bjesus: I can suggest two things for you | 22:43 |
| bjesus | i'd be glad to hear | 22:43 |
| lifeless | bjesus: one, a post pull/update hook to stash the info for you | 22:43 |
| lifeless | bjesus: e.g. it would invoke bzr version-info for you | 22:43 |
| lifeless | bjesus: alternatively, when you update do that manually | 22:44 |
| bjesus | well, i can do it manually but i've got some other users which would create a mess. as for the hook - that sound's good, but by looking at the hooks list it seems like there's a post_pull but not a post_update hook. | 22:46 |
| bjesus | actually, what would happen if i'll start doing 'bzr pull' instead of 'bzr update'? is there a difference? can a lightweight checkout do that? | 22:47 |
| lifeless | bjesus: you need a branch to be using pul | 22:51 |
| lifeless | bjesus: we can add a hook for post_update quite easily. Its, oh, 15 lines of code-and-docs or so, plus a test or two. | 22:52 |
| bjesus | well, isn't my main server a branch? i'm doing bzr update from there, isn't it a branch? | 22:52 |
| lifeless | bjesus: the object you are updating is not a separate branch | 22:52 |
| lifeless | bjesus: if you pull, you'd be altering the main server as well because thats where your branch is | 22:53 |
| bjesus | oh, got it. | 22:53 |
| bjesus | so you say i should fill a RFE for post_update? | 22:55 |
| lifeless | WorkingTree.post_parents_change | 22:55 |
| lifeless | yes | 22:56 |
| bjesus | okay, last question - what's WorkingTree.post_parents_change ? :p | 22:58 |
| lifeless | the name of the hook you should ask for | 22:59 |
| bjesus | why not post_update? | 22:59 |
| lifeless | I prefer to make the most useful hook I can when adding a new hook | 23:00 |
| bjesus | but what does post_parents_change means? how is it different? | 23:00 |
| lifeless | commit, push, pull, uncommit will trigger it as well | 23:01 |
| maxb | and merge? | 23:01 |
| lifeless | yes | 23:01 |
| bjesus | oh, okay | 23:01 |
| lifeless | up-thread, down-thread, pump too | 23:01 |
| bjesus | https://blueprints.launchpad.net/bzr/+spec/post-parents-change-hook/ | 23:12 |
| lifeless | bjesus: oh, just file a bug | 23:19 |
| lifeless | bjesus: blueprints are generally massive overkill | 23:20 |
| bjesus | you sure? it's not really a bug, isn't it? i mean, it's not like there's something wrong about bazaar... :s | 23:20 |
| lifeless | bjesus: I'm sure | 23:22 |
| lifeless | bjesus: bugs are not exclusively 'a defect in what we thought was working correctly' | 23:23 |
| lifeless | bjesus: more generally, we don't manage work via blueprints: most of our work is bug centric, so blueprints tend to get ignored, and launchpad doesn't provide an integrated view. | 23:24 |
| lifeless | I wish blueprints and bugs were merged in launchpad in fact; it would be a lot simpler to work with. | 23:24 |
| lifeless | if they were,for example, a slightly different UI on the same underlying concept | 23:25 |
| bjesus | okay, i'm filling a bug report. | 23:25 |
| NfNitLoop | Hrmm. I thought I read that bzr-svn would populate svn:merge properties. Does it not read them as well? this branch's history looks very linear when it's mostly merges from another. | 23:25 |
| lifeless | NfNitLoop: I don't know if it reads them yet, jelmer would know but hes on a plane | 23:26 |
| NfNitLoop | how inconvenient for *me*! ;) | 23:26 |
| NfNitLoop | I s'pose I could read some docs. | 23:26 |
| * NfNitLoop does. | 23:26 | |
| * fullermd . o ( irssi connect --bind... ) | 23:27 | |
| NfNitLoop | aah: Other features currently held back by Bazaars feature set: Showing SVN merges as merges in Bazaar | 23:28 |
| bjesus | @ https://bugs.launchpad.net/bzr/+bug/504997 | 23:29 |
| NfNitLoop | that's OK then. :) | 23:29 |
| ubottu | Launchpad bug 504997 in bzr "post_parents_change hook" [Undecided,New] | 23:29 |
| bjesus | oops :) didn't know it would happend automagically | 23:29 |
| lifeless | bjesus: it doesn't, you referenced it | 23:31 |
| maxb | NfNitLoop: What do you mean by svn:merge? That's not a normal property | 23:33 |
| maxb | You probably mean one of svnmerge-integrated, svk:merge, or svn:mergeinfo | 23:33 |
| NfNitLoop | ah, svn:mergeinfo. Whatever it's called. ;) | 23:34 |
| maxb | Yeah. I kinda need support for that too :-) | 23:35 |
| NfNitLoop | I can see why it's not there. in svn you can merge in any revision (cherrypick). You can't quite do that in bzr. | 23:36 |
| fullermd | Well, you can also merge in random files or subparts of a branch (or superparts of a branch, come to that) | 23:37 |
| NfNitLoop | oh, good point. | 23:37 |
| NfNitLoop | yeah, SVN's data model is... special. :p | 23:37 |
| ronny | it woultn be that much of an issue is svn had propper tools to work with that, but it doesnt | 23:39 |
| fullermd | Mmm. "superparts" is an interesting etymological construction... I'll have to try using it sometime it can really mess people up. | 23:39 |
| NfNitLoop | ronny: what would propertools to work with that look like? | 23:39 |
| ronny | NfNitLoop: something that helps figuring the relations between subtrees | 23:40 |
| NfNitLoop | aah. yeah. | 23:40 |
| fullermd | Seems tough to do, since the relation among subtrees is entirely transitory. | 23:41 |
| NfNitLoop | well, you can sortof do that. Just "svn log" till you see the branch copy, then you know those two things are branches of each other. | 23:41 |
| ronny | fullermd: thats why svn's history model is a complete engineering fail | 23:41 |
| NfNitLoop | or, at least, were at one time. | 23:41 |
| ronny | if one needs seriously smart tools to figure what the history is like, something is wrong | 23:42 |
| ronny | hg/git/bzr do better there | 23:42 |
| fullermd | Well, by restricting the meaningful actions. That's an easy way to make existing models capable of holding your results 8-} | 23:46 |
| ronny | well, filtering out all the stuff that is insanely hard to support | 23:48 |
| NfNitLoop | and/or nonsensical. | 23:48 |
| fullermd | Eye of the beholder. | 23:49 |
| ronny | the kiss principle is powerfull | 23:49 |
| fullermd | SVN lets you "branch" a file within a branch, and merge changes. It's not overly hard to dream up cases where that's useful. | 23:49 |
| fullermd | Branch subparts of a branch has its uses too. | 23:50 |
| ronny | fullermd: working with strict subtrees can actually be simple | 23:50 |
| ronny | but svn doesnt restrict it | 23:51 |
| fullermd | Well, there are a lot of bits&pieces of these things that aren't conceptually hard to do in a DVCS, except for the 'D' part. | 23:51 |
| ronny | D part ? | 23:51 |
| fullermd | I mean, if your repository is all in one place, who cares that you have to [internally] copy 200 gigs of history to copy the 180k of history for the subtree you're branching? | 23:51 |
| fullermd | Whereas if you're distributed, you care a whole lot. | 23:52 |
| ronny | fullermd: thats where partial history support starts to matter | 23:52 |
| ronny | bzr has, hg will have, no idea about git | 23:52 |
| fullermd | Well, but there's two types of partial history support involved. | 23:53 |
| lifeless | git has alternates, functionally equivalent to stacking | 23:53 |
| fullermd | One is simple horizons, which any of the above can do. | 23:53 |
| lifeless | hg has punching, which is a bit different | 23:53 |
| fullermd | The other is slicing subsets of the tree, which is a LOT harder. | 23:53 |
| ronny | lifeless: punching? | 23:53 |
| fullermd | hg might have the easiest time; I think their lower levels are a lot more file-oriented than bzr/git. | 23:53 |
| lifeless | ronny: history punching, its what hg calls it | 23:54 |
| fullermd | (certainly their storage is, but I have vague memories of discussions suggesting that it leaks up higher too) | 23:54 |
| lifeless | they keep the index, but discard the content | 23:54 |
| ronny | lifeless: thats not what i meant | 23:54 |
| ronny | lifeless: there was some work on something comparable to bzr ghost revisions | 23:55 |
| ronny | lifeless: i dont think punching is in the actual official hg, seems more like a external patch | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!