Mark Phippard wrote:
>>As you already mention yourself: you can get around that restrictions
>>with the command line client.
>
> Correct, and if you will not put this in the UI as an option, then the
> user has to write a commit hook which would be more complicated and less
> flexible since there would be no way around it.
Not the user has to write the commit hook, but the bug tracking tool
provider. User's don't have direct access to the repository and
therefore can't write those scripts themselves.
And isn't that your whole point? Making sure that there are no ways
around it?
>>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.
>
> I am not buying this. First, the feature has to be turned on
> specifically. Second the overwhelming place it would be used is a
> corporate environment where TSVN was provided to the user by the company.
> I find it hard to believe they are going to complain to you. Even if they
Sure, the company or the admins surely won't complain. But the devs will
soon find the mailing list and start complaining.
> did, there is a very simple answer and explanation. Why is it that you do
> not care about the people that might want this feature and have no real
> way to enable it themselves? The people that do not want the feature can
> always turn the feature off. Heck, since this is a folder property, they
> can even do it themselves.
Yes. They can remove those properties and even commit them. They will do
that right after they complained on the mailing list and some user told
them that that would be a way around this "feature". And about two hours
later the Admins of that company will start complaining on the mailing list.
I guess you've never been involved in an open source project. If you
did, you would know that such a feature _will_ cause massive complaining
on the mailing list. And you would also know that each mail sent to the
list takes time to read and answer. Time which could be spent much
better for developing.
> I do not buy any of this. People that go out of their way to enable this
I didn't think you would.
> feature will want it. We are building a system on a house of cards as it
> is since we are relying on a perfectly formatted log message for the
> features to work properly. Right now, if a well intentioned user forgets
> to enter the bug ID, adding it in later is not trivial and cannot even be
> done from the TSVN UI. It also would require a hook script be enabled to
> allow the log message to be edited after the fact.
Sorry? Can't be done from the TSVN UI? Please go ahead and start reading
the TSVN docs. If you're done with that, we'll talk about if it's really
"not trivial" and if it really "can't be done from the TSVN UI".
> As for your other items, people that want every commit to have a valid
> issue ID will have to use a hook to validate it. There will never be a
> way around that. However, I think there is a middle ground where you want
> 95% of your commits to have issue ID's and you do not care if someone has
> a catchall issue ID, or special issue ID for the rest. In this case, the
> property is a UI feature that makes the product easier to use since you do
> not forget to specify an ID. And again, you can always just not enable
> the feature in the first place since it is off by default.
The only thing I *might* add sometime:
Show the user a warning if the issue text box is left empty. But a
warning with a "NO" _and_ a "YES" button to answer the question "do you
really want to commit without an issue number?".
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 17:53:44 2004