I've accidentally created a branch with the wrong config spec and I've made a merge in there that wasn't meant to be done. Is there a way to remove this branch like it never existed, with one and only command? There are no checked-out files in the branch.
I could go through all files and do it manually since there are only 3 files that were merged. But what if there were 3000 instead of 3?
You can try and delete the byrtpe (branch type) with cleartool rmtype brtype:xxx.
That is possible only if you are talking about a brand new branch, which was used only in this instance (that is, where you need to delete all instances of that branch type: an instance of a branch type is a branch created to reference a version at a checkin).
Then (if the only versions in that branches are the wrong merged ones), you could do:
cleartool rmtype -rmall brtype:yourBranch#\avob
Again, that is a dangerous command, and should only be used for a new branch with a few versions.
The -rmall will first remove all branch type instances (ie the actual branches, and their associated versions and labels).
Then the branch type itself will be removed.
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
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.
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:
How can I resolve this merging issue ?
My project has 1 branch which I used for production and head. 2 times it worked merging production branch into head. Each time I created a tagged head after merging to have a start point for the next merge. Its important to note that I do not create a new branch after each merge, I reuse the branch.
The problem is, if I try to merge my branch to head. eclipse cvs acts like it is comparing and listing all files as "to update", even if file head version is greater than the file branch version.
ex: head file version is 1.8 and branch file version is 1.6. This file was already merged in last merge. When trying to merge I specifiy as "common base version" the head tag that I created after the last merge. Still, eclipse cvs suggests to override head modifications and use the branch version. This behaviour applies to all files.
I dont know what to do. I dont want to manually merge hundreds of files.
thanks for any help
Look at the example:
|tag_h1 |tag_h2
-----------------------------------------> trunk
\ ^ ^
\ / /
\----------------------------------> my_branch
|tag_b1 |tag_b2
On branch there are tags tag_b1 and tag_b2 before each merge, and in trunk, tags tag_h1 and tag_h2.
For a next merge from branch to trunk, the "common base version" of Eclipse will be the one tagged with tag_b2. With CVS update, if you specify two parameters, you will get modifications between these two merged in your working directory. Giving Branch or version to be merged (end tag)=my_branch and Common base version (start tag)=tag_b2 will merge changes from tag_b2 until my_branch end, like calling CVS from command line:
$ cvs up -j tag_b2 -j my_branch
I always tag from where I will merge, and before and after the merge, like this:
|tag_before |tag_after
--------------------------------->
^
/
------------------------------>
|tag_from
Giving the tags a name I can recognize.
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]