[Stefano Rivera] > Since upgrading to subversion 1.7, svn-inject no longer works: > > > ... > > svn co svn+ssh://purcell/tmp/test/pycparser/trunk /tmp/tmp.jKa9wdfMh5/trunk > > svn: E125001: Couldn't determine absolute path of '.' > > svn: E000002: No such file or directory > > mkdir -p /tmp/tmp.jKa9wdfMh5/trunk > > svn -m Creating trunk directory import /tmp/tmp.jKa9wdfMh5/trunk > > svn+ssh://purcell/tmp/test/pycparser/trunk > > svn: E125001: Couldn't determine absolute path of '.' > > svn: E000002: No such file or directory > > Command 'svn -m Creating trunk directory import /tmp/tmp.jKa9wdfMh5/trunk > > svn+ssh://purcell/tmp/test/pycparser/trunk' failed in '<unknown>', how to > > continue now? [Qri?]: q > > Aborting.
That is svn complaining because, apparently, it is run inside a directory that has been deleted. How would I reproduce your bug - how did you invoke svn-inject? I tried, and could not. And I can't find where svn-bp _would_ delete the cwd while it is still the cwd. (I am not a svn-bp user, so I don't know the common use patterns.) The fact that svn aborts because it can't turn '.' into an absolute path is arguably a bug, which I've pinged upstream about. svn wants to canonicalize the paths it acts upon, and then report them relative to the current directory - that's why it attempts to getcwd(). In fact this is not relevant if you pass it absolute pathnames, as svn-inject does, but getting svn to look up the absolute cwd only when it is working on relative paths turns out to not be trivial. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
