Social Media links in Newsletter:- For starters, starting today any newsletter you send out, needs to have at least two of your favorite social media networks included in them. (I would recommend Facebook and Twitter).

Social Media Links in Website:- Your website needs to have visible links to all your social media platforms. The header and footer are usually is a good place for those.

Coupon Redeem through Social platforms:- If you have a plan on creating any coupons, give them options to redeem them on your Facebook page.

Social Media links to your contents:- If you do any kind of Content marketing, include relevant social platforms links at the end of it. Also, put your Twitter handles in your business cards.

Mention Social Networks in outdoor events:- Put all major social handles into any outdoor promotions, events, and campaigns.

Try to create as many follow-up opportunities as possible, to reach your audience in the future. At the end of the day, that’s what Social Media is all about, creating authentic connections.

According to the science:

The mere-exposure effect, and the familiarity effect:- Its psychological phenomenon by which people tend to develop a preference for things merely because they are familiar with them.

Studies on this have been done since the 1960s. And more recent 2001 proved that this is not even done at a conscious level. This means your brain doesn’t even think when liking something which it considers familiar.

Do you think your choice of a brand is random or on purpose?

Well, guess again. And this knowledge has been used by advertising agencies for ages, that’s why you see the same ADs over and over again. So remember this the next time you have any doubts about mentioning your social media accounts anywhere else within your marketing channels. Because it can make the difference if people picks your products from the line-up, or goes for your biggest competitor.

Jumps on trends early

As a business owner it’s your responsibility to innovate and bring something new for the customer before your competitiors – so always JUMPS on trends early.

Peter Drucker (Marketing Expert) once said “Business is nothing more than marketing and innovation”.

The reason why you should be an early adopter, it’s obvious – get more traction. Because there is less competition. It’s like having more channels on TV. The more of them available, the smaller the percentage of people that will look at a particular channel. Even if the content your produce is of impeccable quality, due to the sheer number of alternatives, few people will ever get to discover you. But if you are an early adopter, the chances of users stumbling onto your brand are much higher.

Thus’ the chance for your business to grow on that particular platform will be higher. Even, this effect is more powerful for non-mega brands like Coke or Ford or GM. And let’s say the network you join doesn’t grow and is all hype, the loss in time spent there for your business is always outweighed by the alternative of that particular network exploding in attention, and getting the spotlight on your brand as well.

Being an early adopter is more than a social media choice. It should be a life choice if your goals are to deliver groundbreaking work. In the past, the risks involved were higher. Think of all the lives lost and accidents when designing and creating the first airplanes, submarines or cars. It took lots of iterations to get things safe for the masses. And it will take you as well, a lot of effort to create and offer great products and services. But unlike the past, then the risk was literally life-threatening, your risk is the only time, and sometimes money, and even these two are not in huge amounts.

So the next time you hear about a new social media network on the rise, give it a look. See if it makes sense for your business, and jump on it early on, and become a power player on that platform.

The post Social Media Marketing – TIPS – Interconnect Everything & Jumps on trends early appeared first on scmGalaxy.

http://www.joomlaaa.com/Joomla-Articles/optimization/How-can-I-make-my-Joomla-site-load-faster.html

http://www.joomlaperformance.com

http://www.websiteoptimization.com

http://www.pathos-seo.com/joomla-technical-optimization/making-a-faster-joomla-website.html

http://www.pathos-seo.com/joomla-technical-optimization/making-a-faster-joomla-website.html

http://www.wzcreativetechnology.com/joomla-tips-and-tricks/74-how-to-make-joomla-site-load-fast.html

http://extensions.joomla.org/extensions/site-management/cache/7350

http://www.open-source-depot.com/archives/13-MySQL-Performance-Tip-on-CentOS4-on-GoDaddy.html

http://www.open-source-depot.com/archives/13-MySQL-Performance-Tip-on-CentOS4-on-GoDaddy.html

http://www.cyberciti.biz/tips/enable-the-query-cache-in-mysql-to-improve-performance.html

http://forum.joomla.org/viewtopic.php?f=433&t=344013l

http://kb.siteground.com/article/How_to_optimize_a_MySQL_database_using_phpMyAdmin.html

http://www.electrictoolbox.com/mysql-optimize-table-cli/

http://forum.joomla.org/viewtopic.php?p=1250059

http://kb.siteground.com/article/How_to_optimize_a_MySQL_database.html

http://developer.yahoo.com/performance/rules.html

http://www.mightyjoomla.com/Joomla-Tips-Tricks/enable-and-use-gzip-compression-in-joomla-cms-to-enhance-website-performance.html

http://forum.joomla.org/viewtopic.php?t=50278

www.websiteoptimization.com/services/analyze/

http://forum.joomla.org/viewtopic.php?t=50278

http://www.phpmagicbook.com/htaccess-essential-tricks-for-blog-website-performance-a-guide/

http://www.dquinn.net/htaccess-adding-etags-gzip-expires-headers/

The post Joomla Website Performance appeared first on scmGalaxy.

These days in software industry one word is high in trend and that is “DevOps”. Industry experts define DevOps either as a “culture” or “methodology”. But when organizations and companies looking for DevOps expert for their projects or organizations they post job ad like this “Hiring or Looking” for “DevOps Engineer” or “DevOps Architect”. So we can say DevOps is a culture and methodology but it’s a “Role” too.

Today DevOps is reforming the software industry. DevOps integrates developers and operation teams in order to improve collaboration and productivity by automation infrastructure, automating workflows and continuously application performance. These days almost all IT organizations are executing DevOps in their software development process from initial product planning stage to security assurance to quality to user’s feedback. They implementing it because it gives them technical and business benefits. It gives them to deploy code more frequently with less failure rates. By implementing DevOps organizations can provide continuous delivery of software’s with less complex problems to fix and faster solutions of the problems which ultimately means faster delivery of the features, more stable operating environments and they can have more time to add value rather than spending time on fixing and maintaining. This is the reason organizations wants to hire DevOps engineers without wasting any time.

So, let’s see who can become a DevOps engineer.

·         Anyone who is in software development or system operations can become a DevOps engineer.

Yes, you read it write, to become a DevOps engineer you does not need educational and formal career track. Either developers who are interested in network operations and deployments or system Admins who have an enthusiasm for scripting and coding, and move into the development side where they can enhance the planning of test and organizations they all can become a DevOps engineers.

Now, let’s check the skills a DevOps engineer should have:-

·         Knowledge of coding and scripting.

·         Experienced with systems and IT operations

·         Should be comfortable with frequent, incremental code testing and deployment and should be able to adapt ever changing environment.

·         Strong grasp of automation tools

·         They should have skills of Data management.

·         A strong emphasis on business results.

·         Ability to work in team and make them all work together.

·         Should be comfortable with collaboration, communication and reaching ability beyond functional areas.

·         Linux or Windows or Hybrid command line knowledge

·         Must be able to understand and utilize a wide variety of open source technologies and tools.

Now let’s look on the process to become a DevOps engineer.

One who accomplishes the thorough necessities to end up distinctly a DevOps engineer can hope to be enormously rewarded. It’s never been a superior or more gainful time to consider DevOps as a profession way or a career change.

One thing is for sure that DevOps is come here to stay and if you wants to become a DevOps engineer than you must need to enhance above mentioned skills. Remember that DevOps is less about doing things in a specific way, and more about advancing the business and giving it a more grounded innovative favorable position.

To start your career as a DevOps engineer you must need a mentor or instructor to help you in this and I would like to suggest scmGalaxy which is a one stop portal for DevOps learning where you can find DevOps tutorials, DevOps courses, certifications, trainers, study materials and much more all in one place. They have well designed DevOps courses and certification programs and well known dedicated DevOps trainers who can help you to become a successful DevOps engineers.

The post How can you become a successful DevOps Engineer ? appeared first on scmGalaxy.

• A decent trainer makes conveying a class look simple and consistent.
• A  best DevOps trainer is sensitive to his or her own particular vitality level and that of the class.
• Since DevOps trainer are good examples, they ought to be develop, certain and energetic.
• A best DevOps trainer knows the material, lives it, inhales it, and can imbue their own understanding into it.

Status to allow and encourage participants to learn from themselves and the class in order to create as many organic learning moments as possible.

The post Tips to find qualified DevOps Trainers, Instructors and Coach? appeared first on scmGalaxy.

The post Vagrant installation in Centos, Ubuntu and Windows | Vagrant Tutorials appeared first on scmGalaxy.

Team building requires dedication and effective skills. Each member of the team must be made to feel an integral and indispensible part of the team so that team strategy and goals can be placed above individual goals.There are various team building games and exercises available but it is only with perfect execution and participation of all members can these be effective. It is also important to resolve any conflicts as soon as possible. Conflicts can be very harmful for team building. Negative feedback, especially in public should be avoided at all cost as it may hamper the team’s performance.

The post Useful Tips to Make Team Building Exercises Effective and Successful appeared first on scmGalaxy.

This document will help you upgrade Continuum from 1.2.x to 1.3.3 and above.

When upgrading Continuum, it could have some database model changes. Usually these changes will be migrated for you, but in some cases you may need to use a backup from the previous version and restore that data into the new version. The Data Management tool exports data from the old database model and imports the data into the new database model.

If you had used the APP_BASE environment variable in Continuum 1.2 to differentiate your configuration from the installation, you should rename it to CONTINUUM_BASE in Continuum 1.3.

Note: The Jetty version in Continuum 1.3.4 and above has been upgraded to 6.1.19. When upgrading to Continuum 1.3.4 or higher, there is a need to update the library contents listed in $CONTINUUM_BASE/conf/wrapper.conf with the ones included in the new distribution especially if the $CONTINUUM_BASE directory is separate from the installation.

Using Backup and Restore to upgrade

There are 2 databases that need to be considered: one for the builds and one for the users.

There were no changes in the users database from 1.2.x to 1.3.2, so you can simply point Continuum 1.3.2 at your existing user database.

The builds database has had model changes, and will need to be exported and imported.

First, download the Data Management tools you will need. The tool is a standalone JAR that you can download from the central repo.

You will need to download two versions of the tool, one for the export out of the old version and one for the import into the new version:

Note: The 1.2, 1.2.2 and 1.2.3 released versions of this tool have a bug. To export databases from 1.2.2 or 1.2.3, you will need to use version 1.2.3.1 of the tool. To export databases from 1.2, you may use the 1.1 version of the tool.

• http://repo1.maven.org/maven2/org/apache/continuum/data-management-cli/1.3.2/data-management-cli-1.3.2-app.jar
• http://repo1.maven.org/maven2/org/apache/continuum/data-management-cli/1.2.3.1/data-management-cli-1.2.3.1-app.jar
• http://repo1.maven.org/maven2/org/apache/maven/continuum/data-management-cli/1.1/data-management-cli-1.1-app.jar

Next, follow these steps to export data from the old version

• Stop the old version of Continuum
• Execute this command to create the builds.xml export file

java -Xmx512m -jar data-management-cli-1.2.x-app.jar -buildsJdbcUrl jdbc:derby:${old.continuum.home}/data/databases/continuum -mode EXPORT -directory backups

Then, follow these steps to import the data to the new version

• Start the new version of Continuum to create the new data model, but do not configure it.
• Stop Continuum
• Execute this command to import the builds data from the xml file you created earlier:

java -Xmx512m -jar data-management-cli-1.3.2-app.jar -buildsJdbcUrl jdbc:derby:${new.continuum.home}/data/databases/continuum -mode IMPORT -directory backups -strict

Note: Remove -strict when importing data from 1.3.1 to 1.3.x to ignore unrecognized tags due to model changes.

Finally, be aware that sometimes the NEXT_VAL values in the SEQUENCE_TABLE need to be adjusted.

• Before starting Continuum for the first time after the import, connect to the db with a client like Squirrel SQL and check the values in the NEXT_VAL column of the SEQUENCE_TABLE.
• Values must be greater than the max id value in each table.
• For example, the next value of “org.apache.maven.continuum.model.Project” must be greater than the greatest id in Project table.
• Here are some example SQL statements. You may need to add or remove lines depending on the contents of your database.

UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(systemconfiguration_id)+1 from SYSTEMCONFIGURATION) WHERE SEQUENCE_NAME='org.apache.maven.continuum.model.system.SystemConfiguration';
UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(id)+1 from BUILDQUEUE) WHERE SEQUENCE_NAME='org.apache.maven.continuum.model.project.BuildQueue';
UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(id)+1 from SCHEDULE) WHERE SEQUENCE_NAME='org.apache.maven.continuum.model.project.Schedule';
UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(id)+1 from BUILDDEFINITION) WHERE SEQUENCE_NAME='org.apache.maven.continuum.model.project.BuildDefinition';
UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(id)+1 from LOCALREPOSITORY) WHERE SEQUENCE_NAME='org.apache.continuum.model.repository.LocalRepository';
UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(id)+1 from PROJECTGROUP) WHERE SEQUENCE_NAME='org.apache.maven.continuum.model.project.ProjectGroup';
UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(scmresult_id)+1 from SCMRESULT) WHERE SEQUENCE_NAME='org.apache.maven.continuum.model.scm.ScmResult';
UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(projectdependency_id)+1 from PROJECTDEPENDENCY) WHERE SEQUENCE_NAME='org.apache.maven.continuum.model.project.ProjectDependency';
UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(id)+1 from BUILDDEFINITIONTEMPLATE) WHERE SEQUENCE_NAME='org.apache.maven.continuum.model.project.BuildDefinitionTemplate';
UPDATE SEQUENCE_TABLE set NEXT_VAL = (select max(id)+1 from ABSTRACTPURGECONFIGURATION) WHERE SEQUENCE_NAME='org.apache.continuum.model.repository.AbstractPurgeConfiguration';

Now you can start your new version of Continuum.

Reference: http://continuum.apache.org/docs/1.3.6/installation/upgrade.html

The post Upgrading Continuum – Continuum Upgradation Guide appeared first on scmGalaxy.

When writing JUnit tests developers often add log statements that can help provide information on test failures. During the initial attempt to find a failure a simple System.out.println() statement is usually the first resort of most developers.

Replacing these System.out.println() statements with log statements is the first improvement on this technique. Using SLF4J (Simple Logging Facade for Java) provides some neat improvements using parameterized messages. Combining SLF4J with JUnit 4 rule implementations can provide more efficient test class logging techniques.

Some examples will help to illustrate how SLF4J and JUnit 4 rule implementation offers improved test logging techniques. As mentioned the inital solution by developers is to use System.out.println() statements. The simple example code below shows this method.

01    import org.junit.Test;
02
03    public class LoggingTest {
04
05      @Test
06      public void testA() {
07        System.out.println(“testA being run…”);
08      }
09
10      @Test
11      public void testB() {
12        System.out.println(“testB being run…”);
13      }
14    }

The obvious improvement here is to use logging statements rather than the System.out.println() statements. Using SLF4J enables us to do this simply whilst allowing the end user to plug in their desired logging framework at deployment time. Replacing the System.out.println() statements with SLF4J log statements directly results in the following code.
view source

01    import org.junit.Test;
02    import org.slf4j.Logger;
03    import org.slf4j.LoggerFactory;
04
05    public class LoggingTest {
06
07      final Logger logger =
08        LoggerFactory.getLogger(LoggingTest.class);
09
10      @Test
11      public void testA() {
12        logger.info(“testA being run…”);
13      }
14
15      @Test
16      public void testB() {
17        logger.info(“testB being run…”);
18      }
19    }

Looking at the code it feels that the hard coded method name in the log statements would be better obtained using the @Rule TestName JUnit 4 class. This Rule makes the test name available inside method blocks. Replacing the hard coded string value with the TestName rule implementation results in the following updated code.

01    import org.junit.Rule;
02    import org.junit.Test;
03    import org.junit.rules.TestName;
04    import org.slf4j.Logger;
05    import org.slf4j.LoggerFactory;
06
07    public class LoggingTest {
08
09      @Rule public TestName name = new TestName();
10
11      final Logger logger =
12        LoggerFactory.getLogger(LoggingTest.class);
13
14      @Test
15      public void testA() {
16        logger.info(name.getMethodName() + ” being run…”);
17      }
18
19      @Test
20      public void testB() {
21        logger.info(name.getMethodName() + ” being run…”);
22      }
23    }

SLF4J offers an improved method to the log statement in the example above which provides faster logging. Use of parameterized messages enable SLF4J to evaluate whether or not to log the message at all. The message parameters will only be resolved if the message will be logged. According to the SLF4J manual this can provide an improvement of a factor of at least 30, in case of a disabled logging statement.

Updating the code to use SLF4J parameterized messages results in the following code.

