[00:03] mgz: I think the current 'best fix' is to just catch the error and re-raise something that indicates what files are involved [00:04] it may not be the final fix, but it at least progresses us to where users get informed that there is a problem with specific files [00:06] jam: unrelated question, what's the minimum cython version that should work? had issues with _simple_set_pyx.pyx on my old debian box. [00:07] mgz: 0.11? I'm not really sure. pyrex 0.9.6 comes to mind [00:07] I know 0.9.4 has bugs [00:08] hm, python-pyrex seems to be mispackaged on lenny though, and cython is only 0.9.8 [00:09] I'll leave it on the python versions till I get round to updating. === mbarnett changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.2.4 officially released, 2.3.0 frozen. Release plugins ! Build installers ! (rm vila) [01:07] is --hardlink supposed to work on windows? 2.3 crashes here with that option: bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'link' [01:08] kkrev: no, it could probably be made to work, but it does not currently. [01:11] mkanat, mwhudson: Are you guys around? I'm wondering if people are still getting the merge proposal emails for loggerhead. You don't have to do any reviews, but the team was changed to 'loggerhead-team', and I'm getting noisy bounces from a launchpad list [01:11] so I want to make sure whether anyone is seeing the requests at all === Ursinha is now known as Ursinha-afk [01:11] jam: My contract with Canonical is unfortunately over. [01:11] jam: i've seen some of them [01:12] jam: I have seen the emails, though. [01:12] mkanat: no issue for me here, just making sure emails are getting out [01:12] I didn't know if it was going dark because of the target change [01:12] jam, i suggest you request reviews from bzr people [01:12] and also get lp admins to repopulate that team appropriately [01:13] poolie: I'm not really sure who should be in loggerhead-team, but I'm in ti [01:13] it [01:14] from the discussions, lp is supposed to be taking over the review process, and I'm a little unsure what the short-term plan is for the branch. [01:14] We need a timeline for merging 'experimental' into the new lp:loggerhead - in particular whether all of experimental will land at once, or if it's worth re-landing some of the smaller changes first [01:14] i got some of those bounces myself [01:14] there is a thread about it [01:14] I know I've read robert's stuff, but he seems to indicate lp squads will actually do something, which has not really been my experience [01:14] maxb: I'm starting with getting it up to the level of pqm [01:14] i don't think they are as proactive on reviews as we are [01:14] reverting all the way to 422 takes out a fair amount of stuff, like even the view pages [01:14] and we could do better, at that [01:15] i did get your review mails [01:15] poolie: sure. The question is, who is actually going to say something about the future of that branch? I have direct commit rights still, so I could just do it TM [01:15] you can certainly nag me or your other team mates [01:16] let's review them and commit [01:16] poolie: there is still the 'experimental' branch issue, which needs oversite. Which robert had a rough proposal for, but needs someone actually doing the various bits. "watch production like a hawk after rollout", "try to load test on qastaging", etc. [01:17] I'm willing to push a bit on it [01:17] in the "get the stuff I did actually out to people" sense [01:17] But though I know a bit about the process, it still always feels nebulous [01:18] and certainly, nobody other than lifeless seems to notice anything, which seems to go against the point of his experiment [01:18] poolie: for example, what do we do with the SocketException code. You reviewed it, but is that 'official' enough to land it? [01:18] I investigated the HEAD returns BODY bug [01:19] but it seems a general WSGI issue [01:19] that is much bigger than "if REQUEST_METHOD == 'HEAD'" [01:19] namely, you have to get all the headers correct, so the general recommendation [01:19] yeah i was a bit afraid robert would say "yes we'll maintain it; revert; " [01:19] is to do all the work, and at the top-most level strip the body [01:19] i think wsgi makes it easy to get HEAD wrong [01:19] mm [01:20] poolie: did you see the link I posted to the bug? [01:20] well, that's a very general issue [01:20] i did [01:20] http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html [01:20] if there are things that are expensive to compute and not mandatory to have present, we don't need to do them [01:20] it basically says, because of how applications stack on eachother's content streams, it is very hard to get identical headers without actually doing all the work [01:20] true [01:20] poolie: Content-Length is the biggest problem [01:21] since, you can omit it, but if you aren't omitting it from the GET request, you're technically in violation [01:21] You don't have to return Content-Length for a HEAD request, though. [01:21] and you have to have Content-Length to preserve Keep Alive, I believe [01:21] well [01:21] spiv: correct. *but* the spec says the headers must be identical to the GET headers. [01:21] no, not for a head request, since there must be no body in it [01:22] mmm [01:22] The quote he gave was: "The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. " [01:22] My guess is in practice it's fine to omit Content-Length; I'd check with lifeless [01:22] well, that's must vs should [01:22] i'm sure that's correct [01:22] anyhow, for dynamic resources [01:22] "If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length" [01:22] there is no guarantee that the length you get from one HEAD is going to have any necessary relation to what you get from a later GET [01:23] that makes Content-Length one of the things that should be preserved [01:23] poolie: sure. [01:23] but the question is, what is HEAD being used for? [01:23] in this case it's being used as "are you there"? [01:23] [01:23] poolie: sure, I'd be fine just adding a HEAD_middleware that just omits the content bytes [01:24] so i do think it would be wrong to say "length=0" [01:24] start_response is the call that writes the headers [01:24] you can have it return a no-op write function [01:24] and always yeild nothing, but consume the child apps [01:24] and i read that article as saying that wsgi's interface makes it very easy to get this wrong and end up with something saying the wrong length [01:24] anyhow, i think it's pretty obvious that returning a body on HEAD is a much worse violation of the rfc [01:25] I've seen servers that return bodies from HEAD cause weird breakage. [01:25] poolie: sure [01:25] that is really not defensible [01:25] Apache strips it for us in the public site [01:25] Because it understandably screws up pipelining [01:25] I think it is broken for 'bzr serve --http' [01:26] So it's a pretty severe bug (and one that tends to cause breakage on subsequent requests that are otherwise bug-free) [01:26] if we started sending last-modified dates and especially if we started respecting if-modified-since it would probably be important that HEAD sends the correct date [01:26] and it's just thrashing the machine to no good purpose [01:26] poolie: just confirmed that 'bzr serve --http' does it wrong [01:27] poolie: I doubt *thrashing* is the word for something that is requested every 10s on a reasonably small branch [01:27] huh, i thought i tested that but perhaps not [01:27] ok, 'loading' [01:28] poolie: when I first tested it with socket.recv() [01:28] I got it wrong [01:28] I did an initial recv() [01:28] and it returned just the header line [01:28] but that was becuase it was busy churning through the rest of the data [01:28] i think i tested it using curl, and probably curl discards any body sent from HEAD [01:28] once it had been cached and up to date [01:28] then recv() started returning the full content [01:28] jam: more or less load than ('x', 'y') vs. 'x:y' in hook registration? *wink* [01:28] :) [01:28] spiv: significantly more [01:28] but not a startup overhead [01:29] :) [01:29] ok, so we'll agree that bug about head should be fixed? [01:29] spiv, how's bug 603395? [01:29] Launchpad bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propagate new tags" [High,In progress] https://launchpad.net/bugs/603395 [01:30] poolie: I agree there is a bug that paste's HEAD handler doesn't strip the body, which I'll post a fix for in about 20 min [01:34] poolie: erk, closed the bug. The confusion was that the merge proposal state didn't record the fact that while one fix was rejected for 2.2 it was landed on 2.3 (trunk at the time) instead. [01:36] thanks jam; there's a bug number for that too [01:36] no, there isn't? [01:37] poolie: the HEAD stuff? there isn't a separate bug AFAIK, just bug 701329 [01:37] Launchpad bug 701329 in Launchpad itself "loggerhead OOPS - error: [Errno 32] Broken pipe" [Critical,Triaged] https://launchpad.net/bugs/701329 [01:37] but I can report one if you like [01:38] i just did, bug 716201 [01:38] Launchpad bug 716201 in loggerhead "loggerhead sends body content on HEAD request" [High,In progress] https://launchpad.net/bugs/716201 === arjenAU2_ is now known as arjenAU === oubiwann_ is now known as oubiwann [07:33] hi all [08:03] * fullermd waves vila around. [08:17] fullermd: hey ! [08:18] SGIBART and SIGTERM seem to behave differently regarding the children of the process receiving the signal, did that ring any bell ? [08:18] No, SIGBELL is for ringing bells... [08:19] SIGABRT ? [08:19] I couldn't find any answer to that with google :-/ [08:19] yeah, SIG -9 [08:19] that's SIGKILL [08:20] I'm pretty sure neither signal (or any signal...) does anything to processes other than the one you're hitting with it. It may _catch_ the signal and do something unspeakable to its kids, but that's nothing to do with the signal itself... [08:20] And yeah, SIGABRT is 6. [08:20] * maxb believes the same [08:21] hmm, is it just that I mixed ABRT and KILL ?!?! [08:21] Mixing anything with KILL has unpleasant side effects :p [08:22] like zombies maybe ? ;D [08:23] KILL is uncatchable death; ABRT is catchable coredump-and-die [08:23] damn damn damn, my google history confirms I've been climbing the SIGABRT tree, ctrl-alt-del [08:26] No, that's SIGSQUIRRELYPCHISTORICALBAGGAGE :p [08:26] * vila notes: -9 != SIGABRT [08:29] ok, SIGKILL passed a test that SIGABRT didn't... weird [08:30] so the test is spawning a 'sh -c yes' and killing the shell [08:30] I've seen 'yes' staying alive... and detach from the test process [08:30] s/detach/detached/ [08:31] The shell may catch SIGABRT and kill its children. It doesn't have a chance with KILL. [08:31] right, no change with KILL is clear, but how is 'yes' killed ? [08:31] s/change/chance/ [08:32] I call kill with the pid of the shell, no fancy group stuff or else [08:32] anything else (gee tyops day) [08:32] If I "sh -c yes", sh just exec's yes, it doesn't hang around to do anything. [08:34] hmm, no, I'm pretty sure I had distinct processes [08:34] I don't. [08:34] the sh one being reported as defunct [08:34] 45845 sh CALL execve(0x800c30378,0x800c30260,0x800c30270) [08:34] 45845 sh NAMI "/usr/bin/yes" [08:34] 45845 sh NAMI "/libexec/ld-elf.so.1" [08:34] 45845 yes RET execve 0 [08:34] (same pid that starts out the run as 'ktrace', exec's sh, exec's yes) [08:34] right, looks like subprocess.Popen(...shell=True...) is not exactly sh -c yes then [08:37] http://paste.ubuntu.com/565278/ [08:39] *blinks* [08:40] fullermd: *not* same pid even if 'sh -c yes' is clearly (or is it) what 'ps jef' displays... [08:41] 'morning [08:41] Defunct would mean it's a zombie. [08:41] yup, and its children got reparent to 1 [08:42] Which you'd expect. [08:43] well, no, because 'yes' is still connected to its grand-parent process via pipes [08:43] I managed to kill it when it reaches the 8GB mark one of the first times I debugged it ;) [08:44] That doesn't matter. When the parent goes away, it parents right off to init. [08:44] yup, understaood [08:44] but what I don't get is why this occurs with ABRT but not KILL [08:44] may be I should just forget about that, I shouldn't use ABRT anyway [08:45] There are some things man was not meant to enquire into... [08:46] after all, the bug I'm after is about a children clogging the pipes, leading to a parent hang. 8GB collected is good enough proof that the parent is not hanging anymore (even if I can only reproduce it manually) [08:49] fullermd, maxb: Thanks for the teddy-bearing, ABRT != KILL [08:54] jelmer: hey ! Are you feeling better ? [09:09] vila: hey [09:10] vila: good enough to work.. perhaps I'll stick to easier things today [09:10] jelmer: it's amazing how this flu is spreading... I'm not feeling that good myself but I thought I should blame my gf which is getting back to work today [09:11] and now spiv got one too... [09:11] and jam's son [09:15] indeed ! poolie ! watch out ! :) [09:18] :) [09:21] is it possible to use bazaar with a samba share on os x? [09:22] looks like there is an open bug [09:22] but I wondered if anyone knew a workaround [09:22] the bugs been open for 4 years [09:22] thrope: which bug? [09:22] https://bugs.launchpad.net/bzr/+bug/31006 [09:23] thrope: are you sure it's a samba server on the other end, not a windows machine? [09:23] yes [09:23] its a ubuntu server [09:23] at least newer versions of samba should support os locking I think [09:24] 10.10 fresh install [09:24] probably mac os x that doesn't support os locks over smb then :-/ [09:24] yep [09:26] ah ok - my apologies, I guess not really a bazaar bug then [09:26] but it would be nice to be able to do it [09:26] thrope: don't forget to meeto the bug (#98836 in this case, 31006 is a duplicate) [09:26] thrope: it's on the TODO list, but not high enough yet :-/ [09:26] thrope: it's fundamentally a mac os X bug, but that bzr bug you linked to would work around the mac os X bug [09:27] ok got it [09:28] do you think smbfs over fuse would have the same problem? [09:28] rather than the os x built in one [09:29] the fusesmb homepage doesn't say anything about locking, but I'm not sure [09:54] vila: Well, don't sneeze in my direction! [09:55] * vila aims... === Ursinha-afk is now known as Ursinha [11:57] Is anyone else finding bzr's new behaviour of dumping the full plugin list to stderr when a traceback occurs to be somewhat annoying? [11:57] Since the traceback disappears off screen [11:57] is that new? [11:58] I can't say I've noticed it, but I don't think it would bug me that much... the traceback is already way offscreen anyway. [11:59] Why is it already way offscreen? before the plugin list was added, there were only a few lines after it [11:59] I'm pretty sure those "few" lines were already half a term full. There's only 25 lines to work with... [12:00] And the traceback itself is often 20 or so frames deep, with 2 lines per frame, so it couldn't fit even by itself. [12:01] But that's what scrollback is for anyway. [12:06] fullermd: But, the exception is at the bottom of the traceback, and formerly there were only 9 lines after it. So, you got to see the exception. [12:06] Now, you don't [12:06] * fullermd shrugs. [12:06] maxb: IIRC the idea was to output only the plugins that are potentially out-of-date API-wise [12:06] I always remember having to scroll back to figure out what was going on anyway. It's not something that happens to me often either way. [12:06] I don't remember the intent was to display *all* plugins [12:06] Somewhere along the way it turned into a full `bzr plugins` output [12:07] worth filing a bug then, I don't see what value is added by displaying perfectly fine and probably unrelated plugins [12:07] I have sidestepped the issue for now by adding bzrlib.crash._format_plugin_list = lambda: '*elided*' to ~/.bazaar/plugins/maxb.py :-) [12:15] statik, ping ? [12:16] shudder [12:16] you don't like my hack, vila? [12:16] thread is a python module (use discouraged in favour of threading), I forgot about that when creating bzrlib.thread [12:17] ohdear [12:17] maxb: oh no ! As long as a bug if filed so we don't forget your valid point [12:17] so I need to find a new name... safethread sounds a bit pretentious catchingexceptionthread a bit long... [12:18] threadeling ? [12:18] cethread ? [12:19] Or, you could declare that you're looking forward to the future where relative imports are explicit only :-) [12:19] vade retro satanas ;D [12:20] I'll go with cethreads for now and see what reviewers think [12:21] doh ! rm bzrlib/thread.pyc, I hate that one [12:22] eeerk ! plugin list !!! [12:22] maxb: gee, now I see your point :-} [12:22] ha :-) [12:23] it's ~120 lines here 8-} [12:23] fullermd: *4* lines by plugin [12:25] I'm so used to scrollback on exceptions that I didn't notice earlier [12:28] filed bug 716389 [12:28] Launchpad bug 716389 in Bazaar "In-terminal crash report is far too long, containing full `bzr plugins` output" [Undecided,New] https://launchpad.net/bugs/716389 [12:29] thanks ! [12:30] It's all about choosing where to apply pressure, see... [12:31] If we make the crash report painful enough, we create pressure to make sure things don't crash :p [12:31] maxb: metoo'ed [12:32] hehe, the original intent was to point people to their outdated plugins *before* they file a bug against bzr [12:32] fullermd: In that case we need an "I'm a developer just show me a traceback" debug flag [12:33] well, I'm a lazy dev , running plugins from their trunk and I often forgot to update them in a timely manner ;) [12:34] hmm, it's even worse than that, I use a mix of plugins installed in the system libraries and some in ~/.bazaar/plugins (which is a farm link to add to the fun ;) [12:35] anyway, 120 > 84 and I have no plan for a 30" screen yet [12:35] I do. I totally do. [12:35] Now, _budget_ for a 30" screen, that's another matter... [12:54] stop spending that much in ECC and raids ;-D [12:54] afternoon all. [12:55] can loggerhead do a diff between two branches, like bzr merge --preview? [12:58] Pfft. If I did that, bzr would crash and I'd never be able to read _anything_ on my terminal :p [12:59] something in the lp stack is doing it... [13:24] warnocked! [13:24] no loggerhead experts? [13:25] No, loggerhead cannot [13:26] maxb: thanks. [13:26] shame ... [13:27] it's nice to be able to review code before deciding to merge, and it's nice to be able to paste around links that other people can use to review possible merges. [13:29] vila: yeah, my son finally doesn't have a fever, though he threw up this morning. [13:30] vila: so be careful. I've had large swaths of people I know hit by feeling sick [13:30] jam: :-/ Such a nice way to start the day :-/ [13:30] maxb: OK, I think I can merge from trunk into the feature branch, and then persaude loggerhead to show me the diff between the head of the feature branch and the recently merged trunk revision (which is a dotted revision number) [13:30] maxb: does that sound plausible [13:30] right, so I should blame you for Valentine's flu then :-D [13:30] unfortunately I'm bitten by https://bugs.launchpad.net/loggerhead/+bug/602600 so I need to upgrade loggerhead. [13:31] quicksilver: check with jam, loggerhead's trunk is not anymore what it used to be === lionel__ is now known as lionel [13:32] vila: in my description I wasn't talking about loggerhead's trunk [13:32] I was talking about my own repositories trunk :) [13:32] quicksilver: lp:loggerhead recently reverted to an old old revision [13:32] which doesn't include the history-db code, and thus couldn't be affected by bug 602600 [13:32] Launchpad bug 602600 in loggerhead "Error on dotted revisions" [High,Fix released] https://launchpad.net/bugs/602600 [13:33] quicksilver: sry, I got confused, but are you talking about lp's loggerhead or an instance you're running yourself ? [13:33] however, lp:~loggerhead-team/loggerhead/experimental has all the updates [13:33] vila: I didn't say that, so the confusion is of my making, sorry. [13:33] vila: we have a local loggerhead install. [13:33] jam: did lp rollback for a good reason? Should I avoid upgrading my local install to 1.18? [13:34] jam meets quicksilver, quicksilver meets jam, I'm sure you have interesting bits to share ;) [13:35] jam: should I answer that while you take a deep breath ? [13:36] quicksilver: loggerhead hasn't had a strong maintainer in a while. lifeless wanted the launchpad-team to take over maintenance, but basically wanted to roll back to the point where loggerhead has been deployed in production [13:37] I'm slowly pushing to get things back up to where it was [13:37] ah. scary. [13:37] quicksilver: not for you unless your instance can receive the same kind of load as lp [13:37] quicksilver: loggerhead's old trunk (now "experimental") seems very stable for most installs, but what Launchpad needs as a giant codehosting site is a bit different [13:37] we've been running the debian package of "1.17+bzr424-1" [13:37] quicksilver: I meant, not scary for you [13:37] I see. [13:37] yes, we only have a handful of users. [13:38] we just want repo browsing + diffs [13:38] mostly diffs, actually. We paste the urls into our automatic commit emails. [13:38] quicksilver: I think the experimental stuff will have some very big long-term gains, which is why I'm pushing it, but it potentially regresses some immediate concerns. [13:38] * quicksilver nods [13:38] it's been fine for us, until I wanted to generate a URL for what git people call a "pull request" [13:38] and discovered that I couldn't do that. [13:39] I could make a throwaway branch and actually do the merge in that and use that as a URL, I guess. [13:40] quicksilver: isn't that just "please merge my tip"? I don't see exactly what you are wanting out of the pull request [13:40] or is it that they want "pull" to work, rather than "merge"? [13:40] jam: I want them to be able to examine the diff before they do it. [13:40] for code review. [13:40] obviously they can run bzr merge --preview locally [13:40] yeah, people want the nice merge request interface like launchpad [13:40] I just wanted a URL which contained the output of bzr merge --preview [13:41] and looking nice. === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3.0 is officially out ! (rm vila) [13:41] quicksilver: sure. We use launchpad merge proposals for that, but it doesn't cover people just using loggerhead [13:41] * quicksilver nods [13:41] I think I'll do the throwaway branch thing [13:42] quicksilver: I think it would be reasonable to add a feature/bug request on loggerhead for a merge --preview type view [13:42] I don't know who would actually get around to coding it, but it does seem like something you should be able to get from loggerhead [13:42] jam: well the other alternative would have been to actually commit the reverse merge [13:42] (which is quite common practice anyway, to resolve conflicts before merging) [13:42] then I would have a 'dotted revision' to diff against. [13:43] which loggerhead ought to be able to do - but see the bug above :) [13:43] quicksilver: well, you could always show the diff vs the "ancestor:" but loggerhead should make that available, rather than you having to do it yourself [13:44] and merge --preview exists because you can get conflicts while merging [13:44] * quicksilver nods [13:44] vs "diff -r ancestor:" which will never show a conflict [13:44] I don't think I know what ancestor: means. [13:44] quicksilver: try "bzr diff -r ancestor:../other-branch" [13:45] it finds the most recent common ancestor of this branch and other-branch [13:45] ah, handy. [13:45] so 'bzr diff -r ancestor:../other/branch" shows you what is new in your current branch, vs the ancestor of the othe rbranch [13:45] I normally dig manually through the output of bzr log -n0 and copy-paste the ancestor revno :) [13:45] so you don't see the changes in trunk being removed in your branch [13:46] quicksilver: bzr log -n0 -r ancestor:../other/branch should show you what rev it is :) [13:46] * quicksilver nods [13:47] getting software right is hard. [13:51] I can't even understand how we managed to install the squeeze deb of loggerhead when we're only running lenny on this machine. [13:51] heh :-) [13:51] each rabbithole leads to a door which opens into a deeper rabbithole [13:52] I don't think uprading loggerhead is going to be the most time-efficient thing for me to do this afternoon. [13:52] quicksilver: tbh, I think for most people the best way to "install" loggerhead is probably just 'bzr branch lp:loggerhead' [13:53] and then upgrading is "bzr pull" [13:53] you may be right. [13:53] It looks like the debian package has no harsh dependencies [13:54] so I think someone just downloaded it from squeeze and dpkg -i'ed it by hand. [13:54] btw, of the package you are running, the only thing of importance that got removed from trunk was the initial landing of the history-db branch [13:55] Also, if you want to go to 1.18, 1.18 doesn't include anything that was removed from trunk [13:55] maxb: what odes the history-db branch do? [13:56] It's jam's big make-it-faster-by-caching-stuff project [14:02] Hi, I need help for solve a conflict of type "Contents conflict in " I read the doc on http://doc.bazaar.canonical.com/bzr.0.92/en/user-guide/conflicts.html [14:02] so, I am using bzr mv as: [14:02] bzr mv Connection.java.OTHER Connection.java [14:02] bzr: ERROR: Could not move Connection.java.OTHER => Connection.java: src/ea/doma [14:02] in/Connection.java is already versioned. [14:03] then, how should I proceed? The right file is .OTHER [14:03] I know take-other option, but I need how to make with bzr mv [14:08] some help? [14:10] shakaran: The particular documentation URL one you pasted is a very old one - bzr 0.92 is positively ancient [14:10] As for the error, it sounds like you may want "bzr rm file; bzr mv file.OTHER file" [14:11] maxb: I search http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/conflicts.html but it have 404 [14:11] I don't think so. [14:11] the .OTHER file is not versioned. [14:11] I think you just want normal "mv" [14:11] mv foo.OTHER foo [14:11] 'chooses' the .OTHER as the version you want for foo. [14:12] http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/conflict-types-help.html [14:12] quicksilver: No, the .OTHER file *is* versioned [14:13] I did: [14:14] bzr rm Connection.java [14:14] deleted src/ea/domain/Connection.java [14:14] bzr mv Connection.java.OTHER Connection.java [14:14] src/ea/domain/Connection.java.OTHER => src/ea/domain/Connection.java === Ursinha is now known as Ursinha-afk [14:14] but, now the Connection.java file is not added, so I need a bzr add Connection.java ? === Ursinha-afk is now known as Ursinha [14:14] erm. That's not what I expected at all :-/ [14:15] shakaran: I don't suppose these branches are public? [14:15] If bzr mv mv'd it, it IS versioned. [14:15] See your stat output. [14:16] 'bzr mv' also has special logic; if it can't find the OLD file and the NEW file already exists, it presumes you are telling it about a 'mv' you already did [14:16] ok, I use bzr explorer on windows (it take a 20 second on refresh the folder with the icon) it is added [14:16] https://code.launchpad.net/~shakaran/ea/angel it is my public branch === oubiwann is now known as oubiwann_ [15:14] Anybody encountered a bug on windows with "JUNCTIONS" (on win7 here) causing bzr to error out? [15:15] I'm using a tool that automatically creates a junction, and i would like to treat it as a regular folder so the contents of the folder pointed to get added/committed... suggestions? [15:31] @latexer what error, or thing, happens when you do this? Are junctions like hard links, I forget, or do they work like mounts? [15:34] squall: let me pull it up exactly. I believe the tool is using windows vista & newer "junctions" which work like soft links to files/directories. [15:35] uhuh ok. junctions were available on xp too and so on, but there were never any tools to manipulate them.. viz: http://technet.microsoft.com/en-us/sysinternals/bb896768 [15:35] squall: the initial "bzr add" attempt just says "bzr: ERROR: [Error 3] The system cannot find the path specified: u'C:/Users/pete.johanson/dev/repo/mainline/wraps/openwrap\\*.*' [15:36] where the "openwrap" portion of that path is the junction. [15:37] okay and that opwnwrap points somewhere else on your disk then. [15:37] squall: correct. [15:37] and openwrap points to a bzr tree. and "repo" is a repository I guess. [15:38] And looking, I think actually the ideal situation for me would be if the "JUNCTION" details (what path it points to) would be the thing committed. (I believe the same way symlinks are handled on *nix) [15:38] repo is an initialized repository, "mainline" is a branch I've created. [15:38] the junction wraps/openwrap points to wraps/_cache/openwrap-1.0.0.50386209/ [15:39] (hopefully that's clear) [15:39] hmm. There probably is a bug about symlinks not working on windows already. As for what you're seeing, it probably should work I guess. [15:40] yeah, I found https://bugs.launchpad.net/bzr/+bug/81689 which seems to somewhat discuss the issue. [15:40] (that bug talks about checkouts, but I think fundamentally it's addressing the same thing) [15:41] There is this I find on wikipedia "Windows Vista supports a new symbolic link capability that replaces junction points in Windows 2000 and Windows XP. They are designed to aid in migration and application compatibility with UNIX operating systems" [15:41] have you tried this new symlink stuff? [15:41] that's the thing... the openwrap utility/tool is the one creating this junction/link, I don't really have control of it... [15:41] quicksilver: actually, history-db is "change from caching and always accesessing the entire history", to "cache the history in a way that we can access just the recent stuff quickly" [15:42] i mean, I could fiddle with it, but I was hoping to not have to potentially muck with the openwrap internals. [15:42] yeah I see. I just wondered if it's actually creating a "junction" or a "symlink" type of thing. I guess a junction. [15:43] jam: *nod* [15:43] squall: "dir" from cmd shows it as a , so I would guess it's a junction, not a symlink. [15:43] right, okay. [15:46] yes well, anyway it appears that bzr doesn't like them. that is the answer for now. We may need a new bug on this I am not sure I'll look in a minute. Perhaps you could try the "new" symlink approach by changing this "openwrap". It depends if you can do that or not. [15:46] yeah, can't hurt to try. [15:46] See, these junctions/symlinks have never been polular on windows at all. Probably becuase there are programs that fail to work correctly with them. [15:47] ya, makes sense. [15:47]