[00:00] vila: btw, I've been using your --startingwith a lot lately, thanks for doing it [00:00] It actually jumps out at me when I'm using an older branch which doesn't have it [00:02] Is there a pleasant way of deciding whether something is remote? [00:04] I take BRANCH as an argument on the command line, if it is local then I want to "cd" there, if it isn't I want to change some values of something [00:04] it doesn't have to be perfect in checking whether something is local, and I don't mind about the case that someone gives an sftp:// URI that resolves to their current working directory. [00:05] would just checking for local paths and file:// URIs with string comparison be ok? [00:07] local = urlparse.urlsplit(location)[0] in ('', 'file') [00:07] that would seem to do it [00:11] mwhudson, you've got mail. Let me know if that addresses your comments [00:12] lifeless: can you please set up a pqm 1.6 branch some time soon [00:12] actually nm [00:12] we'll wait to branch til next week [00:13] beuno: ok [00:13] cool, ipython uses bzr and LP! http://ipython.scipy.org/moin/ [00:13] morning [00:23] jam: Where is cvsps-import storing the map history? [00:24] mkanat: look at your output there should be a directory where it is storing something.map [00:24] I don't remember off-hand [00:24] but it should be fairly obvious [00:24] jam: Okay. [00:24] Ah, yeah. [00:25] jam: If I do a manual checkin on one of the branches, will it break fmap? [00:26] mkanat: you aren't supposed to be modifying these branches outside of cvsps, I'm not sure what will happen if you do [00:26] Hm. [00:26] jam: I'm trying to figure out a workaround for the situation I'm in, any ideas? [00:26] Hmm.. I downloaded the bzr emacs repository from http://bzr.notengoamigos.org/emacs.tar.gz, but I get a fatal error when trying to check out revision 50255 [00:26] mkanat: well, you can fix cvsps or rebase.... [00:26] sorry I don't have a better answer [00:27] jam: It looks like rebase won't work, as far as I can see... [00:28] mkanat: sorry you can fix (cvsps or rebase) [00:28] Ahh. [00:28] not (fix cvsps) or (rebase) [00:31] jam: What would happen if I surgically remove those revisions from revision-history? [00:33] Ha, okay, that's bad. === abentle1 is now known as abentley [00:50] jearl`: you there? [01:13] Ah, I'm back online. [01:16] mkanat: uncommit should be fine, I would expect converters to just re-add them tho :P [01:17] mkanat: also, you may find that there are fixes for the cvsps program itself 'out there', I've seen various folk talk about patches for it [01:24] lifeless: Yeah, but this one isn't so much a bug as a missing feature. [01:24] lifeless: Also, there are commits after the "bad ones". [01:24] mkanat: sorry, I didn't track the very start of the conversation; whats the root bad behaviour of cvsps? [01:25] lifeless: It doesn't track what patchset a branch starts at from its parent. [01:25] so how do we create new branches at all? [01:26] does cvsps-import infer that itself? [01:26] jam: ^ ? [01:31] lifeless: I think so. I think the first time it sees a branch name it branches it from its ancestor at that point in time. [01:31] lifeless: I'm guessing there's no way to uncommit a series of revisions that aren't actually the most modern set. [01:34] lifeless: The stream of cvsps tells you "create a new branch, originating from this branch" [01:34] It doesn't indicate at what point in time along the other branch to split, it was just inferred by order [01:34] jam: ok [01:34] jam: so could we not just run cvsps in toto again, checking it for consistency against the last output [01:35] lifeless: hi, do you have a minute, I'd like to confirm something? [01:35] james_w: shoot [01:35] lifeless: is your idea that a revision should only appear in the left hand ancestory of a branch if it was uploaded to that distribution? [01:35] lifeless: I think cvsps deterministically gives the same results each time [01:36] james_w: from the branch point yes [01:36] lifeless: if it didn't, then I couldn't support resume without more work [01:36] lifeless: e.g. if Debian was to upload two versions quickly, and the first wasn't synced then it should not be a revision in the Ubuntu branch. [01:36] jam: surely then new branches appear in the entire output correctly? [01:36] lifeless: apparently not [01:37] It seems that if you tag a branch [01:37] and then do a couple of commits on the source branch [01:37] and *then* commit to the new branch [01:37] it shows the same thing [01:37] except it doesn't realize that the tag was on an earlier commit [01:37] oh, date sorted output [01:37] something like that [01:38] it claims to do topological sorting, etc [01:38] but we are seeing date sorted here [01:38] lifeless: what about packages that predate Ubuntu, should they adopt the history of the Debian branch? [01:40] james_w: I'm not sure what you mean [01:42] lifeless: this is stage 2 really, but I want to get it clear in my head, the first version of package foo didn't appear in Ubuntu as it predates it, so if the above statement is true it should not be in the left-hand ancestory. However, this would mean that the branches for Debian and Ubuntu are divergent, even if foo has only ever been synced from Debian. [01:43] is that the desired behaviour? [01:43] ah [01:43] so perhaps rephrasing [01:44] 'every upload we import from ubuntu should be in the left hand ancestry' [01:45] sure [01:46] does that help ? [01:46] and in the first case, where debian uploads two packages quickly and only the second is synced, should that cause divergence, or would it be ok to include the first upload in the left hand ancestry? [01:47] I think that is fine [01:47] given you're tagging to identify distro versions orthogonally to revision ids [01:48] I don't think I ever suggested that commit should imply upload, only that upload -> left hand commit [01:48] (If I did, sorry for confusion, I didn't intend to) [01:48] abentley: I have a test case [01:49] ah, no, you didn't imply either way, I don't think. I was just unsure, so I wanted to confirm before getting too far down one path. [01:49] thanks for your time. [01:49] abentley: http://pastebin.com/d54e0a61e [01:50] abentley: if you could just eyeball that and see if it makes sense to you [01:50] back to bed :-) [01:51] fun, it breaks everything [01:52] actually, http://pastebin.com/d3ba9db64 is the working version [01:54] lifeless: on line 21, is that "line\2line..."? [01:54] abentley: oh, nice catch :) [01:55] should be \n indeed [01:55] now it only breaks annotated weaves as expected [01:56] Is the first vf only being used to generate a sha1? [01:56] yes, I am shrinking it further now [01:57] if it appears to make sense to you that is [01:58] I forget what the parameters to ParentText are... [01:58] parent number [01:58] | __init__(self, parent, parent_pos, child_pos, num_lines) [01:59] I got those numbers by printing the bzr generated mpdiff with the optimiser disabled [01:59] but I wanted a test that was independent of that other discussion [02:00] Yeah, assuming that \2 is \n, it looks reasonable. [02:00] thanks [02:02] * fullermd hates the launchpad bug mailings... [02:03] Every time I THINK I've captured every way they can get to me, some whole new set of headers arrives... [02:04] ok, it has to be on top of a delta to trigger the error [02:05] http://pastebin.com/d3b2ceea5 [02:21] * igc running some errands - bbl [02:31] yay finally triggered this without mpdiff involvement [02:50] lifeless: no test for 234748 yet, will do it soon [02:51] poolie: I'm dealing with a very similar bug [02:51] nearly finished [02:51] if you have a fix for 234748, perhaps you could try my test case against it ? [02:52] happy to [02:52] http://pastebin.com/d6b23fcca [02:54] feature request: [02:54] a request for a feature [02:55] bzr foo --hlep should show the help for foo [02:55] it does [02:55] If I can't type 'help' then I probably need it. [02:55] unless you meant literally hlep [02:55] Hmm. We have quite a few tests that rely on indirect ways to force snapshotting in knits. Which is fine (we don't want a public API for that), but maybe it deserves some explicit test infrastructure so that if the snapshotting heuristic changes we don't have to change/audit lots and lots of tests. [02:55] oic :) [02:56] spiv: indeed. I'd already written: [02:56] meh [02:56] I'll finish, commit and you can review instead ;) [02:56] lifeless: ok :) [02:57] is there anybody specifically looking at git-bzr bridging? [02:58] igc [02:59] I just had a possibly nasty idea of CVS -> git -> bzr [02:59] why? [02:59] cvs->git recommends cvs2svn fastexport nowadays [02:59] and bzr-fastimport can read that directly [02:59] because CVS -> bzr isn't quite working and cvs->git is working for me [03:01] hmm, maybe I should try bzr-fastimport then [03:02] wait a sec though [03:03] why doesn't LP use bzr-fastimport then [03:03] LaserJock: i think fastimport is probably the way to go [03:03] but it would be good to just fix the bugs in reading from cvs2svn [03:04] jelmer was looking at doing git foreign branch support though [03:12] poolie: did your fix fix my test case? I would expect not .. [03:14] sorry have not tried it yet, will now [03:15] !! [03:15] yes it did [03:15] thought it might [03:15] i am a bit surprised; i thought this only affected the multiple extraction case [03:15] interesting [03:15] no [03:15] we've an awkward abstraction [03:15] it doesn't strictly do so [03:15] the Content objects [03:15] yes [03:16] also, the higher-level check code is still really thinking in terms of knits or weaves [03:16] ok, I'm going to commit what I have [03:16] because I think they are useful changes to review [03:16] and send in and move on [03:16] LaserJock: because fastimport is pretty new, and launchpad has been doing cvs imports since 2004? [03:17] mwhudson: makes sense [03:17] also [03:17] not sure how well suited the fastimport is for syncs [03:17] I haven't seen anything as strict or capable as cscvs is at at handling *ongoing* fuckage of cvs [03:17] ah [03:18] there are amazingly stupid things people can do to a live cvs repository [03:18] yeah, if we can fix the file-created-by-merge bug cscvs starts to look quite good again for what it dos [03:18] (and i think this bug is created by cvs changing since cscvs was written, believe it or not) [03:18] That's a side effect of there being amazingly stupid things people _have_ to do to a live cvs repository :) [03:18] given it consists entirely of analysing breakage people *do* [03:18] !cvs bashing [03:18] Factoid cvs bashing not found [03:19] :) [03:19] fullermd: not true; choose to yes, have to - no [03:19] lifeless: so this looks like a good test for 234748; do you think i should add another closer to the case where this arose? [03:20] poolie: uhm, my test happens to show up the bug. its a bit of a bug we don't have good tests of the behaviour on these things, neither fish nor fowl :( [03:20] well, it's pretty close to what i had in mind, except i didn't think it'd show up through that api [03:25] poolie: I've committed and sent to the list my state [03:25] poolie: that bug actually can lead to knit corruption on knit repositories [03:25] (not packs though) [03:27] jml: if you use your patched loom [03:27] jml: and do 'bzr st --short' what happens? [03:28] lifeless: traceback. I guess I do need those args after all. [03:28] :) [03:28] and maybe a test to catch that. [03:28] mmm [03:29] no need for the test I think [03:29] bzr blackbox tests will exercise options [03:29] (bzr selftest status) with loom installed should break [03:29] hmm. [03:29] oh [03:29] if that's the strategy, why did I need to add a test for non-loom support? [03:30] also you should upddate the bzr_commands in setup.py [03:30] I'd like to someday have 'bzr selftest loom' use that metadata to also run blackbox tests that match those patterns from bzrlib core [03:31] jml: because non-loom support is an explicit case we will not cause a fragile test on [03:31] jml: as opposed to options from bzr itself which could change at any time [03:33] lifeless: (just clarifying) even though it's covered you think it's better to have something explicit? I'm cool with that. [03:39] lifeless: I've done all that now. [03:42] OK, I'm having a hard time figuring out what -Dhpss is saying, but I get two of the "does not understand protocol 3" messages when doing a pull over the smart server when I specify a URL. [03:45] fullermd, I've been getting those for a while not with bzr.dev [03:46] It's not the getting them; it's the getting TWO of them. [03:46] ah [03:48] (actually, I get it with a number of other commands too, but pull's the easy one to point at) [03:49] fullermd, I get two also [03:49] (I just checked with pull) [03:49] I don't with push though [03:51] from the log, it looks like one for get, and one for open [04:02] yay with that fix versionedfiles tests pass [04:03] beuno: You want to file it? [04:03] what would be the best way to get a diff for a file between 2 revisions? [04:03] 'bzr diff -r x..y' [04:03] fullermd, I don't want to take the credit :p [04:04] lifeless, right, I meant with bzrlib :) [04:04] Well, I can't make heads or tails of -Dhpss :| [04:04] fullermd: that sounds like a bug in pull, we should avoid opening multiple connections when one will do. [04:04] merge at least did it too. [04:04] beuno: so do I - look at the code :P [04:04] fullermd: feel free to pastebin the ~/.bzr.log + console output, or mail it to me. [04:05] I noticed on an attempt to merge --uncommitted over bzr+ssh. Double sin-points for 2 protocol downgrades, before telling me it wouldn't work remotely anyway :p [04:05] fullermd: or a way to reproduce [04:05] lifeless, lol, well, yes. I was hoping for some magical answer which would save me from half an hour of browsing through bzrlib, but I guess it's the only way to learn :) [04:06] spiv: bzr init /tmp/foo ; cd /tmp/foo ; env BZR_REMOTE_PATH=bzr-1.4 bzr.dev pull bzr+ssh://localhost/tmp/foo/ [04:06] Or 1.5, or whatever is old enough to force the downgrade. [04:07] or just pulling from LP with bzr.dev :) [04:08] fullermd: ta [04:08] fullermd: I see it, thanks! [04:08] Ooh, three connections in fact. [04:09] Well, it was only one connection 'till *I* looked at it. That moved it to 2. Then you looked at it, and it became 3. [04:09] Nobody else look at it! [04:17] 37 errors left [04:18] lifeless: woot. [04:24] * beuno curses loggerhead [04:25] mwhudson, I may be wrong, but there is absolutely no easy way to get a diff for one file, with the current loggerhead code, right? I gets *all* the files changed [04:26] beuno: at some point, we should drink a very large amount of beer together [04:26] beuno: that sounds entirely plausible [04:26] If I upgrade a parent bzr branch, is that going to break merges with the branch's children? [04:26] you'll need to bend the history.History interface a bit [04:26] rockstar: "depends" [04:26] i think [04:26] mwhudson, heh, I will owe you quite a few when a month in, so I'll make an effort to make that happen [04:27] mwhudson, I'm going to add that then, I need that if I'm going to do any of the things I have in mind (I've been going in circled cursing for the past 4 hours) [04:28] ok [04:28] i haven't been loggerhead-ing much today [04:28] 30 minutes to get the ajax part sorted out, 4 hours jumping around loggerhead code and looking at many # This is a bad API, remove this eventually [04:33] heh heh heh [04:33] aaargh backscatter time [04:33] rockstar: no except for the case of rich-roots [04:36] lifeless, pack-0.92-subtree It's in great need of upgrading. [04:38] abentley: I've come around to your way of thinking w.r.t. keyspaces; the compelling argument for me is 'making pack indices regeneratable' - but the changes are all deeper than the surface stuff [04:39] abentley: we need to alter the knit records and up [04:39] rockstar: there is no more rececnt format than that [04:40] lifeless, more recent than pack-0.92-subtree ? Really? [04:40] rockstar: there are three flavours of formats - plain, rich-root, and subtree [04:40] pack-0.92 is the most recent subtree format [04:40] lifeless, so no need to upgrade? [04:40] I'm glad that you agree. I'm curious about how it makes pack indices regeneratable, but I don't understand what you said afterward. [04:40] * rockstar wonders who told him to upgrade [04:40] rockstar: no need [04:41] abentley: every record written to a pack file should have enough data to parse it and figure out what index to put it in etc [04:41] rockstar: I recommend downgrading to rich-root-pack. [04:42] Unless you are actually using the subtree functionality. [04:42] lifeless: Right. [04:42] Why do we need to alter the knit records? [04:42] You want to store additional data in them? [04:42] abentley, will that break branches that need to merge back in? [04:42] abentley: and currently they don't :(. Anyhow, short term I think I've taken a huge step towards consistent access, but deadlines [04:43] abentley: yes, the knit records should store the full key [04:43] rockstar: Not unless they're using the subtree features. [04:44] Those features are experimental, and no one should be using them. [04:45] lifeless: Alternatively, we could store supplemental data elsewhere. Anyhow, I agree about deadlines. [04:46] abentley, alright, so I just bzr upgrade --rich-root-pack PATH_TO_REPO ? [04:47] abentley: storing it elsewhere makes verification harder amongst other things [04:47] rockstar: No. Because you're doing a downgrade that was supposed to be disallowed, you need to create a new branch and pull into it. [04:48] And then push that new branch with --overwrite ? [04:48] upgrade --rich-root-pack may well work, because it will trigger the clone-and-copy upgrade path [04:48] No, overwrite doesn't change format. [04:48] but take a backup first :P [04:49] lifeless, that's a given :) [04:51] fullermd: I've found the reconnection bug. It's pretty trivial, I'll send a fix in a moment. [04:51] abentley: question for you on bundle installs - you check for presence of texts before installing... [04:52] abentley: it would be simpler to just add them I think, trusting to the underlying store to turn duplicates into a sha check [04:54] lifeless: I don't think any of our current APIs allow this. [04:54] In many contexts, an early check could avoid plenty of I/O. But for this purpose, it would be fine. [04:56] abentley: thanks. in point of fact add_lines explicitly allows exact match duplicates IIRC [04:57] Ah. I guess I just assumed the API would match the store characteristics. [04:58] oh, add_lines raises RevisionAlreadyPresent [04:58] I'll check that that is not the cast any more [05:16] 19 [05:17] (this is without reconcile tests being run :P) [05:24] Hmm, is bzr supposed to require x11? [05:25] no [05:25] It looks like bzr recommends bzrtools, which recommends graphviz. apt-get follows those. [05:25] does graphviz require x? [05:25] Yup. [05:25] I thought it was just a rendering library [05:25] anyhow, override apt :P [05:28] Yeah, just inconvenient. I figure I should check if it was intentional before filing a bug. :) [05:28] graphviz can be built without requiring X, but I expect standard packages won't trim the options enough to do so. [05:29] ToyKeeper: its a weakness in dpkg [05:29] ToyKeeper: (I suspect) [05:31] Of the two optional dependency types, apt treats one as a requirement and ignores the other. I'd consider it a bug in apt, unless there's a hidden feature I'm missing. [05:34] ToyKeeper: its bizarre - graphviz package says that it contains the command line tools [05:34] ToyKeeper: and there doesn't seem to be a graphviz-nox package [05:35] ToyKeeper: That's a deliberate design decision - Recommends is there for packages which aren't hard dependencies, but which almost all sane people will want to use. Thus, installing recommends-by-default is the new default. [05:35] ToyKeeper: "aptitude install bzr graphviz-" will, however, install bzr without graphviz (and hence x11). [05:38] ish [05:38] It pulls in graphviz plus all deps, then removes graphviz from the list. So, 79 new packages instead of 80. :) [05:39] ToyKeeper: thats a definite bug [05:39] ToyKeeper: (on aptitude) [05:40] Oh, sorry. That's what apt-get does. aptitude works correctly. [05:40] Aptitude has had recommends-by-default for longer ;) [05:44] spiv, are you away on friday the 13th? :) [05:45] poolie: [05:49] I don't suppose there's a way to do an anonymous "bzr branch lp:foo", is there? :) [05:49] ToyKeeper: exactly that will do it [05:50] Oh, hmm. I tried it and got a warning about logging in, then a traceback. [05:51] the whinging is quite annoying [05:52] * ToyKeeper -> away [06:01] there probably should be a way to turn it off... [06:01] spiv: is that a yes? please don't make me go back into canonicaladmin :) [06:03] FWIW, it was caused by a broken python2.5 package; difflib was not importable. [06:03] oh ok [06:03] so just local to your machine? [06:07] mm, it'd be nice if launchpad people could register lp.net and have it like sourceforge has sf.net [06:08] true [06:09] If only they'd thought of it 11 years ago... :p [06:11] poolie: yes :) [06:32] what the frell is it with concrete drills and epping [06:33] !!!!!!!! [06:35] mwhudson, I'm off to bed. I've got most of the basics down for the diff-on-request branch, but I wasted a ton of time trying to figure out some of loggerhead (and bzr) inner workings. Hope to be able to upload the branch tomorrow (which will probably be your saturday, so I won't expect feedback) [06:36] beuno: time spent learning about innards is hardly wasted [06:36] beuno: i am on holiday my monday, btw [06:36] though i guess that's your sunday [06:37] mwhudson, yes, but it frustrates me when 7 hours go by, and I don't have much code to show for it :/ [06:37] feel free to send me email about anything you like :) [06:37] ah, well, that will give me more time to polish [06:37] lifeless: Is the railway line (to Chatswood iirc) finished? [06:37] mwhudson, very cool, thanks. Enjoy your weekend+holiday@ [06:38] lifeless: your test doesn't actually fail in trunk afaics [06:38] is it meant to? [06:39] poolie: the bundle I mailed? contains its own fix [06:39] bimberi: its not the source of the noise, buut no [06:39] i applied just the test into a branch from trunk and it does not fail [06:39] poolie: *blink* let me check [06:40] poolie: bah I must have fucked it while shrinking it [06:41] i was trying to write something based on it that would check get_lines and wondered what i was doing wrong :) [06:43] checking why now [06:44] here is why: [06:44] (Pdb) merge_content.text() [06:44] ['prelude \n', 'line'] [06:44] (Pdb) content.text() [06:44] ['line\n'] [06:44] (Pdb) [06:45] so I was wrong - you have to pass in left_matching_blocks to add_lines() to trigger the bug via the top level api [06:45] and the only thing that does that is bundles [06:45] hm [06:45] this sounds like a kinda different bug then [06:45] mwhudson: btw, is all the code import spam needed? [06:46] poolie: the one I pastebinned earlier definitely failed [06:46] I will reinstate that test [06:47] lifeless: unclear, i guess [06:48] it's probably not necessary for _you_ to get it :) [06:49] mwhudson: well, if you think about queue management, if the queue is centralised and gui managed, telling all the operators of the queue on any change is, well, overkill [06:49] 'queue died' is interesting [06:49] lifeless: it should be a feed i guess [06:49] uhm, I guess I mean 'what happend to reporting exceptions' :) [06:50] lifeless: thumper did all the email stuff, blame him [06:50] :-p [06:50] thumper: this is me blaming you [06:58] poolie: ok, have a verified test now [07:01] and mailed [07:02] hmm, it probably wants a couple of lines trimmed, but thats minor [07:02] (cause I just realised I don't use the sha1) [07:29] * spiv ducks out to the shops [07:33] lifeless: http://pastebin.ubuntu.com/15732/ [07:36] which I worked on in the pre-coding time into Picard itself. [07:37] er, sorry :) [08:11] poolie: http://pastebin.com/d47e68554 enjoy [08:25] lifeless: feel free to filter it :) [08:48] thumper: I will but it makes seeing the wheat harder [08:48] night all [09:02] supposing that I have a pair of CVS repositories (one for upstream, one for Debian packaging) and I'd like to migrate them to bzr. Are there any tricks available that might let me do a one-time import and merge? [09:03] slangasek: would suggest importing them separately then merging i guess [09:04] poolie: if my Debian CVS repo happens to be a full-source repo rather than a debian-only repo, am I SOL on that count? :) [09:06] are there any connections, like common tags between them? [09:06] or are they just totally unrelated (but similar) histories? [09:07] I could reconcile the tags between them if that would help [09:15] poolie: so would that help? :) [09:18] sorry, i don't have any good suggestions for how to merge them [09:23] so you were just teasing me? :) [09:24] well, I think I could probably get away with just ignoring the upstream repo altogether, if worst comes to worst [09:24] since upstream is dead :P [09:31] my project wont update due some errors... I got two files with "RM or RN" What do these mean? [09:31] enquest: I'd guess remove and rename [09:32] enquest: see "bzr help status-flags" === thekorn__ is now known as thekorn [09:34] I already did that "RN www/media/admin/js/tiny_mce => www/media/admin/js/tiny_mce.OTHER@" [09:34] no tiny_mce.OTHER@ is there nor tiny_mce [09:34] as I removed them [09:35] night all [09:36] now I get Path conflict: www/media/admin/js/tiny_mce.OTHER / www/media/admin/js/tiny_mce.OTHER [09:37] night all - have a good weekend [11:05] hi all [11:06] trying to push a branch on to launchpad but it keeps failing with an error, can anyone help please? [11:06] $ bzr push lp:~dragffy/grope/dev [11:06] bzr: ERROR: Target directory lp:~dragffy/grope/dev already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway. [11:07] where are the archives of the bzr mailing list? [11:07]