Kobaz | how would i perminantly remove a file/dir | 00:14 |
---|---|---|
Kobaz | and not just mark it deleted | 00:14 |
Byrnison | bzr rm --force | 00:15 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:24 |
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:25 |
ia | Byrnison, hiredman: thanks :-) | 00:29 |
Kobaz | beuno: poke | 02:49 |
=== 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 | ||
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:52 |
Peng_ | I wonder how you have a sys.version_info that isn't valid? | 13:56 |
Peng_ | Hmm, bzr 1.9 handles invalid plugin version tuples better. I wonder if that applies to sys.version_info too? | 13:59 |
Peng_ | No, it doesn't. | 14:01 |
mamatat | bzr version bugs too | 14:02 |
Peng_ | mamatat: Out of curiosity, run this: python -c "import sys; print sys.version_info" | 14:02 |
mamatat | (2, 5, 2, 'alpha', 0) | 14:03 |
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:05 |
mamatat | argh | 14:06 |
Peng_ | Ehh, according to the docstring, that's intentional. "alpha 0" releases aren't "reasonable". | 14:08 |
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:11 |
mamatat | switched back to good'ol 2.4 but still get the first half of the errors (until 32) | 14:16 |
Peng_ | Yeah. I concentrated on the silly version formatting bug instead of the important part. Sorry. :P | 14:17 |
mamatat | hehe... | 14:17 |
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:18 |
mamatat | hmm... thx for the help | 14:20 |
mamatat | i hope things don't get corrupted too often too badly :S | 14:21 |
Peng_ | Like I said, I'm not sure. It could be a bug in the parser. | 14:23 |
Peng_ | mamatat: Um..mind if I send a patch to change the _format_version_tuple thing? | 14:28 |
Peng_ | (a (trivial) patch..) | 14:29 |
mamatat | well it seems like a good thing not to run alpha0 | 14:30 |
Peng_ | Heh. | 14:31 |
Peng_ | 2.5 is a stable branch; I doubt there would be issues. | 14:31 |
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:33 |
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:37 |
mamatat | pff, now i get "bzr: ERROR: [Errno 5] Input/output error" on bzr status... not my day i guess | 14:43 |
mamatat | Peng_: you know where this error might come from? | 14:49 |
Peng_ | Nope. | 14:49 |
mamatat | not a very debuggeur friendly error... :( | 14:52 |
LarstiQ | that sounds like a fs problem | 14:55 |
LarstiQ | mamatat: see ~/.bzr.log or try with -Derror | 14:55 |
mamatat | LarstiQ: http://pastebin.com/d18f1414f | 15:05 |
mamatat | 'bzr status' seems to be not working well at all here and corrupted the branch... all other commands seem to work fine | 15:13 |
Peng_ | mamatat: Are you using a strange OS or file system? NFS? | 15:23 |
mamatat | nfs i think... it's a hosting server not mine | 15:28 |
mamatat | support says things work fine as long as bzr status is not used... | 15:29 |
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:30 | |
mamatat | i guess... apparently bugs have been filed to bzr about it and have been open for quite some time... | 15:31 |
mamatat | how do you tell bzr to finally ignore a file that has been version controlled in the past | 15:34 |
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:50 |
mamatat | hadn't thought of a 'rm --keep' command | 15:52 |
BUGabundo | hi | 16:18 |
BUGabundo | how do I restore just a file from an old revision» | 16:18 |
BUGabundo | ? | 16:18 |
james_w | "bzr revert -r rev filename" | 16:20 |
BUGabundo | thanks james | 16:21 |
BUGabundo | thanks james_w | 16:21 |
BUGabundo | thanks you so much | 16:22 |
BUGabundo | you are a life saver | 16:22 |
=== Hydrogen is now known as HydroGone | ||
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:16 |
Peaker | why does bzr install a system tray icon in Ubuntu? | 17:51 |
Peaker | it has nothing interesting, just a whoami configuration dialog... | 17:51 |
=== RAOF_ is now known as RAOF | ||
mamatat | what's the easiest way to check from a script that everything has been commited (knowing that status crashes my branch)? | 19:46 |
Peaker | mamatat: status crashes?? | 19:47 |
mamatat | yep :( | 19:47 |
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:48 |
mamatat | not sure... it's shared hosting... and not a big deal for status... but i do need to check things are commited | 19:49 |
Peaker | mamatat: what kind of crash do you get with status? | 19:52 |
mamatat | branch becomes broken | 19:52 |
Peng_ | Peaker: Earlier he put a traceback up at http://pastebin.com/d1a77bd98 | 19:53 |
Peng_ | (he? she? it? anyway...) | 19:53 |
Peaker | arrg, someone didn't wrap a %x with %(x,) !! | 19:55 |
Peaker | though that's the least of the problems | 19:55 |
Peaker | (still worth a fix in bzrlib/__init__.py, probably) | 19:56 |
Peng_ | Oh, you're right. I didn't notice that one. | 19:57 |
Peng_ | ...It's been fixed. | 19:57 |
Peaker | mamatat: probably best to solve the problem rather than the symptom | 19:58 |
mamatat | what's the pb? | 19:59 |
thumper | mamatat: bzr revno <remote branch> | 19:59 |
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:00 |
mamatat | lol, ok thx | 20:01 |
Peaker | mamatat: do you know Python? | 20:01 |
mamatat | Peaker: hmm, depends... | 20:01 |
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:02 |
Peaker | xpdb, maybe (shameless plug) | 20:03 |
mamatat | i hear bugs have been filed about it... | 20:03 |
mamatat | long time ago apparently | 20:04 |
mamatat | https://bugs.launchpad.net/bzr/+bug/122106 | 20:04 |
ubottu | Ubuntu bug 122106 in bzr "UserWarning: lock on ... .bzr/checkout/dirstate ... not released" [Medium,Confirmed] | 20:04 |
mamatat | https://bugs.launchpad.net/bzr/+bug/108605 | 20:04 |
ubottu | Ubuntu bug 108605 in bzr "dirstate locks can fail on nfs" [Medium,Confirmed] | 20:04 |
Peaker | mamatat: hmm, how do you reproduce the bug? | 20:06 |
mamatat | i've tried to avoid doing that until now... :S might be everytime i run status but not sure | 20:08 |
mamatat | on my machine, status works fine... bug is only on server | 20:09 |
=== snova is now known as Byrnison | ||
=== sdboyer is now known as sdboyer|vurk | ||
mwhudson_ | is there a supported way to uninstall a hook? | 22:04 |
=== mwhudson_ is now known as mwhudson | ||
spiv | mwhudson: Hmm | 22:30 |
mwhudson | it sure doesn't look like it | 22:30 |
spiv | ISTR raising this on the list, and it being decided as a YAGNI so far... | 22:31 |
mwhudson | well i NI | 22:32 |
spiv | :) | 22:32 |
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:35 |
luks | huh, "NoSuchFile: No such file: None" | 22:38 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:46 |
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:47 |
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:48 |
spiv | If it results in a bug or patch, sure : | 22:49 |
spiv | :) | 22:49 |
=== Guest83236 is now known as jelmer | ||
=== jelmer is now known as Guest39692 | ||
=== Guest39692 is now known as jelmer |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!