Search Results

Search found 2 results on 1 pages for 'user72150'.

Page 1/1 | 1 

• recent cvs cygwin newline windows problems. How to solve?

  - by user72150

  Hi all, One of our projects still uses CVS. Recently (sometime in the past year) the Cygwin cvs client (currently using 1.12.13) has given me problems when I update. I suspect the problem stems from windows/unix newline differences. It worked for years without a problem. Here are the symptoms. When I update from the command line, I see messages like these: "no such repository" messages /cvshome : no such repository False-"Modified" due to newline differences M java/com/foo/ekm/value/EkmContainerInstance.java False-"Conflicts" cvs update: Updating java/com/foo/ekm/value/XWiki cvs update: move away `java/com/foo/ekm/value/XWiki/XWikiContainerInstance.java'; it is in the way C java/com/foo/ekm/value/XWiki/XWikiContainerInstance.java Note the for the 'no such repository' error, I found that cd-ing into the 'CVS/' folder and running 'dos2unix Root' updates correctly. I'm not sure how this file (or Repository or Entries) gets whacked. I don't remember when these problems started. I have a workaround: updating from our IDE (Intellij Idea) always succeeds Yes, I know we should switch to (svn|git|mercurial), but does anyone know what causes these problems? when they were introduced? workarounds? thanks, bill

  Read the article

• doublechecking: no db-wide 'unicode switch' for sql server in the foreseeable future, i.e. like Orac

  - by user72150

  Hi all, I believe I know the answer to this question, but wanted to confirm: Question Does Sql server (or will it in the foreseeable future), offer a database-wide "unicode switch" which says "store all characters in unicode (UTF-16, UCS-2, etc)", i.e. like Oracle. The Context Our application has provided "CJK" (Chinese-Japanese-Korean) support for years--using Oracle as the db store. Recently folks have been asking for the same support in sql server. We store our db schema definition in xml and generate the vendor-specific definitions (oracle, sql server) using vendor-specific xsl. We can make the change easily. The problem is for upgrades. Generated scripts would need to change the column types for 100+ columns from varchar to nvarchar, varchar(max) to nvarchar(max), etc. These changes require dropping and recreating indexes and foreign keys if the any indexes/fk's exist on the column. Non-trivial. Risky. DB-wide character encodings for us would eliminate programming changes. (I.e. we would not to change the column types from varchar to nvarchar; sql server would correctly store unicode data in varchar columns). I had thought that eventually sql server would "see the light" and allow storing unicode in varchar/clob columns. Evidently not yet. Recap So just to triple check: does mssql offer a database-wide switch for character encoding? Will it in SQL2008R3? or 2010? thanks, bill

  Read the article

1