[01:11] Hello there I am using bzr explorer and I was going to push code and I entered the wrong password (caps was on) but I can not fix this error . I am sure that it is right under my nose but I can not seem to fix this. I tried to sign in from command line to launchpad and all is well there [01:11] hi there [01:12] Hi poolie [01:12] you can't fix the problem meaning that it's not giving you a second chance to enter the password? [01:12] that's a bit icky [01:12] you should be able to find and edit authentication.conf [01:12] i think it's stored there [01:12] yup ^^ no 2nd chance [01:12] ohh cool thanks [01:12] you could file a bug at pad.lv/fb/bzr-explorer [01:12] cool will do [01:12] thanks poolie ! [01:13] np [02:02] gezz I still can get it worked out under that file there is no passwd this is the error that I am getting bzr: ERROR: Could not acquire lock "(remote lock)": I have tried to also break the lock but that also did not do anything [02:08] bobweaver, sometimes that means you don't have permission on the remote machine? [02:11] my ssh key is there [02:15] I am going to try and reboot [02:21] so a no go let me enter password and I def typed correct this time. must be lp ? [02:22] I can log into LP and all my old code is there and asys that it is owned by me [02:23] so if I have a shared repo somewhere on a machine that isn't up all the time, does it make any sense to rsync it over to another machine, or is that messed up thinking? [02:23] IE. what might be wierd about having multiple shared repos around. [02:25] I imagine I should have set up the shared repo on a server... and I guess I can dismantle the other one... but then might there be some benefit to not dismantling the original. [02:31] kbulgrien: I can't think of anything particular to shared repos that makes it any different from doing the same thing with any other set of branches. [02:31] kbulgrien: It just sounds like a management question of making sure people are pushing things into the right place, not somewhere that'll get overwritten. [02:34] can you sync the shared repos with bzr, or is just rsync the way to do that? [02:36] There's nothing in bzr at the moment that syncs repos. There's some stuff like multi-pull in bzrtools that gives you some automation of iterating over the branches, but it's all branch-at-a-time. [02:36] rsync is simpler. Could potentially lose you stuff if the right (wrong) things blow up in the middle. [02:38] I suppose --delete is out of the question. files never go away in the repo? [02:38] only add? [02:39] Along the lines that you could do two rsync one in each direction to make them the same. [02:39] if you were to have had things put separately in each. [02:39] Files go away with fair regularity. [02:40] ok [02:40] Multiple old files get repacked into one new file. With bad timing, you could get the old files --delete'd before the new one gets synced, and then the squirrel takes the last bite through the network cable... [02:41] :-) [02:41] nom nom nom [02:41] To be sure, it adds that extra savor to the squirrel stew that evening, but you get yelled at a lot before then. [02:42] its always faster doing it the second time eh? ;-) [02:46] maybe --delay-updates would foil the squirrel [02:51] Probably mostly it would make sense for one copy just to be the big giant backup that nobody ever uses except the mirror or the owner in a recovery situation. [02:51] Yeah. You definitely wouldn't want to try using rsync as a "keep both in sync while people are writing to both" thing. [02:52] seems like just a simple script to run 'bzr update' occasionally on whatever branch [02:52] You _could_ use bzr itself for that (I mean, that's just distributed development, right?) but I wouldn't try it automated. So it sounds like just extra complexity in that case too. [02:52] seems like the best way [02:52] cause i assume it knows how to deal with whats happening if its being updated at the same point you are trying to download it [02:53] so the problem is [02:53] and i think that the bzr docs say thats the preferred method [02:53] rsync isn't file-system order [02:53] bzr's primitives ensure ~0 data loss window if they are replayed in filesystem order [02:53] Obviously, the solution is "zfs send" 8-} [02:54] an external actor (like rsync) doing any of breadth-first, depth-first, etc traversals, with immediate or deferred deletes will create otherwise impossible situations in the receiving copy, if they happen concurrently with bzr acting on the repository [02:55] this is the same reason that rsyncing a postgresql DB has no guarantees in the absence of cooperation-with-postgresql [02:55] and we haven't written a cooperate-with-rsync/cp/etc module for bzr yet [02:55] (FWIW git and hg have the same issue, its not unique to bzr) [02:55] yeah. [02:55] * kbulgrien looks for a repo dump [02:55] thats wht the docs just suggest [02:55] using bzr update/pull [02:56] cause then that way it handles things correctly [02:56] one of the things that makes doing a cooperative thing for bzr is that we assume that fsync doesn't work ;) [for good reason] [03:01] ok multi-pull seems agnostic to what branches exist in a particular folder, so it could just pull everything it finds without someone having to say what to pull. [03:01] i believe it pulls all branches in a shared repo. [03:01] No, it doesn't care about repos one way or another. It's roughly equivalent to `find . -type bzr-branch -print | xargs -n1 bzr pull` [03:03] hmm and there is automirror [03:03] So, it'll pull a set of independent branches, the branches in one repo, the branches in a couple repos, some combination... whatever it finds under the dir you point it at. [03:03] its kind of a multipush I guess [03:04] ok, cool, learned something... I found the backup/restore stuff in the admin guide. [03:06] I think I read that if, I am the only one using stuff, rsync is faster and ok. Its when you can't guarantee the copied stuff is static that that becomes an issue. [03:07] That's what I gathered from the above comments too, so I think I get it. [03:07] rsync *can* be faster; it won't right after compactions [03:08] I would probably be better off sticking to bzr stuff though for sake of making myself more well-rounded and familiar with the tool set. [03:09] not to mention forgetting the nitpick and messing myself over once I was so used to using the unsafe tool. [03:10] I'll decline to admit how long I rsync backup'd postgres in the middle of the night ;-) before I wrote a dump script. [03:11] all the time knowing it wasn't really safe. [03:11] I do it every night. [03:12] Granted, I mostly care about and rely on the gzip'd dump file also in the dir tree being synced, but.. [03:14] I actually have mine pulling over dumps and the receiving system drops and rebuilds everything based on what it just pulled over. [03:15] Anyway... trying to get geared up to do bzr stuff in a way so I have a hot backup. [05:43] Hi folks. I would like to check out files both on windows and linux and have bzr ignore differing line endings. My rules has a name * eol = native but that isn't helping. What am I doin wrong here? [05:43] hm, that should do it [05:43] does bzr try to convert line endings for you? [05:43] that seems weird o.o [05:44] what do you mean more specifically by 'not helping'? [05:44] poolie: when I run a bzr st, all files are reported as changed, but when I do a qdiff and "Ignore whitespace differences" there are no changes [05:45] mgrandi: I don't know but if it were then that would be a whitespace change in every file wouldn't it... [05:46] i dunno, i thought bzr would just bersion the file and not try and modify line endings [05:49] If you hit 'commit', does it actually try to commit those changes, or does it say there's nothing to do? [05:50] I didn't try committing it. Odd thing is that when I do a revert... it doesn't revert it still reports modifications. [05:57] mgrandi: only if you configure it to do so [05:58] ah [08:05] morning [08:06] hey [08:06] if you are up that means i'm up way too late. hmm [08:07] I think it just means he's up way too early. [08:07] I mean, the sun probably isn't even down yet where he is. [08:07] so, i did a revert the other day and i cant revert the tree cause its says TreeTransform is malformed [08:07] wat do [08:13] or rather should i just report a bug / upload the branch [08:16] so, the problem with TreeTransform errors, is without a clear way to reproduce there's not much to go on [08:16] ideally you should work out what change is problematic, and reproduce it in a fresh branch, giving steps in bug report [08:17] it's generally easy enough to work around not being able to revert something, just branch to a new location from the rev that you're trying to revert from [08:18] a bug report and packed up branch wouldn't hurt though, if you confirm that someone downloading and trying the steps you give will get the same error [08:19] yeah, i zipped up the branch [08:23] and just report a bug then? [08:24] sure, but trying to reproduce from scratch woul still be very useful. [08:24] well i just tried it (with the branch that i zipped) and if you do bzr revert on it then it still crashes [08:25] how do you mean do it from scratch, as in make a new branch and try do the steps to break it? [08:28] right, and you can search the existing bugs to see if one of those already covers your case [08:29] k [08:30] eg bug 632704 and bug 660125 [08:30] Launchpad bug 632704 in Bazaar "Can't merge a directory deletion in a wt with a pending subdirectory deletion" [High,Confirmed] https://launchpad.net/bugs/632704 [08:30] Launchpad bug 660125 in Bazaar "shelve crashes with "Tree transform is malformed" when renamed file already exists" [Medium,Confirmed] https://launchpad.net/bugs/660125 [08:30] working out what the particular case that's making it fail for you is the most relevent thing [08:32] i know i was doing some renaming stuff [08:33] but its late and i'll do it this weekend, and if jelmer is here i'm also having problems with bzr-git >.> [08:34] What's 'stat' look like? [08:34] bzr status on the branch? [08:34] Yah. Well, on the WT, but 6.5 of one... [08:36] its ugly D: http://bpaste.net/show/26999/ [08:37] not sure what the * means in 'modified' [08:37] +/-x [08:38] Hm. How about this part. [08:38] ah, yeah, i never modified the +x by myself [08:38] removed: php_frontend/src/codeigniter/system/libraries/Twig/lib/ [08:38] unknown: php_frontend/src/codeigniter/system/libraries/Twig/lib/ [08:38] What if you rm (or move aside) that unknown dir? [08:39] that looks like a winner. [08:39] yeah [08:39] that fixed it. [08:40] so now the question is how it got into that weird state o.o [08:44] A little fiddling with trivial similar setups doesn't show up any problems, so it's liable to be a little twisted. [08:47] i have the log so ill be able to recreate exactly what i did [08:51] mgrandi: hey [08:51] hey [08:52] so, i have a bzr branch that i was using to do stuff with github [08:52] and one branch is just a straight up copy of someones github repo, i haven't done anything to it [08:52] i tried updating it and bzr-git says the branches have diverged, and to do 'bzr missing' to see why, but then bzr missing says 'git smart protocol doesn't support that' [08:54] mgrandi: yeah, the git protocol doesn't support remote graph inspecition [08:54] then i just tried branching it again in a brand new branch, and i get: bzr: ERROR: Could not determine revno for {git-v1:78d796d1f018bb66d986e73bc4641b6c0b372a55} because its ancestry shows a ghost at {git-v1:78d796d1f018bb66d986e73bc4641b6c0b372a55} [08:55] what version of bzr-git? [08:55] how do you get versions of the plugins? [08:56] mgrandi: 'bzr plugins' [08:56] git 0.6.8dev [08:56] hmmok, that's fairly recent [08:56] I'm not sure what's going on there, without looking into it in more detail [08:58] it seems that its something to do with the repo, since making a folder outside of the repo i have works fine [08:58] mgrandi: aha [08:58] is the repo old, does it perhaps have revisions that might have been fetched with old (broken?) versions of bzr-git? [08:59] the repo isnt that old, and i think ive been using this version of bzr git for a while [09:01] the last commit i have in that branch is Fri 2012-02-24 21:16:15 -0200 [09:01] or that came from the guy whose github i'm branching [09:03] Well, I give up. I've tried a handful of likely-looking slices of those changes, and I don't get any blowups with 2.5 or .dev. [09:04] fullermd: i finally scrolled through my log so i have the exact commands i did [09:04] so i'll try and recreate it [09:05] What version are you running? [09:05] 2.5.0 [09:06] Oh well. [09:07] the rename of files from a subdir of that clashing directory looks interesting for the revert [09:07] mgrandi: so, I'm out of ideas too without looking into the issue more closely [09:07] do you want the entire shared repo / branch? [09:08] http://paste.ubuntu.com/927613/ is the script I worked up for testing. [09:08] But it works as expected for me, so it's something more than just moving files out of the subdir but leaving it sitting there. [09:08] And more than having other stuff beside it also being moved around. [09:09] you're a twinkling object in the night sky, fullermd [09:10] im uploading the repo/branch/ and bzr.log output [09:10] Yeah, I blow a lot of hot gas around sometimes. [09:11] its ugly cause im new to this framework and i couldn't figure out where to put this one library so thats why i have so many 'bzr move' and whatnot, but here it is: www.kramidnarg.com/stuff/tree%20transform%20bug.zip [09:42] Does that include the branch in the state where the revert blows up? [09:42] yeah [09:42] Works for me. [09:42] in 'tmprepo.zip' [09:42] really? doing bzr revert inside tmprepo/enquest_work works for you? [09:43] Yep. With .dev and 2.5.0. [09:43] soooo why does mine not work then [09:44] Now, here's one difference: You're apparently on OS X. [09:45] yeah [09:45] maybe a platform dif... what fullermd said [09:45] Maybe the fs is doing something with the .DS_STORE's? [09:45] bzr 2.5.0 on python 2.6.7 (Darwin-11.3.0-x86_64-i386-64bit) [09:46] does bzr even use .ds_store? how would that effect it [09:46] and i think i have those ignored anyway [09:46] OS X does do some special stuff with unicode normalization, but it looks like all the filenames are 7-bit ASCII, so it's probably not that. [09:46] No, but maybe it hits some conflict with the forks when moving stuff around, since the OS treats them special? [09:46] my first guess was directory rename differences, but that was assuming windows rather than osx [09:46] * fullermd is guessing pretty randomly... [09:47] mac is not case sensitive...which is weird [09:47] maybe that? [09:47] allowing renaming over an existing (empty) dir is a posix thing, but osx should allow it too [09:47] Mmm. I thought it was. [09:47] case things is also a possibility. [09:48] /users/markgrandi is the same as /Users/markgrandi, i dont know if python forces a case sensitivity [09:48] HFS+ supprts case sensitivity but mac os x doesn't do it for some reason [09:48] Oh, right, it's case-insensitive-but-case-preserving. [09:49] That's the most likely place, yah. Nothing jumps out at me immediately though. [09:49] are you on windows or linux fullermd [09:50] Neither, naturally. I have [daemonic] standards ;p [09:50] heh [09:50] i'll try on my windows/linux machines later [09:50] when its not 3 am [09:52] Give http://paste.ubuntu.com/927663/ a try locally. [09:52] (prob. have to fix the bzr path or something anyway) [09:52] 's a few tweaks past the one I pasted earlier. Still works for me, but since yours does too, maybe it'll blow up for you. [09:52] Get you a step closer to an isolated testcase anyway. [09:54] dear ubuntu: why do i have to log in to download a paste. signed, me [09:54] Anyway. 's way over my time quota; I've gotta get back to pretending to work in preparation for tomorrow's (later today's) pointless conference call. [09:55] ok [09:55] i'll let you know what happens [10:33] going to bed, i'll be on later to discuss these problems more, ttyl~ [22:19] how can I disable the spinner/speed on actions on ssh repositories? [22:20] also can I make bzr use /bin/ssh instead of paramiko, so it reuses established master session? [22:30] got it, BZR_SSH=openssh BZR_PROGRESS_BAR=none === yofel_ is now known as yofel