I was testing Vault, with your demo server, and I checked out (non-exlusive) one file from multiple machines so I could test merging. I made edits on both machines (making sure not to have conflicting edits), and checked the file back in. When I attempted to check the file in on the other machine, it said that there were conflicts, and I would have to merge (I had assumed it would auto-merge them since they did not conflict). I was confused as to how to actually merge the changes, and after a few attempts, I noticed that it kept adding the same change over and over again in the diff window, until I aborted the change.
1) Is that a bug? A user should not be able to hose themselves like that.
I later found that I was supposed to do a Get first (while my changed file was still checked out), which is not intuitive to me.
I would expect that a CheckIn would automatically do the Get for me, and then merge, and then check in (if it can auto-merge).
2) Is there a setting for that?
If it can't auto-merge, then I would expect it to bring me straight into DiffMerge so I can resolve it, just like VSS 2005.
3) Am I just missing something obvious?
I think this is the only remaining obstacle left in my quest to toss VSS.
Brian
Merge keeps adding same change over and over
Moderator: SourceGear
We'll need more info as to how exactly you got into this state. I am assuming you are using the Vault GUI client?
If you include a file in a Check In that is in a Needs Merge state, a dialog is displayed showing you the files in that state, along with buttons to Diff, Merge, or Resolve Merge Status. Pressing Merge should bring up the merge tool and allow you to resolve it and proceed with the checkin.
You are right that a Get will automatically merge the file (which is the easy way to do it), but resolving it via checkin should work too.
If you include a file in a Check In that is in a Needs Merge state, a dialog is displayed showing you the files in that state, along with buttons to Diff, Merge, or Resolve Merge Status. Pressing Merge should bring up the merge tool and allow you to resolve it and proceed with the checkin.
You are right that a Get will automatically merge the file (which is the easy way to do it), but resolving it via checkin should work too.
After 3 attempts I am still unable to reproduce the problem. I will try some more on Monday.
As for my other concern...
If the user is required to do a Get for the CheckIn to work, then why not just do the Get for them, so that the their entire CheckIn process is reduced to one button click? Maybe that could be an option?
I expected it to work in one click but instead this is what I got:
Clicked CheckIn.
DialogBox: "The CheckIn/Commit transaction failed. See message pane for details."
Clicked OK
Clicked Show Merge.
Looked at the changes...no conflicts.
Clicked Close
DialogBox: Change merge status?
Clicked Yes:
DialogBox: Are you sure...Should do a Get first...
got scared, Clicked Cancel
Clicked Get
Clicked CheckIn
That was for a non-conflicting merge.
Now I know to do a Get first, but its not intuitive. I want to check it out, make changes and check it back in... just like VSS2005.
As for my other concern...
If the user is required to do a Get for the CheckIn to work, then why not just do the Get for them, so that the their entire CheckIn process is reduced to one button click? Maybe that could be an option?
I expected it to work in one click but instead this is what I got:
Clicked CheckIn.
DialogBox: "The CheckIn/Commit transaction failed. See message pane for details."
Clicked OK
Clicked Show Merge.
Looked at the changes...no conflicts.
Clicked Close
DialogBox: Change merge status?
Clicked Yes:
DialogBox: Are you sure...Should do a Get first...
got scared, Clicked Cancel
Clicked Get
Clicked CheckIn
That was for a non-conflicting merge.
Now I know to do a Get first, but its not intuitive. I want to check it out, make changes and check it back in... just like VSS2005.
A number of people don't like SCC tools to automatically merge their files - they want to do it all themselves, so we try to be cautious in the direction of not changing files.
However, having this be an option seems reasonable, especially if it follows the default Get option for whether to automatically merge or not. I'll add this is a change request, and we'll need to discuss it internally. Thanks for the feedback on it.
However, having this be an option seems reasonable, especially if it follows the default Get option for whether to automatically merge or not. I'll add this is a change request, and we'll need to discuss it internally. Thanks for the feedback on it.
I can reproduce that problem now...
From 2 diferent machines, with 2 different demo accounts:
PC1 (username: demobweed)
PC2 (username: mars)
PC1: created a folder in your demo server called $/ZTest
PC1: Added MgcVector3.cpp
PC2: Get $/ZTest
PC1: Checkout MgcVector.cpp
PC2: Checkout MgcVector.cpp
PC2: Added printf("\n");
PC1: Added +1, +2, +3
PC2: CheckIn
PC1: as follows
Get file into Needs Merge status. By Either a CheckIn, or a Diff.
Click CheckIn again (brings up Diff/Merge/Resolve dialog)
1) Click Merge.
2) Click OK on AutoMerge Results dialog.
3) Click Close
4) Click Yes to save changes to center panel
5) Click no on the resolve merge status dialog.
Click Merge...
You will see the change from PC2 duplicated
You can keep cycliing thru 1..5 and it will keep duplicating the change back in.
From 2 diferent machines, with 2 different demo accounts:
PC1 (username: demobweed)
PC2 (username: mars)
PC1: created a folder in your demo server called $/ZTest
PC1: Added MgcVector3.cpp
PC2: Get $/ZTest
PC1: Checkout MgcVector.cpp
PC2: Checkout MgcVector.cpp
PC2: Added printf("\n");
PC1: Added +1, +2, +3
PC2: CheckIn
PC1: as follows
Get file into Needs Merge status. By Either a CheckIn, or a Diff.
Click CheckIn again (brings up Diff/Merge/Resolve dialog)
1) Click Merge.
2) Click OK on AutoMerge Results dialog.
3) Click Close
4) Click Yes to save changes to center panel
5) Click no on the resolve merge status dialog.
Click Merge...
You will see the change from PC2 duplicated
You can keep cycliing thru 1..5 and it will keep duplicating the change back in.
I've been trying to duplicate this, but have been unable to.
Can you post the exact files here that you are using (it might have to do with the specific edits you have in the file). I've tried both conflicting and non-conflicting changes, but none of them seem to repeatedly add the same changes.
Note that if don't say the merge has been resolved, it will try to apply the same change again. However, it should be smart enough to know that the same change already exists in that file. Are you editing the file again after doing the merge, as that would explain this behavior more readily.
Also, I'm assuming you are using 3.1.7, and that you are using the Vault diff merge tool, and not a 3rd party app?
Can you post the exact files here that you are using (it might have to do with the specific edits you have in the file). I've tried both conflicting and non-conflicting changes, but none of them seem to repeatedly add the same changes.
Note that if don't say the merge has been resolved, it will try to apply the same change again. However, it should be smart enough to know that the same change already exists in that file. Are you editing the file again after doing the merge, as that would explain this behavior more readily.
Also, I'm assuming you are using 3.1.7, and that you are using the Vault diff merge tool, and not a 3rd party app?
I was using the latest client (3.1.7), and the Vault diff merge tool, not a 3rd party one. And I did not make edits to the file after the merge.
The file I used to test this is in $\ZTest in your demo server. You can see the history of the file there. (it's also attached).
The file I used to test this is in $\ZTest in your demo server. You can see the history of the file there. (it's also attached).
- Attachments
-
- MgcVector3.cpp
- (7.39 KiB) Downloaded 523 times
When I follow the same steps on the file with the same edits, the second time I go in, I get conflicts when it tries to merge, because it is trying to merge changes into the place it has already changed (because it was already merged), which I believe is reasonable/correct behavior. I'm still not seeing a change continually repeated.
In any case, the use case here is kind of strange, in that you are merging the file, then telling Vault that it wasn't merged, so when you merge again, it is trying to apply the change again. In my case, I am getting either a conflict or it is applying the change again, depending on where the edit is. In your case, it is applying the change again, which I could argue is correct, since you are telling it to merge a change again that you've already merged.
In any case, the use case here is kind of strange, in that you are merging the file, then telling Vault that it wasn't merged, so when you merge again, it is trying to apply the change again. In my case, I am getting either a conflict or it is applying the change again, depending on where the edit is. In your case, it is applying the change again, which I could argue is correct, since you are telling it to merge a change again that you've already merged.