obliterate functionality?

[cowwoc]

Giorgos Keramidas wrote:
> 
> On Wed, 19 Mar 2008 18:54:55 -0700 (PDT), cowwoc <cowwoc at bbs.darktech.org>
> wrote:
>> Dirkjan Ochtman wrote:
>>> Have you seen Linus' talk on Distributed Version Control Systems?
>>> While he is not always nice about it, he has some interesting things
>>> to say on why it is good if all repository mirrors are created equal.
>>
>> Let's be clear here: repository mirrors are repository clients are two
>> different things. For one thing, mirrors to be equal to one another in
>> permission whereas clients tend to have less control.
> 
> I don't really `get' the distinction you are trying to make about
> `mirrors' vs. `clients'.  In the world of Mercurial there is no `client'
> concept.  Anyone who can `clone' a tree is a self-sufficient, fully
> independent `mirror' of the original tree.
> 
>> One would expect mirrors with read/write access to fall under the
>> guise of the same trusted organization, or else how do you prevent
>> someone from checking in random junk into the FreeBSD repository using
>> one of the mirrors? Point being, if all mirrors are equal, then they
>> should respect each other's obliterate commands.
> 
> Mirrors are usually one-way in the FreeBSD world.  They can `read' but
> they cannot (and don't really need to) `write' to the main CVS tree.
> This means that we are trying to solve the wrong problem, if we spend
> too much time worrying about `read-write mirrors'.
> 

I was trying to say that when Sun decides to obliterate some file from
OpenJDK, the command should get propegated to all their mirrors. People were
complaining that they don't want someone (potentially malicious) to be able
to propagate obliterate to their machine but I'm arguing that if you're all
mirrors you essentially have to trust one another. If you don't trust Sun's
obliterate then you're not really a mirror, you're a client. We need to
differentiate between the two kinds of repositories.
-- 
View this message in context: http://www.nabble.com/obliterate-functionality--tp16114445p16184358.html
Sent from the Mercurial mailing list archive at Nabble.com.