My main branch has some files that have different codes from the same file of development branch. The development branch is the one that has the correct version of these files but when I am trying to merge it to main branch(target); I am getting a message saying
There was no changes to merge
How can I resolve that problem so that the main branch has the correct version of those files?
When merging files TFS doesn't just look at the differences between the two branches, but it also keeps track of whether you've ignored these changes in a previous merge attempt. When merging TFS offers you 3 options when there are conflicts:
Merge
Keep Source
Keep Target
When you pick Keep target or when you manually merge and deselect certain changes, TFS will mark these changes as "resolved" and will not offer them again when you try to merge in the future. This is called a "merge credit".
You can also create these issues using the commandline when using tf merge /discard which will tell TFS to ignore the changes in those files/changesets when considering merges.
There are two ways to force TFS to reconsider these changes:
Use force merge. On the commandline you can initiate a merge in which TFS will temporarily ignore it's records and will offer you every different file for merging. This can be a lot of work, but once done your merge history will be back in shape. To issue a force merge run tf merge $/Source/Folder/File $/Target/Folder/File /force /version:T This will almost certainly raise a merge conflict which you can resolve to get the right changes in the target branch.
Undo the previous merge using Rollback. If you've recently done the merge in which changesets have been discarded. Find it in the history, rightclick the changeset and pick Rollback and check in the code that has been undone. This will actually remove all of the changes in that changeset and will reset the "merge credits". Once this has been done you can redo the merge and do it right this time. This can also be done from the command line using tf rollback
Related
Database team is implementing code changes, using Visual Studio SSDT database projects with Git source control. Everyone is pushing to main Release branch with code review (only 5 developers on the team). All the database coworkers are only allowed pushing to different files only (tables, sprocs, functions), etc. The way work is assigned, none of us push or work the same sql file. Eventually all good changes from Release (currently in Work) are merged into Master branch (Production Ready).
Code Review ---> Push to Release Branch (Currently in work during Sprint) ---> Merge to Master Production Ready Branch
(a) What are the negative consequences of utilizing this strategy in Git?
(b) For cleaner history, should everyone Rebase ReleasePublic Remote into ReleaseLocal, or conducting Pull? (Fetch/Merge), I would think Rebase is answer for cleaner history.
Note: I agree, it would be annoying only if we are working on the same file and pushing changes. Alternative Strategy to create different feature branches and then merge into main branch. We are refraining from this strategy since each developer has 10 dba admin related changes a day, creating many branches and merges is time consuming and cumbersome-
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
Devops
The bottom line is if it's working for you then it's working.
The purpose of the source control solution is to assist you in producing software.
Use this setup until it doesn't work and then adjust. (Please note that all 5 of the devs could start using feature branches, if they want/need, without interfering with the other team member's flow).
Having said that there are consequences of using a single branch. Here are two examples
Releasable main/release branch
One of them could be shown in a following scenario:
A release happens
A commit with a bug in file A is committed
A commit file B is committed
You want to release the changes made to file B\
Now you don't have a releasable snapshot of the repo
If the changes for file A were tested in a feature branch then master/release branch is in a releasable state more often.
Pull requests
Having feature branches allows to use Pull Requests (which is a layer on top of git) better - your code reviews may be get easier to enforce and track.
What is the Clearcase equivalent of git's no fast forward (--no-ff) switch? Or how can I achieve the same functionality?
BACKGROUND
The situation is we are running multiple release branches and we need to be able to pull a feature or defect fix from the release branch if required. Currently (and I'm not the one managing Clearcase) all defect work is checked directly into the release branch, so backing out changes is time-consuming and potentially error-prone.
When using git with --no-ff, I can back out a feature or defect very quickly with minimal chance of causing an issue.
In ClearCase, you would instead cancel an activity (if you are using ClearCase UCM), or cancelling merges for a set of files with negative merges.
But there is no notion of "fast-forward": there is no HEAD to move, only versions (file by file) to merge. So if you know the merged versions, you can create new versions which cancel them (that is what the negative merge does).
There is no ff but there is also no HEAD in clearcase in the sense of git. The workflow is different. You always check in your code to a new checkin (or commit in git terminology). So it is like you are always doing a merge commit
I was experimenting in the ClearCase merge manager and mistakenly merged one file to another file (which turned out to be parent of the file).
I want to revert it back now.
How to cancel that merge for that specific file?
All you need to do, if you haven't yet completed the merge is to:
undo checkout the merged checked out version in the destination view (the view used to make the merge)
relaunch the merge manager.
You will see that, during the second execution of the merge manager:
any version already merged will directly be displayed as merged
the version you undo checked out will again be listed as to be merged.
I know this post is old, but perhaps adding an additional detail will be useful to future users as it was to me.
In add one detaul to VonC's answer, I saved my merge before re-launching the merge manager, and hit Resume upon re-launch instead of New.
This approach worked as VonC said.
A bit complex to describe, but I'll do my best. Basically we're using the Git workflow, meaning we have the following branches:
production, which is the live branch. Everything is production is running in the live web environment.
integration, in which all new functionality is integrated. This branch is merged to production every week.
one or more feature branches, in which developers or development teams develop new functionality. After this is done, developers merge their feature branch to integration.
So, nothing really complex here. But, since our application is a web application running against a MySQL database, new functionality often requires changes to the database scheme. To automate this, we're using dbdeploy, which allows us to create alter scripts, given a number. E.g. 00001.sql, 00002.sql, etc. Upon merging to the integration branch, dbdeploy will check which alter scripts have a higher number than the latest executed one on that specific database, and will execute those.
Now assume the following.
- integration has alter scripts up until 00200.sql. All of these are executed on the integration database.
- developer John has a feature branch featureX, which was created when integration still had 00199.sql as the highest alter script.
John creates 00200.sql because of some required db schema changes.
Now, at some point John will merge his modifications back to the integration branch. John will get a merge conflict and will see that his 00200.sql already exists in integration. This means he needs to open the conflicting file, extract his contents, reset that file back to 'mine' (the original state as in integration) and put his own contents in a new file.
Now, since we're working with ten developers, we get this situation daily. And while we do understand the reasons behind this, it's sometimes very cumbersome. John renames his script, does a merge commit to integration, pushes the changes to the upstream only to see that somebody else already created a 00201.sql, requiring John to do the proces again.
Surely there must be more teams using the Git workflow and using a database change management tool for automating database schema changes?
So, in short, my questions are:
How to automate database schema changes, when working on different feature branches, that operate on different instances of the same db?
How to prevent merge conflicts all the time, while still having the option to have a fixed order in the executed alter scripts? E.g. 00199.sql must be executed before 00200.sql, because 00200.sql might be depending on something done in 00199.sql.
Any other tips are most welcome ofcourse.
Rails used to do this, with exactly the problems you describe. They changed to the following scheme: the files (rails calls them migrations) are labelled with a utc timestamp of when the file was created, eg
20140723069701_add_foo_to_bar
(The second part of the name doesn't contribute to the ordering).
Rails records the timestamps of all the migrations that have been run. When you ask it to run pending migrations it selects all the migration files whose timestamp isn't in the list of already run migrations and runs them in numerical order.
You'll no longer get merge conflicts unless two people create one at exactly the same point in time.
Files still get executed in the order you wrote them, but possibly interleaved with someone else's work. In theory you can still have problems - eg developer a decides to rename a table that I had decided to add a column too. That is much less common than 2 developers both making any changes to the db and you would have problems even not considering the schema changes presumably I have just written code that queries a no longer existant table - at some point developers working on related stuff will have to talk to each other!
A few suggestions:
1 - have a look at Liquibase, each version gets a file that references the changes that need to happen, then the change files can be named using a meaningful string rather than by number.
2 - have a central location for getting the next available number, then people use the latest number.
I've used Liquibase in the past, pretty successfully, and we didn't have the problem you describe.
As Frederick Cheung suggested, use timestamps rather than a serial number. Applying schema changes by order of datestamp should work, because schema changes can only depend on changes of a prior date.
In addition, include the name of the developer in the name of the alter script. This will prevent merge conflicts 100%.
Your merge hook should just look for newly added alter scripts (present in the merged branch but not in the upstream branch) and execute them by order of timestamp.
I've used two different approaches to overcome your problem in the past.
The first is to use a n ORM which can handle the schema updates.
The other approach is to create a script, which incrementally builds the database schema. This way if a developer needs to an additional row in a table, he should add the appropriate sql statement after the table is create. Likewise if he needs a new table, he should add the sql statement for that. Then merging becomes a question of making sure things happen in the correct order. This is basically what the database update process in an ORM does. Such a script needs to be coded very defensively, and each statement should check if its perquisites exists.
For the dbvc commandline tool, I use git log to determine the order of the update scripts.
git log -c --no-merges --pretty="format:" --name-status -p dev/db/updates/ | \
grep '^A' | awk '{print $2}' | tac
In this case the way the order of your commits will determine the sequence in which the updates are run. Which is most likely what you want.
If you run git merge b, the updates from master will be run first and than from B.
If you run git rebase b, the update from B will run first and than from master.
Environment
TFS 2010. Three branches: Main, Development and Release.
Question
I would like to easily retrieve a list of changesets that have not been fully merged into all three branches.
For Example
Lets says I have a changeset, 100, that was a bugfix and checked in directly into Release. I can use the Tracking feature to visualize that it exists only in Release.
But that requires me to know to look at that changeset. I'm looking for a generic list that would show me any changeset that exists in one branch, but not in all three.
What I know
I know I can compare Release to Main to see the differences. Is that my only option?
I try to associate changesets with work items, so I could query a list of non-closed work items and then as a 'rule', I could verify that a changeset has been fully merged before closing it. And perform code compare to verify.
From the Developer Command Prompt, you can also use the tf.exe merge command.
tf merge /candidate /recursive Release Main
will show you all the changesets that were made to Release but haven't been merged into Main.
You can get a simple list of changesets through the IDE by choosing the "Selected Changes" option when merging things onto a build.
Another option is to use the API. VersionControlServer has a property named GetMergeCandidates which returns an array of MergeCandidate which has the changeset and if it has been partially merged already as properties.