SVN Commit results in Action = Replacing, not Modified

d843nred

When I "Keep Mine" on the Commit Changes tab and then Commit to SVN (Dedicated Database, and this has happened both for stored procedure changes and for changing column order in tables), it results in the SVN history on the object showing an Action of "Replacing" rather than "Modified".

If I TortoiseSVN - Show Log on the object, it only shows me one revision with an action of "Replacing". If I double-click the object name, I can see the previous version of the object, but no history before that.

If I Show Log on the containing folder and step through the history there, I can see changes to the object in the past.

Do I have a setting in SQL Source Control configured somehow that is causing this? Other developers are not seeing this behavior. They have only SQL Source Control. I have the Developer Bundle, as I manage the build process and do production support.

Evan Moss

Hello,

Thanks for your post.

I just did some tinkering and it looks like "replacing" is actually the appropriate behavior in this situation.

Let's say your copy of the database is on revision #5, your repository is on revision #6 (which includes a change to object x), and then you change object x in your database. If the difference between 5 and 6 is different than the difference between 5 and 7 (the change you just made), this will show up as a conflict. If you choose to "Keep Mine" and commit, you're basically telling source control, get rid of whatever version 6 is and put version 7 in there instead. (You'd only see 5 and 7 in the revision history also, because 6 isn't involved in the historical chain.)

Now, if you were to go to a different database that's still on revision 6 and modify object x again (causing a 6-7 vs 6-8 conflict) and select "Keep Mine", you would see "replace" again in the SVN log, and you'd only see 6 and 8 in the revision history.

The only reason I can think that your colleagues would be seeing different behavior is if they weren't in conflict situations.

Please let me know if you have further questions.

Thanks,
Evan

rlevine

This is causing many issues for us.
Our developers are making changes and at times there may be a conflict in which they select keep mine.
We have noticed many times that the checkin history in SVN is all gone (replaced by the latest checkin) and it makes auditing and executing code reviews very challenging.
IMHO: This SHOULD NOT remove all the history items. If you want to argue that it should remove just the single one that it is replacing (if that is even possible in SVN), I can maybe hear that argument, but to delete all the history (years worth), does not sound like a feature to me.

:oops: :evil: :oops: :evil: