Recommendations for developing and using shared libraries in version control?

Question

I always wondered how an actively developed shared library used in two or more projects should be kept in version control. I believe that this can be handled differently than a third-party library, as the internal library is likely to receive hot fixes, which should be distributed in many version control projects.

If its binaries are imported into projects that use it as it is updated (much like a third-party library), or can its source code be downloaded with the projects? Is it possible to have links to other version-controlled paths in Subversion or other version control systems?

Now I am working on a project that has shared libraries that are located elsewhere in Subversion (and are used in many projects) that have been checked with the project, so any changes made to this project are not reflected in their "real" repository. I am going to suggest some changes to this, but I would like some thoughts on what is best suited for handling these shared libraries.

Answer 1

As already mentioned, external SVNs are a good way to do this. Through them, you can link to other parts of your repository (or other repositories, also FTM). A project can refer to the head of some other (library) project or some branch or tag. The last two provide stability, the first of which is always updated with the library.

I saw various schemes on this line using CVS (there are no external links, so these were proven scripts that had to be executed) and SVN. In the company I currently work for, we have different top-level folders for projects and shared libraries. Projects can reference libraries. On the outside of the project, these external links usually refer to the voices of libraries, in tags and branches - projects related to tags of libraries (or, sometimes, to branches).

Answer 2

If you use Subversion, I would use svn: externals , which allow you to create dependencies from one Subversion repository to another.

Answer 3

Subversion allows you to reference other paths using the svn: externals property.

However, often you will need a little more control over the state of the project than just "take everything that is in the head of the shared library." In this case, I would suggest writing the binary of the compiled library to each of the other projects that use it. Thus, you control the deployment of the library for each of your clients.

Answer 4

Yes.

Re-split “sub-libraries” into separate projects earlier and often.

Look at the open source methods: most of the things are a lot of small projects that are put together.

Create many small projects.

Avoid checking binary files. Again, follow the open source practice. Keep the source in subversion.

Create binaries and place them in the "project share" directory separately from the source.

Answer 5

The right tool to solve this problem is Maven . Originally developed for Java, it can be used for any existing programming language.

Maven creates a repository on your computer where all the modules are located. You can also create a public module repository, allowing other users to download modules from there.

Each module has a list of dependencies that are automatically resolved (read downloaded). At the stage of building the project, the one suitable for your plug-in with the programming language will place all the dependencies in certain places to see their source code.

Maven is an excellent multifunctional tool, but it is very difficult to master that it is only a minus.

Answer 6

We save code from shared libraries in SVN in our project folders. We also transfer the binaries to another project folder called Dependencies. We use svn: externals to bring the necessary links to projects.

Answer 7

I don’t even understand the question. If foo is libbar dependent, why do you want to keep the source for libbar in foo VCS? You refer to libbar or import the bar module, if necessary for the language. Why do you want to confuse the source tree for your project? My "hello world!" project depends on libc. So is my "hello dolly!" project. None of the projects support the libc source in their code base. To do this would be insane. Why process internal libraries as opposed to third-party libraries? In short, the best practice is: do not do this. If your library has corrections that need to be distributed for your projects, use dynamic linking.