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:
Related
I am new to Git. I have checked new remote branch at my local. As I am checking out a new fresh branch from remote, I don't expect any local changes in the files of my repository.
But somehow few files show changes. I am using Git on Eclipse IDE.
Why is so? Have I misunderstood the concept of new fresh branch checkout?
Update
Based on comments by Tim Biegeleisen and Sajib Khan my understanding was wrong as it is expected behaviour when you check-out remote as a local branch any previous uncommitted changes in the working directory ( Repository ) will carry to the newly checked-out local branch.
Just to put in simple words let me explain with example
Think that your working in master branch and add some new file (Eg file1.txt and file2.txt). Now you don't stage or commit these 2 files then it will be shown as untracked files.
Master Branch
Untracked files
file1.txt
file2.txt
At this particular point of time you switch to another branch then the files which were untracked will be shown in the newly checkout branch.
To over come this problem you can go for the following 2 ways
Stash the files from master branch and then switch to another branch, now it wont show the untracked files of master in newly switched branches. Stashing is nothing but saving the files and then reusing those at later point of time.
commit amending
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
The situation:
Several branches I constantly have to merge between them. Each branch has a special file that identifies the branch (with certain settings for commit mails, plugin options and more, doesn't matter here).
The problem:
Whenever I merge one branch to the other and this special file has been changed it will obviously overwrite the merge target file. But I don't want this to happen. Those files must be version controlled in their branches as they are an essential part of it, but they should not be merged at all as they contain branch specific information.
The question:
Is it possible (and how) to exclude a specific file from a merge? I'd like a solution that doesn't requier me to specify this on each merge as a paramter, but if there's nothing else then I bite the bullet.
The only way to exclude a file from a merge is to revert it right after the merge, before you commit, for example:
cd /path/to/repo/trunk
bzr merge ../branchA
bzr revert file/to/exclude
bzr commit -m 'merged from branchA'
Later, when you merge again from branchA, the bzr revert step in the middle is only necessary if the file changed in branchA since the last merge. So if the file doesn't change very often, then "biting the bullet" might not be all that bad.
I have a branch which have 2 new files .I want to merge those files to another branch - NOT trunk?
Is it actually merge ?- because the new files are not in destination branch
I tried to do a check out of branchB and try to merge the files from BranchA
but gives me some error .What is the proper way to do it?
One more question - If i check out an existing branch , is it creating a new branch or
just its copy in my local system?
Just Checkout the branch that you want to add the files and add them manually then commit. trunk or any other folder is treated the same. It's just a folder.
Checking out will copy files from server into your local system. depending on destination in your system it will copy new files and/or will give you warning if there are modified files in the destination.
If you have many files checked-in in branch A with revision number Ar, Now if you want to merge this revision Ar from Branch A to Branch B,
Simply checkout the branch B, inside src, right click -> SVN Tortoise -> Merge
Select the cross branch merge radio button (first one) , and give in the Branch A src URL, also give the revision number you want to merge into Branch B from Branch A.
Click the Test Merge button, to mock the merge
If all goes well, hit the actual merge button
My current SubVersion workflow is like so:
The trunk is used to make small content changes and bug fixes to the main source code.
Branches are used for adding/editing enhancements and projects.
So, trunk changes are made, tested, committed and deployed pretty quickly. Whereas, enhancements and projects need additional user testing and approval.
At time, I have two branches that need testing and approval at the same time. I don't want to merge to the trunk and commit until the changes are fully tested and approved.
What I need to do is merge both branches to one working copy without any commits.
I am using Tortoise SVN, and when I try to merge the second branch, I get an error message:
Cannot merge into a working copy that has local modifications
Is there a way that I can do this without committing either merge?
You currently have the trunk and 2 branches A and B (which are both branches from the trunk). I suggest you create yet another branch called AB as follows:
Switch your working folder to the trunk, if not there already
Update the latest and make sure you have no local modifications. If you do, either commit them (to the trunk) or revert them as appropriate.
Do one last update of your working folder from the trunk. Note the revision number you have updated to (call it revision R).
In the repo, copy revision R of the trunk to a new branch called "AB" (Do not switch your working folder to AB yet)
Merge your working folder with A.
Switch your working folder to AB.
Commit your working folder (to AB) and update (from AB).
Switch your working folder to the trunk.
Merge your working folder with B.
Switch your working folder to AB.
Commit your working folder to AB.
Test, and commit any fixes to AB.
When it's working and you're ready to merge everything to the trunk, do a final commit (to AB), then update your working folder (from AB).
Switch your working folder to the trunk.
Merge your working folder with AB
Test and fix
When it's working, commit working folder to the trunk.
Go out for beers
We had a similar workflow at one point. The solution I finally landed on was to keep multiple local copies, basically one per branch. Got a bit dicey at times with shared databases but overall it was very successful.
you can checkout another copy of the branch you want to merge into at a different place on your local drive, merge into it and then commit it. Then delete the whole 2nd working copy and return to your current task.
But it does seem that you are trying to subvert your own working practices - unless you want to just merge 2 branches together to commit all the work simultaneously and delete the 2 old branches... but then, what's stopping you from committing to them and merging normally in such a case?
Every merge operation is done in your local sandbox. You do not have to be worried until you commit some junky code.
I don't know the whole deploy process you do but what you can do is:
switch to branch A
merge branch A with branch B
build the app, deploy and test it
If all works fine you can commit all changes (you are on branch A). Then you can switch to trunk and merge with branch A. After all conflicts are solved you can commit on trunk and that is all.
Eric, " I may want to only deploy one change at a time..." and "merge two branches to one working copy without committing" are incompatible requirements: or you'll test branch after branch or mix two branches in one big mix.
Version A Anyway - you can merge any node with any node inside repo-tree, not only somebranch with trunk. I.e., in common, #JoelFan workflow is good, but - require less actions
copy HEAD of trunk to AB
Merge AB with A
Commit mergeset, test etc...
Merge AB with B
Test merged results
Merge to trunk and delete temporary AB-branch
Version B is 2-URL merge. svn help merge, "2-URL Merge Example" part as start. You can merge 2 independent branches into third in one command merge BRANCHA[#N] BRANCHB[#M] [TRUNK_WCPATH]