On Sat, Dec 1, 2012 at 8:14 AM, Eric S. Raymond <esr_at_thyrsus.com> wrote:
> This one confines your Unix-ID adhesion to the FULLNAMES array, which
> is a long step in the right direction because it means your repo history
> will be local-ID-clean.
It confines it to whatever value that python script could be taught
how to get it. I'm sure you can modify the python script to get it
from a different source.
For that matter you could have the script in the repo and use a
post-commit script that updates it everytime someone commits it. Then
the script moves with the repo.
> But it doesn't actually solve the mobility problem. If the project
> ever moves, you still have to patch the FULLNAMES dictionary by hand.
> This approach won't scale very well.
Of course it doesn't scale. It's a trivial example to demonstrate the
technique.
What I don't understand is your hypothetical situation is demanding an
awful lot of Subversion. You've scoped things like an issue tracker
and other things as being part of this. But for some reason you've
not bothered to scope an authentication system and exporting and
moving the users. All of these forge sites allow you to access the
repo with the same username/password as the issue tracker etc...
So you need some sort of federated (even if it's just specific to each
project) authentication system. Subversion doesn't provide that for
you, nor should it.
You're probably not going to find one that's ready made to your
situation either. You're going to need to do some thinking about how
to configure things.
> I also note that you do really want "J. Random User <jrandom_at_foobar.org>"
> with a preferred "home" address as part of the mix, because the
> entropy of human names alone is not quite high enough. Yes, if I see
> "Daniel Shahaf" I'm pretty sure there is only one of those. But
> "Willam Smith" or "Robert Jones"? " :-)
And it's trivial to adjust it to be that way.
> But the first? I've heard of LDAP and know roughly what it does, but
> I've never seen a live instance. Forges don't have them. Maybe I'm
> being parochial, but this seems like a solution for a case too unusual
> to be very interesting.
Why not? What's so hard about setting up an LDAP instance for the project?
>> Alternative server-side implementation (via breser):
>> [[[
>> command="svnserve -t --tunnel-user='Daniel Shahaf'" ssh-rsa ...
>> ]]]
>
> Um, does this mean everyone's commits are coing to look like
> Daniel Shahaf made them? If not, where is --tunnel-user going to
> come from?
No this setup is something that gets added to the start of everyone
line (different for each user) of the authorized_keys file for the
user you're having people use with svn+ssh. Generally I'd expect
whatever system you're using to manage these keys is going to handle
this for you(e.g. user goes to some web form and pastes their public
key in and then this system edits the authorized_keys file). You'll
have to write something.
> The lesson from this criticism is intended to be that it's not
> enough to make Internet-scoped IDs possible, you have to make
> them *easy* - that is, not disruptive of normal workflow.
I'd say that the choices you've been presented with are relatively
easy to implement. Tons of corporate users have managed to implement
things like this.
What isn't easy is what you're really asking to do. Which is systems
design. You want to pull together a bunch of disparate programs and
make them work together in a coordinated and seamless way. That's not
terribly easy to do without putting some degree of time building the
infrastructure around them.
Which is really what a forge site is about.
If you want to build a forge site that has portable setups then you're
going to have to take and write a way to export all the data (not just
the repositories, issue trackers db, wiki db, etc...) but also all the
glue between those pieces.
Unless you've got multiple existing forges already interested in
implementing something like this that come together to implement an
agreed upon data format. Your best bet is going to be implementing a
packaged up system that uses various systems and then exports and
imports your data format.
We've gone well beyond the area that Subversion is involved and quite
frankly we're heading entirely into off topic design work for your
forge.
Received on 2012-12-01 15:28:29 CET