2

I am working on a project that uses visual studio's GUI DB designer to draw out a data access layer.

I use mercurial as my VCS, but it shouldn't matter too much. Whenever I make a change to the DB designer screen in one branch, then another change in another branch, and try to merge the two branches... I almost always get terribly complex merge conflicts that are hard to figure out even by hand on the .cs files that the DB designer generates.

How do you deal with this?

Davis Dimitriov
  • 4,159
  • 3
  • 31
  • 45
  • 1
    IMHO, Visual Studio should output designer files in a deterministic way. For example, sorting symbols by type, access level, and name. This way if you make a change that causes a single property to be added the entire goddamn file isn't rewritten in a different order... If this was done then version control would have no problem with it. As it is, my team (we're also using Mercurial) basically has to "lock" our entity framework model (by verbal communication), make their changes, commit and push, and then "unlock" them; allowing somebody else to make changes. It's very difficult to merge ... – bambams Sep 30 '11 at 20:42

2 Answers2

1

Branching / merging DB differences does not work really well with textual diff/merge tools. There are special tools like ERwin (see http://erwin.com/), which can handle this, but those tools are expensive and will probably be not easy to integrate into your VCS.

I think best option when using the Visual Studio DB designer is to avoid branching completely. Or don't design your DB using the DB designer. Better have a more or less simple description file for your DB and generate everything else you need from this by a handwritten generator.

Doc Brown
  • 19,739
  • 7
  • 52
  • 88
1

I think that @Doc Brown answer is a great one, and this is a common issue with DVCSs

Given the Copy-Modify-Merge workflow of a DVCS, you'd be better off using a text format (like @Doc Brown stated), or develop a process/convention that allows you to communicate changes to the rest of your team, so that you don't step on each other when trying to update/pull.

The ability to handle binary files works well with centralized VCS, because you have the (sometimes limited) ability to lock the file on check-out (Checkout-Modify-Checkin workflow).

FWIW, here's a great discussion of the subject on SO.

Binary Files in DVCS

Community
  • 1
  • 1
Ritch Melton
  • 11,498
  • 4
  • 41
  • 54
  • I interpret "designer file" as a *.designer.cs or *.designer.vb file that is generated for a number of things. They are text, but they're still extremely difficult to merge because a simple change results in the entire file being rewritten in a different way. Also, this isn't limited to distributed version control systems. It applies to any version control system. Two members could make separate changes in Subversion and one would still have to merge them. – bambams Sep 30 '11 at 20:48
  • @bamcciag - If the file is locked, two people can't make changes to it at the same time. – Ritch Melton Sep 30 '11 at 21:55
  • 1
    If the file is locked, somebody can't do their job, and might as well go home. >_> The entire point of version control (especially distributed version control; not being able to lock a file is a FEATURE) is that everybody can work freely without interfering with one another. – bambams Oct 25 '11 at 15:09
  • @bamcciag - Locking is painful. So is merging binary files (or even xml for that matter). There isn't a really good solution to this in terms of tooling, but if you structure your application and enable a team to coordinate checkins, then locking can be the most effective solution. – Ritch Melton Oct 25 '11 at 22:10
  • Binary files generally shouldn't be tracked in a source control management repository. XML can be merged easily enough if the file is organized and formatted sensible. If it's not then somebody should be fired (in this case, Microsoft). – bambams Oct 26 '11 at 17:54
  • @bamccaig - Its been my experience that everything that is not a build artifact should be tracked in version control. The distinctions are arguable, and some tools (like mercurial) fail miserably with large binaries, or even large structured plaintext files. – Ritch Melton Oct 26 '11 at 19:37