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