Appendix A Mirroring

A.1 Introduction

As a normal course of development the release tools assume that the base releases and the tools are accessed by all developers from one central location. This location is typically on a networked file system such as AFS that allows global distribution. There are however occasions where some developers may be unable to use the central repositories for the development. For example, laptop users are only occasionally connected to the network, but often want to continue development even when they are disconnected. Another example are those developers who have so bad network connections to the central repository that they cannot use it for profitable work.

SRT allows a developer or a site to mirror the release tools themselves and the base releases in part or in full. Both of these happen manually by the commands run by the developer or the software manager for a site. Usually the tools themselves would be mirrored whenever a new version of them have been installed in the master repository. Official releases can be mirrored after the librarian has frozen them. Transitive mirrors are not allowed; everybody must always mirror from the central repository. Most software librarian's tools will also refuse to operate on a mirror.

Official releases can be mirrored in two ways: by copying the files from $SRT_DIST to the mirror area, or by building the release from source. The former would be used when the network connection is reasonably fast and it is otherwise possible to use the binaries[1] Otherwise one would check the releases out from the version control system and build them exactly as the software librarian did. Needless to say, the former is the preferred way of mirroring and should be used whenever possible.

If you are mirroring base releases because you have a slow network link, you should not expect to be able to mirror every base release. In a large software project the size of a release may be a gigabyte or more per architecture and they may be created on a weekly basis. If your link is so slow that you cannot access the central software repository effectively, it is hardly going to be fast enough to let you transfer such massive amounts of data so frequently. One solution to this issue is to not mirror so often, for example just once a month, or to mirror only partial releases for a limited set of architectures. This latter choice is possible if the developers on that site will not develop all of the software, but only parts of it. Yet another alternative is to use physical transfer and not networks: burn the releases on CDs and ship them to regional centres once a week. Other remote sites would then use the software at the regional centres, not from the central repository.

You are not allowed to mirror the version control system under any circumstances. This is not useful because of the remote access capabilities built into CVS: as far as CVS is concerned, you do not need to be connected to develop the sources, only when you perform CVS operations. These usually occur rarely enough that you can simply do them when you are connected again. If your site has a bad network connection, the CVS operations will just be slow but guaranteed to work successfully--the remote CVS can function over amazingly miserable networks.

Notes