Re: examining repository for files that only I have changed
Woodworth, James wrote: Hello, Over the past three weeks I have changed and committed some files. I need to somehow recurse through the directories and show me only the files I have changed. How do I do this? I suppose I could write a script to do this, but I suspect Subversion is sophisticated enough, and I am just missing something. Thank you, Jim Shouldn't this be enough? svn log http://repos | grep username
Re: Checkout really slow in Windows with lots of files in one directory
Neil Bird wrote: I couldn't use the version from trunk/1.7 as it differs too much. I will try to submit the patch for someone's perusal at some point, but I couldn't properly test is as for some reason my build of svn out of 1.6.x svn (even before modifying it) fails 'make check': all the tests pass, but I get a load of XFAIL lines I don't understand. AFAICT, the XFAILs I get after my patch are the same as before, but it's not the warm PASS feeling I was hoping for. XFAIL stands for "eXpected to FAIL", meaning that if SVN is doing good, then the test should fail. For instance, you expect svn not to delete an existing file on checkout, so you write your test expecting it to fail the checkout. If it succeeds, the test has not failed as expected.
Re: Checkout really slow in Windows with lots of files in one directory
Stefan Sperling wrote: On Wed, Feb 02, 2011 at 04:12:07PM +0100, OBones wrote: Neil Bird wrote: I couldn't use the version from trunk/1.7 as it differs too much. I will try to submit the patch for someone's perusal at some point, but I couldn't properly test is as for some reason my build of svn out of 1.6.x svn (even before modifying it) fails 'make check': all the tests pass, but I get a load of XFAIL lines I don't understand. AFAICT, the XFAILs I get after my patch are the same as before, but it's not the warm PASS feeling I was hoping for. XFAIL stands for "eXpected to FAIL", meaning that if SVN is doing good, then the test should fail. For instance, you expect svn not to delete an existing file on checkout, so you write your test expecting it to fail the checkout. If it succeeds, the test has not failed as expected. That's not quite right. Behaviour like that would be verified via a PASS test. The test would FAIL if svn overwrote the file. XFails are used to flag known bugs or undesirable behaviour which cannot be fixed at present (e.g. there are a couple of XFAIL tests for tree conflict handling -- we'd like to do better, but can't at the moment). Once the bug is fixed, the test will XPASS (unexpected PASS), and we switch it to PASS then. Ah that makes even more sense this way, thanks for the clarification
Re: commit not validated
Bastien Semene wrote: Hi list, Should I understand that there's no "standard" solution to this problem, or nobody can answer this issue ? Or did I do something wrong in the previous mail ? I think this can't be resolved with obvious basic configuration. That's what branches are for. Work in branch where you can break anything you want then when it's ready, merge it to the trunk.
Re: 1.7.0-alpha1 feedback
Uwe Schuster wrote: Stefan Sperling wrote: On Tue, Jun 21, 2011 at 02:02:08AM +0200, Uwe Schuster wrote: Stefan Sperling wrote: 1. Performance Can you set http-library=neon in the '[global]' section of your 'servers' configuration file and see if that helps? The checkout finishes within 2minutes for me (with neon, on OpenBSD, 16mbit/s downstream). Yes this helps very much! 39 seconds and 6,82 MB instead of 30 min 27 s and 55,70 MB Right. So this is an issue with serf. None of the existing serf issues seem to match, though. Is there anything special about your setup, such as connecting through a proxy? No, there is no proxy involved and there shouldn't be anything special with my setup. On the PC a personal firewall (Comodo) is running and the PC is connected over a Gigabit switch to a T-Com router with DSL modem (SP 700). I did run the tests with TSVN 1.6 an 1.7 on the same machine (they are installed in parallel). Well, you don't have a proxy installed, but connecting to a SourceForge hosted server is guaranteed to go through a proxy because they use it as a means of load balancing. It's transparent to the end user, but maybe not to the libraries
Re: commit issue
Andy Levy wrote: My own pre-commit hook has the same flaw. I just haven't gotten around to fixing it because I have few enough users that it's easier to just tell them "don't do that" - and I haven't been given the time to redo my hooks in a better language. If that helps, you can strip "forbidden" characters like that: set LOGMSG=%LOGMSG:>=_% set LOGMSG=%LOGMSG:'=_% set LOGMSG=%LOGMSG:"=_% but the LOGMSG variable must not be empty for it to work. So if you extract the log message from the transaction, be sure to always put at least one character into LOGMSG and adjust your length checks accordingly. A full example is here: http://svnwintools.tigris.org/source/browse/*checkout*/svnwintools/trunk/sources/SVNHookScripts/check-empty-log.bat?revision=HEAD&content-type=text%2Fplain
Call svn cat for all files modified or added in a given revision
Hello all, Using svn cat I can see the state of a file at a given revision. As it turns out, I have had in the past some files that were commit with inconsistent line endings and that are making analysis tools stop because of this. What I want to do is find which (file, revision) pairs are impacted so that I can go back in the past and fix those invalid commits (using dump/reload). However, I'm having a hard time finding a way to extract a list of modified or added files in a given revision so that I could give that list to the svn cat command that stops with an error when the above situation arises. And then, once this works, I'd put all this in a loop going from the first revision to the last one. I don't mind if this takes time, and I have no preference as to what operating system this should run under between Linux and Windows I believe using Linux would be much simpler, but still, I can't figure out how to parse the result of svn log -v so that I can extract the filenames to give to svn cat. If need be, I can work out of a working copy. I would very much appreciate any help on this matter Regards Olivier
Re: Call svn cat for all files modified or added in a given revision
Andy Levy wrote: On Tue, Mar 20, 2012 at 10:39, OBones wrote: Hello all, Using svn cat I can see the state of a file at a given revision. As it turns out, I have had in the past some files that were commit with inconsistent line endings and that are making analysis tools stop because of this. Can you change analysis tools to one that can handle this condition? Alas no, it's what ohloh.net is using... What I want to do is find which (file, revision) pairs are impacted so that I can go back in the past and fix those invalid commits (using dump/reload). However, I'm having a hard time finding a way to extract a list of modified or added files in a given revision so that I could give that list to the svn cat command that stops with an error when the above situation arises. And then, once this works, I'd put all this in a loop going from the first revision to the last one. svn log --verbose -rX will give you a list of all paths touched in revision X. You'll need to do some parsing to extract just the paths vs. the other log data. If you're handy with XML, you can use svn log --verbose --xml -rX and then use XPath to extract just the paths. To parse the output of svn log --verbose for this project, look for any line starting with one or more letters and/or spaces, followed by a space, followed by a slash. From that space to the end of the line is the path that was touched. The regex should be something close to this: \b[\w\s]+(\/*)\b Thanks for the hints, I'll try to manage something out.
Re: Call svn cat for all files modified or added in a given revision
Andy Levy wrote: On Wed, Mar 21, 2012 at 08:02, OBones wrote: Andy Levy wrote: On Tue, Mar 20, 2012 at 10:39, OBoneswrote: Hello all, Using svn cat I can see the state of a file at a given revision. As it turns out, I have had in the past some files that were commit with inconsistent line endings and that are making analysis tools stop because of this. Can you change analysis tools to one that can handle this condition? Alas no, it's what ohloh.net is using... I'd suggest filing a bug report there then. Depending on the analysis being done, whitespace might be something that can be ignored or relaxed to stop this from breaking. Actually, I went there directly before asking on this list and the answers I was given were that they could not change their process because their using "svn cat" and it's "svn cat" that is giving the error. I'll try to insist on this, but I'm not really confident as to a positive issue...
Re: Call svn cat for all files modified or added in a given revision
Andy Levy wrote: svn log --verbose -rX will give you a list of all paths touched in revision X. You'll need to do some parsing to extract just the paths vs. the other log data. If you're handy with XML, you can use svn log --verbose --xml -rX and then use XPath to extract just the paths. I have taken this route and came up with the script below. It might not be the best script ever, but it worked just fine for me, allowing to discover that there was only one revision in the entire history that was causing issue with svn cat. Regards Olivier --- #!/bin/bash # for this to work, you have to use xpathtool from the following page: # http://www.semicomplete.com/projects/xpathtool/ # set those variables to match your installation BASEURL=https://jvcl.svn.sourceforge.net/svnroot/jvcl USER= PASS= MINREV=13281 XPATHTOOLDIR=~/xpathtool-20071102/xpathtool echo Retrieving maximum revision MAXREV=`svn log -r HEAD --xml --username=$USER --password=$PASS --no-auth-cache $BASEURL | $XPATHTOOLDIR/xpathtool.sh "/log/logentry/@revision"` REV=$MINREV while [ $REV -le $MAXREV ]; do echo Processing revision $REV out of $MAXREV FILES=`svn log --verbose -r $REV --xml --username=$USER --password=$PASS --no-auth-cache $BASEURL | $XPATHTOOLDIR/xpathtool.sh "/log/logentry/paths/path[@kind='file'][@action!='D']"` IFS=$'\n' for FILE in $FILES do svn cat --username=$USER --password=$PASS --no-auth-cache $BASEURL$FILE@$REV > /dev/null if [ $? -ne 0 ]; then echo File $FILE at revision $REV gave an error fi done let REV=REV+1 done
Re: Windows Properties on SVN
Maria de Los Reyes Fernandez Dominguez wrote: Is there anyway that SVN recognizes property changes on ".flv" and ".txt" files? Hello, these properties are stored in what is called an alternate stream, a feature that is bound to the NTFS filesystem. There is no way for SVN to reproduce this data on all the architectures it supports and as such does not support that. The fact that you have properties working for the JPG files is that because they are embedded in the file, as EXIF data for instance.
Re: Feature request: Save the old file when svn revert
Grierson, David wrote: I completely understand that the action of sending to the Recycle Bin (in TortoiseSVN) is very system specific. To simply rename the item being reverted as $item.$backupSuffix before then restoring the pristine item is presumably not that system specific? Having this functionality in the base tool would then provide a benefit to all users and not just those using a specific IDE. I would very much prefer if this could be an option that is not enabled by default. I mean, this would clutter the filesystem with many files that one would have to delete manually, especially when considering that some of us are using less than optimal filesystems when it comes down to lots of small files.
Re: Moving SVN from one server to another
Nico Kadel-Garcia wrote: In general, to jump that many major revisions, I tend to use "svnsync" to allow the repositories to stay synchronized while the client stays talking to the first repository, then take the first repository entirely offline. Note that this is probably the first opportunity, in years, to obliterate content from the old repositories "and reset the ID of the new repository, to avoid clients getting confused about obliterated content. Setting up the svnsync is explained in the manual, but how do you "turn it off" of afterwards?
Re: Moving SVN from one server to another
Ryan Schmidt wrote: On Apr 25, 2018, at 07:15, OBones wrote: Nico Kadel-Garcia wrote: In general, to jump that many major revisions, I tend to use "svnsync" to allow the repositories to stay synchronized while the client stays talking to the first repository, then take the first repository entirely offline. Note that this is probably the first opportunity, in years, to obliterate content from the old repositories "and reset the ID of the new repository, to avoid clients getting confused about obliterated content. Setting up the svnsync is explained in the manual, but how do you "turn it off" of afterwards? svnsync synchronizes every time you run it. If you don't want to synchronize anymore, simply don't run it again. Well, maybe I read this wrong, but the manual talks about a master and a slave, which are tightly related. If I remove the master once the slave is fully ready to take over its role, I'm not sure it will work smoothly, hence my question.
Setting sticky depth without grabbing content immediately
Hello, When using the update command with subversion 1.8, one can set the sticky depth with the --set-depth option. When changing from emtpy to infinity, all the files that were not retrieved yet are retrieved immediately. While this is fine in most cases, I am in a situation where I'd like to prepare the working copy setting the depths but would like to have the files retrieved later on when doing an option-less update. To sum up, based on svnbook sparse dirs example, here is what I'd like to be able to do: $ svn checkout file:///var/svn/repos mom-empty --depth empty Checked out revision 1. $ svn update --set-depth infinity --record-only mom-empty/daughter Updating 'mom-empty/daughter': depth recorded $ svn update mom-empty Updating 'mom-empty': Amom-empty/daughter Amom-empty/daughter/granddaughter1 Amom-empty/daughter/granddaughter1/bunny1.txt Amom-empty/daughter/granddaughter1/bunny2.txt Amom-empty/daughter/granddaughter2 Amom-empty/daughter/fishie.txt Is this something that can be done? If yes, how can I achieve this? Thanks for your help
Re: Setting sticky depth without grabbing content immediately
Stefan Sperling wrote: On Mon, Nov 04, 2013 at 11:16:12AM +0100, OBones wrote: Hello, When using the update command with subversion 1.8, one can set the sticky depth with the --set-depth option. When changing from emtpy to infinity, all the files that were not retrieved yet are retrieved immediately. While this is fine in most cases, I am in a situation where I'd like to prepare the working copy setting the depths but would like to have the files retrieved later on when doing an option-less update. To sum up, based on svnbook sparse dirs example, here is what I'd like to be able to do: $ svn checkout file:///var/svn/repos mom-empty --depth empty Checked out revision 1. $ svn update --set-depth infinity --record-only mom-empty/daughter Updating 'mom-empty/daughter': depth recorded $ svn update mom-empty Updating 'mom-empty': Amom-empty/daughter Amom-empty/daughter/granddaughter1 Amom-empty/daughter/granddaughter1/bunny1.txt Amom-empty/daughter/granddaughter1/bunny2.txt Amom-empty/daughter/granddaughter2 Amom-empty/daughter/fishie.txt Is this something that can be done? If yes, how can I achieve this? Thanks for your help Perhaps this can help you: https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py Thanks for this, but it won't help much in this case. Basically, I'd like to prepare a working copy for a system that will do the final svn update and over which I have no control. As a result, I'd like to avoid, if possible, that this final update does nothing. It seems it's not possible easily however, so I guess I'll have to live with that useless update...
Re: Setting sticky depth without grabbing content immediately
Johan Corveleyn wrote: I think this would be a useful feature. Whether or not someone will have time to work on it, or someone steps up to write a patch for it, is another matter. But I'd suggest that you enter this into the issue tracker in any case. Can you please file an issue for this? Done: http://subversion.tigris.org/issues/show_bug.cgi?id=4445 Regards
Externals issue
Hello all, I'm using SVN 1.8.8 and facing an issue with externals that worked perfectly fine using SVN 1.8.4 Basically, they all are defined like this: -r 7121 ../../../Path/To/Calculator Calculator When I update, this gives me the following error: D:\Path\To\WC\Some\App\Calculator Path '/svn/Repository/!svn/rvr/34031/branches/some/branch/Path/To/Calculator' not found This is correct because there was some overhaul in the repository and the path pointed at by the relative external did not (yet) exist in revision 7121. I thus decided to change the external to this: -r 7121 ^/branches/OldBranch/Path/To/Calculator Calculator Because I know that at revision 7121, the following path is completely valid. However, I still get an error, telling me this: D:\Path\To\WC\Some\App\Calculator Path '/svn/Repository/!svn/rvr/34031/branches/OldBranch/Path/To/Calculator' not found Basically, it's testing for existence in the latest revision instead of the external defined revision. Have I done something wrong in my setup? Any pointers are most welcome. Regards.
Ran svn revert but files are still modified
Hello, I have a working copy here where a file is in status "modified" which won't go away. This file is a binary database dump (.bak) and I don't understand why this happens on that file while there are other files with that extension in the same folder that do not behave the same. I tried running "svn revert" and "svn cleanup" but this did not make the file go back to unmodified. When using WinMerge to see the diffs, it tells me the file is identical to its base. I must be missing something obvious but I can't think of anything short of doing a fresh checkout of the working copy. Any suggestion is welcome. Regards, Olivier
Re: Ran svn revert but files are still modified
OBones wrote: doing a fresh checkout of the working copy. I just did that, and also happens on the very same file in that new working copy. I'm quite lost here...
Re: Ran svn revert but files are still modified
Stefan Sperling wrote: On Fri, Jul 18, 2014 at 01:51:07PM +0200, OBones wrote: Hello, I have a working copy here where a file is in status "modified" which won't go away. This file is a binary database dump (.bak) and I don't understand why this happens on that file while there are other files with that extension in the same folder that do not behave the same. I tried running "svn revert" and "svn cleanup" but this did not make the file go back to unmodified. When using WinMerge to see the diffs, it tells me the file is identical to its base. What files does WinMerge compare exactly? Perhaps it's not comparing the right set of files? When ran from TortoiseSVN, this is the command line it gets: "C:\Program Files (x86)\WinMerge\WinMergeU.exe" -e -x -ub -dl "TheFile.bak : Working Base, Revision 35975" -dr "TheFile.bak : Working Copy" "C:\Users\obones\AppData\Local\Temp\TheFile.bak-revBASE.svn002.tmp.bak" "D:\Sources\Some\Path\TheFile.bak" If I run svn diff on the command line, here is what I get: Index: TheFile.bak === Unable to display : file considered as binary. svn:mime-type = application/octet-stream I used ProcessMonitor to see who is accessing that file and besides svn.exe, nothing is accessing it...
Re: Ran svn revert but files are still modified
Andreas Stieger wrote: Hi, On 18 Jul 2014, at 13:51, OBones wrote: I have a working copy here where a file is in status "modified" which won't go away. This file is a binary database dump (.bak) and I don't understand why this happens on that file while there are other files with that extension in the same folder that do not behave the same. I tried running "svn revert" and "svn cleanup" but this did not make the file go back to unmodified. Did you run revert recursively with "-R", or did you run it on the item specifically? Without that, do not expect the file to be reverted. I ran "svn revert ." but you are correct, this does nothing to my file. But I ran "svn revert -R ." and "svn revert *" and the same behavior happens. I tells me "Item reverted" then immediately comes back as modified in svn status. I even went as far as running them in sequence like that: svn rever * & svn status I get this output: 'TheFile.bak' reset M TheFile.bak When using WinMerge to see the diffs, it tells me the file is identical to its base. Note that your third-party diff tool may be configured to ignore certain changes like line ending formats etc Check your diff tool invocation settings, and check the authoritative "svn diff" on the specific item. svn diff is unable to show the difference, it shows this: Index: TheFile.bak === Unable to display : file considered as binary. svn:mime-type = application/octet-stream As to WinMerge, it is configured to take all differences it knows about into account and still tells me that there are no differences.
Re: Ran svn revert but files are still modified
OBones wrote: I must be missing something obvious but I can't think of anything short of doing a fresh checkout of the working copy. Well, browsing through history, I found out that the svn:special property with value * was added to the file at the same time that its content changed from 20M to 79K which appear to be the exact beginning of the original file. I'm not sure how this happened but reverting those changes made the "sticky modified status" go away. Thanks for all of you that provided suggestions.
