I'm using SOS 4.0.
It appears that if I checked out, say, version 1 of a file, someone else checks in a version 2, then I go to checkin my changes as version 3, SOS tries to automatically merge my changes with the version 2 changes with respect to version 1 as it checks in.
That may be expected behavior. But if instead, I had done a Get Latest Version to get version 2 (allowing automatic merge) so that my local file now includes both my local changes and the version 2 changes, and then I go to checkin my changes as version 3, SOS still tries to do that automatic merge during the checkin which sometimes messes up the file.
Automatic merging on checkin is never useful to me, because we always want to first merge down and test our local changes merged with the latest before checking in. So I always want to checkin exactly what's in my file (which is what has been tested). (Does anyone really want to check in something that got automatically merged during the checkin and you never had a chance to test it or even see it before it got checked in?)
Is there a way to turn off automatic merging during checkin? Especially if SOS has already done the merge for me on Get Latest Version, but even if I manually did the merge myself? I never want it to automatically merge on checkin.
Thanks,
Jim
SOS merging on checkin
Moderator: SourceGear
If there are no conflicts, there's no way to stop a merge on checkin, since this behavior is dictated by SourceSafe, not SOS.
If you never want to merge on checkin, you might want to consider using exclusive checkouts. That way, you don't have to deal with someone else making changes to a file you have checked out. This option is managed in the VSS Admin Tool under Tools->Options->General->Allow Multiple Checkouts.
If you never want to merge on checkin, you might want to consider using exclusive checkouts. That way, you don't have to deal with someone else making changes to a file you have checked out. This option is managed in the VSS Admin Tool under Tools->Options->General->Allow Multiple Checkouts.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
It's not that I don't want to merge. In our environment, we do want to allow multiple checkouts and we do expect to have to merge (and test) before checkin. We just don't want our files changed after we've already merged them.
There is an approach that I think would solve this problem very nicely. When I do a SOS Get Latest Version and do the automated merge (or manual merge and tell it that all conflicts were resolved), it would make sense for SOS to change the version number that is checked out to the latest version - since the version I have now includes all the changes from the latest version. This way, when I do the checkin, VSS won't see any need to merge, and it will checkin the file properly.
I can do this process manually as follows:
1) Do Get Latest Version - with automated or manual merge.
2) Undo Checkout (choose Leave Local copy)
3) Do Checkout (choose Don't get local copy)
Now doing a checkin will avoid the automated merge and check the file in correctly. It would be nice if this were the default action (or at least an option) of SOS when completing a merge down. I don't see any advantage of the way it currently works which makes VSS think you haven't yet incorporated the latest version locally when you really have.
If not that, then at least some option to tell it to prompt when checking in any file whose checkout version is not the latest version - and give the option to continue (which will do the automated merge up), do a manual merge, or cancel.
One or both of these options would be nice. A number of people new to SOS have inadvertantly had the wrong stuff checked in because of the way it currently works.
Thanks,
Jim
There is an approach that I think would solve this problem very nicely. When I do a SOS Get Latest Version and do the automated merge (or manual merge and tell it that all conflicts were resolved), it would make sense for SOS to change the version number that is checked out to the latest version - since the version I have now includes all the changes from the latest version. This way, when I do the checkin, VSS won't see any need to merge, and it will checkin the file properly.
I can do this process manually as follows:
1) Do Get Latest Version - with automated or manual merge.
2) Undo Checkout (choose Leave Local copy)
3) Do Checkout (choose Don't get local copy)
Now doing a checkin will avoid the automated merge and check the file in correctly. It would be nice if this were the default action (or at least an option) of SOS when completing a merge down. I don't see any advantage of the way it currently works which makes VSS think you haven't yet incorporated the latest version locally when you really have.
If not that, then at least some option to tell it to prompt when checking in any file whose checkout version is not the latest version - and give the option to continue (which will do the automated merge up), do a manual merge, or cancel.
One or both of these options would be nice. A number of people new to SOS have inadvertantly had the wrong stuff checked in because of the way it currently works.
Thanks,
Jim
-
MikeA
Multiple checkout results in "limbo" file
We've been using SourceOffsite for several months now. Overall, we are very pleased, as it enables VSS use over VPN. Occasionally, we find that as we are checking in files, a developer will lose some changes. I am able to recreate the following situation reliably, but I'm not sure if it's the only time data is lost:
User 1 checks out a file using VSS and modifies a line of code.
User 2 checks out the same file using SourceOffsite and modifies the same line of code.
User 1 checks in
User 2 tries to check in, but receives an error that the files could not be automatically merged.
User 2 then does an Undo Checkout. No errors are reported, but the file still has User 2's changes.
User 2 then does a Get Latest Version. This results in a message box saying certain files could not be merged. After viewing the conflicts (the dialog does not let you fix them), User 2 says that all conflicts have been resolved. (What else can User 2 say?)
At this point User 2 has a file with the changes User 2 made, although it is now in the neutral state. If User 2 does a Get Latest Version, the most recent copy in VSS is not copied locally. The only way to get the most recent copy is to delete the local copy, then do a Get Latest.
The worst case scenario (which happened to us!), is User 2 neglects to delete the local copy and then proceeds to check out the file and check it back in. At this point, User 1 changes are now lost.
Is this a flaw in the checkout model, or user error?
User 1 checks out a file using VSS and modifies a line of code.
User 2 checks out the same file using SourceOffsite and modifies the same line of code.
User 1 checks in
User 2 tries to check in, but receives an error that the files could not be automatically merged.
User 2 then does an Undo Checkout. No errors are reported, but the file still has User 2's changes.
User 2 then does a Get Latest Version. This results in a message box saying certain files could not be merged. After viewing the conflicts (the dialog does not let you fix them), User 2 says that all conflicts have been resolved. (What else can User 2 say?)
At this point User 2 has a file with the changes User 2 made, although it is now in the neutral state. If User 2 does a Get Latest Version, the most recent copy in VSS is not copied locally. The only way to get the most recent copy is to delete the local copy, then do a Get Latest.
The worst case scenario (which happened to us!), is User 2 neglects to delete the local copy and then proceeds to check out the file and check it back in. At this point, User 1 changes are now lost.
Is this a flaw in the checkout model, or user error?