[00:07] Noldorin: if you run "bzr serve --directory=/" in cygwin, can you use bzr:// using root-based URLs? [00:08] hmm let's see :-) [00:15] jelmer, what port does normal smart serv run on? [00:36] jelmer, apparently it's a read-only transport? [00:36] Noldorin: yes, unless you specify --allow-writes [00:36] ah [00:36] on the server end eh? [00:37] it doesn't do authentication, so you probably want to do this on a world-facing machine [00:37] yes indeed [01:06] jelmer, not working any more [01:06] really weird [01:06] Noldorin: what isn't? [01:07] bzr serve [01:07] very weird [01:07] hmm one min [01:08] jelmer, ok tested. interestingly, that inits the branch in the wrong dir too [01:08] under the home dir [01:08] instead of root cygwin dir [01:08] so nothing to do with ssh it seems [01:08] Noldorin: are you specifying --directory=/ ? [01:08] yep [01:08] absolutely [01:10] hm [01:14] jelmer, any thoughts? [01:15] Noldorin: what's the URL you're specifying to connect? [01:16] bzr://alex-serverb/test1 [01:16] bzr serve --directory=/ --allow-writes [01:16] on server [01:19] Noldorin: and "bzr ls /test1" on the server works? [01:20] jelmer, correct [01:33] Noldorin: hmm, no idea in that case. Perhaps a cygwin-specific issue? [01:34] maybe [01:34] hm [01:34] either way, quite annoying [01:34] let's see... [01:38] jelmer, maybe you could ocnfirm somehow? [01:38] confirm* [01:52] Noldorin: sure === jordan__ is now known as jordan [02:33] jelmer, cheers. let me know when you get any more info :-) [02:43] Noldorin: ? [02:43] Noldorin: what do you need me to confirm? [02:44] I don't have cygwin (or Windows) here, I thought you were going to ask me for something else to confirm. [02:44] sorry [02:56] why did you say sure then lol? [02:56] i meant that it *does* work without cygwin [02:56] all else the same [02:56] brb [02:57] Noldorin: Yes, I'm sure it works without cygwin. [02:57] (and just confirmed) [09:36] hi all. I'm looking for some docs on criss-cross merges (basically, what is the definition of criss-cross graph of branches?). bzr help criss-cross gave me a rough idea, in bzrlib/tests/test_merge.py there are some examples, but i'd like to get the general idea before digging into specific examples. Maybe a paper on three-way merge? any hint? [11:34] hi ggherdov [11:34] hello jelmer [11:35] ggherdov: see also 'bzr help criss-cross' [11:36] sure I did. Actually I came over this line in bzrlib/merger.py , class Merger : [11:36] lcas = self.revision_graph.find_lca(revisions[0], revisions[1]) [11:36] if the list "lcas" have more than 1 elem, [11:36] i.e. more least common ancestors, [11:37] you get a criss cross (ie. a _is_criss_cross variable is set to True :-) [11:37] I was now looking into the find_lca method, to get a grasp on the algorithm. [11:43] ggherdov: criss-cross isn't an algorithm but rather a situation that can occur during merge, are you asking about the lca merge algorithm? [11:45] jelmer: my question was: "what is the definition of criss-cross?". From the code, apparently, is: when you have more than one LCA. Now my question is: what is the definition of LCA? and for that, I am reading the algo that finds them. [11:46] ggherdov: lowest common ancestor [11:47] how is an ancestor "lower" or "higher"? [11:48] I mean, it isn't just path's length, [11:50] since you have two paths to consider: A is a (common) ancestor of X and Y, so there is a path A-->X and A-->Y. How do you measure the distance pf ancestor A to the couple (X,Y), to compare with another ancestor, say B? [11:50] s/pf/of [12:04] ggherdov: distance would be the number of edges between X and A and X and B [12:05] got it! it's in the file bzrlib.graph . Say that you have a bunch of ancestors. lowest common ancestor of two nodes are those ancestors such that none of their descendant is a common ancestor. pastebin of the comment in graph.py: http://pastebin.com/ijyzmSQs [12:05] right [12:05] jelmer: isn't about distance, I was completely off road. [12:06] ggherdov: right, it's about the relationship - the number of commits in between is irrelevant [12:07] Yeah. I am going to make a wikipedia entry right away :-D (joking) [12:09] heh [12:09] ggherdov: what are you trying to do? [12:10] bah, nothing specific. Last week at work I got this warning about "hey - you are trying to merge but there is a criss-cross", which looked voodoo to me, and I wanted to see things clearer [12:10] ah, I see [12:11] ggherdov: Do you think there's anything specific in the help text "bzr help criss-cross" that could be improved? [12:11] *help text of [12:12] I had the impression that it didn't tell me what was happening, i.e. what the hell is criss-cross. Let me read it again. [12:18] no, I guess it was my inexperience. The help is good, it provides a practical explaination without a boring math definition: [12:18] Criss-crosses occur in a branch's history if two branches merge the same thing [12:18] and then merge one another, or if two branches merge one another at the same [12:18] time [12:20] the first is a "diamond" (clear criss cross), the second is a |X| (again clear criss cross). [12:20] then the help continues: [12:20] "Criss-crosses mean there is no good choice for a base" [12:20] which is just right into the problem. [12:23] maybe the point is that we're all a bit paranoid when merging (you are afraid of losing stuff silently), and anywhere you aren't 100 % in control you panic. [12:24] ggherdov: yeah, I know that feeling :-) [12:24] :-) [12:26] I don't think I've actually had merge lose stuff. Perhaps that message should be just a note rather than a warning. [12:28] Well, if there is even *just one* thoretically possible criss-cross situation where a bad thing can happen, i think that the warning is appropriate. [12:29] ggherdov: with the default merge algorithm, the worst that can happen is that you get more conflicts than you would with --lca [12:30] I see. --lca triggers a different merge algorithm? [12:31] ggherdov: yep [12:33] about the help: if anything, I would add a reference to some more specific documentation, like a technical paper or the code itself (like: to know more, read this paper / look into file XY) [12:37] jelmer: do you know if algorithms in bazaar are developed by the canonical folks, or rather the implementation of some standard stuff you can find in google scholar? if the latter, a tiny link somewhere would be nice I think. [12:38] ggherdov: I'm not too familiar with the merge algorithm internals personally. I think it's a combination of both. [12:38] ok I see. [15:58] hey jelmer [16:04] hi Noldorin [16:04] jelmer, found out the solution [16:04] jelmer, bzr+ssh is always relative to home directory it seems [16:04] at least in cygwin [16:05] it's designed this way [16:05] but i can get around with it by a) creatign a cygwin symolic link [16:05] b) creating a cygwin mount entry [16:05] :-) [16:05] Noldorin: I'm pretty sure that's not design in bzr+ssh [16:05] jelmer, well either way, bzr+ssh doesn't work hwo it should with bzr+ssh urls in cygwin [16:05] but there is a solution [16:05] as i said ;-) [16:05] this works at least [16:06] Noldorin: well, good to hear you found a solution at least [16:06] yeah :-) [16:06] jelmer, it's not a bug in bzr itself, i agree. either an explicit feature, or just the result of how cygwin operates [16:29] Noldorin: now you have it working, will you give in to my request to post about what you did on the bazaar list? :) [16:29] wgz, i was going to write a blog post, but okay... [16:29] what's the email? [16:29] blog post and link to it is fine also. [16:29] ok cool [16:50] jelmer, wgz any idea whether bzr+ssh urls on windows servers run bzr within cygwin or not? [16:51] Noldorin: that depends on your ssh server [16:51] jelmer, openssh as i said before ;-) [16:52] but on windows of course [16:52] it is the cygwin sshd server [16:52] but [16:52] not sure whether it's actually run in the cygwin context [16:52] Noldorin: natively compiled, or in cygwin? [16:52] Noldorin: bzr simply connects to the ssh port - whatever happens behind there is up to you [16:52] jelmer, nothing is native in cygwin [16:52] you're thinking of msys [16:52] (mingw) [16:52] Noldorin: openssh can be compiled natively perhaps? [16:52] nope [16:53] definitely not on windows [16:53] at least, no-one has tried it/released any source [16:55] jelmer, bah, i just figured it out [16:56] the problem is that the sshd uses cygwin fs [16:56] but not bzr exe itself [16:56] this explaisn everything :-( [16:56] hmm [16:58] ahh [17:00] yeah, it's within the cygwin shell so it sees those paths [17:00] wgz, no, that's the thing. bzr *does not* run with the cygwin shell [17:00] it runs natively on windows [17:01] ah, if you call out to a native windows bzr, sure [17:01] native windows bzr is by far the easiest solution on windows [17:01] but the `bzr serve` command works from the cygwin shell [17:01] it doesn't like python on windows, esp. regarding plugins and whatnot [17:02] wgz, it works, but it uses the native win32 environment :-P [17:02] ok, so with a normal windows hard link: [17:02] it kind of works...but gives a remote lock error [17:02] http://pastebin.com/NmH0CU2j [17:02] any ideas? :-) [17:04] need to see the server side log [17:04] ok [17:04] one sec [17:04] likely you want a different BZR_REMOTE_PATH [17:05] wgz, http://pastebin.com/2ixVJHVh [17:07] no error there hmm [17:09] need some debug flags thrown in as well [17:10] wgz, tell me what to do :-) [17:13] need fullermd really, he has more cunning tricks than me [17:14] the basic issue is the chroot is in totally the wrong place apparently [17:15] heh [17:15] i see [17:15] Noldorin: [17:15] wgz, well i'm happy to do some testing now, just give me orders. [17:15] otherwise we'll wait until fullermd is around [17:15] hmm [17:15] wgz, which ones, and on client or server? [17:15] in your config, set debug_flags to hpss and hpssdetail [17:16] ok [17:16] for the server, but but both wouldn't hurt [17:16] and hpssvfs too I guess [17:16] where is bzr.conf? [17:16] bazaar.conf* [17:17] run `bzr version` it will tell you what dir it's in [17:18] wgz, no file in the config dir. create one called bazaar.conf? [17:20] yeah, you want [DEFAULT] at the top too. [17:20] kk [17:20] if you run `bzr config debug_flags=hpss,hpssdetail,hpssvfs it's do it for you think [17:20] yep just did that, ta [17:21] then try the init again and paste the client and server logs again [17:23] http://pastebin.com/uWrLUtsx [17:23] (server) [17:23] err wait [17:23] that's someone else's paste [17:23] weird [17:23] http://pastie.org/3036664 [17:24] try again with /testreallyuniquenamethistime ? [17:25] ...really I want to see what the underlying fs path is getting mapped to... [17:25] wait, no, misread, that does create the dir [17:25] cleint is same [17:25] yeah [17:25] it does [17:25] the actual dir/repo/branch looks like it's created fine [17:26] just the stupid remotelock error [17:26] in what location? [17:26] C:\projects [17:26] need some way of getting the actual error/traceback on the server side... [17:27] wgz, -Derror maybe? [17:27] see the page you linked me to [17:27] throw in "lock" and "strict_locks" and yeah, why not "error" as well. [17:29] http://pastie.org/3036698 [17:29] wgz, there [17:31] okay, that's helpfuly. [17:31] -y [17:32] looks like a lockdir bug. [17:32] I wonder what cwd is from the perspective of bzr [17:35] yeah [17:35] hmm [17:42] okay, it feels like something is holding open the '8fuv1clmc4.tmp' file preventing it from being renamed into place [17:43] but it's a directory, so I'm not even sure if that can happen [17:55] hah, bzr run time is finally creeping towards 0.1s again [17:55] yeah, we regressed that pretty badly. [17:57] * jelmer has a nasty patch that copies urllib.quote and urllib.unquote into bzrlib.urlutils [17:57] it avoids import socket and ssl during normal operation though [18:01] okay, I think I understand the lockdir issue [18:03] jelmer: the other option would be something like the inspect_for_copy hack :) [18:03] I don't think you should feel too bad about reimplementing bits of urllib though [18:03] everyone else does. [18:04] Noldorin: is there any antivirus/other filsystem scanning software on your server? [18:06] LocalTransport.put_bytes_non_atomic etc are pretty bad [18:07] not safe in face of signals, way too much platform workaround code [18:13] ha, I wonder. [18:15] wgz, not on the server i don't believe... [18:15] no antivirus [18:15] wgz, what do you think it is then? [18:29] wb wgz [18:29] did you get my messages? [18:31] nope, sorry, paste me in pm? [18:35] thanks. [18:35] okay, so lockdir works like so [18:36] create a folder with a temp name [18:36] create a file inside the folder with info in it [18:36] try to rename the folder to "held" to take the lock [18:37] if that fails, assume someone else already has the lock [18:37] right [18:37] trying that now [18:37] hmm [18:37] however, it can fail for reasons other than "held" already existing [18:37] wgz, i'm the only user using this btw [18:37] oh wait, you're just explaining how it works [18:37] okay... [18:37] one way to get the error you had is just by another process having the info file open when the rename happens [18:38] this is incorrectly reported as LockContention [18:38] right [18:38] actually debugging this without changing code is hard. [18:39] yeah, so i thought [18:39] can you run the bzr serve from a source tree? [18:39] sure [18:39] the problem is a lot of our code here is... not great [18:39] hah [18:40] wgz, you trying to say some bzr is the composite work of monkeys on typewriters? ;-) [18:40] no, but the layering and platform specific hacks work against sanity in many respects [18:40] okay [18:41] wgz, so not all the codebase is bad huh? :-P [18:41] wgz, running it from a specific branch...just on the bzr:// protocol eh? [18:42] right, I should probably see if I can repo anything here, but I suspect not [18:43] wgz, ooh, this is kind-of-good news [18:43] a local bzr init in that directory fails [18:43] with LockContention [18:43] with a traceback [18:43] pastebin? [18:43] http://pastie.org/3037040 [18:44] it may also be a geniune permission error, given you're on a newer windows [18:44] just check i have full control on that dir [18:44] so unlikely [18:46] what exists inside Shared-Projects\foo\.bzr\branch-lock ? [18:46] if there are any files, pastebin me them [18:47] (also see if, from Shared-Projects, you can do `bzr init newfoo`) [18:47] wgz, no files [18:49] identical [18:49] result [18:49] with that command [18:49] okay, now [18:49] set BZR_PDB=1 [18:49] then run the command again [18:50] will get you into the debugger at hopefully, line 641 in lockdir [18:52] if you then type "self._attempt_lock()" you should get the same exception as before [18:52] we can then try stepping into that [18:55] *** LockContention: Could not acquire lock "LockDir(file:///Z:/Alex/Shared-Projects/foo/.bzr/branch- [18:55] lock)": [18:56] wgz, i end up with that [18:56] on self._attempt_lock [18:56] ace. [18:57] so what next? :-) [18:58] looks like the bzr documentation for windows is very out of date [18:58] isn't it Noldorin :) [18:59] Noldorin: "debug self._attempt_lock()", then start hitting 's' [19:00] till you get inside _attempt_lock [19:00] then use 'n' till you get to the 'self.transport.rename' line [19:02] teusje, most of the docs are platform-agnostic ;-) [19:02] but some of it is old yes [19:02] heh [19:02] wgz okies [19:03] :p [19:04] windows default paths that don't exist anymore in windows vista/win 7 :p [19:04] so, "n" is forwards, and "s" is forwards-and-in [19:04] we want to go in to the rename [19:04] got it [19:04] wgz, step over and step into as we say on windows :-) [19:04] get to the except clause, where we have the real error from os.rename [19:05] wgz, just one s i think? [19:05] not sure i'm inside it yet [19:05] this should be in transport/local.py [19:05] hit 's' if unsure [19:05] k [19:05] but can always redo if you accidentally jump over [19:05] cool, how? [19:06] PermissionDenied: Permissi...s denied) [19:06] > z:\alex\shared-projects\bzrlib\lockdir.pyo(243)_attempt_lock() [19:06] wgz, get that before i get to self.transport.rename [19:06] that looks like the error from that line [19:07] we need to get into the call, so more 's' and less 'n' [19:07] wgz, do you fancy just teamviewer-ing in? might go a lot quicker this way [19:08] how do i back up then? [19:09] *awaits command* [19:09] Noldorin: format c: [19:09] * vila ducks [19:09] vila tries to be funny [19:09] *anticipates vila's duck and clobbers him with a Windows 7 install DVD* [19:10] . o O (Only way to be is to try ;) [19:10] Noldorin: j 241 [19:10] wgz, then just 's' until... ? [19:10] right [19:10] Noldorin: could do some desktop sharing thing if you want, I'd need to install things [19:11] wgz, actually teamviewer can run locally without install, that's what nice about it :-) [19:12] wgz firstly though, http://pastie.org/3037180 [19:13] ace. [19:13] Noldorin that it is not supported on their windows xp that they use for writing documentation :p [19:13] do "p path_from" and "p path_to" [19:13] u'Z:/Alex/Shared-Projects/foo2/.bzr/branch-lock/j2robxgreu.tmp' [19:14] and u'Z:/Alex/Shared-Projects/foo2/.bzr/branch-lock/held' [19:14] respectively [19:14] then you can do "os.exists(path_from)" and "os.exists(path_to)" [19:14] teusje, heh [19:14] I expect path_from to exist, and path_to not to. [19:14] wgz, module has no attribute exists [19:15] *os.path.exists, sorry [19:15] wgz, you expectations were correct. [19:15] your* [19:16] ok, now "p os.listdir(path_from)" [19:16] wgz, just u'info' [19:16] then "f = open(os.path.join(path_from, 'info')) [19:17] "p f.read()" [19:17] "f.close()" [19:17] 'hostname: Alex-ServerB\nnonce: 2a540tvz6rmuz5p97tvz\npid: 3900\nstart_time: 1324235155\nuser: Alex\ [19:17] n' [19:18] "os.remove(os.path.join(path_from, 'info'))" [19:18] done [19:18] and it worked, heh. [19:18] so, discounts the handle issue [19:18] now, "os.rename(path_from, path_to)" [19:19] *** WindowsError: [Error 5] Access is denied [19:20] "os.stat(path_from)" [19:20] "os.remove(path_from)" [19:20] nt.stat_result(st_mode=16895, st_ino=0L, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=0L, st_at [19:20] ime=1324235908L, st_mtime=1324235908L, st_ctime=1324235155L) [19:20] *** WindowsError: [Error 5] Access is denied: u'Z:/Alex/Shared-Projects/foo2/.bzr/branch-lock/j2robx [19:20] greu.tmp' [19:20] cute. [19:20] is that informative at least? [19:20] heh [19:21] "os.getcwd()" [19:22] 'Z:\\Alex\\Shared-Projects' [19:22] okay, so, everything is sane. [19:22] heh [19:22] what's going on then? [19:23] except we have created a directory, that we can't rename or remove. [19:23] hah [19:23] nice [19:24] have you got process explorer installed? [19:24] wgz, i *literally* just started up procexp 2 seconds before you said that :-) [19:24] to check for locks [19:24] by other procs [19:24] heh [19:25] right, find handles with substring "Z:\Alex\Shared-Projects" [19:25] wgz, no open handles on it [19:25] none at all [19:25] okay, so that discounts the theory. [19:25] permissions look fine on it to :-S [19:25] hrmm [19:26] wgz, interestingly i have no prob deleting it from winexplorer [19:27] what credentials is bzr.exe running with?... [19:27] the code doesn't seem to be suprising either... [19:28] potentally not the right ones, but letting you make a dir you can't remove doesn't sound like a standard persm issue ither [19:28] ha, I mistyped an instruction earlier, than may have confused things [19:29] want to try the screen sharing thing? what do I need to see your desktop rather than visa versa? [19:30] wgz, sure, we can do that. teamviewer is already set up here [19:30] wgz, actually, mind waiting 20 minsm as i need to eat? [19:31] go for it. [19:31] I shall ponder in the mean time. [19:31] wgz, something tells me though that because Windows Explorer can delete the dir fine but Python can't, the Samba share on the directory is confusing it. maybe the Windows shell sends a notification to the Samba server to release it before deleting [19:31] *shrug* [19:31] be back soon! [19:33] should directory names in entries in dirstate (in dirstate field _dirblocks) be unicode or bytes? [19:34] they're utf-8 bytes. [19:35] i'm looking at bug https://bugs.launchpad.net/bzr/+bug/185211 [19:35]