Ben Reser <ben_at_reser.org>:
> The only thing that's really lacking here is a good way to pass along
> extra property values in an easy to configure way per
> server/repository so that you can use a client defined value to put it
> in svn:author. I don't really see adding support for something like
> that as terribly difficult. The only caveat I would make is that you
> should realize the change here is a client side change and that it'll
> take some time for users to upgrade clients (most distros are still
> shipping SVN 1.6 over a year after 1.7 released).
>
> Once you have something like that, you can expose it to the hook
> scripts and they can change the svn:author field to whatever the local
> repository prefers. If local repositories want to store the local
> authenticated user in a different property they can also do this.
Sounds like I should write that patch to make a preferred-ID string
available out of ~/.subversion/config, then. As soon as possible.
> Given your goal that users shouldn't notice I'm going to assume you're
> allowing anonymous commits.
Actually that wasn't in my plan. It's sufficient that every commit
get an Internet-scoped ID, anonymity isn't required.
My plan about "users don't notice" works like this. Multiple instances
of my forge (the design's name is "Federation") each have lists of peer
instances. They flood project-index updates to each other. When you do
a transaction about project foo with instance bar, it looks in the
index and transparently proxies for wherever the project actually is.
Another consequence of this design is that you can back up your project
state yourself by asking the forge federation to send you the same blob
it would pass around if a peer said "Aaargh! I'm about to die!".
With a little work, the federated instances could set up a rolling-backup
scheme that would protect pretty well against unplanned server deaths.
I designed this after Berlios told the world it was going down, and
potentially taking hundreds of projects with it. It's still up, but
I don't ever again want to have to bet everything on the eternal
stability of a single forge site.
This is a serious vulnerability in the open-source infrastructure.
I want to fix it.
--
Eric S. Raymond
Received on 2012-11-29 20:26:08 CET