Eric S. Raymond wrote on Wed, Dec 05, 2012 at 10:46:28 -0500:
> Peter Samuelson :
> > In fact, I'm having trouble coming up with a scenario in which identity
> > / contact information is interesting enough to want to publish via the
> > repository, yet not interesting enough to want to know before
Peter Samuelson :
> In fact, I'm having trouble coming up with a scenario in which identity
> / contact information is interesting enough to want to publish via the
> repository, yet not interesting enough to want to know before giving
> someone commit access.
Those aren't necessarily the *same* p
> Eric S. Raymond wrote on Tue, Dec 04, 2012 at 19:54:17 -0500:
> > O(1) cost vs. O(n) cost, where n is the number of repos. Q.E.D.
[Daniel Shahaf]
> No, O(n) cost <=> O(m) cost, where M is Ω(the number of homedirs).
And also, the O(n) is piggybacked on top of another cost that is
_already_ O(n
On 05.12.2012 11:44, Markus Schaber wrote:
> And I don't think that People like Linus Thorvalds will rebase the
> Linux kernel when ...
All the Internet-scoped IDs in the world, unique or not, won't help
people tell the difference between Thorvalds and Torvalds. :)
-- Brane
--
Branko Čibej
Dir
Johan Corveleyn :
> Just to be clear, this entire proposal / discussion is about a feature
> that only makes sense for public repositories, forges, open source
> projects, etc, ... right?
That's the use case in mind, but see below.
>AFAIU, there is no need for something like
>
Hi, Eric,
Von: Eric S. Raymond [mailto:e...@thyrsus.com]
>
> As the author of reposurgeon - which can edit old commits in multiple
> VCSes - I've probably heard more about the use cases for this ability than
> anyone else. Patching committers' past email addresses is not one of them,
> though I h
On Wed, Dec 5, 2012 at 1:54 AM, Eric S. Raymond wrote:
> Ben Reser :
...
>> 3) You keep assuming that email addresses are immutably owned by
>> someone. That is fundamentally not true for the vast majority of
>> people and frankly is never absolutely not true.
>
> So? Does this make it any les
Eric S. Raymond wrote on Tue, Dec 04, 2012 at 19:54:17 -0500:
> Ben Reser :
> > As it stands the entire functioning of your proposed solution here
> > is that people always remember to configure their unique id.
> > I don't see that as particularly easier than what the situation is
> > now where yo
Peter Samuelson :
>
> (Sorry, still feeling a bit verbose.)
Yeah, like *I'd* have any room to criticize on that score... :-)
> [Eric S. Raymond]
> > 1. They have enough entropy that collisions aren't a practical problem.
> > A human name alone does not. I'm excluding deliberate spoofing from
>
Ben Reser :
> First of all the Ohloh problem has already been solved by Ohloh. You
> can claim your commits.
More pointless handwork. We ought to be designing *away* from this
sort of thing...
> 1) Some people may prefer not to use the same identity on different
> projects, even open source pro
(Sorry, still feeling a bit verbose.)
[Eric S. Raymond]
> 1. They have enough entropy that collisions aren't a practical problem.
> A human name alone does not. I'm excluding deliberate spoofing from
> the analysis because we now have enough experience with un-cryptosigned
> commits in DVCSes to
Ben Reser wrote:
> Eric S. Raymond wrote:
>> Peter Samuelson :
>>> [Eric S. Raymond]
>>> > 1. Add support to the client tools for shipping a FULLNAME field
>>> > mined from somewhere under ~/.subversion. Maybe the existing
>>> > username entry will do, maybe it won't - I see arguments both
>
On Tue, Dec 4, 2012 at 3:39 AM, Eric S. Raymond wrote:
> Peter Samuelson :
>>
>> [Eric S. Raymond]
>> > 1. Add support to the client tools for shipping a FULLNAME field
>> > mined from somewhere under ~/.subversion. Maybe the existing
>> > username entry will do, maybe it won't - I see arguments
On 04.12.2012 11:08, Eric S. Raymond wrote:
> Daniel Shahaf :
>> 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 a
Daniel Shahaf :
> 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
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 prob
Peter Samuelson :
>
> [Eric S. Raymond]
> > 1. Add support to the client tools for shipping a FULLNAME field
> > mined from somewhere under ~/.subversion. Maybe the existing
> > username entry will do, maybe it won't - I see arguments both ways.
> > I don't care, we can fill in that detail later
[Eric S. Raymond]
> 1. Add support to the client tools for shipping a FULLNAME field
> mined from somewhere under ~/.subversion. Maybe the existing
> username entry will do, maybe it won't - I see arguments both ways.
> I don't care, we can fill in that detail later.
This part (upon which your
On Sat, Dec 01, 2012 at 09:41:17AM -0500, Justin Erenkrantz wrote:
> Whether I call him "zhakov" or "ivan" - it's the same person.
No, he's very different on IRC ("zhakov") to when I sat next to
him in-person ("ivan") in a bar in Berlin at 2am in the morning.
Really!
On Sat, Dec 1, 2012 at 8:53 AM, Eric S. Raymond wrote:
> There. You're done. It's backward-compatible (older installations
> can ignore the feature and nothing breaks). It's independent of your
> authentication method, but you can add auth checks if you care enough.
> It scales well because the
On Sat, Dec 1, 2012 at 9:28 AM, Daniel Shahaf wrote:
> BTW, the ability to change svn:author at will is one of the reasons they
> aren't global-scoped: if Subversion ever migrated away from ASF, we can
> _then_ change all svn:author revprops --- just like we once changed
> "zhakov" (implied @tigri
Justin Erenkrantz wrote on Sat, Dec 01, 2012 at 09:08:05 -0500:
> And, once again, I'll reiterate my earlier point that FULLNAME can be added
> retroactively pretty easily to existing SVN repositories. So, for
> svn.apache.org, after we might deploy a FULLNAME infrastructure, we could
> easily cra
On Sat, Dec 1, 2012 at 8:53 AM, Eric S. Raymond wrote:
> I'm not certain, but if your server-side hooks work the way I think
> they do, all of this except (1) can be done in Python. Not having to
> add complexity to your C code is a significant virtue.
>
Here's another approach to take with reg
This discussion has been fruitful. The responses from Greg, Branko
and others suggest that you guys are actually engaged with the
project-mobility problem now - apologies if my approach seemed a bit too
boot-to-the head, but I really am trying to be helpful.
I think I can now write a simple propo
24 matches
Mail list logo
