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