[00:07] <jelmer> Noldorin: if you run "bzr serve --directory=/" in cygwin, can you use bzr:// using root-based URLs?
[00:08] <Noldorin> hmm let's see :-)
[00:15] <Noldorin> jelmer, what port does normal smart serv run on?
[00:36] <Noldorin> jelmer, apparently it's a read-only transport?
[00:36] <jelmer> Noldorin: yes, unless you specify --allow-writes
[00:36] <Noldorin> ah
[00:36] <Noldorin> on the server end eh?
[00:37] <jelmer> it doesn't do authentication, so you probably want to do this on a world-facing machine
[00:37] <Noldorin> yes indeed
[01:06] <Noldorin> jelmer, not working any more
[01:06] <Noldorin> really weird
[01:06] <jelmer> Noldorin: what isn't?
[01:07] <Noldorin> bzr serve
[01:07] <Noldorin> very weird
[01:07] <Noldorin> hmm one min
[01:08] <Noldorin> jelmer, ok tested. interestingly, that inits the branch in the wrong dir too
[01:08] <Noldorin> under the home dir
[01:08] <Noldorin> instead of root cygwin dir
[01:08] <Noldorin> so nothing to do with ssh it seems
[01:08] <jelmer> Noldorin: are you specifying --directory=/ ?
[01:08] <Noldorin> yep
[01:08] <Noldorin> absolutely
[01:10] <Noldorin> hm
[01:14] <Noldorin> jelmer, any thoughts?
[01:15] <jelmer> Noldorin: what's the URL you're specifying to connect?
[01:16] <Noldorin> bzr://alex-serverb/test1
[01:16] <Noldorin>  bzr serve --directory=/ --allow-writes
[01:16] <Noldorin> on server
[01:19] <jelmer> Noldorin: and "bzr ls /test1" on the server works?
[01:20] <Noldorin> jelmer, correct
[01:33] <jelmer> Noldorin: hmm, no idea in that case. Perhaps a cygwin-specific issue?
[01:34] <Noldorin> maybe
[01:34] <Noldorin> hm
[01:34] <Noldorin> either way, quite annoying
[01:34] <Noldorin> let's see...
[01:38] <Noldorin> jelmer, maybe you could ocnfirm somehow?
[01:38] <Noldorin> confirm*
[01:52] <jelmer> Noldorin: sure
[02:33] <Noldorin> jelmer, cheers. let me know when you get any more info :-)
[02:43] <jelmer> Noldorin: ?
[02:43] <jelmer> Noldorin: what do you need me to confirm?
[02:44] <jelmer> I don't have cygwin (or Windows) here, I thought you were going to ask me for something else to confirm.
[02:44] <jelmer> sorry
[02:56] <Noldorin> why did you say sure then lol?
[02:56] <Noldorin> i meant that it *does* work without cygwin
[02:56] <Noldorin> all else the same
[02:56] <Noldorin> brb
[02:57] <jelmer> Noldorin: Yes, I'm sure it works without cygwin.
[02:57] <jelmer> (and just confirmed)
[09:36] <ggherdov> 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] <jelmer> hi ggherdov
[11:34] <ggherdov> hello jelmer
[11:35] <jelmer> ggherdov: see also 'bzr help criss-cross'
[11:36] <ggherdov> sure I did. Actually I came over this line in bzrlib/merger.py , class Merger :
[11:36] <ggherdov> lcas = self.revision_graph.find_lca(revisions[0], revisions[1])
[11:36] <ggherdov> if the list "lcas" have more than 1 elem,
[11:36] <ggherdov> i.e. more least common ancestors,
[11:37] <ggherdov> you get a criss cross (ie. a _is_criss_cross variable is set to True :-)
[11:37] <ggherdov> I was now looking into the find_lca method, to get a grasp on the algorithm.
[11:43] <jelmer> 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] <ggherdov> 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] <jelmer> ggherdov: lowest common ancestor
[11:47] <ggherdov> how is an ancestor "lower" or "higher"?
[11:48] <ggherdov> I mean, it isn't just path's length,
[11:50] <ggherdov> 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] <ggherdov> s/pf/of
[12:04] <jelmer> ggherdov: distance would be the number of edges between X and A and X and B
[12:05] <ggherdov> 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] <jelmer> right
[12:05] <ggherdov> jelmer: isn't about distance, I was completely off road.
[12:06] <jelmer> ggherdov: right, it's about the relationship - the number of commits in between is irrelevant
[12:07] <ggherdov> Yeah. I am going to make a wikipedia entry right away :-D (joking)
[12:09] <jelmer> heh
[12:09] <jelmer> ggherdov: what are you trying to do?
[12:10] <ggherdov> 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] <jelmer> ah, I see
[12:11] <jelmer> ggherdov: Do you think there's anything specific in the help text "bzr help criss-cross" that could be improved?
[12:11] <jelmer> *help text of
[12:12] <ggherdov> 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] <ggherdov> no, I guess it was my inexperience. The help is good, it provides a practical explaination without a boring math definition:
[12:18] <ggherdov> Criss-crosses occur in a branch's history if two branches merge the same thing
[12:18] <ggherdov> and then merge one another, or if two branches merge one another at the same
[12:18] <ggherdov> time
[12:20] <ggherdov> the first is a "diamond" (clear criss cross), the second is a |X| (again clear criss cross).
[12:20] <ggherdov> then the help continues:
[12:20] <ggherdov> "Criss-crosses mean there is no good choice for a base"
[12:20] <ggherdov> which is just right into the problem.
[12:23] <ggherdov> 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] <jelmer> ggherdov: yeah, I know that feeling :-)
[12:24] <ggherdov> :-)
[12:26] <jelmer> 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] <ggherdov> 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] <jelmer> ggherdov: with the default merge algorithm, the worst that can happen is that you get more conflicts than you would with --lca
[12:30] <ggherdov> I see. --lca triggers a different merge algorithm?
[12:31] <jelmer> ggherdov: yep
[12:33] <ggherdov> 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] <ggherdov> 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] <jelmer> ggherdov: I'm not too familiar with the merge algorithm internals personally. I think it's a combination of both.
[12:38] <ggherdov> ok I see.
[15:58] <Noldorin> hey jelmer
[16:04] <jelmer> hi Noldorin
[16:04] <Noldorin> jelmer, found out the solution
[16:04] <Noldorin> jelmer, bzr+ssh is always relative to home directory it seems
[16:04] <Noldorin> at least in cygwin
[16:05] <Noldorin> it's designed this way
[16:05] <Noldorin> but i can get around with it by a) creatign a cygwin symolic link
[16:05] <Noldorin> b) creating a cygwin mount entry
[16:05] <Noldorin> :-)
[16:05] <jelmer> Noldorin: I'm pretty sure that's not design in bzr+ssh
[16:05] <Noldorin> jelmer, well either way, bzr+ssh doesn't work hwo it should with bzr+ssh urls in cygwin
[16:05] <Noldorin> but there is a solution
[16:05] <Noldorin> as i said ;-)
[16:05] <Noldorin> this works at least
[16:06] <jelmer> Noldorin: well, good to hear you found a solution at least
[16:06] <Noldorin> yeah :-)
[16:06] <Noldorin> 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] <wgz> 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] <Noldorin> wgz, i was going to write a blog post, but okay...
[16:29] <Noldorin> what's the email?
[16:29] <wgz> blog post and link to it is fine also.
[16:29] <Noldorin> ok cool
[16:50] <Noldorin> jelmer, wgz any idea whether bzr+ssh urls on windows servers run bzr within cygwin or not?
[16:51] <jelmer> Noldorin: that depends on your ssh server
[16:51] <Noldorin> jelmer, openssh as i said before ;-)
[16:52] <Noldorin> but on windows of course
[16:52] <Noldorin> it is the cygwin sshd server
[16:52] <Noldorin> but
[16:52] <Noldorin> not sure whether it's actually run in the cygwin context
[16:52] <jelmer> Noldorin: natively compiled, or in cygwin?
[16:52] <jelmer> Noldorin: bzr simply connects to the ssh port - whatever happens behind there is up to you
[16:52] <Noldorin> jelmer, nothing is native in cygwin
[16:52] <Noldorin> you're thinking of msys
[16:52] <Noldorin> (mingw)
[16:52] <jelmer> Noldorin: openssh can be compiled natively perhaps?
[16:52] <Noldorin> nope
[16:53] <Noldorin> definitely not on windows
[16:53] <Noldorin> at least, no-one has tried it/released any source
[16:55] <Noldorin> jelmer, bah, i just figured it out
[16:56] <Noldorin> the problem is that the sshd uses cygwin fs
[16:56] <Noldorin> but not bzr exe itself
[16:56] <Noldorin> this explaisn everything :-(
[16:56] <Noldorin> hmm
[16:58] <jelmer> ahh
[17:00] <wgz> yeah, it's within the cygwin shell so it sees those paths
[17:00] <Noldorin> wgz, no, that's the thing. bzr *does not* run with the cygwin shell
[17:00] <Noldorin> it runs natively on windows
[17:01] <wgz> ah, if you call out to a native windows bzr, sure
[17:01] <Noldorin> native windows bzr is by far the easiest solution on windows
[17:01] <wgz> but the `bzr serve` command works from the cygwin shell
[17:01] <Noldorin> it doesn't like python on windows, esp. regarding plugins and whatnot
[17:02] <Noldorin> wgz, it works, but it uses the native win32 environment :-P
[17:02] <Noldorin> ok, so with a normal windows hard link:
[17:02] <Noldorin> it kind of works...but gives a remote lock error
[17:02] <Noldorin> http://pastebin.com/NmH0CU2j
[17:02] <Noldorin> any ideas? :-)
[17:04] <wgz> need to see the server side log
[17:04] <Noldorin> ok
[17:04] <Noldorin> one sec
[17:04] <wgz> likely you want a different BZR_REMOTE_PATH
[17:05] <Noldorin> wgz, http://pastebin.com/2ixVJHVh
[17:07] <Noldorin> no error there hmm
[17:09] <wgz> need some debug flags thrown in as well
[17:10] <Noldorin> wgz, tell me what to do :-)
[17:13] <wgz> need fullermd really, he has more cunning tricks than me
[17:14] <wgz> the basic issue is the chroot is in totally the wrong place apparently
[17:15] <Noldorin> heh
[17:15] <Noldorin> i see
[17:15] <wgz> Noldorin: <http://doc.bazaar.canonical.com/beta/en/user-reference/debug-flags-help.html>
[17:15] <Noldorin> wgz, well i'm happy to do some testing now, just give me orders.
[17:15] <Noldorin> otherwise we'll wait until fullermd is around
[17:15] <Noldorin> hmm
[17:15] <Noldorin> wgz, which ones, and on client or server?
[17:15] <wgz> in your config, set debug_flags to hpss and hpssdetail
[17:16] <Noldorin> ok
[17:16] <wgz> for the server, but but both wouldn't hurt
[17:16] <wgz> and hpssvfs too I guess
[17:16] <Noldorin> where is bzr.conf?
[17:16] <Noldorin> bazaar.conf*
[17:17] <wgz> run `bzr version` it will tell you what dir it's in
[17:18] <Noldorin> wgz, no file in the config dir. create one called bazaar.conf?
[17:20] <wgz> yeah, you want [DEFAULT] at the top too.
[17:20] <Noldorin> kk
[17:20] <wgz> if you run `bzr config debug_flags=hpss,hpssdetail,hpssvfs it's do it for you think
[17:20] <Noldorin> yep just did that, ta
[17:21] <wgz> then try the init again and paste the client and server logs again
[17:23] <Noldorin> http://pastebin.com/uWrLUtsx
[17:23] <Noldorin> (server)
[17:23] <Noldorin> err wait
[17:23] <Noldorin> that's someone else's paste
[17:23] <Noldorin> weird
[17:23] <Noldorin> http://pastie.org/3036664
[17:24] <wgz> try again with /testreallyuniquenamethistime ?
[17:25] <wgz> ...really I want to see what the underlying fs path is getting mapped to...
[17:25] <wgz> wait, no, misread, that does create the dir
[17:25] <Noldorin> cleint is same
[17:25] <Noldorin> yeah
[17:25] <Noldorin> it does
[17:25] <Noldorin> the actual dir/repo/branch looks like it's created fine
[17:26] <Noldorin> just the stupid remotelock error
[17:26] <wgz> in what location?
[17:26] <Noldorin> C:\projects
[17:26] <wgz> need some way of getting the actual error/traceback on the server side...
[17:27] <Noldorin> wgz, -Derror maybe?
[17:27] <Noldorin> see the page you linked me to
[17:27] <wgz> throw in "lock" and "strict_locks" and yeah, why not "error" as well.
[17:29] <Noldorin> http://pastie.org/3036698
[17:29] <Noldorin> wgz, there
[17:31] <wgz> okay, that's helpfuly.
[17:31] <wgz> -y
[17:32] <wgz> looks like a lockdir bug.
[17:32] <wgz> I wonder what cwd is from the perspective of bzr
[17:35] <Noldorin> yeah
[17:35] <Noldorin> hmm
[17:42] <wgz> okay, it feels like something is holding open the '8fuv1clmc4.tmp' file preventing it from being renamed into place
[17:43] <wgz> but it's a directory, so I'm not even sure if that can happen
[17:55] <jelmer> hah, bzr run time is finally creeping towards 0.1s again
[17:55] <wgz> 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] <jelmer> it avoids import socket and ssl during normal operation though
[18:01] <wgz> okay, I think I understand the lockdir issue
[18:03] <wgz> jelmer: the other option would be something like the inspect_for_copy hack :)
[18:03] <wgz> I don't think you should feel too bad about reimplementing bits of urllib though
[18:03] <wgz> everyone else does.
[18:04] <wgz> Noldorin: is there any antivirus/other filsystem scanning software on your server?
[18:06] <wgz> LocalTransport.put_bytes_non_atomic etc are pretty bad
[18:07] <wgz> not safe in face of signals, way too much platform workaround code
[18:13] <wgz> ha, I wonder.
[18:15] <Noldorin> wgz, not on the server i don't believe...
[18:15] <Noldorin> no antivirus
[18:15] <Noldorin> wgz, what do you think it is then?
[18:29] <Noldorin> wb wgz
[18:29] <Noldorin> did you get my messages?
[18:31] <wgz> nope, sorry, paste me in pm?
[18:35] <wgz> thanks.
[18:35] <wgz> okay, so lockdir works like so
[18:36] <wgz> create a folder with a temp name
[18:36] <wgz> create a file inside the folder with info in it
[18:36] <wgz> try to rename the folder to "held" to take the lock
[18:37] <wgz> if that fails, assume someone else already has the lock
[18:37] <Noldorin> right
[18:37] <Noldorin> trying that now
[18:37] <Noldorin> hmm
[18:37] <wgz> however, it can fail for reasons other than "held" already existing
[18:37] <Noldorin> wgz, i'm the only user using this btw
[18:37] <Noldorin> oh wait, you're just explaining how it works
[18:37] <Noldorin> okay...
[18:37] <wgz> one way to get the error you had is just by another process having the info file open when the rename happens
[18:38] <wgz> this is incorrectly reported as LockContention
[18:38] <Noldorin> right
[18:38] <wgz> actually debugging this without changing code is hard.
[18:39] <Noldorin> yeah, so i thought
[18:39] <wgz> can you run the bzr serve from a source tree?
[18:39] <Noldorin> sure
[18:39] <wgz> the problem is a lot of our code here is... not great
[18:39] <Noldorin> hah
[18:40] <Noldorin> wgz, you trying to say some bzr is the composite work of monkeys on typewriters? ;-)
[18:40] <wgz> no, but the layering and platform specific hacks work against sanity in many respects
[18:40] <Noldorin> okay
[18:41] <Noldorin> wgz, so not all the codebase is bad huh? :-P
[18:41] <Noldorin> wgz, running it from a specific branch...just on the bzr:// protocol eh?
[18:42] <wgz> right, I should probably see if I can repo anything here, but I suspect not
[18:43] <Noldorin> wgz, ooh, this is kind-of-good news
[18:43] <Noldorin> a local bzr init in that directory fails
[18:43] <Noldorin> with LockContention
[18:43] <Noldorin> with a traceback
[18:43] <wgz> pastebin?
[18:43] <Noldorin> http://pastie.org/3037040
[18:44] <wgz> it may also be a geniune permission error, given you're on a newer windows
[18:44] <Noldorin> just check i have full control on that dir
[18:44] <Noldorin> so unlikely
[18:46] <wgz> what exists inside Shared-Projects\foo\.bzr\branch-lock ?
[18:46] <wgz> if there are any files, pastebin me them
[18:47] <wgz> (also see if, from Shared-Projects, you can do `bzr init newfoo`)
[18:47] <Noldorin> wgz, no files
[18:49] <Noldorin> identical
[18:49] <Noldorin> result
[18:49] <Noldorin> with that command
[18:49] <wgz> okay, now
[18:49] <wgz> set BZR_PDB=1
[18:49] <wgz> then run the command again
[18:50] <wgz> will get you into the debugger at hopefully, line 641 in lockdir
[18:52] <wgz> if you then type "self._attempt_lock()" you should get the same exception as before
[18:52] <wgz> we can then try stepping into that
[18:55] <Noldorin> *** LockContention: Could not acquire lock "LockDir(file:///Z:/Alex/Shared-Projects/foo/.bzr/branch-
[18:55] <Noldorin> lock)":
[18:56] <Noldorin> wgz, i end up with that
[18:56] <Noldorin> on self._attempt_lock
[18:56] <wgz> ace.
[18:57] <Noldorin> so what next? :-)
[18:58] <teusje> looks like the bzr documentation for windows is very out of date
[18:58] <teusje> isn't it Noldorin :)
[18:59] <wgz> Noldorin: "debug self._attempt_lock()", then start hitting 's'
[19:00] <wgz> till you get inside _attempt_lock
[19:00] <wgz> then use 'n' till you get to the 'self.transport.rename' line
[19:02] <Noldorin> teusje, most of the docs are platform-agnostic ;-)
[19:02] <Noldorin> but some of it is old yes
[19:02] <Noldorin> heh
[19:02] <Noldorin> wgz okies
[19:03] <teusje> :p
[19:04] <teusje> windows default paths that don't exist anymore in windows vista/win 7 :p
[19:04] <wgz> so, "n" is forwards, and "s" is forwards-and-in
[19:04] <wgz> we want to go in to the rename
[19:04] <Noldorin> got it
[19:04] <Noldorin> wgz, step over and step into as we say on windows :-)
[19:04] <wgz> get to the except clause, where we have the real error from os.rename
[19:05] <Noldorin> wgz, just one s i think?
[19:05] <Noldorin> not sure i'm inside it yet
[19:05] <wgz> this should be in transport/local.py
[19:05] <wgz> hit 's' if unsure
[19:05] <Noldorin> k
[19:05] <wgz> but can always redo if you accidentally jump over
[19:05] <Noldorin> cool, how?
[19:06] <Noldorin> PermissionDenied: Permissi...s denied)
[19:06] <Noldorin> > z:\alex\shared-projects\bzrlib\lockdir.pyo(243)_attempt_lock()
[19:06] <Noldorin> wgz, get that before i get to self.transport.rename
[19:06] <wgz> that looks like the error from that line
[19:07] <wgz> we need to get into the call, so more 's' and less 'n'
[19:07] <Noldorin> wgz, do you fancy just teamviewer-ing in? might go a lot quicker this way
[19:08] <Noldorin> how do i back up then?
[19:09] <Noldorin> *awaits command*
[19:09] <vila> Noldorin: format c:
[19:09]  * vila ducks
[19:09] <teusje> vila tries to be funny
[19:09] <Noldorin> *anticipates vila's duck and clobbers him with a Windows 7 install DVD*
[19:10] <vila> . o O (Only way to be is to try ;)
[19:10] <wgz> Noldorin: j 241
[19:10] <Noldorin> wgz, then just 's' until... ?
[19:10] <wgz> right
[19:10] <wgz> Noldorin: could do some desktop sharing thing if you want, I'd need to install things
[19:11] <Noldorin> wgz, actually teamviewer can run locally without install, that's what nice about it :-)
[19:12] <Noldorin> wgz firstly though, http://pastie.org/3037180
[19:13] <wgz> ace.
[19:13] <teusje> Noldorin that it is not supported on their windows xp that they use for writing documentation :p
[19:13] <wgz> do "p path_from" and "p path_to"
[19:13] <Noldorin> u'Z:/Alex/Shared-Projects/foo2/.bzr/branch-lock/j2robxgreu.tmp'
[19:14] <Noldorin> and u'Z:/Alex/Shared-Projects/foo2/.bzr/branch-lock/held'
[19:14] <Noldorin> respectively
[19:14] <wgz> then you can do "os.exists(path_from)" and "os.exists(path_to)"
[19:14] <Noldorin> teusje, heh
[19:14] <wgz> I expect path_from to exist, and path_to not to.
[19:14] <Noldorin> wgz, module has no attribute exists
[19:15] <wgz> *os.path.exists, sorry
[19:15] <Noldorin> wgz, you expectations were correct.
[19:15] <Noldorin> your*
[19:16] <wgz> ok, now "p os.listdir(path_from)"
[19:16] <Noldorin> wgz, just u'info'
[19:16] <wgz> then "f = open(os.path.join(path_from, 'info'))
[19:17] <wgz> "p f.read()"
[19:17] <wgz> "f.close()"
[19:17] <Noldorin> 'hostname: Alex-ServerB\nnonce: 2a540tvz6rmuz5p97tvz\npid: 3900\nstart_time: 1324235155\nuser: Alex\
[19:17] <Noldorin> n'
[19:18] <wgz> "os.remove(os.path.join(path_from, 'info'))"
[19:18] <Noldorin> done
[19:18] <wgz> and it worked, heh.
[19:18] <wgz> so, discounts the handle issue
[19:18] <wgz> now, "os.rename(path_from, path_to)"
[19:19] <Noldorin> *** WindowsError: [Error 5] Access is denied
[19:20] <wgz> "os.stat(path_from)"
[19:20] <wgz> "os.remove(path_from)"
[19:20] <Noldorin> 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] <Noldorin> ime=1324235908L, st_mtime=1324235908L, st_ctime=1324235155L)
[19:20] <Noldorin> *** WindowsError: [Error 5] Access is denied: u'Z:/Alex/Shared-Projects/foo2/.bzr/branch-lock/j2robx
[19:20] <Noldorin> greu.tmp'
[19:20] <wgz> cute.
[19:20] <Noldorin> is that informative at least?
[19:20] <Noldorin> heh
[19:21] <wgz> "os.getcwd()"
[19:22] <Noldorin> 'Z:\\Alex\\Shared-Projects'
[19:22] <wgz> okay, so, everything is sane.
[19:22] <Noldorin> heh
[19:22] <Noldorin> what's going on then?
[19:23] <wgz> except we have created a directory, that we can't rename or remove.
[19:23] <Noldorin> hah
[19:23] <Noldorin> nice
[19:24] <wgz> have you got process explorer installed?
[19:24] <Noldorin> wgz, i *literally* just started up procexp 2 seconds before you said that :-)
[19:24] <Noldorin> to check for locks
[19:24] <Noldorin> by other procs
[19:24] <Noldorin> heh
[19:25] <wgz> right, find handles with substring "Z:\Alex\Shared-Projects"
[19:25] <Noldorin> wgz, no open handles on it
[19:25] <Noldorin> none at all
[19:25] <wgz> okay, so that discounts the theory.
[19:25] <Noldorin> permissions look fine on it to :-S
[19:25] <Noldorin> hrmm
[19:26] <Noldorin> wgz, interestingly i have no prob deleting it from winexplorer
[19:27] <Noldorin> what credentials is bzr.exe running with?...
[19:27] <wgz> the code doesn't seem to be suprising either...
[19:28] <wgz> 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] <wgz> ha, I mistyped an instruction earlier, than may have confused things
[19:29] <wgz> want to try the screen sharing thing? what do I need to see your desktop rather than visa versa?
[19:30] <Noldorin> wgz, sure, we can do that. teamviewer is already set up here
[19:30] <Noldorin> wgz, actually, mind waiting 20 minsm as i need to eat?
[19:31] <wgz> go for it.
[19:31] <wgz> I shall ponder in the mean time.
[19:31] <Noldorin> 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] <Noldorin> *shrug*
[19:31] <Noldorin> be back soon!
[19:33] <roryy> should directory names in entries in dirstate (in dirstate field _dirblocks) be unicode or bytes?
[19:34] <wgz> they're utf-8 bytes.
[19:35] <roryy> i'm looking at bug https://bugs.launchpad.net/bzr/+bug/185211
[19:35] <roryy> and i've run robert collins demo script with pdb
[19:35] <roryy> they look like bytes to me
[19:35] <roryy> but my python-fu is not super-strong, so I may be missing something
[19:37] <wgz> oh, oh man
[19:38] <wgz> nice bug rorry, that repo script is hilarious
[19:39] <roryy> yeah, i dunno why all those weird characters
[19:39] <wgz> looks a lot like a 'safe' unicode bug
[19:39] <roryy> what does that mean?
[19:40] <wgz> I bet you can double-decode as utf-8
[19:40] <wgz> yep, win.
[19:41] <wgz> >>> b = "\xc3\x83\xe2\x80\x9e\xc3\x83\xe2\x80\x93\xc3\x83\xc5\x93"
[19:41] <wgz> >>> u = b.decode("utf-8")
[19:41] <wgz> >>> b2 = u.encode("CP1252")
[19:41] <wgz> >>> u2 = b.decode("utf-8")
[19:42] <wgz> basically, a bug due to bad handling of which encoding is used for what
[19:45] <wgz> the tricky part is the failure comes after the bug has already happened
[19:45] <wgz> have you tried running the script with -Ddirstate added?
[19:46] <roryy> no
[19:46] <roryy> ah, track dirstate activity
[19:47] <roryy> interesting that u2==u in this case
[19:47] <roryy> oh, hang on
[19:47] <roryy> did you mean u2=b2.decode() there?
[19:47] <wgz> ah yes, my error
[19:47] <wgz> >>> u2 = b2.decode("utf-8")
[19:48] <roryy> ok, that is saner
[19:48] <wgz> >>> u
[19:48] <wgz> u'\xc3\u201e\xc3\u2013\xc3\u0153'
[19:48] <wgz> >>> u2
[19:48] <wgz> u'\xc4\xd6\xdc'
[19:48] <roryy> i thought somehow cp1252 and utf-8 had a weird equivalence
[19:52] <roryy> hmm, -Ddirstate doesn't obviously output anything
[19:55] <wgz> it goes in .bzr.log
[19:55] <roryy> ah-ha, thank you
[20:00] <wgz> I suggest cutting down the filename to the shortest thing you need to reproduce the bug, then seeing if you can track when it turns into something that doesn't match what's on disk
[20:13] <roryy> the error is triggered with just one non-ASCII character in the filename
[20:14] <roryy> and in the entry, i see only 'abc' for the directory name, where I expected to see u'abcÃ'
[20:15] <roryy> the -Ddirstate and trace.mutter look useful; might be easier than working with pdb
[20:23] <Noldorin> hi wgz
[20:23] <Noldorin> back
[20:26] <wgz> hey Noldorin
[20:27] <Noldorin> hi
[20:27] <Noldorin> any more thoughts? :-)
[20:28] <wgz> only for a different bug with a similar symptom I'm afraid
[20:28] <wgz> want to try some more debugging?
[20:28] <Noldorin> yes please
[20:29] <wgz> okay, if you pm me the id thingy let's try teamviewer
[20:34] <roryy> wgz: thanks for the help.  i'm off to sleep.
[20:38] <wgz> night roryy
[21:41] <wgz> bug 716507 ...not completely relevent
[21:41] <jelmer> wgz: btw, what are your thoughts on using __future__.unicode_literals?
[21:42] <wgz> it's a bad idea.
[21:46] <jelmer> wgz: because string handling in python3 isn't quite right either?
[21:48] <wgz> just breaks too many basic things
[21:48] <jelmer> wgz: well, we'll have to deal with that at some point, if we ever want to support python3
[21:49] <wgz> the number of things that need to be str/unicode are fewer than those that need to be str/str
[21:50] <wgz> that's 3/2 confusingly...
[21:50] <jelmer> ah, hmm
[22:36] <thumper> morning
[22:36] <thumper> does anyone remember a simple way to use meld to see the diff between two branches?
[22:36] <thumper> or am I going to have to look it up again :)
[23:51] <poolie> hi all
[23:51] <wgz> hey poolie
[23:51] <poolie> hi wgz
[23:52] <poolie> i'm riding a pangolin
[23:52] <poolie> it's bit bumpy
[23:52] <poolie> but good
[23:53] <wgz> yeah, the guys on thursday were talking about that too