On 01/05/2012 12:34 PM, Branko Čibej wrote:
> On 05.01.2012 18:25, Mark Mielke wrote:
>> On 01/05/2012 12:04 PM, Branko Čibej wrote:
>>> Ha, but svn:author currently fills that role. So why add another
>>> property?
>> If svn:author is defined as the primary key and also the
>> authentication key, it does seem simpler and more compatible with
>> existing tool assumptions and existing documentation.
> svn:author is basically "the username". Of course, many installations,
> especially those that use client certificates, will put other things
> there; an example I've ofthen seen is CN (Email), which usually is not
> what you'd really want since neither is unique or persistent.
Yep. Microsoft AD likes to use user's name in the DN (Distinguished
Name), or at least that is how many people seem to configure it. Yuck.
In any case, I would say it's the responsibility of the organization to
decide what their unique identifier is. If they choose a bad one -
that's on them. :-)
For many systems, username is pretty good.
>> There is of course some expectations around transition - such as we'd
>> only want to do the conversion to the new model once some key tools
>> supported it - "svn log", TortoiseSVN, Subclipse, and Crucible/FishEye
>> will begin working right away as the content of svn:author is now
>> recognizable as Crucible/FishEye user identifiers without the need to
>> define committer mappings and the Subversion metadata could be
>> re-indexed. I think it wouldn't be a problem beyond scheduling.
> Well, given that revision properties aren't indexed at all ... my use of
> the term "primary key" was a bit overdone, since it's really just a
> convention, not a requirement. But If we extend the way we identify
> authors, we'd better do something about enforcing these requirements, too.
Sorry for the confusion. I take it Crucible/FishEye is not widely used
around here? In any case, FishEye is a tool like ViewVC that scans
repositories such as Subversion repositories and creates an index to
allow users to perform lookups from a web view. All commits owned by a
user. Files that contain a particular text string. Etc. So when I
mention re-index above, I mean asking Crucible/FishEye to dump its index
and to re-scan the Subversion repositories. This would allow it to pick
up the new properties and reset its statistics.
In terms of requirements - I don't think Subversion needs to enforce the
requirements. It needs only make them known (which is perhaps what you
are saying). The only true requirement is that the unique identifier can
be reliably used to lookup additional data. The additional data may or
may not be unique keys - but this would be up to the upstream data
source to define. Display name would not generally be unique. Email
might or might not be unique - there are scenarios for both. For
example, some users may have a secondary account that they use for
another purpose, but they might have the same "contact email address". I
think the requirement is that svn:author be usable as a primary key, and
that any support for pluggable modules to provide additional data will
only be given this primary key to determine what additional data to return.
--
Mark Mielke<mark_at_mielke.cc>
Received on 2012-01-05 19:36:48 CET