1

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 ?

Deltics
  • 22,162
  • 2
  • 42
  • 70
  • That's fairly strange. It might be a tortoise-svn bug -- I know tortoise will automatically create a trunk/branches setup if you ask it to. I would be interested in seeing what a svn status (check for modifications according to tortoise I believe) or diff of the git working copy says. – AlexMA Feb 13 '13 at 19:18
  • 'tis strange indeed. It looks like a git/github thing, mis-reporting the existence of that folder, because after updating, the SVN working copy is "up to date". If I delete the branches folder SVN/Tortoise then reports it as "missing" and restores it if I Update once again. So far it's just annoying, but it could become a major problem if I ever wanted or needed an actual folder called "branches" in one of my (external) repos. – Deltics Feb 13 '13 at 21:40
  • Possibly--I don't know much about git or github, but I'm doubtful that it would add a directory unless you were doing something unusual. How are you "pulling" from github? I'd like to isolate the specific step where the directory suddenly appears. There's nothing in the branch directory's (svn) history? – AlexMA Feb 13 '13 at 21:51
  • It's all in the question. The "pull" from git is not a pull (in the sense of a formal git pull operation) as such, but the result of defining an svn:external that references a git repo hosted on github. github "talks SVN" to SVN clients. I've updated the question with what happens when I try to view it's history as it might be useful information (github reports "does not exist"). – Deltics Feb 14 '13 at 00:20
  • Well, I just looked at https://github.com/blog/1178-collaborating-on-github-with-subversion and it seems like github, in order to facilitate svn/git compatibility for pulling and pushing, really encourages a strict workflow involving branches. Any chance this is being forced upon you? Might be worth a test with an external repo that does have a /branches/ with stuff in it. – AlexMA Feb 14 '13 at 00:35
  • That is what I'm doing - essentially. The crux is that the "master" is your deployed (or deployable) code. "master" is surfaced as "trunk" to an SVN client, so my svn:externals url is [gitrepourl]/trunk. All the other aspects of the suggested workflow involves how you *use* branches (that you create for specific purposes), but I don't see that it dictates that branches *will be created* by github on your behalf, whether using SVN or not. I've logged a support case with github to see what they say. – Deltics Feb 14 '13 at 00:48

1 Answers1

0

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.

Deltics
  • 22,162
  • 2
  • 42
  • 70