Mark Phippard wrote:
>>>In case he didn't use that but entered it manually right away -
>>>personally, I could live with the fact that a commit might fail on
>>>validation of the ticket id in the pre-commit hook.
>>
>>If the manually entered id doesn't match one of the "open tickets list"
>>received, then a simple warning could be shown (_not_ blocking the
>>commit!).
> OK, I guess I cannot help myself. :)
You know, I was expecting a comment from you about that ;)
> If I as the Administrator have to go out of my way to turn this feature on
> in the first place, by setting the properties in my repository, then why
> can't you just honor that? You seem to have made up your mind that bug
> ID's should never be mandatory and I do not really understand why. There
> are plenty of corporations out there that will absolutely want every
> transaction to have an ID associated. If you wanted to add another
> property with values of warn vs. error I could understand that, but why
> are you so against adding a feature that some people demonstrably want and
> need?
Ok, let's try to explain why not to enforce things:
- yes, you set those properties and they get committed to the
repository. But we're talking here about file/folder properties, not
revision properties. That means that a user can simple remove those from
his working copy and then commit without the restriction, also removing
the properties for all other users while doing the commit.
- The Subversion command line client will never implement those. That's
something for GUI clients. And not all GUI clients will have this
implemented either. So by making TSVN enforce things, you just drive
many users away from TSVN to other clients. Sure, we don't earn money
with our program, but that doesn't mean we like using users!
- As an Administrator, you might have noticed that as soon as you
enforce whatever restriction/policy, users first get angry (because they
can't do what they're used to anymore), then they start looking for
other ways to do what they're used to. And you might have noticed how
creative people can get when it comes to work around a restriction.
- enforcing to enter a 'valid' bug-ID (tell me: what's a valid ID for
you?) prevents commits which correct a spelling error, fix some
intendation, add a more clear comment to a function, ... So you'll end
up with those corrections mixed into other commits assigned to a bug-ID.
And that's very, very bad from a source control point of view.
- What prevents a user from simply choosing a 'valid' bug-ID for a
commit, even though the commit has nothing to do with the bug-ID? Yes,
exactly: nothing! So you'll end up with a messed up bugtracker.
> Yes they can use a hook, but as I said, a hook happens very late in the
> process and forces the user to start over. Also, I think it can be
> difficult for the bug tracking vendor to provide the hook, as the
> Subversion repository could be on just about any operating system. That
> means different shells and scripting languages, not to mention other
> dependencies. This gets more complicated (in terms of dependencies) if
> the script would have to be able to call out to an HTTP service and parse
> the results.
For open source bugtrackers, that's not a problem. There are many users
out there who are more than happy to provide such hooks for their
favourite bugtracker. And vendors of bugtrackers get enough money for it
so they can be expected to implement two different hook scripts (one for
Linux and one for Windows). I don't think that's too much to ask for if
you see the price of those!
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Oct 27 21:57:51 2004