[00:14] <Kobaz> how would i perminantly remove a file/dir
[00:14] <Kobaz> and not just mark it deleted
[00:15] <Byrnison> bzr rm --force
[00:17] <Kobaz> k
[00:17] <Kobaz> and then... anyone know any good email notification hooks
[00:17] <Byrnison> I think. I just looked at the output of 'bzr rm --help' real quick.
[00:18] <Kobaz> i've been using svnnotify for subversion
[00:18] <Kobaz> Byrnison: i dunno about --force... i think --force will delete local files that aren't commited
[00:18] <Kobaz> kinda like svn delete --force
[00:19] <Byrnison> I haven't used Subversion for a while...
[00:19] <Kobaz> i've read in some comparisons that bzr has a perm delete
[00:19] <Kobaz> in other vcs's it's called obliterate
[00:19] <Byrnison> I'm testing --force
[00:19] <ia> hello, everybody. i have a question. if i want to create "trunk/branches"-model via bzr, i should run bzr init-repo my-repo, then create in my-repo directory trunk and branches directories manually and then run bzr add trunk branches, right?
[00:19] <Byrnison> Yep.
[00:20] <Byrnison> I think that is how, yes.
[00:20] <Kobaz> k
[00:20] <Kobaz> Byrnison: do you use any email hooks?
[00:20] <Byrnison> ia: But... add --no-trees to the command line.
[00:20] <Byrnison> No. I don't use Bazaar for anything complicated, or often at all, really.
[00:21] <hiredman> ia: you could create a repo, and, infact, bzr branch it, to create branches
[00:21] <Byrnison> I don't even really know how to use hooks.
[00:21] <hiredman> just to toss that idea out there
[00:24] <ia> well, then another question. from man page for bzr init-repo --no-trees and init repo/trunk said, that "create a shared repos holding _just_ branches". _just_ means that such repo couldn't be also working tree, right?
[00:25] <Byrnison> That is the purpose of --no-trees.
[00:25] <Byrnison> You could leave the option off if you wanted to use it like that.
[00:25] <Byrnison> But --no-trees would be useful if you were sharing the repo between other people, or if it was on a shared server.
[00:29] <ia> Byrnison, hiredman: thanks :-)
[02:49] <Kobaz> beuno: poke
[13:52] <mamatat> hi, i suddenly have this weird error when i run bzr status: http://pastebin.com/d1a77bd98
[13:52] <mamatat> any ideas what's going on?
[13:56] <Peng_> I wonder how you have a sys.version_info that isn't valid?
[13:59] <Peng_> Hmm, bzr 1.9 handles invalid plugin version tuples better. I wonder if that applies to sys.version_info too?
[14:01] <Peng_> No, it doesn't.
[14:02] <mamatat> bzr version bugs too
[14:02] <Peng_> mamatat: Out of curiosity, run this: python -c "import sys; print sys.version_info"
[14:03] <mamatat> (2, 5, 2, 'alpha', 0)
[14:05] <mamatat> 4th can't be 0 according to bzr code
[14:05] <mamatat>     elif __release_type in ('alpha', 'beta') and __sub != 0:
[14:05] <mamatat>         __sub_string = __release_type[0] + str(__sub)
[14:05] <Peng_> Yeah, you're right. (2, 5, 2, 'alpha', 1) is handled fine.
[14:06] <mamatat> argh
[14:08] <Peng_> Ehh, according to the docstring, that's intentional. "alpha 0" releases aren't "reasonable".
[14:11] <mamatat> yeah... figured out... it's explicitly forbiden by code... kinda makes sense but sucks that it happens now like that... it's not my server :(
[14:16] <mamatat> switched back to good'ol 2.4 but still get the first half of the errors (until 32)
[14:17] <Peng_> Yeah. I concentrated on the silly version formatting bug instead of the important part. Sorry. :P
[14:17] <mamatat> hehe...
[14:18] <Peng_> ISTM your working tree's state file got corrupted, but I'm not a developer. It could be some other sort of issue.
[14:18] <Peng_> You should wait for someone who knows that code to answer.
[14:20] <mamatat> hmm... thx for the help
[14:21] <mamatat> i hope things don't get corrupted too often too badly :S
[14:23] <Peng_> Like I said, I'm not sure. It could be a bug in the parser.
[14:28] <Peng_> mamatat: Um..mind if I send a patch to change the _format_version_tuple thing?
[14:29] <Peng_> (a (trivial) patch..)
[14:30] <mamatat> well it seems like a good thing not to run alpha0
[14:31] <Peng_> Heh.
[14:31] <Peng_> 2.5 is a stable branch; I doubt there would be issues.
[14:33] <mamatat> i'd rather file a ticket to hosting...
[14:33] <mamatat> need to figure out other bug... will try creating other working tree... need to remember how :S
[14:37] <Peng_> You could rename .bzr/checkout to something else and run "bzr co", but it might clobber changes you have in the working tree.
[14:37] <Peng_> You could also just make another branch.
[14:43] <mamatat> pff, now i get "bzr: ERROR: [Errno 5] Input/output error" on bzr status... not my day i guess
[14:49] <mamatat> Peng_: you know where this error might come from?
[14:49] <Peng_> Nope.
[14:52] <mamatat> not a very debuggeur friendly error... :(
[14:55] <LarstiQ> that sounds like a fs problem
[14:55] <LarstiQ> mamatat: see ~/.bzr.log or try with -Derror
[15:05] <mamatat> LarstiQ: http://pastebin.com/d18f1414f
[15:13] <mamatat> 'bzr status' seems to be not working well at all here and corrupted the branch... all other commands seem to work fine
[15:23] <Peng_> mamatat: Are you using a strange OS or file system? NFS?
[15:28] <mamatat> nfs i think... it's a hosting server not mine
[15:29] <mamatat> support says things work fine as long as bzr status is not used...
[15:30] <Peng_> Oh. Well, that shouldn't cause corruption, but NFS does have issues with locking.
[15:30] <Peng_> Hmm, isn't dirstate like the one case where bzr relies on OS locks, the very things that don't always work in NFS?
[15:30]  * Peng_ shrugs.
[15:31] <mamatat> i guess... apparently bugs have been filed to bzr about it and have been open for quite some time...
[15:34] <mamatat> how do you tell bzr to finally ignore a file that has been version controlled in the past
[15:50] <Peng_> mamatat: Stop versioning the file. ("bzr rm" or "bzr rm --keep" if you don't want to delete it.)
[15:50] <mamatat> thx
[15:52] <mamatat> hadn't thought of a 'rm --keep' command
[16:18] <BUGabundo> hi
[16:18] <BUGabundo> how do I restore just a file from an old revision»
[16:18] <BUGabundo> ?
[16:20] <james_w> "bzr revert -r rev filename"
[16:21] <BUGabundo> thanks james
[16:21] <BUGabundo> thanks james_w
[16:22] <BUGabundo> thanks you so much
[16:22] <BUGabundo> you are a life saver
[17:16] <mamatat> hi, i'm thinking of using bzr to merge and sync online and offline db. i would need to have a bot deal with running bzr for the online server. does anyone have experience or comments about something like that?
[17:51] <Peaker> why does bzr install a system tray icon in Ubuntu?
[17:51] <Peaker> it has nothing interesting, just a whoami configuration dialog...
[19:46] <mamatat> what's the easiest way to check from a script that everything has been commited (knowing that status crashes my branch)?
[19:47] <Peaker> mamatat: status crashes??
[19:47] <mamatat> yep :(
[19:48] <mamatat> some bug with nfs
[19:48] <Peaker> NFS sucks :-(
[19:48] <Peaker> Maybe sshfs is better
[19:48] <mamatat> well not my choice...
[19:48] <Peaker> mamatat: surely you can use an alternative mount?
[19:49] <mamatat> not sure... it's shared hosting... and not a big deal for status... but i do need to check things are commited
[19:52] <Peaker> mamatat: what kind of crash do you get with status?
[19:52] <mamatat> branch becomes broken
[19:53] <Peng_> Peaker: Earlier he put a traceback up at http://pastebin.com/d1a77bd98
[19:53] <Peng_> (he? she? it? anyway...)
[19:55] <Peaker> arrg, someone didn't wrap a %x  with %(x,) !!
[19:55] <Peaker> though that's the least of the problems
[19:56] <Peaker> (still worth a fix in bzrlib/__init__.py, probably)
[19:57] <Peng_> Oh, you're right. I didn't notice that one.
[19:57] <Peng_> ...It's been fixed.
[19:58] <Peaker> mamatat: probably best to solve the problem rather than the symptom
[19:59] <mamatat> what's the pb?
[19:59] <thumper> mamatat: bzr revno <remote branch>
[20:00] <thumper> mamatat: isn't exact, but useful and fast
[20:00] <thumper> mamatat: well, by exact, it doesn't tell you anything except the revno
[20:01] <mamatat> lol, ok thx
[20:01] <Peaker> mamatat: do you know Python?
[20:01] <mamatat> Peaker: hmm, depends...
[20:02] <mamatat> Peaker: won't get into bzr coding but am using it with django...
[20:02] <Peaker> mamatat: I'd debug that traceback
[20:02] <Peaker> mamatat: with pdb.pm() or such
[20:03] <Peaker> xpdb, maybe (shameless plug)
[20:03] <mamatat> i hear bugs have been filed about it...
[20:04] <mamatat> long time ago apparently
[20:04] <mamatat> https://bugs.launchpad.net/bzr/+bug/122106
[20:04] <mamatat> https://bugs.launchpad.net/bzr/+bug/108605
[20:06] <Peaker> mamatat: hmm, how do you reproduce the bug?
[20:08] <mamatat> i've tried to avoid doing that until now... :S might be everytime i run status but not sure
[20:09] <mamatat> on my machine, status works fine... bug is only on server
[22:04] <mwhudson_> is there a supported way to uninstall a hook?
[22:30] <spiv> mwhudson: Hmm
[22:30] <mwhudson> it sure doesn't look like it
[22:31] <spiv> ISTR raising this on the list, and it being decided as a YAGNI so far...
[22:32] <mwhudson> well i NI
[22:32] <spiv> :)
[22:35] <spiv> It doesn't seem hard to implement.  Basically it'd just do the equivalent of "Thing.hooks['pre_foo'].remove(callable)", plus removing the associated entry in _callable_names.
[22:35] <mwhudson> right, currently my code does this "Branch.hooks['transform_fallback_location'] = []"
[22:38] <luks> huh, "NoSuchFile: No such file: None"
[22:40] <spiv> mwhudson: this is outside a test, I assume?
[22:40] <mwhudson> spiv: yes
[22:40] <spiv> luks: over hpss?  I think I may have fixed that bug
[22:40] <spiv> mwhudson: interesting :)
[22:41] <mwhudson> spiv: i want to do
[22:41] <mwhudson> install_hook()
[22:41] <mwhudson> try:
[22:41] <mwhudson>    stuff
[22:41] <mwhudson> finally:
[22:41] <mwhudson>    uninstall_hook()
[22:41] <luks> spiv: yes, I'll try to pull from bzr.dev
[22:41] <spiv> That seems a bit weird, tbh.
[22:41] <mwhudson> (i only need to do this to make tests pass, mind)
[22:42] <spiv> Although having an unconditionally installed hook function that then looks at some (effectively) global state to decide what to do (if anything) is probably just as odd.
[22:42] <mwhudson> spiv: right
[22:43] <mwhudson> it's a bit of an odd hook, perhaps
[22:43] <mwhudson> the problem i have is that i want to use this hook to detect stacking loops
[22:43] <luks> spiv: thanks, current bzr.dev works
[22:43] <spiv> luks: great
[22:44] <spiv> luks: it was a bug introduced in 1.9 (#299254).
[22:44] <mwhudson> so having it installed for a long time tends to result in spurious loop errors
[22:46] <spiv> Well, I have no objection to adding an uninstall_name_hook or similar, and I see from the mail archives that jam agrees.
[22:47] <spiv> (The thread had the subject "[MERGE] Extend -Dhpss to emit a count of HPSS calls to stderr" if you care, although not very much was said on that topic)
[22:47] <mwhudson> spiv: is there a bug or patch or something
[22:47] <mwhudson> ?
[22:47] <spiv> None that I know of.
[22:48] <spiv> Feel free to submit a bug or patch or both :)
[22:48] <spiv> or something ;)
[22:48] <mwhudson> does a post it stuck to my monitor count?
[22:49] <spiv> If it results in a bug or patch, sure :
[22:49] <spiv> :)