Combining svn log 'search' and 'limit'
Hello! I want to make simple tool, for viewing svn log results and without search everything works well. Now I want to implement search, and I have some problems with search and limit combination. Without limit search works well, but with limit result is totally unpredictable. For example, if I enter "limit 30", it may return 28 records for revision "121:1" and 7 records for revision "86:1". Why it is working so strange and what you can suggest, to make correct pagination for svn log and search combination?
Exclude file types from SVN diffs?
Hi, what's the best way to filter out a certain type of file from svn diff output without having to use external tools such as filterdiff? The project I'm working with insists on storing a lot of data files in ascii format in the repo, but users don't want to see diffs for these files. I was thinking of changing the svn:mime-type on these to e.g. octet-stream, but will that affect how the database on the server handles these as well? That is, it would be nice if the server could still treat these files as text files and compress changes, but that the diffs are not shown to users. Another option would be if there's some way to add exclude-patterns to svn diff, e.g. something like "svn diff --exclude-filepatterns '*.ascii'". Is anything similar to that available? Or a similar exclude-functionality that could look for specific svn properties "--exclude-files-with-properties myasciifileproperty" so I can force a property "myasciifileproperty" on all these files BR, Chris
Re: Combining svn log 'search' and 'limit'
On 06.11.2017 10:38, Dmitrijs Reinmanis wrote: > Hello! > > I want to make simple tool, for viewing svn log results and without > search everything works well. Now I want to implement search, and I > have some problems with search and limit combination. Without limit > search works well, but with limit result is totally unpredictable. For > example, if I enter "limit 30", it may return 28 records for revision > "121:1" and 7 records for revision "86:1". > > Why it is working so strange and what you can suggest, to make correct > pagination for svn log and search combination? The --search option filters within --limit results, not the other way around. Specifically, if you set --limit to 30, you'll get 30 results; then --search will return only the results that match from within those 30. If I recall correctly, --search is completely client-side (but I may be wrong ... I haven't checked that code recently). -- Brane
Re: Exclude file types from SVN diffs?
On 06.11.2017 10:59, Chris wrote: > Hi, > > what's the best way to filter out a certain type of file from svn diff output > without having to use external tools such as filterdiff? > > The project I'm working with insists on storing a lot of data files in ascii > format in the repo, but users don't want to see diffs for these files. > I was thinking of changing the svn:mime-type on these to e.g. octet-stream, > but will that affect how the database on the server handles these as well? > That is, it would be nice if the server could still treat these files as text > files and compress changes, but that the diffs are not shown to users. The repository doesn't care if files are text or not; compression (actually, binary delta storage) happens regardless. Specifically, the server does not interpret the value of the svn:mime-type property in any way. > Another option would be if there's some way to add exclude-patterns to svn > diff, e.g. something like "svn diff --exclude-filepatterns '*.ascii'". Is > anything similar to that available? > Or a similar exclude-functionality that could look for specific svn > properties "--exclude-files-with-properties myasciifileproperty" so I can > force a property "myasciifileproperty" on all these files Nothing like that is available. If you do set the MIME type to something that's not "text/*", 'svn diff' will still show the diff headers for changed files but won't show the diff contents. There is another way you could solve this: by using the --diff-cmd option and writing a tool that ignores cretain files. Diff headers will still be printed, though. -- Brane
Re: Exclude file types from SVN diffs?
Hi Brane, thanks for the reply. I'm ok with seeing the diff header as long as I don't have to see the content. I'll just change the mime-type of these files. /Chris On Mon, 11/6/17, Branko Čibej wrote: Subject: Re: Exclude file types from SVN diffs? To: users@subversion.apache.org Date: Monday, November 6, 2017, 12:14 PM On 06.11.2017 10:59, Chris wrote: > Hi, > > what's the best way to filter out a certain type of file from svn diff output without having to use external tools such as filterdiff? > > The project I'm working with insists on storing a lot of data files in ascii format in the repo, but users don't want to see diffs for these files. > I was thinking of changing the svn:mime-type on these to e.g. octet-stream, but will that affect how the database on the server handles these as well? That is, it would be nice if the server could still treat these files as text files and compress changes, but that the diffs are not shown to users. The repository doesn't care if files are text or not; compression (actually, binary delta storage) happens regardless. Specifically, the server does not interpret the value of the svn:mime-type property in any way. > Another option would be if there's some way to add exclude-patterns to svn diff, e.g. something like "svn diff --exclude-filepatterns '*.ascii'". Is anything similar to that available? > Or a similar exclude-functionality that could look for specific svn properties "--exclude-files-with-properties myasciifileproperty" so I can force a property "myasciifileproperty" on all these files Nothing like that is available. If you do set the MIME type to something that's not "text/*", 'svn diff' will still show the diff headers for changed files but won't show the diff contents. There is another way you could solve this: by using the --diff-cmd option and writing a tool that ignores cretain files. Diff headers will still be printed, though. -- Brane
svn rename adds mergeinfo property / renaming in working copy does not
Hi all, I just stumbled across a very strange behaviour. We're using a pre-commit hook, that checks if a commit involves a merge operation. If the operation does involve a merge, we force the user to use the word "merge" in the commit message. I implented this using svnlook diff --no-diff-deleted --no-diff-added -t XX /my/path/to/repo and analysing if the string "Added: svn:mergeinfo" or "Modified: svn:mergeinfo" shows up in the diff. Recently one of my team members tried to rename a sub folder in a project where there is a mergeinfo-property on the base folder. He tried to do so using the command line client: svn rename https://example.org/repo/project_a/subfolder_a https://example.org/repo/project_a/subfolder_b In this example, the "project_a" folder carries the mergeinfo property. The commit hook complains that the operation is a merge an blocks (the user did not use the word "merge" in the message since the operation is no merge at all). Doing the same rename in a working copy works. I was not able to find any documentation on that behaviour: Obviously svn copies the mergeinfo property from the root folder to the renamed folder - but does only so if the rename is invoked as "svn rename from_url to_url". If the rename is applied to a working copy and commited afterwards, the svnlook on the server does not show adding the mergeinfo property. I cannot imagine a case where copying the mergeinfo to the new folder is a wanted behaviour, even worse, without the user being able to notice anything about such an operation. Maybe there's something wrong in our setup? Or is this the expected behaviour? The server currently uses httpd 2.2 + svn 1.8.13, the clients used for testing where svn 1.8.13 and svn 1.9.7. Any insight is appreciated! Greetings Nico
Re: svn rename adds mergeinfo property / renaming in working copy does not
On Mon, Nov 06, 2017 at 06:10:37PM +0100, Nicolai Scheer wrote: > I cannot imagine a case where copying the mergeinfo to the new folder is a > wanted behaviour The current behaviour was implemented on purpose. It has been this way since Subversion 1.5.5. See https://svn.haxx.se/dev/archive-2008-11/0432.shtml and https://svn.haxx.se/dev/archive-2008-11/0297.shtml for details.
