How do I stop SVN creating a "branches" folder when updating an external referencing a GitHub repo?

Question

I have a simple git repo hosted on GitHub that I wish to pull into a project that is maintained in an SVN repo. There are 2 branches in the Git repo (currently, more will come) but I only want and need to pull in the current "master" branch of the Git repo.

I am using a simple svn:external to achieve this, using the "/trunk" path appended to the Github repo URL and this is basically working well.

The only problem is that when I update my SVN working copy, in addition to updating the external (fundamentally correctly), I also end up with a "branches" folder that is not part of my project files in the Git repo at all (and never has been).

So, with a git repo master that looks like this:

  repo-root
      folder a
      folder b
      file a
      file b

I end up with a folder updated from the SVN external that looks like this:

  external-root
      branches
      folder a
      folder b
      file a
      file b

i.e. an extraneous "branches" folder has inexplicably appeared. If I delete the folder it is simply recreated the next time the external is updated. The branches folder that is created is empty - it does not contain any files or data, let alone anything that relates to the actual branches on the GitHub side of things.

I am using TortoiseSVN, and if I use the repo browser to view the git repo referenced by the external I see nothing to suggest where this extraneous "branches" folder is coming from, just the expected branches/trunk structure:

   repo-url
      branches
         develop
      trunk
         folder a
         folder b
         file a
         file b

If I use the "Show log" facility of Tortoise SVN to try to view the history of this branches folder, github responds with "non-existent in revision NN".

Where is this branches folder coming from and how do I stop it ?

Answer 1

Detailed investigation of the issue, in conjunction with the very helpful support staff at GitHub, have lead us to conclude that this was a bug in the older version of TortoiseSVN that I was using when I performed the initial "update" of the external.

This we believe lead to some misconfigured meta-data in the SVN repository which was then being - inappropriately - applied by later, updated SVN clients (the branches folder would be "restored" after deletion even by an alternate, command line client such as SlikSVN).

However, after deleting the externals configuration entirely, re-committing the "external-less" SVN repository, and then re-creating the external references, the branches folder no longer appears, thus we conclude that whatever the bug was and in which-ever component it resided (TortoiseSVN or github SVN API layer) it is now fixed.

If you experience this or a similar issue with an svn:externals referencing a GitHub (or perhaps git generally) repo, then with a fully up-to-date SVN tool chain:

1. delete all working copies of the external files
2. delete/remove the svn:externals configuration in the SVN properties
3. commit the SVN repo in this state
4. then re-create your svn:externals

This should solve the problem.