What's up with this error on a 'tf merge'? We think our IT folks applied a patch this weekend - we think it was a SQL server patch... Should we expect baseless merges to work or not?
tf merge /recursive /baseless . C:\destDir
A database error occurred (SQL error 2627) > Violation of PRIMARY KEY constraint 'PK_tbl_Lock'. Cannot insert duplicate key in object 'dbo.tbl_Lock'.
Hi Richard,
We are running RTM. These branches were both created from Main a few months ago and now we want to merge them together without touching Main -- ie using /baseless.
We do not have exclusive checkout turned on.
Binary files - so far as we know there aren't any that would need merging.
Using /candidate with /baseless gives error:
TF10100: The option baseless is not supported.
Using /preview with /baseless gives what looks like every possible file - I can't redirect the output of 'tf merge' via either pipe or > so it's kinda hard to tell but it looks like it's whining about all the couple thousand files... most of which do NOT have any changes between these branches.
Yes this is real-world on a large project.
Thanks!
Sue
Hmmm. Since we created these 2 branches a few weeks apart in time, when we checked in all the files, they checked in as different changesets.
We have been doing forward-integrates from Main to both branches, so they're pretty well in sync with each other.
If we try to tf merge one single file, that 'diff' shows as having no changes, the merge still whines that the changesets are different. Which of COURSE they are, since the branches were created at different times. But the files today are identical.
We were thinking /baseless would compare content rather than changeset #, since the changeset # will always be different even if the contents are identical....?
Sue
Ah I hadn't done the redirect on /preview right - 1>foo 2>bar works.
Emailing to you...
Let me do it again. Since the high-level merge has 2000 conflicts :-(, I'm doing a merge in a subdir with 21 files, of which 3 have content differences. The other 18 have identical content.
> tf merge /recursive /baseless . C:\destDir\subdir
Gives 21 stderr lines of Conflict (merge, edit)... one for each file
On the "Resolve Conflicts" dialog it lists 21 files as all having differences "The source and target both have changes"
I hit "Auto Merge All" and get 3 merged, "18 could not be resolved due to conflicting content changes". That's wrong - these have identical content. Manually doing 'diff' on these files shows no content difference.
Anyways, I choose one file and press "Resolve...". This "Resolve version conflict" dialog intelligently shows "Changes: No content changes" and Merge is not an option, so I can just hit OK to keep the target.
If I choose multiple files and press "Resolve...", then I get 3 choices:
"Merge changes for me" -- this doesn't work, it says it's can't resolve. Bull.
"Undo my local changes" -- hmmm does this mean take the target? This is confusing.
"Discard server changes" -- what the heck does this mean?
I expected multi-select on Resolve to give me the same choices as single-select (Keep changes in target / copy item from source). I don't understand those other choices...
I suppose since there really are no changes, once the auto-resolve resolves the files that actually have changes, I can just Close / Cancel out of the rest :-)...?
too, needing resolution as namespace conflicts rather than content
conflicts. That would be a pain.)
In short, baseless merges are a very blunt instrument, not something you look forward to doing. For instance, when Perforce added the ability to compute a pseudo-base from common branch ancestors, they discouraged using baseless merges to do indirect (aka 'sideways' or 'sibling') integrations. Unfortunately, TFS doesn't have that feature, so baseless is the only way.
I'll keep working with Sue privately to get a repro for the PK violation.
The failure of AutoMerge on identical files is a bug too, albeit not one I'm familiar with. These are text files, yes?
I just got this also. I did a baseless merge and all the files that were really different merged fine but I was left with 900+ Conflicts. of those about 100 were in binary files which I expected. The remaining 800 or so were all in *.cs source files, all of which where identical in both branches.
You appear to indicate this is a defect. Has this been fixed for SP1? Do I need to 'vote' someplace for it?
-mark
A baseless merge intentionally produces a conflict for each merge change, because there is no base. You should be able to use the Auto Merge All button in the resolve dialog to resolve the conflicts on the identical text files.
Buck
Buck,
The Automerge button did not resolve the conflicts on the identical text files.
-mark
Susan, sorry for the delay in getting back to you. Suffice to say I don't know what's going on in your database. Please call Customer Support and request an escalation to the version control team so that we can investigate directly.
