On Sat, Dec 1, 2012 at 8:14 AM, Eric S. Raymond <e...@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 <jran...@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.
