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
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
o this would be equivalent to using --with-revprop on commit, but
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.
Director of Subversion | WANdisco | www.wandisco.com
Received on 2012-12-04 11:40:33 CET