RevId began its existence in I43a6d6e4:
Introduce RevId as an abstraction around revision strings
This may make it easier to replace Git with some other tool like
Hg or SVN, but it also offers us a convenient way to abstract the
data type and improve type safety within Gerrit's code tree.
There are no plans to support another VCS in Gerrit in the foreseeable
future; that would be a huge project. Even if we were to start, moving
away from ObjectId in the storage layer is just a drop in the ocean,
considering the heavy usage of ObjectId elsewhere in Gerrit (to say
nothing of other JGit APIs).
The arguments around encapsulating the type and improving compile-time
safety still apply, but ObjectId serves the same purposes--arguably
better, since ObjectId has useful and well-tested and -benchmarked
methods upstream in JGit.
There were other arguments for using RevId in the past: ObjectId
couldn't be used as a field type in ReviewDb, and isn't GWT-compatible.
These arguments no longer hold, since both ReviewDb and GWT are gone.
The specific implementation of RevId itself had some shortcomings:
* It didn't validate that the underlying value was a valid hex SHA-1.
* It allowed null as a value, although nearly all callers assumed it
didn't.
* The id field was non-final. (In practice it was not possible to
reassign it without using either gwtorm libraries or direct
reflection.)
* There were no convenient methods for converting to/from ObjectId,
a very frequent operation, largely because of the historical GWT
incompatibility.
Of course, these problems are fixable, but why bother? ObjectId serves
the purpose, and this way contributors don't have the cognitive overhead
of deciding which of two similar types to use.
Change-Id: Iff5644e21c51a7a8c12a113fd5a6a6ffaf60ae20
ef40918fb4