I still haven't figured out how everyone communicates with each other on this site. It seems like there is some connection going on, as I see replies and references to other people's diary entries along the way. But it sure looks easy to completely miss a message from someone.

I've been browsing CVS entries on the web (specifically knipknap's canvas code (nice work, I enjoy seeing other C++ designs)), and a thought occurred to me.

Personally, I prefer to create local CVS repositories. This allows me to keep them local, they are faster, more secure in my opinion, and I can place them on the best machine for the job. It also lets me keep all the history local, as well as letting me tinker with the raw repository files to make up for CVS shortcomings, such as move. Overall, I am still very pleased with CVS, and have no compelling need to "upgrade" besides my own curiosity of what could be better.

A real drawback to my way of development, is that the history is unavailable to the outside world. When using public CVS repositories (such as SourceForge,
Alioth, or Gna), all your free software work is out in the open by default. There is no danger of forgetting to make a release, or having users waiting while you find free time to publish work in progress.

Happily, I can have my public CVS along with my local CVS copy. SourceForge and Gna document that they create nightly tarballs of the raw CVS repository, for backup purposes. This would allow me to keep personal copies of my repository, but I would be unable to push them back into the public repository if I worked off a local repository. That would be a dumb thing to do too, but I like my local repository, dang it. :-)

I have a couple options:

Use a public CVS repository, and be happy.

Use a local CVS repository, and publish nightly tarballs of my repository on my own website. This sounds like work, but would give me the most control

Use arch

I suspect I've answered my own question and it's time to dive into arch.

The main reason I like CVS is its simplicity. From the backend storage to the command line, it is mostly straightforward and doesn't place a heavy load on my fingers to use it every day. Arch appears to need some scripting to help cut down on the verbosity.