Many people create a new archive on a yearly basis. A common practice is to add the year of the archive to the end of the archive name. For example, jblack@inframix.com--2004 or mister@x.org--public-2004.
The reason many people do this is that creating branches in Arch is a very simple and lightweight operation. During a year of active development one can expect to have accumulated a lot of temporary branches. Cycling the archive enable you to carry forward only the ones that see active development. This allows you to clean up the namespace. You also don't have to cycle yearly. You can do it twice a year (--2004a, --2004b) or every 3 years (--2004, --2007) depending on how often you create branches and how much clutter you can tolerate.
But how does a developer perform this task? When a new archive is created, it does not contain any of the revisions from the old archive. The answer is quite simple, actually. When the new archive is created, the developer should decide which versions to carry over from his old archive, and creates brand new ones in the new archive. The developer then tags the new version in the new archive to the old version in the old archive.
See "Maintain your own version of another project" in Arch Recipes for specifics (the "other project" is your old old archive). You only need to read the first section describing tagging the old version into the new archive. The rest of that section, on merging changes from the other project into your tree, doesn't apply because, presumably, you will no longer be adding to your old archive.
The easiest way to ensure that you don't accidentally commit to an old archive is to make arch think it is a mirror (commiting to a mirror is explicitly disallowed). To do that, just put the name of the archive in a file called =meta-info/mirror in the top level of the archive. Alternatively, you might want to use a command like
tla commit --seal -s 'New version in arch://new-archive/cat--branch--ver'
on each version in the old archive. This will make a --version-0 revision in that version and make it impossible to commit to it without specifying the --fix option. This also has the distinct advantage of notifying people watching your archive that you have a new archive.
It's OK not to cycle
Archive cycling is by no means required to use arch. Many arch users never, ever cycle their archives. There is, in fact, no performance benefit in doing so for most of the basic version control commands. Arch archives are organized hierarchically, so you really rarely have to deal with the archive as a whole.
The main problem with not cycling your archive is that all your revisions, versions, branches and categories are in one place. So, commands that act on the whole archive (or category, or branch) will take longer. Some examples:
- tla categories -- if you have lots of categories, this takes longer
- tla branches -- lots of branches in a category will make this take longer
- tla versions -- if you have lots of versions in a branch, this will take longer
- tla push-mirror -- if you do this with a whole archive, it can take a long time to synch.
In addition, doing system maintenance like backing up your archive, moving your archive to a new location, or what have you will take longer.
The main advantage of not cycling your archive is that all your revisions, versions, branches and categories are in one place. So you can do queries on very old versions, look at histories, or restart an old project more easily. You also don't have to deal with all the hoohaw needed to cycle repositories.
How might this be different in a corporate environment?
[Orleans New]