DBML changes & source control

views:

446

answers:

DBML changes & source control

Hi all!

I'm having some issues with the DBML. Every time the team needs to synchronize changes into SVN, the DBML is changed which generates lots of conflicts. This seems to be related to some rearrangement in the dbml editor, because most of the associationConnector sections in the .dmbl.layout seem to change during development if you open the dbml file in the editor.

Do you have any best practices to avoid these layout rearrangements that can easily take more than one hour to fix?

Best regards, Gustavo

If it is just the .layout being changed then I would actually ignore the request since the GUID's which link everything up will still match. They just won't be in the same place as I set them, something I could live with. If the .dbml changed as well, then I would accept both without merging.

Robert MacLean 2009-03-10 14:43:07

We have all scenarios. I agree with what you said, but what if different people changed the same tables, requiring a merge, but at the same time having a lot of conflicts caused by the connectors rearrangement?

Gustavo 2009-03-10 14:48:21

In the scenario you describe: If people do not change the tables, just moved them around the .dbml won't be effected and you could ignore that. If the .dbml changes then you would need to do a merge.

Robert MacLean 2009-03-10 14:54:52

If I try a merge I will solve the new fields/tables problem but I will get duplicate associationConnector such as this one:<associationConnector edgePoints="[(23.75 : 39.056113374349); (23.25 ........One for my change, another for the source controlled version. Or am I missing something?

Gustavo 2009-03-10 15:21:58

Yeah, let me rephrase.If the .layout changes always just accept (if the .dbml also changed) or reject it (if the .dbml didn't also change) - never merge.If the .dbml changes worry about merging that.

Robert MacLean 2009-03-11 06:52:53

ansaurus

tags:

views:

answers:

DBML changes & source control

related questions