Re: Problem with code page on Windows XP SP3
On Oct 30, 2010, at 2:56 PM, Paul Maier wrote: > Hello, > > who has advice for the following problem on a DOS console of a Windows XP SP3 > machine. > "svn cat" doesn't display German umlaut characters (neither does Windows' > built in type command). > Whereas a "svn cat > b; cat b" (cat command comes from cygwin) displays > correctly. I don't know if this will work, but you might try doing a "chcp 1252" before "svn cat". > C:...\yy>cat a > äöü ÄÖÜ ß § -- abcd1234 > C:...\yy>svn cat a > õ÷³ -Í_ ¯ º -- abcd1234 ä is at code point 0xE4 in CP1252. In your CP850, 0xE4 is õ ö is at code point 0xF6 in CP1252. In CP850, 0xF6 is ÷ etc...
Re: AW: Problem with code page on Windows XP SP3
On Oct 30, 2010, at 3:43 PM, Paul Maier wrote: > Hello David, > > thank you! I have added "chcp 1252" at the top of my script > and the result is strange. I attach a screen shot to this > mail - hopefully it makes through the list. > > With "chcp 1252" it's like this: > > 1. output on the console (black window) is same than before > > 2. When I copy the content out of the console into an > Elvis editor (vi for Windows; white window), then > the caracters I get in vi are not the ones that I've copied. > See screen shot. > More strange: The unreadable wrong characters on the console > turn into the right German umlauts in vi. > And the correct characters from the console turn into > black rectangles in vi. Interesting and very strange :) Perhaps also try changing the font that you're using in the console window to a Truetype font (like Lucida Console). I think the Command Prompt raster fonts only support the default OEM code page. I suspect that this will make the "svn cat" output work properly, but will break the Cygwin cat output :(
Re: Feature request: Support of Windows Codepage 850
On Oct 31, 2010, at 1:35 PM, Paul Maier wrote:
> Hi there!
>
> All output, that comes from the svn internationalization, shows correctly
> on both codepages, 850 and 1252. E. g. error messages or "svn help ci". Good.
> (Font in use is Lucida Console.)
>
> This shows, that it *is* possible for svn, to produce correct output on both
> codepages, 850 and 1252.
>
> But output that comes from file data ("svn cat file") only prints correct with
> Codepage 1252. Seems, that this output goes through a different piece of code,
> that is not able to adjust to the Codepage in use.
svn cat just outputs the file that's in the repository... if your file happens
to be a a CP1252-encoded text file, but your console expects CP850, I don't
think you should expect it to display properly. And how would svn even know
that the file is a CP1252-encoded text file? While it does keep track of the
MIME type, it doesn't keep track of charset encoding... perhaps I have a
Chinese BIG5-encoded file in my repo; if SVN assumed it was CP1252 and tried to
do a 1252->850 conversion on it, it'd corrupt the file.
I think svn cat just needs to output the exact bytes of the file, rather than
trying to do any conversion. If you want to do charset conversion, you could
probably just pipe the output through iconv (available in Cygwin). E.g., svn
cat filename | iconv -f cp1252 -t cp850
> (I have to use Codepage 850, because Cygwin needs it.)
I haven't tried it myself, but my understanding is that Cygwin 1.7 honors the
locale environment variables. Perhaps try "set LC_CTYPE=de_DE.CP1252" or
perhaps one of the other locale variables (LANG? LC_ALL?)
Re: SVN 1.6.15 checkout fails on particular file
On Jan 14, 2011, at 2:19 PM, KARR, DAVID (ATTSI) wrote: > I then looked at the full local path this file would represent, and the > entire path is 260 characters long. I would think if there's any threshold, > it would be at 255, not 259. > > Any idea what's going on here? The usual maximum path length limit on Windows is indeed 259 (or 260 if you count the terminating NUL): See the "Maximum Path Length Limitation" section of http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 34 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: SVN 1.6.15 checkout fails on particular file
On Jan 14, 2011, at 6:31 PM, KARR, DAVID (ATTSI) wrote: > I'm not sure what you mean. You're saying that Subversive in Eclipse is > referencing absolute paths, but using the command line client is using > relative paths? Assuming that's the distinction, is there some way I > could use the command-line client in a different way that might avoid > this problem? The SVN library used by the commandline client uses the Apache Portable Runtime library (apr), which IIRC, uses the special "\\?\" prefix when needed to support long pathnames. I don't know much about Subversive, but perhaps it doesn't do that trick? P.S. Your mail server (att.com?) doesn't seem to like me :( At least my first email to you was bounced back by MessageLabs saying there was something wrong with the content. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: svn status comes out empty
On Feb 14, 2011, at 9:57 PM, Andy Levy wrote: > Make sure that your find/sed combo is excluding .svn directories (for > some reason, I'm not able to run it on OS X). If you modify both the > "visible" file in the working copy AND the pristine copy of it, > Subversion won't detect the change. FWIW, the find/sed combo doesn't run on OS X because 1) the find is missing the mandatory "path" argument (apparently GNU find has a non-standard extension to default path to "." if not present), and 2) standard sed has no "-i" option; again, GNU sed added it as an extension. Looks like OS X sed has the same extension, but did it slightly differently. The OS X equivalent to GNU's sed -i is sed -i "". But it would be nice if repro scripts in bug reports stuck with the standards in order to avoid these issues. (And yes, as you and others have mentioned, the reason svn status thinks that nothing has changed is because the find went into the .svn directory and made an identical change to the base copy of the file too). -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: SVN always thinks a few certain files need to be merged
On Mar 23, 2011, at 7:52 PM, Pat Farrell wrote: > On 03/23/2011 08:34 PM, Konstantin Kolinko wrote: >> You are not giving much specifics, so how can people know what is going on >> in your case? > > Specifics for complete 100% reproducable problem: > > do svn update for whole project > create branch from trunk > change one source file, not the one with the bogus mergeinfo, commit it. > merge branch back to trunk > > before you commit the trunk, do a svn status > You will see the bogus mergeinfo listed as a change to the trunk. If you're sure that the mergeinfo is bogus, why not just delete it? e.g., svn propdel svn:mergeinfo fnfapp/src/java/com/fnfbook/bean/FilterListBase.java http://www.collab.net/community/subversion/articles/merge-info.html might be worth a read too. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: Question about excessive mergeinfo
On Jan 9, 2010, at 7:58 AM, Geoff Rowell wrote: > I follow a few rules to avoid this: > 1) Remove obsolete merge info as part of the branch creation process > (svn pd -R svn:mergeinfo /my/branch). I don't do that regularly (but have done it once or twice), but from my understanding, that fixes the "problem"/annoyance where existing subtree mergeinfo gets updated every time a merge is done, even if the merge doesn't affect the files with mergeinfo. That's not the same issue as what I'm seeing though; in my case, mergeinfo is being created on files that didn't have it before. > 2) Only allow recording of merge info at the root level. This means > that all merges must take place to and from the root of branches and > the trunk. (In fact, a pre-commit hook prevents saving merge info > anywhere else.) I do always merge at the root. > 3) Remove merge info from trunk when a branch is no longer under > active development. This also seems to address the issue of updates on existing mergeinfo, but not creation of new mergeinfo.
Re: Question about merging
So, I'm doing another merge between two trees, and ran into this issue again, which reminded me that I never did get any info about what's going on... To summarize, my repo looks something like this: trunk -> branch1 -> branch1.1 | '> branch2 I have a WC containing a checkout of branch2, and in that WC, I'm doing: svn merge https://my.repo/branches/bran...@somerev https://my.repo/branches/branch1.1 The merge shows a bunch of files being "U"pdated, but those files haven't changed between branch1 and branch1.1, and indeed, despite the U lines, after the merge is done, those files in my WC aren't modified. And this time, there's something new: I'm getting conflicts on some files that are identical between branch1 and branch1.1. There's no mention of those files in a svn diff https://my.repo/branches/bran...@somerev https://my.repo/branches/branch1.1 (not even property changes) , yet there's a conflict when merging? How is that possible? The files in question are all binary files, if that makes a difference. The docs imply that a merge is the equivalent of getting a diff and applying it, but that doesn't seem to be the case exactly, since the merge is trying to touch files that aren't mentioned in the diff. I've tried this with both commandline svn 1.6.5 and TortoiseSVN 1.6.10--same results. On Dec 15, 2009, at 5:33 PM, Dave Huang wrote: > On 12/15/2009 4:11 PM, Ryan J Ollos wrote: >> David Huang-5 wrote: >>> >>> So, I tried doing that, and I think it mostly worked, but a lot of files >>> were unexpectedly shown as "Updated"--I have no idea why they show up in >>> the >>> merge, since they haven't been modified between branch1 and branch1.1. It >>> seems to be harmless though; even though merge shows them as Updated, >>> they're not actually modified in the WC after the merge is done. >>> >> >> Pay close attention to whether the files are shown as having text >> modifications or property modifications. It is very likely that just the >> mergeinfo or another property on the files has changed. > > Both text modifications and property modifications will cause the file to be > flagged as modified (e.g., with the "modified" overlay icon, or since that's > not always reliable, in the "Check for modifications" window)--in this case, > the overlay remained the "normal" one, and Check for modifications confirmed > that neither the text nor properties were modified on many of the files > listed as "Updated". -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 34 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: Question about merging
On Sep 17, 2010, at 12:38 PM, Bob Archer wrote: > It is updating/writing merge info on those child nodes. There must have been > a merge that was done at a level lower than the root folder of your project > which put merge info on those files but not on the parent root folder. > > What is the mergeinfo before you do your merge and after you do your merge on > one of those files where the merge info is being updates but the files are > not modified? There's no mergeinfo on the files in question either before or after the merge... and as mentioned, after the merge, neither the text nor properties of the supposedly-updated files are shown as modified. BTW, on the binary files that are conflicted after the merge, the .merge-left and .merge-right files are identical. I.e., I see no conflict; it should've just used one of them.
Re: Question about merging
On Sep 17, 2010, at 12:38 PM, Bob Archer wrote: > It is updating/writing merge info on those child nodes. There must have been > a merge that was done at a level lower than the root folder of your project > which put merge info on those files but not on the parent root folder. A more concrete example: hexley-wl:~ khym$ svn co https://my.repo/svn/branches/dave-calendar72 [ ... ] hexley-wl:~ khym$ cd dave-calendar72 hexley-wl:dave-calendar72 khym$ svn merge --accept postpone https://my.repo/svn/branches/7...@28161 https://my.repo/svn/branches/dave-calendar71 --- Merging differences between repository URLs into '.': [ ... ] ULoadDB/LoadDB.cpp [ ... ] CReports/Invoice.rpt [ ... ] Summary of conflicts: Text conflicts: 491 Tree conflicts: 5 # So, a .cpp was supposedly updated, and an .rpt was supposedly conflicted hexley-wl:dave-calendar72 khym$ svn proplist https://my.repo/svn/branches/7.1/LoadDB/loaddb@28161 https://my.repo/svn/branches/dave-calendar71/LoadDB/LoadDB.cpp LoadDB/LoadDB.cpp Properties on 'https://my.repo/svn/branches/7.1/LoadDB/LoadDB.cpp': svn:keywords Properties on 'https://my.repo/svn/branches/dave-calendar71/LoadDB/LoadDB.cpp': svn:keywords Properties on 'LoadDB/LoadDB.cpp': svn:keywords # No mergeinfo on that file, in any of the places that are involved in the merge. Doing the same thing for Invoice.rpt shows that the only property is svn:mime-type. hexley-wl:dave-calendar72 khym$ svn diff https://my.repo/svn/branches/7.1/LoadDB/loaddb@28161 https://my.repo/svn/branches/dave-calendar71/LoadDB/LoadDB.cpp hexley-wl:dave-calendar72 khym$ svn diff https://my.repo/svn/branches/7.1/Reports/invoice@28161 https://my.repo/svn/branches/dave-calendar71/Reports/Invoice.rpt # And svn diff shows that there are neither any text differences or property differences. hexley-wl:dave-calendar72 khym$ svn stat LoadDB/LoadDB.cpp Reports/Invoice.rpt C Reports/Invoice.rpt # Finally, svn stat shows that there are no modifications to my WC's LoadDB.cpp, despite the merge supposedly updating it. However, Invoice.rpt really is conflicted.
Re: Best way to "un-version control" a file?
On Sep 22, 2010, at 8:21 PM, Chris Albertson wrote: > But, I did not think until now that I should have excluded files such > as core files and logs and autoconf's cache from version controls. I > now know how to a global ignore and a ignore foe one directory but how > to remove these files from version control once they are already > there. Is "svn rm" the best why? But that will remove them from > the working directory too. I don't want that. svn rm --keep-local filename > Next is these a way to make the ignore property for a directory apply > to all sub dirs recursively. The next project I want to move to svn > is much larger and has many nested directories svn propset --recursive svn:ignore ignorepattern . -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 34 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: Best way to "un-version control" a file?
On Sep 23, 2010, at 6:40 AM, Nico Kadel-Garcia wrote: > On Thu, Sep 23, 2010 at 12:43 AM, David Huang wrote: >> >> On Sep 22, 2010, at 8:21 PM, Chris Albertson wrote: >>> But, I did not think until now that I should have excluded files such >>> as core files and logs and autoconf's cache from version controls. I >>> now know how to a global ignore and a ignore foe one directory but how >>> to remove these files from version control once they are already >>> there. Is "svn rm" the best why? But that will remove them from >>> the working directory too. I don't want that. >> >> svn rm --keep-local filename > > Which is thoughtful, but does *NOT* get old versions of the file out > of the repository. True, but Chris didn't say that was a requirement... he just wants to "remove them from version control", but not "remove them from the working directory too". In which case, rm --keep-local sounds like exactly what he wants. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 34 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
Re: Best way to "un-version control" a file?
On Sep 24, 2010, at 12:17 AM, Nico Kadel-Garcia wrote: > On Thu, Sep 23, 2010 at 11:18 PM, Daniel Shahaf > wrote: >> Les Mikesell wrote on Thu, Sep 23, 2010 at 12:27:40 -0500: >>> Am I wrong in thinking that similar accidents happen to everyone >>> eventually and that a feature to fix them would be desirable? >> >> Yes, the feature has its use case. And if you'd like to see it >> implemented yesterday, that's cool. Just don't assume that everyone >> thinks the same way please. > > Can you actually name anyone who thinks it's not a useful, or > potentially useful feature? Anyone? I suspect what was meant is that not everyone thinks obliterate needs to be "implemented yesterday" or that it's the "#1 request". I do think obliterate would be useful, but I personally have not ever needed it in my 2 or 3 years of administering an SVN repo, and don't forsee needing it in the future. Also, it's not like the SVN team has rejected the feature; the FAQ mentions that it's planned: http://subversion.apache.org/faq.html#removal and there's even a roadmap for it: https://svn.apache.org/repos/asf//subversion/trunk/notes/obliterate/plan-milestones.html
Re: filename encodings and conversion failure
On 12/30/2022 4:40 PM, Karl Berry wrote: Well my point is that this would not work everywhere. How can "store as bytes" not work (be implementable?) everywhere? I'm missing something. I seem to remember an earlier message in the thread mentioning Windows... where filenames are natively UTF-16LE, and the various file/path API functions have a "wide character" version that takes a UTF-16LE-encoded filenames, and an "ANSI" version that will convert single-byte/multi-byte charset filenames to/from UTF-16LE (where the source encoding is generally determined by a system-wide setting; e.g., in the US, most systems would be using Windows-1252, which is similar to ISO 8859-1, although not identical. And Japanese systems would probably be set to use Windows-932, which is basically Shift-JIS). So if SVN on Windows used the UTF-16 APIs and "stored as bytes", it'd be incompatible with *nix: a *nix README file, 0x52 0x45 0x41 0x44 0x4d 0x45 would turn into U+4552 U+4441 U+454D, or 䕒䑁䕍 in Windows. And what happens with filenames that are an odd number of bytes long? Or in the other direction, a README file committed from Windows couldn't be checked out on *nix because 0x52 0x00 0x45 0x00 etc would appear to contain NUL characters from the *nix POV. And if SVN on Windows used the single-byte charset APIs, the README example would work, but any filenames with non-ASCII characters would either change depending on the system-wide locale setting, or perhaps not be able to be checked out at all. So as a Windows user, I think it's good that SVN converts filenames by default. That said, perhaps it would be useful to have an svn: property or something that says not to do any conversion on this filename. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: k...@azeotrope.org | they raise a paw / the bat, the cat / | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 47 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
