![]() Understanding Distributed Version Control Systems.Understanding and Eliminating Technical Debt.Building Serverless Applications in Azure.Azure Container Instances: Getting Started.Microsoft Azure Developer: Implement Azure Functions (AZ-204).Versioning and Evolving Microservices in ASP.NET Core.Microservices Architecture: Executive Briefing.Microsoft Azure Developer: Deploying and Managing Containers.Most people who fork can just ignore the maintenance branch and work exclusively in the default branch (I can always use hg transplant to move a fix into a maintenance branch). So with NAudio I am thinking of creating a single maintenance branch for each major release (only created when it is needed). Their use is mainly limited to short-lived, experimental branches.īookmarks are appealing as they are closest to the git philosophy, but because Mercurial requires you to explicitly ask to push them, and there can be naming collisions, I think they are best used simply as short-lived markers for local development (I might do another blog post on the workflow for this). I’d either have to create a new project for each NAudio maintenance branch, or create a fork, but both options would cause confusion.Īnonymous branches are a bad idea because you open the door to merge the wrong things together, and it’s hard to keep track of which head relates to what. This is because CodePlex allows only one repository per project. I actually think that branching with clones is easier for users to understand than named branches, but for NAudio it is not a viable option. Here’s a screenshot of a repository which has had the steps above performed on it: With your repository in this state you still have two branches (default and v1.0 maintenance) which you can continue work on separately. hg update defaultĪnd that is pretty much all you need to know to work with named branches. How do we do that? Go to the default branch and ask to merge from the maintenance branch. We have a few bugfixes now in our v1.0 branch, and we’d like to get them into v2.0 as well. Step 6: Merging from maintenance branch into default get onto the branch we are merging into hg merge won’t do anything if you are still on the default branch, as it knows that the contribution is on a different branch): hg pull bugfixfork Now we can do the same with the contribution on the maintenance branch (n.b. need to be on the default branch to merge it is often a good idea to use a local integration clone so that if you want to reject the contribution you can do so easily). Hg commit -m "another v1.0 bugfix after the fork"įirst, lets pull in the new v2.0 feature (n.b. Hg commit -m "another change on v2 after the fork" If our contributors issued pull requests now, things would be nice and easy, but let’s imagine that more work has gone on in both branches in the meantime: hg update default Their commit will me marked as being on the v1.0 maintenance branch (as named branches are stored in the commits, unlike git branches which are simply pointers to commits) Step 5: Accepting Contributions Hg commit -m "contributing a bugfix for v1.0" Our second contributor is offering a bugfix, so they must remember to switch to the named maintenance branch (they can use hg branches to see what branch names are available): hg clone public-repo-address my-bugfix-fork Hg commit -m "contributing a new feature in v2" Our first contributor makes a clone, and is contributing a v2 feature, so they can simply commit to the default branch: hg clone public-repo-address my-feature-fork Imagine at this point, we have a couple of contributors, who want to fork our repository and make some changes. To get back to working on our main branch (which is called the default branch in Mercurial), we simply use the update command: // get back onto the v2 branch: branch will be created when we commit to it We’ll create a branch by going back to the v1.0 commit (revision 1 in our repository) and using the branch command // go back to v1 release Now we’ve had a bug report and need to fix version 1, without shipping any of our version 2 changes. Now we’ve released version 1, let’s start work on version 2. We’ll start with a fresh repository with just two commits hg init I’ll explain at the end why I’ve decided that named branches are the best option for NAudio. In this article I will walk through the process of how you can use a named branch for maintenance releases, and the workflow for both contributors and for accepting contributions. For a good comparison of these techniques, I suggest reading Steve Losh’s Guide to Mercurial Branching, which explains it well although is a little out of date now. Mercurial offers a variety of approaches to branching, including “named branches”, “bookmarks” (most similar to git), “anonymous branches” and using clones.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |