Team dev - VS 2005 Project file sync woes
Moderator: SourceGear
-
- Posts: 33
- Joined: Tue Mar 11, 2008 11:27 am
- Location: Seattle, WA
- Contact:
Team dev - VS 2005 Project file sync woes
I hope I can explain this problem in a way that makes sense. I'll try describing a simple example.
Imagine we have a VS2005 solution with several projects in it. One of these projects is called "myLibrary". In myLibrary, there are a couple of class files: "myFirst.cs", "mySecond.cs".
We're using Vault in VS2005 for source control. We're working under the CVS model, so we're not forced to "check out" all the time.
Now, we've got 2 developers working on the team. I create a new class called "myThird.cs" and add the class to the Library project. I check both the class file and my project file into Vault.
Meanwhile, Bob (the other developer) has created "myBig.cs" and added it to his version of the project. He then checks in the class file and when he attempts to check in the project file, it tells him that the project file needs to be "merged" first.
Here's where we run into a problem. The only way we're able to do the "merge" is by doing a Get Latest and select "attempt auto merge". This appears to work (no errors) and Bob then checks the project file IN without error.
Unfortunately, the merge didn't really happen and the repository now contains a project file that thinks it only contains mtFirst, mySecond and myBig. myThird is missing. Doing a DIFF between the current and previous versions shows this.
The weird part is, that for Bob, myThird.cs still shows in VS2005, but when he try to compile, he gets an error saying that any reference to the myThird class is invalid because that class doesn't exist.
Just to confuse the issue, I'm not certain this example is the identical process we're experiencing, since we actually have several projects in our solution and 4 different developers working on it at once.
I'm hoping this will at least kick off a discussion that might lead me to finding the true problem and a fix for that problem.
Thanks!!
Imagine we have a VS2005 solution with several projects in it. One of these projects is called "myLibrary". In myLibrary, there are a couple of class files: "myFirst.cs", "mySecond.cs".
We're using Vault in VS2005 for source control. We're working under the CVS model, so we're not forced to "check out" all the time.
Now, we've got 2 developers working on the team. I create a new class called "myThird.cs" and add the class to the Library project. I check both the class file and my project file into Vault.
Meanwhile, Bob (the other developer) has created "myBig.cs" and added it to his version of the project. He then checks in the class file and when he attempts to check in the project file, it tells him that the project file needs to be "merged" first.
Here's where we run into a problem. The only way we're able to do the "merge" is by doing a Get Latest and select "attempt auto merge". This appears to work (no errors) and Bob then checks the project file IN without error.
Unfortunately, the merge didn't really happen and the repository now contains a project file that thinks it only contains mtFirst, mySecond and myBig. myThird is missing. Doing a DIFF between the current and previous versions shows this.
The weird part is, that for Bob, myThird.cs still shows in VS2005, but when he try to compile, he gets an error saying that any reference to the myThird class is invalid because that class doesn't exist.
Just to confuse the issue, I'm not certain this example is the identical process we're experiencing, since we actually have several projects in our solution and 4 different developers working on it at once.
I'm hoping this will at least kick off a discussion that might lead me to finding the true problem and a fix for that problem.
Thanks!!
In this case, are you merging a solution file or a project file? Solution files shouldn't be merged. I don't think project files should be merged either, but if you want to try that, you should list them as a mergeable file type for your repository.
Which version of Vault are you using, and in VS Tools - Options, which client are you using?
Which version of Vault are you using, and in VS Tools - Options, which client are you using?
-
- Posts: 33
- Joined: Tue Mar 11, 2008 11:27 am
- Location: Seattle, WA
- Contact:
Easy answer first:
Vault version is 4.1.0.16216
VS Client option is Visual Studio Enhanced Client.
Now back to the solution/project merge question:
we have both the Solution file and all the project files in Vault. I know I'm not supposed to answer a question with a question, but I'm forced to. If we don't keep the project file in Vault and do Merges on it, how does one workstation's environment know when new components have been added to the project? Isn't it the project file that keeps track of everything in the project?
I'm co sonfused.
Vault version is 4.1.0.16216
VS Client option is Visual Studio Enhanced Client.
Now back to the solution/project merge question:
we have both the Solution file and all the project files in Vault. I know I'm not supposed to answer a question with a question, but I'm forced to. If we don't keep the project file in Vault and do Merges on it, how does one workstation's environment know when new components have been added to the project? Isn't it the project file that keeps track of everything in the project?
I'm co sonfused.
Hi Kevin.
What probably happened is Bob got this dialog (attached below), and chose Yes. By choosing Yes, Bob told Vault to change the file's status from "Needs Merge" to "Edited", even though he hadn't actually done a merge. This let him check his version in, ignoring the previous version you checked in. This would result in the behavior you've described.
(This isn't a disaster, because all the data you need to do a merge is still present in the repository, but it's not the desired behavior in your scenario. If you want to know how to merge the relevant file versions after Bob's checkin in this scenario, let me know.)
I'd recommend that you add project file extensions (e.g. csproj) to the mergeable file type list. This will allow you to Show Merge when a project file gets in this state, and perform the merge, then check in.
But what about Beth saying solution and project files shouldn't be merged? And why aren't they in the mergeable list by default? These files are machine generated, and there are no guarantees that two different instances of Visual Studio are going to produce the same file based on the same changes. (It sometimes orders things differently, for example.) All this means in practice is that you need to either do the merge manually (using Show Merge as I described above) or, if an auto-merge during Get Latest succeeds, review its changes before checking in.
Make sense?
What probably happened is Bob got this dialog (attached below), and chose Yes. By choosing Yes, Bob told Vault to change the file's status from "Needs Merge" to "Edited", even though he hadn't actually done a merge. This let him check his version in, ignoring the previous version you checked in. This would result in the behavior you've described.
(This isn't a disaster, because all the data you need to do a merge is still present in the repository, but it's not the desired behavior in your scenario. If you want to know how to merge the relevant file versions after Bob's checkin in this scenario, let me know.)
I'd recommend that you add project file extensions (e.g. csproj) to the mergeable file type list. This will allow you to Show Merge when a project file gets in this state, and perform the merge, then check in.
But what about Beth saying solution and project files shouldn't be merged? And why aren't they in the mergeable list by default? These files are machine generated, and there are no guarantees that two different instances of Visual Studio are going to produce the same file based on the same changes. (It sometimes orders things differently, for example.) All this means in practice is that you need to either do the merge manually (using Show Merge as I described above) or, if an auto-merge during Get Latest succeeds, review its changes before checking in.
Make sense?
- Attachments
-
- CannotMergeBinaryFiles.PNG (14.75 KiB) Viewed 4742 times
Ian Olsen
SourceGear
SourceGear
-
- Posts: 33
- Joined: Tue Mar 11, 2008 11:27 am
- Location: Seattle, WA
- Contact:
Sort of makes sense.
I can't speak for Bob on whether or not he did as you described, but I guess it's possible.
I think I'm in disagreement about "csproj files shouldn't be in Vault", though. This file lists all the files in the project. If one person creates a NEW file in his local version of the project, but only checks in that file, no one else's project is actually going to know that file belongs, even if the Get Latest and have the file. Of course, when they Get Latest and try to compile and get errors, they can always guess that a new file is missing and try adding it to their own local project. However, this makes for PITA development, especially in the early stages when new files are being created fast and furious.
I can't speak for Bob on whether or not he did as you described, but I guess it's possible.
I think I'm in disagreement about "csproj files shouldn't be in Vault", though. This file lists all the files in the project. If one person creates a NEW file in his local version of the project, but only checks in that file, no one else's project is actually going to know that file belongs, even if the Get Latest and have the file. Of course, when they Get Latest and try to compile and get errors, they can always guess that a new file is missing and try adding it to their own local project. However, this makes for PITA development, especially in the early stages when new files are being created fast and furious.
Beth wasn't saying the files shouldn't be in Vault. They most definitely should, for all the reasons you've listed.
Beth was saying project files shouldn't be merged. You do have to be a bit more cautious when merging project files, as I described above. It's a question of choosing the pain you prefer: force developers to wait for one another, or be careful merging project files?
(This article talks more about picking your pain with respect to locked project files.)
Beth was saying project files shouldn't be merged. You do have to be a bit more cautious when merging project files, as I described above. It's a question of choosing the pain you prefer: force developers to wait for one another, or be careful merging project files?
(This article talks more about picking your pain with respect to locked project files.)
Ian Olsen
SourceGear
SourceGear
-
- Posts: 33
- Joined: Tue Mar 11, 2008 11:27 am
- Location: Seattle, WA
- Contact:
No offense taken, just trying to clear up the miscommunication.
Auto-merge is trustworthy because it's conservative. If it sees something that's even slightly possibly nebulous, it gives up, does nothing, and makes you merge manually.
That said, I always review the results of an auto-merge before committing. That's why the merge is performed locally: so you have a chance to evaluate it before it leaves your machine. The Diff button in the commit dialog comes in handy in this case.
Auto-merge is trustworthy because it's conservative. If it sees something that's even slightly possibly nebulous, it gives up, does nothing, and makes you merge manually.
That said, I always review the results of an auto-merge before committing. That's why the merge is performed locally: so you have a chance to evaluate it before it leaves your machine. The Diff button in the commit dialog comes in handy in this case.
Ian Olsen
SourceGear
SourceGear
-
- Posts: 33
- Joined: Tue Mar 11, 2008 11:27 am
- Location: Seattle, WA
- Contact:
Hmm... Maybe I'm just not clear on how this is supposed to work. I'm used to the traditional "check out exclusively" way of doing things.
We're using the CSV method, which apparently means we don't have to check things out. I can just start modifying and [here comes the question] it automatically checks the file out to me?
Then, when I check in the changes I've made to a file, it tries to automatically merge my local copy with what's in the repository, right?
IF there's a conflict that the auto-merge can't resolve, do I get some sort of notification when I try to check in? Is there something I should be doing, as a practice, before I check in any changes?
I've kind of taken this thread on a tangent, since I'm no longer talking about just the csproj file. Sorry
We're using the CSV method, which apparently means we don't have to check things out. I can just start modifying and [here comes the question] it automatically checks the file out to me?
Then, when I check in the changes I've made to a file, it tries to automatically merge my local copy with what's in the repository, right?
IF there's a conflict that the auto-merge can't resolve, do I get some sort of notification when I try to check in? Is there something I should be doing, as a practice, before I check in any changes?
I've kind of taken this thread on a tangent, since I'm no longer talking about just the csproj file. Sorry
First, read this. It's a better explanation than I could whip up here. Chapter 2 might also be helpful. (The whole thing is potentially helpful, if you have the time and inclination.)
The quick and dirty CVS mode work flow is this:
The quick and dirty CVS mode work flow is this:
- Get Latest to set up your local dev environment
- Edit source however you like. You don't tell the server what you're doing.
- Merge if necessary. "Necessary" means somebody else has committed a change to a file you've also changed. Vault gives these files a "needs merge" status and prevents you from committing changes until you've resolved the merge. You can merge manually (using the Show Merge command) or you can attempt an auto merge by doing Get Latest on the file that needs merging. If auto-merge doesn't work, it will do nothing and you'll have to merge manually.
- Commit.
Ian Olsen
SourceGear
SourceGear