01    import org.junit.Rule;
02    import org.junit.Test;
03    import org.junit.rules.TestName;
04    import org.slf4j.Logger;
05    import org.slf4j.LoggerFactory;
06
07    public class LoggingTest {
08
09      @Rule public TestName name = new TestName();
10
11      final Logger logger =
12        LoggerFactory.getLogger(LoggingTest.class);
13
14      @Test
15      public void testA() {
16        logger.info(“{} being run…”, name.getMethodName());
17      }
18
19      @Test
20      public void testB() {
21        logger.info(“{} being run…”, name.getMethodName());  }
22      }
23    }

Quite clearly the logging statements in this code don’t conform to the DRY principle.

Another JUnit 4 Rule implementation enables us to correct this issue. Using the TestWatchman we are able to create an implementation that overrides the starting(FrameworkMethod method) to provide the same functionality whilst maintaining the DRY principle. The TestWatchman Rule also enables developers to override methods invoked when the test finishes, fails or succeeds.

Using the TestWatchman Rule results in the following code.

01    import org.junit.Rule;
02    import org.junit.Test;
03    import org.junit.rules.MethodRule;
04    import org.junit.rules.TestWatchman;
05    import org.junit.runners.model.FrameworkMethod;
06    import org.slf4j.Logger;
07    import org.slf4j.LoggerFactory;
08
09    public class LoggingTest {
10
11      @Rule public MethodRule watchman = new TestWatchman() {
12        public void starting(FrameworkMethod method) {
13          logger.info(“{} being run…”, method.getName());
14        }
15      };
16
17      final Logger logger =
18        LoggerFactory.getLogger(LoggingTest.class);
19
20      @Test
21      public void testA() {
22
23      }
24
25      @Test
26      public void testB() {
27
28      }
29    }

And there you have it. A nice test code logging technique using JUnit 4 rules taking advantage of SLF4J parameterized messages.

I would be interested to hear from anyone using this or similar techniques based on JUnit 4 rules and SLF4J.

Reference: http://www.catosplace.net/

The post JUnit 4 Test Logging Tips using SLF4J appeared first on scmGalaxy.

The post How to run Remote Desktop Console by using command line? appeared first on scmGalaxy.

1 Introduction
Perforce introduced the first server-side trigger in release 99.1 with the pre-submit trigger. This trigger satisfied a long-standing desire in the user community, but demand continued for more hooks. In release 2004.2, Perforce squarely hit the need with the addition of five new trigger types. Release 2005.1 adds yet one more trigger type to this list rounding out one of the categories of triggers to completeness. This paper discusses triggers, techniques for implementing them and purposes for using them. It presumes a general knowledge of scripting. The examples follow in several programming languages. They should be easy to follow with knowledge of general programming, and any more arcane constructs will be explained. The paper also presumes a reasonable knowledge of Perforce scripting alternatives, such as that presented in [Bowles2005]. Although this paper will address the scripting of triggers comprehensively, it will refer to other Perforce scripting contexts and to Perforce commands with an assumption of familiarity.

1.1 What is a trigger?
Triggers are programs that run on the server immediately in response to some welldefined event in Perforce. Therefore, the context for a trigger is running on the server
using the trigger mechanism to start. Triggers are typically written in a shell script such as Perl, Python or Ruby due to the flexibility and facilities they provide. However, triggers can be written in any programming language that can interface with Perforce, including UNIX shell (sh, ksh, csh and work-alikes) and compiled languages like C/C++.

1.2 Types of triggers
Triggers fall into two categories. Pre-submit triggers enable actions in response to the submission of changelists. Form triggers allow actions in response to various stages of the life cycle of a form, regardless of the form type. This section provides a brief overview of the trigger types in preparation for the more detailed discussion.
1.2.1 Pre-submit triggers
There are three types of pre-submit triggers corresponding to different points in the life cycle of a submission.
• “Submit” triggers execute after the changelist has been created but before the files have been transferred, allowing inspection of the changelist details but disallowing file inspection.
• “Content” triggers execute after file transfer but before commit, allowing for inspection of the files.
• “Commit” triggers execute after the commit, allowing inspection of the changelist and file contents, but disallowing canceling of the submission.

1.2.2 Form triggers
Form triggers come in four types depending on the point in the form’s life cycle in which they are invoked.
• “Out” triggers execute when the form is generated and can modify the form before it is presented to the user.
• “In” triggers execute when the form is sent back to Perforce but before it is parsed, also allowing modification of the form on its way in.
• “Save” triggers execute after the form has been parsed but before it is saved, allowing reaction to the form but not modification.
• “Delete” triggers execute before a form is deleted, allowing failure of the deletion.

1.3 Why use a trigger?
Knowing why to use a trigger is partially a matter of knowing what are the competing alternatives. The alternatives naturally come from other contexts, since triggers define a context of their own. This section details the salient operational characteristics of triggers and contrasts them with Perforce alternatives. The three primary alternatives to triggers are wrapper scripts, such as p4wrapper, 1 review daemons, and journal tailers. A variation on the wrapper script would be a script available from the Tools menu in P4Win.

1.3.1 Synchronous execution
Triggers execute synchronously in response to their associated event. This provides an immediacy of response that is sometimes required or at least highly desirable. One option that provides synchronous execution could be an action invoked from a wrapper script such as p4wrapper. Another option would be to forego synchronous execution and rely on frequently running review daemons. Journal tailers would also perform asynchronously, although with very rapid and event-driven response.
1.3.2 Immediate user feedback on error
Triggers can provide messages back to the user, but only on error. Messages are not delivered on successful execution. A wrapper script can deliver messages to the user regardless of whether an error occurs or not. Review daemons and journal tailers can only provide feedback through indirect mechanisms.
1.3.3 Enforceability
Enforceability refers to the ability of an administrator to ensure that the script will run regardless of the client program used to initiate the operation. Because triggers are
installed on and executed by the server in response to server events, they will execute regardless of the client program. Wrapper scripts will only be invoked when the wrapper is used, whereas direct use of p4 or use of a different client program will circumvent the desired action. Review daemons and journal tailers are also enforceable due to their context on the server.

1.3.4 Modify a form
Form triggers can modify a form as it is delivered to the user or as it is sent back to Perforce. Wrapper scripts share this characteristic. Review daemons and journal tailers can not modify forms except to the extent that any user or administrator can after the operation has finished.
1.3.5 Customize any action
Form triggers have a limited ability to customize actions that involve forms, but they do not have the ability to react to any arbitrary command. Similarly, pre-submit triggers can only react to submits. Review daemons can only react to commands whose side effects can be reliably observed, something that is not readily available from the command line in many cases or from review mechanisms. Journal tailers have the ability to react to any action that affects database entries, which includes almost all.
1.3.6 Optimization for bulk processing
The review mechanism gives the ability to process a large number of actions in an orderly and efficient manner as long as those changes impact a counter. This optimization is not readily if at all available to triggers, wrappers or journal tailers due to their association with individual commands or journal entries.

1.3.7 Deterministic execution
Triggers and wrappers provide an exact and deterministic understanding of when they will execute relative to the command that initiates them. Review daemons are generally driven in a time-based manner and therefore do not execute deterministically relative to the Perforce command. Journal tailers are closer to deterministic than review daemons, but can conceivably execute prior to completion of a command.
1.3.8 Summary
The following table summarizes the characteristics of the scripting contexts that compete with triggers for Perforce scripting.

The post How to Write Trigger in Perforce? – Perforce Triggers Guide appeared first on scmGalaxy.

CVS Tips & Tricks

The CVS commands here assume that you are using the command line version of CVS. Tips and tricks for a specific CVS GUI are specific to each GUI and do not really belong here.

Viewing the commit log of a file.

Show current status of a file.

The status command will show you the latest version, the version in your working directory and if your local copy has been modified.

Performing a CVS diff

After developers have checked in updates to the code it may be beneficial to see what has changed, either to help solve bugs or to track changes. There are several option to do this.

1. Perform a diff between complete branches:

1. Perform a diff between a single file in two branches:

1. Perform a diff between different versions of a file:

1. Perform a diff between working version and most up to date file in database:

1. Perform a diff between working version and a specific database version:

Retrieving CVS Information on Files

To retrieve the current version and other relevant information about a file run:

To retrieve the entire change log pertaining to a file run:

Retrieving CVS Files Based Upon Revision

To retrieve a file from CVS based upon a revision number perform the following:

• To get the revision number use the log command above

Tag file in CVS as a Release

To tag files in CVS as a release perform the following:

• Run the command from within the release source dir.

Creating a Branch

I like to do the following before creating a branch:

See what tags are available and pick one.

Revert to a tagged version of HEAD.

To create a branch in CVS perform the following:

Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_36_BUG_.

Reverting to a Branch

To revert to a branch in CVS perform the following:

• Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_BUG_.

Verifying you are in a branch

To verify you are in a branch

You will see that the branch is a sticky tag.

Merge Current Branch with HEAD

Ensure that you are in the branch by reverting to the branch and Verifying that you are in the branch.

This will ensure that you are your branch is getting merged properly with HEAD so the only differences you see between your branch and the are changes that you made. You can verify this from your branch with:

You will eventually have to commit your changes you should always do a tag on the branch after your commit.

Merge HEAD into Current Branch Multiple Times (with tags) and without -kk option

This command will unfortunenately result in a lot of your ID tags getting changed at the top. Using the –kk option will avoid this problem. But then you won’t see which files have changed and You won’t know who last modified a file easily. After you run this command I recommend:

$ vim `cvs up -d | grep '^C' | sed -e 's/^C //'`

You may find the following page interesting as well: http://kb.wisc.edu/middleware/page.php?id=4087

This will grab all of the conflicting files. You can save them with :w. And step through them with :bn. You can easily close them all with :wq!.

Merge HEAD into Current Branch Multiple Times (with tags)

To merge current HEAD into a branch that has already had HEAD merged into it once, the differences between that last merge and current HEAD need to be gathered and applied to the branch. This is done by finding out when the last time HEAD was merged with the branch. Hopefully you tagged your branch. Repeat steps 1 and 2 from the previous section to create a tag for HEAD and to create a tag for your branch so you can have a backup/reference point. Then, perform the following if you have tagged the branch when merging the last time:

• Run the command from within the branched version. is the old tag in HEAD from the last time you merged (the tag that you created in Step one from the previous section). If you in this case, the format will likely be the following:

The first tag is the one created the last time HEAD was merged into the branch. The second tag is one that should have been just created. This will take all the differences between the two tags, and bring them into the branch. The next time a merge from HEAD into the branch occurs, this latest tag will be the “old” tag, and the new tag will be created at the time of the merge.

The reason for tagging the branch before a join/merge like this is to create a reference point to revert to if the need ever arises. The -kk option removes rcsid tags so that the cvs tag at the top doesn’t get flagged as a conflict on every merge/join.

Merge HEAD into Current Branch Multiple Times (without tags)

If no tags have been created for the branch when HEAD was merged into a branch at a previous time, an alternative is to use the daily build tag. Find the commit message of the last time HEAD was merged into the branch and was committed and select the daily build tag the day BEFORE that one (but only if the commit was before the daily build that day, i.e. before lunch time for GMT -06:00). An example is provided below on how to merge without tagging:

Run the command from within the branched version.

———————————-
To Avoide network confusion :-

use :- alias cvs=`cvs -z9`

causes cvs to use compression level 6.

Good links for it:-

• http://datagrams.blogspot.com/2009/01/how-to-deploy-cvs-concurrent-versions.html

• http://kb.wisc.edu/middleware/page.php?id=4087
• http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_10.html#SEC85
• http://ximbiot.com/cvs/wiki/Special/Index
• More Help!!

Refer for more on This:-

          Click Me!!

Thanks,

-Amaresh Das

The post How CVS will help to Realtime Developers ? appeared first on scmGalaxy.

CVS Best Practices

These are list of CVS Best Practices:

* Don’t share workspaces

Sharing workspaces compromises CVS’s ability to track activity by user or task.

* Don’t work outside of managed workspaces

CVS can only track work in progress when it takes place within managed workspaces. Never copy files from others sandboxes or even from outside your sandbox since you may overwrite somebody else’s code.

* Don’t use jello views

A file in your workspace should not change unless you explicitly cause the change. A “jello view” is a workspace where file changes are caused by external events beyond your control e.g. workspace built upon a tree of symbolic links to files in another workspace.

* Stay in sync with the codeline

The quality of your work depends largely on how well it meshes with others work. In other words, as changes are checked into the codeline, you should update your workspace and integrate those changes with yours. Update your code at least once in the morning daily.

* Checkin code daily

Integrating your development work with other peoples’ work also requires you to check in your changes regularly. Don’t keep your new code lying in your workspace for many days at a time. This may lead to many conflicts at a later stage when you try to merge.

* Never check in without compiling and testing your code

* Always update your modules/ files and resolve any conflicts before committing

* After committing changes, diff with previous version to make sure you did not accidentally overwrite anybody else’s code

* If you overwrite somebody else’s code, rollback

* Always communicate any changes you commit, to all those concerned with the module/ file that was changed

* Always add comments when committing changes

Good and meaningful comments make it easy for others to know exactly what was changed. For e.g. if it’s a bug fix it should have a Bug Number.

* Add whitespaces with discretion

Changes to whitespaces cause unnecessary updates to happen and may show conflicts during merges

The post What are the Best Practices of CVS? appeared first on scmGalaxy.

CVS Best Practices

These are list of CVS Best Practices:

* Don’t share workspaces

Sharing workspaces compromises CVS’s ability to track activity by user or task.

* Don’t work outside of managed workspaces

CVS can only track work in progress when it takes place within managed workspaces. Never copy files from others sandboxes or even from outside your sandbox since you may overwrite somebody else’s code.

* Don’t use jello views

A file in your workspace should not change unless you explicitly cause the change. A “jello view” is a workspace where file changes are caused by external events beyond your control e.g. workspace built upon a tree of symbolic links to files in another workspace.

* Stay in sync with the codeline

The quality of your work depends largely on how well it meshes with others work. In other words, as changes are checked into the codeline, you should update your workspace and integrate those changes with yours. Update your code at least once in the morning daily.

* Checkin code daily

Integrating your development work with other peoples’ work also requires you to check in your changes regularly. Don’t keep your new code lying in your workspace for many days at a time. This may lead to many conflicts at a later stage when you try to merge.

* Never check in without compiling and testing your code

* Always update your modules/ files and resolve any conflicts before committing

* After committing changes, diff with previous version to make sure you did not accidentally overwrite anybody else’s code

* If you overwrite somebody else’s code, rollback

* Always communicate any changes you commit, to all those concerned with the module/ file that was changed

* Always add comments when committing changes

Good and meaningful comments make it easy for others to know exactly what was changed. For e.g. if it’s a bug fix it should have a Bug Number.

* Add whitespaces with discretion

Changes to whitespaces cause unnecessary updates to happen and may show conflicts during merges

The post CVS Best Practices – List of CVS Best Practices – CVS Tips appeared first on scmGalaxy.

Link: http://www.collab.net/downloads/subversion/

1. Platform and configuration

   Product: CollabNet Subversion server

   Certified platforms: Windows XP SP2, Win 2003(Standard Edition) R2

   Apache version: 2.2.8

   ViewVC: 1.0.5 (requires ActiveState Python 2.5)

   Repository format: fsfs (bdb support not included)

   Prerequisite: The user needs administrative privileges to install

   and uninstall CollabNet Subversion.

2. IMPORTANT: Apache version upgraded from 2.0 to 2.2

   With the CollabNet Subversion 1.5.0 release, we have upgraded the included

   Apache server version from 2.0 to 2.2. This is consistent with the

   packages we provide for other operating systems, and also upgrades our

   package to the best available version of Apache.

   This is important to existing users because your current Apache 2.0 server

   configuration cannot be automatically updated to the format of the Apache

   2.2 configuration file. If you allow the installer to upgrade your existing

   installation, it backs up your Apache conf, logs, and htdocs folders so

   that you can refer to your previous configuration when configuring your new

   server.

3. Installation tips

     If you install an Apache server, the installer asks you for a

     “Repository URL.” This represents the prefix of the URL which users can

     use to connect to Subversion. If you set this URL to ‘/svn’, then users

     can checkout their repository from:

        http://hostname/svn/repos-name

     We recommend that you use ‘/svn’ as your URL prefix, as this is common

     practice.

4. ViewVC installation

   Users of the Apache web server option can now also have ViewVC automatically

   installed and configured as part of the installation. You must have

   ActiveState’s ActivePython 2.5 installed before installing CollabNet Subversion.

   Download a free version of ActivePython from:

   http://www.activestate.com/Products/activepython/index.mhtml

   You must install version 2.5.x.

5. Upgrade procedure

   When the installer detects a previous version, it offers to upgrade your existing

   installation. However, if you want to add ViewVC to your installation, we

   recommend you use the following process for an upgrade. In general, this is

   the best process for any upgrade scenario:

   1. Stop Apache or Subversion Server services, if running.

   2. Copy/back up any customizations that were done to your Apache installation.

     (For example, your httpd.conf file, a password database, any content you

      added to the htdocs folder, and so on.)

   3. Uninstall the currently installed version.

   4. Manually delete the existing folder if the installer did not remove it. The

      uninstall process does not remove files that were added or modified after

      installation.

   5. Follow the normal install instructions for 1.5.

   6. Manually put back your Apache customizations. NOTE:  You cannot simply copy

      back the previous configuration file. You must make the appropriate edits

      to your new Apache 2.2 version of the configuration file.

6. Post-installation instructions

   The installer created a folder to store your repositories. You are not required

   to use this folder, but if you let the installer install the server to run as a

   service, then the server has also been configured to serve repositories from this

   location. It is a good idea to use the location you specified in the installer.

   A. Using svnserve

      ==============

   To use svnserve as your server, follow these steps:

     1. Open a new terminal (command prompt).

        NOTE: If you have an old command prompt open (prior to the Subversion

              installation), remember to open a brand new command prompt.

     2. Create a subversion repository.

        cd <Repository_Path>

        svnadmin create <Repository_Name>

        For example:

        cd \repositories

        svnadmin create my-first-repos

     3. Setup a password database.

        Using notepad, edit the svnserve.conf file inside the conf directory of your

        repository.

        For example:

        If your repository is C:\repositories\my-first-repos

        svnserve.conf is:

        C:\repositories\my-first-repos\conf\svnserve.conf

        Inside svnserve.conf, you see the following information:

         ### The password-db option controls the location of the password

         ### database file.  Unless you specify a path starting with a /,

         ### the file’s location is relative to the conf directory.

         ### Uncomment the line below to use the default password file.

         #password-db = passwd

       Follow the above instructions, and uncomment the “password-db=passwd”

       line, so that it simply says:

          password-db = passwd

     4. Setup usernames and passwords.

       Next, edit the passwd file. This passwd file is located in the

       same directory as svnserve.conf.

       Inside the passwd file, you see the following information:

       ### This file is an example password file for svnserve.

       ### Its format is similar to that of svnserve.conf. As shown in the

       ### example below it contains one section labelled [users].

       ### The name and password for each user follow, one account per line.

       [users]

       #harry = harryssecret

       #sally = sallyssecret

       To add a new user account, add your own username and password

       inside the [users] section. For example, if your name is “joe”,

       and you want to set your password to “super-secret”, add a

       new line like this:

         joe = super-secret

       Add as many users as you like.

     5. Open Port on Windows firewall.

        Before starting the server, the firewall must be notified that

        this particular port is going to be used. To enable this port in the

        Windows firewall, follow the instructions found here:

    http://www.microsoft.com/windowsxp/using/security/internet/sp2_wfexceptions.mspx

        Note: svnserve.exe is the program name which needs to be added to the

        exceptions list. Alternatively, you can also use the port where

        you decide to run the server. By default, svnserve runs on 3690.

     6. Start svnserve.

        If you elected to have the installer setup svnserve as a service, then open

        the Services application, find the entry for the Subversion server, and take

        the Start option. The service has been configured to start automatically

        on reboot. You can also run this command from the command line:

        net start svnserve

        If you did not install svnserve as a service and want to start the server

        manually, run this command:

        svnserve -d -r <Repository_Path>

        For example: svnserve -d -r C:\repositories

     7. To provide read and write access to anonymous users, modify the

        conf/svnserve.conf file inside the repository.

        anon-access = write

        To restrict an anonymous user from the repository:

        anon-access = none

     8. Check out the repository.

        svn co svn://localhost/<Repository_Name>

        For example: svn co svn://localhost/my-first-repos

     Tip: If you check out your Subversion repository from a different computer,

     replace ‘localhost’ with the IP address or hostname of the machine which

     hosts the Subversion repository.

   B. Using Apache

      ============

   To use Apache as your server, follow these steps:

     1. Configure Apache.

        The installer did these steps automatically based on the repository location

        entered in the installer. This information is only presented if you want to

        manually modify the configuration.

        Use notepad to edit the httpd.conf file inside the httpd\conf directory of your

        CollabNet Subversion Server installation.

        Tip: By default, httpd.conf is in the following directory:

             C:\Program Files\CollabNet Subversion Server\httpd\conf\httpd.conf

        At the bottom of the httpd.conf file, you see a location directive that looks

        something like this:

          <Location /svn>

            DAV svn

            SVNParentPath C:\repositories

          </Location>

        Change the above section to look like the following:

          <Location /svn>

            DAV svn

            SVNParentPath C:\repositories

            SVNListParentPath On

            Require valid-user

            AuthType Basic

            AuthName “Subversion repository”

            AuthUserFile C:\repositories\password-file

          </Location>

     2. Open a new terminal (command prompt).

        NOTE: If you have an old command prompt open (prior to the Subversion

              installation), remember to open a new command prompt.

     3. Create Subversion users.

        Now create usernames with passwords that can be used to authenticate with

        Apache. Use the htpasswd command to create usernames and passwords for the

        Apache server.

        Type the following at the command prompt:

          htpasswd -cm <password-file> <username>

        This command prompts you for a password for the user. Enter the

        password and retype the password when prompted.

        For example: If you want to create a user ‘joe’, and the file at

        “C:\repositories\password-file”, type the following at the

         command prompt:

               htpasswd -cm C:\repositories\password-file joe

        Enter the desired password for the user and retype the password

        when prompted.

        For additional users, use the following command at the command prompt:

        htpasswd -m C:\repositories\password-file joe

     4. Create a Subversion repository.

        svnadmin create <Repository_Path>\<Repository_Name>

        For example: svnadmin create C:\repositories\my-first-repos

     5. Open Port on Windows firewall.

        Before starting the server, the firewall must be notified that

        this particular port is going to be used. To enable this port in the

        Windows firewall, follow the instructions found here:

    http://www.microsoft.com/windowsxp/using/security/internet/sp2_wfexceptions.mspx

        Note: apache.exe is the program name which you need add to the

        exceptions list. Alternatively, you can also use the port where

        you decide to run the server. By default, apache is run on 80.

     6. Start Apache.

        If you elected to have the installer set up Apache as a service, then open

        the Services application, find the entry for Apache/2, and take

        the Start option. The service was configured to start automatically

        on reboot. You can also run this command from the command line:

        net start apache2

        To start the server manually, run the following at the command prompt:

        apache

     7. Checkout the repository.

        svn co http://localhost/svn/<Repository_Name>

        For example: svn co http://localhost/svn/my-first-repos

        Tip: If you check out your Subversion repository from a different

        computer, replace ‘localhost’ with the IP address or hostname

        of the machine which hosts the Subversion repository.

7. Known issues

   When trying to access a repository via ViewVC, you might see an error

   trace that ends with this message:

      ImportError: DLL load failed with error code 182

   This error occurs when you have an older version of the OpenSSL DLLs in your

   PATH ahead of the CollabNet Subversion bin folder. Many Windows applications

   ship the OpenSSL DLLs and many of them also use older versions. To fix this

   problem:

      1. Edit your PATH so that the CollabNet Subversion bin folder is at or

         near the beginning of your PATH.

      2. Reboot so that your Apache service can pick up the change.

8. Back-end support

  If you try to access an existing BDB (Berkeley DB) based repository through

  CollabNet Subversion, then you might receive an alert “Failed to load module

  for FS type ‘bdb’.” This is because CollabNet Subversion does not support BDB.

  CollabNet recommends FSFS over BDB for ease of maintenance and supportability.

9. Support for CollabNet Subversion

   Find out about CollabNet Technical Support at

   http://www.collab.net/services/subversion/

   Information about CollabNet Training, Consulting, and Migration

   services is at http://www.collab.net/services/subversion/training.html

   Join openCollabNet for community support: http://open.collab.net

10 About Subversion and CollabNet

   CollabNet launched the Subversion project in 2000 in response to the demand

   for an open standard for Web-based software configuration management that

   could support distributed development. CollabNet continues to be strongly

   involved with the Subversion project and offers CollabNet Subversion Support,

   Training, and Consulting services.

   CollabNet also provides the most widely used collaborative development

   environment in the world. More than 1,400,000 developers and IT projects

   managers collaborate online through CollabNet. The company is transforming

   the way software is developed by enabling organizations to leverage global

   development talents to deliver better products and innovate faster.

   Visit CollabNet at http://www.collab.net for more information.

The post Process to Install CollabNet SVN Command Line Client in Windows appeared first on scmGalaxy.

Link: http://www.collab.net/downloads/subversion/solaris.html

1. Platform and configuration

Product: CollabNet Subversion client

Platforms: Solaris 10 SPARC

Prerequisite: You must be a superuser (root) to install and uninstall

CollabNet Subversion.

2. Import/Update CollabNet certificate

CollabNet Subversion Solaris packages are signed. As a one-time task,

import the CollabNet certificate using the command:

    sudo pkgadm addcert -ty certificate.pem

The CollabNet certificate is available for download at:

http://www.collab.net/nonav/downloads/subversion/certificate/certificate.pem

NOTE: the certificate has changed between 1.5.0 and 1.5.1 release.  The

certificate used for 1.5.0 had a short expiration date so we have created

a new certificate.  If you have previously installed the 1.5.0 certificate,

you must remove it before installing the new one:

    sudo pkgadm removecert “Alexander Thomas(AT)”

Once it is removed you can install the new certificate.

3. First installation

The command to install the CollabNet Subversion client, if a previous version

has not already been installed, is:

    sudo pkgadd -d /path/to/client-sparc-local

4. Updating an existing installation

The proper way to update a Solaris package is to remove the current version

and then install the new version.  If you have the CollabNet Subversion server

installed, you will need to remove it first.  Again, refer to the readme for

that package before proceeding.

    sudo pkgrm CSVNclnt

    sudo pkgadd -d /path/to/client-sparc-local

5. Post-installation instructions

A. CollabNet Subversion installs into /opt/CollabNet_Subversion, which is

   probably not on the executable search path for your system. Add the directory

   /opt/CollabNet_Subversion/bin to your $PATH environment variable. In order to

   make this change affect all users of your system and persists across reboots,

   add the following line to /etc/profile:

    PATH=/opt/CollabNet_Subversion/bin:$PATH

B. CollabNet Subversion provides man pages and localizations for several

   languages. To take advantage of these features, update your MANPATH and/or

   LOCPATH environment variables to include the CollabNet Subversion directories.

   For example:

    export MANPATH=/opt/CollabNet_Subversion/share/man:$MANPATH

    export LOCPATH=/opt/CollabNet_Subversion/share/locale:$LOCPATH

6. Support for CollabNet Subversion

Find out about CollabNet Technical Support at

http://www.collab.net/services/subversion/

Information about CollabNet Training, Consulting, and Migration

services is at http://www.collab.net/services/subversion/training.html

Join openCollabNet for community support: http://open.collab.net

7. About Subversion and CollabNet

CollabNet launched the Subversion project in 2000 in response to the demand

for an open standard for Web-based software configuration management that

could support distributed development. CollabNet continues to be strongly

involved with the Subversion project and offers CollabNet Subversion Support,

Training, and Consulting services.

CollabNet also provides the most widely used collaborative development

environment in the world. More than 1,400,000 developers and IT projects

managers collaborate online through CollabNet. The company is transforming

the way software is developed by enabling organizations to leverage global

development talents to deliver better products and innovate faster.

Visit CollabNet at http://www.collab.net for more information

The post How to Install CollabNet SVN Command Line Client in Solaris? appeared first on scmGalaxy.