Re: Entity back pointers to the branch Eivind Eklund (eivind@yes.no)
Tue, 13 Jun 2000 18:57:22 +0200

On Mon, Jun 12, 2000 at 10:59:42PM -0400, Jonathan S. Shapiro wrote:
> I think you have it right, but I think there are two different things going
> on here.
>
> One is to be able to go back and look at the code that changed in a given
> file over time. The other is to look at the checking commentary that was
> included when those files were checked in. The first (which I think is what
> you are talking about) is easily done. The second sort of requires a policy
> choice. The commentary is just strings, but these strings have to hang off
> of something. If you force people to enter them per-file, you tend not to
> get overview. Conversely, if you key them per change, it's easy to fail to
> get commentary on specific files.
>
> My immediate question is which kind of object a checkin comment string
> should hang from: a revision or a file. At the moment, it hangs off of a
> revision. I'm inclined to think that's the better choice, but I wanted other
> opinions.

My choice in OVCS has been to have them hanging off both - a changeset consists of a lot of new versions, and each version can have a description, and the changeset itself is a new version of the LOD (branch) and can thus also have a description. This gives a nice structure to the repository, but has the disadvantage that it is somewhat difficult to look up the history in a distributed setting (you need access to the original LOD, not just the single object from the LOD that you have merged over to the new LOD).

You definately need a description to hang off a changeset, to describe what the changeset does - but having the opportunity to give a deeper description of each part of the change. A different twist is to attach a comment with internal structure (through some form of markup, most likely) to the changeset, and always look up the changeset when you want to find the descriptions.

An important aspect of commit message recording: Commit messages should NOT be replicated all over creation (as CVS does). For changes that touches many files in a small way, this significantly bloats the repository (for good commit messages in CVS, often by a factor of 10x+.)

Eivind.