| fullermd | bash? People still use that? :p | 00:02 |
|---|---|---|
| Odd_Bloke | *BSD? People still use that? ;) | 00:02 |
| * fullermd is single-handedly keeping it from dying. | 00:03 | |
| lifeless | keyboards? | 00:03 |
| fullermd | "The keyboard. How quaint." | 00:03 |
| Odd_Bloke | (People still use those?) | 00:03 |
| lifeless | does anyone know what irc nick marius uses? | 00:04 |
| lifeless | 99 round trips to push a new trivial branch | 00:06 |
| abentley | lifeless: amanic | 00:06 |
| lifeless | abentley: thanks | 00:06 |
| fullermd | Take one down, pass it around... | 00:07 |
| lifeless | fullermd: yeah looking at that :) | 00:07 |
| lifeless | vila: ping | 00:07 |
| Odd_Bloke | Next format: 'bottlesofbeer-core' | 00:07 |
| AfC | fullermd, Odd_Bloke: :) | 00:11 |
| === abentley1 is now known as abentley | ||
| lifeless | this is weird | 00:41 |
| lifeless | pqm hates my branch, but the failing test passes locally >< | 00:41 |
| === ameoba_ is now known as ameoba | ||
| poolie | lifeless: which test? | 00:50 |
| lifeless | branch_implementations.test_branch.TestTestCaseWithBranch.test_branch_format_matches_bzrdir_branch_format(RemoteBranchFormat-v2) | 00:52 |
| lifeless | branch_implementations.test_branch.TestTestCaseWithBranch.test_branch_format_matches_bzrdir_branch_format(RemoteBranchFormat-default) passes | 00:52 |
| lifeless | which adds to the oddity | 00:52 |
| spm | lifeless: oops. let me just remove the "fail-lifeless'-branches-spuriously" config option from bzr pqm.... :-P | 00:53 |
| lifeless | spm: pqm runs make check yes? | 00:59 |
| spm | lifeless: yup (verified) | 01:00 |
| lifeless | python 2.4? | 01:00 |
| spm | Python 2.4.3 | 01:02 |
| spm | in the chroot as in | 01:02 |
| lifeless | thanks | 01:03 |
| === orospakr` is now known as orospakr | ||
| thumper | I have a repository object that is on my local filesystem | 01:37 |
| thumper | and I want to pull in some revisions from a remote branch | 01:37 |
| thumper | without creating a branch locally | 01:37 |
| thumper | how do I do this? | 01:37 |
| Odd_Bloke | thumper: Shared repositories are purely a storage mechanism. | 01:38 |
| Odd_Bloke | Which is to say: there isn't a way. | 01:38 |
| thumper | Odd_Bloke: well, abentley told me there was a way :) | 01:38 |
| Odd_Bloke | But branching into the shared repo and then deleting the branch should have the desired effect. | 01:38 |
| thumper | Odd_Bloke: and I think jamesh has done the before | 01:38 |
| Odd_Bloke | Actually, 'bzr pull -r revid:... <REMOTE LOCATION>' might do it. | 01:39 |
| jamesh | repository.fetch() perhaps? | 01:39 |
| Odd_Bloke | And it's certainly possible in bzrlib. | 01:39 |
| Odd_Bloke | (Which it now occurs to me you might have been talking about. >.<) | 01:40 |
| thumper | jamesh: ta | 01:40 |
| thumper | ah | 01:41 |
| thumper | ha | 01:41 |
| thumper | y'know what | 01:41 |
| thumper | this code is written already | 01:41 |
| * thumper smacks himself | 01:42 | |
| baxissimo | Howdy, I'm having trouble deciding how to convert my svn repo... where to draw the branch lines, basically. | 01:43 |
| jamesh | thumper: the code I did for that bzr-gnomeserver plugin? | 01:43 |
| thumper | jamesh: no, it came from a gobby session I had with abentley | 01:43 |
| jamesh | thumper: ah. I think I did something like this in that gnomeserver plugin to make sure a repository contained all the revisions from another repository without creating a branch. | 01:44 |
| thumper | jamesh: yeah, I remember you writing it | 01:44 |
| thumper | jamesh: I'm working on my version of your old pending reviews | 01:45 |
| thumper | script | 01:45 |
| jamesh | making it launchpadlib aware? | 01:45 |
| thumper | yep | 01:45 |
| thumper | I have all the launchpadlib bits in place now | 01:45 |
| thumper | or will have very shortly | 01:45 |
| jamesh | cool. are you allowed to make that code public yet? | 01:45 |
| baxissimo | I've got top-level dirs in SVN like app/ and lib1/ lib2/. The libs are used by app/ but also could be used without app/ | 01:46 |
| thumper | jamesh: it will be public as soon as it is written | 01:46 |
| baxissimo | Best to put all three in one repo? or three separate repos? | 01:46 |
| thumper | jamesh: users will be able to run it locally | 01:46 |
| thumper | hmm.. Branch.open doesn't like lp: style urls | 01:48 |
| thumper | load plugins maybe? | 01:48 |
| thumper | yep, that did it | 01:49 |
| baxissimo | Any advice? | 01:50 |
| lifeless | baxissimo: 'bzr svn-import SVN-REPO-ROOT BZR-REPO-ROOT' | 01:51 |
| baxissimo | lifeless: q isn't what command to use but whether it's better in general to have three .bzrs for three related but independent things, or one .bzr containing all three. | 01:52 |
| lifeless | baxissimo: I don't think there is a general answer to the question | 01:53 |
| baxissimo | I frequently make changes to the libs same time as the app, so like being able to have all changes committed with one commit. | 01:53 |
| baxissimo | But I'd also like to be able to branch just a lib or just the app. | 01:54 |
| baxissimo | Is it the case I have to pick one or the other of those capabilities? | 01:54 |
| lifeless | yes | 01:55 |
| lifeless | (sorry) | 01:55 |
| baxissimo | Ok. No, that's helpful. Now I can stop looking for how to get both at once. :-) | 01:56 |
| baxissimo | Any chance of "bzr externals" at some point a la svn externals? | 01:57 |
| baxissimo | I.e. have multiple branched locations collected in a single directory tree so that one update/commit/pull will hit all the locations. | 01:59 |
| bob2 | I think you mean "branch" not "repository" btw :) | 01:59 |
| lifeless | baxissimo: not yet, but there is some hope we'll get something soon | 01:59 |
| bob2 | you can do that with the repo-push or multi-pull plugins | 01:59 |
| baxissimo | bob2: grr. Ok what do I call the stuff that's in a .bzr dir? | 02:00 |
| baxissimo | bob2: That actually contains all the history | 02:00 |
| lifeless | baxissimo: .bzr/repository is a repository | 02:02 |
| lifeless | baxissimo: .bzr/branch is a branch :) | 02:02 |
| bob2 | it might be simpler to just forget about repositories entirely | 02:02 |
| lifeless | baxissimo: a .bzr can have either or both of these things (and more besides, like working trees [.bzr/checkout], search indices [.bzr/bzr-search], etc) | 02:03 |
| baxissimo | bob2: ok. I mostly meant "a place where all the history actually lives" as opposed to one of those lightweight or stacked branches that doesn't actually contain any history. | 02:03 |
| lifeless | baxissimo: that is indeed a repository | 02:04 |
| baxissimo | bob2: I'll check out those repo-push and multi-pull plugins. | 02:05 |
| lifeless | they don't give you commit coherency | 02:05 |
| lifeless | which was one of the things you asked for | 02:05 |
| baxissimo | lifeless: so what do you call the .bzr dir that can have all of that? | 02:05 |
| lifeless | baxissimo: a .bzr dir | 02:06 |
| lifeless | (literally, in the code its 'BzrDir') | 02:06 |
| baxissimo | lifeless: .bzr dir. Ok. I'll see if I can remember that one at least. :-) | 02:06 |
| lifeless | baxissimo: you can't 'push' or 'checkout' or 'clone' or run nearly any UI commands just on a '.bzr' dir though - you generally have to have a branch [.bzr/branch] to run any UI commands | 02:06 |
| lifeless | baxissimo: bzr is very focus on branch level operations | 02:07 |
| baxissimo | lifeless: ok I was focusing on the .bzr dirs since they seem to be the easiest way to see if the files I have are all part of one branch or come from separate branches. | 02:08 |
| lifeless | baxissimo: 'info' and 'branches' are two commands you might like | 02:08 |
| baxissimo | lifeless: ok, but I can see right from Explorer if there's a .bzr or not without typing any commands. :-) | 02:09 |
| AfC | Should we still be using curl or is it time to stop building with that? | 02:09 |
| baxissimo | lifeless: what did you mean by "no commit consistency" -- that I'll have to issue commit once for each branch even with those plugins? | 02:10 |
| lifeless | baxissimo: exactly | 02:10 |
| lifeless | AfC: ask vila on the list - he knows all https :) | 02:11 |
| baxissimo | lifeless: so they make it so pulling/updating can be done with one command? | 02:11 |
| lifeless | yes | 02:11 |
| AfC | lifeless: um, oh, right. I was using bzr:// so I guess curl doesn't come into it. | 02:13 |
| AfC | lifeless: I was a bit surprised to see it sitting for 40 seconds at 0/7805 while it downloaded something huge and then over about 3 seconds cycled through all the integers up to 7805 and moved onto the next thing that it sat at 0/ for a while. | 02:14 |
| AfC | lifeless: I naively wondered if the to-curl-or-not-to-curl thing was to blame. | 02:15 |
| lifeless | AfC: what release? | 02:15 |
| AfC | 1.12 | 02:15 |
| AfC | lifeless: ^ | 02:15 |
| lifeless | AfC: and were you seeing network download counters? | 02:15 |
| AfC | no | 02:15 |
| AfC | lifeless: come to think of it, having seen a download counter in a pull was why I tried the raw branch | 02:15 |
| AfC | lifeless: wanting to see what it said. Let me try again. | 02:15 |
| lifeless | thats odd, I was sure there was a patch to do network counters for bzr*:// | 02:16 |
| baxissimo | Does bzrtools work on Windows? The lack of a .zip is usually a bad sign. | 02:16 |
| * AfC notes that there seems to be an awful lot getting packed onto that progress line. I wonder if a standard 80 char wide terminal isn't wide enough | 02:16 | |
| AfC | Nope | 02:19 |
| baxissimo | Doh, [/me smacks forehead] looks like bzrtools are installed by default with the Windows installer. | 02:19 |
| AfC | that's not a problem | 02:19 |
| AfC | lifeless: I'd have to guess that the download counter only works over http transport. | 02:21 |
| AfC | And indeed 80 columns is NOT wide enough. Yetch. | 02:21 |
| AfC | lifeless: yeah. It's http only (in 1.12, anyway) | 02:22 |
| thumper | AttributeError: 'RemoteBranch' object has no attribute 'supports_rich_root' | 02:23 |
| thumper | poos | 02:23 |
| lifeless | thumper: branches don't affect rich root support | 02:23 |
| lifeless | thumper: what are you doing? | 02:24 |
| spiv | There's a patch for hpss download counters, but I didn't get time to decide how it should interact with vila's socket-wrapping approach for the HTTP ones. | 02:28 |
| baxissimo | lifeless,bob2: ok, seems like repo-push isn't what I want. I don't want to "push all branches to another [single] location", I'd want to push all branches to their different respective locations. | 02:28 |
| spiv | So I decided against rushing it into 1.12 late in the release cycle. | 02:28 |
| baxissimo | But multi-pull looks good. Thx for the pointer. | 02:28 |
| bob2 | baxissimo: that's what repo-push does | 02:29 |
| baxissimo | bob2: the command description makes it sound like it only works with 1 destination location. | 02:30 |
| lifeless | thumper: jml: mwhudson: lp:foo through proxies - http://docs.python.org/library/xmlrpclib.html#example-of-client-usage | 02:30 |
| bob2 | baxissimo: yes... | 02:30 |
| lifeless | jamesh just dug that up | 02:30 |
| bob2 | baxissimo: /local/foo/liba -> /remote/whatever/liba, /local/foo/libb -> /remote/whatever/libb | 02:31 |
| bob2 | ideally, at least, it was broken last time I tried it | 02:31 |
| baxissimo | bob2: ok, so you couldn't have a --> /remote/whatever/a b --> /somewhere/else/something/b then? | 02:32 |
| thumper | lifeless: repository.fetch from a branch | 02:32 |
| lifeless | thumper: b = Branch.open('remote') | 02:33 |
| lifeless | refs = b.get_last_revision_info()[0] + b.tags.get_tags_dict().values() | 02:33 |
| lifeless | for ref in refs: target.fetch(b.repository, ref) | 02:33 |
| * thumper tries | 02:34 | |
| lifeless | or something ~= to that | 02:34 |
| thumper | AttributeError: 'RemoteBranch' object has no attribute 'get_last_revision_info' | 02:37 |
| thumper | last_revision()? | 02:37 |
| lifeless | last_revision_info(), or sure, last_revision() | 02:38 |
| thumper | does bzr tag it's revisions in lp:bzr? | 02:41 |
| thumper | 'cause I'm not seeing any using Branch.open('lp:bzr').get_tag_dict() | 02:41 |
| thumper | insert a .tags in there too | 02:41 |
| === _[PUPPETS]Gonzo is now known as [PUPPETS]Gonzo | ||
| lifeless | thumper: there is something weird with pqm, they don't propogate through the merge process | 02:47 |
| lifeless | thumper: in the general case, tags for releases aren't in trunk anyhow | 02:47 |
| lifeless | thumper: anyhow, see that link above? | 02:47 |
| lifeless | there is a bug/limitation in the bzr-lp plugin which it allows fixing | 02:48 |
| thumper | which one? | 02:48 |
| thumper | the docs.python.org one? | 02:48 |
| lifeless | yes | 02:49 |
| lifeless | thumper: bug 330823 - its a dup of a much older one | 02:59 |
| ubottu | Launchpad bug 330823 in bzr "Branching from Launchpad (direct via http) fails behind HTTP/DNS proxy" [Undecided,New] https://launchpad.net/bugs/330823 | 02:59 |
| thumper | base = graph.find_unique_lca(rev1, rev2) | 03:06 |
| thumper | why does this raise ObjectNotLocked? | 03:06 |
| lifeless | thumper: because your backing repository isn't locked | 03:07 |
| thumper | lifeless: and I lock and unlock how? | 03:07 |
| lifeless | we used to autolock but had too many cases of 'its slow because its continually refreshing the object list' | 03:07 |
| lifeless | tree|branch|repository.lock_read(), unlock() | 03:08 |
| * igc heads off for lunch & medical stuff | 03:09 | |
| lifeless | thumper: why do you need that though? | 03:10 |
| thumper | lifeless: ;-) you'll see | 03:10 |
| thumper | bzrlib.errors.NoCommonAncestor: Revisions have no common ancestor: | 03:11 |
| thumper | I don't believe it | 03:11 |
| thumper | how can I manually confirm? | 03:13 |
| thumper | I think it is lying to me | 03:13 |
| jml | lifeless: I wonder if 2.4 supports that: http://www.python.org/doc/2.4.4/lib/module-xmlrpclib.html | 03:14 |
| lifeless | jml: if it doesn't, we could version-check | 03:15 |
| jml | lifeless: anyway, I *think* I knew about that already :) | 03:15 |
| thumper | abentley: ping | 03:17 |
| * thumper calculates time zones | 03:17 | |
| * thumper thinks abentley may still be up | 03:17 | |
| lifeless | thumper: you can traverse the graph by hand, but its not lying to you | 03:17 |
| thumper | lifeless: the graph is obviously not complete | 03:18 |
| thumper | lifeless: as the revisions are related | 03:18 |
| bob2 | baxissimo: you can, but afaik repo-push nor multi-pull will do it for you | 03:18 |
| lifeless | thumper: or something; but without some details on what you're doing I can't comment sensibly | 03:18 |
| thumper | lifeless: I have a repo with no branches but a bunch of revisions | 03:18 |
| thumper | lifeless: which I have populated with repository.fetch yadda yadda | 03:19 |
| bob2 | baxissimo: in practice 'for dir in *(/); (cd $dir ; bzr pus) ; done' may suffice | 03:19 |
| thumper | lifeless: I'm trying to generate preview diffs without using working trees | 03:19 |
| thumper | lifeless: abentley tried to give me an outline | 03:19 |
| thumper | lifeless: and we're close | 03:19 |
| thumper | lifeless: I've got it so I get the repository populated with the revisions | 03:19 |
| thumper | lifeless: but I need to work out the lca to pass into the 3 trees merger | 03:20 |
| thumper | lifeless: or preview tree thingy | 03:20 |
| thumper | lifeless: I'm at the stage of trying to find the lca | 03:20 |
| lifeless | thumper: and why are you sure the revisions are related? | 03:21 |
| thumper | lifeless: because I branched one from the other | 03:22 |
| thumper | lifeless: one is lp:pqm | 03:22 |
| thumper | lifeless: and the other is one of my pqm branches | 03:22 |
| thumper | lifeless: so I'm pretty sure they are related | 03:22 |
| lifeless | well | 03:22 |
| lifeless | make sure you're using the right key type | 03:22 |
| lifeless | if graph is repository.get_graph(), its a simple string otherwise its a key tuple | 03:23 |
| thumper | rev1, rev2 = repo.get_revisions(['my-revid', 'trunk-reviid']) # not real revids | 03:24 |
| thumper | I used repository.get_graph() | 03:24 |
| thumper | base = graph.find_unique_lca(rev1, rev2) | 03:24 |
| lifeless | secondly, you don't need a shared repo for this sort of thing if you have recent repositories you can just add a temporary fallback repo during the calculation | 03:24 |
| thumper | lifeless: lets just say I have a local copy of all the revisions | 03:25 |
| lifeless | sure, just letting you know :P | 03:25 |
| thumper | so why does the graph not think they are related? | 03:25 |
| spiv | We really should improve the "here's a traceback, please file a bzr bug" message to peek at the traceback to see if a plugin is obviously involved, and if so blame the plugin rather than bzr... | 03:26 |
| jml | lifeless: can you please take a look at https://bugs.launchpad.net/bugs/330823 | 03:26 |
| ubottu | Ubuntu bug 330823 in bzr "Branching from Launchpad (direct via http) fails behind HTTP/DNS proxy" [Undecided,New] | 03:26 |
| abentley | thumper: You rang? | 03:26 |
| lifeless | jml: in what sense | 03:27 |
| thumper | abentley: yes, I'm having mad issues | 03:27 |
| abentley | thumper: lol | 03:27 |
| thumper | abentley: I have my local repo with revisions now | 03:27 |
| thumper | abentley: but the graph doesn't seem to think that the two revs are related | 03:28 |
| lifeless | jml: oh its a more complex report than I knew | 03:28 |
| abentley | thumper: Well, it's possible they're not... | 03:29 |
| thumper | abentley: the branches that they are from are related | 03:29 |
| abentley | How are you creating them? | 03:29 |
| thumper | abentley: pulled from real branches | 03:30 |
| abentley | thumper: Can you run bzr find-merge-base against them? | 03:30 |
| lifeless | thumper: oh | 03:30 |
| lifeless | thumper: don't pass in revision objects | 03:30 |
| lifeless | thumper: pass in revision ids | 03:31 |
| thumper | grr | 03:31 |
| lifeless | nearly everything works in terms of identifiers | 03:31 |
| lifeless | full revision objects are expensive when not needed | 03:31 |
| thumper | the docstring says revision not revision_id | 03:31 |
| thumper | so I assumed revision objects | 03:31 |
| lifeless | fair enough | 03:31 |
| abentley | thumper: Sorry, I'm a bit sloppy with that distinction. | 03:32 |
| thumper | hah | 03:32 |
| thumper | have a base now | 03:32 |
| * thumper attempts to generate a preview diff | 03:33 | |
| kkubasik | hey, anyone know if/when a osx 10.5 installer will be available for 1.12 | 03:33 |
| thumper | abentley: where does the preview tree code live? | 03:33 |
| mwhudson | kkubasik: i saw some swearing in here about bzr-svn on os x, so hopefully soon | 03:34 |
| kkubasik | slash, I'm totally willing to build it if anyone can point me to how the 1.11 package was built | 03:34 |
| abentley | thumper: In transform.py, but you won't use it directly. | 03:34 |
| kkubasik | mwhudson: thanks! | 03:34 |
| thumper | abentley: so given base_id, rev1_id, and rev_2 id | 03:34 |
| thumper | abentley: and a repo | 03:34 |
| thumper | abentley: what do I do to generate the treeless diff? | 03:34 |
| abentley | thumper: Instantiate a Merge3merger | 03:35 |
| thumper | found in? | 03:35 |
| thumper | merge? | 03:35 |
| abentley | thumper: merge.py | 03:35 |
| mwhudson | thumper: have you seen http://pastebin.ubuntu.com/119504/ ? | 03:35 |
| mwhudson | (from my lpreview hackery( | 03:35 |
| jam | kkubasik: there is already one uploaded last I checked | 03:35 |
| abentley | thumper: You'll need to get RevisionTrees for all the revisions first. | 03:36 |
| thumper | abentley: a Merge3Merger wants working trees | 03:36 |
| mwhudson | me has a shiny loggerhead branch he wants everyone to try! | 03:36 |
| jam | ah, only a 10.4 one here: https://edge.launchpad.net/bzr/1.12/1.12 | 03:36 |
| jam | not sure why | 03:36 |
| mwhudson | lp:~mwhudson/loggerhead/unified-by-default-sbs-by-ajax | 03:36 |
| abentley | thumper: Yeah, but you can get away with just revisiontrees. | 03:36 |
| jam | or if it matters | 03:36 |
| thumper | abentley: RevisionTrees are created how? | 03:37 |
| thumper | mwhudson: I have no real trees | 03:37 |
| abentley | thumper: Repository.revision_tree | 03:37 |
| jam | thumper: repository.revision_trees([revision_id1, revision_id2]) | 03:37 |
| mwhudson | thumper: neither does that code | 03:37 |
| kkubasik | jam:at https://launchpad.net/bzr/+download ? | 03:38 |
| mwhudson | branch.basis_tree() == branch.repository.revision_tree(branch.last_revision()) | 03:38 |
| kkubasik | I can't find one.... | 03:38 |
| abentley | thumper: Make sure you pass in do_merge=False. | 03:39 |
| thumper | mwhudson: I don't have a branch | 03:39 |
| mwhudson | thumper: but you have a repository and a revision tree | 03:39 |
| jam | kkubasik: On the page you linked, I see: Bazaar-1.12-OSX10.4-universal.dmg | 03:39 |
| mwhudson | thumper: but you have a repository and a revision id | 03:39 |
| mwhudson | (rather) | 03:39 |
| jam | but you're right that I don't see a 10.5 one | 03:39 |
| jml | lifeless: thanks | 03:40 |
| kkubasik | jam: yeah, i need OSX10.5 | 03:40 |
| thumper | hmm | 03:41 |
| thumper | KeyError: 'pop(): dictionary is empty' | 03:41 |
| thumper | line 1694, in _iter_inventory_xmls | 03:41 |
| thumper | chunks = text_chunks.pop(key) | 03:41 |
| thumper | that is attempting repo.revision_trees | 03:41 |
| baxissimo | Why doesn't this work?: bzr svn-import --trees http://svn.dsource.org/projects/multiarray/trunk/multiarray/dflat | 03:42 |
| abentley | thumper: that's odd-- it should just fail if it can't find the right inventories. | 03:42 |
| thumper | :( | 03:44 |
| abentley | thumper: Did you pass revision_ids in as a list? | 03:44 |
| thumper | yes | 03:44 |
| thumper | base_tree, rev1_tree, rev2_tree = repo.revision_trees(base, rev1, rev2) | 03:45 |
| thumper | hang on | 03:45 |
| thumper | wrong line | 03:45 |
| abentley | thumper: That should be repo.revision_trees([base, rev1, rev2]) | 03:45 |
| thumper | base_tree, rev1_tree, rev2_tree = repo.revision_trees([base, rev1, rev2]) | 03:45 |
| thumper | I tried the first after the second | 03:45 |
| thumper | but it failed with wrong number of args | 03:45 |
| thumper | base, rev1 and rev2 are all revision ids | 03:46 |
| abentley | thumper: Can you put a pdb in _iter_inventory_xmls where it's looping through records? | 03:47 |
| * thumper wonders which bzrlib he's using | 03:47 | |
| thumper | abentley: I'm in the interactive interpreter right now | 03:48 |
| thumper | so I should just be able to invoke pdb | 03:48 |
| thumper | and set a break point right? | 03:48 |
| abentley | thumper: Could be. I always do it the hard way :-) | 03:48 |
| thumper | ok | 03:49 |
| thumper | abentley: do you want to skype? | 03:49 |
| abentley | thumper: sure. | 03:50 |
| spiv | baxissimo: file a bug on bzr-svn | 04:12 |
| baxissimo | spiv: is making a repo with init-repo first a requirement? | 04:13 |
| spiv | baxissimo: not | 04:13 |
| spiv | "no", rather | 04:13 |
| baxissimo | spiv: Ok. I'll file a bug. | 04:14 |
| spiv | baxissimo: cool. jelmer's pretty good at fixing them :) | 04:14 |
| jblount | Can someone tell me why I get this response from launchpad-login ? http://dpaste.com/121983/ | 04:18 |
| spiv | jblount: hmm, because of a bug with progress bars | 04:19 |
| lifeless | its not being ifnished() | 04:20 |
| baxissimo | spiv: submitted https://bugs.launchpad.net/bzr/+bug/330832 | 04:20 |
| ubottu | Ubuntu bug 330832 in bzr "svn-import doesn't import anything" [Undecided,New] | 04:20 |
| spiv | jblount: I don't think that bug has been reported yet | 04:21 |
| * jblount heads off to LP | 04:21 | |
| lifeless | or possibly its reporting when there isn't a progress bar? | 04:21 |
| jblount | lifeless: I could take a video if you like, but it does go into "progress bar mode" briefly and then report the paste. | 04:21 |
| jblount | fwif http://etc.joshuablount.com/bzr-launchpad-login-weirdness.ogv | 04:26 |
| lifeless | jblount: heh | 04:27 |
| lifeless | you have far too much bandwidth | 04:27 |
| Peng_ | Are those progress bar warnings disabled in release builds? | 04:27 |
| lifeless | Peng_: not yet | 04:28 |
| jblount | lifeless: :) | 04:28 |
| Peng_ | ...That's unfortunate. | 04:28 |
| jamesh | perhaps using "script" might produce a more australia-friendly recording | 04:28 |
| jamesh | actually, that is a fairly small ogv | 04:29 |
| jblount | 49KB | 04:29 |
| poolie | jblount: is that perfectly reproducible? | 05:41 |
| poolie | and thanks for the video, i think that's the first time i've seen one used in a bug report | 05:41 |
| baxissimo | If I have branches foo/ and bar/ how can I reorganize that so bar is under foo -- like foo/bar? | 06:15 |
| baxissimo | merge keeps telling me they have no common ancestor. | 06:16 |
| baxissimo | oh... bzr merge -r0..-1 is the magic I'm looking for. | 06:21 |
| baxissimo | Dang, I merged into the wrong place. Is there an undo? | 06:22 |
| poolie | baxissimo: bzr revert | 06:23 |
| poolie | baxissimo: probably you want to just make a checkout of bar under foo | 06:24 |
| baxissimo | foo/ already has foo/baz and foo/bif as part of the same branch though. | 06:25 |
| baxissimo | poolie: bzr revert ... very nice. | 06:25 |
| baxissimo | So ... think about it more actually maybe what I'd rather do is break baz and bif into their own branches. They are all pretty independent. | 06:30 |
| lifeless | baxissimo: there is a merge-into plugin too | 06:37 |
| baxissimo | lifeless: that sounds like what I'm after. But I guess it pretty much just does a merge 0..-1. | 06:39 |
| vila | hi all | 07:01 |
| poolie | hi vila! | 07:03 |
| davidstrauss | Is there an efficient way to unmerge a branch? | 07:04 |
| baxissimo | davidstrauss: bzr revert I think | 07:05 |
| davidstrauss | baxissimo: I mean one that's long committed. | 07:05 |
| poolie | davidstrauss: you can uncommit | 07:07 |
| davidstrauss | The merge is about 20 commits down. | 07:07 |
| baxissimo | Can I somehow change a repo to --no-trees after it's already created? | 07:59 |
| jfroy | baxissimo: right now not through bzr | 08:01 |
| jfroy | however, you can simply touch .bzr/repository/no-working-trees | 08:01 |
| davidstrauss | jfroy: What about http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#remove-tree | 08:02 |
| jfroy | that operates on a branch | 08:02 |
| davidstrauss | Or do you mean shared storage | 08:02 |
| davidstrauss | oh | 08:02 |
| jfroy | I think baxissimo was asking about the --no-trees option for repositories | 08:02 |
| baxissimo | I have a shared repo that I just filled up with a bunch of different branches. | 08:03 |
| davidstrauss | Well "repository" can mean many things in Bazaar. | 08:03 |
| jfroy | No :p | 08:03 |
| jfroy | A repository is what gets made by init-repo :p | 08:03 |
| baxissimo | Now I'm thinking I'd like to convert all those branches to --no-trees style. | 08:03 |
| davidstrauss | jfroy: No. "A branch consists of the state of a project, including all of its history. All branches have a repository associated..." | 08:04 |
| jfroy | baxissimo: touching that file will turn on the no trees option on the repo. | 08:04 |
| davidstrauss | jfroy: And not all branches use shared storage. | 08:04 |
| jfroy | You'll need to remove-tree on any existing branch however | 08:04 |
| baxissimo | jfroy: remove-tree before or after touching the file? | 08:04 |
| jfroy | davidstrauss: don't actually consider that relevant. Branches may have internal storage of their deltas or use external storage e.g. a repository | 08:05 |
| davidstrauss | jfroy: The fact that there's a command "init-repo" doesn't change that all revision storage, branch-local or not, are called "repositories." | 08:05 |
| jfroy | Saying that "branches may contain a repository" just confuses things. | 08:05 |
| jfroy | IMO | 08:05 |
| jfroy | But, I suppose, "shared storage" is more accurate. | 08:05 |
| davidstrauss | jfroy: Well, then the docs need updating, because the quote I pulled was from them. | 08:05 |
| jfroy | I'm aware of that. | 08:05 |
| davidstrauss | "All branches have a repository associated" | 08:05 |
| davidstrauss | http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#remove-tree | 08:05 |
| jfroy | But the confusion about bzr shared repositories is well known... | 08:06 |
| baxissimo | bzr terminology is definitely confusing. | 08:06 |
| jfroy | Which is rather unfortunate. | 08:06 |
| jfroy | baxissimo: it isn't, once you have clearly separate things | 08:06 |
| davidstrauss | And "shared storage" doesn't mean it's a repository in the collaborative "main line" sense, either. | 08:06 |
| jfroy | It's shared by many branches. | 08:07 |
| davidstrauss | I use shared storage on my laptop to avoid pulling revisions twice for my own dev branches | 08:07 |
| jfroy | And yes, again, the terminology isn't as clear as it could be. | 08:07 |
| jfroy | But the concepts are, however. | 08:07 |
| davidstrauss | jfroy: Also: "Repositories in Bazaar are where committed information is stored." | 08:07 |
| davidstrauss | jfroy: That is true of non-shared storage, as well. | 08:07 |
| jfroy | I ind that quote, again, unfortunate. | 08:08 |
| jfroy | *find | 08:08 |
| jfroy | It's unnecessarily confusing. | 08:08 |
| davidstrauss | And: "By default just running 'bzr init' will create a repository" | 08:08 |
| jfroy | Repositories are such an unimportant, technicality of bzr. | 08:08 |
| jfroy | The core concept is that of a branch. | 08:08 |
| davidstrauss | Agreed | 08:08 |
| jfroy | init creates a branch | 08:08 |
| jfroy | repository has clearly defined semantics by virtue of other, past VCS | 08:09 |
| davidstrauss | All I'm doing is quoting the docs | 08:09 |
| jfroy | I know | 08:09 |
| baxissimo | I think it would help if the words were more often coupled with their concrete implementation | 08:09 |
| jfroy | :| | 08:09 |
| baxissimo | Like a repository is generally implemented as a .bzr/repository directory containing the data. | 08:09 |
| davidstrauss | And saying I'm justified for not assuming removing a tree from a repository means from shared storage ;-) | 08:09 |
| baxissimo | That helps demystify the terms I think. | 08:10 |
| davidstrauss | Bazaar should stop using the term repository entirely, I think | 08:10 |
| jfroy | I agree | 08:10 |
| jfroy | well a tree is its own thing | 08:10 |
| davidstrauss | Yes | 08:10 |
| baxissimo | And instead .... "revision store" or something liek that. | 08:10 |
| jfroy | a "bazaar", so to speak | 08:11 |
| baxissimo | What would you call it instead? | 08:11 |
| davidstrauss | jfroy: Just saying that "How do I remove (a) tree(s) from a repository?" is an ambiguous question with current terminology. | 08:11 |
| jfroy | *rimshot* | 08:11 |
| jfroy | It is, unfortunately. | 08:12 |
| davidstrauss | Unless you have a shared mainline. Then it's a cathedral. ;-) | 08:12 |
| baxissimo | :-) | 08:12 |
| luks | I think it's just wrong, repositories can't have working trees :) | 08:12 |
| jfroy | And they don't! | 08:12 |
| jfroy | branches do | 08:12 |
| jfroy | but the repository no-tree option affects branches pushed to the repository | 08:12 |
| jfroy | it's a pragmatic option | 08:12 |
| luks | that's a configuration option | 08:12 |
| jfroy | that lives in a poorly defined semantic space | 08:12 |
| luks | not a tree | 08:12 |
| luks | I personally think the term repository makes perfect sense | 08:13 |
| davidstrauss | I'd rather have Bazaar kill shared storage and merely use a shared revision cache. I don't care about disk space. I care about performance. | 08:13 |
| jfroy | I meant the option is there because it provides a solution for storage of remote branches on a server that don't need working trees. | 08:13 |
| jfroy | No, I think shared storage is great. | 08:14 |
| davidstrauss | And disk space can be saved pretty effectively with stacked branches, anyway | 08:14 |
| jfroy | It's a powerful tool to optimize your branch storage. | 08:14 |
| jfroy | However, I agree there needs to be an automatic *cache* fallback. | 08:14 |
| davidstrauss | Shared storage is inherently flawed because of the impossibility of safe garbage collection. | 08:14 |
| jfroy | The use case of "branch remote branch, branch local branch" needs to be addressed perfectly with 2 branch commands at optimum speed, no matter the user configuration. | 08:15 |
| AfC | jfroy: I think what davidstrauss is trying to say is that if there was a global (per user, whatever) revision store then no one would need to ever think about setting up the structure where a shared repository can work. | 08:15 |
| luks | you have the same problem with stacked branches | 08:15 |
| jfroy | It's a do-or-die use case IMO. | 08:15 |
| AfC | And since most people screw that up the first time, and changing to it later is also a pain in the ass, I tend to support the notion. | 08:15 |
| davidstrauss | AfC: Correct, at least for the sake of performance. | 08:15 |
| luks | unless you store list of branches in the repository, it's impossible to do gc | 08:15 |
| jfroy | That's an interesting point. | 08:15 |
| asabil | I also agree with davidstrauss | 08:16 |
| davidstrauss | But I think that revision store should be a cache, not canonical storage. | 08:16 |
| davidstrauss | I should be able to safely delete or gc it. | 08:16 |
| AfC | davidstrauss: well, if you mean performance as in "not setting things up in such a way that causes you do duplicate network I/O" then sure. | 08:16 |
| AfC | davidstrauss: But otherwise, if anything, such a hypothetical global one shot revision store would slow things down by the mere fact of having [way] more revisions in it that need indexing and searching through than a given individual project would have. | 08:16 |
| luks | ehm, where would it store revisions then? | 08:16 |
| davidstrauss | luks: locally with the branch | 08:17 |
| davidstrauss | luks: the cache would be to save network I/O | 08:17 |
| luks | davidstrauss: what's the point of revision store then? | 08:17 |
| jfroy | shared revision storage saves a ton of time for local branching as well, however | 08:17 |
| davidstrauss | revisions have globally universal IDs, a local cache of the last X MB of revisions I pulled would do wonders for my frequent branching of drupal | 08:18 |
| AfC | davidstrauss: all that said, if you go ahead and `bzr init-repo ~` you'll have your global revision store. | 08:18 |
| luks | davidstrauss: so if you have 5 branches of the same project, instead of having them stored once, you have stored them 6 times? | 08:18 |
| jfroy | disks may be orders of magnitude faster than network, but they're still slow | 08:18 |
| luks | that's insane, IMO | 08:18 |
| davidstrauss | AfC: http://fourkitchens.com/blog/2009/02/09/no-brainer-shared-branch-storage-your-workstation | 08:18 |
| jfroy | local branching within a shared repository is nearly instantaneous, as it should be | 08:18 |
| AfC | davidstrauss: and given that you have enough knowledge to be having this conversation, why on earth have you not just used a shared repository at .. or wherever as the developers of Bazaar want you to do? | 08:18 |
| davidstrauss | luks: The idea that the shared storage accumulates cruft that I can't clean up bothers me. | 08:19 |
| jfroy | it may be worthwhile to have bzr gc | 08:19 |
| davidstrauss | AfC: That's exactly what the guide I linked (that I also wrote) describes | 08:19 |
| davidstrauss | AfC: And I do that | 08:19 |
| AfC | davidstrauss: fine. So what's the problem? | 08:19 |
| luks | davidstrauss: more than duplicating the data all over the disk? | 08:19 |
| asabil | what about some kind of automatic branch stacking ? | 08:19 |
| davidstrauss | AfC: It's clunky | 08:19 |
| davidstrauss | I think branch stacking is the real answer, combined with multi-level caching. | 08:20 |
| asabil | local automatic branch stacking ? | 08:20 |
| jfroy | I'd say that it's additional mental load that users of the other DVCS don't have to deal with | 08:20 |
| luks | I don't like branch stacking at all | 08:20 |
| asabil | suppose that I branch http://foo.bar/baz into ~/mybranches/baz | 08:20 |
| davidstrauss | Branch stacking is bad now because it's not horizon-based. | 08:21 |
| luks | I want to have the full history right there where I'm working | 08:21 |
| davidstrauss | You should have a certain amount of history | 08:21 |
| asabil | and then try to branch again from the same location, it can try to stack it on the branch in ~/mybranches/baz | 08:21 |
| davidstrauss | asabil: Yes, but you're still thinking from the perspective of a user who knows Bazaar internals. | 08:21 |
| asabil | davidstrauss: how so ? | 08:21 |
| davidstrauss | asabil: You know that you can branch locally and stack off that for efficiency. | 08:22 |
| asabil | davidstrauss: no, that can be automatic | 08:22 |
| davidstrauss | asabil: To search for a local branch to stack off of? | 08:22 |
| asabil | the cache can keep a (remote branch => local branch) | 08:22 |
| asabil | and stack based on that information | 08:23 |
| davidstrauss | asabil: That's basically what I mean. | 08:23 |
| asabil | or not even stack, just copy the revisions from the local branch | 08:23 |
| davidstrauss | Now, I'm always thinking from the perspective of Drupal developers. We want to branch cheaply, have a bit of local history, and not have to think too hard about it. | 08:24 |
| asabil | davidstrauss: I see your point | 08:24 |
| davidstrauss | And almost everyone will branch from the master server. | 08:24 |
| davidstrauss | Only advanced users would think to branch locally and re-branch from that or use shared storage. | 08:25 |
| luks | I don't see how running bzr init-repo _once_ is a problem | 08:25 |
| davidstrauss | Once merged, we typically delete the local branch. | 08:25 |
| davidstrauss | luks: It continues to grow, and you can't gc it. | 08:25 |
| davidstrauss | luks: Nor is there an obvious method for gc'ing it that we could implement. | 08:26 |
| luks | davidstrauss: I uncommit or develop dead-end branches very rarely | 08:26 |
| luks | so I don't find that a problem | 08:26 |
| asabil | luks: the current approach used by bzr, is to *just work* by sacrificing the performance | 08:27 |
| asabil | the proposed approach is the *just work* by sacrificing the disk space usage | 08:27 |
| jfroy | well, you could do a breath-first traversal of the fs starting at the root of the shared repository, build a set of live branches, then delete any changeset no longer required by the set of branches you found. | 08:27 |
| jfroy | But that may be a time consuming process. | 08:27 |
| davidstrauss | jfroy: And incorrect. | 08:27 |
| davidstrauss | jfroy: You can move a branch using shared storage to a non-child location from the shared storage. | 08:28 |
| luks | asabil: using any tool without reading at least it's basic documenation is wrong, IMO | 08:28 |
| jfroy | you would destroy that branch | 08:28 |
| davidstrauss | jfroy: Yes, and that's unacceptable for safe gc. | 08:28 |
| jfroy | you need to push it outside the scope of the shared repository, at which point it has a complete history | 08:28 |
| luks | asabil: if the user can't find out that running bzr init-repo is an important step, there is a bug in the documentation | 08:28 |
| davidstrauss | When you have a community as large as Drupal's, we can depend on most users not reading the docs. | 08:29 |
| luks | davidstrauss: ehm, you can? | 08:29 |
| jfroy | which means any branch not under the root of the shared repository can effectively be considered "no stored in this repository", which would let you find dead-ends in the histories, e.g. deleted branches, | 08:29 |
| luks | davidstrauss: if you move the branch, it will be broken | 08:29 |
| asabil | luks: I'd say it is a bug in the human behavior :p | 08:29 |
| jfroy | luks: I disagree there | 08:30 |
| jfroy | the *less* mental load you *force* on your user, the better | 08:30 |
| davidstrauss | luks: Don't branches using shared storage refer to their shared storage with an absolute path? | 08:30 |
| jfroy | bzr is worse than hg and git in that respect, period. | 08:30 |
| asabil | luks: do you read the documentation of the appliances you buy ? | 08:30 |
| luks | davidstrauss: no | 08:30 |
| luks | davidstrauss: they just traverse directorties until they find a repository | 08:30 |
| davidstrauss | luks: when you create them | 08:30 |
| davidstrauss | luks: but what if you move them later? | 08:30 |
| luks | davidstrauss: outside of the repository, using mv? you have a problem | 08:31 |
| jfroy | they break if you move them above the shared repo | 08:31 |
| jfroy | IIRC anywhere under the shared repo is fine | 08:31 |
| luks | asabil: yes, I do | 08:31 |
| asabil | :) | 08:31 |
| luks | not all of it | 08:31 |
| luks | but the "how to start" parts | 08:31 |
| jfroy | luks: you are far more diligent than most people then :p | 08:31 |
| luks | well, it takes longer to figure it out myself than to read it | 08:32 |
| jfroy | I'd also like to remind one of the strongest argument of bzr over its competition is ease of use (particular w/r to git) | 08:32 |
| luks | bzr by default works just fine | 08:32 |
| jfroy | The need to know about, understand and setup share repositories, even once, takes away from that. | 08:32 |
| davidstrauss | Interesting. They do fail if you move them, despite claiming to refer to the shared storage using an abs. path on creation. | 08:33 |
| luks | if it's too slow, it's because the usert didn't read the docs | 08:33 |
| jfroy | luks: but unacceptably slowly | 08:33 |
| jfroy | that answer is arrogant, to some extent | 08:33 |
| luks | jfroy: at that point the user will be forced to read the docuemntation | 08:33 |
| luks | you can't use svn/hg/git/csv without setting up a repository | 08:33 |
| luks | you *can* do that with bzr | 08:34 |
| davidstrauss | luks: You can git init in place. | 08:34 |
| davidstrauss | luks: The difference is that git inherently uses shared branch storage because of its branching model. | 08:34 |
| luks | davidstrauss: that sets up a shared repository as well | 08:34 |
| thumper | jfroy: the core devs are looking into making the first impressions better | 08:34 |
| jfroy | thumper: I'm certain they are | 08:34 |
| thumper | jfroy: which does include better stories around shared repos and inital working | 08:34 |
| davidstrauss | luks: There's no such thing as non-shared git branch storage AFAIK | 08:34 |
| luks | davidstrauss: right, neither there is for subversion, for example | 08:35 |
| davidstrauss | correct | 08:35 |
| jfroy | thumper: I don't care what the solution is. I care about the use case. "Branch from a remote branch, then branch locally is way slower under Bazaar if you don't care / know about shared repositories." | 08:35 |
| jfroy | That use case should be as simply as "bzr branch http://... foo; bzr branch foo bar" | 08:36 |
| jfroy | Nothing less. | 08:36 |
| jfroy | *Nothing more. | 08:36 |
| davidstrauss | A cache would solve that. | 08:36 |
| jfroy | *as simple | 08:36 |
| jfroy | davidstrauss: or implicitly initializing a shared repository in the parent when checking out a remote branch | 08:37 |
| thumper | jfroy: I understand | 08:37 |
| davidstrauss | Especially if the answer I'm getting for the flaws in shared storage is that disk space doesn't matter if it makes life easier. | 08:37 |
| luks | jfroy: in the parent directory? | 08:37 |
| jfroy | I think there is a place for discussion on the how, but now the need to do something. | 08:37 |
| luks | oh | 08:37 |
| asabil | davidstrauss: the best would be to write a plugin that does what you want | 08:37 |
| jfroy | I dislike plug-ins. | 08:37 |
| asabil | and hopefully it will become part of the core | 08:37 |
| davidstrauss | This ought to be in core. | 08:37 |
| jfroy | It's yet more stuff to worry about to get going. | 08:37 |
| thumper | jfroy: well, bzr loves them :-| | 08:37 |
| davidstrauss | Some things should be plugins. | 08:37 |
| jfroy | plug-ins are fantastic to expand on the program and integrate bzr | 08:38 |
| asabil | davidstrauss: yes, but it would be a very good proof of concept | 08:38 |
| thumper | I agree that the core story needs to be better | 08:38 |
| jfroy | But there's so much good stuff in them that you basically need bzr distros at this point. | 08:38 |
| thumper | as do almost all the core devs | 08:38 |
| davidstrauss | The fundamental code to pull revisions quickly should not be a plugin. | 08:38 |
| thumper | if you have a really strong opinion, let kfogel know | 08:38 |
| asabil | davidstrauss: I agree ! but you have to start somewhere | 08:38 |
| thumper | hi emmajane | 08:38 |
| luks | I think having this would come at the price of making bzr less flexible | 08:39 |
| asabil | davidstrauss: discussions don't lead to anything | 08:39 |
| emmajane | thumper, morning :) | 08:39 |
| davidstrauss | asabil: Understood. We have a similar philosophy in Drupal. Try it out in contrib, and we might migrate it to core. | 08:39 |
| asabil | davidstrauss: then apply that philosophy to bzr :p | 08:39 |
| davidstrauss | luks: How would a ~/.bzrcache or something cost flexibility? | 08:39 |
| jfroy | luks: I'm not certain about that. bzr could establish a heuristic for branch history storage that maintains its flexibility. | 08:39 |
| asabil | davidstrauss: bzr-svn already uses a cache, you can take a look at it | 08:40 |
| luks | davidstrauss: it forces you to certain workflows | 08:40 |
| davidstrauss | luks: I'm not suggesting removing shared storage, at least right now. | 08:40 |
| luks | the cache would take a lot of space, and it wouldn't be possible to have it on every machine | 08:40 |
| davidstrauss | luks: The cache would be used when you're not using shared storage. | 08:40 |
| luks | there are e.g. deployment machines, where you would explictly not want it | 08:40 |
| davidstrauss | luks: And there could be an option to not use one, possibly on the user level. | 08:41 |
| asabil | wait wait | 08:41 |
| asabil | davidstrauss: are you talking about a revision cache ? | 08:41 |
| luks | well, this seems just wrong to me | 08:41 |
| jfroy | I agree with david on those principles. | 08:41 |
| jfroy | it is, after all, only an extension of the current mechanism. | 08:41 |
| davidstrauss | asabil: Yes, one bzr can check before pulling from a remote server. | 08:41 |
| jfroy | Where bzr will search for shared storage, and if that search fail store history in the branch itself. | 08:41 |
| asabil | davidstrauss: I would rather create a remote -> local uri mapping cache | 08:41 |
| davidstrauss | asabil: So, the result of not using shared storage would be wasted disk but not much lost performance. | 08:41 |
| jfroy | A cache would only introduce an additional step in that process. | 08:42 |
| jfroy | *with the caveat that by definition a cache can be deleted safely at any time* | 08:42 |
| davidstrauss | jfroy: Which is very good. | 08:42 |
| jfroy | And that, I think, is the biggest problem of a per-user cache. | 08:42 |
| jfroy | No, it's a very difficult design problem w/r to bzr. | 08:42 |
| asabil | davidstrauss: that way you don't need to store the revisions in the cache | 08:42 |
| luks | jfroy: I can already see users downloading hundrets of bzr data, just to see how the code looks like, then deleting it | 08:42 |
| jfroy | it essentially means history duplication and atomicity nightmares. | 08:42 |
| luks | jfroy: what will happen with the cache? | 08:43 |
| davidstrauss | jfroy: How could you have atomicity nightmares? Revisions are keyed with globally unique IDs. | 08:43 |
| luks | er, +megabytes | 08:43 |
| davidstrauss | jfroy: It's a cache designers dream. | 08:43 |
| jfroy | Implicitly, if the cache can be deleted, you need to store revisions elsewhere as well, don't you? | 08:43 |
| davidstrauss | designer's* | 08:43 |
| jfroy | Hence, 2 FS operations. | 08:43 |
| davidstrauss | jfroy: Yes, but the cost of the FS operations is trivial compared to Internet I/O. | 08:44 |
| jfroy | granted, if the operation on the cache fails, then the cache will simply be missing data, which by design is not an issue | 08:44 |
| jfroy | I disagree to some extent with that. | 08:44 |
| jfroy | Disk operations are costly in time and energy. | 08:44 |
| luks | davidstrauss: this going in circles, if the FS operation is cheap, why not use standalone repositories? | 08:44 |
| jfroy | Less so than network, but they are. | 08:44 |
| davidstrauss | luks: Because you end up downloading all revisions over and over again. | 08:45 |
| lifeless | also, note that we're looking at shrinking the size of repos by nearly an order of magnitude | 08:45 |
| luks | davidstrauss: no, you end up copying the data from your disk | 08:45 |
| davidstrauss | luks: Are we talking with or without caching? | 08:45 |
| lifeless | I've been down the cache route before with 'arch', and I think its a sign of a different problem if you need one | 08:45 |
| jfroy | For example, if I'm using a laptop on battery to do some hacking on the move, I would want all software on my computer to do as little IO of any kind as possible. | 08:45 |
| luks | davidstrauss: assuming this is about "bzr branch http://.. foo; bzr branch foo bar" | 08:45 |
| luks | davidstrauss: without | 08:45 |
| jfroy | So I'm certainly not ready to call disk IO "cheap". | 08:45 |
| davidstrauss | luks: No, it's about repeatedly branching from a remote URL. | 08:46 |
| davidstrauss | luks: Which is the common case for large projects with many contributors. | 08:46 |
| lifeless | davidstrauss: is it because shared repos are too hard to setup? / not default? | 08:46 |
| jfroy | davidstrauss: mmm this suggests 2 problems, possibly | 08:46 |
| lifeless | davidstrauss: if so thats under discussion at the moment anyway | 08:46 |
| jfroy | perhaps we could have a remote branch cache | 08:46 |
| luks | davidstrauss: well, you lost me there. I think think that case needs special handling at all | 08:47 |
| jfroy | used only on protocols that are known to be "remote" | 08:47 |
| luks | if the developer is branching from the URL multiple times, they should know about shared repositores | 08:47 |
| jfroy | then we can worry about fast local branching as a separate concern, to be addressed perhaps in tandem with this remote branch cache. | 08:47 |
| davidstrauss | lifeless: I'm trying to think about what would happen if Drupal moved to bzr. | 08:47 |
| davidstrauss | lifeless: The common case for developers would be to branch from a remote URL. We cannot expect most users to create shared storage. | 08:48 |
| davidstrauss | lifeless: How can we make that fast? | 08:48 |
| luks | davidstrauss: branching from CSV requires you to re-download the data as well, is it that different? | 08:48 |
| luks | CVS | 08:48 |
| davidstrauss | luks: CVS checkouts are lightweight. | 08:48 |
| davidstrauss | luks: And you can do lightweight checkouts with bzr, but that defeats the point of DVCS. | 08:49 |
| lifeless | davidstrauss: well, the first thing that can make it fast is to download less; branch --stacked [currently slow due to a bug in the memory/IO tradeoff algorithm, in line for a fix in the next couple of weeks I suspect] | 08:49 |
| lifeless | will download only enough to reconstruct the tree locally; thats about the same as a cvs / svn initial checkout | 08:50 |
| davidstrauss | lifeless: True, but is there a way to branch --stacked and download a little history (but not nearly all)? | 08:50 |
| lifeless | davidstrauss: yes, --stacked could [should in fact for the branch case] do that | 08:50 |
| davidstrauss | One of the boons of DVCS is being able to work effectively offline. | 08:50 |
| lifeless | note that --stacked doesn't work offline | 08:50 |
| davidstrauss | lifeless: indeed | 08:50 |
| davidstrauss | If would be great to have the horizon stuff implemented | 08:51 |
| lifeless | secondly, as I note, we have a new repo format which in some trials is 1/7th the size of current repositories | 08:51 |
| davidstrauss | wow, congrats :-) | 08:51 |
| jfroy | lifeless: is that the new compression stuff I've seen people talk about? | 08:51 |
| lifeless | and performs equivalently for log/commit/annotate | 08:51 |
| davidstrauss | stacking with horizons could plausibly work offline for recent history | 08:51 |
| lifeless | jfroy: yes, the groupcompress plugin [*not* ready for end users] | 08:52 |
| jfroy | I believe in eating your own dogfood :p | 08:52 |
| lifeless | davidstrauss: indeed, but I'd rather talk about things that are nearly-complete rather than 'talked about but noone working on' | 08:52 |
| davidstrauss | Something just bugs me about the idea of offline-usable branches continuously growing larger, no matter how well we compress the data. | 08:52 |
| jfroy | It's incredibly painful (distasteful, you could say), but it's a great motivation to file bugs / fix bugs. | 08:52 |
| lifeless | jfroy: oh sure, but groupcompress is being revised - its like working on zlib, you dogfood but you don't keep your tars in it, until you freeze the format :) | 08:53 |
| jfroy | lifeless: oh we do that all the time, and it leads to pain :p | 08:53 |
| lifeless | davidstrauss: I think its reasonable for repeat contributors to run some command to get a local working area | 08:54 |
| davidstrauss | fair enough | 08:54 |
| lifeless | davidstrauss: now, I definitely think we need a better, default, story in core | 08:54 |
| jfroy | I vote for bzr getem'branch http://... | 08:55 |
| davidstrauss | lifeless: What exactly do you mean by "story"? | 08:55 |
| lifeless | but its easy enough to have a plugin that makes a local shared repo and does a branch into it | 08:55 |
| jfroy | davidstrauss: use case, I believe | 08:55 |
| lifeless | davidstrauss: user story, top level 'this is how it works' | 08:55 |
| davidstrauss | ah | 08:55 |
| lifeless | one path through a use case, if you like | 08:55 |
| davidstrauss | lifeless: I've been drafting some on my blog from a Drupal perspective. | 08:55 |
| lifeless | [no conditionals] | 08:56 |
| jfroy | indeed, a plugin could even replace "branch" and add logic to it to always enforce a shared repository, for example. | 08:56 |
| lifeless | davidstrauss: e.g. bzr drupal-setup c:\src\drupal 6 | 08:56 |
| davidstrauss | I don't think we can expect our normal contributors to install plugins. | 08:57 |
| jfroy | lifeless: incidentally, I've been convincing myself that bzr needs a command to install plug-in as well as a plug-in index | 08:58 |
| davidstrauss | btw, I was elected today to the Drupal Association, and I'm discussion VCS tools with the rest of the infrastructure team now. | 08:58 |
| jfroy | (or plug-in index mechanism, which would allow for internal plug-ins) | 08:58 |
| davidstrauss | discussing* | 08:58 |
| lifeless | jfroy: yes, there is a hook in bzr to discover plugins when a user runs a missing command, and this could install. We've put that there with the intent that people can do this | 08:58 |
| jfroy | I had no idea that was in place. | 08:59 |
| davidstrauss | I think it should download random code from the web and run it with no verification. | 08:59 |
| jfroy | But, a "bzr install-plugin foo" would be great | 08:59 |
| davidstrauss | But only on the Windows client. | 08:59 |
| lifeless | jfroy: see doc/developers/plugin-api.txt for the declaritive data that lets my plugin-info plugin tell you the metadata | 08:59 |
| lifeless | jfroy: most of the bits are there just needs a little glue | 08:59 |
| jfroy | innnnnteresting | 08:59 |
| lifeless | jfroy: the reason its a hook and not a run-random-code is because on e.g. Ubuntu you should really call into apt to install a plugin, because thats validated, signed code etc | 09:00 |
| lifeless | rather than random bits off the net | 09:00 |
| jfroy | ah yes, that's quite true | 09:00 |
| lifeless | davidstrauss: http://drupal.org/node/147789 talks about a bunch of tools to setup | 09:00 |
| jfroy | it is unfortunately useless to Mac OS X and Windows developers | 09:00 |
| AfC | I've got to admit that I just (socially-) engineered around this whole issue by making it *very* clear to people wanting to checkout our project that they have to go through the steps to create a shared repository. Having done that, they never duplicate the network traffic again. | 09:00 |
| jfroy | AfC: yes, that works quite well, having experience with it | 09:01 |
| jfroy | I wrote steps to start using bzr with my project at Apple | 09:01 |
| AfC | It's a bit of a pain to force that at the beginning, but it's now down to "Follow those instructions, and things will work great". "Yeah, but I did...". "No. Delete that, and try again. Follow these instructions..." | 09:01 |
| lifeless | davidstrauss: I don't see that downloading a tiny .exe and running it on windows would be hard; you expect your contributors to know SQL and a long list of other tools | 09:01 |
| jfroy | Which includes each and every command to run, copy-pastable to a terminal | 09:01 |
| jfroy | it really is about the only reliable solution to get everyone a sane working environment | 09:01 |
| lifeless | davidstrauss: but! like I say, I think bzr's core does need to improve | 09:01 |
| davidstrauss | lifeless: I have a hard enough time betting devs to download Bazaar itself: http://fourkitchens.com/blog/2009/02/17/developer-preview-materialized-views | 09:02 |
| lifeless | OTOH does tortoise-bzr give an easy clicky clicky to do stuff? | 09:02 |
| AfC | Part of what makes it "hard" is that they are following instructions that seem really arcane. But since it's so entirely worth it, I've done my best to front load the issue. | 09:02 |
| davidstrauss | "Oh, and for those of us who don't have bzr, how do we get this magical code? :-)" | 09:02 |
| davidstrauss | "And a tarball would indeed be much appreciated :)" | 09:02 |
| lifeless | davidstrauss: do you have a loggerhead instance? (or are your branches registered with launchpad?) | 09:02 |
| davidstrauss | These are serious core devs from Drupal. | 09:02 |
| davidstrauss | lifeless: http://vcs.fourkitchens.com/ | 09:02 |
| davidstrauss | lifeless: We host everything | 09:03 |
| jfroy | urg, loggerhead | 09:03 |
| jfroy | *the pain* | 09:03 |
| jfroy | it's dandy for your own branch on your own machine with a local apache | 09:03 |
| davidstrauss | It would be great if loggerhead allowed tarball downloads (via bzr export) from branches. | 09:03 |
| jfroy | it doesn't work on a central sharing server with 1000s of users | 09:03 |
| jfroy | that well | 09:03 |
| jfroy | (each with their own set of branches) | 09:04 |
| lifeless | davidstrauss: its meant to | 09:04 |
| beuno | davidstrauss, that's a branch for LH which does that. Still needs some cleanups, but it's landing is immanent | 09:04 |
| gioele | hello | 09:04 |
| lifeless | I patched bzr's core to support that | 09:04 |
| lifeless | beuno: JFDI | 09:04 |
| lifeless | beuno: otherwise your core cleanups will make that branch bitrot, not good. | 09:04 |
| davidstrauss | beuno: what's that branch? | 09:04 |
| beuno | lifeless, it needs an option to disable it, or many users will hunt me down and kill me | 09:05 |
| lifeless | beuno: why? | 09:05 |
| beuno | lifeless, server resources? | 09:05 |
| lifeless | beuno: and we know them all, can't be that hard) | 09:05 |
| davidstrauss | it ought to cache the exports | 09:05 |
| lifeless | beuno: compared to the cost of running loggerhead in the first place, I don't think anyone will notice | 09:05 |
| beuno | davidstrauss, https://code.edge.launchpad.net/~danigm/loggerhead/loggerhead/+merge/3266 | 09:05 |
| gioele | BzrFastExport keeps saying to me: "Fixing recursive rename for ./dir/foo.bar". | 09:06 |
| gioele | Is there a way to fix these recursive renames once for all? | 09:06 |
| beuno | lifeless, exporting mysql-server qoul problably not be the best thing in the world for LPs sedrvers | 09:07 |
| lifeless | beuno: didn't we add this like june last year? | 09:07 |
| lifeless | beuno: it should be totally fine, for folk that are hosting branches of mysql-server | 09:07 |
| beuno | we did, I never got to it :( | 09:07 |
| beuno | so someone in the community did | 09:07 |
| lifeless | beuno: don't let the perfect be the enemy of the good | 09:07 |
| poolie | hi beuno | 09:08 |
| lifeless | beuno: I'd be more worried about robots following the links | 09:08 |
| beuno | ok, let's make a deal. I'll tweak that branch and land it with the config option before Sunday :) | 09:08 |
| davidstrauss | I have a real problem with getting deeply involved with all open source tools I use. :-/ | 09:08 |
| beuno | hiya poolie | 09:08 |
| davidstrauss | Bazaar is not proving to be an exception. | 09:08 |
| davidstrauss | :-P | 09:08 |
| lifeless | beuno: than about having an option to turn it off completely. | 09:08 |
| lifeless | davidstrauss: I love users like you :) | 09:08 |
| davidstrauss | I'd contribute more, but I barely know Python | 09:09 |
| beuno | lifeless, we already have a way to specify a robots.txt, so that's a little bit less of a problem | 09:09 |
| lifeless | beuno: in which case, what user has asked to have this unmerged feature configurable ? | 09:09 |
| beuno | lifeless, the reviewer of that branch, rockstar | 09:09 |
| beuno | and myself :) | 09:09 |
| davidstrauss | It sounds like a nice "poor man's" release builder | 09:10 |
| beuno | we have enough performance issues at it is, so if we're going to add this, I'd like to make it optional | 09:10 |
| beuno | on by default | 09:10 |
| beuno | but optional | 09:10 |
| lifeless | beuno: well he says its a concern | 09:10 |
| beuno | not very hard, just need to plug in a config option to bazaar.conf | 09:10 |
| beuno | lifeless, he's also across the table from me, and it's a blockable concern | 09:11 |
| beuno | etierh way, I'll make that fix myself by sunday, or erge as is | 09:11 |
| beuno | sound good? | 09:11 |
| lifeless | beuno: I'm happy with that, in this specific case. | 09:11 |
| beuno | *either | 09:11 |
| beuno | good, I'll take it | 09:12 |
| lifeless | but I really would like to point out that folk hosting big branches have big resources ;) | 09:12 |
| lifeless | and they are more likely to want the feature (capability >> no capability) than not | 09:12 |
| beuno | I know at leasy one big hosting facility that doesn't fall in line with that ;) | 09:13 |
| davidstrauss | Speaking as a Drupal.org infrastructure guy, I think we should be able to turn it off. | 09:13 |
| lifeless | in terms of performance, actually measuring it should show its pretty fast FWIW. Its actually basically what bzr downloads trigger | 09:13 |
| lifeless | davidstrauss: ok, well thats fair enough then :) I was just objecting against strawmen objections. | 09:14 |
| lifeless | <- unwell today, so extra ornery | 09:14 |
| davidstrauss | lifeless: Understood, but big projects create their own tarballs for users to download. | 09:14 |
| davidstrauss | lifeless: And we do things like synching them to CDNs. | 09:15 |
| lifeless | davidstrauss: sure. As far as caching exported tarballs from loggerhead; I think that would be a useful (configurable by giving it a place to put em) feature | 09:15 |
| beuno | yeah, just cache them with the revid as their name (but serve them with a saner name) | 09:17 |
| davidstrauss | I'm less concerned about caching if you can just turn it off. | 09:17 |
| lifeless | I will note that by default bzr should simply be fast enough to do it on the fly | 09:17 |
| davidstrauss | lifeless: Even gzipping the data would be a horrible server load for a project like MySQL. | 09:19 |
| Lo-lan-do | How about uncompressed tarballs then? | 09:20 |
| lifeless | gzip is pretty cheap, as long as you don't use pythons GZipFile | 09:21 |
| lifeless | which sets -9 :P | 09:21 |
| jelmer | bandwidth can also be a problem | 09:21 |
| jelmer | that's one of the reasons we've got this option turned off on git.samba.org | 09:22 |
| lifeless | jelmer: people downloading tarballs they don't need? | 09:22 |
| lifeless | jelmer: or robots? | 09:22 |
| jelmer | lifeless: robots, and people downloading tarballs from cronjobs | 09:22 |
| Mez | are bzr up and bzr update meant to do different things? cause they just did | 09:22 |
| jelmer | lifeless: maybe caused by the fact they don't know how to do keep a checkout with git, but still :-P | 09:23 |
| lifeless | Mez: due to an unfortunate thinko, 'bzr up' is an alias for 'bzr up-thread' | 09:23 |
| lifeless | Mez: it will be getting fixed | 09:23 |
| lifeless | jelmer: yes well, don't get me started on *that* topic :) | 09:23 |
| Mez | lifeless... that's internal? because it seems neither bzr up or bzr update will restore a working copy | 09:24 |
| lifeless | Mez: what do you mean 'restore a working copy' | 09:24 |
| davidstrauss | Mez: You restore working copies with revert. | 09:24 |
| davidstrauss | Mez: If you mean like "svn up" does | 09:24 |
| Mez | lifeliess | 09:24 |
| davidstrauss | Mez: Just be careful | 09:24 |
| Mez | lifeless: no, the .bzr folder is there, but there is no working tree... we need the files from the tree | 09:25 |
| davidstrauss | Mez: That's bzr checkout | 09:25 |
| davidstrauss | Mez: or you can export the branch to elsewhere | 09:25 |
| Mez | davidstrauss: bzr revert seems to work | 09:25 |
| lifeless | Mez: 'bzr checkout .' is likely what you want. Note that if you the .bzr dir is on a remote server, you may be better of looking at either loggerhead (web history viewer) or 'bzr-upload' | 09:26 |
| * Mez shrugs | 09:26 | |
| lifeless | poolie: I was unwell all day today | 09:26 |
| Mez | it's from a checkout where people cocked up :D | 09:26 |
| lifeless | poolie: this is advance warning, if I feel == or worse tomorrow, I'll be calling in sick, well not calling in precisely :) | 09:27 |
| davidstrauss | lifeless: Where do you work? | 09:27 |
| lifeless | davidstrauss: @ canonical | 09:27 |
| davidstrauss | lifeless: I mean physically | 09:27 |
| lifeless | Oh, like most canonical folk, from home. I live in Sydney | 09:27 |
| davidstrauss | ah | 09:27 |
| poolie | lifeless: hope you feel better soon | 09:28 |
| lifeless | poolie: so do I :) | 09:28 |
| AfC | lifeless: I'm not sure I really believe them, but it's supposed to actually be sunny tomorrow. Maybe that'll help. | 09:28 |
| lifeless | AfC: I'm reasonably sure its not drectly weather related, but who knows | 09:29 |
| lifeless | throat closed up, raw-feeling, feverish, snuffly | 09:29 |
| AfC | They even have a name for it where I grew up. "Seasonal Disaffective Disorder" or some such. Also known as "holy cow I need to get the hell away from the bleak misery of winter and go sit on a beach somewhere." | 09:30 |
| Lo-lan-do | Grog! | 09:30 |
| AfC | (so I did :)) | 09:30 |
| lifeless | AfC: :) | 09:30 |
| poolie | Affective | 09:30 |
| poolie | SAD | 09:30 |
| AfC | ah | 09:30 |
| AfC | I knew something didn't sound right there. | 09:30 |
| lifeless | jml: btw, I acked your subunit review with a full reply branch changes etc | 09:30 |
| davidstrauss | lifeless: I'm headed to bed. Hope you feel better tomorrow. :-) | 09:30 |
| lifeless | jml: if you can ack-me-back I'd love that | 09:31 |
| lifeless | davidstrauss: gnight, thanks | 09:31 |
| Lo-lan-do | (Kerosene, propylene glycol, rum, scumm, axle grease, battery acid, pepperoni. Grog. It's good for you.) | 09:31 |
| lifeless | Lo-lan-do: VM? | 09:31 |
| Lo-lan-do | Er, yeah. That was sort of a quote from Monkey Island, a game I mostly play in scummvm :-) | 09:32 |
| lifeless | ok, halt() | 09:37 |
| lifeless | night all | 09:37 |
| ronny | moin | 09:38 |
| beuno | g'night lifeless | 09:39 |
| === jonnydee is now known as Guest63706 | ||
| ronny | yo | 09:57 |
| ronny | is there a way to sign tags in bzr? | 09:57 |
| luks | ronny: no, tags are just simple name -> revision_id map in bzr | 09:58 |
| james_w | would it be reasonable to have a hook so that plugins can set revision properties at commit time? | 10:02 |
| james_w | or is that already possible? | 10:02 |
| gioele | james_w: start_commit can do everything (while pre_commit cannot touch some things). Is that the hook you're looking for? | 10:11 |
| ronny | jelmer: ping? | 10:12 |
| ronny | jelmer: is there any need to keep dulwich compatible to old pythons? | 10:12 |
| Peng_ | ronny: How old is old? | 10:13 |
| james_w | a simple one like commit_message_template would be nice | 10:13 |
| james_w | but pre_commit might work | 10:13 |
| ronny | Peng_: <2.5, preferable <2.6 | 10:14 |
| james_w | nope, it would need a new hook | 10:16 |
| jelmer | ronny: My aim was to be compatible with 2.4 and up | 11:49 |
| jelmer | ronny: Since that means being able to use generators | 11:49 |
| jelmer | ronny: is there anything in particular that breaks 2.4 at the moment? | 11:50 |
| ronny | jelmer: with breaks 2.4 and annotations break 2.5 | 11:50 |
| jelmer | ronny: hmm, where is dulwich using either? | 11:50 |
| jelmer | ronny: I'm running 2.5 at home, so it shouldn't require any 2.6 features yet :-) | 11:51 |
| ronny | jelmer: i started to hack simple tools that compile python code down to c | 11:51 |
| ronny | works best with annotated code cause inference is hell | 11:52 |
| Peng_ | I should do research before asking this, but anyway: Isn't Git libifying itself? Why rewrite it in Python instead of writing bindings for that? | 11:54 |
| jelmer | ronny: no cython/pyrex ? | 11:54 |
| jelmer | Peng_: there is something, but it's not ready for prime time yet | 11:55 |
| ronny | jelmer: it wont be possible to give those sane backends for jython/ironpython | 11:55 |
| ronny | jelmer: and they wont run out of the box | 11:55 |
| jelmer | Peng_: also, the git formats, etc. are pretty simple | 11:55 |
| jelmer | Peng_: and writing them in Python means they'll work on Windows OOTB | 11:55 |
| Peng_ | jelmer: Okay. Thanks for the answer. :) | 11:56 |
| ronny | jelmer: well, annotations help, and annotation decorators would suck as they would add complexity for detection | 11:58 |
| jelmer | ronny: I wouldn't mind depending on annotations at some point, but preferably not before Python2.6 is available somehow in the main linux distro's | 12:00 |
| ronny | ok | 12:02 |
| ronny | gmm | 12:02 |
| ronny | kinda sad it doesnt go into the next ubuntu | 12:03 |
| ronny | i think fedora already has it | 12:03 |
| jelmer | Debian unstable/testing will have it soon as well | 12:04 |
| jelmer | I wasn't aware yet it wasn't going into Jaunty :-/ | 12:04 |
| luks | it does have it, but not as the default | 12:04 |
| luks | or am I reading http://packages.ubuntu.com/jaunty/python2.6 wrong? | 12:04 |
| ronny | jelmer: oh, im not sure, i just asumed cause its not yet there | 12:04 |
| jelmer | luks: ah, that must've been added recently | 12:05 |
| luks | same situation happened when 2.5 was released, 2.4 was the default for a long time | 12:05 |
| ronny | very recent i think | 12:05 |
| luks | 13 Feb 2009, according to the changelog | 12:06 |
| === serg__ is now known as serg | ||
| === sabdfl1 is now known as sabdfl | ||
| igc | night all | 14:00 |
| james_w | night igc | 14:00 |
| vila | igc: night | 14:04 |
| vila | jam: ping | 14:17 |
| jam | morning vi | 14:17 |
| jam | vila: | 14:17 |
| vila | jam: I'm not your editor :) | 14:17 |
| vila | I'm even your reviewer today :) | 14:17 |
| jam | morning vila's emacs | 14:17 |
| jam | anyway, I didn't mean to derail your question. What's up ? | 14:19 |
| vila | jam: 'bzr gblame bzrlib/tree.py 985' and scrollback a little | 14:20 |
| === kiko-afk is now known as kiko | ||
| vila | jam: until the previous elif, choking isn't it ? | 14:21 |
| vila | That's the cause of the bt.test_merge.TestMergerEntriesLCAOnDisk.test_nested_tree_subtree_renamed_and_modified failure in bbc because the indentation has been fixed in bbc | 14:22 |
| vila | And the commit comment for the patch that introduced that test proves that the author had some doubts :) | 14:23 |
| vila | bzr gblame bzrlib/tests/test_merge.py 2636 & | 14:23 |
| vila | AIUI, the wrong indentation predates your test, so I'm not sure about how to fix. Obviously tree.py must be fixed like in bbc, but what about the test ? subtrees semantics are unclear for me and fixing *that* will be time-consuming and again put me off bbc :-/ | 14:25 |
| jam | vila: the "elif from_kind == 'tree_reference'" looks like it should be lined up with the other elifs | 14:25 |
| vila | jam: yes, it's done in bbc | 14:26 |
| vila | jam: that's why the above test fails there and not in trunk | 14:26 |
| vila | jam: at the time you wrote the test I think the bug was there in trunk and you didn't realize it (but given your commit comment, were not satisfied either :) | 14:26 |
| jam | vila: so just change the test to expect "True" | 14:29 |
| jam | ('sub-tree-root', True, ..) | 14:29 |
| vila | hehe, you didn't try to run it don't you :-) | 14:30 |
| vila | it fails in the wt.revert() | 14:31 |
| vila | well it didn't fail, it errors I should have said | 14:32 |
| vila | with: ImmortalPendingDeletion: Unable to delete transform temporary directory /tmp/testbzr-x7bubL.tmp/bzrlib.tests.test_merge.TestMergerEntriesLCAOnDisk.test_nested_tree_subtree_renamed_and_modified/work/tree/.bzr/checkout/pending-deletion. Please examine /tmp/testbzr-x7bubL.tmp/bzrlib.tests.test_merge.TestMergerEntriesLCAOnDisk.test_nested_tree_subtree_renamed_and_modified/work/tree/.bzr/checkout/pending-deletion to see if it contains any | 14:32 |
| vila | files you wish to keep, and delete it when you are done. | 14:32 |
| vila | And from there it's really unclear to decide where the bug is, is is in the test because you used some operation that is guarded somewhere else when tree references are present or are there other bugs that were hidden by the wrong indentation in iter_changes... | 14:34 |
| vila | That's the question I pinged you for :) Well, the first past at least: do you see something wrong in that test ? | 14:35 |
| vila | s/past/part/ | 14:35 |
| vila | Otherwise I think I'll just follow up to Larstiq and abentley | 14:36 |
| Lo-lan-do | Immortal pending deletion? What's that, rm -f /dev/duncan-mcleod? | 14:36 |
| awilkins | That would be UniqueImmortalPendingDeletion (there can be only one!) | 14:37 |
| Lo-lan-do | There *should* be only one, but see what happens when you define your constraints when the database is already populated? | 14:37 |
| jam | Lo-lan-do: the .bzr/checkout/pending-deletion is supposed to be cleaned up | 14:38 |
| jam | if it is still around it "didn't die" | 14:38 |
| jam | which means the previous command failed in some bad way | 14:38 |
| jam | vila: my guess is that other code that handles subtrees is broken | 14:38 |
| jam | vila: and changing False => True, and changing the indentation causes the test to *pass* (on bzr.dev) here | 14:40 |
| jam | So I would say... fix it in bzr.dev, get that submitted | 14:40 |
| jam | and then we'll try to figure out why it breaks in bbc | 14:40 |
| jam | vila: btw, any feedback on my --dev5 patch? | 14:40 |
| jam | I'm willing to just merge it to bbc | 14:41 |
| jam | but it would be nice to have someone look at it first | 14:41 |
| vila | jam: there is another reason for why it fails in bbc, I'm on it | 14:41 |
| vila | jam: czj:approve | 14:41 |
| jam | czj? | 14:41 |
| vila | czj is sexier than bb (younger at least :) | 14:41 |
| jam | vila: anyway, for a fix like this, I'd rather see it happen in bzr.dev, before we do it in brisbane-core | 14:41 |
| jam | anything that can be cleanly split out is something that ends up under constant PQM monitoring :) | 14:43 |
| vila | jam: agreed, that's why I tried to reproduce it in bzr.dev as soon as I realized the root cause (but until now I was parallel pbd stepping and didn't realize it didn't fail in the same way) | 14:43 |
| jam | and less to review when bbc lands | 14:43 |
| vila | jam: understood | 14:43 |
| jam | glad to see you working on bbc test suite, though :) | 14:43 |
| vila | jam: by the way, if you merge from bbc, be aware that we both fix some failing tests in different ways, that should conflict in an obvious way | 14:44 |
| jam | k | 14:44 |
| vila | jam: it appears that my setup is still incomplete, my commits on bbc didn't get posted to bzr-commits (they were trivial enough to be push and I thought you got feedback by the ML hence my lack of "noise" about them) | 14:45 |
| vila | jam: err, it errors out in bzr.dev here >-/ | 14:49 |
| jam | it seems my fix isn't complete yet anyway... | 14:50 |
| jam | I forgot to actually change the inventory serialization, and only changed the chk_map serialization... | 14:50 |
| jam | fixing | 14:50 |
| jam | (I'm glad I double checked that, though for a different reason) | 14:51 |
| * mvo thinks the new progress bar is sweet | 14:51 | |
| jam | mvo: I agree it is quite a bit better than the old one | 14:51 |
| vila | mvo: did you said some days ago or was it someone else ? | 14:52 |
| mvo | I just upgraded my bzr, I see it for the first time (and it seems to be more accurate as well) | 14:52 |
| vila | mvo: far more accurate yes, did you see the IO rate for some operations ? | 14:53 |
| mvo | yes! | 14:53 |
| mvo | I need to do some big commits now so that it actually stays a bit longer :) | 14:53 |
| vila | mvo: it's not complete yet, only some protocols are implemented so far so don't be surprised | 14:53 |
| mvo | thanks vila | 14:54 |
| vila | mvo: that's a team thing, I deserve only a little part :-) | 14:54 |
| * mvo hugs the team and vila | 14:55 | |
| vila | jam: can you confirm you made the test pass with bzr.dev@4017 ? | 14:56 |
| jam | vila: this change: http://paste.ubuntu.com/119711/ | 14:56 |
| jam | applied to bzr.dev 4011 | 14:56 |
| jam | I'll upgrade now | 14:56 |
| vila | wth | 14:57 |
| jam | you know what... I may have run the wrong one | 14:58 |
| jam | (wrong bzr) | 14:58 |
| vila | I sure hope so (kind of :/ | 14:58 |
| jam | yeah, it fails 2x now | 14:58 |
| jam | once in giving the wrong result | 14:58 |
| jam | a second time in giving Immortal... | 14:58 |
| jam | vila: shall I leave it to you? Or do you need me to work on it? | 14:59 |
| vila | jam: I think I'll bring the issue on the ML instead to leave it to the ones working on subtrees | 14:59 |
| vila | They ought to run into it anyway at some point so it should help them | 15:00 |
| jam | vila, just to check, if you run "bzr selftest -s X -s Y" it runs the X tests before the Y ones, right? | 15:02 |
| vila | jam: it doesn't care about the order at all :-) The execution order is.... roughly the loading order | 15:02 |
| vila | if you switch them and use --list you can confirm that | 15:03 |
| vila | and --list will give you the running order too | 15:03 |
| jam | dang | 15:04 |
| jam | oh well, it is probably alphabetical | 15:04 |
| jam | since that is how we list things | 15:04 |
| vila | it can change at each '.' depending on how the module load its tests | 15:05 |
| vila | parametrized tests can also come in vastly different orders | 15:05 |
| jam | sure, but I'm just doing bt.XXX | 15:05 |
| jam | anyway, it doesn't really matter | 15:05 |
| jam | I just have about 500 tests I run for chk branches | 15:05 |
| vila | At that level, yes alphabetical | 15:05 |
| jam | and it is nice to know that if it fails in Y I don't have to run X tests agaig | 15:06 |
| jam | again | 15:06 |
| Tak | what am I doing wrong here? http://paste2.org/p/149615 | 15:11 |
| jam | it looks like you have a Branch objects whose "self.base" is None | 15:12 |
| jam | is it, perhaps, a bzr-svn branch? | 15:12 |
| SiCuTDeUx_ | Hi! | 15:14 |
| SiCuTDeUx_ | how can i install the webdav plugin for bazaar? | 15:14 |
| jam | SiCuTDeUx_: "mkdir -p ~/.bazaar/plugins; cd ~/.bazaar/plugins; bzr co lp:bzr-webdav webdav" | 15:15 |
| SiCuTDeUx_ | that's ala? | 15:18 |
| SiCuTDeUx_ | *all? | 15:18 |
| jam | SiCuTDeUx_: generally | 15:20 |
| jam | I won't absolutely guarantee it, but that is a general way to install plugins | 15:20 |
| jelmer | vila: btw, did I mention I packaged bzr-webdav for Ubuntu? | 15:32 |
| jelmer | jam: bzr-svn should set self.base properly | 15:32 |
| vila | jelmer: wow, no, thanks. Did you do that for debian too or is it ubuntu only ? Do you have public branch for that ? | 15:33 |
| jelmer | vila: it's for Ubuntu only at the moment, but it'll go into Debian as well | 15:34 |
| SiCuTDeUx_ | jelmer, ? | 15:34 |
| jelmer | vila: James reviewed and advocated bzr-webdav last night, so it should end up in Jaunty | 15:34 |
| SiCuTDeUx_ | jelmer, where can i find it? | 15:34 |
| jelmer | vila: there should be a packaging branch here: http://bzr.debian.org/pkg-bazaar/bzr-webdav/ubuntu | 15:35 |
| SiCuTDeUx_ | i use 8.10 | 15:35 |
| vila | James as in james_w ? :-) | 15:35 |
| SiCuTDeUx_ | it is empty jelmer | 15:35 |
| jelmer | SiCuTDeUx_: I'll upload a new package to my PPA | 15:35 |
| jelmer | SiCuTDeUx_: it's a bzr packaging branch | 15:36 |
| SiCuTDeUx_ | jelmer, nice | 15:36 |
| jelmer | vila: there very same | 15:36 |
| vila | jelmer: your ppa contains webdav_1.6.0, there was an update for bzr1.12 and the plugin version is now 1.12 too to reflect that | 15:39 |
| vila | The revno for webdav is 62 | 15:40 |
| jelmer | vila: I haven't uploaded a recent version to PPA yet | 15:40 |
| jelmer | vila: only to REVU, am preparing to re-upload to PPA | 15:40 |
| vila | jelmer: no problem, I was mentioning just in case | 15:40 |
| emmajane | vila, thanks :) | 15:42 |
| vila | emmajane: *I* thank you :) | 15:42 |
| emmajane | vila, I thought it might make sense to link to that document from the plugin page/ | 15:43 |
| emmajane | ? | 15:43 |
| vila | emmajane: oops, forgot that one :) I printed your mail and read it in bed yesterday and then forgot that part :) | 15:44 |
| jelmer | vila: any chance you can tag releases in bzr-webdav? That makes my live as packager a bit easier | 15:45 |
| emmajane | vila, *chuckle* I'm not sure it was quite worthy of bed time reading. | 15:45 |
| jelmer | james_w: is there any harm in me uploading a version of bzr-webdav to REVU that merges a new upstream ? | 15:46 |
| vila | jelmer: there are several things I'd like to discuss about packaging branches, I'll try to mail about it | 15:46 |
| jelmer | james_w: or will I automatically lose the advocation | 15:46 |
| jelmer | james_w: ? | 15:46 |
| james_w | you will, but I can re-review | 15:46 |
| vila | emmajane: hehe, but there, I knew I could read it peacefully :) | 15:46 |
| emmajane | vila, hehe | 15:46 |
| vila | james_w, jelmer : the change is really minor FWIW | 15:47 |
| emmajane | vila, Ultimately I think it would be nice to extend all of the plugins to have a little bit more information; and also for the workflows to have an "in five minutes" tied to each. I'm slowly working my way through the ones that I know. | 15:48 |
| jelmer | james_w: ok, I'll reupload in that case - thanks | 15:49 |
| emmajane | vila, also: I'm talking about the plugin for my Bazaar presentation at SCaLE this weekend. I only talk about it briefly so I wanted to have the documentation available for people who wanted to give it a try. | 15:49 |
| james_w | jelmer: unfortunately I may not be able to re-review in time though, sorry | 15:51 |
| james_w | perhaps you are better seeking advocation on #ubuntu-motu now, and then I will sponsor an upload once it is in | 15:51 |
| jelmer | james_w: ok | 15:52 |
| jelmer | james_w: will do | 15:52 |
| vila | emmajane: http://bazaar-vcs.org/BzrPlugins updated, feel free to change it and good luck for your talk ! | 15:58 |
| emmajane | Thanks!! :) | 15:59 |
| * emmajane heads out. | 16:01 | |
| emmajane | thanks again, vila for looking through the tutorial! | 16:01 |
| Tak | jelmer: I'm trying out yet another md-bzr backend | 16:03 |
| * vila hugs his little daughter cause she needs love just right now and he just got some to share :) | 16:03 | |
| jelmer | Tak: other than bzr-xmloutput? | 16:04 |
| * jelmer hopes the new monodevelop enters sid soon.. | 16:04 | |
| Tak | yeah, I'm using bzrlib via pinvokes into libpython | 16:04 |
| Tak | jam: oh, belated response to your response: no, it's a branch from lp | 16:06 |
| Tak | I can get the push location successfully, but not the submit branch or the parent branch | 16:07 |
| jam | vila: so the reason *not* to use 0xFFFFFFFF is because it casts up to PyLong | 16:09 |
| jam | which are pretty slow | 16:09 |
| jam | and we call the function a lot | 16:09 |
| * vila feels depressed | 16:10 | |
| vila | :-) | 16:10 |
| jam | for now, I'll leave your fix, because I don't feel like worrying about it until we have to | 16:10 |
| jam | but I figured I'd point that out | 16:10 |
| vila | ha good | 16:10 |
| jam | In reality, I think if performance there becomes an issue, we'll just write an extension | 16:11 |
| vila | jam: We'll end up coding that in C at one point anyway | 16:11 |
| jam | because struct.pack is + '\x00'.join is never that good | 16:11 |
| vila | lol, heard the echo on the wire ? | 16:11 |
| jam | I just type faster :) | 16:11 |
| jam | however, it *would* be reasonable to do that for dirstate | 16:13 |
| === jelmer_ is now known as jelmer | ||
| jam | since it is not a performance critical section of code | 16:13 |
| jam | feel free to submit a patch to bzr.dev | 16:13 |
| jam | ): | 16:13 |
| jam | :) | 16:13 |
| jelmer | vila: does it seem reasonable to just have each AbstractAuthHandler provide a variable that says whether it needs a username? | 16:14 |
| jam | vila: inv_as_lines has now landed. --dev5 is now the only new format. | 16:14 |
| jelmer | SiCuTDeUx_: looks like the new version is now available in PPA | 16:15 |
| vila | jelmer: sounds reasonable without seeing the code, if you propose it *hacking* the code, that should be good :) | 16:15 |
| jelmer | SiCuTDeUx_: you'll need bzr 1.12 | 16:16 |
| jelmer | vila: Don't worry, there'll be a patch for you to review soon ;-) | 16:16 |
| vila | jam: ok | 16:16 |
| awilkins | Anyone using Homeplug? | 16:22 |
| emile | We just started our migration from svn to bzr by using svn2bzr.py. Our repo in svn was 22MB, in bzr it is 382MB. Is there some kind of housekeeping I'm supposed to run? I can't imagine bzr needing a 15-fold of the disk space. | 16:33 |
| Odd_Bloke | emile: Try 'bzr pack'. | 16:34 |
| === mvo__ is now known as mvo | ||
| jam | emile: did you have a lot of binary files in your svn repo? (bzr's delta for binaries isn't as efficient as svn's) | 16:40 |
| jam | though 22 => 382 seems a bit extreme, regardless | 16:40 |
| Lo-lan-do | Maybe svn2bzr.py didn't use a shared repo? | 16:40 |
| jam | oh, and bzr-svn is generally preferred to svn2bzr, just as a heads up | 16:41 |
| jam | Lo-lan-do: certainly could be | 16:41 |
| emile | Odd_Bloke: I tried "bzr pack /path/to/repo", no change in size | 16:42 |
| emile | jam: I'll try bzr-svn. There were some bins, but it isn't the bulk of the repo | 16:43 |
| awilkins | emile: How messy is your SVN repo? | 16:43 |
| emile | Lo-lan-do: I don't understand? | 16:43 |
| emile | awilkins: messy in what regard? | 16:43 |
| awilkins | emile: Project layout, esp. history of project layout | 16:44 |
| emile | awilkins: nope, one branch, two tags, and the bulk of the work on trunk. There's just 50 or so revisions in the svn repo. | 16:45 |
| awilkins | emile: Ok, sounds tidy compared to my 14k revisions and 1.5GB of repo | 16:45 |
| awilkins | Most of that is alas, PNGs and DOC files | 16:45 |
| emile | awilkins: Ah, make that 108 revs. Anyhow, shouldn't be significant at these numbers I reckon. We're just starting out this project on vcs. | 16:46 |
| emile | jam: I thought bzr-svn was a like connection of sorts? We're looking to abandon svn. | 16:47 |
| jam | emile: it is still the best converter | 16:48 |
| jam | highest fidelity, etc | 16:48 |
| jam | and the most actively developed, probably also the fastest | 16:48 |
| emile | jam: "highest fidelity" in what regard? Should I be expecting loss? | 16:48 |
| jam | emile: the big issue is with tracking what a branch is, and when they occurred, etc. | 16:49 |
| jam | the actual content probably never differs | 16:49 |
| jam | but the revision ancestry can be difficult to follow | 16:49 |
| jam | again, your repo doesn't sound complex enough to cause problems. | 16:50 |
| jam | I'd still recommend bzr-svn | 16:50 |
| emile | I see. We can actually discard the one branch. Maybe even the tags. | 16:50 |
| jam | emile: I would just try converting again with bzr-svn | 16:51 |
| jam | there are certain ways you can convert which might cause bloat, and I'm not sure how bzr2svn does it | 16:51 |
| jam | If it is hard to get set up, I can try to talk you through alternative setups for bzr2svn, it just doesn't seem specifically worth it | 16:51 |
| * awilkins would also use bzr-svn | 16:52 | |
| emile | It's a one-time task, so I don't really mind. I'm trying to get bzr-svn set up, I don't have root access so I'm going to have to get bzr-svn installed in my home dir | 16:53 |
| awilkins | At least it's *nix, it's a pig to build on Windows | 16:54 |
| awilkins | Although there is allegedly a version in the exe-flavoured installer | 16:54 |
| emile | jam: ok, bzr-svn has run its setup. Something showed up in /var/www/opt. So what next? | 16:57 |
| jam | emile: "bzr svn-import $SOURCE" | 16:59 |
| jam | or at least "bzr help svn-import" | 16:59 |
| emile | it says "No help can be found". I've set my pythonpath, I can import bzrlib. | 17:01 |
| === cody-somerville_ is now known as cody-somerville | ||
| jam | emile: it means you haven't properly installed bzr-svn yet | 17:02 |
| jam | how did you "install" it? | 17:02 |
| emile | $ ./setup.py install --prefix /var/www/opt | 17:03 |
| emile | $ export PYTHONPATH=/var/www/opt/lib/python2.4/site-packages:$PYTHONPATH | 17:03 |
| emile | you're correct, the following fails: from bzrlib.plugins import svn | 17:04 |
| jam | emile: so I think the easier way to install is: | 17:07 |
| jam | cd ~/.bazaar/plugins | 17:07 |
| jam | bzr co "bzr | 17:07 |
| jam | bzr co "bzr-svn" svn | 17:07 |
| jam | cd svn | 17:07 |
| jam | python setup.py build_ext -i | 17:07 |
| jam | Depending on what "bzr-svn" you are grabbing | 17:07 |
| jam | (also, newer versions of bzr-svn also require you to build the "subvertpy" library) | 17:08 |
| emile | the bzr co yields "bzr: ERROR: Not a branch: "/home/hnse/.bazaar/plugins/bzr-svn/"." | 17:09 |
| jelmer | I think John means "bzr co lp:bzr-svn svn" | 17:09 |
| emile | slow, but it's doing something... | 17:10 |
| emile | OK, running build_ext, no errors, but "bzr plugins" doesn't list svn | 17:11 |
| emile | Logged in and out, now I "bzr plugins" says "Unable to load plugin 'svn' from '/home/hnse/.bazaar/plugins'" | 17:12 |
| jelmer | emile: you need the subvertpy python module as well | 17:13 |
| emile | what will be easiest? Grabbing an older bzr-svn version, or installing subvertpy (in a non-standard location) | 17:15 |
| jam | jelmer: can you just build subvertpy in the bzr-svn directory? | 17:15 |
| emile | jam: will check, it's coming in from launchpad now | 17:16 |
| jelmer | emile: installing subvertpy somewhere in PYTHONPATH should be easiest | 17:17 |
| jelmer | jam: atm it's not possible, bzr-svn no longer modifies sys.path | 17:17 |
| emile | drat, it needs apr-config, which is not installed | 17:19 |
| jelmer | emile: yeah, it needs the subversion development libraries as well :-/ | 17:20 |
| jam | jelmer: but doesn't it do "import subvertpy"? | 17:20 |
| jam | which means that if it is in the same dir, it should just find it? | 17:20 |
| jelmer | emile: you can try an older version of bzr-svn, but it will probably mean downgrading your version of bzr | 17:21 |
| jelmer | jam: yeah, but bzr-svn has subpackages | 17:21 |
| emile | jelmer: damn. I have no root access to this machine, so I can't downgrade *or* upgrade. I suppose bzr repos are portable? Could I do the migration elsewhere and put the repo back? | 17:21 |
| jam | emile: yes, you can convert anywhere | 17:22 |
| jam | emile: ok, so basically installing a plugin into your PYTHONPATH doesn't really work, because we don't search PYTHONPATH (though you could add it to BZR_PLUGIN_PATH), installing subvertpy should be on PYTHONPATH | 17:22 |
| jam | emile: if you want, you can have one of us do the conversion | 17:22 |
| jam | though it means exposing the repo to someone | 17:22 |
| emile | jam: appreciate it, but I can't, my manager would freak out | 17:23 |
| emile | Oops, gotta run, thanks guys! I'll check back in later | 17:24 |
| Tak | jam: ok, in the situation above, b.base is a file:// url | 17:27 |
| jam | Tak: that shouldn't really be a problem, then. The issue it is bringing up is that it is trying to work with a path which is None | 17:45 |
| jam | which I don't quite understand | 17:45 |
| jam | hmm... different base | 17:46 |
| jam | just a sec | 17:46 |
| jam | Tak: what platform are you on? | 17:46 |
| Tak | debian x86 | 17:47 |
| jam | We seem to have this trap: | 17:47 |
| jam | if base is None: | 17:47 |
| jam | base = os.path.expanduser("~") | 17:47 |
| jam | What does: python -c "import os; print os.path.expanduser('~')" give you? | 17:47 |
| Tak | my homedir | 17:48 |
| jam | well, one thing to try | 17:48 |
| jam | export BZR_HOME="$HOME" | 17:48 |
| jam | Otherwise I don't really understand why we are getting None there | 17:49 |
| Tak | same thing with BZR_HOME set | 17:53 |
| Tak | it only seems to happen with get_submit_branch and get_public_branch | 17:54 |
| Tak | parent and push location seem to be fine | 17:54 |
| === chx is now known as chx_sleeping | ||
| vila | jam: ping, just fix the same crc32 problem for _search_key_16 (test_search_key_16 fails on 64, succeeds on 32) | 17:58 |
| vila | jam: but I now realize that I broke compatibility for dev5, since you should be the only one affected how big a problem is it ? | 17:59 |
| jam | vila: hmm.. I would have thought the abs() would have been enough there | 17:59 |
| jam | but I guess I understand why not | 17:59 |
| jam | actually, you can take out "abs()" if you switch to using 0xFFFF... | 17:59 |
| vila | jam: I thought abs() was ok too until the test broke and I realized I was wrong | 18:00 |
| vila | jam: that's what I did | 18:00 |
| jam | k | 18:00 |
| jam | no problems here | 18:00 |
| vila | good | 18:00 |
| jam | I recreate them all the time :) | 18:00 |
| vila | ./bzr selftest -s bt.test_chk_map.TestMap.test_map_splits_with_longer_key | 18:00 |
| vila | ERROR: test_chk_map.TestMap.test_map_splits_with_longer_key | 18:00 |
| vila | maximum recursion depth exceeded while getting the str of an object | 18:00 |
| vila | jam: rings a bell ? | 18:01 |
| vila | jam: it's in a map -> _split -> map -> map chain | 18:01 |
| jam | IIRC I added explicit tests for "splitting doesn't cause infinite recursion" | 18:01 |
| jam | so there is certainly a different issue here | 18:01 |
| jam | well, still an issue, obviously | 18:01 |
| jam | but I'd like to understand why | 18:02 |
| jam | vila: "bt.test_chk" passes here | 18:02 |
| vila | jam: Holy cow ! It breaks here on both 32 and 64 8-) | 18:02 |
| jam | well, I haven't updated to the latest bbc | 18:03 |
| vila | It was failing before I fixed the crc32 | 18:04 |
| vila | And bt.test_chk says: FAILED (failures=1, errors=1) | 18:04 |
| vila | File "/net/bigmamac/Volumes/home/vila/src/bzr/experimental/brisbane-core/bzrlib/tests/test_chk_map.py", line 1176, in assertSearchKey16 | 18:04 |
| vila | self.assertEqual(expected, chk_map._search_key_16(key)) | 18:04 |
| vila | AssertionError: not equal: | 18:04 |
| vila | a = '738C9ADF' | 18:04 |
| vila | b = '8C736521' | 18:04 |
| vila | is the other one | 18:04 |
| mneptok | jam: got a moment? | 18:05 |
| vila | mneptok: nope, I pre-empted it :) | 18:05 |
| vila | kidding, no urgency from me :) | 18:05 |
| jam | mneptok: what's up? | 18:05 |
| mneptok | vila: could i convince you to commit a k: line-able offense? >;) | 18:06 |
| mneptok | jam: some "commit --fixes" questions. | 18:06 |
| kfogel | hunh | 18:07 |
| jam | vila: it passes at revno 3821 | 18:07 |
| * vila wonders what 'a k: line-able offense' means... | 18:07 | |
| jam | so something you've done recently broke it | 18:07 |
| mneptok | kfogel: ahoy sailor | 18:07 |
| kfogel | why do we have http://bazaar-vcs.org/Documentation and a separate "official documentation site" http://doc.bazaar-vcs.org/ | 18:07 |
| jam | perhaps either your "assert" patch, or your "search_key_16" one. | 18:07 |
| mneptok | vila: "something that would get you banned from the network" (so i can then steal jam) ;) | 18:07 |
| kfogel | mneptok: doing a draft of a new bzr home page right now, which is leading to lots of questions/cleanups about other pages :-). | 18:07 |
| vila | mneptok: Ohhhh Kkkkk | 18:08 |
| === jelmer_ is now known as Guest94594 | ||
| jam | kfogel: some are wiki documentation, doc.bazaa is built from the source tree | 18:08 |
| jam | plus referencing 3rd-party docs/tutorials, etc. | 18:08 |
| mneptok | vila: hence my wink | 18:08 |
| jam | mneptok: so what are you trying to do with --fixes ? | 18:08 |
| kfogel | jam: hmmmm. okay, so the seams of our automation are showing to the user, sounds like :-). | 18:09 |
| vila | mneptok: I got the wink but not the joke ;-) | 18:09 |
| kfogel | Not necessarily worth cleaning up right now, but worth fixing if we can. | 18:09 |
| jam | kfogel: I don't think all documentation should be bundled into the bzr source tree... do you? | 18:09 |
| kfogel | jam: huh? no, never thought that | 18:09 |
| mneptok | vila: my humor is like that. obtuse until you "get" it. and then it's just unfunny. ;) | 18:09 |
| jam | So I think there is still worth in having a Wiki page that can reference things we haven't bundled | 18:09 |
| kfogel | jam: ? | 18:10 |
| jam | Whether we should be calling the stuff from source "doc.bazaar..." perhaps | 18:10 |
| kfogel | jam: couple of things: | 18:10 |
| mneptok | jam: the question was about "commit --fixes" referencing multiple bugs as fixed. | 18:10 |
| kfogel | jam: one, the so-called "official documentation site" is really talking about developer and reference documentation, not other kinds of documentation, it sounds like. | 18:10 |
| jam | mneptok: '--fixes' is a list option, so I'm pretty sure you can supply it multiple tiems | 18:10 |
| jam | times | 18:10 |
| kfogel | Since the Users Guide is by far the most needed bit of documentation, than which all others pale in comparison to, a user would naturally expect it to live on the official documentation site. | 18:11 |
| jam | bzr commit --fixes lp:1 --fixes lp:2 | 18:11 |
| jam | etc | 18:11 |
| kfogel | jam: sorry, misphrased | 18:11 |
| mneptok | jam: right right. i didn't realize it was a list | 18:11 |
| mneptok | (that's pretty sweet) | 18:11 |
| jam | mneptok: I don't see that the help text really *tells* you it can be supplied multiple times | 18:11 |
| kfogel | jam: what I'm getting at is: docs is just docs, users don't care where they came from, but right now it looks to a user like our docs are split across two sites. | 18:11 |
| jam | mneptok: so certainly there is a bug report & fix waiting for your name | 18:12 |
| mneptok | jam: your hints are as subtle as a flying mallet. :) | 18:12 |
| mneptok | and .... on the to-do | 18:13 |
| mneptok | thanks | 18:13 |
| kfogel | jam: anyway, it will be less important when those globes-on-external-links go away. :-) | 18:13 |
| jam | kfogel: so, you're welcome to clean it up as you see fit, but I think non-vetted documentation is still worth having | 18:14 |
| jam | and once vetted we can bring it into the bzr source tree | 18:14 |
| jam | I don't really care how that is organized | 18:14 |
| jam | vila: revno 3822 breaks '-s bt.test_chk' for me | 18:15 |
| jam | shame on you :) | 18:15 |
| vila | jam: I see that, amazing (I mean the fix is amazingly simple but I'd like to understand it :) | 18:16 |
| jam | vila: you changed: "common = prefix[:pos+1]" to "common = prefix[:pos]" | 18:16 |
| serg | jam: "bzr help bugs" does say that "Note: As you provide a short name for each tracker, you can specify one or more bugs in one or more trackers at commit time if you wish." | 18:16 |
| kfogel | jam: until you said that, I never even knew that in-source-tree vs in-wiki meant vetted vs non-vetted. I think if a user sees something on a website with "bazaar-vcs.org" in its name, the user will assume it's reasonably vetted. I don't think anyone but a few developers is even conscious of what docs are in the source tree. | 18:16 |
| jam | kfogel: well, I do watch the emails about updates to the wiki | 18:16 |
| jam | but it *is* still a wiki | 18:16 |
| vila | jam: I thought I have that covered with the tests I added when removing the asserts, I need to find the right test to add :) | 18:16 |
| jam | vila: just add direct tests to the "common_prefix" code | 18:17 |
| jam | It is a class method anyway | 18:17 |
| vila | look at that 3822 diff again ;-) | 18:17 |
| kfogel | jam: I understand. I'm just saying that we don't have a choice about what users regard as "vetted". If it's on the site, they'll trust it -- they're not tracing the source back to this or that location. So if we're maintaining these distinctions with the idea that it's meaningful to users, that's probably not working... | 18:17 |
| jam | vila: the problem is that you aren't asserting *what* the common prefix is | 18:18 |
| vila | jam: I do now :) | 18:18 |
| jam | so for "beg" versus "begin" I would guess it is returning "be" | 18:18 |
| jam | which wasn't being detected | 18:19 |
| jam | vila: so did that fix it? | 18:23 |
| jam | and when are you committing that to core :) | 18:23 |
| vila | sure | 18:23 |
| vila | jam: argh family NMI, I'll commit the fix later tonight :-/ | 18:27 |
| jam | vila: then I'll fix it now | 18:28 |
| jam | since I need a non-broken brisbane-core | 18:28 |
| vila | no wait, almost there | 18:28 |
| jam | vila: enjoy your family time, though | 18:28 |
| jam | (certainly don't postpone family for this, it isn't that hard to fix) | 18:28 |
| vila | but the tests are already updated too here | 18:28 |
| vila | jam: pushed (and that's why we want full test suite passing everywhere :-) | 18:31 |
| Lo-lan-do | Jc2k: I'm interested in helping out with bzr-*-pack, what would be a good way for me to help? | 18:41 |
| Jc2k | Lo-lan-do: thats up to you! | 18:43 |
| Jc2k | Lo-lan-do: writing test cases would be awesome | 18:44 |
| Jc2k | but even reproducable bug reports would be welcome | 18:44 |
| jam | vila: of course, in your haste you left in a "import pdb;" but I'll fix that :) | 18:45 |
| Lo-lan-do | Jc2k: I'll try using it first then :-) Is there any doc? | 18:45 |
| Jc2k | Lo-lan-do: ooh, docs would be nice too. | 18:45 |
| Lo-lan-do | I'll take that as a "no". | 18:46 |
| Jc2k | the gist is you install the bzr-git plugin and then set the bzr-*-pack scripts up so git finds them instead of its own git-*-pack. | 18:46 |
| Jc2k | then it should *just work* | 18:46 |
| Lo-lan-do | A symlink to ~/bin/git-*-pack would do the trick? | 18:47 |
| Jc2k | Lo-lan-do: well thats the icky bit, it probably wouldnt - i dont think .bashrc/.profile is respected when doing "ssh host git-program-name" | 18:48 |
| Lo-lan-do | I see. /usr/local/bin it is then. | 18:48 |
| montwi | mneptok: hi | 18:50 |
| montwi | About --fixes; Can one also use --fixes=lp:444,lp:3333 ? | 18:50 |
| montwi | Anyway, better documentation for 'bzr help commit' would be appreciated | 18:51 |
| jelmer | montwi: I think you can specify --fixes multiple times | 18:51 |
| montwi | works, but a little more cumbersome; Best would be to allow both things | 18:51 |
| jam | montwi: well, it is possible that bugfixes have commas in them | 18:55 |
| montwi | how can bug fix numbers have commas in them ? | 18:56 |
| montwi | aren't the bug numbers just an incremental serie ? | 18:57 |
| Lo-lan-do | On LP maybe. | 18:59 |
| Lo-lan-do | But there are other bug trackers, you know :-) | 18:59 |
| kfogel | Okay, opinions: "screen shots" -- one word or two? | 18:59 |
| montwi | then make an option --multi-fixes that supports both | 18:59 |
| Odd_Bloke | kfogel: One. | 19:01 |
| kfogel | Odd_Bloke: ok, sold | 19:01 |
| * fullermd was going to say 'two'... | 19:03 | |
| === chx_sleeping is now known as chx | ||
| fullermd | Especially if you're running multi-head, because then you get "screens shot". | 19:03 |
| fullermd | And "screensshot" is a bit too Gollum. | 19:04 |
| Tak | it's still one logical screen imo | 19:04 |
| jam | Tak: it gets a bit weird if you have different sized monitors, though | 19:09 |
| Lo-lan-do | Jc2k: __init__() takes exactly 2 arguments (1 given) / Unable to load plugin 'git' from '/home/roland/.bazaar/plugins' | 19:09 |
| Lo-lan-do | Jc2k: Does that ring a bell? | 19:09 |
| jelmer | Lo-lan-do: you need a newer bzr | 19:09 |
| Lo-lan-do | >> 1.11? | 19:10 |
| jelmer | yeah | 19:10 |
| Lo-lan-do | Um. I actually have 1.12-1. | 19:11 |
| jelmer | Lo-lan-do: what bzr-git do you have? | 19:11 |
| jelmer | you might need a newer bzr-git instead :-) | 19:11 |
| Lo-lan-do | Straight out from http://bazaar.launchpad.net/%7Ejohncarr/bzr-git/git-serve/ rev "215: John Carr 2009-01-26 Merge upstream" | 19:11 |
| * Lo-lan-do tries from trunk | 19:12 | |
| jelmer | I suspect John may have to merge trunk | 19:12 |
| Jc2k | *nod* havent merged in a bit. | 19:12 |
| Lo-lan-do | Ah, better. | 19:12 |
| Lo-lan-do | Blah. It seems I need to install the plugin to /usr/local or something, it doesn't seem to find bzrlib.plugins.git.server otherwise. | 19:16 |
| Lo-lan-do | Nope. Not better. | 19:17 |
| Lo-lan-do | Ah, installing to /usr works slightly better -- only to stop later by not finding bzrlib.plugins.git.foreign. | 19:18 |
| Lo-lan-do | jelmer, Jc2k: http://pastebin.com/d705b5138 | 19:26 |
| Lo-lan-do | Also http://pastebin.com/d319f3cde :-( | 19:40 |
| jelmer | Lo-lan-do: thanks | 19:42 |
| Lo-lan-do | Seomething seems to expect normal bzr revids to start with a particular prefix, which they... don't. | 19:44 |
| Lo-lan-do | (The bzrtest is a standalone branch of the simplest "bzr init;date>foo;bzr add;bzr commit -mbar" variety) | 19:45 |
| jelmer | Lo-lan-do: yes, it only works with revisions pushed from git afaiu | 19:45 |
| jelmer | this is the roundtripping I mentioned yesterday | 19:45 |
| Lo-lan-do | Oh damn. I misunderstood that part then. | 19:46 |
| Lo-lan-do | So it's currently only usable as a storage backend for git, with read-only for bzr clients? | 19:47 |
| * Lo-lan-do ponders | 19:49 | |
| jelmer | Jc2k: ^ | 19:49 |
| Jc2k | *nod* | 19:51 |
| Jc2k | in theory you can dpush to it.. | 19:51 |
| Jc2k | :P | 19:51 |
| Lo-lan-do | Any clue what I'd need to do to fix that? | 19:54 |
| Lo-lan-do | As far as I understood, git revids are hashes of their contents, so presumably they could be computed on the fly, right? | 19:54 |
| Jc2k | Lo-lan-do: so consider git ls-remote | 19:55 |
| Jc2k | it just lists the tip sha1s of each branch | 19:55 |
| Jc2k | to satisfy this on the fly, we not only need to sha the commit, but the inventory and all of the blobs. and not just for the top commit, but *all* parent commits going back to the origin. | 19:56 |
| Lo-lan-do | I get the same error. | 19:56 |
| Jc2k | of course you do, its just the easy part of git pull | 19:56 |
| Jc2k | just saying, you cant do it on the fly, too expensive. we need to build a lookaside cache of sha to bzr rev id | 19:57 |
| Lo-lan-do | I guess all that data could be cached, but yeah, I see the problem. | 19:57 |
| jelmer | my branch has the beginnings of a cache | 19:59 |
| fullermd | That's good. If it had the end of the cache, you'd already have run out. | 20:00 |
| * Lo-lan-do tries following the code | 20:02 | |
| === jfroy|work is now known as jfroy | ||
| === RAOF_ is now known as RAOF | ||
| Tak | what's the bzrlib equivalent of `bzr branch`? Branch.clone? | 20:43 |
| mwhudson | Tak: sprout | 20:48 |
| Tak | that'll do WT as well when applicable? | 20:49 |
| lifeless | Tak: yes | 20:49 |
| Tak | cool, thanks | 20:53 |
| lifeless | poolie: I still have some symptoms; I am coding ok at the moment, but I'm going to stay fairly submarine today; if I go downhill I'll let you know | 20:58 |
| === kiko is now known as kiko-phone | ||
| phinze | okay weird lock issue doing a netcat bounce with bzr+ssh | 21:29 |
| phinze | is there any way of checking manually for lock data? | 21:30 |
| lifeless | phinze: bzr info | 21:30 |
| phinze | blank | 21:30 |
| phinze | (no locks) | 21:30 |
| phinze | hmm oh the lock is actually on the remote branch | 21:31 |
| phinze | lemme go there and do it | 21:31 |
| === bac is now known as fakestevejobs | ||
| lifeless | bzr info <url> should work | 21:31 |
| === fakestevejobs is now known as bac | ||
| jelmer | moin lifeless | 21:32 |
| phinze | yeah because of the bounce the lock-url looks like chroot-3079972620:///path/to/repo/and/branch/.bzr/branch/lock | 21:32 |
| mwhudson | ah that bug | 21:32 |
| mwhudson | bzr break-lock :push will work, i think | 21:32 |
| lifeless | hi jelmer | 21:32 |
| ronny | jelmer: can subvertpy tell me infos about moves in the svn workdir? | 21:33 |
| phinze | mwhudson: nice! ty | 21:33 |
| jelmer | ronny: only about copies | 21:34 |
| * phinze is all about breaking locks | 21:34 | |
| jelmer | lifeless: wrt bug 330928, what do you expect bzr-svn to do differently? | 21:34 |
| ubottu | Launchpad bug 330928 in bzr-svn "1.12 bzr help commands failed" [Undecided,New] https://launchpad.net/bugs/330928 | 21:34 |
| ronny | jelmer: so i'd have to infer moves via copy + remove? | 21:34 |
| jelmer | ronny: yeah, although I wouldn't mind seeing a utility function for inferring moves in subvertpy | 21:35 |
| montwi | strange problem with merge | 21:36 |
| lifeless | jelmer: I thought I put it in the bug: the absence of a dependency shouldn't cause noise on operations that don't need the plugins functionality | 21:36 |
| montwi | I upgrade just my own mysql-maria trees to bzr version 1.9; The original on launchpad is the previous versions | 21:36 |
| montwi | now I get a lot of conflicts, even on easy stuff when doing a merge | 21:37 |
| montwi | The question: Can one get different merges than before becasue of version 1.9 ? | 21:37 |
| lifeless | jelmer: you don't need subvertpy to have a command object with help text :) | 21:37 |
| montwi | I mean with with the 1.9 "A branch and pack based repository that uses btree index" | 21:38 |
| lifeless | mwhudson: montwi question, oculd that be related to the fixup script? | 21:39 |
| montwi | in some cases, I have a conflict but now .BASE file | 21:40 |
| mwhudson | lifeless: i'm not completely sure what you mean by "fixup script" but instinct says "no" | 21:40 |
| lifeless | mwhudson: didn't you just forward the output of a script run on all the mysql branches? | 21:40 |
| phinze | mwhudson: can't seem to find that bug reported -- should i file one for the lock message to suggest break-lock :push? | 21:41 |
| mwhudson | lifeless: oh | 21:41 |
| mwhudson | lifeless: yes, i guess that is possible | 21:41 |
| mwhudson | phinze: it's certainly reported | 21:41 |
| lifeless | montwi: no, the 1.9 formats don't change the data model. However a seperate task has been done recently | 21:41 |
| mwhudson | phinze: https://bugs.edge.launchpad.net/bzr/+bug/250451 | 21:41 |
| ubottu | Ubuntu bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [High,Confirmed] | 21:41 |
| montwi | lifeless: tell me... | 21:41 |
| mneptok | oh dear. Monty meets Robert. i'm pretty sure this day is mentioned in Revelations. :) | 21:41 |
| mwhudson | montwi: there was a bug in the initial conversion of mysql to bzr | 21:42 |
| lifeless | mneptok: we've met before | 21:42 |
| mwhudson | https://bugs.edge.launchpad.net/bzr/+bug/277537 | 21:42 |
| ubottu | Ubuntu bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [High,Fix released] | 21:42 |
| * montwi waits with high antipation for a simple, elegant solution that doesn't require hours of work on my side | 21:42 | |
| mneptok | lifeless: oh good! | 21:42 |
| mwhudson | we recently ran the script to fix the damage to the repositories hosted on launchpad | 21:43 |
| jml | lifeless: yeah, I want to review it over the next couple of days | 21:43 |
| lifeless | montwi: I would guess that running the fixup script on your copy of any branches is the right answer, but I wasn't personally involved | 21:43 |
| mwhudson | vila: hello! | 21:43 |
| mwhudson | i didn't think running this script should have had far-reaching consequences though from what i was told | 21:44 |
| montwi | so I should revert the merge, run the script and try the merge again ? | 21:44 |
| === mtaylor_ is now known as mtaylor | ||
| mwhudson | montwi: are you using --weave merges? | 21:44 |
| lifeless | montwi: that is my first inclination, yes. vila: or jam: have more detail on the specific issues | 21:44 |
| montwi | no, just bzr merge | 21:44 |
| mwhudson | then i _think_ it should be something else, 'cause the fix only affects the per-file graph but the merge3merger doesn't look at that afaik | 21:45 |
| lifeless | montwi: I'll poke quickly at this; can you run 'bzr revision-info' in both branches(source and target) for the merge | 21:48 |
| lifeless | montwi: I'm just steting up a work area now | 21:48 |
| montwi | 2674 monty@askmonty.org-20090218144051-xtg0ki3hbhosiqk7 | 21:48 |
| lifeless | is it lp:mysql-server to get trunk ? | 21:49 |
| montwi | sorry, don't have both trees | 21:49 |
| lifeless | montwi: that ok, URL for the second is fine | 21:49 |
| lifeless | or url's for both | 21:50 |
| kirkland | i just did a 'bzr revert', how do i undo the revert? | 21:50 |
| montwi | I am basicly doing a merge with the bzr+ssh://bazaar.launchpad.net/~monty/maria/1.5 and the lp:~mysql/mysql-server/mysql-maria trees | 21:51 |
| montwi | So I have a copy of the 1.5 tree here and then I did: | 21:51 |
| montwi | bzr merge lp:~mysql/mysql-server/mysql-maria | 21:51 |
| lifeless | kirkland: you don't? any files reverted are backed up with ~ pattern suffixes | 21:52 |
| mwhudson | kirkland: with a nasty shell script probably; revert leaves the changes in *~#~ files | 21:52 |
| kirkland | lifeless: okay | 21:52 |
| kirkland | better question | 21:52 |
| lifeless | kirkland: if you had a pending merge, you can put that back by just doing the merge again | 21:52 |
| kirkland | let's say i'm currently on revision 320 | 21:52 |
| kirkland | i want to prune only revision 315 | 21:52 |
| montwi | I just got a lot more conflicts that expected and some have looked strange. Unfortunately I resolved a lot before starting to think something is wrong | 21:52 |
| kirkland | and leave everything else untouched | 21:53 |
| kirkland | what's the best way to do that? | 21:53 |
| lifeless | kirkland: 'bzr merge -r 315..314 .' | 21:53 |
| montwi | will check if I can find one file that includes not resolved conflicts that should have been resolved | 21:53 |
| kirkland | lifeless: brilliant | 21:53 |
| kirkland | lifeless: thanks. | 21:53 |
| mwhudson | does bzr do any logging setup at import time? | 21:59 |
| lifeless | mwhudson: no | 21:59 |
| mwhudson | hm | 21:59 |
| lifeless | mwhudson: its hard to undo that sort of thing, due to python.logging.sucking.hard | 21:59 |
| lifeless | montwi: nearly up to testing | 21:59 |
| jam | mwhudson: you can call 'bzrlib.trace.enable_default_logging()" | 22:00 |
| poolie1 | hello | 22:00 |
| jam | hi poolie1 | 22:01 |
| poolie1 | lifeless: ok, take it easy | 22:01 |
| mwhudson | jam: yeah, but... | 22:01 |
| mwhudson | let me work out what i'm really complaining about first i guess :) | 22:01 |
| jam | lifeless: just found something odd with groupcompress | 22:01 |
| montwi | lifeless: thanks | 22:01 |
| === poolie1 is now known as poolie | ||
| jam | I put together code to support "negative" offsets | 22:02 |
| montwi | found one file that shows the strangeness | 22:02 |
| jam | so that rather than giving the bytes since-start, you can give bytes before current endpoint | 22:02 |
| montwi | lifeless: mysql-test/extra/rpl_tests/rpl_log.test | 22:02 |
| jam | the weird thing is that before zlib, it should save something like 44kB | 22:02 |
| jam | but *after* zlib, I actually see an increase in size of ~120kB | 22:03 |
| montwi | Here the .OTHER and .THIS files are almost identical but the .BASE file is very differnt from either of the files | 22:03 |
| === kiko-phone is now known as kiko | ||
| montwi | it's almost as it's from and older version | 22:03 |
| mwhudson | montwi: ah, maybe you _should_ be using --weave or --lca to merge | 22:03 |
| mwhudson | the overall least common ancestor can end up being surprisingly old | 22:04 |
| lifeless | jam: interesting; I presume you figured that that will be smaller to encode? | 22:04 |
| lifeless | jam: I expect that its larger because bytes-from-start is probably a repeating pattern | 22:04 |
| montwi | Shouldn't one normally get the .BASE from the last merge ? | 22:04 |
| jam | lifeless: well it is shorter for raw (uncompressed) bytes | 22:04 |
| jam | but you're probably right | 22:04 |
| jam | anyway, it was worth exploring | 22:06 |
| mwhudson | montwi: nope | 22:06 |
| mwhudson | well, maybe normally | 22:06 |
| jam | I also notice that for the chk invs, we have a trailing "insert" which is always followed by an insert of the final newline | 22:06 |
| lifeless | montwi: ok, I get 128 conflicts, so trivially reproduced :) | 22:06 |
| mwhudson | anyway, i'll let robert explain with science rather than guessing | 22:06 |
| lifeless | montwi: it goes off the top but: | 22:06 |
| jam | lifeless: does it give a "criss-cross" warning? | 22:06 |
| lifeless | Warning: criss-cross merge encountered. See bzr help criss-cross. | 22:06 |
| lifeless | jam: :) | 22:06 |
| jam | hence use --weave | 22:07 |
| lifeless | jam: perhaps that should be down the bottom/also at the bottom ? | 22:07 |
| montwi | I have already resolved some conflicts, so can I do bzr remerge on the rest ? | 22:07 |
| jam | lifeless: we just need to either auto-switch it on | 22:07 |
| jam | or use per-file graphs for merge3 | 22:08 |
| montwi | bzr remerge --weave ? | 22:08 |
| jam | montwi: should work | 22:08 |
| montwi | thanks; will try | 22:09 |
| lifeless | montwi: I think so; I just repeated the merge with --weave, got 40 conflicts | 22:09 |
| montwi | ok, down to 41 conflicts, sounds much better | 22:10 |
| lifeless | montwi: and mysql-test/extra/rpl_tests/rpl_log.test is not conflicted | 22:10 |
| asabil | is there any way to convert a rich-root repo to non rich root ? | 22:10 |
| lifeless | asabil: no | 22:10 |
| poolie | jelmer, hi | 22:10 |
| lifeless | asabil: not in terms of 'downgrade and merge with folk that hadn't upgraded' | 22:11 |
| asabil | lifeless: I want to convert a repo completely | 22:11 |
| montwi | lifeless: yes, rpl_log.test is ok | 22:11 |
| montwi | why is weave not default ? | 22:11 |
| asabil | I am the only owner of the repo and related branches | 22:11 |
| lifeless | asabil: if you're already on rich root, it should work fine - just stay with that format | 22:12 |
| asabil | lifeless: I am trying to write a filter-branch thingie | 22:12 |
| Lo-lan-do | I'll ask the recurring question: when's rich-root becoming default? | 22:12 |
| asabil | but when I call Tree.revert | 22:12 |
| asabil | I hit a ValueError: Cannot have multiple roots. | 22:12 |
| asabil | in rich-root repositories | 22:12 |
| montwi | lifeless: any obvious reasons why include/maria.h doesn't have a .BASE file ? | 22:12 |
| montwi | it's has an OTHER in THIS file | 22:13 |
| lifeless | montwi: I don't think --weave generates .BASE files | 22:13 |
| lifeless | I may be wrong | 22:13 |
| asabil | lifeless: any idea ? | 22:13 |
| lifeless | asabil: a bug in your code I suspect | 22:13 |
| asabil | lifeless: that's definitely the case, but is there any doc that would help me understanding the issue | 22:14 |
| asabil | why the code works with non rich root ? and doesn't with rich root ? | 22:14 |
| lifeless | montwi: in fact, maria.h isn't conflicted for me at all | 22:15 |
| montwi | strange. I had a conflict | 22:15 |
| montwi | trivial conflict to resolve, but still strange that we get different answers | 22:16 |
| lifeless | montwi: you remerged after doing some edits | 22:16 |
| montwi | but I didn't commit | 22:17 |
| montwi | so shouldn't remerge have used the original (kind of reverted) file ? | 22:17 |
| lifeless | I'm not 100% sure if it looks at your edits or not | 22:17 |
| montwi | just noticed I am using bzr 1.10; Will update to bzr 1.12 at once | 22:17 |
| lifeless | its not a command I use much | 22:17 |
| lifeless | I used 1.11 in this test | 22:18 |
| montwi | lifeless: no problem, the issue is resolved for that file. will see if same things happesn for files I didn't touch before | 22:18 |
| lifeless | mtaylor: when are you upgrading your main repos to 1.9 :) | 22:21 |
| mtaylor | lifeless: when you say "my main repos" ... are you referring to MySQL | 22:22 |
| lifeless | mtaylor: and drizzle, unless its already 1.9 | 22:22 |
| mtaylor | lifeless: drizzle is on 1.6 ... I just haven't gotten around to 1.9 upgrade yet | 22:22 |
| mtaylor | lifeless: I'm pinging chad about 1.9 for mysql | 22:23 |
| emile | jam: hi again. I tried a conversion (bzr svn-import subversion bazaar) on another system, and this time the bzr repo was actually smaller than the original svn repo. How can I confirm everything went OK? If I cd into the created directory and do "bzr log", I get: bzr: ERROR: Not a branch: "/home/emile/PW/bazaar/.bzr/branch/" | 22:23 |
| jam | emile: the repo isn't a branch. there should be subdirectories which *are* branches, though | 22:24 |
| jam | bazaar/trunk | 22:24 |
| jam | for example | 22:24 |
| emile | Hey ho, and so there is! It's even kept the commit logs! The tags subdir isn't present, however. Not a major biggie, but if it can be preserved... | 22:26 |
| jam | emile: "bzr tags -d bazaar/trunk" | 22:26 |
| jam | I believe we convert tags as real "tags" and not as directorise | 22:26 |
| jam | directories/branches | 22:26 |
| emile | awseome. Time for me to start digging through the docs, as you can see I'll have a few svn-isms to shake loose ;) | 22:28 |
| montwi | lifeless: did you get a conflict with mysql-test/mysql-test-run.pl | 22:31 |
| montwi | this didn't have a .BASE for me either | 22:31 |
| lifeless | montwi: not sure, I removed the test area already :( | 22:31 |
| lifeless | jam: does --weave output .BASE ? | 22:32 |
| === jfroy is now known as jfroy|coalmines | ||
| montwi | ok, looks like I don't have any .BASE files | 22:33 |
| montwi | not good as it makes life harder | 22:33 |
| mwhudson | lifeless: i don't think --weave even really has a sane concept of base | 22:34 |
| mwhudson | it's not a three way merge | 22:34 |
| === jfroy|coalmines is now known as jfroy|bunnysuit | ||
| === jfroy|bunnysuit is now known as jfroy | ||
| montwi | merge done, now running test. will push in the morning if test suite goes trough | 23:10 |
| montwi | sorry, wrong channel ... | 23:13 |
| === montwi is now known as montywi|sleep | ||
| asabil | does anyone see the problem with this code: http://bazaar.launchpad.net/~asabil/%2Bjunk/bzr-filter-branch/annotate/head%3A/__init__.py ? | 23:33 |
| asabil | I get the following traceback: http://pastebin.ca/1341535 | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!