[development] Naming the CVS abstraction module

Jakob Petsovits jpetso at gmx.at
Sat Jun 9 00:16:24 UTC 2007


Derek (in his mentor role) and I are in search of a good name for the module 
that I'll develop during this Google Summer of Code. (...once again, as the 
directory in CVS will be recreated due to other reasons.)

We need your input on this issue, as none of the options seems to be
the ideal one.

Objective of the module:
To abstract the existing CVS integration into a separate API and an 
accompanying set of projects, so that we can more easily plug in other 
backends for different version control systems like Subversion, git, etc.

Now, naming this thing is a bit hard, as there's no widely standardized term 
for these things which handle repositories and stuff.
We can currently think of the following names for the module:

- rcs.module / "Revision Control System API"
Slightly suboptimal since there already is a revision control system that goes 
by the name of "RCS". As the predecessor of CVS, it's not very common these 
days, but people still use it. So when calling the module "RCS API" it might 
be mistaken for the original RCS.

- vcs.module / "Version Control System API"
Better, but the name is quite verbose. I'd personally prefer
"Version Control API" because it's snappy and easy to grasp from the 
beginning. However, there are other drawbacks on this.

- vc.module / "Version Control API"
Fixes the previous issue, but occupies a top-level acronym ("VC") that is used 
for a common term like Venture Capitalists, selected indiviuals also think of 
Visual C when reading this acronym. So this screams for namespace clashes. 
Also, it doesn't immediately prompt associations for version control with 
most people, which is certainly the case for "VCS" or "RCS".

- versioncontrol.module, and other long names
Annoying as function prefixes in the code, I'd rather prefer short ones.

- scm.module "Source Control Management API"
Sounds reasonably good, looks reasonably good, but has the unfortunate 
drawback that it specializes on source control. There may be people though 
who use revision control for other stuff like client documents or config 
files, so this doesn't quite fit as well.

- Other proposals?
If you've got a good idea that we hadn't yet thought of, do tell us.

Please chime in on this issue. The development list might not be the most 
fitting place for this discussion, but given that the feedback in the SoC 
group on the same issue wasn't all too extensive (say, none until I 
specifically promted my other mentor Andy) we thought it appropriate to bring 
this issue to the mailing list.

What do you think would be the best name for this module?

-- Jakob, SoC student


More information about the development mailing list