I have two branches in my mercurial repository that I want to merge. One is my default branch and the other is Bootstrap 3.3.7.
In my default branch I've customised the Less files. I replaced them with the vanilla ones from Bootstrap 3.3.7 and committed the changes to a new branch Bootstrap 3.3.7.
I'm currently on the default branch and want to merge Bootstrap 3.3.7 to that but when I do the merge instead of having merge conflicts that I can manually resolve (thereby preserving my edits), mercurial simply takes the file versions from my default branch, ignoring Bootstrap 3.3.7 files, even though I know there should be conflicts.
How do I do the merge so that I have the option of picking which changes I want.
In the attached screenshot I've filtered my repository to the relevant branches but my working directory is Rev 7097 on the default branch.
Related
I am using a named branch for a customer specific version. On this branch, I have some files that are customer-specific (Branding, logos,...). These files should never be merged to the default branch.
I want to make sure that these customer-specific files will never be merged in the default branch.
Is there a way to mark some files as branch specific in Mercurial?
No, not that I know of such feature. However, you can merge that branch once into default, taking care to merge into default only what you want to see merged (e.g. hg forget those customer files during the merge into default). In later merges those files you chose to forget in the default branch will be "only" show up with
remote changed customer which local deleted
use (c)hanged version, leave (d)eleted, or leave (u)nresolved? d
where you should choose 'd'. An example transcript of such exercise you can find in this paste
If those files are well-known and fairly stable, you could create a commit hook (client-side) and/or a pretxnchangegroup hook (server side) which checks those files not being present in any commit within the default branch, and which rejects the commit when any such file is committed to default.
You can use merge-patterns.
hg merge --config merge-patterns.somefile=internal:local otherbranch
I am working on a project with some mates.
Yesterday I cloned the project with the intention to add a functionality.
I have 2 local branches that are develop (the main branch) and pageContent (my feature branch).
The problem I am currently encountering is when I edit something on my feature branch, it automatically edits it on my developp branch too (I did not commit anything).
I checked out on my developp branch to delete the edition and when I checked out on my feature branch, the edition was deleted too ...
The branches seem to be auto-synchronised.
I checked out on my develop branch to delete the edition and when I checked out on my feature branch, the edition was deleted too ...
This is how git works.
In the following diagram you can see the 3 states.
Git has three main states that your files can reside in.
They are all shared between your branches. but when you checkout branch you change the HEAD so you end up with the staging area && working directory shared between your repository even when you checkout branches.
Since you did not commit (i assume that what happened) when you switch branches you see the changes following you to your new branch.
If you don't want the changes to follow you you need to commit (or stash) your work before switching to the branch.
How to checkout different branch with clean working directory and stage area?
If you wish to checkout clean branch without any "leftovers" in your working directory and staging are you can create a new worktree which will result in shared view of your repository (all the content is shared) but with a different working directory and staging area.
From git v2.5
git worktree add <new_path>
Now do whatever you want in any of your branches. It will create 2 separate working folders separated from each other while pointing to the same repository.
Using wortree you don't have to do any clear or reset in order to remove all your staged and untracked content.
Here is demo of how to do it:
Me and my friend need to develop a project parallely. how to do this?
I created two branch worked on each leaf. Tried to merge the leaves but getting conflict error for edited file. What is the way to merge them?
I would like to know if it possible to have 2 leaves in a single branch? If so then how to create a new leaf in addition to the default leaf.
Each branch has one leaf at any time. These represent the most recent state of the repository from the perspective of each branch. As your post mentions, branches are used to afford parallel developments within the repository. They are also created automatically (called a "fork" in such a case) to prevent two commits to same branch when each commit has the same immediate ancestor... allowing this would be just like having multiple leaves on the same branch.
To create a new branch of development, one opens a fossil repo and executes a command like:
fossil branch new some_feature trunk
Complete example
For the sake of example, I quickly created a new repository and added a single file to the trunk (the only branch initially), file.txt. The initial contents of my example file are:
here
is
a
file
After committing the added file with the comment, "create baseline", I created a development branch for a new feature called "some_feature" based on the current state (aka the leaf) of the trunk branch...
fossil branch new some_feature trunk
Now there are two branches, trunk and some_feature. Creating the branch does not change my working branch, so I am still in trunk. Then I edited the baseline file to:
here
is
a
file
folder
...adding "folder" to the end. Then I committed the change to trunk with the comment, "modification on first branch... trunk. Then I switched development to the some_feature branch...
fossil co some_feature
From this second branch, I also edited the last line of the baseline file:
here
is
a
file
reader
...adding "reader" to the end. Then I committed the change to some_feature with the comment, "modification on second branch... some_feature".
To merge development, you chose the branch you want to merge changes into. In this case, I will merge the feature branch changes into the trunk. To do this you must first checkout the destination branch for the merge... in my case, trunk.
fossil co trunk
Then, I merge in the change from the specific commit of the other branch. In my case, I'll use the leaf of that branch:
fossil merge some_feature
MERGE file.txt
***** 1 merge conflicts in file.txt
WARNING: 1 merge conflicts
"fossil undo" is available to undo changes to the working checkout.
This leaves me with four files now in my working directory instead of one. No new commit/checkin has actually made it back to the repository proper. The four files are: file.txt, file.txt-baseline, file.txt-merge, and file.txt-original. "file.txt-baseline" is the file as it existed in the most recent common ancestor of the merging branches. "file.txt-original" is the file as it existed in the target brach, in my case, trunk, just before the merge. "file.txt-merge" is the file as it existed in the branch you were merging from, in my case, some_feature. Finally, "file.txt" contains the contents of the baseline file with conflicting changes from the original and merge files annotated so you can decide how to deal with the differing contents.
In my case the generated conflicts file, "file.txt" looked like this:
here
is
a
file
<<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
folder
======= COMMON ANCESTOR content follows ============================
======= MERGED IN content follows ==================================
reader
>>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Until the merge conflict annotations are removed from the file, fossil will not let you commit (or it will at least warn against it). Otherwise, you would make a commit with message, such as, "merged some_feature into trunk".
For reference, here is the event history diagram as provided by fossil for this example:
I am having a major issue with clearcase merge:
I have a list of files taken from clearcase long time back and updated outside clearcase. In between, the same files have changed in clearcase as well. Now, I created a new branch and checked in the updated code from outside in the new branch.
But when I want to merge from new branch to integration branch, it automatically merges and overwrites the changes in integration branch with the changes from new branch. What I would have expected it to atleast raise a conflict and not wipe out the changes made in clearcase integration branch.
can anyone help here please?
You need to be careful from which version you are starting your new branch.
If you are starting a new branch from the LATESt version of the current branch, in order to:
clearfsimport your code modified outside of ClearCase
merge said new branch to your current branch
Then, yes, all changes will overwrite the current versions.
But if you make your branch from an older version (a previous label or UCM baseline), import your code there and merge, then the merge will work or generate conflict if appropriate.
In other words, you need to start your branch from what you estimate is a common ancestor for your merge to work.
See "Rebasing and merging in ClearCase":
.
Our team uses Eclipse to develop a software product, and recently we switched to Subversion to do our source control/version management. At first our team was still committing directly to the trunk as we were new to Subversion's way of source control and things needed to be drawn out still.
At some point I made my first real branch from the trunk to do development for a specific project within our product. Suppose the branch is called DEV_PROJ.
Later as our team knew better how to work with Subversion from Eclipse, I put the team on our first real development branch, not for a specific sub-project but to keep track of different versions. Suppose the branch is called DEV_VERS. Now we are working on that branch and no longer committing directly to the trunk. DEV_VERS was branched from the latest version of the trunk and there have been no commits to the trunk since then.
In between the two branches about two/three months passed and there have been a lot of changes to the trunk before I made the version branch. Now the time has come for me to merge the changes from DEV_PROJ to the DEV_VERS branch to incorporate the project in our new version branch.
What I did first was merge the latest version of the trunk to my DEV_PROJ branch (forward merge?), thinking that would minimize the difference between the two branches while keeping the changes specific to the project.
What I'm trying now and what I'm having problems with is merging the DEV_PROJ to the DEV_VERS branch. Right-click, Team/Merge my DEV_VERS project to start the merge, there are three tabs to choose from: URL, 2 URLs, Reintegrate. As far as I know this is not a reintegration merge, that would be from branch toward the trunk and not between branches that are not directly related. I also don't need to merge two branches towards my branch so I skip 2 URLs tab.
So I choose the first one, URL. As the source I take my project from the DEV_PROJ branch, Revisions: Start from copy, Depth: Working Copy. In a second try, I also chose to Ignore Ancestry. Both tries I push the Preview button to get an overview of what files are target for merging.
What I see is that there are a lot of files that are candidate for merging, that have not been changed in my DEV_PROJ branch. So the (subversion) merging process sees a lot more merging candidates than I had expected. The files I added to the DEV_PROJ branch appear as "Added", but a whole lot of files that I know I didn't change in that branch appear as "Modified" or "Tree Conflict" in the merge overview.
My questions:
Is this the right way to merge between branches? If not can it be done directly using the merge menu (URL, 2URLs, Reintegrate)?
Is my first step (forward merge trunk to DEV_PROJ) the reason why there are merge candidates that were not supposed to be there?
If there is no direct way of merging these branches correctly, then I only see one option. That is merge the DEV_PROJ to the trunk (reintegrate), and then merge the trunk towards the DEV_VERS branch (forward merge). Would this be the right way to do this? If so, is it the only way to do this?
Eclipse: Helios Service Release 2, build: 20110218-0911
SVN server: 1.6.15
Eclipse SVN plugin: SVNKit 1.3.2 (2.2.2.I20100512-1900) // SVN Connector (2.2.2.I20100512-1900) // SVN Team Provider (0.7.9.I20100512-1900)
If I understand your question correctly, this is the state of your project:
_________________ B DEV_PROJ
/
A /
---------------------------------- trunk
C \
\_____________ D DEV_VERS
And you want all changes from A -> B in your DEV_VERS branch.
If so, what I would do is the following (the following is the command line equivalent, but it should be easy to find the Eclipse SVN GUI equivalent):
Find the revision of A:
svn log --stop-on-copy URL_OF_DEV_PROJ
The earliest commit revision number is the revision number of point A
Find the revision of B:
Assuming you want to merge all changes in the DEV_PROJ branch, the value of B is simply HEAD
Checkout DEV_VERS:
svn co URL_OF_DEV_VERS
Inside the directory of the checked out code from step 3, merge the changes from A to B as follows:
svn merge -r<RevisionOfA>:HEAD URL_OF_DEV_PROJ .
In short, what you're doing is taking the difference between A and B and merging it to DEV_VERS