We're using Mercurial to manage a project that has two teams working on it. Our team manages the repo, and we're using hg flow on it, with default, develop and feature branches. The other team does their work in a separate repo, with us pulling in their changes every now and then.
The other team isn't particularly up to speed on Mercurial, and they've wanted to do their work on the default branch. This makes pulling in their changes annoying, because we'd like to keep our default branch clean.
We've done what Ned Batchelder suggested in http://nedbatchelder.com/blog/201111/advanced_mercurial_branches.html, but that still leaves commits in our repo with their branch marked as default. So does using Bitbucket's pull requests.
Other options that spring to mind are using patches or using graft and strip. I'd love to hear suggestions that would be less hassle.
If you want "Hard way, but nice results" you have to forget about easy pure-Bitbucket interface of syncing repositories
With Convert Extension --branchmap option you can rename any branch in source repository into any name. Thus, your workflow will be something like:
Prepare file for branch-mapping
Clone|pull from fork to local repository
Convert cloned repo, using branchmap, into repository with good naming of branch(es)
Push result of convert into your Bitbucket0repository
Or consider using bookmarks instead of named branches. Then you can move their changesets into your develop bookmark without any of its past default-ness showing through.
hey're not entirely crazy for wanting to develop in the default branch; it's the standard advice: https://www.mercurial-scm.org/wiki/StandardBranching#Don.27t_use_a_name_other_than_default_for_your_main_development_branch
Related
We have three developers working on a microsoft visual studio project that is being hosted on Github but we are using the VS Github extension tool.
We are a little confused about how many branches are necessary for our project.... This is what we have right now.
Master Branch -> Development Branch.
The idea that we are currently working with, is that we will each individually make changes, and then push up to the Development Branch to test with. When Coder 1 makes a change, Coder 2 and 3 will see the change and can merge their projects with the Dev branch and vice versa- so we stay in sync.... Then when we are comfortable with the changes, we merge Development Branch into Master Branch.
We are wondering if we need more branches, or if more branches would be userful....
For example what if we had:
Master Branch -> Development Branch -> Coder1 Branch, Coder2 Branch, Coder3 Branch.
Is there any benefit to adding more branches? We only have three coders and are wondering what the setup should look like.
Thanks!
With only three programmers, I believe everyone can work on the development branch at the same time as long as there's proper communication on what parts each are working on. Everyone can work on the development branch and when it's time to push their own changes, I advise:
git stash, which will put your changes into a temporary stash and revert back to HEAD, pretending like you did not change anything
git pull, which will pull the others' changes
git stash pop, which will bring back your own changes. This way, you can build "on top" of other people's changes. If there's a merge conflict, "local" will be the other person's changes and "remote" will be your own changes.
But if you really want to be safe and formal, separate branches for each person can work, and using GitHub's page, it's easy to implement a pull request and do code review.
All in all, it just depends on how formal you want it to be.
Keeps track of files in eclipse, who made changes on which branch
Hello Guys, I am using BitBucket for project management, and i Create different branches as per features. Multiple teams works on their own branches and some time multiple teams make changes in same file.
So at the time of release I have to merge all the created branches in one major branch, but at time of merge i get a lot of merge conflicts,
So basically what i want, when developer going to make changes in any file, dev will get to know all submitted changes in another branches for this same file, (where dev going to make changes), So he or she will know the possible scenarios.
An alternative is to ask for a developer to rebase his/her own branch on top of the main branch first.
Then you can merge that branch easily enough.
That way:
if there are any conflicts, they are detected and resolve by the developer (who knows best how to resolve it)
each merge is a trivial one.
I have been doing all my work on the master branch. Since I created my project and pushed it into my Github repository, I have been the only one working on it so I have had no need to fetch.
I want to work on an experimental feature, so I want to create a new branch. When I go to "Team -> Switch To -> New Branch" I see this:
It mentions creating a branch based on a local branch. I have read EGit Local vs. Remote repositories but to be honest I am quite confused by it. I'm not sure if I should be fetching or cloning because both are mentioned there, and even then I'm not sure how I would do it (like I said, as I am the only contributor to this project all I've had to do so far is commit and push).
And even then, I'm not sure if Rebase, Merge, None should be my pull strategy as shown in the screenshot?
I was hoping I could just create a new branch, commit and push like I normally do and then switch back to my master branch when I didn't want to work on my experimental feature. It seems like it's much more complicated than that.
I'd like to be able to do this through Eclipse so I learn how for the future, but will it be easier if I just do this on the Git command line? Thanks in advance.
It sounds like what you want is to create your (local) branch based the remote/origin master (use the drop-down list at the top) and then select Merge as your pull strategy. That way when you are working on the branch and pull, it will pull from master and merge any changes directly into the branch. It also allows you to push the branch to remote, which give you another level of safety in case your local repo gets lost or messes up somehow.
Another piece of advice I've learned the hard way: whenever I'm about to do something with git that I'm not totally confident about, I make a quick ZIP or copy of my local repo. That way it's easy to throw away whatever I did and go back to a good state. Sad that git drives us to such measures, isn't it?
I am new to Perforce and find it really hard to follow its workflow..
I have used Mercurial before (not in any advanced ways), but what I lack most in Perforce is the idea of named branches.
Let me explain what I'd like to do:
I get the latest revisions of all files and want to work on a new feature/story/task..
I create a brach, say "Feature 3021"
I code, save changes in this branch (hg commit)
I can save changes to a central server (hg push)
When I'm done coding, I merge the changes from "Feature 3021" with the main branch (default, master, etc.) - after that the main branch has the code I wrote
I can close the named brach ("Feature 3021") so that further commits are not possible.
I don't need this exact behavior in Perforce, but something analogous. I know that Perforce is centralized, so the commit-push step would be probably one, but this is a minor problem here.
All I care is to be able to save my work in version control at any time, even if it's not 100% ready - perhaps to a different branch. I'd also like other users to be able to be able to get my code (from this different branch), but only if they want this - the default branch should stay unafected as long as I don't merge my changes with it.
Is it possible? I am using Server 2012.2
Can you upgrade to Server 2013.1 or later? There's a great feature there, called Task Streams.
Here's some references:
http://www.perforce.com/blog/130627/task-streams-even-if-you-are-classic-perforce-shop
http://www.perforce.com/blog/130206/task-streams
http://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html
The analogous flow in Perforce would be:
Maintain a main-line "branch" at some path, say //depot/default
To create a feature branch, integrate from //depot/default to //depot/feature-3021
Work under //depot/feature-3021 and submit
When you are ready to merge back, integrate //depot/feature-3021 to //depot/default
Regarding closing the branch after its use, there are a couple of options that I can think of. You could either change permissions or simply delete it. The delete could always be recovered.
Also note the paths don't need to be at the same hierarchy. A more reasonable branch strategy might use paths like this.
Main-line: //depot/default
Developer branches: //depot/dev/${user}/${feature}
Suppose I have the following senario:
Trunk is my main development line where programmers commit to when done.
Branch V1.0 is a branch I created when releasing version 1.0.
The programmer is working on the trunk but needs to switch to the branch in order to fix bugs.
When switching back to the trunk Subversion will give me the latest in the SVN repository which does not include the recent changes.
So, in order to switch he will have to commit what he has because otherwise the changes are "lost". I know they are still kept in the local repository but it would still mean restoring them one by one once he switchesback.
Am I missing something here?
Edit:
Now I am thinking down these lines:
Each programmer would have his own "private" development branch off of the trunch. He could commit to there whenever he wants. When he has finished what he has written he can them merge it into the trunk. He starts again for the next assignment.
If at any point he is required to fix a bug in some other release he can just commit to his own private branch, fetch the odl release and fix it. Then, after committing the changes to the fix, he can easily switch back to his own development branch.
Would that work?
I think that subversion is not thought for switching as you described. A solution would be to have two workspaces, one for the branch and another one the trunk, so you can switch from one to another without problems. I know it is not a nice one.
Consider switching to a version control tool that is better suited for your approach. My own suggestion is Mercurial, coupled with MercurialEclipse. The only drawbacks I'm aware of are that Subversion is better suited to store binary files and that Mercurial's subrepositories don't work so well as Subversion's externals.
In Mercurial your programmers would be able to commit their changes to their private repositories, merge and commit locally again, and then push the resulting changes to an official repository, from which other programmers would pull them into their own private repositories.
The best solution for such purposes is to have two separate working copies. One for working with trunk and one working with the branch.