I am evaluating Vault for purchase as our company's SCC system. I have installed it on a stand alone network with two computers, the client on my development computer and the server on a Windows 2000 Professional computer hosting SQL Server 2000.
I read the similarly titled thread with interest, hoping it would answer my questions - unfortunately not. I am having similar problems. Here is the problem as succinctly as possible:
I am trying to follow the Microsoft recommendations for file system and VSS project structure, as described in 'Team Development with Visual Studio .NET and Visual Source Safe' (available from the Microsoft Patterns & Practices web site). They recommend the following:
File System:
\Projects <- root projects folder
\Projects\Product1 <- root product folder
\Projects\Product1\MyWinAppSolution <- solution folder
\Projects\Product1\MyWinAppSolution\MyWinApp1 <- project folder 1
\Projects\Product1\MyWinAppSolution\MyWinApp2 <- project folder 2
\Projects\Product2
\Projects\Product2\WinAppSolution2
\Projects\Product2\WinAppSolution2\MyWinApp3
etc.
VSS Project Structure:
$/Projects
$/Projects/Product1
$/Projects/Product1/MyWinAppSolution
$/Projects/Product1/MyWinAppSolution/MyWinApp1
$/Projects/Product1/MyWinAppSolution/MyWinApp2
$/Projects/Product2
$/Projects/Product2/WinAppSolution2
$/Projects/Product2/WinAppSolution2/MyWinApp3
etc.
VS.NET works fine with this structure (of course). However, I have been unable to achieve this folder structure in my Vault repository. I've tried a variety of different things, most of which end up with several levels of redundant folders, like:
$/Projects/Product1/SolutionName/ProjectName/Product1/SolutionName/ProjectName.
Is there something obvious I'm overlooking? Should Vault be able to accomodate this Microsoft recommended folder structure? If so, I'd greatly appreciate any (detailed) guidance you can provide on how I can accomplish it. If not, do you have a recommend alternative folder structure? I have to admit that after spending most of today banging my head against this wall, I'm feeling pretty frustrated.
BTW - the article I cited above is a really great article on using VS.NET with source control, and it's very clear about using VS.NET for adding solutions to source control so only the necessary files get added. It is obviously slanted towards VSS, but the principles apply to using VS.NET with any SCC system. I highly recommend it for anyone considering using VS.NET with your products.
I mention this because Microsoft clearly encourages using the VS.NET IDE as much as possible for interacting with the SCC system. Your documentation does a good job of documenting your client interface, but does not provide much help at ALL for using the VS.NET integrated features. You guys may be experts at SCC and at using the VS.NET SCC features, but some of us are not. FWIW - I'd recommend you enhance your client documentation to provide more detailed coverage in this area.
Another request for solution / project heirarchy guidance
Moderator: SourceGear
An IDE integration article is on the way, and your post makes it all the more important to finish it.
Vault should handle the same structure as VSS. Did you add the whole solution to Vault, or add it project by project? Or, did you unbind the solution from VSS and then add it to Vault?
When you add a solution or a project, Vault will ask you to login, choose a repository, and then a Vault folder chooser dialog will be displayed, which shows exactly where the solution/project will be placed (change the "Vault Folder" textbox to choose the project's root name, and select a project in the folder tree, and the "Choose Folder" box will show where the solution will be placed.
After that, the IDE creates whatever folders underneath that folder it needs to for the solution tree. Is it possible that you manually created "$/Projects/Product1/SolutionName/ProjectName", and then chose that as the root node of your solution, and then the IDE created "Product1" and below again?
From Vault's point of view, we just ask the user for the root node of where to place the solution/project, and the IDE tells us where to create everything below that. This isn't clear, of course, which is why we need to get that article finished.
Vault should handle the same structure as VSS. Did you add the whole solution to Vault, or add it project by project? Or, did you unbind the solution from VSS and then add it to Vault?
When you add a solution or a project, Vault will ask you to login, choose a repository, and then a Vault folder chooser dialog will be displayed, which shows exactly where the solution/project will be placed (change the "Vault Folder" textbox to choose the project's root name, and select a project in the folder tree, and the "Choose Folder" box will show where the solution will be placed.
After that, the IDE creates whatever folders underneath that folder it needs to for the solution tree. Is it possible that you manually created "$/Projects/Product1/SolutionName/ProjectName", and then chose that as the root node of your solution, and then the IDE created "Product1" and below again?
From Vault's point of view, we just ask the user for the root node of where to place the solution/project, and the IDE tells us where to create everything below that. This isn't clear, of course, which is why we need to get that article finished.
-
Guest
More info on my travails...
Well, after spending another 1/2 day working with Vault and VS.NET, not only have I become expert at undoing by hand the changes made to project files and file attributes by adding a solution to source control, but I think I have finally gotten things figured out and added to my Vault repository successfully!!!!!
I think the key component I was leaving out was deleting and recreating the repository each time I went through a 'cycle' of experimentation. Things started working much more repeatably once I started doing that.
When you initially add the solution to source control, the dialog is kind of tricky. First, don't accept the Vault Folder name it suggests. I cleared it out and left it blank, and FINALLY got the folder structure in VAULT that I was looking for. Also, the Working Folder is apparently meaningless, because it always says 'c:\', even though after the solution is added to VAULT, this is NOT the working folder. When you subsequently check out a file, it is checked out to the project folder, not to 'c:\'. I don't know how VAULT determines or uses this working folder, but it is VERY confusing. Overall, this dialog could use MAJOR IMPROVEMENT. It is very, very difficult to determine what folder structure will be created in VAULT based on what you enter in this dialog, and once you click OK and everything is committed to VAULT, changing the folder structure is extremely time consuming and painful!!!
The other very confusing thing I ran into is the Change Source Control dialog. When you first bring up this dialog, the Status column shows 'Invalid' for every Solution/Project. If you click the Refresh button on the toolbar (and it is not obvious that this IS a toolbar), the status changes briefly to 'Unknown' then to 'Valid'. The Server Binding column always displays <Unable to Display>, and I have no idea what this means, but it appears that VAULT is working as expected, so I'm not sweating it. However, if you are having problems getting things to work and you bring up this dialog, the information it provides misleads you to believe that there are problems when, apparently, there are not.
One last complain is that it is not obvious how to install just the client component. The MSI installer downloaded from your web site wants to install both the server and the client pieces, and I could not figure out how to get that installer to install just the client component. I had to search around on the server computer to find the client install MSI. Did I miss something in the documentation or readme that described how I was supposed to find this installer?
I really like the product concept and the fact that VAULT uses standard, stable components such as SQL Server 2000 and IIS, as well as the fact that it uses web services and managed code. It has characteristics that I need, such as the ability to access the source code repository remotely via the internet. It is reasonably priced and it seems there are plans to release a collaborative version that integrates bug tracking. However, there are still some rough edges and it is a difficult product to set up. I figured it out because I am a senior level developer with a couple of decades of experience muddling through these types of things and because I have a large dose of stubbornness. I suspect other less experienced (or stubborn) folks might not have been so successful. You guys are really close to a great product. I hope you address these things that I found so frustrating.
I think the key component I was leaving out was deleting and recreating the repository each time I went through a 'cycle' of experimentation. Things started working much more repeatably once I started doing that.
When you initially add the solution to source control, the dialog is kind of tricky. First, don't accept the Vault Folder name it suggests. I cleared it out and left it blank, and FINALLY got the folder structure in VAULT that I was looking for. Also, the Working Folder is apparently meaningless, because it always says 'c:\', even though after the solution is added to VAULT, this is NOT the working folder. When you subsequently check out a file, it is checked out to the project folder, not to 'c:\'. I don't know how VAULT determines or uses this working folder, but it is VERY confusing. Overall, this dialog could use MAJOR IMPROVEMENT. It is very, very difficult to determine what folder structure will be created in VAULT based on what you enter in this dialog, and once you click OK and everything is committed to VAULT, changing the folder structure is extremely time consuming and painful!!!
The other very confusing thing I ran into is the Change Source Control dialog. When you first bring up this dialog, the Status column shows 'Invalid' for every Solution/Project. If you click the Refresh button on the toolbar (and it is not obvious that this IS a toolbar), the status changes briefly to 'Unknown' then to 'Valid'. The Server Binding column always displays <Unable to Display>, and I have no idea what this means, but it appears that VAULT is working as expected, so I'm not sweating it. However, if you are having problems getting things to work and you bring up this dialog, the information it provides misleads you to believe that there are problems when, apparently, there are not.
One last complain is that it is not obvious how to install just the client component. The MSI installer downloaded from your web site wants to install both the server and the client pieces, and I could not figure out how to get that installer to install just the client component. I had to search around on the server computer to find the client install MSI. Did I miss something in the documentation or readme that described how I was supposed to find this installer?
I really like the product concept and the fact that VAULT uses standard, stable components such as SQL Server 2000 and IIS, as well as the fact that it uses web services and managed code. It has characteristics that I need, such as the ability to access the source code repository remotely via the internet. It is reasonably priced and it seems there are plans to release a collaborative version that integrates bug tracking. However, there are still some rough edges and it is a difficult product to set up. I figured it out because I am a senior level developer with a couple of decades of experience muddling through these types of things and because I have a large dose of stubbornness. I suspect other less experienced (or stubborn) folks might not have been so successful. You guys are really close to a great product. I hope you address these things that I found so frustrating.
Thanks for the update, and for the fair assessment of our setup. Yes, it is kind of a double-edge sword. Using standard components has great advantages, but the major downside is loss of control over setup issues - we are at the mercy of IIS/SQL/VS.Net, and getting these configured is sometimes very tricky. Luckily, it is usually only one person that has this setup headache, and the rest of the team only has to install clients, which is far easier.
Other issues:
1. We do have a client-only installer, but you may not have downloaded it. It is at: http://www.sourcegear.com/vault/downloads.asp (box that says client). Also, a little known feature of Vault allows you to install the client from your installed server: Go to http://yourvaultmachine/VaultService, and there should be a link there to the client installer, that you can use for deployment.
2. I think we will re-arrange that folder selection dialog to make it more clear what is going on. Also, if you were getting "c:\" as your working folder, and finally got it to work, that's great. We just had a report of that same thing yesterday. This is the working folder that VS.Net sends to us, and we don't know why it is sending the wrong one, but it causes all sorts of problems. So far, we have traced it to a project that, if included in the solution, causes it to send c:\, and if not included, causes it to send the correct working folder. VSS doesn't display the working folder value, and does add the solution, but then changing source control gets messed up, so I don't think VSS works entirely right either in that regard.
Anyway, thanks for your comments, and I'm really glad you are up and running.
Other issues:
1. We do have a client-only installer, but you may not have downloaded it. It is at: http://www.sourcegear.com/vault/downloads.asp (box that says client). Also, a little known feature of Vault allows you to install the client from your installed server: Go to http://yourvaultmachine/VaultService, and there should be a link there to the client installer, that you can use for deployment.
2. I think we will re-arrange that folder selection dialog to make it more clear what is going on. Also, if you were getting "c:\" as your working folder, and finally got it to work, that's great. We just had a report of that same thing yesterday. This is the working folder that VS.Net sends to us, and we don't know why it is sending the wrong one, but it causes all sorts of problems. So far, we have traced it to a project that, if included in the solution, causes it to send c:\, and if not included, causes it to send the correct working folder. VSS doesn't display the working folder value, and does add the solution, but then changing source control gets messed up, so I don't think VSS works entirely right either in that regard.
Anyway, thanks for your comments, and I'm really glad you are up and running.
I've done a bit more investigation, and wrote up a quick kb article at http://support.sourcegear.com/viewtopic.php?t=552
You probably had a stray file or project that wasn't under the solution hierarchy. Since you are up and runnng, this won't help for this case, but if others see this thread, the kb article can be referenced from here.
You probably had a stray file or project that wasn't under the solution hierarchy. Since you are up and runnng, this won't help for this case, but if others see this thread, the kb article can be referenced from here.