Subversion - where does svn: externals come from?

Question

I am going to establish the rule here that all svn: externals links should come from one of the other project tags, never from its chest or from any of its branches. Is this a reasonable rule or do you see problems / problems with this approach? I am trying to achieve a stable development environment, and I am wondering if this rule will slow down or hinder development.

Answer 1

You are worried that a project with "svn: externals" may change without any obligation in this project. This is a problem because it is difficult to detect a violation or return to a good version.

So yes, requiring svn: external links are stable is a good rule. One way to achieve this is to use only tag links. Another way is to use the -r syntax to bind the external to the fixed revision. An example from a subversion book :

third-party / skins -r148 http://svn.example.com/skinproj

It will also protect you from tag changes, bad practice, which is more common than I like.

However, there is still a trade-off between stability and continuous integration . Often you need changes and bug fixes in external dependencies. In this case, you want your CI server to be notified as soon as possible that some changes in the dependencies have broken your project, so that the problem can be fixed as soon as possible. Most continuous integration servers support external resource verification.

For this reason, I believe that it is normal for external external elements to track the HEAD trunk of your dependencies (if you have a CI server). Just attach external elements to fixed revisions when marking and when creating stable maintenance branches.

Answer 2

I think it comes down to how mature your software development methods are. Do you have change management processes? Automated builds and reports? Etc. The safest thing to do is link to the tagged-build of the project (e.g. lib, dll, jar, etc.).

If an external project has weekly releases with frequent bug fixes, this can be useful and difficult. I found that without a good configuration management policy, tagging makes it easy to skip critical updates. And by the time you move on to “updating” this dependency, there may be many small changes that give most of the work.

For relatively stable projects, this is a good idea. The only problem is that not all IDEs make it clear that the source directory is an external refernce. In this case, it will be very easy for developers to make changes to this tag. From what I remember, Subversion has not yet implemented read-only, although I used an older version.

Answer 3

And the decision to actually allow external? I am sure that you are doing this for the right reasons. It is often better to simply check from the original place and / or check the dependencies in several places. I have been burned by external links in the past. If you are going to branch out, they will become a real problem if you do not “freeze” the outer when you do.

But to answer your question, it makes sense to have a specific place where all external links and links are placed. This means that you can control the contents of this location, and people know that when they put something there, it will be used as external and, therefore, depends on a large number of projects.

Answer 4

It depends on how stable you are.

• If your trunk is something that is always ready for release, then you really do not want your external links to point to the trunk.
• If you have release branches that only change by merging in revisions from the outside, then you really do not want your external links to point to the connecting line.
• If for any reason you need a revision in the chest that says: “I am using this version of this external now”, thus controlling all changes to the project code, you do not want your external links to point to the connecting line.

However, the developer should perfectly switch working copies of their external files to the torso. It is also good to point to the connecting line in the development branch. It may be ok to point to the connecting line before the first stable version of the project.

My personal approach is to be very attentive to the chest, because for me this has special meaning - this is the full history of the project. Everything that will be released must go through the body, by definition. If you can change the connecting line without having the changes written against the change (which is effective, what happens if you point to the outside of the connecting line), you lost control over the release of this revision and when you included this revision in your project.

Remembering that all your links to specific changes have changed, when you separate from the backbone, it can be a trial. Hudson can make things more prominent with tag support, but it doesn't help much.

Pointing to the connecting line can also lead to an untouchable library problem. "

When it comes to CI, there is no reason why you cannot perform CI for all components, as well as for final integrated projects. Choosing when to join in the latest library, you choose when you want to do the integration work.

However, it would be nice to have some kind of mechanism that says: "Your project uses an outdated library, the latest version is X." This is currently not possible.

In addition, if you have nested external elements, pushing a change from the base library through 5 layers of links until it reaches the main project is a pain.