Open from Source Control after project branched problem
Moderator: SourceGear
-
- Posts: 18
- Joined: Thu Jan 15, 2004 12:56 pm
Open from Source Control after project branched problem
I have had some of our developers report to me through the years that they have done an open from source control on new project and then would begin making changes checking files in and out only to find out that the bindings were wrong and they were checking files in against a different project. Nobody could every really tell me how to reproduce nor was I able to reproduce it until now.
So, I branched the entire source code project sturcture for a an application from V4 to a V5 to begin development on a new version of the application. I then did an open from source control and selected one of the projects from the new V5 branch. When prompted by VS to open the solution, I select the solution and everything appeared to be openned correctly. All of the directories were created on my hard drive under the correct V5 folder. However, the ONLY project in the solution that was bound to the Vault V5 project was the one I selected when I did Open from Source Control. All of the other projects in the solution are still bound to the V4 Vault projects. I have recreated this on multiple occasions now.
The only solution I see is to go through every project in the solution and make sure you bind it to the right project in Vault right after you do an Open from Source control the first time before you begin development. But if as a developer do not know if someone has done that for this project yet, I will have to check the first time you Open it from source control. This is a very dangerous (from a source code version management standpoint) problem.
So, is this a Vault problem? Is there another way we should be doing this?
I have seen it with both VS 2003 and 2005.
We are using Vault Version 3.5.3.
So, I branched the entire source code project sturcture for a an application from V4 to a V5 to begin development on a new version of the application. I then did an open from source control and selected one of the projects from the new V5 branch. When prompted by VS to open the solution, I select the solution and everything appeared to be openned correctly. All of the directories were created on my hard drive under the correct V5 folder. However, the ONLY project in the solution that was bound to the Vault V5 project was the one I selected when I did Open from Source Control. All of the other projects in the solution are still bound to the V4 Vault projects. I have recreated this on multiple occasions now.
The only solution I see is to go through every project in the solution and make sure you bind it to the right project in Vault right after you do an Open from Source control the first time before you begin development. But if as a developer do not know if someone has done that for this project yet, I will have to check the first time you Open it from source control. This is a very dangerous (from a source code version management standpoint) problem.
So, is this a Vault problem? Is there another way we should be doing this?
I have seen it with both VS 2003 and 2005.
We are using Vault Version 3.5.3.
What kind of project/solution is this?
If it's a web project, those behave a little differently: Branching Web Projects
If it's a web project, those behave a little differently: Branching Web Projects
-
- Posts: 18
- Joined: Thu Jan 15, 2004 12:56 pm
If I have the following layout:
$
-Trunk
---SolutionFolder
-----.sln file
-----subProj1Folder
----------projfiles
----------projfiles
-----subProj2Folder
----------projfiles
----------projfiles
Then I can branch either the Trunk folder or I can branch the solution folder (technically you can branch individual projects too, but not using that in this example). Next I open Visual Studio and perform a fresh Open From Source Control and select the .sln file and pick the location where I want the opened branch to go. The .sln file has relative paths, so it is still able to find the projects that go with it and I have the branched projects.
If yours is pointing back to the originals, then something isn't quite right. There was a bug in VS at one time that made it check out the originals instead of the branch. Check this KB article for details: Branching a project stills checks out file from trunk in IDE
The way to fix your current situation is to unbind and then bind to the proper areas like you had mentioned, or you can remove your files from disk and try another Open From Source Control.
Do you have a layout that is different than what I showed? If so, can you show me how yours is set up, and I can try to mimic it in a test?
$
-Trunk
---SolutionFolder
-----.sln file
-----subProj1Folder
----------projfiles
----------projfiles
-----subProj2Folder
----------projfiles
----------projfiles
Then I can branch either the Trunk folder or I can branch the solution folder (technically you can branch individual projects too, but not using that in this example). Next I open Visual Studio and perform a fresh Open From Source Control and select the .sln file and pick the location where I want the opened branch to go. The .sln file has relative paths, so it is still able to find the projects that go with it and I have the branched projects.
If yours is pointing back to the originals, then something isn't quite right. There was a bug in VS at one time that made it check out the originals instead of the branch. Check this KB article for details: Branching a project stills checks out file from trunk in IDE
The way to fix your current situation is to unbind and then bind to the proper areas like you had mentioned, or you can remove your files from disk and try another Open From Source Control.
Do you have a layout that is different than what I showed? If so, can you show me how yours is set up, and I can try to mimic it in a test?
-
- Posts: 18
- Joined: Thu Jan 15, 2004 12:56 pm
My structure is a little different. Basically my solution is in the folder with one of the projects. And I did the branch at the trunk level. Then I go into VS and do an open from source control and select Project1, then VS (maybe this is actually Vault) prompts me to create the directory, then VS ask me to select the file to open project1.sln or project1.vbproj. I select the solution file. VS finishes openning and all of the files are in the correct structure on my hard drive under TrunkV5. But if I go look at the Vault bindings Project1 is bound to the new branched TrunkV5, but the other projects are all still bound to TrunkV4. And I can do exactly what you said and get everything bound correct, but if I forget, or I don't know that this is the first time the project has been openned since it was branched. I am checking changes back against V4 and I have a real mess. I just did this again yesterday on another solution in this same application and had the same results, so it has done it everytime since I figured out what was happening.
-TrunkV5
---Project1
-----.sln
-----project files
---Project2
-----project files
---Project3
-----project files
-TrunkV5
---Project1
-----.sln
-----project files
---Project2
-----project files
---Project3
-----project files
Brad W. Young
DevSource LLC
DevSource LLC
The .sln file doesn't normally like to be in the same folder as the project. I created a blank solution and put it in a similar location and added the projects to it and created a branch and came up with the same situation. I think in this case a pyramid structure closer to what I used may help.
Is there a reason that the solution file needs to be in the project folder?
How did you get it there? I think it usually involves a move and manually editing the relative paths.
Is there a reason that the solution file needs to be in the project folder?
How did you get it there? I think it usually involves a move and manually editing the relative paths.
-
- Posts: 18
- Joined: Thu Jan 15, 2004 12:56 pm
Well, there is a checkbox when you create a new project whether you put the solution in its own folder or in the same folder as the project. So, it is a standard option provided by VS. It is the option that we have used most of the time, in the past. Now, I have found good and bad with doing both ways. Generally the applications we develop are big enough that we have multiple solutions for the different parts of the application and certain projects are used by multiple projects and are then in multiple solutions. So, you are generally adding another layer of folders for each solution when you create the directory for the solution.
If I do what you suggest and I expand on my example sturcture it would look like the following. The project1 which represents a solution would have an extra folder. Project2 and Project3 are used in Project4 and Project1 each of which has a solution.
-TrunkV5
---Project1Solution
-----.sln
-------Project1
---------.vbproj
-----project files
---Project2
-----project files
---Project3
-----project files
---Project4Soltuion
-----.sln
------Project4
--------.vbproj
Now, having said all of that I do think having the solution level makes some since and is something we are using more of. And I will definitely begin using more if this is going to be an issue. But the structure I have on these older projects that I am branching is supported structure by VS and not something I did by moving files around. So, if Vault is not handling this structure then I would recommend that this be reported as a problem and see if it can be addressed.
Thanks for your help!
If I do what you suggest and I expand on my example sturcture it would look like the following. The project1 which represents a solution would have an extra folder. Project2 and Project3 are used in Project4 and Project1 each of which has a solution.
-TrunkV5
---Project1Solution
-----.sln
-------Project1
---------.vbproj
-----project files
---Project2
-----project files
---Project3
-----project files
---Project4Soltuion
-----.sln
------Project4
--------.vbproj
Now, having said all of that I do think having the solution level makes some since and is something we are using more of. And I will definitely begin using more if this is going to be an issue. But the structure I have on these older projects that I am branching is supported structure by VS and not something I did by moving files around. So, if Vault is not handling this structure then I would recommend that this be reported as a problem and see if it can be addressed.
Thanks for your help!
Brad W. Young
DevSource LLC
DevSource LLC
You can most certainly work that way if you wish. I have had best results with the way I have it. There is a KB article here on the issue you are seeing: Branching a project stills checks out file from trunk in IDE
It has more to do with Visual Studio than Vault I believe. When it comes to IDE integration, VS tells the source control tool what to do through its API instead of the other way around.
The work around would be to rebind as you have already been doing.
It has more to do with Visual Studio than Vault I believe. When it comes to IDE integration, VS tells the source control tool what to do through its API instead of the other way around.
The work around would be to rebind as you have already been doing.
-
- Posts: 18
- Joined: Thu Jan 15, 2004 12:56 pm
Well, the KB says it was fixed in VS 2003. Which is what I am using in this instance. Also, it does not talk about putting the solution in the same folder as the project. It does talk about putting the project on a different drive than the solution.
So, I guess by your short comment SourceGear is basically saying this is not a Vault issue and/or not something that you are going to look into.
So, I guess by your short comment SourceGear is basically saying this is not a Vault issue and/or not something that you are going to look into.
Brad W. Young
DevSource LLC
DevSource LLC
Brad:
Once you've opened from Source Control on the branch's solution, you can verify the working folder settings by highlighting the solution from the Solution Explorer, and then choose File -> Source Control -> Change Source Control.
If you look at the sub projects bindings, they should contain the new working folder location of your branches. If they do not, unbind and rebind from that dialog. This should make the Vault Classic client ask for a new working folder so you can make the changes, close the dialog, Save Everything and commit everything back to the repository.
FWIW, I tried to recreate your problem on Visual Studio 2005 with Vault 4.1, but could not. I had the following VS 2005 project added to Vault:
I branched $/src into $/src-branch from within the Vault client.
Next I opened up Visual Studio 2005, and did a open from source control. I browsed to $/src-branch/WinApp1, and chose that repository path and set a working folder to a new empty location.
Once the entire project was downloaded, I checked -> File -> Source Control -> Change Source Control, and the WinApp1 (project) and CtrlLib1 (project) were both mapped to the correct working folders.
Once you've opened from Source Control on the branch's solution, you can verify the working folder settings by highlighting the solution from the Solution Explorer, and then choose File -> Source Control -> Change Source Control.
If you look at the sub projects bindings, they should contain the new working folder location of your branches. If they do not, unbind and rebind from that dialog. This should make the Vault Classic client ask for a new working folder so you can make the changes, close the dialog, Save Everything and commit everything back to the repository.
FWIW, I tried to recreate your problem on Visual Studio 2005 with Vault 4.1, but could not. I had the following VS 2005 project added to Vault:
Code: Select all
src
-- WinApp1
-- WinApp1
-- CtrLib1
Next I opened up Visual Studio 2005, and did a open from source control. I browsed to $/src-branch/WinApp1, and chose that repository path and set a working folder to a new empty location.
Once the entire project was downloaded, I checked -> File -> Source Control -> Change Source Control, and the WinApp1 (project) and CtrlLib1 (project) were both mapped to the correct working folders.
Jeff Clausius
SourceGear
SourceGear