You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Hammant <pa...@hammant.org> on 2019/12/02 09:56:18 UTC

Re: Re: GIT/Perforce like .svnignore

This is a fantastic feature. At least, it is very popular in Git and
Mercurial.

In lieu of the Svn dev team agreeing, there's at least two implementations
on GitHub - https://github.com/search?q=subversion+ignore

On Fri, Nov 29, 2019 at 11:12 AM Krzysztof Siewiorek <kr...@tlen.pl>
wrote:

> 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\**\XboxOne\*.lib
> Engine\Engine\Plugins\**\PS4\*.a
> Game\Plugins\**\XBoxOne\*.lib
> Game\Plugins\**\PS4\*.a
> Engine\Engine\Source\Programs\**\obj\*
>
> 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 <ha...@gmail.com>
> napisał(a):
>
> On Thu, Nov 28, 2019 at 2:20 AM Krzysztof Siewiorek < <kr...@tlen.pl>
> krzycho_s@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
>
>
>

Re: GIT/Perforce like .svnignore

Posted by Paul Hammant <pa...@hammant.org>.
Of course.

Re: GIT/Perforce like .svnignore

Posted by Branko Čibej <br...@apache.org>.
On 02.12.2019 12:12, Paul Hammant wrote:
> All of which can be played out in the issues and the PRs of the most
> viable GitHub repo for this idea.

At some point you're going to have to come back and discuss any design
on this list.

-- Brane

Re: GIT/Perforce like .svnignore

Posted by Paul Hammant <pa...@hammant.org>.
All of which can be played out in the issues and the PRs of the most viable
GitHub repo for this idea.

Re: GIT/Perforce like .svnignore

Posted by Branko Čibej <br...@apache.org>.
On 02.12.2019 11:48, Paul Hammant wrote:
> > ... "pointing at GitHub not going to solve anything" ...
>
> I was pointing at a GitHub repo in order for the OP to use that, and
> perhaps contribute to it there. It can easily be perfected there in
> (say) Python, and in a couple of years time re-implemened in C in for
> Svn on Apache's canonical Svn 'upstream'.
>
> I get that the implementation cost is (say) 4x higher in C with tests,
> and think prototyping things in higher level languages is a great idea.
>
> So I'd say it is solving the OPs problem imperfectly.


I think the main problem with (one of) those examples is that they
populate the svn:ignore property from the contents of some file. When
you change the file ... what happens? Do existing patterns that don't
match the new template get deleted? What if they were added to the
svn:ignore property manually?

And so on. So, sure, prototyping is a good idea, but when it comes to
considering the semantics you want to have in Subversion, some extra
thought is required.

-- Brane

Re: GIT/Perforce like .svnignore

Posted by Paul Hammant <pa...@hammant.org>.
> ... "pointing at GitHub not going to solve anything" ...

I was pointing at a GitHub repo in order for the OP to use that, and
perhaps contribute to it there. It can easily be perfected there in (say)
Python, and in a couple of years time re-implemened in C in for Svn on
Apache's canonical Svn 'upstream'.

I get that the implementation cost is (say) 4x higher in C with tests, and
think prototyping things in higher level languages is a great idea.

So I'd say it is solving the OPs problem imperfectly.

Re: GIT/Perforce like .svnignore

Posted by Branko Čibej <br...@apache.org>.
On 02.12.2019 10:56, Paul Hammant wrote:
> This is a fantastic feature. At least, it is very popular in Git and
> Mercurial.
>
> In lieu of the Svn dev team agreeing, there's at least two
> implementations on GitHub - https://github.com/search?q=subversion+ignore


Clearly there's interest for having such functionality, but pointing at
GitHub is not going to solve anything in Subversion itself. Until
someone volunteers to implement something like this in Subversion,
either as a backwards-compatible extension of existing svn:ignore (and
svn:global-ignores) patterns or as a new feature with a new controlling
property, it's unlikely to just happen by itself.

This community is very (very!) open to new contributions, as long as
certain minimal quality standards are met. If you want this feature,
please by all means help design and implement it.

-- Brane