Just a general initial comment, I am not trying to drag this dicussion
down, sorry if it came across that way. I am just trying to explore all
aspects of the spec.
> 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.
That is a good point, I do not know why I was missing that before. You are
correct, I would be providing this, so the user would not have to do it.
> And isn't that your whole point? Making sure that there are no ways
> around it?
No, that wasn't my point. That is what I have been trying to say. I think
that scenario is the fringe case. My main point is that I think the
majority of people that want this feature want to have an issue ID on the
majority of their commits. Requiring an issue ID is a UI helper, not
hindrance.
> Sure, the company or the admins surely won't complain. But the devs will
> soon find the mailing list and start complaining.
I really do not see why, but I will trust you on it.
> 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 must confess that this is the part of the spec that troubles me the most.
However, I think that the current spec is probably the best we can do with
what Subversion currently gives us to work with.
> 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".
If I missed this feature in TSVN, I apologize. I certainly never doubted
it would be added. If you can edit a log message after the fact that is
awesome. How about a new feature where you add/remove an issue after the
fact, and under the covers it manipulates the log message? That would all
but eliminate the need to require the field for me.
> 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?".
I guess if all we are differing on is whether there ought to be a way for a
developer to purposefully commit something without an issue ID, then I am
100% in favor of that. Especially, if the default behavior is to assist
the user that forgot an issue ID. So maybe this is the answer? Never
absolutely require an issue ID, but have a setting that could warn the user
if they forget one, with a way for the user to commit the change anyway?
That sounds very good to me.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Aug 22 18:23:45 2004