| maxb | Hmm | 00:09 |
|---|---|---|
| maxb | I was going to push 2.3b2 to the beta-ppa | 00:09 |
| maxb | But now I think it would be better if I first figured out how to make bzr selftest run as part of the build | 00:10 |
| maxb | But I'm too sleepy for that, so later. | 00:10 |
| lifeless | mgz: around? | 00:15 |
| thumper | poolie: I've been thinking about the underlying problem | 00:32 |
| thumper | poolie: and I've come up with two repeating problems | 00:32 |
| poolie | ok | 00:33 |
| thumper | 1) we have no initial idea if we are trying a write or read operation | 00:33 |
| thumper | 2) we don't have a clear way to ask "does this exist" without poking the filesystem | 00:33 |
| thumper | by removing the FileNotFound errors | 00:33 |
| thumper | it opened a world of hurt | 00:33 |
| thumper | which stopped being able to push branches | 00:34 |
| thumper | and I can't think of a clean way to get errors out of translatePath | 00:34 |
| thumper | with lead me to think that we should have an earlier check | 00:34 |
| thumper | which can have better "smarts" | 00:34 |
| thumper | I wish we had some smart command that allowed us to say: I want branch "X" for writing | 00:35 |
| thumper | or I want branch "Y" for reading | 00:35 |
| thumper | although even that probably isn't enough | 00:35 |
| * thumper is thinking stacking | 00:35 | |
| thumper | we could then do our smart branch lookup | 00:35 |
| thumper | with clean semantics early on | 00:35 |
| poolie | i agree specifying that earlier would be good | 00:36 |
| poolie | it would also let us give a better message on http | 00:36 |
| * thumper nods | 00:36 | |
| lifeless | what are the contracts and constraints of translatePath ? | 00:36 |
| thumper | lifeless: well... | 00:36 |
| thumper | lifeless: probably best talked through if you're willing | 00:37 |
| poolie | what do you mean by "without poking the filesystem"? | 00:42 |
| peitschie | jelmer: are you around atm? | 00:44 |
| jelmer | peitschie: yep | 00:44 |
| peitschie | jelmer: cool. a quick query, I'm recreating our svn repo from scratch, but want to preserve the history from the existing bzr branches.... is fetch ghosts likely to reintroduce any history issues? | 00:45 |
| peitschie | jelmer: or is there a better way to get the bzr history linked up in the new repository? theres quite a few branchs (~400 i think...) so manually is a little bit painful :) | 00:46 |
| peitschie | jelmer: a bit more context might help for you... specifically, we've encountered bug #485601 again... I didn't create the new repo last time as suggested so am doing it now :) | 00:48 |
| ubot5 | Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601 | 00:48 |
| peitschie | jelmer: argh... realised that missed some vital joining bits as well! What I *mean* to say, is I am creating a new bzr shared repo from the existing svn trunk | 00:52 |
| jelmer | peitschie: yeah, fetch ghosts should do the right thing in that case | 00:52 |
| peitschie | jelmer: cool! that will make this a lot less painful than I feared | 00:53 |
| poolie | thumper: i'd like to see a bug saying what the behaviour ought to be case by case | 00:54 |
| peitschie | jelmer: oh... that was a fun experience | 00:55 |
| peitschie | jelmer: I can't fetch ghosts... as this encounters bug #485601 again | 00:55 |
| ubot5 | Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601 | 00:55 |
| jelmer | :-( | 00:55 |
| peitschie | i suppose that makes sense... lol... now just gotta find a way to fool things... | 00:55 |
| peitschie | hmm... there seems to be a specific checkin that has poisoned the broken repo | 01:00 |
| peitschie | as soon as I attempt to pull any branch across that references this broken rev, things go dodgey | 01:00 |
| peitschie | awww... i scared jelmer off :( | 01:01 |
| peitschie | jelmer: if I can hunt down the exact svn checkin that causes this rev error... would that be of any assisstance with the missing chk nodes bug? | 01:01 |
| jelmer | peitschie: I'm not sure - didn't somebody (you?) already post a script for reproducing the chk node bug? | 01:03 |
| GaryvdM | Yhea - Productive night for me. - Goodnight all... | 01:03 |
| peitschie | jelmer: I haven't been able to yet. I posted some more thoughts about it... but I keep struggling to be able to reproduce | 01:03 |
| jelmer | g'night Gary | 01:03 |
| peitschie | jelmer: i'm pretty much shooting in the dark with the latest one, as I spent ages the other night trying various permutations to try and get the crash. I've posted up on that bug the exact workflow we use essentially... but haven't been able to narrow down why it works 99% of the time | 01:05 |
| peitschie | jelmer: bzr-svn is frustratingly stable sometimes :D | 01:05 |
| jelmer | peitschie: a way to reproduce the chk node bug or even a public repository that demonstrates the issue would be a big help. | 01:07 |
| jelmer | peitschie: unfortunately this is a combination of a bzr-svn and a bzr bug; bzr (imho at least) shouldn't be giving an exception this low in the stack, it should give a sane exception when called with invalid parameters. | 01:08 |
| jelmer | peitschie: and of course bzr-svn is at fault for calling it with invalid parameters in the first place. | 01:08 |
| peitschie | jelmer: i know! (programming is my day job too... without reproduction steps it's usually a lost cause) problem is I don't know what I'm looking for really. I can verify which part of the check is failing on the insert, and have dabbled with dropping break-points in various spots to see the stack... but my knowledge of bzr is lacking heavily | 01:08 |
| peitschie | jelmer: that would correlate with my impressions too... this is a joint bug of some type. I can make the exception throw out the chk node it's complaining about... but don't know what to do with it from there. That is why I was wondering if potentially identifying the file/commit/? that this is related too and comparing this to the svn properties or similar might give some hints? | 01:10 |
| peitschie | jelmer: of course... i'm still hopelessly unbazaared so have been lurking here for help | 01:11 |
| jelmer | it should be possible to convert the chk node back to the related file id | 01:14 |
| jelmer | I need to get some sleep though.. I'm usually around during Australian mornings, or perhaps one of the other bzr devs can help debug. | 01:15 |
| spiv | jelmer: g'night! | 01:17 |
| peitschie | jelmer: fair enough :). Thanks for your help! sleep well | 01:17 |
| spiv | Hmm, I suppose my chk-used-by hack could be extended to look at more than just root keys. | 01:17 |
| jelmer | spiv: hi and goodnight (-: | 01:17 |
| spiv | :) | 01:17 |
| peitschie | spiv: would you have some time to give me a hand again? I've recreated a clean repo from svn trunk, and am trying to branch history across to the new repo... but keep hitting the same chk nodes issue | 01:18 |
| spiv | peitschie: hmm, what can I do though? Extend chk-used-by to look at more than just root nodes? | 01:24 |
| peitschie | spiv: thas pretty much all I was hoping for if you could :) | 01:25 |
| peitschie | oh... wait... thats a little cool | 01:26 |
| peitschie | if i fetch the right revision set, I get "Cannot add revision(s) to repository: missing referenced chk root keys" | 01:26 |
| spiv | peitschie: ah! | 01:28 |
| spiv | peitschie: that's good :) | 01:28 |
| peitschie | spiv: if I branched an svn branch that suffered from bug #522637... would bazaar automatically recover from that bug on the way through the branching? or will I then need to reconcile the repo afterwards...? | 01:28 |
| ubot5 | Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 89)" [Low,Triaged] https://launchpad.net/bugs/522637 | 01:28 |
| spiv | peitschie: 'bzr branch' won't usually automatically correct that | 01:29 |
| spiv | peitschie: but is the source branch an svn branch? | 01:29 |
| peitschie | spiv: yes. The "Central" source control is svn, so that has trunk. So what I did was branch straight from that trunk again. I'm wondering though if the revision data bzr is finding in there is incorrect tho... and so I am essentially creating a freshly broken repository | 01:31 |
| spiv | peitschie: ok, that's very interesting | 01:31 |
| peitschie | spiv: running the chk-used-by i have now gotten 3 revisions in the broken one that use it | 01:31 |
| spiv | peitschie: because AFAIK bzr-svn is causing CHK records to be created on the fly (because the underlying SVN repo doesn't use that) | 01:31 |
| spiv | peitschie: which version of bzr itself are you using? | 01:32 |
| poolie | hi spiv | 01:32 |
| peitschie | spiv: we only just upgraded to 2.2.1 in the last few weeks. We've been running on 2.0 & 2.1 for the last 3ish months.... with around 3000 commits to svn in that time... I think roughly 9000 commits to the bzr repo | 01:33 |
| spiv | 2.2.1 is new enough to have the fix to 522637, so it shouldn't be generating non-canonical CHKs that cause the error you just saw. | 01:34 |
| peitschie | spiv: that is correct... but I suspect the bug happened prior to 2.2.1 being released. Looking at this stuff, the bug happened on a commit to svn trunk on sept 1st | 01:35 |
| peitschie | spiv: what I mean by that is the missing sha1 is referenced by that commit at the earliest | 01:36 |
| peitschie | spiv: which happened to be a commit to svn directly, so the network repo would have gotten second hand info about that commit when it updated from svn.... mayb a non-canonical chk was created and inserted along side that revision? | 01:37 |
| spiv | peitschie: hmm | 01:37 |
| spiv | I wouldn't have thought that the SVN repo would be storing references to CHKs at all, though | 01:37 |
| peitschie | spiv: let me go look :) | 01:38 |
| spiv | Because that's an implementation detail of bzr's 2a format | 01:38 |
| spiv | And not something that would make sense to store in SVN, because it has its own mechanisms already to store trees of files. | 01:38 |
| peitschie | i know bzr-svn stores a bunch of properties along with the checkin | 01:38 |
| peitschie | from previous glances it looks like bzr-svn stores enough information to be able to track base revisions and such | 01:39 |
| spiv | Right | 01:41 |
| spiv | The CHK stuff is basically just a storage optimisation, though | 01:41 |
| spiv | It's possible to fully represent the data bzr records without it (just it will tend to be less efficient to do so) | 01:42 |
| spiv | FWIW grepping the bzr-svn source I don't see any obvious sign that it would ever store CHK info in a SVN repository. | 01:43 |
| peitschie | ahh k | 01:43 |
| peitschie | well... the data stored against the rev is things like: | 01:43 |
| peitschie | slidetraytemperature-20100901004344-1c1ttvdesj7oryzv-1 | 01:43 |
| peitschie | 13860@464e02c1-a7d9-0310-851b-f51ca712b586:products%2FBondAdvance%2Ftrunk%2FBond%2FInstrument%2FInstrumentControl%2FController%2FMessageAdaptors%2FHeatersAdaptor.cs | 01:43 |
| peitschie | ahh | 01:44 |
| peitschie | wait | 01:44 |
| peitschie | so it was merged into svn eventually | 01:44 |
| peitschie | but the revision was directly committed to bzr first | 01:44 |
| peitschie | then svn just had the merge committed | 01:44 |
| peitschie | it looks like the referenced chk root key was introduced as part of a merge | 01:46 |
| peitschie | that is... the first time this referenced sha appears is when i merged from svntrunk to my feature branch | 01:47 |
| spiv | Ok, and the bzr repo you are branching into is the same one that has this other bzr branch that has been merged into svntrunk? | 01:48 |
| peitschie | yep | 01:48 |
| peitschie | essentially... we have svntrunk, then a network repo that also has a copy of svn trunk + all feature branches | 01:49 |
| spiv | And this bzr data pre-dates you upgrading to bzr 2.2.1? | 01:49 |
| peitschie | then each dev has a local repo with a bound branch to their feature | 01:49 |
| peitschie | yep... this data pre-dates 2.2.1 | 01:49 |
| spiv | If so, it's fairly likely that following the repair instructions on #522637 will fix it. | 01:49 |
| peitschie | I did run the repair tool for that bug tho | 01:49 |
| peitschie | so this is the repo after that tool has been run across it | 01:50 |
| peitschie | and at this point, if I recreate the local devs repo, they can commit to their feature only until someone checks into svntrunk | 01:50 |
| peitschie | at this point, the dev that committed to svntrunk can continue to commit as per normal, but every other dev hits the missiing chk nodes bug | 01:51 |
| peitschie | (to recreate teh local dev repo, I simply branch the NETWORK bazaar version of svntrunk into a new repository, so the dev gets all the bzr history with their repo) | 01:51 |
| spiv | Did the | 01:52 |
| spiv | repair tool log any lines like "Non-canonical CHK map for ..." in your ~/.bzr.log? | 01:52 |
| spiv | Also, could you elaborate on "at this point" a bit more? | 01:53 |
| spiv | Each dev has their own bzr repo, I assume? | 01:54 |
| peitschie | (i didn't connect that was ur tool btw. i do appreciate all your work here... i'm in awe of the tool you guys have built here) | 01:55 |
| spiv | But as soon as they pull/merge a revision from svntrunk that was committed by another dev using bzr-svn they encounter this bug? | 01:55 |
| peitschie | so.. the setup is as you said | 01:56 |
| spiv | And precisely on which operation do they get an error? | 01:56 |
| peitschie | each dev has their own repo, but the feature branchs are actually bound branches that point to the network one (so we keep things backed up in case an individual pc dies) | 01:56 |
| spiv | (ugh, my grammar is terrible!) | 01:57 |
| peitschie | *usually* the dev will hit this bug when they attempt to merge & commit changes from svn trunk into their feature branch | 01:57 |
| peitschie | e.g., bzr merge ..\svntrunk && bzr commit -m "Merging trunk" | 01:57 |
| peitschie | it will then blow up with bug #522637 at this point, and refuse to commit | 01:58 |
| ubot5 | Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 89)" [Low,Triaged] https://launchpad.net/bugs/522637 | 01:58 |
| spiv | So the merge succeeds, but the commit fails? | 01:58 |
| peitschie | yep | 01:58 |
| spiv | That's extra bizarre :) | 01:58 |
| peitschie | they can then simply throw away the commit, and keep working as normal and committing... but can never get changes in from svn trunk | 01:58 |
| spiv | And they are definitely using 2.2.1? | 01:58 |
| peitschie | i never realised how close bizarre and bazaar sounds until ppl say that all the time in real life lol | 01:58 |
| peitschie | they are now... and the same issue still occurs | 01:59 |
| spiv | Hmm. | 01:59 |
| spiv | What if they run the repair tool (on their local repo *and* the bound repo) between the merge and the commit? | 02:00 |
| spiv | (And does the repair tool log anything about non-canonical chk maps in ~/.bzr.log?) | 02:00 |
| peitschie | due to how long the repair tool takes I haven't tried that | 02:01 |
| peitschie | i checked my logs and the first run of the tool has been lost unfortunately | 02:01 |
| spiv | Yeah, I understand :( | 02:01 |
| peitschie | i was hoping that once the network repo was fixed, each dev then only needs ~30mins to get their working sets back up again | 02:02 |
| peitschie | hmm | 02:02 |
| peitschie | so it appears that either way, teh reconcile has still left this revision hanging in the network repo that causes the missing chk root keys | 02:02 |
| spiv | This is sounding very much like 522637, though, or something closely related. | 02:03 |
| spiv | When you say "network repo", you mean the repo that devs have their branches bound to? Or the SVN repo? | 02:03 |
| peitschie | the one their branches are bound to | 02:03 |
| peitschie | oh wait... i meant to say way prior... the merge works, but the commit actually blows up with bug #485601... not the one i had there | 02:04 |
| ubot5 | Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 13)" [Medium,Incomplete] https://launchpad.net/bugs/485601 | 02:04 |
| peitschie | *but* if I attempt to branch the networked version of svntrunk (this is all bzr only... not svn interaction), I get bug #522637 | 02:05 |
| ubot5 | Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 89)" [Low,Triaged] https://launchpad.net/bugs/522637 | 02:05 |
| spiv | Hmm. | 02:06 |
| peitschie | if it'd help i can draw up a pretty diagram and instructions lol... it is a slightly convoluted workflow to explain :) | 02:07 |
| spiv | Hmm. The distinction between those two errors might not be very important: one is that the root node of a CHK map is missing, the other is that a non-root node is missing. | 02:08 |
| spiv | It's otherwise a sanity check at the same point in the code. | 02:08 |
| peitschie | thats what i started suspecting. dont know if that helps anything much tho | 02:09 |
| spiv | Either way, it suggests that at some point CHK maps are either not being generated correctly (i.e. the wrong nodes), or generated incompletely, or that we are losing nodes during a fetch. | 02:09 |
| spiv | All 3 options should be equally impossible :) | 02:10 |
| spiv | The slightly different errors are certainly interesting, and I think a useful hint. | 02:10 |
| spiv | But I'm pretty sure they are a manifestation of the same root cause. | 02:11 |
| spiv | What's weird is that these checks are run on every write to the repository. | 02:12 |
| peitschie | i'm looking at the earliest rev to reference these and seeing where it came from | 02:12 |
| spiv | So if the merge works, and it does, then the data being pulled across by merge is apparently complete. | 02:12 |
| peitschie | mm... it's not a big merge either | 02:13 |
| spiv | (Not necessarily *correct*, bug 522637 can create data that passes this check but causes trouble for new data generated against the bad data) | 02:13 |
| ubot5 | Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 89)" [Low,Triaged] https://launchpad.net/bugs/522637 | 02:14 |
| peitschie | has 2 revs... 1 rev is a single binary file, second rev is a few sources + a bunch of binary files | 02:14 |
| spiv | Only file modifications | 02:14 |
| spiv | ? | 02:14 |
| peitschie | 1st is a file modification, 2nd are all new files | 02:14 |
| spiv | Hmm. | 02:14 |
| spiv | Ok, at this point I'd really like to know that it's not another case of 522637. | 02:15 |
| spiv | I can't see how, but obviously some assumptions need questioning at this point :) | 02:16 |
| spiv | https://code.edge.launchpad.net/~jameinel/+junk/bzr-check-chk is a plugin that will be useful | 02:16 |
| peitschie | getting it now... | 02:16 |
| spiv | You can give it a range of revisions, and it can tell you if they are broken in a way that reconcile --canonicalize-chks will repair | 02:17 |
| peitschie | range... it works by branch or repo? | 02:17 |
| spiv | Branch | 02:17 |
| spiv | So you can use it to relatively cheaply check if e.g. 'bzr merge' from svntrunk has this corruption. | 02:18 |
| peitschie | i'm running it over the networked repo's trunk at the moment | 02:20 |
| peitschie | then i'll do it in the branch it first appeared in | 02:20 |
| spiv | In fact, it seems to me that if 'bzr merge ..\svntrunk && bzr commit' fails on commit but not merge that it's likely that either the new revisions fetched by 'merge' are broken, or the most recent parents of those are, or one of the recent parents of the current tip you are trying to commit on are. | 02:20 |
| peitschie | that would reflect how it appears to behave | 02:21 |
| spiv | Note that tool is actually slower than 'bzr reconcile --canonicalize-chks' per revision, so it'll only be faster to use it if you give a range of revisions rather than letting it check the whole repo. | 02:21 |
| peitschie | if i then delete the individual dev's repo, and create a brand new clone from the network repo again, the problem goes away... until the next bzr checkin lands in svn that both the dev and the remote repo retrieve | 02:22 |
| peitschie | ok... check-chk on trunk hasn't turned up anything for the revision range where the affected root key was merged in | 02:23 |
| peitschie | i've widened the range to work earlier slightly and am running again | 02:23 |
| spiv | Basically at this point I'd really like narrow down where the corruption is being introduced. | 02:23 |
| spiv | Because so far in isolation all the individual pieces sound fine. | 02:24 |
| peitschie | ahh the fun of complex interactions :) | 02:25 |
| spiv | And e.g. glancing at the bzr-svn source it seems to be fetching revisions from SVN to bzr in a totally reasonable way, so I wouldn't tend to suspect it. | 02:25 |
| spiv | Except that the only people reporting this bug are using bzr-svn... | 02:25 |
| peitschie | i wonder if it is something related to two different repos with slightly different history available coming up with a slightly different revision somehow | 02:26 |
| peitschie | svn would b the key then, because of it's effect on ghosting various parts of teh revision | 02:27 |
| peitschie | under normal bzr operation, the situation doesn't seem quite as common as for bzr-svn | 02:27 |
| peitschie | (the ghosting situation that is :)) | 02:27 |
| spiv | Possibly, yes. I mean, in principle that should be fine! But obviously *something* isn't fine. | 02:28 |
| peitschie | on a side note, are you aware of any tools for generating a bunch of changes for a branch? I've been considering throwing together a fuzzer of sorts so that I can set up a repository and essentially simulate a whole bunch of changes being made... working on the theory that i will eventually hit this again | 02:30 |
| spiv | No, not really. | 02:33 |
| spiv | I mean, we have a perfectly decent API ;) | 02:33 |
| peitschie | oh... that check-chks doesn't work with a branch that has ghosts by the way | 02:33 |
| peitschie | i didn't want to go through the api for fear that it was bzr-svn's use of said api that was doing something "unusual" | 02:33 |
| spiv | Oh, interesting. I guess I can see that. | 02:34 |
| lifeless | well bzr-svn is an implementation of the api | 02:34 |
| lifeless | so its a bit special in that regard | 02:34 |
| peitschie | i can't run check-chk on the clean checkout of svntrunk due to the ghost thing... is there any easy way we can fix that? | 02:35 |
| spiv | peitschie: specify revisions one by one? | 02:36 |
| peitschie | lifeless: thats wat was one of the questions... one of teh bugs is only affecting bzr-svn users, which suggests bzr-svn's usage is a little different from standard bzr somehow... likely in some very subtle way... hence why i'm thinking of fuzzing via the file system directly rather than the bzr api | 02:36 |
| lifeless | peitschie: I think you misunderstand me. | 02:37 |
| lifeless | peitschie: bzr-svn is an *implementation* of the API | 02:37 |
| lifeless | peitschie: its not a consumer of it in the usual sense, at all. | 02:37 |
| lifeless | peitschie: this is what makes bzr-svn glue in so nicely to the core | 02:38 |
| peitschie | lifeless: ahh. sorry :S. gotchya | 02:38 |
| peitschie | spiv: so far it hasn't reported any issues with either the new or old repo | 02:40 |
| spiv | Hmm, I wonder if bzr-svn isn't roundtripping inventories perfectly. | 02:42 |
| peitschie | is there any way to verify that you can think of? | 02:44 |
| * spiv adds a note to the bug while he's thinking of it, so jelmer will see it | 02:46 | |
| spiv | Basically, compare the CHK root keys before and after roundtripping. | 02:46 |
| peitschie | hmm | 02:47 |
| peitschie | i can probably try and branch the revisions just prior to this issue from the broken dir | 02:47 |
| spiv | i.e. make a revision in bzr repo A, commit/push it to the SVN repo, and fetch it into bzr repo B. I suppose if you're seeing this bug, and this theory is right, you already have examples of this. | 02:47 |
| spiv | Then use the bzr APIs to tell you what the CHK root keys for that revision's inventory are in A vs. B. They are supposed to be the same. | 02:48 |
| peitschie | the challenge is finding the exact combination that causes it to break :). things work the large majority of the time... so it is a specific sequence of somethings that does it | 02:48 |
| spiv | You can probably see how to adapt bzr-check-chk or similar to just print the key for a given revision. | 02:48 |
| peitschie | yep | 02:49 |
| spiv | (If this theory is right, then it will pass the 'canonical-form' check, because the bug isn't the layout of the CHK, it's that actual inventory contents for a given revision ID are not the same in the two repos.) | 02:50 |
| peitschie | (all check-chks came back without any issues btw) | 02:56 |
| spiv | Ok, that's good to know. Thanks for that. | 02:56 |
| * spiv -> lunch | 03:05 | |
| peitschie | spiv: let me know wen ur back... i could use a few more pointers :) | 03:32 |
| peitschie | spiv: i found the dodgey rev... now i need to get the details out of it somehow | 04:01 |
| spiv | peitschie: back | 04:04 |
| peitschie | spiv: wb :) | 04:04 |
| spiv | peitschie: oh nice | 04:04 |
| spiv | Tell me more about this dodgy rev! | 04:04 |
| peitschie | spiv: it's rather ... unexpected. the key revision is a pure bzr rev that has stacked on an svn rev | 04:04 |
| peitschie | i don't know how to get other debug info out of it yet... i'm quickly testing checking out these revs against trunk | 04:05 |
| peitschie | once this single bzr rev gets into a branch, every branch from that point onwards shows the missing chk node entry bug | 04:05 |
| spiv | A pure bzr rev in the same repo it was created it? Or a pure bzr rev that has travelled via the svn repo? | 04:05 |
| peitschie | (when i try and branch it into my clean repo) | 04:05 |
| peitschie | pure bzr | 04:06 |
| peitschie | so the dev branched off svn trunk (a rev the repo already had), then performed a checkin to their feature branch (pure bzr) | 04:06 |
| peitschie | i can pull the svn rev into the clean repo | 04:06 |
| peitschie | i cant pull the dev checkin to the repo | 04:06 |
| spiv | "pull the svn rev into the clean repo" -- pull from svn -> bzr, or from the first bzr repo? | 04:07 |
| peitschie | first bzr => second (new clean from svntrunk) bzr repo | 04:07 |
| spiv | Ok. I'd definitely like to know if the chk root keys for that rev in both repos match. | 04:08 |
| spiv | And I assume both the bzr rev and the rev from svn trunk both pass check-chk? | 04:09 |
| peitschie | checking now | 04:10 |
| peitschie | these revs were way outside the range i was checking before | 04:11 |
| peitschie | back in early june sometime | 04:11 |
| spiv | What do the two revs look like in terms of changes? Modifies, adds, deletes? | 04:12 |
| peitschie | the svn rev just prior is adding 2 files | 04:12 |
| peitschie | the first bzr checkin after is deletes & modifications | 04:13 |
| peitschie | check-chks says nothing special for those two | 04:13 |
| peitschie | im currently branching at various trunk revs to see what happens once that revision lands back into trunk | 04:20 |
| peitschie | ag... duh.. thats not gonna help because the new repo has all trunk revs >.< | 04:21 |
| peitschie | ok... whats the best way to get all the info we can about these two revisions that cause the problem? | 04:21 |
| spiv | Modify bzr-check-chk to print the root keys | 04:23 |
| spiv | (even if they pass the check) | 04:24 |
| peitschie | they pass the check without any issues | 04:24 |
| spiv | and then use that to make sure the root keys for those revs are the same in both repos | 04:24 |
| peitschie | ahh... thats gonna b fun | 04:24 |
| peitschie | the second commit is only present in one repo... i can't get it in the other | 04:25 |
| spiv | Hmm, yeah. Well, just check that one. | 04:25 |
| spiv | I think it will match, but I'd like to check my assumptions :) | 04:25 |
| peitschie | sorry it's taking so long | 04:31 |
| peitschie | i've dropped pdb into ther and am trying to find what i want on the inventory :) | 04:31 |
| spiv | inv.id_to_entry.key() and inv.parent_id_basename_to_file_id.key() | 04:32 |
| peitschie | thnx! | 04:32 |
| spiv | I don't suppose you're able to send me a copy of the repo that exhibits the problem? | 04:33 |
| peitschie | its 1.2Gb... so it's a little difficult | 04:34 |
| peitschie | oh... thats not so good i suspect | 04:35 |
| peitschie | shas for the svn checkin in question are different | 04:35 |
| echo-area | Hi | 04:37 |
| echo-area | I'm getting trouble similar to https://bugs.launchpad.net/bzr/+bug/377261 | 04:37 |
| ubot5 | Launchpad bug 377261 in Bazaar ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update" (affected: 5, heat: 21)" [High,Confirmed] | 04:37 |
| echo-area | The difference is that I got different stack backtrace than that bug | 04:38 |
| echo-area | Should I file another bug? | 04:38 |
| peitschie | echo-area: probably a good idea. It is easier to mark a bug as a duplicate than split a bug out :). Make sure you mention the other bug in it as well to make it easier for whoever is checking to see | 04:39 |
| echo-area | peitschie: Okay, I'll do that. Thanks | 04:39 |
| spiv | peitschie: ah, so we are getting close after all! | 04:39 |
| peitschie | spiv: it is starting to look that way a bit. wat next? | 04:40 |
| spiv | peitschie: that probably does explain why the next revision that depends on it can't be fetched | 04:40 |
| spiv | peitschie: if you don't mind sharing some of your data, | 04:41 |
| spiv | peitschie: send me the output of print inv.id_to_entry._dump_tree(True) and inv.parent_id_basename_to_file_id._dump_tree(True) for both | 04:41 |
| peitschie | spiv: i can probably talk to people.. I work at a commercial company so things will need to be a little careful. Whats the easiest way for you to get 1.2Gb...? | 04:42 |
| peitschie | spiv: even better :) | 04:42 |
| peitschie | spiv: so you want that of the rev in question correct? | 04:42 |
| spiv | Yes, and from both repos | 04:42 |
| spiv | The output will, I hope, be different :) | 04:42 |
| spiv | And actually, it'd be great if you can send me the output for the parent revision (or revisions?) of that rev-from-svn too. | 04:46 |
| peitschie | yep... so you want the rev that breaks things, and it's parent rev in both sides? | 04:46 |
| peitschie | is 7zip ok for the file? It's way smaller than zip... | 04:47 |
| spiv | I *think* so. bzip2 is also good. | 04:50 |
| poolie | spiv, there is a 7z in ubuntu | 04:50 |
| peitschie | spiv: I'm attempting to send it now... i'm behind a proxy tho, so if this fails i can email it | 04:51 |
| spiv | email is fine, andrew.bennetts at canonical.com | 04:52 |
| spiv | My IRC client says 'DCC unknown ctcp XXXX from peitschie ...' | 04:52 |
| spiv | So I guess that's not going to work :) | 04:52 |
| peitschie | yups :)... emailing now | 04:54 |
| peitschie | it's sent | 04:54 |
| spiv | Thanks! | 04:54 |
| peitschie | now heres to hoping it's useful in some way... | 04:55 |
| spiv | Received ok, I think this is going to be helpful | 05:01 |
| spiv | What is r4686 is the rev from svn? | 05:01 |
| peitschie | thats the one that magically starts breaking things | 05:02 |
| peitschie | so i have a checkin on a branch just past that point, which i cannot branch into my "clean" bzr repo | 05:03 |
| peitschie | that reminds me, do you want the info from the checkin just past 4686 as well? | 05:03 |
| spiv | So interestingly 4685 differs in both revs too | 05:04 |
| peitschie | i've been chasing those back... | 05:05 |
| spiv | er, in both *repos* | 05:05 |
| peitschie | they were differening back to the first bzr checkin made | 05:05 |
| peitschie | so up until the first checkin, it's all identical. once the first checkin was made, the files immediately start differing | 05:05 |
| spiv | The inventories have the same files and directories, with the same IDs, with the same contents and the same lengths and the same executable bits... | 05:06 |
| spiv | *but* some of those files and directories have different revision IDs | 05:06 |
| peitschie | i thought so | 05:06 |
| spiv | Which is the inconsistency that is causing all your trouble.s | 05:07 |
| spiv | So, how precisely were these two repositories created? | 05:07 |
| peitschie | so... repo 1 (broken) was created with a check out of the entire svntrunk | 05:08 |
| peitschie | that then served as our network repo since then (early june) | 05:08 |
| peitschie | repo 2 was created by rechecking svntrunk out a few days ago... that has had no other use at this point | 05:08 |
| peitschie | as soon as the first bzr checkin is made to the repo, the bzr info that i'm dumping changes | 05:09 |
| spiv | peitschie: hmm! | 05:10 |
| spiv | So adding a new bzr revision to the SVN repo is causing future bzr checkouts from that repo to get different results for old revisions? | 05:11 |
| peitschie | it is looking like it! | 05:11 |
| peitschie | i am wondering... we got bitten by https://bugs.launchpad.net/bzr-svn/+bug/587819 ages ago | 05:11 |
| ubot5 | Launchpad bug 587819 in Bazaar Subversion Plugin "race condition when doing a bzr commit to an svn repo (dup-of: 515850)" [Undecided,New] | 05:11 |
| ubot5 | Launchpad bug 515850 in Bazaar Subversion Plugin "Revisions added while a commit is happening are ignored (affected: 4, heat: 23)" [High,Triaged] | 05:11 |
| peitschie | i had to manually delete all bzr revision properties from the svn history | 05:12 |
| peitschie | i wonder if someone forgot to delete their svn cache prior to a checkin... | 05:12 |
| peitschie | and if that might have poisoned the stack | 05:12 |
| spiv | peitschie: ooh, sounds messy! | 05:14 |
| spiv | peitschie: that sounds plausible | 05:15 |
| spiv | peitschie: I'm out of my depth on that degree of SVN-fu, though. | 05:15 |
| spiv | peitschie: I think at this point we need jelmer for further diagnosis | 05:15 |
| peitschie | spiv: i suspected we were hitting that point as well :) | 05:15 |
| spiv | I've added some more comments to the bug. We're definitely much much closer now, thank you very much for your persistence. | 05:16 |
| spiv | And patience :) | 05:16 |
| peitschie | it's a pleasure :).. i like working with you guys | 05:16 |
| peitschie | with those dumps that I sent... I dont mind if you pass them out to a dev or too.. just make sure they don't get too far out of ur sight please :) | 05:16 |
| spiv | Ok, I'll pass them onto jelmer as well | 05:17 |
| spiv | You should probably add a bug comment with the suspicions about svn caches and deleting old bzr rev props | 05:17 |
| peitschie | yep... will do | 05:19 |
| peitschie | if it is related to that... that took a scarily long time to bite :S | 05:19 |
| peitschie | spiv: wb :)... another quick query... is it worth me doing a check-out of svn using an older version of bzr (2.0 or 2.1) to see if that is different too? | 05:37 |
| spiv | Hmm, I don't think so. But then I still don't quite know what's going wrong, so what would I know? :) | 05:38 |
| peitschie | hehe... i know that feeling :S | 05:39 |
| peitschie | i'll hold off then and see how far jelmer can get on wat we've given him | 05:39 |
| peitschie | thanks again for all your help digging that out... It would have taken me all week to do that without your guidance! | 05:39 |
| spiv | If my own experience with these bugs is any guide, longer probably ;) | 05:43 |
| peitschie | aint that the truth... it scares my poor little mind thinking about it :S | 05:44 |
| === IBZ is now known as jfroy | ||
| mgz | lifeless: I'm around now if you're still after me. | 06:23 |
| lifeless | mgz: yeah, you fixed timing data from parallel stuff | 06:24 |
| lifeless | I was wondering if any of that was still in bzrlib, or if its all in testtools nows | 06:24 |
| mgz | it's moved to testtools basically. | 06:25 |
| mgz | https://code.launchpad.net/~gz/bzr/use_testtools_timings_625594/+merge/36784 | 06:25 |
| mgz | that's the bzr mp that does it. | 06:25 |
| lifeless | thanks | 06:29 |
| vila | hi all ! | 07:06 |
| vila | poolie: did you get an email for the shortcuts failures ? Can I have a copy ? | 07:07 |
| mgz | vila: yes, lp:~gz/bzr/escape_selftest_console_output_633216 depends on a non-broken-with-unicode testtools version | 07:08 |
| vila | poolie: regarding the http tests, the code is not called because the http client coalesce the offsets. The tests need to be tweaked to avoid that, but doing so led to a hang when I briefly tried yesterday. Why it hasn't been noticed before is... unfortunate :-/ | 07:08 |
| mgz | and I'd like to see the failure spiv got with it as well. | 07:08 |
| vila | mgz: yup, hence my ping in the review comments | 07:09 |
| vila | spiv: ^ | 07:09 |
| vila | poolie: and to avoid problems, please send this mail to my canonical address | 07:10 |
| vila | poolie: I reported the problem to my ISP but I'm not holding my breath, *one* postmaster for millions of users to handle false positive spams... hmmm, does it blend^W scale ? | 07:11 |
| mgz | should make pqm post a summary to the mp | 07:11 |
| poolie | hi vila, i did get a failure mail | 07:12 |
| poolie | vila: sent | 07:12 |
| poolie | mgz we should use tarmac | 07:12 |
| mgz | or that. | 07:12 |
| poolie | vila, i'm also reviewing your config mp | 07:12 |
| poolie | or, at least, work out why not to use it | 07:12 |
| poolie | vila, well, it's nice we noticed now | 07:13 |
| vila | poolie: noticed what ? | 07:14 |
| poolie | noticed the http test wasn't reached | 07:14 |
| vila | ha, yes, we may just get rid of the tests, they try to ensure a pretty unlikely regression and the hang may be a real bug in the test server | 07:16 |
| vila | poolie: if you can't "work out why not to use it" I'd be happy to land it and work on the *next* steps ;) | 07:25 |
| vila | poolie: ok, got the PQM failures mail. That's insane, what the hell is different on the pqm instance... | 07:28 |
| poolie | vila, i meant either use Tarmac or get a good idea why not | 07:33 |
| poolie | but maybe not today | 07:33 |
| vila | poolie: did Tarmac allows running the test suite before landing ? | 07:34 |
| poolie | it should | 07:34 |
| poolie | i haven't tried this week | 07:34 |
| vila | ok | 07:34 |
| poolie | i mean i haven't tried yet; i hope to try this week or next week before UDS | 07:34 |
| poolie | have you touched fastimport at all? | 07:35 |
| vila | never | 07:46 |
| vila | hmm, at least nothing I can recall, I may have fixed some test failures though ;) | 07:47 |
| lifeless | PQM has code to comment on the MP | 07:57 |
| lifeless | and rockstar has overhauled the API - a small tweak to use the new API next week, and it should be usable. | 07:58 |
| lifeless | using tarmac would be good too | 07:58 |
| lifeless | poolie: I've merged your testscenarios patch; it needed a little tlc to be up to your normal standards, so I did that as I merged. | 07:59 |
| poolie | thanks, i saw | 08:00 |
| poolie | vila, are there any unit tests for urllib2_wrappers? | 08:00 |
| poolie | nm, i can grep | 08:01 |
| GaryvdM | Morning all. | 08:02 |
| lifeless | poolie: if you want to depend on testscenarios, I'd be delighted to do a release of it for you | 08:03 |
| vila | poolie: I don't think so. For historical reasons, I always wrote tests against both _pycurl.py and _urllib.py | 08:13 |
| vila | poolie: thanks for the review ! | 08:32 |
| vila | poolie: note that s/from fnmatch import fnmatch/import fnmatch/ is actually a genuine case where it's *required* I need to access *another* symbol in the module ! | 08:33 |
| poolie | lifeless: i wouldn't mind | 08:35 |
| poolie | it's not very compelling at the end because we have the equivalent in hose | 08:35 |
| poolie | *house | 08:35 |
| poolie | the main thing i would like to do would be to clean up ad-hoc parameterization by subclassing | 08:35 |
| poolie | unfortunately it's a bit hard to grep for | 08:35 |
| lifeless | poolie: grep -i 'base|mixin' tests ? | 08:41 |
| poolie | that'll be close, also for xxx comments | 08:41 |
| poolie | if they can all be cleaned up in a good way that'd be quite a positive step | 08:41 |
| poolie | probably no reason why they can't be | 08:41 |
| poolie | well, positive for the code and good validation of scenarios | 08:42 |
| lifeless | yes, OTOH you could in principle delete the in-tree copy eventually :) | 08:44 |
| lifeless | I'll see about a release this weekend or so | 08:44 |
| poolie | i'd kinda like to delete the in-tree copy | 08:46 |
| poolie | i wonder, empirically, how much pain do dependencies cause for packagers? | 08:46 |
| poolie | vila, i pushed my branch, i'm curious what you think of the tests | 08:49 |
| vila | poolie: tests are nice | 08:53 |
| vila | poolie: as for the fix... I don't understand why 'port' is not set in auth... istm it should in which case your fix is not in the right place, but ibmw | 08:54 |
| vila | poolie: it's especially weird that you create the auth *section* with port, but still get no port in the auth entry | 08:55 |
| vila | poolie: may be I just don't remember the code path well enough anymore :-/ | 08:57 |
| vila | poolie: ha, right, you explained that clearly in the cover letter, sorry, went straight for the diff | 08:57 |
| vila | poolie: I replied to your config review and need additional answers to progress :) | 09:06 |
| poolie | thanks for that | 09:11 |
| vila | poolie: I've approved you mp for the auth password (port really) and I'm now changing my hat to RM and will announce 2.3b2 | 09:12 |
| vila | poolie: we have installers for OSX and windows ready and maxb is working on the beta ppa (activating the test suite run AIUI) so it should be ready soon too | 09:13 |
| vila | maxb: Did I get this right ? Do you need help there ? | 09:13 |
| poolie | thanks vila | 09:28 |
| maxb | vila: Aaaaaaaaaaaaaaaaaaaagh. Why? WHY!? WHY is bzr packaged using cdbs!??! | 09:45 |
| poolie | night all | 09:45 |
| maxb | (I just looked at the debian/rules and cried) | 09:45 |
| vila | maxb: excuse my Klatchian, but what is cdbs ? | 09:46 |
| maxb | on the plus side, it appears there is a test invocation already in there, but disabled | 09:46 |
| maxb | cdbs is an evil monstrosity that results when someone thinks it's a good idea to build an extensible class library of Makefile fragments | 09:46 |
| maxb | for debian package building | 09:46 |
| maxb | Well I'm just going to ignore that and pray just toggling the conditional works :-) | 09:48 |
| vila | hehe, sounds like a plan ;) | 09:48 |
| aboeing | hi. does anyone know how to insert a revision string into source code from bzr? | 10:06 |
| aboeing | for example, after a commit, set a variable REVISION_STRING = 1234 | 10:07 |
| lifeless | the feature used to do that is 'filters' | 10:11 |
| aboeing | lifeless: thanks, would you have an example of this? | 10:11 |
| lifeless | have a look on the plugins page | 10:12 |
| lifeless | there's at least one filter there - the end of line one, for windows users. | 10:12 |
| aboeing | Thanks, found this which looks like what I need: https://launchpad.net/bzr-keywords | 10:21 |
| inge | Dear Members of bzr channel, we have a problem with bzr and file system access I wonder if anybody can help. | 11:20 |
| inge | The repositories are located at a server which is mounted to a directory any user can internally access, this is /home/bzr. | 11:21 |
| maxb | It's always best to actually ask a technical question rather than asking to ask. it lets people gauge whether they have relevant experise. | 11:21 |
| maxb | * expertise | 11:21 |
| inge | Anytime I do a bzr co --lightweight /home/bzr/REPOSITORY the bzr command will not return. I can only kill the shell but the bzr process still exists as a zombie and locks a file in the repository "dirstate" | 11:22 |
| inge | Our assumption is that it could have something to do with NFS4 we migrated to lately, does anybody know something about it? | 11:25 |
| mgz | if you ctrl+\ where is the process stuck at? | 11:25 |
| mgz | blaming nfs is probably right. | 11:25 |
| inge | ctrl+\ does not do anything | 11:26 |
| Kamping_Kaiser | inge: what were you usinb before you put in nfs? | 11:29 |
| inge | we where using nfs3, no problems then | 11:30 |
| inge | I was trying to attach to the bzr process with gdb but that doesn't work. | 11:31 |
| inge | Am I the only one with this problem? | 11:33 |
| mgz | feel free to poke around on the bug tracker, nothing springs to mind though] | 11:35 |
| mgz | you might find it useful to add a break point earlier in the process then step through to work out where the hard hang is happening | 11:36 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | 2.3b2 is officially released, test it ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| vila | inge: yes, there are known issues with nfs4 | 11:48 |
| vila | inge: well, known may be a bit optimistic, the problem AIUI is that we don't understand what is happening, but the suspicion is against nfs | 11:48 |
| vila | inge: but the 'dirstate' file is part of the working tree, it shouldn't be in the repo | 11:50 |
| vila | inge: may we don't assign the same meaning to repo here... | 11:51 |
| vila | inge: thinking more about it, the problem I'm aware of related to nfs4 is about OS locks, which are only used for the dirstate files, so if your working trees are *not* accessed via nfs, i.e. only the branches and their repos, then you should be fine | 11:57 |
| vila | inge: I'm about to leave for a lunch break, but I'll read and answer your questions if needed when I'll be back | 11:58 |
| inge | vila: I meant the dirstate file in the branch, e.g.: REPOSITORYNAME/.bzr/checkout/dirstate, this is I think part of the branch. The working trees are not affected by this problem, nor are the update or commit commands. | 12:17 |
| vila | inge: checkout/ is what defines a working tree, do you *need* a working tree there ? | 12:21 |
| inge | I think your suspicion with OS locks could be true, checking out first runs normally, only at the end, maybe some finishing operation, it hangs. | 12:22 |
| inge | vila: I am a bit confused about the checkout/working tree stuff. Just to explain our setup: We have a central branch/repository on a server A, there only the .bzr directories exist. From the other computer e.g. mine I do e.g. a checkout --lightweight to get a cvs like copy of the current files. So no working tree on the server, only at my personal computer. | 12:24 |
| vila | inge: right, so: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief | 12:25 |
| vila | inge: from what you're describing, REPOSITORYNAME/.bzr/checkout/dirstate shouldn't *exist* so we need to find why it's there and get rid of it | 12:26 |
| vila | inge: can we do that in1/2 hour ? (I didn't get really get this lunch break ;-) | 12:27 |
| inge | Yes of course, I will wait. | 12:27 |
| vila | cool, read this url above, I find it quite good at helping us talk about the same things with the same words | 12:28 |
| inge | I am already reading | 12:28 |
| fullermd | Oh look, bzr ls doesn't take multiple args. | 12:50 |
| vila | fullermd: what a shame, file a bug ;) | 13:05 |
| vila | inge: I'm back | 13:05 |
| inge | me too, had to reboot, to many zombies | 13:05 |
| vila | err, which one of you is really you ? ;) | 13:06 |
| vila | ha ok | 13:06 |
| inge | sorry, double entry on notebook | 13:06 |
| vila | so, basically in the end, you need to: 'bzr reconfigure --no-tree' while logged on the server, but I'd like to understand how you end up there | 13:06 |
| vila | err, --with-no-trees | 13:07 |
| inge | I don't know if that really is the problem, but I think I have repository and branch in the same location | 13:07 |
| vila | inge: it's ok, it's what we call standalone branches as opposed to branches using a shared repository | 13:07 |
| vila | inge: if you have several branches related to the same project, it's generally best to use a shared repo | 13:08 |
| inge | I migrated the repositories from cvs using tailor, then multiple branches where generated and cross merging, maybe something went wrong then. | 13:08 |
| vila | my guess would be that someone has been working on the server and used working trees there | 13:08 |
| inge | Yes that's what we are in general doing. | 13:09 |
| inge | Your guess could be true. From time to time I find some files next to the .bzr directory on the server. The guy the files beling to says he is only working in his working tree, not on the server. | 13:10 |
| inge | Any idea about that? | 13:10 |
| vila | it's a bit unclear but I suspect some operation on the lightweight checkout *also* update the remote working tree | 13:11 |
| inge | bzr: ERROR: Requested reconfiguration of '/home/bzr/trunk/MIP/' is not supported. | 13:11 |
| vila | on the server ? | 13:11 |
| vila | ha, right, sorry, that should be 'bzr reconfigure --branch' | 13:12 |
| inge | yes, I am on the server with ssh | 13:12 |
| vila | that will remove the working tree too | 13:13 |
| vila | hmm, check for uncommitted changes first maybe :-} | 13:13 |
| vila | but the command should do that hopefully | 13:13 |
| inge | okbzr: ERROR: Working tree "/home/bzr/trunk/MIP/" has uncommitted changes (See bzr status). | 13:13 |
| vila | :) | 13:13 |
| vila | pfew | 13:14 |
| inge | yes uncommitted chages, status shows 100 conflicts with files that are not there, I will need a moment to figure that out | 13:14 |
| vila | hmm, most probably accumulated cruft | 13:15 |
| vila | if you can confirm that, 'bzr revert --no-backup' will restore a pristine working tree | 13:15 |
| vila | but don't use --no-backup if you're unsure | 13:16 |
| inge | what about the subdirectories in .bzr, checkout and branch, can I delete them? | 13:17 |
| vila | no | 13:17 |
| inge | I am unsure about the --no-backup, I don't want a working tree there but a clean repository with no branch and no working tree | 13:18 |
| vila | never touch anything under .bzr/ unless told otherwise :) The only exception being .bzr/branch/branch.conf but even for that we're working on providing a command to edit it | 13:18 |
| vila | inge: the --no-backup is to restore a clean working tree so you can do 'bzr reconfigure --branch' which will delete .bzr/checkout | 13:18 |
| vila | err, and you want a lean *branch* with its own private repository | 13:19 |
| vila | *clean | 13:19 |
| vila | unless you also want to use a shared repository for multiple branches but we can look into this later | 13:19 |
| vila | or unless you are already using a shared repository and suddenly get a branch and a working tree there in which case I misunderstood | 13:20 |
| inge | Yes I want a shared Repository, and I got this branch and working tree in there. Think it was not created correctly by tailor, or we messed it up during merges | 13:25 |
| === zyga is now known as zyga-break | ||
| inge | vila: ok I went to all repositories and did bzr reconfigure --branch --force and now the checkouts etc. work, no hangs anymore so far | 13:59 |
| inge | vila: thank you very much for your help. | 14:00 |
| vila | inge: great ! | 14:01 |
| vila | inge: if you encounter again some weird combination that ends with a remote working tree, please file a bug with a reproducing recipe ! | 14:01 |
| inge | Ok I will, but this time I really don't know how to reproduce that | 14:02 |
| vila | sure, no problem | 14:02 |
| === zyga-break is now known as zyga | ||
| poolie | GaryvdM, hi? | 14:37 |
| jam | morning vila, hey poolie | 14:56 |
| poolie | hi there jam | 14:56 |
| poolie | that's a bad sign :) | 14:56 |
| vila | hey jam | 14:56 |
| vila | poolie: :) | 14:56 |
| jam | poolie: I was thinking the same thing | 14:57 |
| jam | I shouldn't see vila wake up, and you shouldn't see me come online | 14:57 |
| jam | though you were saying you wanted to see me around more :) | 14:57 |
| poolie | good night vila, jam | 15:13 |
| GaryvdM | Hi jam | 15:14 |
| vila | poolie: good night ;) | 15:15 |
| jam | sleep well poolie | 15:15 |
| jam | hey GaryvdM | 15:15 |
| === zyga is now known as zyga-afk | ||
| cbz | trying to use bzr on windows can't find a set of options that will print out the full content of the file with changes | 15:35 |
| cbz | Tried bzr --diff --using=/path/to/gnu/diff --diff-options="-iwb -U 100000" - but it only shows the limited section around the changes | 15:35 |
| cbz | any ideas? | 15:39 |
| GaryvdM | cbz: I think you are probably looking command line solution. For that I have no idea, but if you open qdiff, and select Unidiff, and Complete, it will give you that. | 15:48 |
| trashbird1240 | I'm trying to migrate a repository from hg to bzr | 15:52 |
| trashbird1240 | I've used fastimport and everything appears to have worked, but how do I update my working tree or create a branch? | 15:53 |
| trashbird1240 | I've followed http://wiki.bazaar.canonical.com/BzrMigration#Mercurial%20%28hg%29 | 15:53 |
| === deryck is now known as deryck[lunch] | ||
| === zyga-afk is now known as zyga | ||
| === zyga__ is now known as zyga | ||
| === deryck[lunch] is now known as deryck | ||
| sender | jelmer: you there? any news on the bzr-svn bug that we spoke about last week? :) | 17:21 |
| jelmer | sender, hi | 17:34 |
| jelmer | sender, I remember talking with you about it but I don't remember which bug that was. Do you have the bug #? | 17:35 |
| jelmer | sender, I should be able to have a look at it after I finish my work day. | 17:35 |
| vila | jelmer: it seems that bzr-svn and bzr-rewrite needs an API bump to be used with 2,3b2 anf trunk | 17:46 |
| vila | abentley: bzr-pipeline and probably bzrtools as well | 17:46 |
| jelmer | vila: that's already happened | 17:47 |
| jelmer | vila: are you sure you're using the respective trunks? | 17:47 |
| vila | jelmer: not me someone on the ML | 17:48 |
| vila | I thought he said he get latest versions, may be it's not running from source... | 17:48 |
| jam | vila, jelmer: I think he's using a ppa, and got the latest bzr but not updated plugins | 17:49 |
| GaryvdM | vila: the only plugin that is in the windows installer that has not been bumped in it's trunk is pipeline. | 17:50 |
| vila | jam: meh, which ppa then ? The beta one still propose 2.3b1 | 17:50 |
| jam | then again, he says "I'm trying this new release" so he certainly could be running bzr 2.3b2 from source but all plugins from the system | 17:52 |
| jam | /usr/local/lib/... makes it sound like he ran "setup.py install" at least | 17:52 |
| GaryvdM | Maybe a debian user? | 17:53 |
| maxb | Language in that email makes me think he is running setup.py install from *source tarballs* | 17:56 |
| === beuno is now known as beuno-lunch | ||
| maxb | Can anyone think of an easy way to figure out if bzr selftest is loading compiled extensions or not? | 18:03 |
| roryy | i get a warning if i don't have compiled extensions, fwiw | 18:06 |
| maxb | Normally yes. But I think bzr selftest might be different | 18:07 |
| jam | maxb: you can check the features themselves, and the end of the selftest tells you "X tests not running because of features ..." | 18:13 |
| jam | GaryvdM: he was also clear that he was running Ubuntu | 18:13 |
| GaryvdM | oh - I missed that... | 18:14 |
| vila | maxb: selftest is no different, I see a warning everytime I run without extensions | 18:27 |
| maxb | hmm. Then, either I'm lucky and magically the right thing is happening, or ./bzr is picking up the compiled extensions from my system bzrlin | 18:27 |
| maxb | *bzrlib | 18:27 |
| vila | maxb: I dunno what you are trying to do, but I have a bzr installed and running './bzr' warns | 18:29 |
| maxb | I was briefly testing how to run the selftest inside the debian package build | 18:29 |
| vila | maxb: 'make check' ? | 18:30 |
| maxb | There was existing code in the debian/rules to do ./bzr selftest --no-plugins, | 18:30 |
| vila | maxb: or 'make check-nodocs' | 18:30 |
| vila | ha | 18:30 |
| vila | may be it's triggered after the extensions are built ? | 18:30 |
| vila | that would makes sense | 18:31 |
| maxb | it was triggered before they were built. It still didn't warn in my local test | 18:31 |
| vila | make clean should get rid of the existing ones | 18:31 |
| maxb | Anyway, I decided that I need to leave shortly so I threw a best-guess into the bzr-beta-ppa for the builders to chew on | 18:31 |
| mtaylor | w00t! new bzr error I've never seen! | 18:34 |
| mtaylor | oh - nevermind | 18:34 |
| vila | mtaylor: go ahead, we love enthusiastic bug reports ! ;) | 18:34 |
| mtaylor | vila: $ bzr branch lp:drizzle/elliot | 18:35 |
| mtaylor | bzr: ERROR: Permission denied: "Cannot create 'elliot'. Only Bazaar branches are allowed." | 18:35 |
| maxb | heh, that's changed from earlier today | 18:35 |
| mtaylor | well - in _this_ case, lp:drizzle/elliot isn't valid - it should have been lp:drizzle/elliott | 18:36 |
| vila | mtaylor: oh yeah, it's a lp one, never made sense to me either | 18:36 |
| mtaylor | the error message should be "you're an idiot - learn to spell!" | 18:37 |
| vila | maxb: grrrrrr no module named testtools... | 18:37 |
| maxb | oh. duh. obviously | 18:38 |
| vila | maxb: you need it to run the tests, I should have thought about it and warned you | 18:38 |
| maxb | If I'd actually thought about it, or tested in a chroot, I would have realized | 18:39 |
| === beuno-lunch is now known as beuno | ||
| === Ursinha is now known as Ursinha-afk | ||
| jelmer | sender, still there? | 21:15 |
| rubbs | is there a reference to all the branch aliases? I created a branch and pushed it to our central server, now I want to bind the one I pushed from to the one I pushed too. What's the easiest way to do that? | 21:25 |
| jam | rubbs: bzr bind :push ? | 21:25 |
| jam | bzr help location-alias | 21:25 |
| rubbs | jam: that did it thanks. | 21:25 |
| rubbs | ah, awesome that's exactly the help entry i was looking for | 21:26 |
| slangasek | if a remote branch is stacked on a branch which has been moved, how can I make bzr look at the new location instead? | 22:04 |
| slangasek | (case in point: lp:~chessy/live-build/live-helper.chessy, and lp:~vcs-imports/live-helper/trunk/ vs. lp:~vcs-imports/live-build/trunk/) | 22:05 |
| jelmer | slangasek: Hi | 22:05 |
| * slangasek waves :) | 22:05 | |
| jam | slangasek: edit .bzr/branch/branch.conf to reference the new location? | 22:05 |
| jelmer | slangasek: I think "bzr reconfigure --stacked-on=<new-url>" <branch-url> should do that | 22:05 |
| mwhudson | slangasek: use lftp to edit .bzr/branch/branch.conf | 22:05 |
| slangasek | ah, but I don't have commit access to the remote branch :) | 22:06 |
| mwhudson | find someone who does :/ | 22:06 |
| jam | hey mwhudson, just checking what the next step for the forker service is. you mentioned pqm being frozen, and I don't really know when to remind you to try and land it again. | 22:06 |
| slangasek | lool: ping ;) | 22:06 |
| mwhudson | jam: i'll try to remember when pqm reopens i guess | 22:06 |
| slangasek | jam, jelmer, mwhudson: thanks, will take it up with the branch owners | 22:07 |
| jam | mwhudson: do you have a date so I could help you remember? (this week, next, etc?) | 22:07 |
| mwhudson | slangasek: also an admin or a bazaar-expert (eg thumper) can do this for you | 22:07 |
| mwhudson | jam: if i haven't merged it by next monday, certainly give me a prod | 22:07 |
| jam | mwhudson: k, thanks | 22:07 |
| slangasek | mwhudson: mattman should be around, let's make him do it :) | 22:07 |
| jam | slangasek: though he isn't in #bzr | 22:08 |
| slangasek | 5~ | 22:09 |
| slangasek | jam: nevertheless, he's where I can get at him :) | 22:09 |
| thumper | jam: hi | 22:13 |
| jam | hey thumper | 22:13 |
| thumper | jam: do you have 15 minutes for a chat? | 22:13 |
| jam | I probably have 15, though I'm supposed to chat with poolie today (he probably is sleeping in, since I saw him < 8 hrs ago) | 22:13 |
| thumper | ok | 22:14 |
| thumper | jam: skype? | 22:14 |
| jam | works for me | 22:14 |
| peitschie | mornin everyone | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!