Those of us who do software development not only for a living, but also as a hobby, have probably encountered the following scenario:

Say, there is a project at work called WorkApplication on which you work together with a number of colleagues. And suppose that this application is making use of a library called SharedLibrary which is under development, meaning that there will be refactoring done on SharedLibrary, and any such refactoring must cascade to WorkApplication, so that WorkApplication always compiles and runs.

Obviously, for this to work, whenever someone opens WorkApplication in their IDE, they must also open SharedLibrary.

  • In Visual Studio parlance, this would make both WorkApplication and SharedLibrary "projects" under the same "solution".

  • In IntelliJ IDEA parlance they would be "modules" under the same "project".

  • In Eclipse parlance, they would be "projects" under the same "workspace".

Now, suppose that you also have a home project HomeApplication that you play with at home, (alone,) in which you also want to use SharedLibrary. (Suppose that the workplace does not mind if you use SharedLibrary for your own stuff, just as you don't mind if the workplace benefits from work that you put on SharedLibrary while working at home.)

Naturally, whenever you refactor SharedLibrary you want this to cascade not only to WorkApplication, but also to HomeApplication. Suppose that you are the only developer responsible for SharedLibrary, so your colleagues are unlikely to ever modify it, so you do not have to worry about SharedLibrary ever being refactored by someone who knows nothing about HomeApplication. What you want to make sure is that whenever you refactor SharedLibrary, regardless of whether you are doing it in the context of work or hobby, both WorkApplication and HomeApplication will always be updated.

How do you juggle these three entities so as to keep everything updated?

The problem seems to be that different parts of the solution/project/workspace will need to be in different source code repositories: WorkApplication and SharedLibrary need to be in the repository of your workplace, while HomeApplication needs to be in your home repository.

I am not sure how to mix multiple source code repositories under the same solution/project/workspace. Can it be done? Has anyone tried it? Does it work? What problems are common?

I can imagine scenarios where you forfeit the benefits of version control system operations from within the IDE, and instead you do all your updating/committing using external tools, each time separately for each repository, but can it somehow be done from within the IDE?

I do not want to tie this question to any specific IDE, but let me just mention that the IDE that interests me most is IntelliJ IDEA. (Unfortunately, I find the VCS-related options of IntelliJ IDEA to be very confusing. It seems like I might be able to define multiple VCS servers within the same project, but it is not clear how.)

1 Answer 1


You may think in terms of packages, which makes the location of the source irrelevant.

For instance, if you work with C#, your shared library can be published as a NuGet package. When you refactor the library, you don't cascade anything immediately to work application; instead, you publish a new version of the package, and when you're ready, you migrate the work application to the new version, like you would do if, for instance, Microsoft releases a new version of Entity Framework (you wouldn't put EF's source in your code base and ask Microsoft's developers to cascade their changes to your business apps, right?).

This is a publisher-consumer relation. You provide a free (eventually open source) package to your company which acts as your customer. They are free to update their apps to the new versions of your package, or to stay using the obsolete versions if they want to.

The fact that you work in this company is irrelevant: imagine yourself acting as a consultant who knows extremely well the concerned package and so deals with its actual implementation within the product.

Mixing home-grown projects with your work as source level is not a good idea.

If you host them separately (i.e. your personal library remains in your personal repository on your home server), this is problematic for the company, since:

  • There is no guarantee whatsoever that they will be able to access the source forever. What if you decide to remove it or to shut down your home server? Even loss of internet connectivity is problematic: at least developers should be able to access the corporate repository if it is hosted in the same building.

If you host them together, this creates a different set of issues:

  • The company may enforce specific rules you don't want to follow for your personal project, such as style guidelines. The company may require a specific code coverage, or linter-compliant code, or simply that any committed code is reviewed by your pairs. Those standards, normal in corporate environment, shouldn't apply to your personal project.

    Even worse, the company may not require something right now, but set a new quality requirement one day. What would you do? Modify your personal library to match? Remove the library from the source code?

  • Some managers may not understand what you're doing and find it awkward. In the worst case, they may consider that you are spending your time working on your own project at work, which can be perceived very bad.

    In the previous point, I mentioned updating your personal project to match company standards. What if your boss notices you are working on that (and so on your own project), while you're expected to solve bugs for the next release scheduled for the next week?

  • Intellectual property could be another concern. In many cases, the code within your corporate repository is the property of the company. You may find yourself unable to use, change or distribute your own project if you leave the company. More generally, everything may seem fine between you and your employer, and it is, until the relation becomes a mess and should be dealt by lawyers.

The publisher-consumer model solves all four problems:

  1. The company knows they will be able to access the current version of your package forever. Removing a package from NuGet is possible, but very hard.

  2. You don't have to follow any third-party rules and standards. This is your project, so your rules.

  3. There is no way to blame you for working on your personal projects at work. They are clearly separate.

  4. You keep the intellectual property of your project, and set the license of your taste. Again, your project, your rules.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.