[00:25] BitSprocket, which bit didn't work? [00:25] what's going wrong? [00:28] It seems that it removed something called 'tree' *unsure* but the files are still marked with the versioning status as if nothing changed. I tried to export the files but that didn't seem to work either... [00:29] what does 'bzr status' show? [00:29] '... Modified' [00:30] so you did 'bzr rm --keep THING' [00:30] and now 'bzr st' still shows some files under that directory as modified? [00:30] really? [00:31] Yes, but it may be after I've done some more tinkering. I just tried the bzr rm --keep and now the status says: [00:31] bzr: ERROR: No WorkingTree exists for "file:///home/scott/pytivo/.bzr/checkout/". [00:31] ! [00:31] maybe you're in the wrong directory? [00:32] I thought so too so I tried the same steps moving down the directory structure to where the actual files were and did the same thing with the same results. [00:32] in which directory is your actual working tree? [00:32] not sure what you mean by working tree ... sorry [00:33] do you have ~pytivo/trunk or something? [00:33] i mean ~/pytivo/trunk ? [00:33] Ah, yes, its exactly that. [00:33] ok, cd there [00:33] done [00:33] now which directory did you want to un-version? [00:33] trunk and everything below [00:34] !! [00:34] hm [00:34] i think i misunderstood your question [00:34] why do you want to do this? [00:35] Well, I'm learning how to use bzr and I discovered that I created the repository in the wrong directory. My files are actually located in pytivo/trunk/TheBayer and I don't need version control configured for anything above theBayer. I figured if I removed the whole thing and started over I would be better off. [00:36] oh i see [00:36] so what is TheBayer? [00:36] all the source is inside that? [00:36] Its a python project that allows me to stream videos to my tivo box from the network. And yes, that's where the source files are. [00:36] when someone else gets a checkout, do you want them to get a directory called TheBayer, or do you want them to just get the files that you have inside that directory? [00:37] Well, for now, it's a project that I'm using to learn python so for the immediate future it won't be a public repo. I just wanted to be able to roll back changes if I really fouled things up. [00:37] I suppose that directory and everything below as one package [00:43] ok so really TheBayer is the name of your branch? [00:43] as opposed to trunk? [00:43] that's the codename for the feature or something? [00:44] TheBayer is the name of the project that I downloaded from the web. It's not really my project, its someone elses work that I'm using to cut my teeth. No codenames, nothing special. I believe that's what he named his fork from another project. [00:45] I untarred it and got a directory called TheBayer with all the source in it. [00:45] the pytivo and trunk folders I created myself. [00:47] ok [00:47] so i suggest you do [00:47] cd ~/pytivo/trunk/ [00:47] mv TheBayer ../ [00:47] cd ../TheBayer [00:47] bzr init; bzr add; bzr commit [00:48] Okay, so if I understand you, you are suggesting I move the folder and create a new repo right? [00:59] yes [01:00] got it... [01:02] Morning. [01:03] spiv: ahoyhoy [01:06] Hi spiv;GugaDin [01:16] if any of you are familiar with TracBzr, i'm getting "Warning: Error with navigation contributor 'BrowserModule' " [01:17] that is, in the Admin/Repositories page [02:13] hi spiv [02:14] spiv, lifeless, one of us should look at https://bugs.launchpad.net/bugs/594275 fairly soon [02:14] Launchpad bug 594275 in Ubuntu Distributed Development "sphinx automatic import is broken (affected: 1, heat: 6)" [Critical,New] [02:16] what makes that one critical? [02:16] (vs other automated imports failing) [02:16] we need to move the package importer from its current machine too [02:16] and find a team to own it [02:18] fixing that particular bug may fix 15 or so imports [02:18] which would be nice [02:18] lifeless, it makes it critical that it's blocking barry's attempt to do udd [02:18] on inspection a downgrade might be appropriate [02:43] man, I hate spam [02:44] and gmail is failing at catching all these twitter 'we've reset your password' mails. [02:44] It appears that the spammers are bcc'ing all of canonical on each personalised mail! [02:46] "... twitter ..." <--- Found your problem. [02:46] hah [02:49] vila: btw [02:49] SYN_SENT2 minutes [02:50] http://www.dd-wrt.com/wiki/index.php/Router_Slowdown was a quickly found reference for this [02:50] vila: which suggests to me that the server thread isn't actually accepting when it starts, but has presumably open the socket so it doesn't get rejected either. Or something. [02:51] i have created a launchpad branch stacked on top of an earlier tag of another lp branch. i have a local checkout of both for speedy work. I would like to merge all revisions affecting a certain directory. How can I do that? Just doing the merge does the file changes but does not actually merge revisions. [02:52] thats right, merging only part of a patch is a cherrypick and cannot show up as a full merge. [02:53] as said, i would like to merge full revisions, affecting a file / directory ... does that involve lots of scripting trickery :) ? [02:57] you want to merge a revision, but not its parents, right ? [03:02] chx: ^? [03:02] reading [03:02] hrm [03:03] i think the answer is yes :) [03:03] so, thats not a complete merge [03:03] oh? [03:03] well, yes, it's cherry picking [03:03] a complete merge merges a revision *and its parents*, recursively [03:03] but it's revisions that it merges [03:03] all the way back to the revisions that your branch already has [03:03] which would bring in changes to ohter wiles. [03:03] *files [03:04] so a) i need to find which revisions affected a file b) merge in just those revisions [03:04] right? [03:05] lets start over [03:05] what are you doing at the moment, and what is going wrong [03:06] heh [03:07] let's go step by step [03:07] a) i have created a launchpad branch (sandbox) stacked on top of an earlier tag of another lp branch (trunk) [03:07] b) i have checked out both [03:07] c) cd sandbox/sites [03:07] d) bzr merge ~/examiner/trunk/sites/parc/ [03:08] e) bzr ci -m 'merged in parc changes to sandbox' [03:08] f) check with bzr log -n0 -- oopsie no revisions! [03:08] g) bzr uncommit [03:08] h) /join #bzr [03:08] makes sense? [03:09] what does bzr root ~/examiner/trunk/sites/parc/ [03:09] print out [03:10] * spiv guesses the root is ~/examiner/trunk [03:11] /home/chx/examiner/trunk [03:11] ok [03:11] it's a checkout of lp:~examiner-dev/examiner/trunk [03:11] chx: that has happened because you merged a subdirectory. [03:11] I created the sandbox branch with bzr branch -r tag:Perugina --stacked lp:~examiner-dev/examiner/trunk lp:~examiner-dev/examiner/sandbox if that matters [03:11] chx: doing that makes it a cherrypick [03:11] i see. [03:11] chx: and cherrypicks *are not recorded in log* [03:12] hm [03:12] you have two options [03:12] a) don't worry about it not being in log [03:12] b) don't merge a subdirectory [03:13] and if i do bzr merge -c 15932 ../trunk then it'll show up? [03:13] no [03:13] only bzr merge ../trunk will? [03:13] because -c does a cherrypick in the graph as well, a different sort of cherrypick but still a cherrypick [03:13] thats right. [03:14] ok, so then i might pick a [03:14] and hope that when i later do just bzr merge trunk then it will simply figure out that some differences are already in. [03:15] it looks like i have no other choice [03:15] Right. bzr merge can record "revision X (and all parents of X) has been merged", but not "revision X without parents" or "just some subdirectories changed in revision X", or other variations. [03:15] 'bzr merge' will generally avoid reporting conflicts if the exact change to merge already seems to have been applied. [03:15] but then bzr merge is awesome and will figure out that some changes are already in. [03:16] right. [03:17] my heart still aches for darcs but it is so slow :( === davidstrauss_ is now known as davidstrauss === r0bby is now known as robbyoconnor [06:35] lifeless, oh did i mention that we talked a bit about user models [06:36] there's a file in devnotes about this [06:36] http://doc.bazaar.canonical.com/devnotes/bzr3-user-stories.html [06:41] cool [06:44] way [06:44] ...that was an odd typing mistake, but let's pretend I meant to say "way cool" :) [06:49] hey spiv :) [06:56] spiv, https://code.edge.launchpad.net/~mbp/bzr/590638-buffering/+merge/27578 is the issue of excessive buffering from last monday [06:56] not urgent [06:57] poolie: thanks! [06:58] how to confirm that merge is done and all conflicts resolved? [06:58] assad, 'bzr st' [07:00] poolie, i am getting this: pending merge tips: (use -v to see all merge revisions) [07:00] ok [07:00] poolie, is the merge over and conflicts resolved? [07:00] try 'bzr conflicts' [07:00] if there are none you're ready for 'bzr commit' [07:01] none, thanks [07:01] :) [07:29] hi all [07:31] hi there vila [07:31] i have a ScriptRunner patch for you [07:31] poolie: hey ! [07:31] and i guess you already know you're lotzman this week [07:32] hmm, looks like I missed a joke somewhere, that's the second time I see 'lotzman' used and I have no idea what it means :) Well, except some relation with patch pilot that is :) [07:32] it's the Russian word for "pilot" in the sense of someone who helps a ship into a harbor [07:33] bialix told us that when he asked what 'patch pilot' means [07:33] haaa, yeah, the first reference was from bialix indeed :) [07:33] 'pilote' is the French word for that [07:34] heh [07:35] so https://code.edge.launchpad.net/~mbp/bzr/scripts/+merge/27581 is the one i was thinking of [07:35] and then https://code.edge.launchpad.net/~mbp/bzr/externalbase/+merge/27583 uses scripts quite a lot and to good effect [07:35] ok, I'll look into it today [07:41] i don't mean to harrass you there :) [07:42] hehe, no harassment taken :) [07:45] * mneptok arrives on cue [07:45] did someone order some harrassment? === chx is now known as chx_zZz [07:59] poolie, how can i update one branch on launchpad with another branch on launchpad? so that i dont have to first merge my branch and then push the changes to the other branch. [08:01] can you explain more? [08:01] assad: A merge requires a working tree, lp have no WT, I'm pretty sure you can't achieve what you want there [08:01] assad: If I'm understanding your question correctly (what exactly do you mean by "update"?), you can't. What's the problem with pushing the changes? === radoe_ is now known as radoe [08:09] poolie, i intend to update/push changes to my branch from the parent branch via lp itself. so that i dont have to move files through my machine. [08:09] assad, just for curiousity which project is this? [08:09] assad, no, you can't really do that, you need to push from your machine into the other branch [08:09] poolie, ok [08:10] it might be nice if lp let you do the merge remotely but we don't atm [08:10] ok [08:24] lifeless, spm: How did your pqm fixes went ? [08:24] poolie: geee ! No harassment but nothing less than *7* mps !!! :) [08:26] hey vila, sadly no progress *yet*, but I am right now about to attempt to apply lifeless' patch and get the package(s) rebuilt. which is step A in this one. [08:26] spm: hi ! No harassment, no harassment :) Thanks for the feedback ! [08:27] :-) np === nlisgo_ is now known as nlisgo [10:44] vila: did you see my web link for you in backlog ? [10:46] lifeless: yup, thanks [10:47] I don't know how to check that on windows though, but I'm about to try to address it anyway by finishing what I started on SmartServer_for_testing first and see from there [10:49] vila: try changing the timeout in the registry, if the behaviour changes to match, thats what it is [10:50] regis..what ? :) [12:33] heya [12:33] bonjour vila ! [12:46] \/win 5 [13:00] bialix: privet Sacha ! [13:00] cool [13:00] privet [13:01] vila: just want to say that I've read your comment to leaking merge proposal and I very impressed [13:03] by what ? The number of dormant bugs ? :-) The 22 hours on windows ? :-P I'll get them pass on windows, I tell you ;) [13:09] by the problem and analysis [13:09] did not realized hidden problems [13:10] vila: and yes, 22 hours is a bit tooooooooooooooooooooooooooo much [13:10] bialix: ha, yeah, tricky stuff :-/ [13:10] hehe, don't worry, I'll fix that :) [13:10] cool :-) [13:11] but the nice thing is that it should help use more threads in the future (outside of the test servers) while still keeping a python-ish way to describe the processing, still a long way to get there though :-/ [13:17] vila: I don't understand though your remark about slicing test suite to keep number of opened sockets below th elimit [13:18] bialix: when using --parallel=fork, we spawn several processes, each of them with only a slice of the whole test suite [13:18] bialix: so each process see less leaks and is able to finish [13:19] I think limit for opened sockets is limit for all running processes [13:21] bialix: Well, it could be on windows but --parallel=fork doesn't work on windows anyway [13:21] hehe, nice [13:21] :-/ [13:42] Hi all :-) [13:43] jelmer: Do you know if anyone is planning to bring recent versions of bzr, bzr-svn and loggerhead to backports.org? [13:43] Lo-lan-do: not that I'm aware of [13:44] Thanks. I guess I'll try that myself then. [13:44] the bzr versions reasonably recent, 'just' all the packages which depend on it are broken as a result : [13:44] :/ [13:45] http://bzr.debian.org/loggerhead/pkg-python/python-defaults-debian/annotate/head:/dh_python2? seems to crash somewhere in bzrlib [13:45] bzr 2.0.3, loggerhead 1.10 or so === mrevell is now known as mrevell-lunch === chx_zZz is now known as chx [14:09] Lo-lan-do: I know at least two other people who are interested in bzr and bzrtools in backports === kosipov is now known as kostja_osipov === mrevell-lunch is now known as mrevell [14:20] jelmer: Let's see if anyone shouts at my email :-) [15:25] Lo-lan-do: re your email for bzr backports, one of my last messages to bpo users was about doing bzr package backporst. iirc it contains a list of packages which need rebuilding/changing. i can probably find it if you think it'll help === IslandUsurper is now known as IslandUsurperAFK === beuno is now known as beuno-lunch [17:13] Is there really much of a performance penalty in fetching between pack-0.92 and 1.9 formats? [17:13] Or is bzr being a bit over-eager at warning me about format mismatches? [17:14] maxb: between pack-0.92 and 1.9 it shouldn't be very expensive [17:14] Do you think it's expensive to justify bzr issueing a warning on pull? [17:34] jam: ping [17:34] hi parthm [17:34] hi jam. [17:35] i was hoping to complete the lock-url patch. does the 5 sec timeout for LockContention seem ok to you? === IslandUsurperAFK is now known as IslandUsurper [17:36] so we've certainly gone around on it a lot :) [17:36] IMO, the timeout should be on the order of how long it takes to take and release the lock [17:36] jam: yes :) .. i suppose anything is better than 300. [17:37] so that 2 people who are doing things that *can* be done won't block eachother [17:37] for example, updating branch.conf [17:37] also, updating pack-names is done with a physical lock [17:37] so we should look at how long it takes to get the lock, update pack-names, and then release the lock [17:38] That, I think, is the key thing to watch out for [17:38] because if 2 people push to a shared repo, but to different branches [17:38] we want that to succeed [17:39] jam: that makes sense. [17:39] now *if* that is being performed (not with SFTP requests, for example), then 5s is probably reasonable [17:40] jam: i could do a quick check of doing a push from two terminals into one repo at the same time (with 5s timeout). i suppose that should cover it. [17:41] separate branches. [17:41] the ordering is... take the name lock, read the current content, compare it with your own content, write up new pack-names content to a temporary file, and then overwrite the existing file (either with simple POSIX rename, or 'fancy-rename'), unlock [17:42] parthm: well, there is a bit more 'exact timing' issues than just manually testing [17:42] unless you stress test it with a lot of pushes, etc. [17:43] jam: maybe i can just set the timeout to 10s and set the url patch to 'needs review'. these two are actually separate. i can open a bug on getting a better estimate for timeout. [17:44] i agree that a stress test is probably a good way to tune the timeout. [17:45] let me think for a sec [17:45] I think I can do a simple test [17:45] and have it run against a remove bzr [17:45] and just see how things go [17:46] and hopefully have you/someone in AU run it [17:46] jam: ok. === beuno-lunch is now known as beuno === deryck is now known as deryck[lunch] [19:04] I'm trying to run yes yes [19:04] I'm trying to run yes yes | bzr pull but it's not being picked up by the ssh agent "Are you sure you want to continue connecting (yes/no)? " any ideas how to get around this? [19:05] Run bzr pull by hand and say yes to ssh? [19:06] Lo-lan-do: scripting this [19:06] SSH should then remember your answer [19:06] I need to answer it from a script [19:07] Set the StrictHostKeyChecking option to false in your SSH config file? [19:08] :D [19:08] thanks [19:08] (I didn't suggest that, and you found about it yourself, and don't complain if you mess up your security) [19:09] :P [19:09] I can easily comprehend the issues with it [19:10] wide open to man-in-the-middle === deryck[lunch] is now known as deryck [20:36] I've got a local branch with a parent of "/repos/pf6". i want to switch the local banch to use, and be in-sync with, a different parent, "/repos/pf6-617". [20:36] i entered my local branch, and issued a "bzr switch /repos/pf6-617", and got: bzr: ERROR: Cannot switch a branch, only a checkout. [20:37] hm. so, how do I make the switch? [20:42] bendj: I think you have two concepts conflated [20:42] bendj: 'parent' is used for the 'pull' and 'merge' commands. [20:42] bendj: switch is used to change a checkout to be a checkout of a different branch [20:43] bendj: can you describe differerntly what you want to happen, maybe I can suggest a way [20:49] lifeless: I did -- (1) bzr init-repo --no-trees /repos (2) cd /repos (3) bzr branch --no-trees source1 (4) bzr branch --no-trees source2 (5) cd /home (6) bzr branch /repos/source1 mysite (7) cd mysite (8) hack, hack, hack ... [20:49] so, in my language, /home/mysite has a 'parent' of /repos/source1 [20:49] i want to switch it to a 'parent' of /repos/source2 [20:49] description make sense? [20:49] bendj: I think what you wanted to do in step 6 was 'bzr checkout --lightweight /repos/source1 mysite' [20:50] bendj: I can help you make it like that [20:50] bendj: first, cd to mysite [20:50] i THINK i may need to convert the /home/mysite branch to a checkout (via bind?), then i can do the switch ... [20:50] and do 'bzr push :parent' [20:51] lifeless push --> "update a mirror of this branch". sorry, which mirror gets updated? [20:51] :parent is an alias for 'the parent of this branch' [20:51] which according to your commands is /repos/source1 [20:52] by (6) bzr branch /repos/source1 mysite [20:52] lifeless: yup. but, isn't that going to attempt to 'make changes' to the parent, aka /repos/source1? [20:52] bendj: isn't that what you wanted ? [20:52] nope. [20:53] bendj: Do you want to discard the work you've donein mysite ? [20:54] lifeless context -> i'm attempting to update /home/mysite (a pressflow/drupal site, based off the 'release' trunk @ /repos/source1). [20:54] i want to switch /home/mysite to be bbased off newer 'test' branch source of pressflow @ /repos/source2. [20:55] have you made changes in mysite itself ? [20:55] scads! [20:55] then you have the following situation [20:55] branchA (trunk), branchB(test) and branchC(mysite) [20:56] these all have unique content [20:56] pls keep typing. brb .... minor emer [20:56] switch is a command to well, 'switch out' or totally replace a working area with some other branch - it says (for instance), 'I have mysite, but I really want test.' [20:56] this isn't what you want to do. [20:57] What I think you want to do is 'bring in the changes that test made so that I have both the work from test and the work from mysite' [21:00] the way to do that is 'bzr merge /repos/source2; bzr commit -m "Merge in test"' [22:18] lifeless: thanks. emer wasn't so minor ... sorry bout that [23:12] man, I keep breaking things [23:13] should have a precommit hook that runs the tests against all four python implementations [23:13] :) [23:13] mgz: that would be nice [23:13] mgz: I thought about a check-all or something [23:14] but didn't get the activation energy up [23:24] okay, my list of things to do in the branch is at least diminishing [23:25] only hard thing left is decision about moving/renaming some of this 'utils' stuff [23:25] it's a little annoying currently as now testtools.run and testtools.testresult need utils, which pulls in a bunch of code most of which is only needed for Python 2, and some of it only for the test suite [23:26] I think iterate_tests should move anyway as it's part of the base public api [23:26] agree [23:32] mgz: so I think iterate_tests should move; we should leave a forwarder behind [23:32] mgz: we should split 'end users want' and 'only selftest wants' - but for testtools anything generic end users may still want, because of its rather introspective nature [23:32] yup. there's no fancy deprecater as in bzrlib though, right? [23:33] some of this end users indirectly want, but should only be accessible via say, method on testresult [23:33] otherwise they'd need all this horrible version checking in their code as well [23:34] that seems to be a swings and roundabout distinction [23:34] unless its already on unittest.TestResult [23:34] and if it is, they may want to be able to monkeypatch their own - say twisted.trial.TestResult - so a helper function may be nice anway [23:34] ah, I see. [23:35] I don't see that they would need version checking [23:35] it can be in our helper, or in our module or whatever [23:36] hi there jam? [23:47] will bzr run as bzrlib within google appengine? [23:53] it should [23:53] obviously without the C extensions [23:53] I don't think anyone has tried. [23:54] would be interesting to see. [23:54] GAE is a classic example of why we have a no-C-requirement policy [23:54] even though I waver on that from time to time [23:55] I think we could be _so_ much faster if we went pure C, with a python version as a port rather than the primary environment. [23:57] I'm helping a person who's getting "bzr: ERROR: Unsupported protocol for url "ancestor:lp:~pressflow/pressflow/merge-drupal-6.17" when running "bzr diff --old=ancestor:lp:~pressflow/pressflow/merge-drupal-6.17" [23:59] lifeless: having a main function in C with a python fallback seems OK to me... [23:59] lifeless: is this not allowed?