I have just migrated my code from Perforce to TFS. Everything looks good but there are an issue which is Forward and Reverse integration from one solution to another. This is the show stopper for me.
There are two different solutions and 2 projects are common in both the solutions, but have different copies individually. So forward integration would be merging the whole application from sol1 to sol2 resolving the conflicts in common projects. After it gets resolved merge the code back to solution 1 (reverse integration). Point to be understood is only common projects need to be merged and everything else can be excluded.
Can similar setup be done in TFS?
Yes, this scenario is possible in TFVC, but not very common. You have a few options:
Create a branch root at the solution level and merge the files from solution one to solution two. As part of the merge operation exclude the files you don't want to merge. Later you can merge backwards and forwards at the folder level.
Create a folder relationship, but do not turn the folders into branch roots. This allows you to merge one folder with another folder at any time, but doesn't show these folders as branches per se
Create a branch root at each project level and merge each project individually. This has a couple of drawbacks (as you can't branch the whole solution in this case, as branch roots can't be nested).
Or you can approach the problem differently:
Create a separate solution that contains the common code and use package management (NuGet package publishing) to share the dependencies between both solutions (essentially creating 3 solutions).
Use workspace mappings to keep the common code in a single location in version control and map the code to different locations on disk. You can use compiler directives or configuration or different abstractions (interfaces, abstract classes) in code to compile the sources into different versions.
I got the exact solution which is more or less the first option Jesse you provided. Basically we need to create the common projects for one of the solutions and then branch them in another solution. At a later point in time we can merge them from solution 1 to 2 checkin the merged files in solution 2 and then merge from solution 2 to 1 and checkin the merged files in solution 1.
Related
Good Morning,
I am working on legacy code. This legacy code consists of multiple projects (language C with NI LabWindows CVI) and was never manged in a source control System but only in on folders. Over time it got a little messy and copies of this folder were created and changes were made to all folders depending the project that was built.
The result is, that there are 5 folders each containing different codes bases for what once was the same code. Also many files were modified in all folders because they are used in several projects. Each project was only build from 1 of the 5 folder (so project A was only build in folder 1, project b in Folder 4 etc.). It is not only raw code, but also user interface files.
I hope that was clear so far.
My task is to merge all the code into one one codes base (as it started of originally). And I would like to get some suggestions.
Here is the plan:
1. create baseline version of one folder that is supposedly that one with the most changes.
2. create GIT repository to store the code and all changes
3. go through all folders and merge files into baseline version using file diff software. (Folder 1 is baseline, merge folder 2 to baseline, merge folder 3 to baseline etc.)
Do you have any comments on this plan? What is good? Bad? Are there tools I can use?
This seems like as good of a plan as any. You have a mess on your hands either way.
If there are many changes to the user interface panels, that could be a headache. The UIR files are binaries, which will make git merges and diffs useless.
Go into each project and under Options->Preferences select the box to save .UIR files as .TUI files and save the project. This will give you a text file output describing the user interface and allow you to use diff tools properly.
EDIT
When the User Interface is active, you can directly select Options->Save in Text Format to do this as a one-off.
Good Luck!
It might also be worthwhile to use the UI to Code converter under CVI's Tools menu to convert all your UIRs to code. This should make them more compatible with text-based source control (like the save in text format approach), but may also ease the process of merging UIs.
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:
Is it possible to re-arrange sqlproj file somehow before EVERY check-in? Maybe there are somekind of options/tools that doing that already?
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:
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.
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.
Lock each environment until everything can promote together. Not realistic in most cases.
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.
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.
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...
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
What's currently the best way to version multiple subprojects of one root project in Bazaar?
I'm familiar with bzr-externals and scmproj. I'm more drawn to bzr-externals, since it allows to use builtin commands (I'm using Bazaar Explorer), however it seems to lack some features I would like.
My project looks like this:
CommonLibrary
ProjectA (uses CommonLibrary)
ProjectB (uses CommonLibrary)
However, I would like to be able to store some project-level files (and have them versioned too), because I'm working in Visual Studio (which needs solution file containing information for all its projects).
In almost all cases, I would like both projects to share the same common library.
Also, currently I'm versioning them all under 1 branch - however when I choose any of the above solutions, I will need to split them, but I don't know how (I would like to preserve all history).
What's best way to accomplish this?
In order to split your branch, look at the bazaar split command. It does the following: Split a subdirectory of a tree into a separate tree.
I also mainly use bzr-externals because it uses the builtin commands.
We just recently switched from TFS to Mercurial for our small team. The main project that 3 people work on is a Windows Forms application in C#. Every time you use the designer, even for simple changes, it does a whole lot of rearranging and changing to the .Designer file. If two people work on this file, even making simple changes, the merge is an absolute nightmare. Is there an easy way to solve this problem? In TFS, we turned off concurrent edits so we did not have this problem.
The problem is every time the code gen engine may generate code in different order!!! which makes merging a pain.
WinForm (.NET) designer, Swing (Java) designer rely on the code gen engine.
ASP.NET's designer.cs only contains backing field, which less likely to suffer.
WPF's backing field is generated in obj/*.g.cs, which is not required to keep in source control, so no merging problem.
Merges of these kind of files are always painfull... This is the reason why some "locking" extensions for Mercurial exists, so you can have the same workflow as with TFS if needed.
For example you can use the Lock extension written by Martin Geisler to lock .Designer files until the next push, doing so you will avoid any concurrent modification thus avoiding the merge also.
This is what I do:
Copy/Use .Desinger.cs from master/develop branch and open project in VS
Copy whole project (all files with .git) and checkout your_feature branch and open project in VS
now at this point you should have 2 instances of VS (one on master branch and one on your_feature)
Copy controls (ctrl+c) (in design view/mode) from one VS to another
not perferct solution but helps a lot
I am using Team Foundation Server (TFS) 2008, and am preparing to merge several TFS projects together, and I'd like to do this in the best way possible. All of these projects are within a single TFS instance.
I merging projects because the product line that is contained in all of the projects is small and is worked on by a single, small team, and so the projects themselves are simply unnecessary. Thus, I am trying to simplify our structure by merging the projects together. What this amounts to, I think, is a need to move the files from all projects into just one of the projects. But, I want to do this without affecting file history, etc.
I have tried researching this, and have found the following resources:
Moving files from one Team Foundation Project to Another
Moving files between projects in Solution Explorer removes source
control history, breaking merge capabilities
The second resource, a Microsoft knowledge base article, actually looks pretty useful. But, before I dive into this, I am just wondering what advice and/or warnings the SO community might offer? I am just hoping to go into this with my "eyes wide open."
Moves within Solution Explorer (and Solution Navigator from Productivity Power Tools) a move of a solution item will lead to a delete and add in version control.
But you can also move items either within Source Control Explorer or using tf.exe's move command from the command line. The latter can, of course, be automated with in a script if there are many items to move.