Maven Vs Ant
|Unified CodeCount (UCC)||CLOC||POWERSOFTWARE||EZ-Metrics||Metrixware|
|Windows & Linux||Linux 2.6.9, Unix, Mac OS X, Windows 9x/Me/XP/Vista, Solaris||BOTH||Windows, Linux planned but no date||Both|
|How the tool manages folder hierarchy changes?||The tool tries to match files between two baselines using filenames. As such, two files having the same name in different folder structures can be matched. The tool also detects to match and compare files if the folder is changed while filenames of the files contained in the folder are kept the same.||NA||No information||NA|
|How the tool manages files which are renamed?||Currently, the tool does not handle files renamed. However, if the file is renamed but its content does not change, the tool considers it as a duplicate.||NA||No information||NA|
|How the tool manages files or block swapping?||We have not handled swapping blocks of code yet. If the code is copied from one place to another, it is considered as deleted and added. If files are swapped and its filename does not change, the tool can match and compare them.||Available||No information||Available|
|What is the algorithm used for line change detection?||For comparing between lines, we detect the number of common characters between them and determine whether they are modified or deleted using a threshold. This threshold can be specified through a parameter named –t. For detecting bulk of changed or added code, we implemented our own algorithm for detecting longest common sequences. I am sorry, it is quite complex to be described in this email. We are documenting it in detail, and if you are interested I can send you a copy after it is completed.||SLOC, PERL Mod||No information||NA|
|GUI & CLI||CLI||CLI||Both but separate products||GUI|
|CSV & XML Output||Only TXT||XML||HTML, CSV, RAW XML data||YES|
|Provide Qualitative metrics?||No. The tool is focused on software size metrics.||NO||yes but separate product||YES|
|Price||Open Source||Open Source||KEPM (which includes EPM) costs 1,995 USD for a single license or 4,995 for a 5-user license||Commericial|
|Frequency of the releases||No information in net||Regular||One minor/Major release per month or 2 months.|
|Date of last release||December,2009||Apr-10||16-Mar-10|
|Press on the net||Not many reviews available in net||Nope|
|Integration with quality platform||Provides different language source for the integration.||Nope|
|Algorithm confidence||The total sizing of analyzed source code files in terms the SLOC count contains the highest degree of confidence. However, the sizing information pertaining to the sub classifications (compiler directives, data lines, executable lines) has a somewhat lower level of confidence associated with them.
Misclassifications of the sub classifications of SLOC may occur due to:
(1) user modifications to the UCC tool,
|SLOC algorithm with perl string handling features and SPAN mdoules||NA|
|Advantages / Drawbacks / Comments||Output not according to our need.
Limited Output Format
Delta is not useful
Low Processing speed
|Output according to our need.
Output in many form(CSV, XML, TXT and Mysql)
Delta is useful according to our needs
|I tried 30 days trial version. They given web based account/dashboard to add src file and generate output. Which was not functional and could not test it functionality in details. Basic functionality is not working.|
|Tool||Open Source – Commercial||URL|
|SLOC||Open Source -> Commercial||http://www.dwheeler.com/sloccount/|
|Unified CodeCount (UCC)||Open Source||http://sunset.usc.edu/research/CODECOUNT/|
Selecting the Right Software Version Control Product Written by Mike Feighner For many years, I worked loyally for the same company where my expertise was restricted to one single software version control tool—the one that was already in place. I was not involved with determining whether the selected tool was appropriate for the company’s needs; my role was to learn it well and use it within the accepted standards, guidelines, and internally approved processes. When I recently found myself back in the job market, I realized that there were many other version control tools in use in the industry. I then began to consult with other engineers in the field and gathered data from them on which version control tools their organizations were using and the selection criteria they used in choosing a version control tool for their organization. This experience opened up a whole new world for me and soon I realized that selecting and implementing the right tools was essential for the success of any software or systems development effort. From this experience, I have drawn up a checklist of version-control-tool criteria to aid an organization in selecting the best tool. Although there are many good descriptions available on the Internet about the many tools currently on the market, I do not recommend one specific tool over the other, because some tools may fit great in one organization, but fail in another. My goal here is to suggest a partial framework for deciding which tool best fits your needs while at the same time adhering to configuration management best practices. First, you will need to define your organization’s goals, which could include any or all of the following: Good documentation should accompany your tool purchase. The tool should be portable to more than one platform. If your organization is spread out over different time zones or even across international borders, your tool should support a multi-site rather than a single-site function. The cost should be affordable. The tool should be easy to use. The tool should easily support branching and merging. The tool should have the ability to lock a file when being edited to prevent two engineers from editing the same file simultaneously. The tool should be able to accurately merge changes between two or more files. The tool should log a history of changes with notes on who made the change and why the change was made. The tool should have the ability to establish immutable baselines. Next, you will need to review your organization’s requirements for software version control and carefully review the various software tools on the market to determine which one best matches your organization’s needs. Some may be better suited for your project than others. Selecting the wrong tool can have devastating effects on your team’s effort. Lack of a good version control tool can be a major cause for delays and problems during your organization’s application development. The project will run over cost and behind schedule and can be prone to risks associated with the manual management and distribution of your project’s dependencies. Unauthorized changes and results will occur, and the customer will not be satisfied. The tool you select should not impede the implementation of configuration management best practices, which serve as a means to add value to the process, improve quality, and increase productivity. The following are some, but not all, of the questions you will need to consider. Documentation Is the tool well documented? Is support documentation available on this tool’s installation and for the tool’s use by both administrators and developers? As a reference manual, the tool’s documentation should adequately describe the tool’s features—each dialog box, tab, field, button, etc. It should answer a user’s questions about completing a specific task in a clear and concise way. Frequently, the user documentation is available in the tool’s help pull-down menu or can be downloaded electronically from the vendor’s website. Portability Is the tool portable? Can it be used on multiple platforms and operating systems? From a business perspective, your software team will be supporting a broad user market occupying various platforms, including Windows, Mac OS, or some flavor of UNIX. Your tool should be compatible on any of these platforms, as each release will simultaneously need a separate version to support each platform of your user base. Multi-site vs. Single Site Is your team located at one location site, or is your team globally distributed across the nation and across different time zones throughout the world? A “single site” constitutes one physical location such as a single building or office. A “multisite” constitutes an organization in more than one office or location in a single time zone, in multiple time zones within one country or in multiple countries. If your organization is spread out over various time zones or even across international borders, your tool should support a multi-site rather than a single-site function. A multi-site project established as a set of several individual independent single-site systems would be prone to added costs and risks associated with the manual management and distribution of the project’s dependencies. Life for a multisite organization would be a lot easier to maintain a single multisite system with access to one shared repository. A single-site organization would be wise to select a single-site system over the additional costs of a multi-site system Cost What are the costs and terms of licensing of the tool? Is it something your organization can afford? Generally, a tool designed for a large organization will have a much larger cost than one designed for a smaller organization. No one should assume paying a higher cost for your tool will solve all of your problems. Even a high cost tool may fall sort of satisfying your organization’s needs. Your decision should consider overall cost and your organization’s needs. Supporting your organization’s needs should never be underfunded. Ease of Use How easy is it to install and deploy the system? Will the tool be dependent on other tools to conduct software builds, or are some of these capabilities already an integral part of the tool? Is this a tool that is easy to use from the first day of installation throughout the entire development lifecycle? Will training and customer support be available? Will the tool require training an in-house administrator dedicated to the administration of the tool? If you are not able to immediately pick up a source code management system and start building your site, odds are it is not entirely user friendly. Ultimately, the key to a successful deployment of a source code management system is reliability and ease-of-use. A tool that is difficult to use will likely conceal the functional benefits that it would otherwise provide. If training is an affordable option for your organization, consider whether it is available through the vendor or through an unbiased third party. For a lower-cost approach in the long term, consider sending a representative from your organization to a vendor training event who will later write up a training program for your own company-based organization. Branching Does the tool accommodate branch creation? The capability to create a branch should allow duplication of an object under revision control. Thus, code modifications can happen securely in parallel along both branches at the same time whether the change involves adding a new requirement or attempting to resolve an issue from an earlier release. The tool you select should support your particular choice of branching strategy, be it by revision or release via a simple copybranch or by creating adelta branch off of the main branch or trunk. Or the tool may go a step further by creating streams that include supporting metadata and workflow automation as an enhancement in managing multiple variants in the code. Branching is one of the most important features to consider in your choice of a good source control management system as it allows you to easily support at the same time the same source code and a parallel subset of the same code being modified securely to support either a new requirement or a bugfix from an earlier release. Merging Does the tool allow merges of changes and assists in resolving conflicts between different edits to the same file? Can a merge be done via a graphical user interface or on a command line? Take into consideration that merging concurrent changes made by different developers can increase the amount of effort to resolve conflicts and achieve a merge safely. The best advice in such cases is to merge little and merge often. File Locking Does the system have a means of preventing concurrent access to the same file? Does it prevent more than one user at a time from writing to the file until the current user either checks in the file or cancels the checkout? History of Changes Does the tool maintain a log of the history of changes? Can the tool display the history of changes graphically, as in a version tree? Does the tool easily identify the current baselined version and list previous baselined versions? A history change log that maintains accurate records facilitates traceability through the code’s lifecycle, from its beginning to its eventual release and beyond. A change history log can trace a change back its origins to who made the change and to the authority who authorized the change. It plays a vital role in baselining the code. This is a basic requirement of any organization wishing to maintain proper controls and compliance. Baselining Baselining, also known as setting a control point for your code, lets you know the exact versions of all source code and other configuration items that were included in a release. Does the tool have a way of baselining the code (be it via labeling, tagging, or snapshots) to a particular version that would allow us to back out and return to the previous baselined version in the event of a problem? Is the baseline immutable? If the tool allows changes to the previously released baseline, it jeopardizes the integrity of the software. A baseline must be locked down to prevent modifications. Any subsequent release should be based on a previously release baseline. Conclusion No one software version control tool can possibly fit every organization’s needs. There is no one size fits all. The right tool should help you safeguard your code and help your process improve productivity and quality. Remember that thorough evaluation and selection of the right tool will require funding, but this vetting must stay within your organization’s budget. Careful selection of the appropriate version control tool will help your firm improve productivity and quality and ensure that you are adhering to industry standards regarding configuration management best practices. About the Author Mike Feighner has more than twenty years’ experience in information technology in the aerospace industry, including more than ten years in configuration management. Mike graduated from San Jose State University with a bachelor’s degree in German and has a master’s degree in political science from the University of Tübingen in Germany and a master’s degree in software engineering from National University.
My main experience is with ClearCase. I have read various descriptive comparisons between ClearCase and other available Software Management Version tools. Which tool has your company implemented? What were the key features helped you select this tool over another one?
ANTHILLPRO COMPARISON WITH ATLASSIAN BAMBOO
AnthillPro Vs Bamboo OR
Difference between AnthillPro and Bamboo OR
Last month i was discussing with Eric Minick from Anthillpro on Why Build Engineer should be go for AnthillPro instead of Bamboo and i found some interesting inputs which i am sharing below;
Bamboo is a respectable team level continuous integration server. Continuous Integration servers are focused on providing feedback to developers about the quality of their recent
builds, and how that compares to previous builds. While AnthillPro also provides continuous integration features, it pays special attention to what hAnthillpropens after build time.
Where is the build deployed? How does it get tested in the hours, days and weeks after the build occurs? Who releases the software and how?
The distinction in focus between the two solutions shows up in their features. Both AnthillPro and Bamboo provide continuous integration support and integrations with
numerous tools. Only AnthillPro provides the features required to take a build through the release pipeline into production – rich security, build lifecycle management, eAtlassian Bamboo.
For the purposes of this document, we will use the following product aAtlassian Bambooreviations:
There is a lot more to implementing true lifecycle management than simply using the term in marketing and sales materials. The lifecycle extends across multiple processes in
addition to the build process. Most tools have had a very narrow view of this space and have focused their energies purely on the build process. The end result is that true lifecycle
management is an afterthought, and it shows in the features (or lack thereof) in their products. A continuous integration
As the lifecycle is made up of multiple processes (such as the build, deployments, tests, release, and potentially others), a lifecycle management tool must provide some means of
tracking and managing the movement of a build through the lifecycle stages. Without this feature, there is nothing to connect a build process execution to a deployment process
execution to a test process execution; thus the end user has no way of knowing what build actually got tested. Without this pipeline management feature (which we call the Build
Life), traceability between processes is completely absent from the tool.
Atlassian Bamboo: No pipeline management out of the box.
Anthillpro: Provides pipeline management out‐of‐the‐box. Anthillpro has a first‐class concept called the Build Life. The Build Life represents the pipeline and connects the build process to later
processes like deployments into QA, Anthillproprovals by managers, functional testing, and release to production. The pipeline (Build Life) provides guaranteed traceability throughout all
processes in the lifecycle, and provides a context for collecting logs, history, and other data gathered throughout the lifecycle.
Key to lifecycle management is the ability to connect the outputs of a prior process (such as the build) to the inputs of a subsequent process (such as a deployment). After all, the
deployment process needs to have something to deploy. Ideally, the deployment process would deploy the artifacts produced by the build process. And the test process would run
tests on those same artifacts. The ability to cAnthillproture and manage the artifacts created by a build and other processes is central to this effort. Ideally, the artifacts would be managed
by an artifact repository (a Definitive Software Library (DSL) under ITIL). Further, as hundreds or thousands of builds hAnthillpropen, support for discarding old builds needs to
intelligently remove builds that are no longer interesting. Anthillpro bundles a binary artifact repository called CodeStation.
Atlassian Bamboo: Bamboo does cAnthillproture built artifacts but does not have a robust artifact management system. It does not maintain artifact checksums for validation. Old builds may be archived
after a certain number of weeks, but there is no designation for builds that have been to or are potentially going to production that would use a different retention policy. Artifacts are available for user download, but are not accessible for reuse by other plans or deployments.
Anthillpro: Built‐in artifact management system (DSL) called CodeStation. The cAnthillproture, fingerprint and management of artifacts is essential to the solution. This allows AnthillPro to guarantee traceability of artifacts from the build, through deployment, through testing, and into release (in other words, AnthillPro guarantees that what is released into production is what was tested and built). A maximum number of builds or age to keep can be set per project and per status. This means that builds that were released can be kept longer than a simple continuous integration build.
Especially as servers address functionality before the build – deployments or tests to various environments, controlling who can do what within the system can be key element
securing the system and providing clear separation of duties. Once something has been done, it can be equally important to find out who ran which processes.
Authentication and Authorization
Atlassian Bamboo: Basic role based security. Users may be assigned roles and permissions at the project level. Integration with LDAnthillpro, compliments internally managed security.
Anthillpro: AnthillPro provides a rich role based security system, allowing fine‐grained control over who can see which project, run which workflows and interact with which
environments. The Authentication system supports internally managed, single sign on systems, LDAnthillpro, Kerberos (Active Directory), and JAnthillproS modules.
Secure Value Masking
Many “secrets” are used when building and deploying. Passwords to source control, servers, and utilities are often needed to execute build, deploy, test processes.
Atlassian Bamboo: No facility for securely storing Anthillproplication passwords or obfuscating them from the logs. Bamboo does manage to write libraries for some integrations that avoid passing the
password where the logs can see that line. It has no facility that we can see for flagging a command line parameter that will be logged as secure and filtering that value from the log.
Anthillpro: Sensitive values like Anthillproplication passwords are automatically filtered out of logs, hidden in the user interface, entered through password fields, and stored in the database encrypted with a triple DES one time key.
Process Automation & The Grid
In a distributed environment, managing your build and deployment grid needs to be easy.
Atlassian Bamboo: Agents are added into a fairly uniform pool. Agents can define broad cAnthillproabilities they provide and jobs can define what cAnthillproabilities they need to perform matchmaking.
Anthillpro: AnthillPro provides the concept of an environment. Environments are groups of servers. A build farm for a class of projects could be one environment while the QA environment for another project would be another environment. This allows for roaming – or deploying to everything – to span just the machines in an environment. Jobs can be
assigned to a single machine, or roam, or select machines based on criteria like processor type, operating system, or customized machine cAnthillproabilities.
Complex Process Automation
Atlassian Bamboo: Bamboo runs full plans on a single agent. While different agents can be running various builds in parallel, any given plan is executed on just a single agent.
Anthillpro: AnthillPro provides a rich workflow engine, which allows jobs to be run in sequence, parallel, and combinations thereof. Jobs can also be iterated so that they run multiple times with slight variations in their behavior on each execution. This allows parallelization that takes advantage of numerous agents. This facility also makes sophisticated deployments possible.
Cross Site Support
Atlassian Bamboo: Bamboo provides no special support for agents (slaves) that exist outside the local network.
Anthillpro: AnthillPro is architected with support for an cross‐site, even international, grid. Agent relays and location specific artifact caches assist in easing the configuration and
performance challenges inherent in deployment involving multiple sites.
Component based development and reuse are concepts that get a lot of lip service but few if any features from most vendors. Only AnthillPro provides features to enable component based development and software reuse. A flexible dependency management system is part of the built‐in feature set of AnthillPro. The dependency management system is integrated with the bundled artifact repository and with the build scheduler so that builds can be pushed up the dependency grAnthillproh and pulled down the dependency grAnthillproh as configured. Integration with Maven dependency management provides an integrated system.
Atlassian Bamboo: Provides some basic support for build scheduling based on dependencies. A build of one project can kick off a build of it’s dependents and some blocking strategies can prevent wild numbers of extra builds being generated. Bamboo does not provide any tie in between dependency triggering and build artifacts – sharing artifacts between projects is left to the team to figure out with an external tool such as Anthillproache Maven.
Anthillpro: Support for dependency relationships between projects out‐of‐the‐box. AnthillPro provides a rich set of features for relating projects together. Large projects often have tens
or hundreds of dependencies on sub‐projects, common libraries and third party libraries. At build time the dependency system can calculate which projects need to be rebuilt based on changes coming in from source control. At build time, artifacts from dependency projects are provided to the dependants with version traceability and tracking.
AnthillPro provides highly customizable build scheduling and artifact sharing to these projects. In a “pull” model, anytime a top level project is built, it’s dependencies are inspected to see if they are up‐to‐date. If not, they are first built, then the top level project is built. In a “push” model, builds of dependencies will trigger builds of their dependents. AnthillPro interprets the dependency grAnthillproh to avoid extra builds or premature builds. In the case of Maven projects, AnthillPro can simply provide the scheduling or cooperate with Maven to provide traceable artifact reuse.
While both tools have a lot of similarities, AnthillPro’s Lifecycle Management, Dependency Management, and full featured Security cAnthillproabilities set it Anthillproart. Only AnthillPro supports
complete end‐to‐end traceability across all the phases of Build, Deploy, Test, and Release. While Bamboo is likely an effective team level continuous integration server, AnthillPro is a proven solution for enterprises looking to automate the full lifecycle of a build. For build and release automation the technology leader since 2001 is AnthillPro. We were
the first to release a Build Management Server. We were the first to recognize the need for comprehensive lifecycle management (beyond just build management), and we were the
first to release features required to deliver on the vision. We have been very successful at enterprise level RFPs and have added hundreds of customers including some of the leading banks, insurance companies, and high‐technology companies in the world. Our dedication to solving the problems faced by our customers means that we are very responsive to feature and enhancement requests with turn around times measured in days or weeks instead of months and quarters. Urbancode delivers the leading product in its space, the expertise to roll it out, and caring support for our customers to ensure their continued success.
What is Maven 2?
Maven 2.0 is a complete rewrite of the ‘original’ Maven application (‘Maven 1’). As such, it is very different from Maven 1, and not backwards-compatible (eg, it cannot execute Maven 1 plugins). However, Maven 2.0 is the latest stable release of the Maven application, and new users are generally encouraged to use it for all new projects.
If you are familiar with Maven 1, you can find some information about moving to Maven 2 here or on the main Maven site.
To access the repository from your project, add the following line to your project.properties or build.properties.
For Maven2, one needs to add the following into a project’s pom.xml, or into conf/settings.xml // (NOT in mirrors/mirror) where Maven2 is installed:
Maven 2 Lifecycles
Lifecycles are groupings of goals that define a process for building a project. Goals are bound to lifecycles to define a sequence that must be accomplished to produce results. Lifecycles ensure that users building projects with Maven only need to learn a small set of commands. Whereas Maven defines a default set of goals for each typical lifecycle, developers can bind additional goals to lifecycles to transparently add functionality to a build.
Typical lifecycles include:
- compile—compile the source code
- test—unit test the compiled source.
Note: Unit tests should not require the classes to be packaged or deployed.
- package—bundle the compile and tested source code into a distributable package, such as a jar or war.
- integration-test—employ the package as necessary and run integration tests.
- install—install the package into the local repository. This allows the package to be utilized as a dependency of other projects.
- deploy—copies the final package into the remote repositories for sharing and use with other projects.
As you can see, each lifecycle depends upon and builds upon the next. As a result, when a goal is bound to the compile lifecycle, all lifecycles will ensure its execution.
Lifecycles can be executed in conjunction with standalone goals. For instance, commonly the clean:clean goal is executed before the install goal. This is done by invoking:
m2 clean:clean install
Native Multiproject Support
One of the best practices that Maven strongly encourages is the idea that a single project should result in a single artifact, or package, being created. This best practice results in simplified builds and organized project structures. By natively supporting a hierarchical structure of projects, Maven now makes developing enterprise projects which implement this approach easier.
Maven 1 included a plugin for working with related of projects—or multiprojects. Maven 2 takes multiproject builds a step further by including a specialized parent descriptor and native multiproject execution support. As a result, any goals or lifecycles invoked upon a multiproject POM will result in each subproject goal being achieved.
Several other changes are included in Maven 2. Maven has been rewritten to be smaller and faster. The architectural changes make embedding Maven into other tools easier and allows for faster command line execution. Maven 2 depends upon fewer dependencies, resulting in a smaller distribution.
The way extensions are made to Maven has been changed in Maven 2. Instead, developers are encouraged to utilize JavaBeans for enhancements. Whereas scripting is allowed (through marmalade support—which includes a jelly facade), it is no longer the tool of choice. All extensions are made through the development of plugins (projects can no longer be customized through scripting in the maven.xml).
The introduction of a settings.xml file replaces the need for properties files. The settings file can be defined at a system, user, or project level. Settings are used to define private configuration information, including usernames and passwords. Project properties (including plugin configuration) are now all defined in the pom.xml.
Understanding Maven 2 Project Types
The first step to creating a maven project is determining which project template, or archetype, your Maven project should be configured as. Archetypes define which type of artifact will be produced by a project. Several archetype templates exist. The standard archetype will produce a standard library jar file. Templates also exist for webapps/wars, Maven plugin projects, documentation Web sites, and more.
Creating Project Descriptors
The archetype:create goal can be utilized to create a basic pom.xml for you project. This basic POM will allow you to execute all of the lifecycles and goals associated with any maven project. The archetype:create goal should be executed as follows:
m2 archetype:create -DgroupdId=com.daviddewolf.maven -DartifactId=example
This simple command creates the basic infrastructure needed for a project. It creates the pom.xml as well as the basic directory structure of for both source and test code. The following structure indicates the directories and files produced by issuing the archetype:goal command as listed above.
This simple structure that is created is enough to get started with Maven. All of the lifecycles now can be utilized. A simple invocation of the install lifecycle will compile, test, and package the application and then deploy it to the local system repository for use by other projects.
Once created, the POM can be customized to meet the requirements of the specific project. Documentation on the Maven POM can be found on the Maven2 Web site.
Goals You Should Know About
The introduction of lifecycles in Maven 2 has greatly reduced the number of goals that a developer must be aware of. Still, the following goals will undoubtedly be found useful (and can be utilized as soon as the basic descriptor has been generated).
- clean:clean Clean all artifacts and intermediary files created by Maven
- idea:idea Generate project files for the IntelliJ IDEA IDE
- eclipse:eclipse Generate project files for the Eclipse IDE
- javadoc:javadoc Generate the javadocs for the project
- antrun:run Run a specified ant target
- clover:clover Generate a coverage report for the project
- checkstyle:checkstyle Generate a checkstyle report for the project
- site:site Generate a documentation Web site for the project. This site will include many information reports concerning the project.
For more information concerning these and other goals, see the Maven2 Web site.
Learning Maven is not difficult; it simply requires a willingness to accept a new philosophy for building applications. Maven utilizes a a centralized project descriptor to intelligently build applications with prebuilt build tools. This differs greatly from ant and other build tools in that project developers are no longer required to write build systems by using a comprehensive set of utilities. This change will save development teams significant time and has started a revolution in build tools.
It is important to remember that Maven2 is still currently only released as Beta Software. Although it is mature enough to utilize in most projects, all of the Maven 1 plugins have not yet been migrated to Maven 2. With time, Maven 2 will become more widely accepted and the number of available plugins will grow beyond what is even available in Maven 1.
Difference between Bamboo Vs TeamCity Vs CruiseControl
- TC pre-tested commit is good.
- TC integrates to Visual Studio which is our main IDE.
- JetBrains are more focused on supporting .NET builds than Atlassian is, since JetBrains actually has .NET products so they use it internally.
- Support for .Net projects, as well as Java, in the same product (nice if you need it).
- Server-side code coverage analysis (you could get the same results by running EMMA from the Ant build.xml)
- Server-side static code analysis using IDEA inspections (nice but relies on using IDEA for development – Checkstyle and FindBugs could do something similar from Ant).
- Pre-tested commits. Sends your changes to the CI server for building before committing to version control. Your changes are only checked-in if the build succeeds and all tests pass.
- Bamboo JIRA integration is awesome. I wish TeamCity provides that kind of integration.
- Bamboo on the other hand looks like a great tool too. It has so many plugins (just like JIRA). It looks nice as well. I can live without VSTD integration, but I really wanted pre-tested commit. Just a note: I did create a feature request ticket to Atlassian telling them about TC’s pre-tested commit feature.
- “CruiseControl is a framework for a continuous build process.”
- “Bamboo is a continuous integration build server that offers heaps of insight on build processes and patterns via solid reporting metrics.”
- “TeamCity is an innovative, IDE independent, integrated team environment targeted for .NET and Java software developers and their managers.”
- “AnthillPro3 is a third generation Build Management Server.”
Links and Reference:
|File Comparing Tools review|
|File comparison in computing is the automatic comparing of data between
files on a file system. The result of comparisons are typically
displayed to the user, but can also be used to accomplish tasks in
networks, file systems and revision control.| Comparison of file comparison tools | comparison tools | Good comparison tools | comparison tools review | comparison tools feedback | Free File comparison Tools || Beyond Compare Review | Compare Suite review | Araxis Merge review |ECMerg Review | FileMerge review | WinMerge Review | Diffutils Review|
|Compare Files, Folders
Beyond Compare allows you to quickly and easily compare your files and folders. By using simple, powerful commands you can focus on the differences you’re interested in and ignore those you’re not. You can then merge the changes, synchronize your files, and generate reports for your records.
You can compare entire drives and folders at high speed, checking just sizes and modified times. Or, thoroughly verify every file with byte-by-byte comparisons. FTP sites and zip files are integrated seamlessly, so you can update your website with the touch of a button. Once you’ve found pecific files you’re interested in, Beyond Compare can intelligently pick the best way to compare and display them. Text files can be viewed and edited with syntax highlighting and comparison rules tweaked specifically for documents, source code, and HTML. Data files, executables, binary data, and images all have dedicated viewers as well, so you always have a clear view of the changes.
Beyond Compare includes built-in comparison viewers for a variety of data types. Compare .csv data or HTML tables in a Data Compare session,
3-way Merge Pro edition only
Introduced in version 3, Beyond Compare’s new merge view allows you to combine changes from two versions of a file into a single output. Its intelligent approach allows you to quickly accept most changes while carefully examining conflicts. Color coding and section highlighting allow you to accept, reject, or combine changes, simply and easily. And, you can change any line in the output with the built-in syntax-highlighting editor. By using Beyond Compare’s powerful file type support and ability to favor changes from one file, you can trivially accept many changes without even seeing them.
You can use Beyond Compare directly from most version control systems, giving you all of the powerful comparing and merging support you need when you need it most. Integrated source control commands are also available, allowing you to check in and check out files without interrupting your work.
Beyond Compare’s intuitive Folder Sync interface lets you reconcile differences in your data automatically. You can efficiently update your laptop, backup your computer, or manage your website, and Beyond Compare will handle all the details. You can copy to and from disks, FTP servers, and zip files, all using the same interface. Anything you don’t want affected can be easily filtered out, and all of the powerful comparison techniques are available, making the backup as fast or robust as you need.
You can automate repetitive tasks using a flexible scripting language, and any script can be called from the command line, allowing you to schedule your syncs for when it’s most convenient.
|By keywords comparison allows to match non-related documents with different structure.
Compare two folders feature allows to find and synchronize changes that were made in two folders.
Report can be created once you compared two files or folders. It contains detailed comparison information.
Document audit allows to accept or decline changes that were made in plain text files .
Ignore words. Starting version 5.0 Compare Suite can ignore certain keywords or strings while comparison.
Syntax highlighting. Compare Suite can now highlight syntax for some popular formats, such as .pas, .php, .htm and other.
Multimedia and graphics comparison. Compare Suite can compare information from multimedia and graphic formats.
Command line allows to automate comparison and integrate Compare Suite with other software products, Compare Suite can be a part of quality assurance script set.
Server-side comparison. Provide your employees with ability to compare documents on-line.
|ECMergePro 2.0 is a powerful comparison and merge software. ECMerge
provides for side-by-side, two- and three-way file revision and folder
synchronization. ECMergePro 2.0 is available in three versions: MS
Windows, Linux and Solaris. In MS Windows, ECMergePro 2.0 can be
integrated in Windows explorer. The software also provides for command
|FileMerge is one of the old NeXT Developer applications that survived into the days of Mac OS X, and with good reason: It kicks the pants off anything else when it comes to quickly going through file changes, marking them on the scrollba, allowing you to breeze through them with parallax scrolling, and merging them with a single click:|
|WinMerge is an Open Source differencing and merging tool for Windows. WinMerge can compare both folders and files, presenting differences in a visual text format that is easy to understand and handle.
WinMerge is highly useful for determining what has changed between project versions, and then merging changes between versions. WinMerge can be used as an external differencing/merging tool or as a standalone application.
In addition, WinMerge has many helpful supporting features that make comparing, synchronising, and merging as easy and useful as possible:
|You can use the diff command to show differences between two files, or each corresponding file in two directories. diff outputs differences between files line by line in any of several formats, selectable by command line options. This set of differences is often called a `diff’ or `patch’. For files that are identical, diff normally produces no output; for binary (non-text) files, diff normally reports only that they are different.
You can use the cmp command to show the offsets and line numbers where two files differ. cmp can also show all the characters that differ between the two files, side by side.
You can use the diff3 command to show differences among three files. When two people have made independent changes to a common original, diff3 can report the differences between the original and the two changed versions, and can produce a merged file that contains both persons’ changes together with warnings about conflicts.
You can use the sdiff command to merge two files interactively.