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

Re: Do not copy Bugtraq properties for new folders

From: Nicolai Scheer <nicolai.scheer_at_gmail.com>
Date: Wed, 28 Aug 2013 22:01:39 +0200


Thanks for your answer!

On 27 August 2013 15:44, Bob Archer <Bob.Archer_at_amsi.com> wrote:

> I think with the new inheritable properties TSVN would be able to modify
> its behavior to not need the property on every folder. Perhaps they will
> create a change request for this.
> However, when you add the folder, you can edit the properties before you
> commit it. Is the property causing you an issue for some reason? What is
> the use case for it not being there? I'm sure the devs would want to know
> that before making such a low level change.
> BOb
I know that one can remove the properties prior to commiting... It's just a
lot of my developers keep them sneaking in :|
The issue it was causing was a change in the regular expression used for
the ticket string. We changed our project root, and because there were some
folders with copied properties (way down deep in the tree, most folders are
prop free), the people were strangely not able to commit on those folders
(i.e. pre-commit hook denying the wrong ticket format).

Furthermore there are a few less critical properties like
min-comment-length, etc. But again, if we change these, we had to make sure
that every subfolder is changed, otherwise the commit would be rejected by
our pre-commit hook.

Yes, I can ask my developers to remove the properties prior to commiting.
But just one slipped through property copy can leave me scratching my head
and debugging why stuff is not working. And I'd rather spend that hour
developing :)

Maybe the new inheritable props from svn 1.8.x are the true remedy...




To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-08-28 22:01:44 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

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