Ben Reser wrote: > Eric S. Raymond wrote: >> Peter Samuelson <pe...@p12n.org>: >>> [Eric S. Raymond] >>> > 1. Add support to the client tools for shipping a FULLNAME field >>> > mined from somewhere under ~/.subversion. Maybe the existing >>> > username entry will do, maybe it won't - I see arguments both >>> > ways. I don't care, we can fill in that detail later. >>> >>> This part (upon which your whole proposal hinges) makes me scratch my >>> head a bit. Why should the client be involved at all? >> >> Because other ways of setting this bit of metadata have serious though >> un-obvious issues, and offer only partial coverage for particular special >> cases. [...]
>> [...] first I want to clearly >> lay out the desirable qualities and consequences of fullname/email >> attribution cookies; they bear on the use cases I'm going to describe. >> >> 1. They have enough entropy that collisions aren't a practical problem. >> [...] >> >> 2. Because of (1), they allow repositories to be mobile [...] >> >> 3. They imply an email pointer back to a responsible person for each >> commit. >> >> 4. They function as Internet-wide primary keys [for reputation ...] >> >> Now, with these use cases in mind, let's consider different protocols >> that might allow users to set their attribution cookies. [...] > [...] Frankly, I don't think the vast majority of the user > base cares about this problem, which gives them little incentive to > care about setting this configuration setting. [...] > I agree with Brane though that I really don't see a problem with > auto-revprops or a defined rev property name for this use. But I also > think that most people just won't use this. As evidence that this community thinks it makes sense to store the full name and email address of each contributor in our own project, I will point out that we already do so. We maintain a mapping from svn:author to full name and email address in the 'COMMITTERS' file in the repo. For non-committers, we write that information in the 'Patch by:' line that we put in the log message of each contributed patch. That doesn't mean every project in the world will want it, of course, but there seems little objection to providing the facility in general. It certainly makes sense to me to design-in an easy and consistent way to hold that kind of attribution. Some important things seem not to have been discussed. VISIBILITY The proposals so far have focused on getting the new metadata into the repository (or more generally into the Subversion server). In order for a user to bother setting their id, any proposal needs another facet: visibility to the user. The only way a user will currently see an extra rev-prop is if they specifically query it with something like 'svn propget --revprop' or svn 'log --xml --with-revprop'); there needs to be easy and obvious visibility. How and where will Subversion command-line client and GUIs show the attribution id? 'svn log', 'svn blame', 'svn:keywords=Author', etc. What should this value be called? I'm calling it 'attribution' here but that might not be right. MEANING If a user is asked to set their email address, they want to know why -- whether they're going to receive emails to that address, whether it's going to be publicly visible, whether it needs to be reachable for confirmation, whether it should be the address most associated with the project they're committing to or their current work address or personal address. So it's important for us to decide what to call this thing and how to describe it. What do other VCSs say? Is there a web page where we can read about it instead of waffling about it here? Specific questions to be decided: * Does it identify the 'author' or 'owner' of the content of the commit (it's an attribution for the work), or does it identify the committer? Can one commit list more than one attribution? No attribution? * What is the formal degree of the mapping between committer ids and these ids? 1:1, 1:many, many:many? Is that per repo or per project (in a multi-project repo)? * Does the name and email address recorded in each old commit mean the name and email address as they were at the date of that commit (svn:date revision property), or the user's current name and address (which might change over time)? MUTABILITY Should we allow adding an attribution id retrospectively to past commits? Should we allow correcting a dummy or typo'd attribution on past commits? Should we allow updating past attributions to reflect a changed email address or name? If we decide to allow any of these, the design had better accommodate that. - Julian
