Toby Johnson wrote:
> 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.
Seems to me that the ideal way to deal with this is to circulate a rule in
your shop that "If you want support from me you must be running version X or
later."
If a user is happy with the software they have, not experiencing problems,
and in the middle of a task, why should they have to upgrade because of
someone else's whim, if their non-upgrading harms no-one?
> 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.
I am the one who first mentioned the environment variable mechanism in this
discussion. I agree it would be a good way to pass arbitrary information to
hook scripts.
I don't agree that passing the client version to the hook script is
necessary or desirable.
>> 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?
Forget svn:date - you could take the time from the server's clock.
This is a frivolous synthetic example in any case - to so has no possible
point whatsoever.
This case is different: It is a non-trivial new feature which has much
potential for abuse, and very little for positive use.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 10 22:02:08 2005