Modified files immediately after checkout.

[ShadowSpawnOFCS]

I'm running Vault 3.5.1.4786 (client). I have imported a large chunk of code into the repository. However, when I do a checkout, I get files immediately showing as modified.

In my options:

• Local Files -> Detect modified files using CRCs instead of modification times
  Local Files -> Unchecked the limitation on the size of files for CRC check.
  Local Files -> Cache/Backup Locations -> Store Working Folder State/Baseline Files -> In Working Folders
  Concurrent Development Style -> CVS Style

I go to the root of my repository ($) and set the current working folder, allowing it to create a new folder as prompted (folder does not exist to start). I then do a "Get Latest Version". I set File Time to Modification and Make all files writable (the rest seem irrelevant for a new checkout). Then I wait (~150M repository takes a bit.

As soon as it completes the "Get Latest Version" I have a pending action list with dozens of modified files (115 to be specific). If I do a "diff" on the files, they show no differences. Some do indicate a size change, others say "Size Unchanged". They seem to be mostly .disco files if that has any relevance (though not exclusively), though there are a handful each of readme.txt, *.sql, *.cs, and *.aspx files. I can then commit the files.

Any ideas why, on a fresh checkout before touching anything, using CRC checks, why Vault thinks I've modified the files, and then why I can check in the changes and clear the list?

[Beth]

Are you using IDE integration? If so, the working folder is set through VS, not Vault and will cause confusion if both are set.

The other possibility is if you set the working folder to where the original files were. I ran a check and don't naturally get a renegade status.

[ShadowSpawnOFCS]

I'm actually not using any IDE yet; I'm trying to import a source tree from a contractor, so I'm going directly through the Vault Client GUI. Is there a setting I may have overlooked that would cause Vault to strip unicode characters (and Byte Order Marks potentially) and thus see differences in the files that don't display in the diff window?

[GregM]

Sounds like a difference in the end-of-line characters. Did these files come from a unix machine to a windows machine?

[jclausius]

I'm actually not using any IDE yet; I'm trying to import a source tree from a contractor, so I'm going directly through the Vault Client GUI. Is there a setting I may have overlooked that would cause Vault to strip unicode characters (and Byte Order Marks potentially) and thus see differences in the files that don't display in the diff window?

Are the files missing this on a GET or are you seeing this with Diff/Merge? If you are only looking at the files through Diff/Merge, then check the Diff/Merge tool's options check to see what character sets are configured.

[ShadowSpawnOFCS]

Sounds like a difference in the end-of-line characters. Did these files come from a unix machine to a windows machine?

Should all be Windows Source, but it does seem related to special characters.

[ShadowSpawnOFCS]

Are the files missing this on a GET or are you seeing this with Diff/Merge? If you are only looking at the files through Diff/Merge, then check the Diff/Merge tool's options check to see what character sets are configured.

Some of the files are UTF-8 including BOM, so I would tend to think I should use Unicode. However, some are ANSI 1252 and have non-iso-8859-1 characters. Will running Unicode with the default options handle 1252 as well, or is there something else I'd need to add to the list (iso-8859-1 and some Windows 1252 equivalent?)

I'm hoping to experiment on my own too, but help is appreciated With the anemic test environment I'm using it takes a couple hours to import the entire code base (SQL, IIS/Vault, Windows XP on a Pentium M laptop; quite a testament for the product that it performs as well as it does on that setup ).

[ShadowSpawnOFCS]

Some of the files are UTF-8 including BOM, so I would tend to think I should use Unicode. However, some are ANSI 1252 and have non-iso-8859-1 characters. Will running Unicode with the default options handle 1252 as well, or is there something else I'd need to add to the list (iso-8859-1 and some Windows 1252 equivalent?)

I'm hoping to experiment on my own too, but help is appreciated With the anemic test environment I'm using it takes a couple hours to import the entire code base (SQL, IIS/Vault, Windows XP on a Pentium M laptop; quite a testament for the product that it performs as well as it does on that setup ).

Okay, finally made a copy of the tree before the import, the tree after the import, and the tree after a clean checkout.

The ones that grow seem to be from bogus end of line characters which I had previously set to override; that's as it should be (don't know why they were wrong in the first place but I do want them fixed so that's as it should be).

However, there are 53 that shrink because the have Windows 1252 characters in them (0x91, 0x95, etc). When I import them they seem to import correctly (at least, my digging indicates a proper data size), but checking out the files always strips the extra characters, so the file changes and shrinks. (Yes, most of these characters shouldn't be in these files in the first place and I plan to clean them up, but until I look more closely, I can't be sure that's an option).

Is there a way to tell Vault to accept files with those characters and to keep/include them even on a checkout? Is there a relatively easy way to get at the raw data stored in the database to verify that it has been stored correctly?

[ShadowSpawnOFCS]

I uninstalled my test Vault and reinstalled it. I went through and recreated the repository using the same script, imported the same code, and reset my options the same as they were before as far as I can tell (except for setting it not to override EOL), and now it works, successfully preserving the special characters. I don't recall doing anything differently on the server install, so unless somehow overriding EOL was doing it, the reinstall fixed it.