On Sat, Dec 1, 2012 at 1:36 AM, Eric S. Raymond <esr_at_thyrsus.com> wrote:
>...
>> Why do forges not do that? I don't know, but it's definitely not because
>> Subversion doesn't give them fifteen ways of manipulating the svn:author
>> property.
>
> I don't know either.
>
> I do know that protests to me of the general form "if they'd just use
> poorly-documented alchemical formula XYZ everything would be fine" aren't going
> to solve your problem. In no case have I ever seen, etc. The guy in the
> trenches is telling you that your fifteen ways aren't producing any
> result he can distinguish from "svn:author is always a Unix user ID".
>
> You can throw up your hands and say "the forges aren't doing it right", sure.
> And if you want to sleepwalk your way into obsolescence, that'll be a fine
> and effective way to get there.
Woah. Wait a minute, Eric. You're the one positing a [Federation]
scenario, then stating that Subversion does not meet that criteria. I
believe that is called a "Strawman".
I really like your idea of establishing a GUID, and transportation of
artifacts. This is all good. I also see that a good number of svn devs
are engaging with you on that idea. Yet... putting up a strawman and
killing it, doesn't work very well.
If we back up a step: Forges have been using svn:author as the
*authenticated* identity. They may express that identity as a simple
username, or as an LDAP attribute, or as an email name. If the forges
are not storing the identity per your ideal, then it seems wrong to
lay that on Subversion.
I *do* believe it is fair to state "the standard Subversion tools
should do $X to enable better federation". And I believe that is where
you can help.
Historically, Subversion has associated commits with authenticated
identities. It seems that you propose to adjust/augment that
relationship. If you can clarify, then I think we can make it happen.
Cheers,
-g
Received on 2012-12-01 08:17:49 CET