1

We have four repositories in SVN, in which most of the files are same in all four of them. The reason why we are using four different repositories is, we have four different software products which share a lot of common files. Those files are not part of a common library because all four products are going to be built and run in different environments, say electron and browsers which have it's own dependencies for their respective environments. However, the business logic and functionalities are same.

Here my requirement is to make this more manageable, to reduce our development team's work and time. One idea I have is, if I commit any of the particular files in one repo, it could automatically affect the other three repositories. But maybe there is a simpler/more effective approach for solving our issues?

I tried to find a solution by googling it, but didn't get anything which helped me. So, can anyone please tell me that whether I am on the right track, and please guide how to improve our workflow.

(The application is developed using Angular, but this is probably of minor importance.)

Improve this question
2
  • @DocBrown as per your suggesstion I had editted the question with sufficient information and also made it as tool-independent. Hope this gives sufficient info. If you need additional info. please leave a comment. Commented Aug 12, 2019 at 12:53
  • 1
    "we have four different software products which share some common files, also those files are not part of common library because all four products are going to be built and run in different environments say electron and browser which have it's own dependencies for their respective environments whereas the business logic and functionalities are same." I still don't understand why you can extract out a shared library. In any case, Git submodules work perfectly for cases like this, perhaps SVN has a similar thing. Commented Aug 12, 2019 at 13:35

2 Answers 2

Reset to default
6

If you are going to have the same file in four repos, and allow it to be changed in any of the four places, you will sooner or later run into the problems of collisions, how to work with branches, how to handle commit messages, and so on, for a multi-repo case. Of course, you can try implement some homebrewn solution using SVN hooks, batch scripts and diff/merge tools. But then you start to reinvent a lot of the functionality which is already implemented in SVN and available as long as you use just one repo - and believe me, that is not what you want to do.

So the better approach would be to clean up this mess and consider to have only one place where the duplicate files are stored and edited. You have basically the following options:

  1. Consolidate everything into one repo.

  2. For each file, define the "leading" repo (which may be a fifth one, or one of the existing), where the file is maintained and use the "externals" feature of SVN to mirror them to the others.

  3. Keep each of the files in one "leading" repo, and use scripts to mirror them to the other places (but still forbid maintenance of a file in more than one repo). This may also be implemented using hooks, but has the advantage of avoiding collision issues.

  4. Create a shared library as an independ product containing the shared files, set up a package server (using something like Nuget) for distributing the lib among the different repos.

Each of these approaches has its own pros and cons, and depending on your environment and requirements, you have to decide which one fits best (or if you need a combination of them).

Note you do not just have to make sure that those shared files are available in all four products, you also have to make sure in one dev makes a change to it and tests it in one of the four product environments, this does not break any of the other three product environments. So it may be a good idea to set up a CI environment with a build server which runs the build and tests for all four environments at least once in 24 hours.

Improve this answer
0

Those files are not part of a common library This is irrelevant in your case, you have only to know|define - are|can be these "common" files placed in separate directory or they live in common location with repository-specific files.

Why does it matter? Just because after reading about SVN externals you'll know about two types of externals (directory- and file-based) and their limitations (directory-based externals can be linked cross-repository but target-tree in repo can't have additional local files, file-based externals can be used only inside single repo, but target-file can be used inside directory with local /for this directory/ files)

Thus, your migration path can be:

  1. Consolidate all 4 repos in one super-repo (dump-restore cycle) into different trees
  2. Move shared files from all into 5-th independent common location
  3. Link files from "common" to needed destination
  4. Fine-tune|redefine ACLs for all trees in new repo
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.