[00:01] So it's a way of grouping a bunch of recent changes together in a way that can be seen in the revision history. [00:03] Hm. Trying to pull just a single revision of bzr.dev to another box, "bzr pull bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev -r 5218" gives me "bzr: ERROR: Not a branch: "/build/"." [00:03] Can't I do that? [00:06] bendj: /build is what you're pulling into? [00:10] jelmer: nope. dunno where that's coming from. i'm simply in my ~/ dir. [00:11] bendj: Your homedir is a copy of bzr.dev? [00:13] Peng no I'm trying to pull the rev into a dir into it. I've tried to branch a single repo, but it seems to retrieve entire history ... all I want to do is pull the source for ONE revision. [00:13] bendj: Are you trying to create a new branch? [00:13] Ah. [00:13] bendj: pull does not create a new branch. [00:13] Peng_: Nope, just pull source for ONE revision. [00:14] yep, i know. so how do I get ONLY one rev -- not the whole history? [00:14] bendj: The thing is, it may suck that "bzr branch" pulls down the entire history, but it's also the best-optimized path. "bzr checkout --lightweight" or "bzr branch --stacked" or even "bzr export -d" might actually be less efficient. [00:17] Peng_: Iiuc, then, i *can't* pull just one revision's source? [00:22] bendj, you can do a lightweight checkout [00:22] or bzr export [00:25] Lor Ok, I'm confused. If those are single revision retrievals, then how could they conceivably be "less efficient" than retrieving the entire history ? [00:27] bendj: Because a lot of time and effort has been put into optimizing retrieving the entire history. [00:27] bendj: Anyway, I gave you three examples of how to do them. Unless you're on dial-up, even branching the entire history would have finished by now. [00:28] Once you have the history locally, it's presumably more efficient to operate on it to e.g. retrieve a past revision. [00:28] But yeah, speed is not a good reason for lightweight checkouts. Disk space might be. [00:29] But not really on desktop machines, nowadays. [00:29] Lor counterintuitive, but ok. thx. [00:30] I don't think the choice between these has any practical significance, if all you want is a snapshot. [00:34] jelmer fwiw, 5218 is 'good enuf' to avoiid the issue ... thx. [00:35] Lor fair nuf === fabio is now known as fabiokr [00:35] hi there [00:35] is there a command to export just the files that have changed between revisions? === blueyed_ is now known as blueyed [00:41] fabiokr: bzr log -v tells you [00:41] so you can either call whatever python api it calls [00:41] or use xmloutput and parse it out of the xml form of the log :) [00:41] bzr st -c 123 [00:41] aha. [00:48] I want to set up a cron job to push to bzr+ssh with specific credentials (on Windows). Since it ignores passwords in the authorisation.conf, is there a way to do this? [00:49] jbowtie: use key auth instead [00:50] dash: Can I specify the key in the auth.conf? [00:50] jbowtie: you specify it in the setup for your ssh client, presumably [00:51] dash: Ah, but I'm running the cron job as a specific user without a profile. [00:51] jbowtie: okay [00:51] well, you gotta have your ssh client configured somehow :) [00:52] dash: Normally I use the --password parameter, but bzr doesn't give me a way to pass this. [00:53] beats me [00:53] didn't even know cron would run on windows [00:55] dash: Well it can but I'm actually using the equivalent "Scheduled Tasks" feature under Windows. [00:57] jbowtie: aah. [00:57] well, i'm primarily familiar with using pageant [00:57] apparently that can run without having to be logged in? [00:58] dash: Hmmm...I'll have a look, see if bzr interacts with that at all. [00:59] jbowtie: if you're using plink, then it does. [00:59] http://wiki.bazaar-vcs.org/Bzr_and_SSH [01:00] dash: OK, thanks for that, will have a read. [01:16] dash: Looks like it will work, just need the scheduled task to launch pageant before running bzr. [01:17] So now I can pull the latest code from Team Foundation Server and push it to our bazaar mirror. [01:19] i know some guys who will love you forever if you can make bzr pull from TFS. [01:32] dash: I've already done that, just waiting on the lawyers to approve releasing the plugin. [01:32] dash: Right now I'm working on getting push to work as well. [01:33] Hint for anyone who wants to try it themselves: it's just SOAP messages, look at opentf source for details. [01:34] Which I had no hand in, I just looked at bzr-svn and opentf to figure out how to make it work. Just a couple hundred lines of code. [01:46] Funny that there is Tree.iter_entries_by_dir (with a funny traversal order), but no plain depth-first iter_entries [01:46] (which the inventory has, there's just no wrapper in the tree) [01:47] Bah. iter_changes uses the funny order, whereas I'd like depth-first. === SamB_XP_ is now known as SamB_XP [02:59] First successful bzr push to Team Foundation Server. Now to get round-tripping details squared away. [03:01] Congrats. [03:04] Yes, I'm very happy. Only thing that will be sweeter is getting the Legal stamp of approval so I can push to Launchpad. [03:05] But at least I am no longer shackled to TFS. [03:43] I think I've hosed my bzr install ... when I, now, 'bzr commit -m "whatever"', i get: "bzr: ERROR: Unable to determine your name. Please, set your name with the 'whoami' command.". *Was* working a few hours ago :-/ [03:43] Where do I look to fix what? [03:49] bendj: I'd start by looking at the ~/.bzr directory (or Windows equivalent) [03:49] bendj: Sorry, I mean .bazaart [03:50] bendj: Curse my fat fingers! That's ~/.bazaar on Linux/Mac [03:51] Usually the info is in the ~/.bazaar/bazaar.conf file. [03:51] jbowtie: sure. it's (a) there, and (b) bazaar.conf & authentication.conf are as they've been since 3/25/2010 -- untouched. [03:52] bendj: Does the output of "bzr whoami" match the contents of bazaar.conf? [03:53] bendj: The other place where details can be stored is in the branch itself, the .bzr/branch/branch.conf [03:56] jbowtie: --> bzr: ERROR: Unable to determine your name., as well. looking in the branch files ... [03:57] Well, if it's giving that, it means it's not set :p [04:02] fullermd_: sure, trying to figure out "what changes" in the last four hours ... [04:03] Update bzr? === fullermd_ is now known as fullermd [04:03] bendj: If your bazaar.conf hasn't changed *and* it doesn't contain whoami information, then the details were probably in the branch.conf file. [04:03] bendj: If your bazaar.conf contains whoami information, then something's wrong with your bzr install. [04:05] branch.conf is unchanged since 4-29 -- and contains only "parent_location = ../../repos/pf6/trunk/" [04:05] (anyway, less 4 hours, more a week) [04:05] jbowtie: and, bazaar.conf contains: [04:05] [DEFAULT] [04:05] launchpad_username = [04:06] bendj [04:10] bendj: you want a line like: email = Tim Penhey [04:11] bendj: that comes from whoami [04:11] I hate having a VCS that makes me change my name, though :( [04:14] thumper: yup. and with that, i'm back in business. no *$*^ clue what changed, or why. thx! [04:16] You updated your bzr. [07:59] Is there a way to append to a commit rather than creating a new revision? [07:59] Not as such. [08:00] You can _replace_ the commit with a new one. [08:01] (though that's decidedly unfriendly when somebody else might have already seen the existing one) [08:07] OK, well I'm the only one working on it right now. [08:08] How can I bzr revert on a lightweight checkout? It keeps saying readonly transport [08:08] brylie: Well, that saves you the worry :) [08:09] tsp: That may be a bug... [08:09] What can I do to work around it? [08:10] fullermd, so I would say 'bzr replace'? Would 'bzr uncommit' be a reasonable choice since I will just re-commit directly afterwords? [08:10] brylie: Yes, that's what 'uncommit' is for. It backs you up to your state before the last commit (e.g., mv's and add's and file edits are all sitting waiting to be committed) [08:13] tsp: Seems like it may be fixed in newer versions... what are you running? === vila is now known as mgz [08:13] 2.1.1 [08:13] Hm, probably not in a release yet, though. === mgz is now known as vila [08:14] am I a bit too old? [08:15] Well... sorta. Too old to get the bugfix. But all releases are at the moment. [08:15] Is bzr branch that much different? do I just bzr pull instead of bzr up? [08:16] You could grab bzr.dev or the 2.1 branch (or 2.0, but that's a step backward) and use that. I don't know if there are snapshot tars/packages made... [08:16] Well, if you had a local branch, you wouldn't hit that bug, since it's about locking the branch (which it shouldn't do, but you don't notice locally) [08:30] what happens when you specify you'd like to merge just a directory? [08:30] will that show in the history? [08:31] any limitations on that? [08:35] Can I convert a lightweight checkout to a branch checkout? [08:35] GungaDin: No (to your middle question) [08:36] tsp: "branch checkout" is kinda nonsensical. I think 'reconfigure --tree' will turn it into an independent branch in place. [08:37] Testing now. I didn't really want to go the checkout route again if I didn't have to [08:37] Why not? [08:38] If it's a question of time or network bits, reconfigure isn't going to use any less than a fresh 'branch', since it has to do all the same work. [08:38] Well, it'll probably use a smidge less time, since it doesn't have to build a new WT, but that's noise unless it's a HUGE tree. And even then, it's probably noise relative to the history that implies. [08:40] I've got a pile of changes I've made to what I think are ignored files/directories that are required for this thing to build. Wuld reconfigure work here? [08:40] I think it should leave all the WT stuff alone, yes. [08:41] There are Stupid Manual Tricks you could do to have those waiting in a fresh branch, but reconfig is a lot easier and less fidgety than trying. [08:47] hey guys im having issues trying to check out from a bzr branch on launchpad [08:47] :( i loged in with my lp id yet im not commiting anythign to the bzr repo i get the following [08:48] jonathan@Eagle1:~/mixxx$ bzr co lp:mixxx [08:48] Permission denied (publickey). [08:48] bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. [08:48] any idea why im getting that for a simple check out? [08:49] eagles0513875: for some reason your SSH key isn't working [08:49] eagles0513875: what's your LP id? [08:51] if I just do bzr reconfigure --tree, I get an error about network object and a traceback. I can't copy/paste it right now [08:52] spiv: for a simple check out i need an ssh key [08:52] eagles0513875: To use SSH you do. [08:52] spiv: need to get it back on this computer :( have it backed up on a cd [08:53] Peng_: is there a way i can checkout without needing ssh or once im logged in with my lp id it is required that i use ssh [08:53] eagles0513875: you could create a new one [08:53] eagles0513875: For a simple checkout you can use HTTP if you want to, but since you ran launchpad-login, Bazaar will use SSH by default. [08:53] eagles0513875: Sure, go to Launchpad, find the project, username and name of hte branch, then do "bzr co http://bazaar.launchpad.net/~user/project/name". [08:54] Peng_: there a way to logout [08:55] eagles0513875: $EDITOR ~/.bazaar/bazaar.conf and remove the launchpad_username line. [09:03] tsp: Mmm. Dunno there. [09:34] poolie:http://imagebin.org/96665 [09:46] jelmer: did a bzr-git upgrade get CPed? [10:01] mwhudson: not yet [10:01] jelmer: so how did the dulwich import start working again? === oubiwann is now known as oubiwann_ === oubiwann_ is now known as oubiwann [11:06] abentley: hey [11:07] Hi. === oubiwann is now known as oubiwann_ [11:07] abentley: Is there a better way of figuring out the revisions to push than using iter_ancestry ? [11:08] (with only a graph object for the source repo available and a way to check if the revid is present in the target) [11:09] I'm not sure the context. Graph.find_difference might be appropriate. [11:12] abentley: I'm trying to figure out the set of revisions I need to push to a remote git repo while knowing the remote heads [11:13] jelmer, iter_ancestry seems perfect, then. Why do you want something else? [11:14] jelmer: native fetch uses a breadth first searcher [11:14] jelmer: see _walk_to_common_revisions. It's basically just iter_ancestry [11:16] Well, it's like iter_ancestry plus some bits to avoid iterating bits of the graph related to the heads we know we have, I guess. [11:16] abentley: I have multiple stop revisions at the moment and am browsing back all the way to null: atm [11:16] spiv: thanks [11:17] jelmer, yes, spiv's suggestion sounds good then. [11:17] abentley: great, thanks === gnomefreak76 is now known as gnomefreak === oubiwann_ is now known as oubiwann === oubiwann is now known as oubiwann_ [11:25] mwhudson: what's your schedule look like today? [11:26] jam: fairly open [11:30] jam: tbh, i could probably spend all afternoon with you guys [11:31] jam: do you have any more discussion time scheduled? i didn't really have much to add to this morning's [11:31] mwhudson: we don't have anything explicit that i know about [11:31] usually we only do a little bit per day :) [11:35] i might make a core-team mailing list [11:36] how do I get an SSH-based transport to look for its private key in a particular place? [11:36] the two answers I have now are terrible [11:36] jml: If you get a good answer, let me know. [11:37] jbowtie, well, the good answer is "patch bzr" [11:37] jbowtie, but that's not an option for me right now. [11:39] jml: for a start, use paramiko [11:39] paramiko looks in $HOME/.ssh [11:39] so you can override $HOME and life is good [11:39] mwhudson, yeah, that's what we are doing [11:39] jml: On Windows, I use "pageant.exe my.private.key -c bzr xxx" [11:39] mwhudson, that's one of the two terrible answers :) [11:40] jml: openssh looks in .ssh in the user's home directory and finds the home directory by calling getpwent [11:40] mwhudson, the other is monkey-patching bzrlib.transport.ssh._try_pkey_auth [11:40] (!!!) [11:40] mwhudson, good to know. [11:40] jml: ah yes, i guess you'd looking at the codehosting acceptance tests? [11:40] i was extremely unhappy when i found this out about openssh [11:42] jml: you might be able to register a particular ssh vendor [11:42] jml: I need to write a patch for adding NTLM auth to HTTP transport; I can look into the SSH transport while I'm at it. [11:42] jbowtie, that'd be great. [11:43] jml: Do we know what the behaviour should be? Is that defined in a bug or patch somewhere? [11:44] no, sorry [11:44] jml: No worries. I'll work something up and propose it. [11:45] jml: Probably propose something like "key=file.key" in the auth.conf file. [11:46] jbowtie, well, I want to do this in a computer program, so I want parameters, not configs [11:46] jml: environment variables are almost as good as parameters! [11:47] (not really, obviously) [11:48] jml: I hear you, I'll have a play this weekend. [11:49] Speaking of NTLM, is there anyone around who knows the HTTP transport code around? [11:49] vila should be around [11:51] although it's nearly lunchtime here === oubiwann_ is now known as oubiwann [11:52] mwhudson: Well, it's nearly midnight here so I'll probably miss vila. [11:53] But that's all right, I can always write a patch for offline review. I just wanted to avoid breaking it in obvious ways. [12:00] jbowtie: I'm here [12:00] jbowtie: let me re-read the log [12:02] jbowtie: so, there is some code related to NTLM in urllib-based http client, you want to look in to bzrlib/transport/http/_urllib2_wrappers.py [12:02] jbowtie: and search for the NegotiateAuthHandler [12:03] jbowtie: the corresponding tests are in bzrlib/tests/test_http.py [12:04] vila: I was looking to integrate the python-nltm auth handler. [12:04] jbowtie: that won't work, different designs [12:05] vila: So I'm better off patching the NegotiateAuthHandler to work properly then? [12:05] jbowtie: (if that's the one I looked into months ago), i.e. some code may be reused, but you can't just plug it into ours [12:05] jbowtie: certainly [12:06] vila: That's a shame if it can't be plugged in, works really well in my custom transport. [12:06] jbowtie: custom transport ? As in bzr transport ? [12:07] jbowtie: my knowledge may be obsolete, I'd be very happy to be wrong here ! [12:07] vila: Yes, I implemented a tfs+http transport for using Team Foundation Server as a foreign VCS. [12:07] jbowtie: hmm, is there a branch I can look at ? [12:08] vila: No, not cleared by legal yet (which is why I haven't released plugin) [12:08] vila: But all I did was create a custom opener with the python-ntlm auth handler. [12:09] jbowtie: ok, so *from memory* the problem was doing that wasn't allowing keeping the connection alive or something [12:09] jbowtie: which could have a dramatic impact on performance, but I may be wrong [12:10] vila: Well my transport isn't bothering with keeping the connection alive, so might still be an issue. [12:11] vila: But it gives me an angle to look into. I'll also look at what python-ntlm is doing differently than the Negotiate auth handler. [12:11] vila: , what's up? [12:11] jbowtie: it's handled transparently so the transport itself shouldn't have to care, but so is the auth.conf stuff etc [12:13] vila: Yes, I made my own calls to the auth.conf stuff as well. So I think (hope?) it will integrate pretty cleanly. [12:14] vila: But it sounds like there is probably a way forward either way. [12:15] vila [12:15] jbowtie: yes, this certainly sounds good [12:15] jbowtie: you can have a look at the existing tests to plug your auth handler there [12:16] jbowtie: I'm not sure there are enough tests here (especially since you'll need a dedicated auth handler in your case), but that should help [12:16] err, auth *server* [12:17] * vila needs lunch ;) [12:18] vila: That's the problem with MS stuff, hard to write a test suite when the other end of connection is an expensive server. [13:12] Hi. Is it possible to retrieve the argument of a CLI option within a hook? [13:12] Particularly --fixes in my case. [13:16] mathbr: not in general [13:16] which kind of hook are you writing? [13:17] For commit_message_template; I’d like to add (Fixes #N) automatically if the --fixes CLI option is provided. [13:19] mathbr: you should be able to see the revprops on the commit object [13:21] spiv: Exactly as you said. It’s in there as 'bugs'. Thanks a lot. :-) [13:44] Got it working, thanks. === radoe_ is now known as radoe [14:25] vila: ring a bell === bac` is now known as bac [14:29] jam: i experimented with the smart server source (as in source-sink). there doesn't seem to be a good way to do estimation and show progress. the server just hands over the streams. [14:29] jam, lifeless: the current patch looks like https://code.edge.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/24483 [14:30] seems to work fairly accurately. [14:46] bialix: :-P === oubiwann is now known as oubiwann_ [14:59] kfogel: hey [14:59] kfogel: did you see my ping ? [15:06] lifeless: no, machine was fscking [15:06] lifeless: what's up? [15:09] rob savoye is pinging me [15:09] would like a progress report on savannah, I think :) [15:14] Does anyone have any hints/suggestions/etc... for how to build debian packages from source/control/etc... stored in bzr..? [15:14] Ideally I'd love to just be able to grab a checkout, run .. something... and have it Just Know it's trying to build version, say, 0.01~bzr123 [15:14] there's bzr-builddeb [15:15] * LeoNerd reads [15:16] LeoNerd: bzr build-deb is your answer === oubiwann_ is now known as oubiwann === oubiwann is now known as oubiwann_ [15:21] Hrrmmm.. This is almost looking a little too fancy.. [15:22] My source dir. is a CPAN module distribution, so that already has its own set of metadata and so on.. [15:22] dh-make-perl can already cope with that, to build src/bin .deb files.. [15:25] hmm [15:25] is there any way of changing the diff algorithm used by the qbzr plugin? [15:30] cbz: unfortunately not [15:30] cbz: You can configure it to launch a external diff. [15:30] does it use the same algorithm bram cohen outlines? [15:31] on his blog [15:31] cbz: run qconfig, and see diff section [15:31] okay [15:32] it just seems rather worse than the diff used elsehwere [15:32] in terms of not ignoring whitespace and such [15:32] kfogel: sorry for running; missed any reply ;) [15:32] * LeoNerd further considers if bzr-builddeb is best... [15:32] Anyone much experience on it who could answer questions? [15:33] LeoNerd: if you're buildding deb packages, yes. [15:33] cbz: qdiff uses the same algorithm that bzr diff, and according to jam, we do do what bram cohen suggests. [15:33] hmm [15:33] lifeless: OK.. And is it going to put the ~bzr123 on the version number? [15:33] That's -the primary- feature I was looking for [15:33] To the point that I was considering just $(shell bzr revno) 'ing in the Makefile somehow [15:34] The bzr branch stores the native upstream source (possibly as well as the debian/ dir) [15:34] the branch should be releaseable at any time, into a debian source/binary package, even without declaring a new official upstream release [15:35] I want to do that therefore, by building $VER~bzr$REV as the debian package version [15:41] lifeless: no substantive reply -- I was just answering your ping [15:44] LeoNerd: you could use bzr-builder for that [15:44] LeoNerd: however it generates native packages [15:45] get-upstream-source is the official way for doing what you're doing [15:45] Well.. the bzr branch does.. sortof.. contain the official upstream source. [15:45] at least, it contains all the files. [15:45] The tarball is the one that perl's "./Build dist" makes though; for .orig.tar.gz [15:52] lifeless: So.. Is this doable..? I want some kind of setup that the bzr branch can always be built into .debs, possibly indirectly via CPAN, but doesn't have to... [15:52] but I specifically don't want ot have to declare new upstream version all the time.. [15:52] .oO( Ideally if it understood my 'RELEASED ver' bzr tags that would be awesome) === oubiwann_ is now known as oubiwann [16:19] LeoNerd: bzr-builder and/or bzr-builddeb should be able to brin this all together for you [16:24] Righty === IslandUsurper is now known as IslandUsurperAFK [17:16] vila: sent to pqm [17:20] poolie: YES ! [17:20] poolie: thanks :) === beuno is now known as beuno-lunch === IslandUsurperAFK is now known as IslandUsurper [17:40] hi; is it possible to define an alias of a repository string? I'd like to alias bzr+ssh://.../ into something shorter [17:43] deviantintegral: there's a plugin for that; i think called aliases or bookmarks [17:44] poolie: thanks! bookmarks was the word I needed === beuno-lunch is now known as beuno [19:39] how can I find all the commits for a particular user in a log? [22:26] is there an equivalent to svn externals [22:42] Kobaz: http://wiki.bazaar-vcs.org/NestedTrees [22:42] which is kind of stalled [23:24] Hi again. I’m no exactly sure but is there a way to modify revprops of a commit based on the commit message’s content? Kind of what commit_message_template allows for, but inversed. [23:28] I have 2 diferent project that both use the same libraries. Both projects are in BZR and I want that when libraries are updated in one projects, that I can send the changes to the other, and vice versa. Problem is, these projects also have programs which changes I DON'T want to mix. How can I do this? [23:28] is it possible to do a merge with a certain part of the tree masked with DONT MERGE or something?