Re: can i svn cat without keyword expansion
On Sun, Aug 8, 2010 at 5:24 PM, Stefan Sperling wrote: > On Sun, Aug 08, 2010 at 11:50:13AM -0400, Nico Kadel-Garcia wrote: >> disabling the keywords: quite sensible, really. I'd like to see a >> similar setting for "svn diff" > > What use case do you have in mind that requires an --ignore-keywords > option for "svn diff"? > > "svn diff" already deals with keywords in contracted form. > Differences due to keyword expansion changing aren't being shown. Mixed histories with "svn:keywords" turned off, then on, for imported software that already has $Id$ or $Author$. Let's take the Linux kernel as an example. On first import, a developer may not be aware of and ready to set svn:keywords properly, especially for a n ew repository without a forced or default policy for *.c files. They do some work, make some changes, make a few branches. Then they realize that such flags in the original software are not being updated to match the local author or latest edits, so they enable keywords. Now, they need to mail Linus Torvalds the patches. The "svn diff" is now cluttered with mismatched $Id$ lines from before and after svn:keywords was enabled, almost all of which are irrelevant but which are awkward at best to filter out. And because Subversion is so excellent at preserving its history, including broken history, that mishandled original kernel is now nearly impossible to remove from the source tree: the only way to get it properly recorded, from scratch, is to get the change history and overlay it on top of a brand new, correctly imported kernel. I've actually had to do this, in an environment where developers were being careless about both svn:keywords and svn:eol, and doing their text editing from TortoiseSVN environments. It wasn't pretty.
How to build GNOME Keyring for Subversion
Hi, I am trying to build Subversion 1.6.12 with GNOME Keyring support. I have tried GNOME Keyring 2.30.3 downloaded from http://linux.softpedia.com/get/Utilities/gnome-keyring-13111.shtml The configure and make of this GNOME Keyring version have been done with two pkg-config files created: gcr-0.pc and gp11-0.pc but no gnome-keyring-1.pc generated. I have also tried to install GNOME Keyring 2.28.2 downloaded from http://www.linuxfromscratch.org/blfs/view/svn/gnome/gnome-keyring.html This version has an endless list of dependencies: GNOME Keyring 2.28.2: GConf-2.28.0, GTK+-2.18.7, intltool-0.40.6, Libgcrypt-1.4.5, and libtasn1-2.5 GConf-2.28.0: ORBit2-2.14.17 and polkit-0.94 polkit-0.94: D-Bus GObject Bindings-0.5, intltool-0.40.6, Linux-PAM-1.1.1, gobject-introspection-0.6.8, and DocBook XML DTD-4.5 ... ... That looks terrifying. I am almost giving up midway I'd like to know your experience on building subversion with GNOME Keyring. Which GNOME Keyring version works well with svn 1.6.12 and is there an easier way to do it? Your advice will be much appreciated. Thanks, Yudong The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs.
RE: How to build GNOME Keyring for Subversion
> Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 -Original Message- > From: Yudong Sun [mailto:yud...@nag.co.uk] > Sent: 09 August 2010 13:29 > To: users@subversion.apache.org > Subject: How to build GNOME Keyring for Subversion > > Hi, > > I am trying to build Subversion 1.6.12 with GNOME Keyring > support. I have tried GNOME Keyring 2.30.3 downloaded from > http://linux.softpedia.com/get/Utilities/gnome-keyring-13111.shtml > The configure and make of this GNOME Keyring version have > been done with two pkg-config files created: gcr-0.pc and > gp11-0.pc but no gnome-keyring-1.pc generated. > > I have also tried to install GNOME Keyring 2.28.2 downloaded > from > http://www.linuxfromscratch.org/blfs/view/svn/gnome/gnome-keyring.html > This version has an endless list of dependencies: > > GNOME Keyring 2.28.2: GConf-2.28.0, GTK+-2.18.7, > intltool-0.40.6, Libgcrypt-1.4.5, and libtasn1-2.5 > > GConf-2.28.0: ORBit2-2.14.17 and polkit-0.94 > > polkit-0.94: D-Bus GObject Bindings-0.5, intltool-0.40.6, > Linux-PAM-1.1.1, gobject-introspection-0.6.8, and DocBook XML DTD-4.5 > > ... ... > > That looks terrifying. I am almost giving up midway > > I'd like to know your experience on building subversion with > GNOME Keyring. Which GNOME Keyring version works well with > svn 1.6.12 and is there an easier way to do it? Your advice > will be much appreciated. You don't say which flavour of Linux, but if you have a package manager, like yum or apt-get for example, it's much easier as they take care of all the dependencies. Having said that, I personally had a hell of a time (and gave up for the time being) to unlock the keyring upon login. Once the keyring is unlocked the everything is fine, but I can't seem to be able to avoid entering the keyring password. Giulio
Re: How to build GNOME Keyring for Subversion
On Mon, Aug 09, 2010 at 01:28:54PM +0100, Yudong Sun wrote: > Hi, > > I am trying to build Subversion 1.6.12 with GNOME Keyring support. I > have tried GNOME Keyring 2.30.3 downloaded from > http://linux.softpedia.com/get/Utilities/gnome-keyring-13111.shtml > The configure and make of this GNOME Keyring version have been done > with two pkg-config files created: gcr-0.pc and gp11-0.pc but no > gnome-keyring-1.pc generated. > > I have also tried to install GNOME Keyring 2.28.2 downloaded from > http://www.linuxfromscratch.org/blfs/view/svn/gnome/gnome-keyring.html > This version has an endless list of dependencies: > > GNOME Keyring 2.28.2: GConf-2.28.0, GTK+-2.18.7, intltool-0.40.6, > Libgcrypt-1.4.5, and libtasn1-2.5 > > GConf-2.28.0: ORBit2-2.14.17 and polkit-0.94 > > polkit-0.94: D-Bus GObject Bindings-0.5, intltool-0.40.6, > Linux-PAM-1.1.1, gobject-introspection-0.6.8, and DocBook XML > DTD-4.5 > > ... ... > > That looks terrifying. I am almost giving up midway > > I'd like to know your experience on building subversion with GNOME > Keyring. Which GNOME Keyring version works well with svn 1.6.12 and > is there an easier way to do it? Your advice will be much > appreciated. Gnome-keyring's dependencies are outside of the Subversion project's control. So I'm afraid we cannot do much about it. Maybe try Kwallet? It might have a smaller list of dependencies. The easiest way by far is using a distribution that offers readily working build scripts or binary packages. Most current Linux distributions and *BSD systems offer precompiled Subversion binaries with gnome-keyring support enabled. Another possibility for a long-term fix to this problem would be contributing patches to Subversion that allow Subversion to encrypt passwords using GPGme. I'd very much appreciate any effort in this direction. Stefan
Re: How to build GNOME Keyring for Subversion
Thanks for all the replies. My platform is a bit special. It's a Cray supercomputer. The OS is Cray Linux Environment (CLE) which is developed based on SuSE Linux. Yudong Giulio Troccoli wrote, On 09/08/2010 13:44: Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 -Original Message- From: Yudong Sun [mailto:yud...@nag.co.uk] Sent: 09 August 2010 13:29 To: users@subversion.apache.org Subject: How to build GNOME Keyring for Subversion Hi, I am trying to build Subversion 1.6.12 with GNOME Keyring support. I have tried GNOME Keyring 2.30.3 downloaded from http://linux.softpedia.com/get/Utilities/gnome-keyring-13111.shtml The configure and make of this GNOME Keyring version have been done with two pkg-config files created: gcr-0.pc and gp11-0.pc but no gnome-keyring-1.pc generated. I have also tried to install GNOME Keyring 2.28.2 downloaded from http://www.linuxfromscratch.org/blfs/view/svn/gnome/gnome-keyring.html This version has an endless list of dependencies: GNOME Keyring 2.28.2: GConf-2.28.0, GTK+-2.18.7, intltool-0.40.6, Libgcrypt-1.4.5, and libtasn1-2.5 GConf-2.28.0: ORBit2-2.14.17 and polkit-0.94 polkit-0.94: D-Bus GObject Bindings-0.5, intltool-0.40.6, Linux-PAM-1.1.1, gobject-introspection-0.6.8, and DocBook XML DTD-4.5 ... ... That looks terrifying. I am almost giving up midway I'd like to know your experience on building subversion with GNOME Keyring. Which GNOME Keyring version works well with svn 1.6.12 and is there an easier way to do it? Your advice will be much appreciated. You don't say which flavour of Linux, but if you have a package manager, like yum or apt-get for example, it's much easier as they take care of all the dependencies. Having said that, I personally had a hell of a time (and gave up for the time being) to unlock the keyring upon login. Once the keyring is unlocked the everything is fine, but I can't seem to be able to avoid entering the keyring password. Giulio This e-mail has been scanned for all viruses by Star. The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs.
Re: can i svn cat without keyword expansion
Nico Kadel-Garcia wrote on Mon, Aug 09, 2010 at 07:35:42 -0400: > On Sun, Aug 8, 2010 at 5:24 PM, Stefan Sperling wrote: > > On Sun, Aug 08, 2010 at 11:50:13AM -0400, Nico Kadel-Garcia wrote: > >> disabling the keywords: quite sensible, really. I'd like to see a > >> similar setting for "svn diff" > > > > What use case do you have in mind that requires an --ignore-keywords > > option for "svn diff"? > > > > "svn diff" already deals with keywords in contracted form. > > Differences due to keyword expansion changing aren't being shown. > > Mixed histories with "svn:keywords" turned off, then on, for imported > software that already has $Id$ or $Author$. > FWIW, implementing this shouldn't be too difficult: just to change the call to the stream translation routines, such that instead of contracting only some keywords (depending on the file) they would contract all keywords.
Re: svn checkout - special characters in file name are not encoding properly
(I'm going to handle just the "svn repository" potential cause of the problem. I'll let others handle the "client-side problem, but repository is okay" potential cause.) suman.mai...@asia.bnpparibas.com wrote on Mon, Aug 09, 2010 at 11:42:04 +0530: > Hi, > I'm working on French project. Very recently we have migrated our project > from CVS to SVN repository. After migration, when checking out the file > names which have special characters like Western-Europe encoding fonts are > giving problem. > > e.g.:"modŠle fields-replacements.xsl" is the file name inside the > Subversion and after checking out the file into the local machine it is > coming like "mod?le fields-replacements.xsl" > Inside the file name '?' is displaying rather than Š(S with caron). > > Please help me to get the proper file-names from subversion without any > encoding > problem > We do support UTF-8 file names: 0:% x="modŠle fields-replacements.xsl" 0:% echo foo > $x 0:% $svnmucc put -mmsg $x file://`pwd`/r1/$x r2 committed by daniel at 2010-08-09T15:28:18.165794Z 0:% $svn up wc1 Awc1/modŠle fields-replacements.xsl Updated to revision 2. 0:% ls wc1 branches modŠle fields-replacements.xsl tags trunk 0:% (this is under linux with a UTF-8 locale) Given that you migrated from CVS to SVN, can you check that the filenames inside the repository's filesystem are encoded in UTF-8 and not in iso-8859-*? > Thank you, > Regards, > Sunny > >
Re: svn update -r $revision could hang if $revsion is greater than HEAD
The URL is like svn://svn-server-01/Project/trunk. How should I use svn+ssh? I downloaded 1.6.12 from http://subversion.tigris.org. I will try that in Visual Studio. Orginal Message Friday, August 6, 2010 10:37 PM From: "Daniel Shahaf" To: "jason_zhuyx" Cc: users@subversion.apache.org [ adding users@ back to CC ] jason_zhuyx wrote on Fri, Aug 06, 2010 at 16:01:10 -0700: > Hi Daniel, > Could you please show me couple examples of using this "svn+ssh://" thing? > Where would I expect to see the prompt? When you did a checkout, what URL did you use? (You can find that via 'svn info'.) > I downloaded the source code, how usually (e.g. in what tools/IDE) to run in > debug for a particular command? You're on Windows, so you can build/debug using MS Visual C Express 2008. There are build instructions in the INSTALL file. The source of which version did you download? Orginal Message Friday, August 6, 2010 4:01 PM From: "jason_zhuyx" To: "Daniel Shahaf" Hi Daniel, Could you please show me couple examples of using this "svn+ssh://" thing? Where would I expect to see the prompt? I downloaded the source code, how usually (e.g. in what tools/IDE) to run in debug for a particular command? Thanks, - Jason Orginal Message From: "Daniel Shahaf" To: "jason_zhuyx" Cc: users@subversion.apache.org If you're using svn+ssh://, maybe ssh is prompting you? Can you run the offending command under a debugger and investigate where it spends its time? Orginal Message From: "jason_zhuyx" To: users@subversion.apache.org Cc: "Jason Zhu" http://subversion.tigris.org/issues/show_bug.cgi?id=3687 Sorry I should have come to this mailing list before submitting my question on Issue Tracker. Since this issue can only be reproduced on some build machines in my company, I'd like to ask some experts' help on how to do the troubleshooting/debug to understand why such issue exists. Thanks Could someone provide help to me on how to test such issue on my systems? Thanks to hwright and Andy Levy's feedback. But unfortunately, I have tried on several machines and this issue repeats (even after I upgrade svn to version 1.6.12 r955767). On CentOS (2.6.18-128.el5 CentOS release 5.3), the svn version is 1.6.2 (r37639). run `svn up -r 9` on command line will not return until press Ctrl+Z. And I had to run `svn cleanup` or the workspace was locked. On Windows XP SP3, the latest svn I am testing is 1.6.12 (r955767), installed from CollabNet. The command prompt will never return to next prompt until I have to kill svn.exe in Task Manager. I found such issue when I was writing a script which could accept an invalid revision and hang, so that I had to test the revision range by myself. I'd appreciate any hint for me to figure out why this happens on my installations. --- Additional comments from hwri...@tigris.org Mon Jul 19 17:11:51 -0700 2010 --- Can not reproduce using 1.6.12 (tested against the asf repo): $ svn up -r100 subversion/libsvn_ra_neon/util.c:723: (apr_err=160006) svn: No such revision 100 $ --- On Tue, 7/20/10, Andy Levy wrote: From: Andy Levy Subject: Re: svn update -r $revision could hang if $revsion is greater than HEAD To: "jason_zhuyx" Cc: users@subversion.apache.org Date: Tuesday, July 20, 2010, 6:24 AM XP SP3 here, 1.6.6 (r40053), I cannot reproduce the issue. C:\_Projects\workspace\proj>svn up At revision 5604. C:\_Projects\workspace\proj>svn up -r 6000 svn: No such revision 6000 C:\_Projects\workspace\proj>svn --version svn, version 1.6.6 (r40053) compiled Oct 19 2009, 09:36:48 No hangs.
Re: svn checkout - special characters in file name are not encoding properly
Hi. Am 09.08.2010 um 17:31 schrieb Daniel Shahaf : suman.mai...@asia.bnpparibas.com wrote on Mon, Aug 09, 2010 at 11:42:04 +0530: Hi, I'm working on French project. Very recently we have migrated our project from CVS to SVN repository. After migration, when checking out the file names which have special characters like Western-Europe encoding fonts are giving problem. e.g.:"modŠle fields-replacements.xsl" is the file name inside the Subversion and after checking out the file into the local machine it is coming like "mod?le fields-replacements.xsl" Inside the file name '?' is displaying rather than Š(S with caron). Please help me to get the proper file-names from subversion without any encoding problem We do support UTF-8 file names: And I bet, that exactly this is the problem; I bet, he's on a platform, which doesn't use UTF8 for encoding filenames (eg. Windows). How's the iso-8859-x support? Especially if Linux and Windows are used in parallel? Alexander
Re: svn checkout - special characters in file name are not encoding properly
Alexander Skwar wrote on Mon, Aug 09, 2010 at 18:22:57 +0200: > Hi. > > > Am 09.08.2010 um 17:31 schrieb Daniel Shahaf : > >> >> >> suman.mai...@asia.bnpparibas.com wrote on Mon, Aug 09, 2010 at >> 11:42:04 +0530: >>> Hi, >>> I'm working on French project. Very recently we have migrated our >>> project >>> from CVS to SVN repository. After migration, when checking out the >>> file >>> names which have special characters like Western-Europe encoding >>> fonts are >>> giving problem. >>> >>> e.g.:"modŠle fields-replacements.xsl" is the file name inside the >>> Subversion and after checking out the file into the local machine it >>> is >>> coming like "mod?le fields-replacements.xsl" >>> Inside the file name '?' is displaying rather than Š(S with caron). >>> >>> Please help me to get the proper file-names from subversion without >>> any >>> encoding >>> problem >>> >> >> We do support UTF-8 file names: >> > > And I bet, that exactly this is the problem; I bet, he's on a platform, > which doesn't use UTF8 for encoding filenames (eg. Windows). > > How's the iso-8859-x support? Especially if Linux and Windows are used > in parallel? > In the repository filesystem, we use UTF-8 exclusively. APR handles translating that UTF-8 to whatever the local OS supports. > Alexander > >>
Re: svn update -r $revision could hang if $revsion is greater than HEAD
jason_zhuyx wrote on Mon, Aug 09, 2010 at 08:58:55 -0700: > The URL is like svn://svn-server-01/Project/trunk. How should I use svn+ssh? I said: "If you're using svn+ssh://, maybe ssh is prompting you?" ^^ You are not using svn+ssh://, and I wasn't suggesting that you switch to doing that.
Storing large amounts of medium-sized binary files in Subversion
Hello, how good/bad an idea is storing large amounts of medium-sized files (think Yum/RPM repositories with full CentOS/EPEL releases) in SVN for rollback and other purposes? I've got the feeling that the amount of disk space consumed for deprecated versions alone should be preventive; making backups etc. unnecessarily hard. Are there other reasons not to do this? How would you build an argument about this? Can you make this an FAQ answer? Cheers, Andreas -- Andreas Kotes, CISSP, CCNA - flatline IT services - ISP & IT Consulting "Love many things, for therein lies the true strength, and whosoever loves much performs much, and can accomplish much, and what is done in love is done well." -- Vincent van Gogh
RE: Storing large amounts of medium-sized binary files in Subversion
> how good/bad an idea is storing large amounts of medium-sized files > (think Yum/RPM repositories with full CentOS/EPEL releases) in > SVN for rollback and other purposes? > > I've got the feeling that the amount of disk space consumed for > deprecated versions alone should be preventive; making backups etc. > unnecessarily hard. > > Are there other reasons not to do this? How would you build an > argument > about this? Can you make this an FAQ answer? > > Cheers, > >Andreas I think the only issue would be storage space. But, you would need a svn dev to tell you the particulars... I think there are cases where a simple delta can't always be used for a binary file so the whole content is stored in each revision. BOb
RE: svn checkout - special characters in file name are not encoding properly
> -Original Message- > From: Alexander Skwar [mailto:a.sk...@gmail.com] On Behalf Of Alexander > Skwar > Sent: maandag 9 augustus 2010 18:23 > To: Daniel Shahaf > Cc: suman.mai...@asia.bnpparibas.com; users@subversion.apache.org > Subject: Re: svn checkout - special characters in file name are not encoding > properly > > Hi. > > > Am 09.08.2010 um 17:31 schrieb Daniel Shahaf : > > > > > > > suman.mai...@asia.bnpparibas.com wrote on Mon, Aug 09, 2010 at > > 11:42:04 +0530: > >> Hi, > >> I'm working on French project. Very recently we have migrated our > >> project > >> from CVS to SVN repository. After migration, when checking out the > >> file > >> names which have special characters like Western-Europe encoding > >> fonts are > >> giving problem. > >> > >> e.g.:"modŠle fields-replacements.xsl" is the file name inside the > >> Subversion and after checking out the file into the local machine > >> it is > >> coming like "mod?le fields-replacements.xsl" > >> Inside the file name '?' is displaying rather than Š(S with caron). > >> > >> Please help me to get the proper file-names from subversion without > >> any > >> encoding > >> problem > >> > > > > We do support UTF-8 file names: > > > > And I bet, that exactly this is the problem; I bet, he's on a > platform, which doesn't use UTF8 for encoding filenames (eg. Windows). All standard filesystems on Windows since Windows '95 / NT use UTF-16 (or UCS-2) in the filesystem (NTFS, FAT32, VFAT), so Windows can express any character expressed in utf-8 by simple recoding. On Windows '9X the usual way to access them was using the ANSI set, but all Windows '9X versions and even Windows 2000 are out of support now, so APR handles everything for us in Unicode now. There might be some issues if you use network shares; especially if the network share is hosted on some NAS, because these systems sometimes use older protocols and or filesystems which don't support unicode. Bert
Re: viewing svn logs?
On Aug 6, 2010, at 9:19 AM, Chris Shelton wrote: > Tom, > > On Fri, Aug 6, 2010 at 11:58 AM, Tom Cruickshank wrote: > Preferably real-time (or scheduled). > > ie, file(s) get added/committed/updated, etc to the svn server, and viewer > automatically displays the latest entries. > > As long as each piece of information is identified (ie. Revision, Comments, > path/filename, etc) it should be ok. > > The viewers are technically inclined. They have an understanding of what > subversion is already :) > > Tom > > > Trac provides all of these attributes by default in the timeline view. It > needs to be installed on the SVN server, but does provide some basic > searching capabilities, and a nice read-only interface to a subversion > repository. Trac would be a good choice if I understand the requirements properly. It has its own fine-grained permission system that's independent of Subversion's, and it does a nice job formatting the log into a readable timeline. -- David Brodbeck System Administrator, Linguistics University of Washington
Re: Cannot delete directory after deleting included file
On Sun, Aug 8, 2010 at 9:58 PM, Richard Biffl wrote: > If I delete a file from a directory in my working copy, and commit the > deletion, > and then delete the directory that held the deleted file, I cannot commit the > working copy. I get a message instead that the directory is out of date. > > At that point, I cannot revert the directory deletion, and if I try to update > the working copy, I am told I have a tree conflict. > > The way to prevent this problem, I've learned, is to update the working copy > after I commit the deletion of the single file. But that's not intuitive, > especially when I am the only user and I'm making changes from just one > working > copy. It seems wrong that I should need to update immediately after I commit. > > Here is a list of commands that shows the problem. It's in Windows cmd: > > [starting with empty repository \svn\repo1] > $ mkdir work1 > $ svn checkout file:///svn/repo1 work1 > $ mkdir work1\dir1 > $ echo blah > work1\dir1\file1 > $ echo blah > work1\dir1\file2 > $ svn add work1\dir1 > $ svn commit work1 -m "Created directory with 2 files." > $ svn delete work1\dir1\file1 > $ svn commit work1 -m "Deleted dir1\file1." > $ svn delete \work1\dir1 > $ svn commit work1 -m "Deleted dir1 and dir1\file2." > Deleting \work1\dir1 > svn: Commit failed (details follow): > svn: Directory '/dir1' is out of date This looks similar to issue 3526: http://subversion.tigris.org/issues/show_bug.cgi?id=3526 - Commit of newly added file followed by move (or delete) of parent dir causes tree conflict A couple of relevant discussions which may provide some additional insight: - http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388307 - http://svn.haxx.se/dev/archive-2010-03/0496.shtml - http://svn.haxx.se/users/archive-2010-06/0033.shtml I'm not sure what the current plan is for that issue. As far as I understand, the out-of-dateness can not be avoided. It is a consequence of the "mixed-revision working copy" system that SVN uses. I think it would already help a lot of there would be no tree conflict when updating (which is what issue 3526 is actually about). But I'm not sure if someone is actively working on this. >From one of the mail threads above, a good workaround to avoid this issue is to always update a directory before you move or delete it (you don't have to update the entire working copy, just the part you are about to move/delete). -- Johan
Re: svn checkout - special characters in file name are not encoding properly
Please let me know how to check the file system encoding type in repository, and assist me to change the encoding with a proper encoding format to get the files properly. --Sunny Internet d...@daniel.shahaf.name 09/08/2010 21:01 To Suman MAINAM cc users Subject Re: svn checkout - special characters in file name are not encoding properly (I'm going to handle just the "svn repository" potential cause of the problem. I'll let others handle the "client-side problem, but repository is okay" potential cause.) suman.mai...@asia.bnpparibas.com wrote on Mon, Aug 09, 2010 at 11:42:04 +0530: > Hi, > I'm working on French project. Very recently we have migrated our project > from CVS to SVN repository. After migration, when checking out the file > names which have special characters like Western-Europe encoding fonts are > giving problem. > > e.g.:"modŠle fields-replacements.xsl" is the file name inside the > Subversion and after checking out the file into the local machine it is > coming like "mod?le fields-replacements.xsl" > Inside the file name '?' is displaying rather than Š(S with caron). > > Please help me to get the proper file-names from subversion without any > encoding > problem > We do support UTF-8 file names: 0:% x="modŠle fields-replacements.xsl" 0:% echo foo > $x 0:% $svnmucc put -mmsg $x file://`pwd`/r1/$x r2 committed by daniel at 2010-08-09T15:28:18.165794Z 0:% $svn up wc1 Awc1/modŠle fields-replacements.xsl Updated to revision 2. 0:% ls wc1 branches modŠle fields-replacements.xsl tags trunk 0:% (this is under linux with a UTF-8 locale) Given that you migrated from CVS to SVN, can you check that the filenames inside the repository's filesystem are encoded in UTF-8 and not in iso-8859-*? > Thank you, > Regards, > Sunny > > This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Do not print this message unless it is necessary, consider the environment. - Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. N'imprimez ce message que si necessaire, pensez a l'environnement.
Re: svn checkout - special characters in file name are not encoding properly
suman.mai...@asia.bnpparibas.com wrote on Tue, Aug 10, 2010 at 10:52:10 +0530: > Please let me know how to check the file system encoding type in > repository, Use tools that access the repository directly. (i.e., the tools that take a *path*, rather than a URL, of the repository.) For example: svnlook tree --full-paths /path/to/repos svnadmin dump /path/to/repos | grep '^Node-path:' > and assist me to change the encoding with a proper encoding > format to get the files properly. > *If* the encoding in the repository filesystem is wrong, then you'll need to rewrite history. I suppose one of the dumpfile manipulation tools out there would be your best bet; someone on the list might be able to make a more specific recommendation. > --Sunny > > > > > Internet > d...@daniel.shahaf.name > 09/08/2010 21:01 > > To > Suman MAINAM > cc > users > Subject > Re: svn checkout - special characters in file name are not encoding > properly > > > > > > > (I'm going to handle just the "svn repository" potential cause of the > problem. I'll let others handle the "client-side problem, but repository > is > okay" potential cause.) > > suman.mai...@asia.bnpparibas.com wrote on Mon, Aug 09, 2010 at 11:42:04 > +0530: > > Hi, > > I'm working on French project. Very recently we have migrated our > project > > from CVS to SVN repository. After migration, when checking out the file > > names which have special characters like Western-Europe encoding fonts > are > > giving problem. > > > > e.g.:"modŠle fields-replacements.xsl" is the file name inside the > > Subversion and after checking out the file into the local machine it is > > coming like "mod?le fields-replacements.xsl" > > Inside the file name '?' is displaying rather than Š(S with caron). > > > > Please help me to get the proper file-names from subversion without any > > encoding > > problem > > > > We do support UTF-8 file names: > > 0:% x="modŠle fields-replacements.xsl" > 0:% echo foo > $x > 0:% $svnmucc put -mmsg $x file://`pwd`/r1/$x > r2 committed by daniel at 2010-08-09T15:28:18.165794Z > 0:% $svn up wc1 > Awc1/modŠle fields-replacements.xsl > Updated to revision 2. > 0:% ls wc1 > branches modŠle fields-replacements.xsl tags trunk > 0:% > > (this is under linux with a UTF-8 locale) > > > Given that you migrated from CVS to SVN, can you check that the filenames > inside the repository's filesystem are encoded in UTF-8 and not in > iso-8859-*? > > > > > Thank you, > > Regards, > > Sunny > > > > > > > > > > > > > This message and any attachments (the "message") is > intended solely for the addressees and is confidential. > If you receive this message in error, please delete it and > immediately notify the sender. Any use not in accord with > its purpose, any dissemination or disclosure, either whole > or partial, is prohibited except formal approval. The internet > can not guarantee the integrity of this message. > BNP PARIBAS (and its subsidiaries) shall (will) not > therefore be liable for the message if modified. > Do not print this message unless it is necessary, > consider the environment. > > - > > Ce message et toutes les pieces jointes (ci-apres le > "message") sont etablis a l'intention exclusive de ses > destinataires et sont confidentiels. Si vous recevez ce > message par erreur, merci de le detruire et d'en avertir > immediatement l'expediteur. Toute utilisation de ce > message non conforme a sa destination, toute diffusion > ou toute publication, totale ou partielle, est interdite, sauf > autorisation expresse. L'internet ne permettant pas > d'assurer l'integrite de ce message, BNP PARIBAS (et ses > filiales) decline(nt) toute responsabilite au titre de ce > message, dans l'hypothese ou il aurait ete modifie. > N'imprimez ce message que si necessaire, > pensez a l'environnement.
