Re: Question
I have been looking through this thread and it might be resolved. Can I ask why you are trying to merge from trunk into the branch? The usual operation would be the other way around, otherwise you can run into reflective merge issues. Rob On 8 December 2011 18:10, Stefan Sperling wrote: > On Thu, Dec 08, 2011 at 10:15:24AM -0700, Randall Reynolds wrote: > > When I select merge a range of revisions and leave the range blank, it > says: > > > > Merging r7 through 42194 > > <~10 tree conflicts on main folders> > > > > Does this mean we have never merged the trunk into the branch correctly > in > > a way that merge tracking recognizes, and how should I proceed to fix the > > issue? > > It's possible that your server isn't new enough to support merge-tracking. > What version of Subversion is running on the server? > The minimum server version for merge-tracking is 1.5. > Your client should also at least be a 1.5 version and preferably 1.7. > > Another way this can happen is if you fail to commit the svn:mergeinfo > property the Subversion client creates during a merge. > > If you know the revision range you've already merged but failed to record > you can run the same merge as a 'record-only' merge. Tortoisesvn has a > checkbox for this in the merge dialog somewhere. A record-only merge will > create the svn:mergeinfo property but not actually merge any changes to > working files. Of course you must make sure that whatever revisions you > merge as record-only have already been merged. Else you're likely to > encounter more merging troubles down the road. > > BTW, the more common use case for record-only merges is to block revisions > you don't want to merge by marking them as already merged, see > > http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges > -- *Rob Pointer MSc* Software Specialist and Consultant rpoin...@clearvision-cm.com * Tel: +44 (0) 845 459 9530 ** ** <http://www.twitter.com/clearvisioncm> <http://www.facebook.com/clearvisioncm> <http://www.linkedin.com/company/clearvision> <http://www.clearvision-cm.com/rss-feed/clearvision-news> <http://www.clearvision-cm.com/> *
Re: Question
Mark If you put changes multiple times from trunk to a branch (in development terms, a re-base) you can cause reflective merges and actually cause more problems. The recommended merge back into trunk is a reintegrate merge. I am not sure if this has been addressed in 1.7, but certainly for earlier versions (anyone please correct me if I am wrong here though :) ). The scenario goes 1) trunk contains file A 2) copy trunk to branch1 3) modify file A in branch1 4) add folderb/fileb in trunk 5) branch (copy) folderb into branch (or merge if it actually works :) ) 6) do some changes to file A and ffileb 7) merge back into trunk. SVN seems to get confused and when it checks the history of both trunk and branch1 it doesn't know that the folderb/fileb was added in branch1 using a copy, therefore it just thinks you added the files on trunk and then branch1 as two separate operations (for any clearcase users this is an evil twin scenario). Therefore SVN will create a tree conflict when merging your branch back into trunk. A similar scenario occurs of you copied file A from trunk to branch1 after modifying it on trunk. SVN will then throw content conflicts, telling you that you modified the same line in the file in two branches (i.e. trunk and branch1) and the text is identical. Again not sure if 1.7 fixes this, but it is definitely present in 1.6.x Rob On 9 December 2011 12:49, Cooke, Mark wrote: > > > > -Original Message----- > > From: Rob Pointer [mailto:rpoin...@clearvision-cm.com] > > Sent: 09 December 2011 12:45 > > To: Randall Reynolds; Cooke, Mark; users@subversion.apache.org > > Subject: Re: Question > > > > I have been looking through this thread and it might be resolved. > > > > Can I ask why you are trying to merge from trunk into the > > branch? The usual operation would be the other way around, > > otherwise you can run into reflective merge issues. > > Really? My understanding is that most merges are from trunk to branch to > keep the branch up to date so that when you reintegrate back to trunk you > hit less issues... > > ~ mark c > > > Rob > -- *Rob Pointer MSc* Software Specialist and Consultant rpoin...@clearvision-cm.com * Tel: +44 (0) 845 459 9530 ** ** <http://www.twitter.com/clearvisioncm> <http://www.facebook.com/clearvisioncm> <http://www.linkedin.com/company/clearvision> <http://www.clearvision-cm.com/rss-feed/clearvision-news> <http://www.clearvision-cm.com/> *
Re: Question
Let me explain my reasoning. My thinking is that if you are trying to merge from trunk to branch, then you are doing things the wrong way around, because if you copy out from trunk, you merge back into trunk. The other issue may be that If you copy from trunk more than once to the same branch (from trunk) at different revisions, then try to merge back you will likely get reflective merge issues. This is because SVN actually tries to track the changes back. In this case you would need to do a reintegrate merge. But from your explanation you are just doing copy, add copy. Or have you actually copied more than once from trunk to the branch? When you look at the merge conflicts, are they for for folders/files that existed in trunk before the copy? If so they I really think you are doing teh merge the wrong way around :) I am therefore still concerned about your terminology of merging FROM trunk INTO branch. It should most definitely be FROM branch INTO trunk. (excuse the caps, I don't have the ability from here to make my text bold :) ) Rob On 9 December 2011 12:44, Rob Pointer wrote: > I have been looking through this thread and it might be resolved. > > Can I ask why you are trying to merge from trunk into the branch? The > usual operation would be the other way around, otherwise you can run into > reflective merge issues. > > Rob > > > On 8 December 2011 18:10, Stefan Sperling wrote: > >> On Thu, Dec 08, 2011 at 10:15:24AM -0700, Randall Reynolds wrote: >> > When I select merge a range of revisions and leave the range blank, it >> says: >> > >> > Merging r7 through 42194 >> > <~10 tree conflicts on main folders> >> > >> > Does this mean we have never merged the trunk into the branch correctly >> in >> > a way that merge tracking recognizes, and how should I proceed to fix >> the >> > issue? >> >> It's possible that your server isn't new enough to support merge-tracking. >> What version of Subversion is running on the server? >> The minimum server version for merge-tracking is 1.5. >> Your client should also at least be a 1.5 version and preferably 1.7. >> >> Another way this can happen is if you fail to commit the svn:mergeinfo >> property the Subversion client creates during a merge. >> >> If you know the revision range you've already merged but failed to record >> you can run the same merge as a 'record-only' merge. Tortoisesvn has a >> checkbox for this in the merge dialog somewhere. A record-only merge will >> create the svn:mergeinfo property but not actually merge any changes to >> working files. Of course you must make sure that whatever revisions you >> merge as record-only have already been merged. Else you're likely to >> encounter more merging troubles down the road. >> >> BTW, the more common use case for record-only merges is to block revisions >> you don't want to merge by marking them as already merged, see >> >> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges >> > > > > -- > *Rob Pointer MSc* > Software Specialist and Consultant > rpoin...@clearvision-cm.com > > * > Tel: +44 (0) 845 459 9530 > ** > ** > <http://www.twitter.com/clearvisioncm> > <http://www.facebook.com/clearvisioncm> > <http://www.linkedin.com/company/clearvision> > <http://www.clearvision-cm.com/rss-feed/clearvision-news> > <http://www.clearvision-cm.com/> > * > > > -- *Rob Pointer MSc* Software Specialist and Consultant rpoin...@clearvision-cm.com * Tel: +44 (0) 845 459 9530 ** ** <http://www.twitter.com/clearvisioncm> <http://www.facebook.com/clearvisioncm> <http://www.linkedin.com/company/clearvision> <http://www.clearvision-cm.com/rss-feed/clearvision-news> <http://www.clearvision-cm.com/> *
Re: Question
Stefan That's exactly what I was saying, that if any merging/copy has occurred from trunk to branch, then you need to use the reintegrate merge. if you don't then that's when you get merge conflicts. On 9 December 2011 14:00, Stefan Sperling wrote: > On Fri, Dec 09, 2011 at 01:05:02PM +, Rob Pointer wrote: > > Mark > > If you put changes multiple times from trunk to a branch (in development > > terms, a re-base) you can cause reflective merges and actually cause more > > problems. The recommended merge back into trunk is a reintegrate merge. > > I am not sure if this has been addressed in 1.7, but certainly for > earlier > > versions (anyone please correct me if I am wrong here though :) ). > > > > The scenario goes > > 1) trunk contains file A > > 2) copy trunk to branch1 > > 3) modify file A in branch1 > > 4) add folderb/fileb in trunk > > 5) branch (copy) folderb into branch (or merge if it actually works :) ) > > 6) do some changes to file A and ffileb > > 7) merge back into trunk. > > > > SVN seems to get confused and when it checks the history of both trunk > and > > branch1 it doesn't know that the folderb/fileb was added in branch1 > using a > > copy, therefore it just thinks you added the files on trunk and then > > branch1 as two separate operations (for any clearcase users this is an > evil > > twin scenario). Therefore SVN will create a tree conflict when merging > > your branch back into trunk. > > Wrong, wrong, wrong. You may believe that Subversion is broken but in > fact you're just pushing its buttons the wrong way. > > To be clear, if you use the correct merge syntax for each step your > scenario works just fine. And this applies to 1.6 as well as 1.7. > > To demonstrate: > > + rm -rf reflective-merge > + mkdir -p reflective-merge > + mkdir -p reflective-merge/trunk > + echo A > + > reflective-merge/trunk/A > + svnadmin create /tmp/reflective-merge/repos > + svn import reflective-merge/trunk > file:tmp/reflective-merge/repos/trunk -m importing project tree > Adding reflective-merge/trunk/A > > Committed revision 1. > + svn copy file:tmp/reflective-merge/repos/trunk > file:tmp/reflective-merge/repos/branch1 -m creating branch > > Committed revision 2. > + rm -rf reflective-merge/trunk > + svn checkout file:tmp/reflective-merge/repos/trunk > reflective-merge/trunk > Areflective-merge/trunk/A > Checked out revision 2. > + svn checkout file:tmp/reflective-merge/repos/branch1 > reflective-merge/branch1 > Areflective-merge/branch1/A > Checked out revision 2. > + echo foo > + >> reflective-merge/branch1/A > + svn commit -m modify A on branch reflective-merge/branch1 > Sendingreflective-merge/branch1/A > Transmitting file data . > Committed revision 3. > + svn mkdir reflective-merge/trunk/folderb > A reflective-merge/trunk/folderb > + echo bar > + >> reflective-merge/trunk/folderb/fileb > + svn commit -m add folderb/fileb on trunk reflective-merge/trunk > Adding reflective-merge/trunk/folderb > > Committed revision 4. > + svn update reflective-merge/branch1 > Updating 'reflective-merge/branch1': > At revision 4. > + svn merge file:tmp/reflective-merge/repos/trunk > reflective-merge/branch1 --accept postpone > --- Merging r2 through r4 into 'reflective-merge/branch1': > Areflective-merge/branch1/folderb > --- Recording mergeinfo for merge of r2 through r4 into > 'reflective-merge/branch1': > U reflective-merge/branch1 > + svn commit reflective-merge/branch1 -m merge trunk into branch (no > conflicts) > Sendingreflective-merge/branch1 > Adding reflective-merge/branch1/folderb > > Committed revision 5. > + echo baz > + >> reflective-merge/branch1/folderb/fileb > + svn commit -m modify folderb/fileb on branch reflective-merge/branch1 > + svn update reflective-merge/trunk > Updating 'reflective-merge/trunk': > At revision 5. > + svn merge --reintegrate file:tmp/reflective-merge/repos/branch1 > reflective-merge/trunk --accept postpone > --- Merging differences between repository URLs into > 'reflective-merge/trunk': > Ureflective-merge/trunk/A > --- Recording mergeinfo for merge between repository URLs into > 'reflective-merge/trunk': > U reflective-merge/trunk > + svn commit reflective-merge/trunk -m reintegrate branch into trunk (no > conflicts) > Sendingreflective-merge/trunk > Sendingreflective-merge/trunk/A > Transmitting file data . > Committed revision 6. > > You only
Re: Question
Oh and Stefan "Again, please verify that you're invoking the tool in the right way before jumping to conclusions." Jumping to conclusions is the only way I get exercise :) :) On 9 December 2011 16:52, Rob Pointer wrote: > Stefan > That's exactly what I was saying, that if any merging/copy has occurred > from trunk to branch, then you need to use the reintegrate merge. if you > don't then that's when you get merge conflicts. > > > On 9 December 2011 14:00, Stefan Sperling wrote: > >> On Fri, Dec 09, 2011 at 01:05:02PM +, Rob Pointer wrote: >> > Mark >> > If you put changes multiple times from trunk to a branch (in development >> > terms, a re-base) you can cause reflective merges and actually cause >> more >> > problems. The recommended merge back into trunk is a reintegrate merge. >> > I am not sure if this has been addressed in 1.7, but certainly for >> earlier >> > versions (anyone please correct me if I am wrong here though :) ). >> > >> > The scenario goes >> > 1) trunk contains file A >> > 2) copy trunk to branch1 >> > 3) modify file A in branch1 >> > 4) add folderb/fileb in trunk >> > 5) branch (copy) folderb into branch (or merge if it actually works :) ) >> > 6) do some changes to file A and ffileb >> > 7) merge back into trunk. >> > >> > SVN seems to get confused and when it checks the history of both trunk >> and >> > branch1 it doesn't know that the folderb/fileb was added in branch1 >> using a >> > copy, therefore it just thinks you added the files on trunk and then >> > branch1 as two separate operations (for any clearcase users this is an >> evil >> > twin scenario). Therefore SVN will create a tree conflict when merging >> > your branch back into trunk. >> >> Wrong, wrong, wrong. You may believe that Subversion is broken but in >> fact you're just pushing its buttons the wrong way. >> >> To be clear, if you use the correct merge syntax for each step your >> scenario works just fine. And this applies to 1.6 as well as 1.7. >> >> To demonstrate: >> >> + rm -rf reflective-merge >> + mkdir -p reflective-merge >> + mkdir -p reflective-merge/trunk >> + echo A >> + > reflective-merge/trunk/A >> + svnadmin create /tmp/reflective-merge/repos >> + svn import reflective-merge/trunk >> file:tmp/reflective-merge/repos/trunk -m importing project tree >> Adding reflective-merge/trunk/A >> >> Committed revision 1. >> + svn copy file:tmp/reflective-merge/repos/trunk >> file:tmp/reflective-merge/repos/branch1 -m creating branch >> >> Committed revision 2. >> + rm -rf reflective-merge/trunk >> + svn checkout file:tmp/reflective-merge/repos/trunk >> reflective-merge/trunk >> Areflective-merge/trunk/A >> Checked out revision 2. >> + svn checkout file:tmp/reflective-merge/repos/branch1 >> reflective-merge/branch1 >> Areflective-merge/branch1/A >> Checked out revision 2. >> + echo foo >> + >> reflective-merge/branch1/A >> + svn commit -m modify A on branch reflective-merge/branch1 >> Sendingreflective-merge/branch1/A >> Transmitting file data . >> Committed revision 3. >> + svn mkdir reflective-merge/trunk/folderb >> A reflective-merge/trunk/folderb >> + echo bar >> + >> reflective-merge/trunk/folderb/fileb >> + svn commit -m add folderb/fileb on trunk reflective-merge/trunk >> Adding reflective-merge/trunk/folderb >> >> Committed revision 4. >> + svn update reflective-merge/branch1 >> Updating 'reflective-merge/branch1': >> At revision 4. >> + svn merge file:tmp/reflective-merge/repos/trunk >> reflective-merge/branch1 --accept postpone >> --- Merging r2 through r4 into 'reflective-merge/branch1': >> Areflective-merge/branch1/folderb >> --- Recording mergeinfo for merge of r2 through r4 into >> 'reflective-merge/branch1': >> U reflective-merge/branch1 >> + svn commit reflective-merge/branch1 -m merge trunk into branch (no >> conflicts) >> Sendingreflective-merge/branch1 >> Adding reflective-merge/branch1/folderb >> >> Committed revision 5. >> + echo baz >> + >> reflective-merge/branch1/folderb/fileb >> + svn commit -m modify folderb/fileb on branch reflective-merge/branch1 >> + svn update reflective-merge/trunk >> Updating 'reflective-merge/trunk': >> At
Re: Question
And yes I know it does matter what way you invoke the tool, I was trying to figure out what was going on with the original problem by putting together a quick scenario (OK a slightly wobbly one). But I had to jump to conclusions to guess what was occurring in the original question. How else can you get someone to say 'no we didn't do it that way, we did it this way' :) :) However your reply tells me that you also jumped to a conclusion of your own about what I was saying ;) On 9 December 2011 16:54, Rob Pointer wrote: > Oh and Stefan > > "Again, please verify that you're invoking the tool in the right way > before jumping to conclusions." > > Jumping to conclusions is the only way I get exercise :) :) > > On 9 December 2011 16:52, Rob Pointer wrote: > >> Stefan >> That's exactly what I was saying, that if any merging/copy has occurred >> from trunk to branch, then you need to use the reintegrate merge. if you >> don't then that's when you get merge conflicts. >> >> >> On 9 December 2011 14:00, Stefan Sperling wrote: >> >>> On Fri, Dec 09, 2011 at 01:05:02PM +, Rob Pointer wrote: >>> > Mark >>> > If you put changes multiple times from trunk to a branch (in >>> development >>> > terms, a re-base) you can cause reflective merges and actually cause >>> more >>> > problems. The recommended merge back into trunk is a reintegrate >>> merge. >>> > I am not sure if this has been addressed in 1.7, but certainly for >>> earlier >>> > versions (anyone please correct me if I am wrong here though :) ). >>> > >>> > The scenario goes >>> > 1) trunk contains file A >>> > 2) copy trunk to branch1 >>> > 3) modify file A in branch1 >>> > 4) add folderb/fileb in trunk >>> > 5) branch (copy) folderb into branch (or merge if it actually works :) >>> ) >>> > 6) do some changes to file A and ffileb >>> > 7) merge back into trunk. >>> > >>> > SVN seems to get confused and when it checks the history of both trunk >>> and >>> > branch1 it doesn't know that the folderb/fileb was added in branch1 >>> using a >>> > copy, therefore it just thinks you added the files on trunk and then >>> > branch1 as two separate operations (for any clearcase users this is an >>> evil >>> > twin scenario). Therefore SVN will create a tree conflict when merging >>> > your branch back into trunk. >>> >>> Wrong, wrong, wrong. You may believe that Subversion is broken but in >>> fact you're just pushing its buttons the wrong way. >>> >>> To be clear, if you use the correct merge syntax for each step your >>> scenario works just fine. And this applies to 1.6 as well as 1.7. >>> >>> To demonstrate: >>> >>> + rm -rf reflective-merge >>> + mkdir -p reflective-merge >>> + mkdir -p reflective-merge/trunk >>> + echo A >>> + > reflective-merge/trunk/A >>> + svnadmin create /tmp/reflective-merge/repos >>> + svn import reflective-merge/trunk >>> file:tmp/reflective-merge/repos/trunk -m importing project tree >>> Adding reflective-merge/trunk/A >>> >>> Committed revision 1. >>> + svn copy file:tmp/reflective-merge/repos/trunk >>> file:tmp/reflective-merge/repos/branch1 -m creating branch >>> >>> Committed revision 2. >>> + rm -rf reflective-merge/trunk >>> + svn checkout file:tmp/reflective-merge/repos/trunk >>> reflective-merge/trunk >>> Areflective-merge/trunk/A >>> Checked out revision 2. >>> + svn checkout file:tmp/reflective-merge/repos/branch1 >>> reflective-merge/branch1 >>> Areflective-merge/branch1/A >>> Checked out revision 2. >>> + echo foo >>> + >> reflective-merge/branch1/A >>> + svn commit -m modify A on branch reflective-merge/branch1 >>> Sendingreflective-merge/branch1/A >>> Transmitting file data . >>> Committed revision 3. >>> + svn mkdir reflective-merge/trunk/folderb >>> A reflective-merge/trunk/folderb >>> + echo bar >>> + >> reflective-merge/trunk/folderb/fileb >>> + svn commit -m add folderb/fileb on trunk reflective-merge/trunk >>> Adding reflective-merge/trunk/folderb >>> >>> Committed revision 4. >>> + svn update reflective-merge/branch1 >>> Updating &#x
Re: Do all SVN clients run with all SVN servers?
Forgive me if I am misunderstanding here however SVN clients cannot be 'forward' compatible. i.e. an svn 1.4 client will not work with a 1.6 server (repository format differs) and checking out in this manner would produce an error saying that the expected repository format was incorrect. However (as far as I am aware) point releases are file (e.g. 1.6.1 and 1.6.2 clients would work with servers of 1.6 and below . Rob On 30 March 2012 01:50, Daniel Shahaf wrote: > Nico Kadel-Garcia wrote on Thu, Mar 29, 2012 at 20:33:44 -0400: > > On Thu, Mar 29, 2012 at 8:03 AM, Daniel Shahaf >wrote: > > > > > Nico Kadel-Garcia wrote on Thu, Mar 29, 2012 at 07:53:05 -0400: > > > > On Thu, Mar 29, 2012 at 6:59 AM, Mark Phippard > > > wrote: > > > > > > > > > On Thu, Mar 29, 2012 at 6:35 AM, Ben Stover > > > wrote: > > > > > > As I can see there are a couple of different SVN servers and > mutiple > > > SVN > > > > > clients. > > > > > > > > > > > > Do all SVN clients work with all SVN servers? > > > > > > Or are some clients tied to the usage of some special SVN > servers? > > > > > > > > > > All client and servers should be interoperable, even across > versions. > > > > > So a 1.7 client should work with a 1.0 server and vice versa. > Clients > > > > > are generally interoperable with each other on the same working > copy > > > > > as well. In that scenario, all of the clients do need to be from > the > > > > > same major.minor Subversion version as the client working copy > format > > > > > typically changes between versions > > > > > > > > > > > > > Some features are not backwards compatible. The syntax of > svn:externals, > > > > for example, has changed significantly. And there are still people > with > > > > > > The old syntax is recognized by all servers and clients, and the help > > > output documents exactly which syntaxes are not compatible with older > > > (<=1.4) clients. > > > > > And RHEL 4 comes with subversion 1.1.1. It's still under extended support > > from Red Hat: I'm trying to build a clean update to the Repoforge 1.6.17 > > that compiles on all RHEL 4 or greater releases, and it is *NOT* easy. > > Very nice, and good luck. My main point was to clarify your statement > about the compatibility of svn:externals, not to claim that 1.1 is or > isn't supported. > -- *Rob Pointer MSc* Software Specialist and Consultant rpoin...@clearvision-cm.com * Tel: +44 (0) 845 459 9530 ** ** <http://www.twitter.com/clearvisioncm> <http://www.facebook.com/clearvisioncm> <http://www.linkedin.com/company/clearvision> <http://www.clearvision-cm.com/rss-feed/clearvision-news> <http://www.clearvision-cm.com/> *
Do all SVN clients run with all SVN servers?
Ah so there was my misunderstanding on the question. The question was regarding using the client to connect via a web server (i.e. dav svn protocol) I was assuming a direct repo connection. i should read properly before replying :) rob On Friday, 30 March 2012, Mark Phippard wrote: > On Fri, Mar 30, 2012 at 7:53 AM, Rob Pointer > wrote: > >> Forgive me if I am misunderstanding here however SVN clients cannot be >> 'forward' compatible. i.e. an svn 1.4 client will not work with a 1.6 >> server (repository format differs) and checking out in this manner would >> produce an error saying that the expected repository format was incorrect. > > > An SVN 1.0 client can checkout from an SVN 1.7 server just fine. > Obviously it will not support new features like merge tracking and tree > conflicts, but the features that existed for a 1.0 client will still work. > The same would be true for 1.1, 1.2, 1.3, 1.4. 1.5 and 1.6 clients. Heck, > I am sure there are several pre-1.0 client versions that would still work > properly. > > The only time a client would see the sort of errors you mention would be > when using the file:// protocol. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ > -- *Rob Pointer MSc* Software Specialist and Consultant rpoin...@clearvision-cm.com * Tel: +44 (0) 845 459 9530 ** ** <http://www.twitter.com/clearvisioncm> <http://www.facebook.com/clearvisioncm> <http://www.linkedin.com/company/clearvision> <http://www.clearvision-cm.com/rss-feed/clearvision-news> <http://www.clearvision-cm.com/> *
Re: svn output wrong character when set no-unicode in windows7
Justin Have you tried setting the windows command line to code page 936 (this is listed as the correct code page for simplified Chinese in Windows (see http://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx ) You should be able to set the code page using the command *cp 936* * * Rob On 17 October 2012 15:31, Justin Wu wrote: > My windows 7 is English version. > (1) installed SlikSvn-1.7.6-x64, and it output perfectly(see attached > picture) > (2) change current system Locale to Chinese for no-unicode program.(see > attached picture) > (3) svn now output wrong character (it is not English, and also it is not > Chinese), see attached picture > * *
