To be blunt - this is exactly why Subversion will stay small. When the
main people on the developer list hold small world views such as "it is
the responsibility of the organization that uses Subversion to customize
the dozens of tools they integrate with in a non-standard way", it is
guaranteed that Subversion adoption cannot go beyond a certiain
threshold. Which is fine. Sometimes you need small. It is simply not
feasible for every organization to customize every tool they use. The
thought itself is ridiculous.
But if this is truly the opinion, then my efforts here are wasted. Other
solutions provide these capabilities out of box.
On 01/03/2012 09:44 AM, Branko Čibej wrote:
> On 03.01.2012 04:02, Stefan Fuhrmann wrote:
>> * What is an author?
>> * How do concepts like "account", "person",
>> "role", "group" relate to that notion?
>> * What aspects of the above can be provided to /
>> handled by Subversion in a portable way?
>> * What are typical use-cases and do they match
>> with the definitions you use?
>>
>>> svn:author => unique identifier
>> That seems to be the hardest to define and may
>> be difficult to provide. Identifies the person?
>> PGP key ID?
>>> svn:author-name => Mark Mielke
>> That would denote the "person". How would
>> duplicates and name changes be handled?
>>> svn:author-email => mark_at_mark.mielke.cc
>> That looks close to the "account" aspect.
> I think this whole thread is slightly bogus. It should be obvious that
> whatever is in the svn:author field has better be a unique identifier of
> the person responsible for the commit, regardless of how it gets there.
> Once that requirement is met, everything else is "simply" a matter of
> getting the repository administrator to set up that identifier in such a
> way that the tools user by the users of that repository can do something
> useful with it.
>
> I propose that this is /entirely/ in the domain of the organization that
> is maintaining the Subversion installation. There is no standard way of
> identifying all pertinent user information -- or rather, there are some
> 57 different standards. There's nothing stopping the repository
> administrator from writing a pre-commit hook that adds tailored revprops
> with identifiers that comply with all those 57 standards and any custom
> ones, too. Asking Subversion to add reserved revprop names for all
> possible (not even plausible) identification schemes would be a bit like
> asking to add a different boolean property for every known character
> encoding -- in other words, an explosion of reserved property names that
> would, in general, give no benefit to the vast majority of users.
>
> All that would happen is that different organizations would abuse those
> property names in different, incompatible ways.
>
> -- Brane
--
Mark Mielke<mark_at_mielke.cc>
Received on 2012-01-03 18:11:58 CET