More information. I now tried to make a merge deeper in the wc, this time updating a module in drupal, same procedure with svn_load_dirs and guess what - that worked! http://pastebin.com/hVvpw4cv

So from what I understand can't orient itself from the root of the wc, but well deeper into it. Or it might as well that it has to do with that the core files and modules have different paths in the repo /www/vendor/d7-core vs /www/vendor/d7-modules

Joakim

On 22/06/2013 13:13, Joakim Schramm wrote:
Hi list,

my first post as I subscribed due to my problem, so please be gentle in
case I don't get it right ;-)

After upgrading from svn-1.7.9 to 1.7.10 and doing a merge operation
have done regularly during the last 2 years or so, I now get an E160013
Error:

svn dev # svn merge ^/vendor/d7-core/drupal-7.x-dev_2013-Jun-06
^/vendor/d7-core/current
svn: E160013: File not found: revision 4124, path
'/vendor/d7-core/drupal-7.x-dev_2013-Jun-06'

The background is this: In my repo I run a vendor branch keeping track
of Drupal as well as a collection of Drupal modules and themes. In the
same repo I also vc a collection of web sites, which are all tracked
against the vendor branches.

On Thursday evening I upgraded to 1.7.10, and on Friday I made my first
vendor update with the new version, updating Drupal 7 code, using the
svn_load_dirs script:

svn_load_dirs.pl -t drupal-7.x-dev_2013-June-21 -svn_username xxxx
-svn_password yyyy svn://svn.xxxx.com/www/vendor/d7-core current
/tmp/drupal-7.x-dev

and as from what I can judge nothing seems to be wrong with the output
and the commits are done. I can post the output in case it's needed/wanted.

I then (try to) make the merge operation above in the web root of one
site resulting in the error.

Subversion is running on a Gentoo Linux server using svnserve. I also
work with this repo from a Windows workstation using TSVN and using the
TSVN repo browser I can clearly see that the 'not found' file (which
actually is a dir) is present.

'revision 4124' is the last revision in repo created by the load_dirs
script.

Well, I don't know where to start looking as I can't really see anything
is wrong, except for the error message, but hopefully someone else can
or have an idea, or is this possibly a bug?

thanks,

Joakim

Reply via email to