If instead you have a single integration branch where people are checking in directly, you would want to review all pushes to that branch. Obviously all hotfixes must also be reviewed along with the merges into master. Individual commits on feature branches may not make sense to review. In this case, you may want to review changes that are being merged into develop. For example, let's assume a repository structure that looks like the one discussed in this article on Git repository layouts. If you want to do post-push reviews, the ideal workflow depends heavily on your repository structure. DVCS's are nicer in this environment (when compared to traditional SCMs) because they have built-in functionality for saving your local changes and getting your workspace back so you can work on something else. We prefer to do "pre-commit" reviews, which in the world of DVCS really means "pre-push". It depends on how you have your repository structure and what you are trying to accomplish. Note: This is a fairly simple process (and relatively new for us), so it may not work for everyone, and there may be some design bugs that we haven't run into yet. In essence, this provides the developer with a pretty streamlined process (all they have to do is an hg push) and completely automates the creation of the code review (and uploading additional changed files to the review), while ensuring that all code gets reviewed. However, if there were any new changesets (or the code review isn't complete), the hook exits with a non-zero status code (causing Mercurial to roll back the transaction) and outputs a friendly message on Standard Error explaining to the developer that the code review needs to be finished. If all of the changes were found in the database (ie, they've all been added to the code review), then we verify that the status of the code review is Complete.If we've seen some (but not all) of the changesets, we run the (Code Collaborator) command to attach the new changesets to the existing review and record these new changesets in the database.If this is the first time any of these changesets have been seen, then we create a new Code Review (using the Code Collaborator command line), and then record these changesets in the database with that code review's ID.(The table matches the hash of a changeset with a code review ID). It then queries a database we built to see if those changesets were included in a code review. The hook runs and grabs a list of all the changesets included in the transaction (by running HG log).The developer initiates a push to the stable repository (yes, this really is the first step).We leverage the fact that when this hook runs, it can see the repository as-if the code changes were permanent, yet also gives us the ability to prevent the push. To enforce the code review, we wrote a pretxnchangegroup hook (documented in the HG Book). (This is significant because we also require that our stable repositories contain the code that is currently running in production, differeing only by pending code promotions.) We require that code be reviewed before it is pushed into a stable repository. We separate stable repositories from development repositories. Likewise, when the development cycle is complete, code gets pushed into the appropriate repository there also. When developers want to "check out" code, they go to this server and clone from the repositories there. We keep a central definitive copy of all our repositories on one server. The thg script and TortoiseHg dialogs can be used on any platform that supports PyQt, including Mac OS X.We actually went through nearly the exact same thing at my company recently. TortoiseHg is primarily written in Python and PyQt (the Windows shell extension being the notable exception). TortoiseHg binary packages list Mercurial as a dependency, so it is usually installed for you automatically. You must have Mercurial installed separately in order to run TortoiseHg on Linux. On Linux, TortoiseHg consists of a command line thg script and a Nautilus extension which provides overlays and context menus in your file explorer. Binary packages of TortoiseHg for Windows come with Mercurial and a merge tool and are thus completely ready for use "Out of the Box". On Windows, TortoiseHg consists of a shell extension, which provides overlay icons and context menus in your file explorer, and a command line program named thg.exe which can launch the TortoiseHg tools. TortoiseHg is a set of graphical tools and a shell extension for the Mercurial distributed revision control system.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |