4

I have a very convoluted repository structure using subversion. Much of this has to do with the limitations of my team, security requirements, and the dependencies of the project. The structure used here is not optional as a consequence and cannot be altered.

The repository structure consists of the following pattern:

root-|- main -|- branches
     |        |- tags
     |        |- trunk - main - plugins
     |
     |- modules -| - module1 -|- branches
                 |            |- tags
                 |            |- trunk - module1 - plugins - plugin1
                 |            |- modules - ...
                 |
                 | - module2 -|- branches
                 |            |- tags
                 |            |- trunk - module2 - plugins - plugin2
                 |            |- modules - ...

The source of each external is a pluginX folder. The target is the plugins folder of the trunk one level lower (or the plugins folder of main). The documentation of the API is nigh non-existent unfortunately. I'm suspecting I need to the propset function somehow but how to point to the specific target directory and source directories is not described anywhere I've been able to find nor have I found any examples.

Edit: Each module may be pulled separately and worked on independent of the root project. I cannot just use the root for this. Hell, I can't even get a hostile response to this question!!

Richard Robertson
  • 150
  • 1
  • 14
  • 1
    Is "pluginX" the same as "module1", "module2"? – royalTS Jul 20 '18 at 05:48
  • Sorry, What exactly is the problem? You have a bunch of declarative statements, and a guess that you need to set file properties with svn propset, but there's no real problem statement other than the vague clause: "how to point to the specific target directory and source directories is not described anywhere." – gregory Jul 24 '18 at 16:12
  • create a folder 'build' in root folder, then use relative path to reference projects in your solutions, then configure all projects of their output folder to 'build', all output folders are relative path too. with this pattern, no matter who download repo, they could compile projects to same folder, and debug with same configure.dependencies issue will be perfectly resolved. – Dongdong Jul 24 '18 at 21:37
  • @royalTS - if you look there are a series of folders that are enumerated as "plugin1", "plugin2", "plugin3", etc. I just generalized that to "pluginX". – Richard Robertson Jul 26 '18 at 16:53
  • @gregory - the problem is defined in the title. Did the lack of a question mark confuse you? What follows is describing the parameters of the problem. Those would be declarative by nature. I do define as part of the reason I'm having difficulties was there is no direct documentation for this part of the API. This is a SVN repository with sub-repositories that I need to be able to link together with externals and pull/edit independently. To help you out I added the question mark to the title. – Richard Robertson Jul 26 '18 at 17:00
  • @Dongdong - You gave an answer as well as a comment. Your answer and comment ignore the stipulation that the project file structure is not subject to change. I wasn't asking how to structure the project. I was asking how to set up SVN externals using a particular library. – Richard Robertson Jul 26 '18 at 17:03
  • @RichardRobertson Is your problem to map the server paths to file paths? Adding a question mark to the title doesnt help. What is the actual Problem? – Git Jul 26 '18 at 17:07
  • @Git - No, that is not the problem. To understand this question in the first place you have to know what an Subversion external is. SharpSVN is a c# library for Subversion. I needed to set up multiple sub-repositories to have independent externals. What I needed to know was what library function(s) to use and how to use them to set each folders externals as needed. – Richard Robertson Jul 26 '18 at 17:21
  • 1
    @RichardRobertson I know both, but if you ask for "complex problem X", people will assume, that the "complex" part is the problem not X. – Git Jul 26 '18 at 18:40
  • 1
    @RichardRobertson: The problem is not defined in the title. But your comment finally does describe your problem: "I need to set up multiple sub-repositories to have independent externals...What I needed to know was what library function(s) to use [in SharpSVN]." Now, look back at your question--do you see that specific question anywhere? Nope. ...better questions provide better answers. – gregory Jul 26 '18 at 19:25
  • @gregory - then you rewrite the question title. Remember you have a limited number of characters so you need to be VERY brief. – Richard Robertson Jul 29 '18 at 22:54

2 Answers2

0

create a folder build in 'root' folder and use relative path to reference projects in your solutions, then configure all projects of their output folder to build\xxx folder, all output folders are relative path too. and in main program, configure assembly bindings with relative path again. with this pattern, no matter who download repo, they could compile projects to same root folder, and debug with same configure.

For very complex dependencies, like A=>B=>C=>D, the first time to open solution A, if B/C/D is not compiled and not referenced, then A will show a reference warning, you have to open and compile B&C&D, then A will work. but usually, we should add B/C/D to solution A, so, there is no more error at the first time we open it.

Sometimes, some source code is not open for all developers, so they can only get a compiled dlls, for those dlls, we need another folder (like 'tools'), which include all compiled assemblies in Source code server. we add file references with relative path in our solutions, and configure them as "Copy to local"=true

for many of project, we will use post-build or pre-build event to load or copy file from or to somewhere, all of them must be relative path too.

Dongdong
  • 2,208
  • 19
  • 28
  • Nope. The first part of the question makes it clear that the file/folder structure is absolutely not subject to change. Also your English is very poor and is nearly impossible to read. People are not "compiling" to the same root folder. There are no DLLs used in this project. This generates sub-projects of a larger project for Epic's Unreal Engine 4.X That means no "assembly bindings" – Richard Robertson Jul 26 '18 at 16:45
0

Answering my own question. The library I'm using has a function that sets the externals for a given folder in the local system given an absolute path to that folder. The library is a port from the C version of the library and apparently the authors just assumed that people would "just know" to look there.

Richard Robertson
  • 150
  • 1
  • 14