Re: Subversion 1.6.17 Released
Around about 03/06/11 03:46, Nico Kadel-Garcia typed ... And, apparently, the long-standing issue for clients with NTFS filesystems sytems, issue #3719. I'm very much looking forward to testing against a CIFS share, which was taking easily 10 times as long as checkouts on NFS shares. The Linux command-line 1.6.17 is significantly faster¹ for a CIFS-mounted NTFS drive. I expect TSVN to be similarly improved. ¹ - for the use-case of lots of files in single dirs. that have svn props set on them, which is what this fix actually addresses. -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
Segfault when runnning svn merge --reintegrate
Howdy, Anyone have any pointers or workarounds when dealing with a segfault using the svn merge --reintegrate command? I'm running this: svn merge --reintegrate /path/to/repository and after a few minutes, I get: Segmentation Fault This happens on both version 1.6.15 (r1038135) and 1.6.16 (r1073529). This is running on Mac OS X 10.6.7. Thanks, Tom
Re: svnadmin: Path '....' is not in UTF-8 - svnadmin load fails
Am Dienstag, den 31.05.2011, 14:25 +0200 schrieb Stefan Sperling: > On Tue, May 31, 2011 at 01:07:02AM +0200, Stefan Sperling wrote: > > On Tue, May 31, 2011 at 01:41:54AM +0300, Daniel Shahaf wrote: > > > > We should also make svnadmin verify complain if paths are not in UTF-8. > > > > > > +1. > > > > > > The validation that 'load' and 'commit' trigger is path_valid() in > > > fs_loader.c. > > > > Thanks for the hint. I'm now running tests on a patch for this. > > Fixed 'svnadmin verify' in r1129641. Thanks for reporting this, Torsten! Made some task for doc purpose: http://subversion.tigris.org/issues/show_bug.cgi?id=3911 smime.p7s Description: S/MIME cryptographic signature
Re: svnadmin: Path '....' is not in UTF-8 - svnadmin load fails
Made an issue to track this: http://subversion.tigris.org/issues/show_bug.cgi?id=3912 smime.p7s Description: S/MIME cryptographic signature
Re: Subversion 1.6.17 Released
On Fri, Jun 3, 2011 at 6:44 AM, Neil Bird wrote: > Around about 03/06/11 03:46, Nico Kadel-Garcia typed ... >> >> And, apparently, the long-standing issue for clients with NTFS >> filesystems sytems, issue #3719. I'm very much looking forward to >> testing against a CIFS share, which was taking easily 10 times as long >> as checkouts on NFS shares. > > The Linux command-line 1.6.17 is significantly faster¹ for a CIFS-mounted > NTFS drive. I expect TSVN to be similarly improved. Faster than than it was for .6.16 or earlier with the Linux client? Good I want to see the results of the Windows CIFS client. I tried to get a Windows 7 box in my last such test environment to run NFS comparisions, but there were. fascinating reasons I was not among the testers for Windows 7. > > > ¹ - for the use-case of lots of files in single dirs. that have svn props > set on them, which is what this fix actually addresses
Re: svnshell-like client
On Tue, May 31, 2011 at 5:46 PM, Les Mikesell wrote: > On 5/31/2011 12:50 PM, Rick Varney wrote: > >> We are migrating from a RCS-like revision control system, RCE, to >> Subversion. >> The users are accustomed to poking around in the directories where the >> archive files are stored to see what's there in a Linux bash shell. >> While it is possible to do this using the svn client commands by >> providing the full path to objects in the repository, it is somewhat >> inconvenient. A shell user accustomed to using cd, ls, and path >> completion to inspect a file tree can't use the same methods when >> inspecting the repository. >> I noticed svnshell.py. This is similar to what I am looking for. >> However, svnshell.py is a server-side script. I am looking for a >> client-side script - we have users at multiple sites that will want to >> inspect the repository. >> The key features/commands I am looking for are: >> 1. a client-side script >> 2. cd to change the current directory >> 3. ls to list files >> 4. path completion using the TAB key >> 5. info command to invoke svn info on a repository file or dir >> 6. log command to invoke svn log on a repository file or dir >> 7. a simple find command >> Is there anything out there like this? I have not found anything in my >> web searches so far. If not, any suggestions on what to use as a good >> starting point? > > Not quite what you want, but viewvc gives a reasonable way to explore a > repository (especially remotely) with only a web browser and once you > understand the layout you can plug the path you need into your normal svn > client. Almost any web client can provide interactive command line access to a Subversion HTTP or HTTPS enabled repository, with the WebDAV features built in there. I find "lftp" particularly useful for command line access, and use TortoiseSVN from a Windows client to have the best user interface in the business for client-side HTTP access. You can use svnserve, HTTP, HTTPS, svn+ssh, or file based access. (I really, really don't recommend file based access for clients.)
Re: Disabling automatic setting of svn:executable property
On Tue, May 31, 2011 at 5:39 PM, Karl Heinz Marbaise wrote: > Hi, > >> We just tried that. > >> One user complained that the Windows client didn't hide passwords >> he typed in (displayed the whole thing in plain text instead of >> displaying *s), > Sorry to say so, but this can't be cause the SVN client hides on console as > well...and also on Windows...I don't know what the user really did?...May be > he mistaken the username input with the password input? > >> and he couldn't commit because the client was >> unable to find "vim" although it was installed under Cygwin. > First installed under Cygwin is not installed under windwos. These are two > different worlds. > > Furthermore if the user has correctly set the SVN_EDITOR or EDITOR > environment variable correctly to SVN_EDITOR=C:\...WhatEver\vim.exe this > will work...But this has to be done first...usually on a Unix like system > the EDITOR variable is set to default editor vi... > This default does not exist on Windows systems Whether Cygwin is "Windows" is. an interesting problem in definitions. It's precisely the sort of problem I mentioned. No idea why or how the passwords were appearing in CygWin. But CygWin has "vim" available: Mine has it installed, and it works fine. I'm really confused which "vim" he expected to use: one installed in Windows natively, or the one in CygWin? >> In short, he found the Windows-native version unusable and went >> back to the Cygwin version. > >> Any idea what might have caused those issues? > As described above... Sounds like your friend should be asking here himself.
