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 kommentar(er)
