I'm the one who requested this on the TSVN list, and didn't realize this
entire discussion was happening over here!
Max Bowsher wrote:
> I've explained already why rejecting versions is a poor approach due
> to virtual certainty of false positives, and unnecessary encumberance
> on users.
You are looking at this from the perspective of running a repository
with many disparate users. In my shop, almost all users connect via
TSVN, and I want to be able to force them to upgrade to new clients
within a reasonable timeframe. This is not intended as an airtight
security feature. It is meant to get relatively non-technical people to
keep their machines updated, in order to give me a (somewhat) more
homogenous environment of users to deal with.
However, I think Steve wishes he never gave this as an example because
this use-case has dominated the conversation. I know and understand why
the approach I want to take may not be technically the best solution or
it may not prevent a determined user from circumventing it, but that's
not the point. This capability would (as you mention) be useful for
other purposes such as statistics-gathering.
An option which hasn't gotten much discussion is the ability to pass an
environment variable on to the hook scripts. This to me seems like the
best way to get arbitrary info from the client to the server without
cluttering up the repository. If someone wants to gather statistics on
their clients, they could easily write this to a logfile. I could use it
for the reasons I want, regardless of whether you think my reasons or my
approach are the best.
> However, the whole 'rejecting clients based on version' argument has
> opened my eyes to the potential for abusing the feature, making me
> feel rather disturbed about the whole idea.
This argument is pretty empty. Every single feature in Subversion could
be "abused" this way. I could set up my repository so that pre-commit
rejects commits on even-numbered hours of the day. I'm sure this would
be termed "abuse" by you, but does this mean that svn:date is a bad idea
and should not have been implemented?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jan 10 20:36:08 2005