[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] check name svn special properties

From: David Weintraub <qazwart_at_gmail.com>
Date: 2005-08-02 19:52:07 CEST

David Weintraub wrote:
> > Just curious...
> >
> > I just started reading this whole discussion. Couldn't all of this
> > checking be added to a pre-commit hook? I already have a hook that
> > verifies that particular properties are added and are in the correct
> > format. It would be very simple enhance the hook to forbid svn:*
> > properties that aren't valid.

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.

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?

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"?

The best solution will probably be the pre-commit hook custom written
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

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.

David Weintraub
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 2 19:53:05 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.