On 01/05/2012 12:04 PM, Branko Čibej wrote:
On 05.01.2012 11:32, Julian Foad wrote:
Branko wrote:
[...] you have to define which of the properties must have values
that are unique within the given repository; what is the primary key;
OK, let's say:
The "svn:author:authn-id" value is the primary key, and so is unique within a
[Subversion repository | Subversion server ?].
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.
The administrator must configure the Subversion server to perform a mapping from "svn:author" value to the
primary key, typically the trivial "x -> x" mapping but another example could extract "1234" from
"John Doe (1234)".
That seems less than optimal. Your specification changes the meaning of
svn:author. Do you intend this to cater to the installations that are
already abusing and overloading svn:author?
As one of these abusers, I don't mind re-writing history to fix this
problem. I don't have a need for catering here. As per the previous
email around the original problem of importing content from GIT, I don't
mind either of:
1) Prevent users from setting svn:author:* properties, but if they
happen to exist - to serve them instead of doing a lookup. In this case,
I would migrate historical data using revprops and make svn:author
become the primary key / unique identifier again.
2) Migrate users that do not exist into a database of removed users and
have the data available for lookup resolution.
Either would work fine.
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.
--
Mark Mielke<m...@mielke.cc>
