[00:01] <ronny> lifeless: is git alternates networking-cappable?
[00:05] <ChrisMorgan> I have another something which occurred to me; Inkscape has a devlibs SVN repository which has lots of binaries and things in it such as are used to compile Inkscape for Windows (Python, GTK, everything except MinGW).  This could be migrated to Bazaar now without it becoming enormous with lightweight branches, couldn't it?
[00:05] <ChrisMorgan> Historically it wasn't feasible but I /think/ lightweight branches should do it.
[00:13] <rpcesar> hello. the server I am trying to make a checkout using sftp, but its not published publicly via http://. In addition, the server uses a private key (works with putty and scpftp just fine). when I attempt to set the url to sftp://username:password@mycheckout.mydomain.com/ it fails with unable to authenticate host. then says something about supported auth types and public key. I am trying to figure out how to connect using my private key.
[00:15] <Peng> Bazaar should find it automagically.
[00:15] <Peng> Specifying the password in the URL is weird -- it's probably making bzr decide to use password auth or somethin'.
[00:16] <Peng> I don't know any of the details on how to get SSH keys working with bzr on Windows... It's easier on *nix. :P
[00:16] <Peng> Probably something in the docs, though.
[00:18] <Peng> rpcesar: http://wiki.bazaar.canonical.com/Bzr_and_SSH maybe?
[00:18] <rpcesar> i removed the password and username, it still doesent work right. and yes, this is on windows
[00:18] <rpcesar> im aware of placing keys in certain directories on unix, cant seem to find an equiv here
[00:19] <rpcesar> putty logs in fine, but I cannot seem to find the settings for sftp
[00:20] <Peng> There's nothing SFTP-specific here... It's just SSH.
[00:21] <ChrisMorgan> rpcesar: have you used Pageant?
[00:21] <Peng> rpcesar: Did you try that link?
[00:21] <ChrisMorgan> You should start Pageant and load the key in it
[00:23] <rpcesar> ok, im in it
[00:23] <Peng> In fact, that link discusses Pageant.
[00:23] <rpcesar> yep, that worked
[00:24] <Peng> Good. :)
[00:24] <rpcesar> I need to keep pageant open correct?
[00:24] <rpcesar> (as it provides the keys I assume)?
[00:24] <rpcesar> now, im still getting a different (probably unrelated) error stating that it is "not a branch"
[00:24] <rpcesar> the folder I am browsing to contains the .bzr folder
[00:25] <rpcesar> but its still saying "Not a branch"
[00:26] <Peng> rpcesar: Note that paths are relative from the root.
[00:26] <Peng> rpcesar: sftp://example.com/home/you/...
[00:26] <Peng> rpcesar: Or, equivalently, sftp://example.com/~/
[00:26] <rpcesar> hmm.. ok well I am actually working with a subdomain
[00:26] <rpcesar> mybranch.website.com
[00:27] <rpcesar> which points to the folder that contains the .bzr file (the beginning of the branch)
[00:27] <rpcesar> if I log in via scp it takes me to the right folder
[00:29] <Peng> Welll...bzr wants the path from the root of the server.
[00:30] <AfC> [I hate that]
[00:31] <rpcesar> sftp://myusername@name.website.com/~/web/website.com/name
[00:32] <rpcesar> I just tried this, it navigates to the the web home directory, etc, right to the file semi absolutely
[00:32] <rpcesar> its saying not a branch aswell
[00:32] <rpcesar> (~ moves it back to home)
[00:33] <rpcesar> I also used a symbolic link of the server to link to it, and no dice
[00:33] <Peng> Maybe it really isn't a branch. :D
[00:33] <Peng> On the server, what does "bzr info" say there?
[00:33] <Peng> You might have the path wrong. Or even a typo1
[00:34] <Peng> Nice. I typod the first character after "typo".
[00:34] <Peng> typoed? typod?
[00:34] <rpcesar> nevermind, i got it. had to actually type in sftp://username@branch.website.com/home/.....
[00:34] <rpcesar> I dont quite understand though how it does not automatically take it to the proper path
[00:35] <fullermd> Peng: The future tense is obviously "You know beforehand, just don't do it"
[00:35] <rpcesar> load branch.website.com into any sftp program and it goes right to the folder.
[00:35] <rpcesar> but thank you so much for your help guys
[00:36] <rpcesar> today is my first time using bzr, come rom an svn background, that just seemed so much easier :)
[00:37] <ChrisMorgan> rpcesar: you'll need to have the key loaded in Pageant whenever you want an SSH connection
[00:37] <ChrisMorgan> Don't worry, I had trouble with it a month or two ago when I started with Bazaar on Windows too.
[00:38] <ChrisMorgan> The people in here helped me to understand it though :-)
[00:38] <ChrisMorgan> Since then, just this week I've moved to Ubuntu as my main OS and it really is a lot simpler.
[00:41] <rpcesar> yes, i love ubunto. unfortunately, when dealing with clients, unfortunately this is for work and not allowed :)
[00:42] <rpcesar> ok, ran into another issue. I get ERROR: Cannot lock LockDir([path]/.bzr/branch/lock/gobbledegook.tmp) Permission Denied. when I attempt to commit
[01:05] <lifeless> rpcesar: sounds like you don't have permissions to do the commit
[01:05] <lifeless> rpcesar: as for what /~/ wasn't working - I dunno, it works for other users. Perhaps its a special sftp server?
[01:13] <EdWyse_Office> could someone familiar with setup.py take a look at http://paste2.org/p/600644 and tell me if that's the correct way of including the include file in MANIFEST?
[01:15] <lifeless> MANIFEST.in is the normal way
[01:15] <EdWyse_Office> Except MANIFEST.in isn't in the dev tree.
[01:16] <EdWyse_Office> My intention is to create a patch that will allow bdist_rpm to be made.
[01:21] <lifeless> EdWyse_Office: do add MANIFEST.in
[01:21] <lifeless> EdWyse_Office: didn't jam paste a patch for you the other day
[01:21] <EdWyse_Office> Yeah, and it didn't work.
[01:22] <aidalgol> My clone operation just failed with a 110 error.  How can I tell bzr to pick up where it left off?
[01:22] <EdWyse_Office> So I grabbed the source repo and I'm looking at how the devs designed it to work.
[01:22] <EdWyse_Office> Since I have more time now...
[01:22] <GPHemsley> How do I get $Id$ to expand again?
[01:24] <aidalgol> xb
[01:24] <aidalgol> Oops!  Ignore that.
[01:30] <spiv> GPHemsley: the bzr-keywords plugin
[01:31] <GPHemsley> spiv: Remind me how to activate that? :/
[01:31] <spiv> GPHemsley: it should come with docs
[01:31] <spiv> GPHemsley: (I'd have to go read them too)
[01:32] <fullermd> It's not really usable in practice.
[01:32] <GPHemsley> where are they? `bzr help keywords` didn't work
[01:32] <fullermd> It does once you install the plugin  8-}
[01:33] <GPHemsley> oh, I thought it said it comes with Bzr... I hate Launchpad.... *grumble grumble*
[01:36] <GPHemsley> so, uh, how do I install it?
[01:36] <lifeless> EdWyse_Office: We haven't tried to make bdist_rpm work :)
[01:36] <lifeless> EdWyse_Office: so don't limit yourself to what we do at the moment
[01:37] <fullermd> GPHemsley: Something like `bzr branch lp:bzr-keywords ~/.bazaar/plugins/keywords/`
[01:38] <EdWyse_Office> lifeless: I found the right way to do it using distutils.extension now, so unless you /really/ don't want me to do it in setup.py...
[01:39] <GPHemsley> $Id$ isn't in the list of supported keywords now output by `bzr help keywords` :/
[01:39] <lifeless> EdWyse_Office: I don't particularly care; the reason I say MANIFEST.in is because thats what is usually used for increasing the manifest
[01:40] <EdWyse_Office> ok
[01:42] <spiv> GPHemsley: yeah.  It should probably be added, although it is a bit of an odd fit because bzr versions trees, whereas cvs versions individual files.
[01:43] <GPHemsley> well, SVN has it, too...
[01:43] <lifeless> GPHemsley: svn also versions individual files
[01:43] <fullermd> Well.  All the existing keywords all refer to just the file too anyway.
[01:44] <GPHemsley> lifeless: Not insofar as assigning an ID number
[01:44] <lifeless> While I think we're too tree orientated, we're the same as git/hg/monotone/codeville/etc
[01:44] <spiv> fullermd: yeah
[01:44] <fullermd> It just misses the aggregation of $Id$
[01:44] <spiv> fullermd: like I say I think it probably ought to be added
[01:44] <lifeless> GPHemsley: Last I checked the internals, it did.
[01:44] <GPHemsley> lifeless: a revision ID refers to a whole collection of files
[01:45] <GPHemsley> lifeless: How it stores it internally may be another story
[01:46] <lifeless> GPHemsley: thats precisely what I mean, ids refer to things changed in svn, not to the state of a whole tree
[01:46] <GPHemsley> oh
[01:48] <lifeless> you can infer the state of a whole tree, but if compare with bzr/git/etc the whole tree /changes/ to record a commit
[01:48] <lifeless> which is a fundamental difference
[01:48] <GPHemsley> well, I'm not interested in the rev ID for $Id$ so much as all the rest of the data
[01:49] <lifeless> what data is that
[01:52] <fullermd> ...  well, I use $CVSHeader$ rather than $Id$, but it's the same aside from the path...    Path, version, date, committer, state.
[02:01] <lifeless> GPHemsley: you probably want a pre commit start hook then
[02:01] <lifeless> GPHemsley: or something like that
[02:03] <GPHemsley> lifeless: Here's an example from SVN: $Id: LICENSE 50 2009-06-24 22:12:19Z gphemsley $
[02:03] <lifeless> GPHemsley: and that adds lines on each commit?
[02:03] <lifeless> or just the one line
[02:03] <GPHemsley> just the one
[02:03] <lifeless> ok keywords probably does it then
[02:04] <fullermd> It has the individual pieces of information; it doesn't have a keyword that aggregates 'em all.
[02:05] <fullermd> So you could just put a /* $Path$ $Revision-Id$ $Date$ $Committer$ */ sorta thing together.
[02:09] <GPHemsley> yeah, but that's a bit much
[02:12] <fullermd> I doubt it'll be too hard to add $Id$; it'll probably show up eventually.
[02:13] <fullermd> 'minds me, I need to file a bug about the collapsing...
[02:31] <EdWyse_Office> Ok, lifeless, I apologize. I was wrong about distutils (though I still consider it a bug not to include dependencies in the manifest). I'll make the MANIFEST.in file
[02:42] <lifeless> EdWyse_Office: if it works for you, thats all that matters; the rest is detail
[02:43] <EdWyse_Office> Yeah, it didn't, but now I know why at least.
[02:45] <lifeless> why didn't it work?
[02:48] <EdWyse_Office> It's just not designed to include .h files, regardless of the Extension declaration. Making my rpm now, let's see if it works...
[03:20] <EdWyse_Office> Same problem as last time... bdist_rpm fails to build the package because rpm is expecting to find the manpage bzr.1 and instead finds bzr.1.gz. It turns out to actually be a distutils bug: http://bugs.python.org/issue644744
[03:25] <Kamping_Kaiser> is there any reason in particular why bzr log -r -3.. acts differently to bzr diff -r -3..? (the former displays the last 3 log entries, the later does nothing)
[03:25] <Kamping_Kaiser> hm, perhaps i ran it wrong
[03:26] <fullermd> Well, if there aren't any differences between the files in -3 and -1...
[03:28] <Kamping_Kaiser> looks like thats the case - commit -1 is nothing but a commit entry
[03:28] <Kamping_Kaiser> joys of rebasing *heh*
[03:29] <Kamping_Kaiser> thanks for the quick responce too
[03:42] <HFSPLUS> !ops
[03:43] <poolie> HFSPLUS: ?
[03:43] <RAOF> Again?
[03:43] <HFSPLUS> !ops
[03:43] <RAOF> poolie: They come on to Ubuntu-related channels and call the ops untill they get kicked.  Don't ask me why.
[03:44] <fullermd> Some filesystems are weird like that.
[03:45] <RAOF> Heh.  I've seen a number of people complaining about hfs+ recently :)
[03:51] <lifeless> EdWyse_Office: sounds like you need to fix distutils :(
[07:39] <ruki> i am getting this error: http://pastebin.com/m3965372f while pushing to my branch
[07:43] <lifeless> ruki: give break lock the same url you pushed too
[07:44] <lifeless> the error is misleading about the url to use
[07:50] <ruki> lifeless: http://pastebin.com/d6fd1ce8a
[07:54] <Peng> ruki: Follow what it says. :P
[07:54] <ruki> Peng: ok
[07:54] <Peng> ...
[08:55] <lifeless> poolie: #subunit exists btw, if you like
[09:18] <lifeless> poolie: I wish lp bugs mail was a little friskier
[12:14] <Adys> wasn't there a way to avoid committing files unless specified in bzr ci, without adding them to bzrignore?
[12:15] <Kamping_Kaiser> --strict?
[12:15] <Adys> no, more like; i have some local.py file; i run bzr something local.py; bzr ci; it doesn't commit local.py but commits the rest
[12:16] <Adys> until I bind it again to the branch
[12:16] <Adys> a local bzrignore basically
[12:16] <Kamping_Kaiser> hm. bzr shelve?
[12:16] <Adys> looks right, thanks!
[12:16] <Kamping_Kaiser> np :)
[12:17] <spiv> There's a --exclude option for bzr ci, too.
[12:17] <Adys> spiv: yeah but that involves typing it every time
[12:17] <spiv> Well, not really any worse than bzr shelve.
[12:17] <spiv> You could make an alias for it, though, if it's always the same file(s).
[12:18] <Adys> bzr shelve is only typed one until unshelve
[12:18] <spiv> Oh, I see.
[12:18] <spiv> I was thinking that you'd still want it in the workingtree after the commit.
[12:19] <Adys> well the files themselves stay in the working tree, its just ignored by bzr commit
[12:19] <Adys> from what I understand, anyway
[12:19] <spiv> 'bzr shelve' will move uncommitted changes from your working copy onto a "shelf"
[12:20] <spiv> So if you did e.g. "bzr shelve --all", then "bzr st" would show no changes.
[12:20] <Adys> well yeah
[12:20] <spiv> And if you opened the files in an editor, you wouldn't see the changes either.
[12:20] <Adys> uh
[12:20] <Adys> oh
[12:20] <Adys> hmm yeah thats not it
[12:20] <spiv> (Until you unshelved them, of course)
[12:22] <spiv> It would be fairly easy to write a plugin to do what you want, I think.
[12:22] <Adys> hmmm I was sure it was in bzr
[12:23] <spiv> Perhaps add a 'bzr hold-file FILE ...' command that adds file-ids to a list in .bzr/checkout/held-files, and a corresponding 'unhold-file' command.
[12:24] <spiv> And it would wrap 'bzr commit' to automatically pass those files to commit's --exclude.
[12:24] <Adys> yep
[12:24] <spiv> (Possibly add an --override-holds option too)
[12:24] <spiv> If it wasn't getting late here I might try doing it now :)
[12:25] <Adys> I'll try doing it
[12:25] <spiv> Cool.
[12:25] <Adys> reading up on bzr plugin doc
[12:25] <spiv> Ask here or on the list if you get stuck.
[12:25] <Adys> kay :)
[12:25] <spiv> As far as your original question, as you've probably gathered I don't know of an existing solution for that.
[12:26] <spiv> Well...
[12:26] <spiv> You could perhaps use looms like this, sort of, but that would be overkill and clumsy.
[12:27] <Adys> spiv: how do you pass multiple arguments to --exclude?
[12:27] <Adys> --exclude "foo.py bar.py" ?
[12:29] <Adys> also good to note --exclude / -x isn't in bzr help ci
[12:32] <spiv> Adys: Hmm, I see it in that help
[12:33] <spiv> Adys: I would expect you can pass multipe -x options
[12:33] <Adys> http://dpaste.com/142859/
[12:33] <spiv> Adys: i.e. -x foo.py -x bar.py
[12:33] <Adys> ill try
[12:33] <spiv> Adys: it's there on line 20 of that paste?
[12:34] <Adys> I'm blind :/
[12:34] <Adys> and yes, multiple -x works
[12:34] <Adys> thanks :)
[12:34] <spiv> It doesn't help that there's no obvious ordering to the list of options.
[12:55] <lifeless> spiv: BTW,  have I pointed you at lp:testrepository ?
[13:11] <spiv> lifeless: not until just then ;
[13:11] <spiv> ;)
[13:15] <spiv> Gar, the "Subscribe to mailing list" link fails to take to me a page from which I could actually subscribe to the mailing list.
[13:32] <lifeless> spiv: which link? I can fixness
[13:35] <spiv> lifeless: the one on https://edge.launchpad.net/~testrepository-dev, I'm not sure if you can actually fix that.
[13:35] <lifeless> oh, maybe not as easily ;)
[13:35] <spiv> lifeless: (it was where the "Unsubscribe" button now is for me)
[13:36] <lifeless> spiv: did you file a bug for barry?
[13:36] <spiv> It took my to my +editemails page, which isn't particularly useful.
[13:36] <lifeless> oh right, yes.
[13:36] <spiv> No, but only because it's much too late at night to be filing coherent bugs.
[13:36] <spiv> Especially in this heat.
[13:36] <lifeless> bugs aren't lasers :). speaking of the time... gnight.
[15:21] <ruk> do i have to add, commit everytime i have to update my branch ?
[15:21] <ruk> or do i just have to bzr push?
[15:22] <luks> can you reformulate the question?
[15:22] <luks> what do you want to do?
[15:43] <Colonel-Rosa> morning, does bzr have commit globbing?
[15:43] <Colonel-Rosa> bzr ci *index.php
[15:43] <Colonel-Rosa> commits all index files
[15:44] <luks> your shell does that
[15:44] <Colonel-Rosa> nvm, got it
[18:43] <bendj> Hi.  With scheme=ssh in my ~/.bazaar/authentication.conf, how/where do I specify a *different* ssh config file?  atm, i get: "Bad owner or permissions on /root/.ssh/config" if I, e.g., try to exec 'bzr branch lp:pressflow pressflow6-core'.  Not surprising, since my ssh config is at a different, non-default file path...
[18:45] <bendj> Reading @ http://doc.bazaar.canonical.com/latest/developers/authentication-ring.html, I don't see (?) any way to spec the ssh config path :-/
[19:01] <Peng> ...You're running bzr as root...?
[19:01] <Peng> Oh, you're gone too.
[20:29] <EdWyse_Mobile> Any idea how to fix this segfault, http://paste2.org/p/601692 , in the 2.0 branch? ( or at least where to start looking )
[20:30] <poolie> hi EdWyse_Mobile
[20:30] <poolie> wow
[20:30] <poolie> please file a bug for it
[20:30] <poolie> basically i'd look at why that pointer could get to be null
[20:59] <Supertanker> Would it be appropriate to use bazaar to keep track of versions and revisions of my novella document files? Or am I looking for some other sort of backup/revision solution?
[21:32] <gutworth> Supertanker: do you write them?
[21:34] <ronny> anyone got an idea where jelmer is, i got a pair of trivial subvertpy patches for him
[21:46] <Supertanker> gutworth, yep
[21:46] <Supertanker> My current system is tons of .odt files in a directory with different names :P
[21:46] <gutworth> then that would be reasonable
[21:47] <Supertanker> Huh, okay.
[21:47] <gutworth> ah, bzr doesn't do great with binary files
[21:47] <Supertanker> I was just wondering if there was another way to do it.
[21:47] <Supertanker> I thought .odt was a sort of .xmlish format?
[21:47] <Supertanker> (Probably not :P)
[21:47] <gutworth> it's a compressed directory of xml files I believe
[21:47] <gutworth> so binary
[21:47] <Supertanker> O.o
[21:47] <Supertanker> Nope, it's not text
[21:47] <gutworth> /compressed/
[21:48] <Supertanker> Yeah, that makes sense
[21:48] <Supertanker> What about .abw files?
[21:48] <Supertanker> I believe those are plaintext.
[21:48] <Supertanker> Unless specifically saved as .abwz or .abwbz
[21:49] <Supertanker> Oh, there we go
[21:49] <Supertanker> I could save it as Open Document Text (Flat XML)
[23:11] <bendj> I'm setting up a bzr-based development/staging/production workflow.  Seems there are countless ways to do this.   It's just for me -- no other devs -- and I'm wondering (1) with atomic commits @dev, do I really need a standalone staging step? (2) should production be a branch, checkout, or rsync of a 'working' dev/staging branch? What do folks here do for 'best practice'?
[23:26] <spiv> bendj: it depends on what you want from your production rollouts
[23:27] <spiv> bendj: but keep in mind for example that neither 'bzr co' or 'rsync' will atomically update a tree on disk.  So if this a website, a client might hit the site while only half the files are updated.
[23:27] <bendj> spiv In my case, the production site is my live drupal (actually, pressflow) site.  and, no, i haven't figured out yet how i'll stage the databases .... ;-)
[23:28] <spiv> bendj: so you might want to checkout or rsync to a separate directory, then do a rename or update a config file to point at the new location, if that scenario concerns you.
[23:29] <spiv> bendj: but basically any of a checkout, rsync, or say the bzr-upload plugin will do an decent job of actually getting onto disk on your production server.
[23:30] <bendj> spiv Hm.. Hadn't considered the rename/update options.  Was thinking that I *need* to drive everything via bzr.
[23:30] <spiv> s/actually getting/actually getting files/
[23:31] <spiv> Well, a checkout that you update would have an advantage that it's easy to see which version has been rolled out compared to the current development version.
[23:31] <bendj> spiv except that rsync would leave the production site itself NOT under revision control, tight?
[23:31] <spiv> But depending on how tightly you control your rollout process, perhaps you'd already know that anyway.
[23:31] <bendj> Oh, ... didn't look up
[23:31] <spiv> bendj: right, but you're not going to be editing files on production are you? :)
[23:32] <bendj> Who me? Never! UhUh! Nope! No Sir!  That would be nuts! ;-p
[23:32] <spiv> :)
[23:34] <bendj> Well, to be technically correct -- I'll not be editing the production site's files.  I will be editing (occassionally0 ON the production box, but in dev/staging checkouts; I'm thinking about a bzr-server centralized repo scenario, and checkouts,etc to numerous locations as required (e.g., home, laptop, remote, etc etc)
[23:37] <bendj> Unrelated (mostly) question.  Can bzr be KDE (or would it be @filesystem) -integrated, so that the last N (say 10 ...) saved versions of a file are available?  E.g., doing image editing in a directory using GIMP, I could certainly do that if I checked out the file/directory first using bzr, then commit after edit.  But anything integrated as of yet?  I've seem such capabilities @ a Solaris demo once, but I think that was embodied in the ZFS file system.
[23:38] <bendj> s/seem/seen/
[23:44] <spiv> bendj: nothing integrated as yet, sadly
[23:44] <spiv> bendj: it would be lovely to have, of course!
[23:45] <spiv> bendj: I think it really would need to work at the app level rather than filesystem to work well, the filesystem just isn't given enough information to know reliably when a change has been fully written or if a replaced file is a new version of the old one or not.
[23:55] <bendj> spiv found it! -> http://www.serverwatch.com/tutorials/article.php/3831881/Say-Cheese-OpenSolaris-Time-Slider.htm
[23:55] <bendj> iirc, it's file-level restoration across numerous prior versions
[23:56] <bendj> using ZFS' capabilities.  i.e. @ the filesystem level
[23:59] <RAOF> Yeah; something similar will be possible with brtfs.