Re: svn:mergeinfo is acting strange
Hi Chris, Hi, we've been using SVN for a large in-house project for a number of years and the longer time goes by, the more strange the svn:mergeinfo properties behave. I don't know if the issues are completely expected, if our repository somehow has ended up in a state that is unwanted or if there's something bug somewhere. What happens: Whenever someone merges a branch onto the trunk, there are approximately 100 files/directories that get added mergeinfo despite these files (or files under them) not being affected by the commit. That the root directory of the trunk should be modified makes perfect sense to me, but if my merge only affects src/foo/bar.txt, why does it then have to set mergeinfo on e.g. test/some/untelated/thing.txt? It seems to be the same set or files/dirs that always get tagged with additional information, so I suspect that some previous merge has made these specific files add all future mergeinfos into them, while other files that didn't get this strangeness stay unaffected. E.g. I have two source files in the same directory: File1 has 367 lines of mergeinfo (367 different branch merges, that is), file File2 has 0. And both these files are equally old, so it makes no sense that they should differ that way. Is this expected or has our repository become overzealous? If the latter: can I fix this situation by manually deleting the mergeinfo from files further down in the tree? And if I do that, how badly will upcoming branch merges be affected? This isn't a major issue, but there have been cases where we've had conflicts inside the mergeinfo in these special files which has been sort of difficult to resolve for some committers. It is also quite annoying that every time we do svn update after a merge, we get 100+ lines of updates even if just one file has been modified (especially annoying in tools like subclipse). TIA, Chris We are facing exactly the same issue. I just got through dealing with this on our case using a tool written by the SVN developer Stefan Fuhrmann to get rid of redundant/unnecessary mergeinfo entries. It can be downloaded from the svn-mergeinfo-normalizer branch in the SVN repository. The tool is located under tools/client-side/svn-mergeinfo-normalizer. The branch readme provides some basic information about what the tool does and how it can be utilized. In principle it provides the following functionality (all done on a WC): - analyzing the mergeinfo and reporting whether certain nodes can be combined (and if not, what presents it from being combined) - normalize the mergeinfo (basically removing redundant mergeinfo entries on nodes) - combine-ranges to combine the recorded revisions to a shorter but semantically equal representation - clear-obsoletes to drop mergeinfos for branches which no-longer exist on HEAD Since you asked: I guess in most cases the reason for recording additional mergeinfos is because (for some other reason) you ended up with adding mergeinfos on a subnode (for instance test/some/unrelated/thing.txt. As per definition of mergeinfos once a node (like thing.txt in ur case) contains mergeinfo, it needs to contain all the relevant mergeinfo in its own node. This is due to performance reasons as far as I understand it, so that if u want to determine which revisions got merged into a node, SVN only has to check out this one mergeinfo entry, rather than going up the tree to determine which things got merged into this one. The good question here is why does it even keep record for revisions the node is not impacted by. I asked the same question in February already on this list (see: inconsistency between mergeinfo records). As far as I understand this is done atm to keep the application design simple. There are cases where the additional mergeinfo is required on nodes (for instance when adding a new file in a directory, the record needs to be kept on the directory node so the mergeinfo is correct). Effectively things could be improved (and as far as I've read here, it's on the radar for a later version), but the current behavior is as it stands right now. If u're running under Windows and want to give the svn-mergeinfo-normalizer tool a try, I could send u the executable I've compiled and am using myself here. Regards, Stefan
svn:mergeinfo is acting strange
Hi, we've been using SVN for a large in-house project for a number of years and the longer time goes by, the more strange the svn:mergeinfo properties behave. I don't know if the issues are completely expected, if our repository somehow has ended up in a state that is unwanted or if there's something bug somewhere. What happens: Whenever someone merges a branch onto the trunk, there are approximately 100 files/directories that get added mergeinfo despite these files (or files under them) not being affected by the commit. That the root directory of the trunk should be modified makes perfect sense to me, but if my merge only affects src/foo/bar.txt, why does it then have to set mergeinfo on e.g. test/some/untelated/thing.txt? It seems to be the same set or files/dirs that always get tagged with additional information, so I suspect that some previous merge has made these specific files add all future mergeinfos into them, while other files that didn't get this strangeness stay unaffected. E.g. I have two source files in the same directory: File1 has 367 lines of mergeinfo (367 different branch merges, that is), file File2 has 0. And both these files are equally old, so it makes no sense that they should differ that way. Is this expected or has our repository become overzealous? If the latter: can I fix this situation by manually deleting the mergeinfo from files further down in the tree? And if I do that, how badly will upcoming branch merges be affected? This isn't a major issue, but there have been cases where we've had conflicts inside the mergeinfo in these special files which has been sort of difficult to resolve for some committers. It is also quite annoying that every time we do svn update after a merge, we get 100+ lines of updates even if just one file has been modified (especially annoying in tools like subclipse). TIA, Chris
RE: List commits for specific user date range
Thanks guys, that worked.
Re: svn:mergeinfo is acting strange
Hi, If you're using Subversion 1.8, you may find this thread relevant: http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260 It describes specific instances in which Subversion 1.8 (and later) add mergeinfo to nodes. The mergeinfo there may be safely removed. --Pete On Thu, Jun 25, 2015 at 8:01 AM, Stefan Hett ste...@egosoft.com wrote: Hi Chris, Hi, we've been using SVN for a large in-house project for a number of years and the longer time goes by, the more strange the svn:mergeinfo properties behave. I don't know if the issues are completely expected, if our repository somehow has ended up in a state that is unwanted or if there's something bug somewhere. What happens: Whenever someone merges a branch onto the trunk, there are approximately 100 files/directories that get added mergeinfo despite these files (or files under them) not being affected by the commit. That the root directory of the trunk should be modified makes perfect sense to me, but if my merge only affects src/foo/bar.txt, why does it then have to set mergeinfo on e.g. test/some/untelated/thing.txt? It seems to be the same set or files/dirs that always get tagged with additional information, so I suspect that some previous merge has made these specific files add all future mergeinfos into them, while other files that didn't get this strangeness stay unaffected. E.g. I have two source files in the same directory: File1 has 367 lines of mergeinfo (367 different branch merges, that is), file File2 has 0. And both these files are equally old, so it makes no sense that they should differ that way. Is this expected or has our repository become overzealous? If the latter: can I fix this situation by manually deleting the mergeinfo from files further down in the tree? And if I do that, how badly will upcoming branch merges be affected? This isn't a major issue, but there have been cases where we've had conflicts inside the mergeinfo in these special files which has been sort of difficult to resolve for some committers. It is also quite annoying that every time we do svn update after a merge, we get 100+ lines of updates even if just one file has been modified (especially annoying in tools like subclipse). TIA, Chris We are facing exactly the same issue. I just got through dealing with this on our case using a tool written by the SVN developer Stefan Fuhrmann to get rid of redundant/unnecessary mergeinfo entries. It can be downloaded from the svn-mergeinfo-normalizer branch in the SVN repository. The tool is located under tools/client-side/svn-mergeinfo-normalizer. The branch readme provides some basic information about what the tool does and how it can be utilized. In principle it provides the following functionality (all done on a WC): - analyzing the mergeinfo and reporting whether certain nodes can be combined (and if not, what presents it from being combined) - normalize the mergeinfo (basically removing redundant mergeinfo entries on nodes) - combine-ranges to combine the recorded revisions to a shorter but semantically equal representation - clear-obsoletes to drop mergeinfos for branches which no-longer exist on HEAD Since you asked: I guess in most cases the reason for recording additional mergeinfos is because (for some other reason) you ended up with adding mergeinfos on a subnode (for instance test/some/unrelated/thing.txt. As per definition of mergeinfos once a node (like thing.txt in ur case) contains mergeinfo, it needs to contain all the relevant mergeinfo in its own node. This is due to performance reasons as far as I understand it, so that if u want to determine which revisions got merged into a node, SVN only has to check out this one mergeinfo entry, rather than going up the tree to determine which things got merged into this one. The good question here is why does it even keep record for revisions the node is not impacted by. I asked the same question in February already on this list (see: inconsistency between mergeinfo records). As far as I understand this is done atm to keep the application design simple. There are cases where the additional mergeinfo is required on nodes (for instance when adding a new file in a directory, the record needs to be kept on the directory node so the mergeinfo is correct). Effectively things could be improved (and as far as I've read here, it's on the radar for a later version), but the current behavior is as it stands right now. If u're running under Windows and want to give the svn-mergeinfo-normalizer tool a try, I could send u the executable I've compiled and am using myself here. Regards, Stefan
Re: Subversion 1.8.13 on Cygwin: E170000 or E180001: Unable to connect to a repository at URL , Unable to open an ra_local session to URL
The cygwin version of Subversion is a unix compilation of subversion running on Windows, via the cygwin libraries. As such it doesn't understand special Windoes paths. If you would use a normal windows client (compiled for windows; not cygwin) it would understand that it should transform file://myserver/share/path to \\myserver\share\path. If you would like to use the cygwin version, you should probably map the network share and then relocate your working copy. Bert Sent from Surface From: MORGAN Marc Sent: Thursday, June 25, 2015 3:47 PM To: users@subversion.apache.org Cc: MORGAN Marc Hi, I’ve been using subversion on my Windows 7 PC with Cygwin with a repository on a Linux server accessed via file://. I installed a brand new Cygwin version yesterday. My local workspace lost its connection to the repository. I can no longer access via svn the repository which I was previously using on the same PC. % svn status -u svn: E17: Unable to connect to a repository at URL 'file://server/path/repository/trunk' svn: E17: Unable to open an ra_local session to URL svn: E17: Local URL 'file://server/path/repository/trunk'contains unsupported hostname % svn ls file:server/path/repository svn: E180001: Unable to connect to a repository at URL 'file:///server/path/repository' svn: E180001: Unable to open an ra_local session to URL svn: E180001: Unable to open repository 'file:///server/path/repository' % ls //server/path/repository conf dav db format hooks locks README.txt The new svn version is 1.8.13 (r1667537) on i686-pc-cygwin. The previous svn version I was using is 1.6.17. With file:// I get the E17 error. With file:/// or file: I get the E180001 error. The repository directory is technically on another computer but is seen as local on my PC (I guess it’s NFS or SAMBA) when accessed with the // prefix from the shell. I tried touch-ing a new file in the repository’s directory and that worked, with correct owner, group and file permissions when checked from the Linux server. If I copy the repository folder to my local /tmp, I can access it correctly via svn. But that’s obviously not my goal. If I access the repository via the URL svn+ssh://somelinuxcomputer/nfspath/repository, that works. But my experience with the SSH tunnel is that it tends to slow down access. Has anyone experienced this problem before? Any suggestions? Thanks in advance
Subversion 1.8.13 on Cygwin: E170000 or E180001: Unable to connect to a repository at URL , Unable to open an ra_local session to URL
Hi, I've been using subversion on my Windows 7 PC with Cygwin with a repository on a Linux server accessed via file://. I installed a brand new Cygwin version yesterday. My local workspace lost its connection to the repository. I can no longer access via svn the repository which I was previously using on the same PC. % svn status -u svn: E17: Unable to connect to a repository at URL 'file://server/path/repository/trunk' svn: E17: Unable to open an ra_local session to URL svn: E17: Local URL 'file://server/path/repository/trunk'contains unsupported hostname % svn ls file:server/path/repository svn: E180001: Unable to connect to a repository at URL 'file:///server/path/repository' svn: E180001: Unable to open an ra_local session to URL svn: E180001: Unable to open repository 'file:///server/path/repository' % ls //server/path/repository conf dav db format hooks locks README.txt The new svn version is 1.8.13 (r1667537) on i686-pc-cygwin. The previous svn version I was using is 1.6.17. With file:// I get the E17 error. With file:///file:///\\ or file:file:///\\ I get the E180001 error. The repository directory is technically on another computer but is seen as local on my PC (I guess it's NFS or SAMBA) when accessed with the // prefix from the shell. I tried touch-ing a new file in the repository's directory and that worked, with correct owner, group and file permissions when checked from the Linux server. If I copy the repository folder to my local /tmp, I can access it correctly via svn. But that's obviously not my goal. If I access the repository via the URL svn+ssh://somelinuxcomputer/nfspath/repository, that works. But my experience with the SSH tunnel is that it tends to slow down access. Has anyone experienced this problem before? Any suggestions? Thanks in advance
Re: Facing issue in SVN pre commit hook | svnlook cat
Below is the code snippet I am using. I need the file contents in a variable. *fileContents=`$SVNLOOK cat $REPOS $FNAME -t $TXN`* *echo contents: $fileContents 12* Am I doing anything wrong? -Dhiraj On Thu, Jun 25, 2015 at 1:37 PM, Branko Čibej br...@wandisco.com wrote: On 25.06.2015 09:31, Dhiraj Prajapati wrote: Hi, I have a pre-commit hook which validates the contents of the files being committed before commit. I am using *svnlook cat* command to read the contents of the file being committed. However, whenever there is a leading slash on a particular line in the file, the *svnlook cat* command fails to display the slash. Instead it prints the names of all the files/folders in the root directory. *Example file contents:* xyz input name=abc/ /* abc *Command:* svnlook cat repository_path file_name -t txn *Output:* xyz input name=abc/ /app /bin /boot /cdrom /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /sources /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old abc I want* svnlook cat* to print exactly what is in the file. Please assist. This is impossible in the sense that 'svnlook cat' does not process the contents in any way, it just prints them to stdout. You're probably piping the output of 'svnlook cat' into some kind of program or script that validates them, and I suspect that script is interpreting the contents so that it lists the directory contents as you described. You should most likely look for the bug in your validation script. -- Brane
Re: Facing issue in SVN pre commit hook | svnlook cat
On 25.06.2015 10:10, Dhiraj Prajapati wrote: Below is the code snippet I am using. I need the file contents in a variable. *fileContents=`$SVNLOOK cat $REPOS $FNAME -t $TXN` * *echo contents: $fileContents 12* Am I doing anything wrong? Yes of course you are. You really should read a manual about shell argument processing. What's happening here is that shell sees the 'echo' command with the value of the fileContents variable as its argument list, and one of the arguments is '/*', and because '*' is not quoted it expands it as a wildcard. At the very least, you should be quoting the variable value, like this: echo contents: $fileContents 12 but even that is not completely safe. On Thu, Jun 25, 2015 at 1:37 PM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote: On 25.06.2015 09:31, Dhiraj Prajapati wrote: Hi, I have a pre-commit hook which validates the contents of the files being committed before commit. I am using /svnlook cat/ command to read the contents of the file being committed. However, whenever there is a leading slash on a particular line in the file, the /svnlook cat/ command fails to display the slash. Instead it prints the names of all the files/folders in the root directory. *Example file contents:* xyz input name=abc/ /* abc *Command:* svnlook cat repository_path file_name -t txn *Output:* xyz input name=abc/ /app /bin /boot /cdrom /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /sources /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old abc I want/svnlook cat/ to print exactly what is in the file. Please assist. This is impossible in the sense that 'svnlook cat' does not process the contents in any way, it just prints them to stdout. You're probably piping the output of 'svnlook cat' into some kind of program or script that validates them, and I suspect that script is interpreting the contents so that it lists the directory contents as you described. You should most likely look for the bug in your validation script. -- Brane
RE: Facing issue in SVN pre commit hook | svnlook cat
If the variable $TXN contains a *, it is getting expanded by the echo command, unix is expanding that before the echo is called. I would put single around the variable on your echo command From: Dhiraj Prajapati [mailto:dhiraj.prajap...@games24x7.com] Sent: Thursday, June 25, 2015 1:10 AM To: Branko Čibej Cc: users@subversion.apache.org Subject: Re: Facing issue in SVN pre commit hook | svnlook cat Below is the code snippet I am using. I need the file contents in a variable. fileContents=`$SVNLOOK cat $REPOS $FNAME -t $TXN` echo contents: $fileContents 12 Am I doing anything wrong? -Dhiraj On Thu, Jun 25, 2015 at 1:37 PM, Branko Čibej br...@wandisco.commailto:br...@wandisco.com wrote: On 25.06.2015 09:31, Dhiraj Prajapati wrote: Hi, I have a pre-commit hook which validates the contents of the files being committed before commit. I am using svnlook cat command to read the contents of the file being committed. However, whenever there is a leading slash on a particular line in the file, the svnlook cat command fails to display the slash. Instead it prints the names of all the files/folders in the root directory. Example file contents: xyz input name=abc/ /* abc Command: svnlook cat repository_path file_name -t txn Output: xyz input name=abc/ /app /bin /boot /cdrom /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /sources /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old abc I want svnlook cat to print exactly what is in the file. Please assist. This is impossible in the sense that 'svnlook cat' does not process the contents in any way, it just prints them to stdout. You're probably piping the output of 'svnlook cat' into some kind of program or script that validates them, and I suspect that script is interpreting the contents so that it lists the directory contents as you described. You should most likely look for the bug in your validation script. -- Brane
Re: Facing issue in SVN pre commit hook | svnlook cat
On 25.06.2015 10:15, Scott Aron Bloom wrote: If the variable $TXN contains a *, it is getting expanded by the echo command, unix is expanding that before the echo is called. I would put single around the variable on your echo command A single quote would make the command print: contents: $fileContents which is not what he wants ... *From:* Dhiraj Prajapati [mailto:dhiraj.prajap...@games24x7.com] *Sent:* Thursday, June 25, 2015 1:10 AM *To:* Branko Čibej *Cc:* users@subversion.apache.org *Subject:* Re: Facing issue in SVN pre commit hook | svnlook cat Below is the code snippet I am using. I need the file contents in a variable. *fileContents=`$SVNLOOK cat $REPOS $FNAME -t $TXN`* *echo contents: $fileContents 12* Am I doing anything wrong? -Dhiraj On Thu, Jun 25, 2015 at 1:37 PM, Branko Čibej br...@wandisco.com mailto:br...@wandisco.com wrote: On 25.06.2015 09:31, Dhiraj Prajapati wrote: Hi, I have a pre-commit hook which validates the contents of the files being committed before commit. I am using /svnlook cat/ command to read the contents of the file being committed. However, whenever there is a leading slash on a particular line in the file, the /svnlook cat/ command fails to display the slash. Instead it prints the names of all the files/folders in the root directory. *Example file contents:* xyz input name=abc/ /* abc *Command:* svnlook cat repository_path file_name -t txn *Output:* xyz input name=abc/ /app /bin /boot /cdrom /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /sources /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old abc I want/svnlook cat/ to print exactly what is in the file. Please assist. This is impossible in the sense that 'svnlook cat' does not process the contents in any way, it just prints them to stdout. You're probably piping the output of 'svnlook cat' into some kind of program or script that validates them, and I suspect that script is interpreting the contents so that it lists the directory contents as you described. You should most likely look for the bug in your validation script. -- Brane
Re: Facing issue in SVN pre commit hook | svnlook cat
Thanks a lot. I am a newbie to shell script. I appreciate your help. On 25 Jun 2015 13:45, Branko Čibej br...@wandisco.com wrote: On 25.06.2015 10:10, Dhiraj Prajapati wrote: Below is the code snippet I am using. I need the file contents in a variable. *fileContents=`$SVNLOOK cat $REPOS $FNAME -t $TXN` * *echo contents: $fileContents 12* Am I doing anything wrong? Yes of course you are. You really should read a manual about shell argument processing. What's happening here is that shell sees the 'echo' command with the value of the fileContents variable as its argument list, and one of the arguments is '/*', and because '*' is not quoted it expands it as a wildcard. At the very least, you should be quoting the variable value, like this: echo contents: $fileContents 12 but even that is not completely safe. On Thu, Jun 25, 2015 at 1:37 PM, Branko Čibej br...@wandisco.com wrote: On 25.06.2015 09:31, Dhiraj Prajapati wrote: Hi, I have a pre-commit hook which validates the contents of the files being committed before commit. I am using *svnlook cat* command to read the contents of the file being committed. However, whenever there is a leading slash on a particular line in the file, the *svnlook cat* command fails to display the slash. Instead it prints the names of all the files/folders in the root directory. *Example file contents:* xyz input name=abc/ /* abc *Command:* svnlook cat repository_path file_name -t txn *Output:* xyz input name=abc/ /app /bin /boot /cdrom /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /sources /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old abc I want* svnlook cat* to print exactly what is in the file. Please assist. This is impossible in the sense that 'svnlook cat' does not process the contents in any way, it just prints them to stdout. You're probably piping the output of 'svnlook cat' into some kind of program or script that validates them, and I suspect that script is interpreting the contents so that it lists the directory contents as you described. You should most likely look for the bug in your validation script. -- Brane
Facing issue in SVN pre commit hook | svnlook cat
Hi, I have a pre-commit hook which validates the contents of the files being committed before commit. I am using *svnlook cat* command to read the contents of the file being committed. However, whenever there is a leading slash on a particular line in the file, the *svnlook cat* command fails to display the slash. Instead it prints the names of all the files/folders in the root directory. *Example file contents:* xyz input name=abc/ /* abc *Command:* svnlook cat repository_path file_name -t txn *Output:* xyz input name=abc/ /app /bin /boot /cdrom /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /sources /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old abc I want* svnlook cat* to print exactly what is in the file. Please assist. Thanks in advance, Dhiraj
Re: Facing issue in SVN pre commit hook | svnlook cat
On 25.06.2015 09:31, Dhiraj Prajapati wrote: Hi, I have a pre-commit hook which validates the contents of the files being committed before commit. I am using /svnlook cat/ command to read the contents of the file being committed. However, whenever there is a leading slash on a particular line in the file, the /svnlook cat/ command fails to display the slash. Instead it prints the names of all the files/folders in the root directory. *Example file contents:* xyz input name=abc/ /* abc *Command:* svnlook cat repository_path file_name -t txn *Output:* xyz input name=abc/ /app /bin /boot /cdrom /dev /etc /home /lib /lost+found /media /mnt /opt /proc /root /run /sbin /sources /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old abc I want/svnlook cat/ to print exactly what is in the file. Please assist. This is impossible in the sense that 'svnlook cat' does not process the contents in any way, it just prints them to stdout. You're probably piping the output of 'svnlook cat' into some kind of program or script that validates them, and I suspect that script is interpreting the contents so that it lists the directory contents as you described. You should most likely look for the bug in your validation script. -- Brane
