Hi, Thank you all for the feedback. You are right. I was not too precise on
what is the problem, and what is used already. We are using the latest version
of Subversion (1.13.0), and the latest TortoiseSVN client (1.13.1), so we take
advantage of svn:global-ignores properties - and that feature helps a lot
already :) The problem we have, is that we handle big repositories with the
games we develop, including modified UnrealEngine dedicated for each one of the
games. There are some cases that apply using path based rules ( not only file
based ones, like *.obj *.pdb and so on ). We want them to be applied to all of
our repositories, so going down the tree, and adding the properties in certain
directories on each one of them is time consuming and hard to maintain.
I'll give you some example of our old ignore rules we had, and that are
hard to manage in svn: Engine\Engine\Plugins\**\XboxO
Engine\Engine\Plugins\**\PS4\* Game\Plugins\**\XBoxOne\*.lib
Game\Plugins\**\PS4\*.a Engine\Engine\Source\Programs\ There are similar,
but those should give the idea of what is the problem. Ideally, I would like to
set exactly those rules as a svn:global-ignores in the main directory of the
repository, so it's easy to change them any time if needed. Basically the
idea of having all the rules in one place is a key of successful and easy going
maintaince - and this is the goal for me here. If that was possible, putting
the rules in a file and updating it on hook with "svn propset
svn:global-ignores -F .svnignore ." is easy already. But that would be
actually optional and not needed. I hope that clears out all of the questions
:) Thanks! Krzysztof Siewiorek-Pieniążek Dnia 28 listopada 2019 21:24
Nathan Hartman <hartman.nat...@gmail.com> napisał(a): On Thu, Nov 28,
2019 at 2:20 AM Krzysztof Siewiorek < krzych...@tlen.pl > wrote: Hi!
We've started to move from Perforce to SVN in my company for some reasons.
We moved quite a few big projects that we have or we had been working in the
past. Working with perforce for years gave us quite a big and precise ignore
rules list. The problem is that SVN's approach to that does not quite scale
up and also makes managing ignored files a pain - especially when working on
many projects in same time. I was trying to dig for some piece of information,
why actually SVN doesn't have implemented something simillar to GIT's
or Perforce's ignore file that contains extended rules including full
directories in the rules, !mark to not apply the rules for some files/dir, and
so on. Hello, Since you mentioned .svnignore in the subject line, I'd
like to point out that Subversion doesn't require you to clutter your
version-controlled directories with such dotfiles. Subversion offers
versioned properties. These are pieces of metadata that can be associated to
files and directories, and are version-controlled alongside them. Subversion
has various built-in properties, whose names begin with "svn:". In
addition, you can create any other properties you wish for your own purposes
(e.g., to support custom tooling) so long as you don't start their names
with "svn:" as that is reserved for the built-in properties. When it
comes to ignore rules, there are two kinds of properties: svn:ignore -
ignores files matching a pattern in the same directory. svn:global-ignores -
like svn:ignore, but recursive. In my company's Subversion repository we
have quite a few of these properties set up and to date they have covered all
of our needs. Although there is currently no '!' to ignore a rule for
a particular file, be aware that once a file is added to version control,
ignore rules no longer apply to it. The ignore patterns apply only to files
that Subversion is not tracking, for the purpose of not cluttering up the
output of 'svn status'. Hopefully my message is helpful for you and
not merely a regurgitation of things you already know. :-) We're glad to
hear from you. Feel free to write anytime! Also, as Brane points out this is
a volunteer run open source project so we're always happy to meet
enthusiastic new contributors. If you'd like a cool new feature and are
willing to invest some effort, anything is possible. Let us know if you're
interested... Cheers, Nathan
