Dynamic code analysis VS Static code analysis

dynamic-code-analysis-vs-static-code-analysis

Difference between dynamic code analysis and static code analysis

Static analysis is the testing and evaluation of an application by examining the code without executing the application whereas Dynamic analysis is the testing and evaluation of an application during runtime.

Many software defects that cause memory and threading errors can be detected both dynamically and statically. The two approaches are complementary because no single approach can find every error.

The primary advantage of dynamic analysis: It reveals subtle defects or vulnerabilities whose cause is too complex to be discovered by static analysis. Dynamic analysis can play a role in security assurance, but its primary goal is finding and debugging errors.

Level of in-depth review

The key difference between a static and dynamic code analyser is the how in-depth the code review

process is. By default, static code analysis combs through every single line of source code to find flaws and errors. For dynamic analysis, the lines of code that get reviewed depend upon which lines of source code are activated during the testing process. Unless a line of code is interacted with, the dynamic analysis tool will ignore it and continue checking active codes for flaws. As a result, dynamic analysis is a lot quicker since it is able to review code on the fly and generates real-time data. However, static code analysis provides peace of mind that each and every line of source code has been thoroughly inspected. It may take longer, but static code analysis runs in the background and is crucial for creating a flawless web application.

 

Catching errors early and making recommendations

The primary advantage of static analysis: It examines all possible execution paths and variable values, not just those invoked during execution. Thus static analysis can reveal errors that may not manifest themselves until weeks, months or years after release. This aspect of static analysis is especially valuable in security assurance, because security attacks often exercise an application in unforeseen and untested ways.

As mentioned before, dynamic analysis reviews codes during the testing process and generates real-time results. While it is great for fine-tuning the user experience, it has one major drawback: any errors highlighted by dynamic code analysis tools requires developers to go all the way back to the source code, make changes to the code itself and then make changes to everything that has been modified as a result of changing the source code. This is a very time consuming and expensive process; one that companies and developers like to avoid at all costs. Static code analysis tools highlight any errors immediately and allow developers to makes changes before proceeding any further. Moreover, static code analysis tools are more feature-packed than their dynamic counterparts. One important feature is the number of errors it can detect and the recommendations it can make to fix that error. If configured, static code analysers can automatically make the required changes and let developers know what changes have been made.

 

Cost of code analysis tools

Just like any other business, software application companies have to find a fine balance between application costs and profit margins. With respect to price, static code analysis tools are always cheaper than dynamic analysers. Moreover, having a dynamic code analyser requires a company to hire professionals trained in the use of dynamic analysis tools. A static code analysis tool can be used by any web developer with ease, thus guaranteeing that it won’t turn out to be a long-term expenditure.

Static code analysers are absolutely essential for application developers, whereas dynamic code analysers can only be used in conjunction with static analysis tools.

 

Tagged : / / / / / / / / / / / / / / / /

Difference between dynamic code analysis and static code analysis

difference-dynamic-code-analysis-and-static-code-analysis

Difference between dynamic code analysis and static code analysis

Static analysis is the testing and evaluation of an application by examining the code without executing the application whereas Dynamic analysis is the testing and evaluation of an application during runtime.

Many software defects that cause memory and threading errors can be detected both dynamically and statically. The two approaches are complementary because no single approach can find every error.

The primary advantage of dynamic analysis: It reveals subtle defects or vulnerabilities whose cause is too complex to be discovered by static analysis. Dynamic analysis can play a role in security assurance, but its primary goal is finding and debugging errors.

Level of in-depth review

The key difference between a static and dynamic code analyser is the how in-depth the code review

process is. By default, static code analysis combs through every single line of source code to find flaws and errors. For dynamic analysis, the lines of code that get reviewed depend upon which lines of source code are activated during the testing process. Unless a line of code is interacted with, the dynamic analysis tool will ignore it and continue checking active codes for flaws. As a result, dynamic analysis is a lot quicker since it is able to review code on the fly and generates real-time data. However, static code analysis provides peace of mind that each and every line of source code has been thoroughly inspected. It may take longer, but static code analysis runs in the background and is crucial for creating a flawless web application.

 

Catching errors early and making recommendations

The primary advantage of static analysis: It examines all possible execution paths and variable values, not just those invoked during execution. Thus static analysis can reveal errors that may not manifest themselves until weeks, months or years after release. This aspect of static analysis is especially valuable in security assurance, because security attacks often exercise an application in unforeseen and untested ways.

As mentioned before, dynamic analysis reviews codes during the testing process and generates real-time results. While it is great for fine-tuning the user experience, it has one major drawback: any errors highlighted by dynamic code analysis tools requires developers to go all the way back to the source code, make changes to the code itself and then make changes to everything that has been modified as a result of changing the source code. This is a very time consuming and expensive process; one that companies and developers like to avoid at all costs. Static code analysis tools highlight any errors immediately and allow developers to makes changes before proceeding any further. Moreover, static code analysis tools are more feature-packed than their dynamic counterparts. One important feature is the number of errors it can detect and the recommendations it can make to fix that error. If configured, static code analysers can automatically make the required changes and let developers know what changes have been made.

 

Cost of code analysis tools

Just like any other business, software application companies have to find a fine balance between application costs and profit margins. With respect to price, static code analysis tools are always cheaper than dynamic analysers. Moreover, having a dynamic code analyser requires a company to hire professionals trained in the use of dynamic analysis tools. A static code analysis tool can be used by any web developer with ease, thus guaranteeing that it won’t turn out to be a long-term expenditure.

Static code analysers are absolutely essential for application developers, whereas dynamic code analysers can only be used in conjunction with static analysis tools.

 

Tagged : / / / / / / / / / / / / /

Static vs dynamic code analysis: Advantages and Disadvantages

static-vs-dynamic-code-analysis-advantages-and-disadvantages

What are the advantages and limitations of static and dynamic software code analysis? Maj. Michael Kleffman of the Air Force’s Application Software Assurance Center of Excellence spelled it out.

Static code analysis advantages:

  1. It can find weaknesses in the code at the exact location.
  2. It can be conducted by trained software assurance developers who fully understand the code.
  3. It allows a quicker turn around for fixes.
  4. It is relatively fast if automated tools are used.
  5. Automated tools can scan the entire code base.
  6. Automated tools can provide mitigation recommendations, reducing the research time.
  7. It permits weaknesses to be found earlier in the development life cycle, reducing the cost to fix.

Static code analysis limitations:

  1. It is time consuming if conducted manually.
  2. Automated tools do not support all programming languages.
  3. Automated tools produce false positives and false negatives.
  4. There are not enough trained personnel to thoroughly conduct static code analysis.
  5. Automated tools can provide a false sense of security that everything is being addressed.
  6. Automated tools only as good as the rules they are using to scan with.
  7. It does not find vulnerabilities introduced in the runtime environment.

Dynamic code analysis advantages:

  1. It identifies vulnerabilities in a runtime environment.
  2. Automated tools provide flexibility on what to scan for.
  3. It allows for analysis of applications in which you do not have access to the actual code.
  4. It identifies vulnerabilities that might have been false negatives in the static code analysis.
  5. It permits you to validate static code analysis findings.
  6. It can be conducted against any application.

Dynamic code analysis limitations:

  1. Automated tools provide a false sense of security that everything is being addressed.
  2. Automated tools produce false positives and false negatives.
  3. Automated tools are only as good as the rules they are using to scan with.
  4. There are not enough trained personnel to thoroughly conduct dynamic code analysis [as with static analysis].
  5. It is more difficult to trace the vulnerability back to the exact location in the code, taking longer to fix the problem.
Tagged : / / / / / / / / / / / / / / /

Why Git is Better than X | Git or X

why-git-is-better-than-x

Cheap Local Branching

svn perforce

Everything is Local

bzr svn perforce

Git is Fast

hg bzr svn perforce

The Staging Area

svn perforce

Distributed

svn perforce

Any Workflow

hg svn perforce

GitHub

perforce

Easy to Learn

hg bzr svn perforce

Git is the new standard

Tagged : / / / / / / / / / / / / /

Comparison Between UCC, CLOC, POWERSOFTWARE,EZ-Metrics and Metrixware

ucc-vs-cloc-vs-powersoftware-vs-ez-metrics-vs-metrixware

Unified CodeCount (UCC) CLOC POWERSOFTWARE EZ-Metrics Metrixware
Languages
C/C++, C#, Java, SQL, Ada, Perl, ASP, ASP.NET, JSP, CSS, HTML, JavaScript, VB, and VbScript YES – All ADA, Assembly, ASP, C#, C/C++, CSS, Fortran, IDL, HTML, Java, JavaScript, JSP, Perl, PHP, PL/SQL, PowerBuilder, Python, Ruby, ShellScript, Textfiles, VB6 / VB.NET / VBScript, VHDL, Windows Batch and XML YES ALL
Platforms
Windows & Linux Linux 2.6.9, Unix, Mac OS X, Windows 9x/Me/XP/Vista, Solaris BOTH Windows, Linux planned but no date Both
Baselines comparison
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
Miscellaneous
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
Recommend NO Yes No No
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,
(2) syntax and semantic enhancements to the parsed programming language,
(3) exotic usage of the parsed programming language, and
(4) integrity of the host platform execution environment.

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
Fast processing
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.
Tagged : / / / / / / / / / / / / / / / /

SLOC Tools Comparison | SLOC Tools Differences | SLOC Tools Comparison Table

sloc-tools-comparison

Tool Open Source – Commercial URL
CAST Commercial www.castsoftware.com
Sonar Open Source www.sonarsource.org
SLOC Open Source -> Commercial http://www.dwheeler.com/sloccount/
RSM Commercial www.msquaredtechnologies.com
LocMetrics Commercial www.locmetrics.com
EZ-Metrics Commercial http://www.jamesheiresconsulting.com/Products.htm
Metrixware Commercial www.metrixware.com
Parasoft (Jtest) Commercial www.parasoft.com/
Squale Open Source www.squale.org/
KODERS Commercial www.koders.com
PRACTILINE www.practiline.com
POWERSOFTWARE Commercial http://www.powersoftware.com/
CLOC Open Source http://cloc.sourceforge.net/
Unified CodeCount (UCC) Open Source http://sunset.usc.edu/research/CODECOUNT/
Tagged : / / / / / / / / / / / / / / /

Difference between Maven 1 and Maven 2 | Maven 1 Vs Maven 2

maven-1-and-maven-2-differences

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.

Maven 1
To access the repository from your project, add the following line to your project.properties or build.properties.
maven.repo.remote=http://download.java.net/maven/1/,http://www.ibiblio.org/maven/

Maven 2
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:

java.net
http://download.java.net/maven/1
legacy

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.

Other Enhancements

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.

+ root
  - pom.xml
  + src
    + main
      + java
        + com
          + daviddewolf
            + maven
              + example
                - App.java
    + test
      + java
        + com
          + daviddewolf
            + maven
              + example
                - TestApp.java

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.
Conclusions
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.
Reference:
http://www.developer.com/open/print.php/10930_3552026_2
http://www.sonatype.com/books/maven-book/reference/installation-sect-upgrade-detail.html

Tagged : / / / / / / / / / / / / / / / / /

Advance Features of Smart Build Tools

smart-build-tools-features

Table of Contents
Agile Development Challenges
Deployment Challenges
Build Acceleration Challenges
Integration with Elastic and Cloud Computing
Workflow Management
Reference:

 

Agile Development Challenges

Two of the core principles of agile development are: “deliver working code frequently” and “working software is the primary measure of progress.” More and more teams, from ISVs to enterprise IT groups, are recognizing the quality and productivity benefits of integrating early and often. Whether you want to just build and test more frequently or implement a comprehensive agile process, you’ll need to ensure that your build and test process is:

  • fast
  • automated (not requiring manual intervention)
  • reliable (broken builds are the enemy of an agile approach)

Addressing the build-test-deploy process is one of the best first steps toward an agile development model.

Agile Development  Challenge

http://electric-cloud.com/images/common/spacer.gif

http://electric-cloud.com/images/common/spacer.gif

Impact

http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif
Builds require manual intervention http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif Integrating often will overwhelm a manual build process http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif
Slow build cycle (whether long individual builds or a large number of build targets) http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif Long builds limit the number of iterations possible in a day
Builds longer than ~30 minutes rule out Continuous Integration
http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif
Developers introducing errors during integration or production builds http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif If developers can’t do preflight builds and tests on all targets/platforms prior to check-in, Continuous Integration can turn into Continuously Broken Builds http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif http://electric-cloud.com/images/common/spacer.gif

Deployment Challenges

Deployment of a real world application is a complex, and all-too-often, a manual process. The complexity comes from the fact that the application may need to be deployed to any number of environments: Development (DEV), Quality Assurance (QA), User Acceptance Testing (UAT), Pre-production (STAGE), and Production (PROD). Each of these environments is typically slightly different requiring different accounts, password, and setting and thus it may seem like manual intervention is required.
Complicating matters is the fact that today’s business applications comprise multiple moving parts that all need to be synchronized and deployed together. For example, a typical J2EE application can be made up of an EAR file, database changes, some static content, and environment changes (such as JDBC connection pools, Message Queues, etc.). Making sure that all these pieces get deployed on the correct machines and in the correct order can feel like a daunting task, especially if you need to repeat it for each environment. Keep in mind that each environment may have a different number of database servers, application server, HTTP server, etc.

Build Acceleration Challenges

Slow software build cycles are more than just an annoyance. Whether you have long monolithic builds or a large number of smaller builds that take a long time, they are having a real impact on your development organization.

  • Wasted time, frustration waiting for builds
  • Fixing broken builds delays testing
  • Fewer bugs fixed, fewer features added
  • Developers avoid builds
  • QA may skip tests to meet deadlines

A recent survey of more than 350 development professionals found that 68% reported broken builds at least a few times per month (and often weekly), and fixing those typically wasted 2 weeks per year. The majority said their builds were each more than 1 hour long, with 24% reporting builds of 2-4 hours, which translates to time not spent creating great software.

Integration with Elastic and Cloud Computing

In a large infrastructure with many projects, the CI server often experiences variable task loads with unpredictable load peaks (such as during releases). In an environment with fixed resources, this leads to build queue growths, increased build times, and poor build scheduling control.
Computing clouds such as Amazon EC2 provide a nice and efficient way to scale resources to fulfill variable demands with random load spikes. Such rapid demand growths is exactly what happens in Build Server during CI “rush hours,” when everyone starts personal builds before going home, and also during pre-release days, when every new fix needs another round of unit tests, and build feedback time becomes mission-critical.
Build Server utilizes EC2 via virtual build agents. Virtual build agents are similar to standard ones, except that they run on virtual instances on the Amazon EC2. This means that Build Server is able to dynamically start as many instances of such agents as needed, in order to keep the build queue under control under high loads. Additionally, Build Server can shut down virtual build agents when they are not needed anymore, to minimize EC2 instances uptime.
While being a great solution for mitigating peak loads and maintaining constant build feedback time, Amazon EC2 integration also provides great cost optimization opportunities, as each resource accumulates costs only while in use.

Workflow Management

In recent years, build management solutions have provided even more relief when it comes to automating the build process. Both commercial and open source solutions are available to perform more automated build and workflow processing. Some solutions focus on automating the pre and post steps around the calling of the build scripts, while others go beyond the pre and post build script processing and drive down into streamlining the actual compile and linker calls without much manual scripting.

Tools Comparison

 

  OpenMake Bamboo AnthillPro TeamCity Electric Cloud
Agile Support YES YES YES YES YES
Deployment YES NO YES No YES
Remote Agent YES YES YES YES YES
Cloud – Elastic NO YES No YES YES
WorkFlow Mgmt YES YES – Limited YES YES – Limited YES, Limited
           

Reference:

http://www.electric-cloud.com
www.anthillpro.com
http://www.atlassian.com
www.jetbrains.com/teamcity
http://www.openmakesoftware.com

Tagged : / / / / / / / / / / / / / / / / / / / /

What makes P4Win better than P4V? – P4V deficiencies

p4v-deficiencies-compared-to-p4win

P4V deficiencies compared to P4Win

Here’s list of P4V deficiencies & features missing as compared to P4Win…  

1). In P4V you can’t paste paths onto the tree view as way to quickly navigate to items. The nearest equivalent is to paste in to the address bar but that has the annoying side effect of switching between workspace/depot view depending on the format of the address. 

2). P4V has an inferior (broken) ability to copy paths from depot treeview using Crtl+C. P4V copies the string in a totally un-usable format, P4Win copies it ready for use in command line P4 operations etc. 

3). P4V has inferior drag/drop of filenames from treeview. P4Win allows you to drag/drop filenames in local workspace syntax. P4V on the other hand drags/drops in depot syntax – there does not seem to be any way to quickly get filenames in workspace syntax. 

4). P4V can’t integrate a selection of files, it can only integrate single files or entire folders. 

5). P4V doesn’t provide the ability to sort pending changelist by criteria. 

6). P4V doesn’t offer safe automatic merge when integrating a single file. 

7). P4V doesn’t have a default resolve type. 

8). P4V doesn’t allow use of Enter/Ctrl+Enter to select the default action in dialogs (instead you have to use a mouse or press TAB several times). 

9). Many dialogs lack a Cancel button but escape key, in many cases, does the same thing. 

10). P4V suffers from a general lack of keyboard shortcuts (like Ctrl+Shift+M for resolve). 

11). P4V provides no way to “p4 set” defaults and hence interoperates badly with command prompts and scripts. 

13). P4V has lacks command line features of P4Win. 

14). And finally, IMO, P4V is just a more cluttered interface, you spend forever having to resize, switch views and generally fiddle with things. P4Win was fine!But 2008.2 beta release notes that several more dialogs and column-width settings are remembered now 

15). P4V bookmarks no longer cross depots and don’t have keyboard shortcuts. Under P4Win, I constantly switch my current window between depots and file areas using keyboard shortcuts. I have no idea why P4V separates favorites from bookmarks with neither doing the whole job.Favorites is also intent on opening a new app each time rather than just switching which just clutters my desktop. P4V needs the more powerful bookmark function from P4Win. 

16). There is no P4V “resync to same changelist” menu item. I use this frequently when I am testing something and want to wipe out the source and generated binaries and do a quick re-sync. 

17). There is no P4V menu item to update an existing client’s view from another client. We use this all the time with P4Win to update client views from template clients. 

18). P4V does not show the “Explore” and “Command Prompt here” context menus for folders—just for files. I often use this to open a window for the current folder to do something. 

19). Popping up an editor for a file that is not open for edit no longer says read-only with the revision number in the caption bar in P4V. AuthorRobert Pitt & Barry Wilks

Tagged : / / / / / / / / / / / / / / /

Major differences between CVS and CVSNT | CVS Vs CVSNT

cvs-vs-cvsnt

Major differences between CVS and CVSNT | CVS Vs CVSNT

CVSNT was started as a variation (or branch) of CVS in 1999 because patches contributed to CVS were not considered to be suitable for that project by those responsible for making such decisions at that time.
CVSNT has continued to add features to the original CVS that support modern version control and configuration management best practice as well as maintain feature parity with CVS.
Today CVSNT is the most widely deployed version of CVS and is distributed with TortoiseCVS and WinCVS.

Similarities between CVS and CVSNT

  • From a SCM perpective, they share similarity in purpose, Commands including syntax and functionality
  • Both are freeware
  • Both can be accessed through clients.
  • Both are supported with Unix-like, Windows, Mac OS X

Difference between CVS and CVSNT

  • An alternative to CVS with advance features and support
  • CVS is being maintained but new features are not being added henceforth CVSNT is being maintained and new features are under development.
  • CVS is having only merge function instead of CVSNT is having merge and locking system as well.
  • CVS is having limited features than CVSNT
Tagged : / / / / / / / / / / / / / /