如何将C＃更改从一个ASP.NET应用程序转移到另一个？

Question

We are developing Caisis (Caisis.org) -- open source clinical data collection system. Caisis is ASP.NET (4.0) (C# code behind) front end and SQL Server 2008 back end.

Periodically, Caisis versions are upgraded. For example, we have been busy developing on Caisis version 5.0, and now Caisis Version 6.0 has been released. We now need to transfer all our front & back end changes to Caisis Version 6.0.

Synchronizing differences between 2 SQL Server databases may be addressed using Red Gate SQL/Data Compare or open source DB tools like Open DBDiff.

However, as far as I can tell there are no equivalent tools (proprietary or open source) to synchronize 2 ASP.NET/C# applications. Currently we are reduced to semi-automated approaches involving detecting differences between the 2 file systems using robocopy, then applying these changes manually. Is there a more efficient way to do this?

Answer 1

I've been in similar situations. The answer is simply: it's not an easy task. You can use a tool like Beyond Compare or Araxis Merge (Merge being more user-friendly, BC being more powerful, in my opinion). To do directory comparisons. With a little bit of configuration, you can have those tools hide all non-differing directory branches and files, leaving you with just a subset of differences. Then you can use the file comparison feature of those tools to see exactly what changed in files and chose what to pull and what to leave.

(Opinion) You should do this merge on a clean checkout -- that is, no outstanding files to check in. Then, after your merge is complete, have a single large check-in with just the upgrade merge changes. Then you have a way to rollback if you took too much, or if you missed something. You can roll back the changes, make the fixes, and try again.

Answer 2

My inclination if I were setting up a new project of this type would be to handle it via source control branching and merging. I would pull in the original code for the product I am going to modify as my starting point (call it my core branch for the sake of discussion). Before making any changes I would then branch this for my development work (call this one dev). Continue from here with which ever branching strategy you prefer.

The key to what I am setting up is that I never make a change in the core branch, it remains true to the original release I am basing my modifications on. Then as changes to the original code are released I can apply them to my core branch. From there I can merge them into my dev branch, and on through any other branches and to my release code as appropriate.

Of course this approach hinges on two things: A) you use a source control system that does a decent job of handling branching and merging. B) you establish this branching structure at the start of the project.

Setting this up after the project is already in progress would be quite a bit more difficult. Some source control tools will allow you to establish a branch relationship between discrete code bases, but in my experience there are nearly always complications to doing so. For something that already has already been significantly modified from the original, Eli's suggestion is probably one of the better approaches.