SteveKing <steveking@gmx.ch> wrote on 10/27/2004 02:53:11 PM:
> Mark Phippard wrote:
>
> 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.
These three are irrelevant. The types of users I envision this for would
never find another client. Even if they did, I think anyone that turned
on this feature would try to also have some kind of pre-commit hook. This
is mainly about making the front-end friendlier.
> - 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.
These are your opinions spilling through. If you have to undergo SOX
audits or are trying to maintain an ITIL certification, then yes you will
want to have a bug-ID for these changes.
> - 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.
Possibly, but at least the tool has helped as much as it reasonably can.
> 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!
I am finishing a port of Subversion to OS/400, do you think anyone is
going to write scripts for that OS? Also, not all bug tracking tools are
expensive. I thing the main issue is the libraries you need for XML or
HTTP or SOAP or whatever, same as you raised for TSVN. I have to do most
of my hooks in Java. That is too expensive to invoke on the server as a
pre-script. Currently, I have only done it in post-scripts, and then I
can run it in the background so it doesn't tie up the client.
Anyway, I can live with hooks, just thought I'd toss in my opinions.
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 Wed Oct 27 22:17:51 2004