Exposure and Dependence

Question

I am trying to find a viable strategy for the next problem.

We have several web projects that depend on our structure. Everything is stored in our SVN and has its own project with all the necessary directory structure (trunk, tags, branch). In the example, we have the webprj01 and webprj02 projects, and we have the frm01 framework. All of them have the usual structure of an SVN project - trunk, tags, branches.

webprj01 and webprj01 are both dependent on frm01, while in real life frm01 is present as a subdirectory of webprj01 and webprj02. To do this, you can set svn: an external property in SVN, and we can set frm01 to specify / frm 01 / trunk inside trunk webprj01 and webprj02.

To make real coding, we need all three projects to be checked as a working copy and made changes to a specific code base in their own working copy. Unable to post changes from webprj01 / frm01 to SVN. This change must be made in the working copy of frm01 and transferred via SVN to the working pages webprj01 / frm01 and webprj02 / frm01.

This solution has a branch dependency problem. I am doing a production branch from SVN / webprj01 / trunk to / webprj 01 / branches / release-1.0.0. Two days later, working on the second project webprj02 and frm01, I can no longer have a stable check, as through svn: externals in branch release 1.0.0. The frm01 directory already points to new frm01 / trunk changes.

A simple simplified version of the problem is described. In our real situations, addictions sometimes go to five levels. I would like to get stable code from SVN anytime. In other words. When I forked / marked webprj01 as release-1.0.0. I want to get a stable code for this particular tag a year after creation.

Obviously, the described strategy using svn: externals does not do the job. What will be your experience in this situation? No need to use one order. Here you could use build scripts or another solution. I am looking for a long-term solution to a problem that will not be very dependent on human actions, as we are prone to errors.

Answer 1

In the Java world, I would not try to solve this problem using only a version control system - instead, I would use a dependency management tool like Maven +, a version control system.

In the place where I work, we have a setting that seems pretty common:

Any project "framework" lives in its own directory structure (trunk, tags, branches), as if you already seem to have it. They are also managed using Maven, and whenever something is checked, a new version of the component (in most cases a JAR file) is published in our local Maven repository (which is located on the Nexus server).

Any project that should use the "framework" project will depend on the specific version of the framework project - Maven automatically pulls this version from the Nexus server whenever the project is built.

This allows us to separate each project and infrastructure component separately, but still monitor the dependencies between them. We can even have several versions of the infrastructure components used by different projects, without completely losing dependencies.

So far, this has worked very well for us - I see only two drawbacks:

It takes some time to configure, especially if you have not used Maven before.

When you release each project, there is some overhead because you also want to free each dependent component to avoid depending on the version of the “external” versions of the other components (for example, “SNAPSHOT” in Maven terminology).

Answer 2

Eric is right, the dependency manager will help you - you might want to look in maven or ant / ivy.

Using svn: externals as a manager of dependence on poor people is a hack and requires a lot of discipline - it is PITA to find out which version of the framework is included, and then some joker is going to set an external link to project onto the trunk of the frame, and you will have very rough time determining the delta between releases.

In the past, I had js, css and xsl common to many projects packaged as .tgz files and published in the ivy registry using simple ant scripts, then projects have ant builds (and ivy.xml files) that resolve dependencies and then pack it all up. He worked, but

• Guys from third-party sites struggled with version control, and even more so with dependency management. It was very difficult to get them to “get” enough to post the changes in the general module to the local repository, and then build a project that depended on it to change them.

• The extra step mentioned by Eric was to release a few artifacts to get something ready for prod.

• Cruddy legacy design meant most of the changes, where in fact in the general code, 1 out of 10 releases of the deployed actually had changes in its code ... it was usually common code.

seriously - svn: external as dependency management will become a headache. It is worth the investment. Having said that these guys had problems with dependency management, they would be less likely, so sort svn: externals in many branches that you have now.

If I had to repeat this again, I would go to maven.