Case Status Kiln
Log In


  • RSS Feed

Last modified on 4/3/2014 8:58 AM by User.



Our Expectations

When contributing to EWL, we expect you to:

  • Use our coding standards for all code contributions. The easiest way to do this is to obtain our ReSharper settings file and then perform Code Cleanup on the C#, JavaScript, CSS, and XML files you've changed. Visual Studio text editor settings can also affect the format of your code; here are our settings: CSharp.vssettings, JavaScript.vssettings, CSS.vssettings, XML.vssettings. Note that we do care about white space formatting when reviewing diffs.
  • Discuss third-party component updates with the lead developer before pushing any code. These updates sometimes create huge diffs, and we don't want to burden reviewers with this more than necessary. We also want to keep our repository to a manageable size.
  • When changing the public API, make an effort to mark old functionality obsolete, with a "guaranteed through" date, instead of immediately removing it. Please set the "guaranteed through" date approximately twelve weeks in the future; this allows four weeks for your changes to be reviewed and pulled into canonical, four weeks for EWL users to update to the latest version, and four more weeks for these users to remove their usages of the obsolete functionality. Rationale for using ObsoleteAttribute: It's very important for EWL users to know in advance what maintenance needs to be done. This is the only way it can be delegated. If a system's build breaks because deprecated EWL stuff was removed, it's too late to delegate maintenance since if something urgent needs to be done, the person resposible for that work ends up having to do the maintenance too.

A Few Tips

Heed this advice to get your changes quickly into canonical:

  • Use the smallest branches you can get away with. Do not build your separate changes on top of one another unless there is a compelling reason to do so.


Pulling Changesets from Canonical EWL

  1. Pull the changesets.
  2. Ensure that you have a line similar to
    %include your-machine-configuration-folder-path\Development Tools\Mercurial\Revset Aliases.ini
    in your mercurial.ini file; this gives you access to our nextIntegrationMerge revsets predicate.
  3. Run "nextIntegrationMerge( all() )" as a revsets query and merge the result into your integration branch. Repeat until the query no longer returns anything. At this point everything you pulled should now be incorporated into your integration branch.
  4. Push the changesets to your EWL branch repository.
  5. Copy accompanying accomplishments from the Enterprise Web Library system in RSIS to the end of your EWL branch accomplishments note. Indicate that the incoming accomplishments didn't originate in your branch. Otherwise you might have trouble knowing which accomplishments to copy back to RSIS when you push your changesets to canonical.

Bringing an Unfinished Change Branch Up-To-Date

Warning: Merging the canonical head into a branch risks "criss-cross" merges in the future, so avoid doing it unless it is significantly painful to work on the branch in its original state, for example if the branch predates a major Visual Studio upgrade.

Pushing Changesets to Canonical EWL

  1. Make sure the changesets have been approved by other EWL developers. This includes merges, except those performed by William Gross, the lead developer.
  2. Push the changesets.
  3. Copy accompanying accomplishments from your EWL branch accomplishments note into the Enterprise Web Library system in RSIS.
  4. Update the push marker in your EWL branch accomplishments note.
  5. Tell the system lead to release canonical EWL if:
    • there are sufficient accomplishments or anything was marked obsolete, and
    • there are no required-for-deployment tasks.