![]() Merging in this context simply means that the changes made on the experimental branch will be applied to the relevant files in the main branch. We can also see this in the graphical interface by right clicking in the folder where the file resides and selecting “Hg Workbench”.Īt this point we could continue to experiment on the modified code, or if we are at a good stopping point, we can proceed to merge the changes back into the main (or “default”) branch. Summary: Finished enhancement to also show locks / blocks on database principals. We can verify this by running the “hg log”command. There’s no need for any additional options to ensure that the change is committed to the specific branch we created, as Mercurial automatically switched to the new branch when it was created. When they are complete and ready to be committed, simply use the “hg commit” command that we talked about in the previous article. Once the branch has been created, you can proceed to make your changes as you normally would. It’s a little out of date, but still very well written and useful. For a really good discussion of the pros and cons of this approach (and several others), see this blog post. My personal opinion is that is a little heavy handed, but might be useful in cases where you’re really tearing things up. Note: there are those that would advocate simply cloning a completely separate copy of the existing Mercurial repository for this sort of thing, rather than creating a branch. (branches are permanent and global, did you want a bookmark?)Ĭongratulations, you have successfully created a new branch in your Mercurial repository! We can now safely proceed with messing around with things. Marked working directory as branch block_db_principal PS C:\A_Workspace\sql-tools> hg branch block_db_principal Merge the branch back to the main ( “default” ) branch when development is complete.Ĭreating a branch in Mercurial is as simple as issuing a command. The process to complete this operation can be summarized in the following steps.Ĭomplete the work required for the feature, committing along the way as necessary (it’s a good idea to do frequent commits to have relatively stable save point of work). I would like to enhance my stored procedure to display this information as well, but I don’t want to do so on the main branch in case I discover issues that need to be corrected in the meantime. Note the highlighted section, which shows the locks held on the database principal (the fancy term for a user in a database). For example, by altering a database user, we will (for the duration of the session transaction) hold locks that prevent anyone else from further modifying the same principal (SQL’s terminology for user).Īfter running this command, you will see the following results. However, there’s quite a few other resources that sessions can hold locks on. For example, the procedure only handles certain kinds of resource locks, namely those involving database files, objects (tables, procedures, triggers, functions, etc), extents (a 64kb block of data in SQL Server), pages (a smaller, 8kb block of data an extent is made up of eight pages), and individual rows of data. Currently, the functionality, while stable, is fairly limited. I have a stored procedure written which collects and displays blocking information in an easily consumable format. The Mercurial wiki has a discussion of this approach which you should review however I think this is best illustrated with an actual example, written down as it happens. This in turn allows us to continue working on the new branch without disturbing the original.Ī common use of this is to create a new branch on which development of a new feature can commence, while still leaving the main (or “default” in Mercurial’s own terminology) branch stable and untouched. For Mercurial, a ‘line of development’ is a linear sequence of consecutive changesets.” In other words, we spawn off a new line of development from a base (or “parent”) state of the code. ![]() The term ‘branch’ may thus refer to a ‘diverged line of development’. Mercurial’s official documentation defines the term “branch” as follows: “Branches occur if lines of development diverge. ![]() In this installment, we are going to go into more depth on the specifics of two feature of Mercurial that, once harnessed, can add significant efficiency to our coding workflows.įirst, let’s go over the concept of branching. Among many reasons, it allows us to easily track history and changes to our scripts, which in turn makes it easier for us to experiment and enhance our toolkit, since we can do so safely without fear of permanently causing damage. In my previous article, we went over the basics of Mercurial, as well as some arguments why using it is critical for database administrators. ![]()
0 Comments
Leave a Reply. |