2

We have constant problem with project XML file (*.sqlproj). If the files are added/renoved/changed location then it automatically adds/removes records in some unexpected places. After that we have big troubles by merging it when somebody changes that file also.

We came to conclusion that we might sort it before checkin. We would alphabetically sort it and in that case merge tool will understand it much better.

So, my questions would be:

  1. Is it possible to re-arrange sqlproj file somehow before EVERY check-in? Maybe there are somekind of options/tools that doing that already?
  2. Are there any other ways to make developers life easier?

UPDATE:

Once again I got the same problem. sqlproj file was modified 3 times and I want to merge to production only the last change, other 2 are not tested yet. in the merge tool I have the option to add all these 3 new objects or leave it without changes. I am not able to select only the last change ...

EXAMPLE:

  1. developerA created tableA and checked in;
  2. developerB got the latest version of dev branch, created tableB and checked in;
  3. developerC got the latest version of dev branch, created tableC and checked in. DeveloperC tested the code and ready to go to production. He tries to merge his code to QA and get's the conflict where he has an option only to go with ALL changes.
Dmitrij Kultasev
  • 5,447
  • 5
  • 44
  • 88

2 Answers2

1

I understand the scenario you are running into very well. This typically happens when you have multiple work streams happening in the context of a single repository and you don't have a common promotion schedule (as in all work will go to QA at the same time and PROD at the same time).

There's a few ways I can think to get around this problem and there are pros and cons to each option.

  1. Lock each environment until everything can promote together. Not realistic in most cases.

  2. When you are ready to promote, create a promotion branch from source environment and take things out of the promotion branch that aren't ready to promote to destination environment. This allows devs to keep working and be able to promote without freezing.

  3. Hybrid approach... Don't source control anything in Dev until it's ready to promote to test. Then either do option #1 or 2 from there onward.

  4. Create a more flexible ecosystem that can spin up an environment for each Feature branch in order to demo/test with others(or at least allocate/rotate enough between the developers to accomplish the same objective). Once it's accepted promote. This is what we are working towards currently but building out the infrastructure and process when you have a ton of interconnected databases and apps that share them is a bit challenging to say the least (especially in the Microsoft world).

Anyways hopes this helps...

Shaunt
  • 183
  • 1
  • 3
  • 11
0

1 - what source control are you using? No source control that I am aware of understands the context of sqlproj files but this isn't normally a problem.

2.a - This shouldn't be a problem you get constantly, are you checking in/out regularly? I would only expect to see issues if different developers are making large scale changes to the projects and not checking out / checking in before and after.

2.b - It is also possible you are not merging correctly, if you take both both sets of changes then it is normally fine.

ed

Ed Elliott
  • 6,666
  • 17
  • 32
  • 1) TFS; 2a) Constantly, checking more or less regularly (not big sets of changes); 2b) Trying to merge only my changes – Dmitrij Kultasev Jun 15 '15 at 13:37
  • How are you fixing conflicts? including changes from both halves of the conflict?(conflict window, tick on left and right side) - I do this quite a lot and have never had any problems things being put into the wrong place – Ed Elliott Jun 15 '15 at 13:45
  • The problem happened when we are working on several issues. Let's say that I've added the object and did not finished yet. After that I've switched to another task and added 1 more file. Finished task #2 and want to go live, but in proj file I still have an entry from the first task. It is small example but we have a lot of problems when merging this file :( – Dmitrij Kultasev Jun 15 '15 at 13:51
  • ok there are two things I would do, you can either start creating branches for each piece of work (simpler int git that tfs) or checkin one pice at at time, if task#1 isn't finished either roll it back, shelve it or just get another workspace - check in task #2 then go back to task #1, finish it off and then check it in - mixing stuff up like this you find merges harder and you risk deploying too much / too little – Ed Elliott Jun 15 '15 at 13:55
  • yeah, git and branches are beautiful however it is quite hard to do the local copy of the project for every change in the project. With GIT it was easy, however we use TFS in the current workplace. – Dmitrij Kultasev Jun 15 '15 at 14:12
  • The problem is that you are making changes over a long period of time and mixing up work items in the same workspace, either finish off what you are doing or use different workspaces - does that work for you? – Ed Elliott Jun 15 '15 at 14:43
  • Hey! Do you mean the pending changes shows all changes or the .sqlproj file includes all the changes? The problem is that there is a single .sqlproj file - you need to start using branches and stop mixing all your work up. – Ed Elliott Jun 23 '15 at 15:08
  • not pending. When I am trying to made merge from dev to qa or prod then I have this problem. Example: developerA created tableA and checked in, developerB got the latest version of dev branch, created tableB and checked in, developerC got the latest version of dev branch, created tableC and checked in. DeveloperC tested the code and ready to go to production. He tries to merge his code to QA and get's the conflict where he has an option only to go with ALL changes. – Dmitrij Kultasev Jun 24 '15 at 11:12
  • Ah ok I see. What I would do is...devC shouldn't have checked out the dev branch, you should have branched when the code went to QA and fixed tableC there, that should then be sent to QA. The fix for tableC should then be merged back into dev ready for the next QA release. – Ed Elliott Jun 24 '15 at 12:50
  • yes, but in that way it might happen that developerC would work with outdated version of the project. We made somekind of workaround by resorting all the objects in the sqlproj file when we build the project. It helps in the most of the time. However if the object are of the similar name and go 1 by 1 in the file then you have that issue. – Dmitrij Kultasev Jun 24 '15 at 15:09