[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: simple proposal for Internet-scoped IDs

From: Branko Čibej <brane_at_wandisco.com>
Date: Tue, 04 Dec 2012 11:39:56 +0100

On 04.12.2012 11:08, Eric S. Raymond wrote:
> Daniel Shahaf <d.s_at_daniel.shahaf.name>:
>> Eric S. Raymond wrote on Tue, Dec 04, 2012 at 03:39:12 -0500:
>>> Contrast protocol D: the user sets *one* preference in *one* place.
>>> He's done, nobody else had to do any work, and the change is
>>> guaranteed to be reflected in all his future commits. No scaling
>>> problem here.
>>>
>> The scaling problem here is needing to run 'git config --global
>> user.email' in every home directory one commits from.
> Huh? You run it once, in your home directory. At least, I never
> had to do it again.

He did say, "in every home directory you commit from." It's not a given
that everyone always uses a single computer and has a single home
directory. Even on my laptop I typically run at least one additional VM
for development.

Furthermore, I don't /want/ to use the same identity for all my commits;
that might potentially work for open source, where I always use my
@apache.org ID these days, but I do more than just open source. So I end
up doing the git config dance for each clone.

I think you're assuming a bit too much about how people work. I agree
that your use cases are valid and your proposed solution sensible for
people who only ever use a single identity, but I'm not convinced that's
the most common case. Hence my statement earlier that kind of
configuration has to be per-server and even possibly per working copy (I
doubt that git lets you configure your ID per clone by accident). The
scaling argument isn't all that clear-cut.

The bottom line, as far as Subversion is concerned, is, IMO:

  * We cannot change the semantics of svn:author since everyone assumes
    it's an ID that's been authenticated by the server (whatever string
    actually ends up in there)
  * We can define another reserved property and make its contents
    client-configurable
      o this would be equivalent to using --with-revprop on commit, but
        automated;
      o and is something we'd probably want to generalize (I recall
        someone mentioning "auto-revprops" elsewhere in this thread).

I think this would cover your use cases well enough. I can't think of a
reason /not/ to add both auto-revprops and a new reserved property to
Subversion for this purpose.

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2012-12-04 11:40:33 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.