"Jonathan S. Shapiro" said:
> 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.
From a revision, definitely.
BTW one thing I'd like to check -- if you make the entire check-in one atomic unit, will it be possible to do the following:
There's a definite need to be able to create a "view" or checked-out set of files which contain a subset of files with 1 set of changes, and another subset with a different set; imagine a view containing version "A.latest" of all files except for directory D, which contains version "A.stable" in some way (e.g. view spec in Clearcase, client spec in Perforce, etc.).
What happens if one of the checkins on the revision-path to "A.latest" affects files in directory D? If you make the change an atomic unit, would this be possible?
--j.