Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4F05ED9A.1020501@mark.mielke.cc>
Date: Thu, 05 Jan 2012 13:36:10 -0500
From: Mark Mielke <mark@mark.mielke.cc>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
CC: dev@subversion.apache.org
Subject: Re: format of svn:author
References: <20111230193655.GA2910@lp-shahaf.local>
 <4EFE63EA.7030302@mark.mielke.cc> <20111231023547.GA22418@daniel3.local>
 <4EFEA4EC.6050406@mark.mielke.cc> <20120101022113.GA1725@daniel3.local>
 <4F001F05.4070407@mark.mielke.cc>
 <20120102075208.GA10330@apb-laptoy.apb.alt.za>
 <4F016C1C.3020400@mark.mielke.cc> <4F026FC4.1090200@web.de>
 <4F03145F.9010608@apache.org> <20120104100948.GF8604@xvii.vinc17.org>
 <4F042B6A.2060706@apache.org> <4F044AFE.1030600@mark.mielke.cc>
 <1325702550.6029.YahooMailNeo@web86708.mail.ird.yahoo.com>
 <4F055188.3000300@mark.mielke.cc>
 <1325759535.3851.YahooMailNeo@web86708.mail.ird.yahoo.com>
 <4F05D807.8040804@apache.org> <4F05DD0E.7030502@mark.mielke.cc>
 <4F05DF0D.2040801@xbc.nu>
In-Reply-To: <4F05DF0D.2040801@xbc.nu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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@mielke.cc>