David Weintraub wrote:
>
> On 8/2/05, Julian Foad <julianfoad@btopenworld.com> wrote:
>
>>Of course a pre-commit hook could check this, but that would only take effect
>>when I try to commit.
>
> So, the idea is to catch the problem *before* it happens -- an
> admirable goal. However, one of the things I like best about
> Subversion is that I don't have to worry about the client side setup.
> The user can use whatever Subversion client they want on whatever
> system they want. I'm worried that depending upon client side
> implementation might cause some unpleasant repercussions.
We haven't decided whether this will be implemented in the client library (for
all clients) or just for the command-line client. I can't remember which way
the initially submitted patch did it. Either way, it won't allow or prevent
anything from being done, it will just offer a bit of casual help to casual users.
Nothing would be depending upon client side implementation, so there is nothing
to worry about.
Please read the rest of this email thread to get a better understanding of the
proposal and its implications if you haven't done so.
> For example, we put this into the given Subversion command line
> client, but what about the various other clients available? What if a
> new "svn:*" property is added? Do I now have to worry about the
> version of the Subversion client my developers are using? What if they
> decide to use the Java client or TortoiseSVN?
My previous paragraph and the rest of this email thread answer that.
> And, there is always a problem of creating a fool proof way of doing
> something: You simply cause people to become bigger fools. For
> example, my favorite trick is not creating invalid svn:* properties.
> It's typing "snv" instead of "svn". If I could just get paid for this,
> I'd be a rich man. Will your solution catch it when I accidently type
> "snv:eol-style" as well as "svn:eolstyle"?
This is not an attempt to make anything foolproof. It will not detect "snv:*".
> The best solution will probably be the pre-commit hook custom written
The best solution depends on what problem is to be solved.
> for the site. The CM will quickly see what are the various problems
> specific to his project, and write a hook to catch them. In turn, the
> hook will block bad commits thus moving the problem from the CM to the
> user.
Good. And in addition to the administrator's good work with hook scripts, this
patch will catch some of the users' errors before they get as far as attempting
a commit. It will not interfere with the administrator's work.
> It would then be up to the user to come up with their own solution to
> this issue. The user might switch to a client like TortoiseSVN which
> uses a dropdown list for svn:* properties, or maybe the user will
> write their own wrapper around the svn propset command.
This patch won't prevent users from doing either of those things if they want
to, but it may avoid the need to do so.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 2 20:36:07 2005