I've been testing Vault here with a collegue of mine. For me (locally) everything is working great, but for my partner things are going horribly wrong with the projects under source control.
Here's what we did. We're working on a set of framework level projects that we both share, but both of our solutions are actually different in that we both have different front end projects. I checked in the original set of projects with a solution of four projects. To make sure everything is in working order I went into VS.Net and opened the entire solution to a new location with Open from Source Control and all went well. I also created my 'real' working project which required pulling the four projects individually, but not the solution. For me this all seems to work ok (when pushing things into a different directory).
However, for my partner here the same steps do not work correctly. He tried to create a new solution and then add the existing projects individually. The projects opens under source control, but every single file is marked as checked out in VS.Net and the Vault client! However, it's not marked as checked out on the server (I don't see it as checked out). I can also go in and check out and edit a file no problem. Checking back in he does not see the changes even after Get Latest Version.
On his Vault client we had to go through several iterations of checking out and checking in to get things into synch. Prior to that the files where marked as unknown. But remember that this was immediately after the import.
What is going on here? <g>
+++ Rick ---
Problems with 'Unknown' files
Moderator: SourceGear
There are a few things going on here, and a few mysteries:
First of all, it would be good to figure out how the files got into an Unknown state. If a file exists on the local disk that Vault didn't retrieve, it is considered Unknown (we have on our TODO list to try to compare unknown files to the actual contents in Vault to handle this better, but that didn't make 2.0).
If your partner already had the working files on disk and simply set the working folder to that folder, instead of doing a fresh Get, the files would have been marked Unknown. This would also be the case if your partner did a Get to a non-working folder, and then set the working folder to that folder.
Files in an Unknown state can't be checked in, because Vault needs a baseline file to get a delta from (all changes between versions of files in Vault are stored using deltas, so Vault needs to know which file version the user started with). If you edit an Unknown file, it remains Unknown, since we can't tell whether it is changed or not without the baseline.
So, in general, Vault can't deal very well with Unknown files, and the only way to get rid of the Unknown status is to do Get, and overwrite the files (they will get backed up into a _sgbak folder before they are overwritten).
The second thing to be aware of is that Visual Studio itself is not very smart about how a file is checked out. Some versions of VS determine that if a file is read-write, instead of read-only, that it is checked out. It isn't really checked out in Vault, but VS thinks it is. Of course, trying to check those files in fails, since they are not really checked out.
From your symptoms, all of it could be explained if your partner started with a local version of the files that were read-write, and then set the working folder to that folder, which would explain why the files were Unknown and why VS thought they were checked out.
In any case, if your partner's files are no longer Unknown and the checkouts actually do reflect their real state now, everything *should* work normally from here on out...
First of all, it would be good to figure out how the files got into an Unknown state. If a file exists on the local disk that Vault didn't retrieve, it is considered Unknown (we have on our TODO list to try to compare unknown files to the actual contents in Vault to handle this better, but that didn't make 2.0).
If your partner already had the working files on disk and simply set the working folder to that folder, instead of doing a fresh Get, the files would have been marked Unknown. This would also be the case if your partner did a Get to a non-working folder, and then set the working folder to that folder.
Files in an Unknown state can't be checked in, because Vault needs a baseline file to get a delta from (all changes between versions of files in Vault are stored using deltas, so Vault needs to know which file version the user started with). If you edit an Unknown file, it remains Unknown, since we can't tell whether it is changed or not without the baseline.
So, in general, Vault can't deal very well with Unknown files, and the only way to get rid of the Unknown status is to do Get, and overwrite the files (they will get backed up into a _sgbak folder before they are overwritten).
The second thing to be aware of is that Visual Studio itself is not very smart about how a file is checked out. Some versions of VS determine that if a file is read-write, instead of read-only, that it is checked out. It isn't really checked out in Vault, but VS thinks it is. Of course, trying to check those files in fails, since they are not really checked out.
From your symptoms, all of it could be explained if your partner started with a local version of the files that were read-write, and then set the working folder to that folder, which would explain why the files were Unknown and why VS thought they were checked out.
In any case, if your partner's files are no longer Unknown and the checkouts actually do reflect their real state now, everything *should* work normally from here on out...
Hi Dan,
Thanks for the explanation. I was digging through the KB and messages here last night and I found a few explanations on Unknown files that clarified things but didn't help with our situation.
Before I go into that maybe I should show my ignorance here and ask a very basic question. I have a feeling that we possibly are doing something that VS (or Vault) isn't handling the way we think it should <g>.
The original project I checked in was a solution with 4 subprojects. After checkin we both create new Solutions in VS, then add a couple of new projects (not under source control - private to each of us). Then we go in and pull in two or three of the projects that I originally placed under source control. IOW, we're not using the original solution, but projects out of that original solution.
We both tried this in a number of different ways. Using Add Project From Source Control (creating a brand new directory for the files) or by pointing at the existing project that is already under source control on our local disks.
In either situation the project comes into VS.Net with all files checked out and Vault showing files either as Missing or Unknown (and the project usually showing Renegade).
Now, after some suggestions from others who use Vault, we've taken each project and dumped it into its own solution and that seems to work properly for the most part.
However, now *I* have problems with some of the projects not wanting to add to a new solution. I get different errors depending on how many times I try <g>. The first is:
The project 'Project Name' is under source control. An error occurred registering this project with source control. It is recommended you do not make any changes this project.
Second try will then yield:
The folder 'D:\projects\Mere Mortals .NET Framework\Mere Mortals Framework Windows Forms' cannot be used for the solution or project you are trying to open because it is already in use to store part of another solution or project.
If I then go into Vault I notice that several files are missing. I have to go Get Latest Version and delete the source control files out of the original project directory (don't ask - I'm not sure of the exact steps after x number of tries here), THEN I can add the project.
Any ideas what are causing these conflicts above? This time around my partner has absolutely no problems reading in the projects. The only difference is that my projects are the original ones that were added to source control and I'm always pointing back to those original directories for the working folder.
I have everything working now, but this has not been a fun nor consistent experience to get rolling.
BTW, it'd be nice if you'd fix the Working Folder selection dialog that comes up for Working Path to show the already selected directory <g>...
+++ Rick ---
Thanks for the explanation. I was digging through the KB and messages here last night and I found a few explanations on Unknown files that clarified things but didn't help with our situation.
Before I go into that maybe I should show my ignorance here and ask a very basic question. I have a feeling that we possibly are doing something that VS (or Vault) isn't handling the way we think it should <g>.
The original project I checked in was a solution with 4 subprojects. After checkin we both create new Solutions in VS, then add a couple of new projects (not under source control - private to each of us). Then we go in and pull in two or three of the projects that I originally placed under source control. IOW, we're not using the original solution, but projects out of that original solution.
We both tried this in a number of different ways. Using Add Project From Source Control (creating a brand new directory for the files) or by pointing at the existing project that is already under source control on our local disks.
In either situation the project comes into VS.Net with all files checked out and Vault showing files either as Missing or Unknown (and the project usually showing Renegade).
Now, after some suggestions from others who use Vault, we've taken each project and dumped it into its own solution and that seems to work properly for the most part.
However, now *I* have problems with some of the projects not wanting to add to a new solution. I get different errors depending on how many times I try <g>. The first is:
The project 'Project Name' is under source control. An error occurred registering this project with source control. It is recommended you do not make any changes this project.
Second try will then yield:
The folder 'D:\projects\Mere Mortals .NET Framework\Mere Mortals Framework Windows Forms' cannot be used for the solution or project you are trying to open because it is already in use to store part of another solution or project.
If I then go into Vault I notice that several files are missing. I have to go Get Latest Version and delete the source control files out of the original project directory (don't ask - I'm not sure of the exact steps after x number of tries here), THEN I can add the project.
Any ideas what are causing these conflicts above? This time around my partner has absolutely no problems reading in the projects. The only difference is that my projects are the original ones that were added to source control and I'm always pointing back to those original directories for the working folder.
I have everything working now, but this has not been a fun nor consistent experience to get rolling.
BTW, it'd be nice if you'd fix the Working Folder selection dialog that comes up for Working Path to show the already selected directory <g>...
+++ Rick ---
This is all very mysterious.
There shouldn't be a problem with adding projects under source control to a personal solution. I just re-checked this here to make sure, and it worked in the simple cases I tried.
One question: Did you add the projects to Vault via Visual Studio, or manually through the Vault GUI client? If you added them via the Vault GUI client, it is possible that you added some files that shouldn't be in source control (such as the mssccprj.scc files or the .user files).
If not, can you recreate what happened by creating some dummy projects and solutions, and retracing the exact commands that were invoked at each steps and from where (e.g., from VS or Vault GUI client). Then I could try to recreate that here and see what I find.
If you are up and running, and all seems fine, it might be better to leave things lie at this point though
Visual Studio configuration with source control can be very persnickity, so once it is working, it is best not to push one's luck...
There shouldn't be a problem with adding projects under source control to a personal solution. I just re-checked this here to make sure, and it worked in the simple cases I tried.
One question: Did you add the projects to Vault via Visual Studio, or manually through the Vault GUI client? If you added them via the Vault GUI client, it is possible that you added some files that shouldn't be in source control (such as the mssccprj.scc files or the .user files).
If not, can you recreate what happened by creating some dummy projects and solutions, and retracing the exact commands that were invoked at each steps and from where (e.g., from VS or Vault GUI client). Then I could try to recreate that here and see what I find.
If you are up and running, and all seems fine, it might be better to leave things lie at this point though
Visual Studio configuration with source control can be very persnickity, so once it is working, it is best not to push one's luck...