Mark Phippard wrote:
> OK, I don't get it. All I am suggesting is that there be a setting,
> default would be off. If you would never use it, don't. I probably
> wouldn't either. I can see where some people would like to have it so that
> they did not have to deal with fixing log messages after the fact. Sure,
> they could add a pre-commit hook, but it would be a lot harder to write
> than it would be to add the feature, and if the feature is just in the GUI
> clients, a user can always use the command line to get by it.
As you already mention yourself: you can get around that restrictions
with the command line client.
> My larger point, is why impose your point of view on others. That seems to
> be what you are trying not to do in one sense, but in fact that is what you
> are actually doing. The property would be off by default, someone would
> have to configure it to turn it on, why should you care? Who says you are
> right?
I'm not insisting that I'm right on this point. All I'm saying is that
I'm the one who will have to deal with angry users, not you.
> Not to beat this to death, but think of an admin in control of a repository
> with hundreds of programmers. The admin can use the command line to do
> stuff like create branches and tags that do not require bug ID's. They
> want their programmers to always supply one though. If you have hundreds
> of programmers you are going to constantly be fixing log messages for them,
> not to mention writing scripts to inspect the database to see if there are
> commits with no bug ID. Although I suppose if you had a post-commit email
> script you could just keep track of the commits via email. The point is
> that programmers can have something they enter that means it does not have
> a specific issue number, if that is an issue, or someone can just not use
> the feature. Why not just try to support more usage models? Finally, as
> that other poster pointed out a few days ago, there might be admins that
> want absolutely everything to have a bug ID associated with it, even basic
> repository admin tasks.
Even if I would implement such a feature, it wouldn't take long before
users start working around it. First, there are always changes which are
never assigned to an issue, e.g. gramar/spelling fixes in comments.
Second: TSVN and any other client have no way to know if the issue
number entered is even valid! That means users will soon find out about
that and just enter some bogus issue number to get around that
restriction. Even if you then decide to use a pre-commit-hook to only
allow valid issue numbers, users will then just use any existing issue
number they find - even if the commit has nothing to do with it.
So the point is: all those "workarounds" users _will_ do will do more
harm than just entering no issue number at all.
And last but not least: once users find out that other clients don't
bother them with that feature, they will say that TSVN is crap and use
another client instead.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Aug 22 13:23:24 2004