Download gitlab from
https://www.gitlab.com/downloads/
Installation, setup, configuration, backup Instructions is given in…
Tag: Tutorials
Depot Migration between perforce servers with history and change list
There are many questions asked for the depot migration between server without losing any of the history such as…
- Moving depots across servers
- Moving depots between servers
- Move a product depot from one Perforce server to another
- Depot Migration between perforce servers with history and change list
There are one solution which i find worth to try it out?
1. Take A full backup of Source perforce server including jounals and file systems using checkpoint featres
2. Then obliterate everything in the Source server that you didn’t want to copy – and remove redundant changelists with p4 change -f -d (refer p4 manuals)
3. Go back to the Source server and obliterate the bit you’ve moved and remove redunant changelists again.
4. Now using p4merge tool, you can merger source and destination servers. this tools will help you for how to merge two separate servers into a single combined server using the Perfmerge++ utility.
What is Perfmerge++?
Perfmerge++ is a tool for merging two Perforce repositories to produce a third repository; it replaces the venerable perfmerge2.pl script. Unlike its predecessor, perfmerge++ does not work with checkpoints, rather it accesses the database files directly and creates new database files in the target directory. These new database files contain the merged content.
Reference:
http://kb.perforce.com/article/911
ftp://ftp.perforce.com/perforce/tools/perfmerge/perfmerge.html
How to put comment in Ant | Comments in Apache Ant
How to put comment in Ant | Comments in Apache Ant
Method 1:
<!– Comments are just as important in buildfiles, do not –>
<!– avoid writing them! –>
<!– Example build file for “Ant: The Definitive Guide” –>
<!– and its sample project: irssibot –>
Method 2: Echo
Description
Writes a message to the Ant logging facilities. A message may be supplied
as nested text to this task.
Echoes a message to the current loggers and listeners which means System.out unless overridden. A level can be specified, which controls at what logging level the message is filtered at.
The task can also echo to a file, in which case the option to append rather than overwrite the file is available, and the level option is ignored
Parameters
| Attribute | Description |
Required |
| message | the message to echo. |
No. Text may also be included in a character section within this element. If neither is included a blank line will be emitted in the output. |
| file | the file to write the message to. |
No |
| append | Append to an existing file (or open a new file / overwrite an existing file)? |
No – default is false. |
| level | Control the level at which this message is reported. One of “error”, “warning”, “info”, “verbose”, “debug” (decreasing order) |
No – default is “warning”. |
| encoding | encoding to use, default is “”; the local system encoding. since Ant 1.7 |
No |
Examples
Style 1:
<echo message=”Hello, world”/>
Style 2:
<echo message=”Embed a line break:${line.separator}”/>
Style 3:
<echo>Embed another:${line.separator}</echo>
Style 4:
<echo>This is a longer message stretching over
two lines.
</echo>
Style 5:
<echo>
This is a longer message stretching over
three lines; the first line is a blank
</echo>
Style 5:
<echo message=”Deleting drive C:” level=”debug”/>
A message which only appears in -debug mode.
Style 6:
<echo level=”error”>
Imminent failure in the antimatter containment facility.
Please withdraw to safe location at least 50km away.
</echo>
A message which appears even in -quiet mode.
Style 7:
<echo file=”runner.csh” append=”false”>#\!/bin/tcsh
java-1.3.1 -mx1024m ${project.entrypoint} $$*
</echo>
Generate a shell script by echoing to a file. Note the use of a double $ symbol to stop Ant filtering out the single $ during variable expansion
Depending on the loglevel Ant runs, messages are print out or silently ignored:
| Ant-Statement |
-quiet, -q |
no statement |
-verbose, -v |
-debug, -d |
| <echo message=”This is error message.” level=”error” /> |
ok |
ok |
ok |
ok |
| <echo message=”This is warning message.” /> |
ok |
ok |
ok |
ok |
| <echo message=”This is warning message.” level=”warning” /> |
ok |
ok |
ok |
ok |
| <echo message=”This is info message.” level=”info” /> |
not logged |
ok |
ok |
ok |
| <echo message=”This is verbose message.” level=”verbose” /> |
not logged |
not logged |
ok |
ok |
| <echo message=”This is debug message.” level=”debug” /> |
not logged |
not logged |
not logged |
ok |
Method 3:
Description
Clover and Maven working with Distributed Applications
1. Configure maven clover plugin.
2. Build the all components with clover enabled.
3. Deploy the clover enabled build to test server.
4. Run the tests.
5. Create & Review the Code Coverage Report.
Configure Maven Clover Plugin
Configure the maven plugin in pom.xml .If you are having multi module projects; you can configure the plugin in parent-pom instead of modifying each module’s pom xml.
Build all components with clover enabled.
Run the following command.
“mvn -U clover2:setup package clover2:aggregate”
If you got something like this
[INFO] Loaded from: C:\Documents and Settings\Administrator\.m2\repository\com\cenqua\clover\clover\2.6.3\clover-2.6.3.jar
[INFO] Clover: Commercial License registered to ABC Corporation.
[INFO] Creating new database at ‘C:\p4_depot\trunk\4A\target\clover\clover.db’.
[INFO] Processing files at 1.5 source level.
[INFO] Clover all over. Instrumented 5 files (1 package).
[INFO] Elapsed time = 0.532 secs. (9.398 files/sec, 812.03 srclines/sec)
Congratulation, you get clover work with your source!!
Deploy the clover enabled build to test server.
Deploy the Clover enabled build to the server. The same process as normal
Copy the Clover registry file to the appropriate directory on each of the test servers
The registry file is the DB file create during compile, defined by initstring parametersclover‐setup task, this needs to occur after the Clover build is complete, and before you run your tests
Background: the Clover initstring
FileName: xxx.db
At build time, Clover constructs a registry of your source code, and writes it to a file at the location specified in the Clover initstring. When Clover‐ instrumented code is executed (e.g. by running a suite of unit tests), Clover looks in the same location for this registry file to initialise itself. Clover then records coverage data and writes coverage recording files next to the registry file during execution
Notes: gives the folder contains the registry file full control permissions
Recommended Permissions
Clover requires access to the Java system properties for runtime configurations, as well as read write access to areas of the file system to read the Clover coverage database and to write coverage information. Clover also uses a shutdown hook to ensure that it flushes any as yet unflushed coverage information to disk when Java exits. To support these requirements, the following security
permissions are recommended:
grant codeBase “file:/path/to/clover.jar” {
permission java.util.PropertyPermission “*”, “read”;
permission java.io.FilePermission “<>”, “read, write”;
permission java.lang.RuntimePermission “shutdownHooks”;
}
Grant Permissions to clover.jar
Edit the java.policy file of the java runtime on the test server
%JAVA_HOME%/jre/lib/security
Copy clover.jar and license file to the java runtime class path of the test servers
%JAVA_HOME%/jre/lib/ext
Run the test suite
Run the test suite as normal. Either automation test case or manual test case.
Create Code Coverage Report
Copy the coverage recording files to build machine.
Once test execution is complete, you will need to copy the coverage recording files from each remote machine to the initstring path on the build machine in order to generate coverage reports.
Background: CoverageRecording Files
Filename:xxx.dbHHHHHHH_TTTTTTTTTT or clover.dbHHHHHHH_TTTTTTTTTT.1 (where HHHHHHH and TTTTTTTTTT are both hex strings)
CoverageRecording files contain actual coverage data. When running instrumented code, Clover creates one or more Coverage Recorders. Each Coverage Recorder will write one CoverageRecording file. The number of Coverage Recorders created at runtime depends the nature of the application you are Clovering. In general a new Coverage Recorder will be created for each new ClassLoader instance that loads a Clovered class file. The first hex number in the filename (HHHHHHH) is a unique number based on the recording context. The second hex number (TTTTTTTTTT) is the timestamp (ms since epoch) of the creation of the Clover Recorder. CoverageRecording files are named this way to try to minimise the chance of a name clash. While it is theoretically possible that a name clash could occur, in practice the chances are very small.
CoverageRecording files are written during the execution of Clover‐instrumented code. CoverageRecording files are read during report generation or coverage browsing.
Run the generating report goal to create the report.
“mvn clover2:clover”
How we reduced build time from 8 hours to 1 hour ? – Complete Guide
Situation
- For one of our clients, Build is taking 8 hours and nightly build is failing frequently.
- Test case execution is consuming more time than the compilation.
- Low confidence levels for developers on nightly builds and subsequently during integration cycle.
Approach
- We reviewed the whole set of build scripts being used and test case suite to check how we can refatcor them.
- Verified the build infrastructure i.e., build server capacity from hardware point of view.
- Feasibility study done to check how a CI environment help in giving faster feedback on the quality.
Solution
- Refactoring done for build scripts to make modules compilation parallel (wherever possible).
- Some test cases are selected (which don’t require external services like database) to run as part of the build.
- CI environment (using open source cruise control) is established to run builds per commit and execute only above set of test cases as part of the build.
- Set up low-cost remote agent machine which will run remaining test suite once per day.
Results
- Build took only 1 hour and gave faster feedback to dev team.
- CI environment provided good confidence to dev team.
- Team is able to implement more best practices.
- Effective use of existing build infrastructure (hardware) ensured no further cost is required.
- This helped the client in ensuring smooth release management.
How to run Remote Desktop Console by using command line?
| How to run Remote Desktop Console using command line |
| If you may want to run Desktop Console from a batch file, for example RDC over VPN, you can use mstsc /v:servername /console command.
Mstsc Creates connections to terminal servers or other remote computers, edits an existing Remote Desktop Connection (.rdp) configuration file, and migrates legacy connection files that were created with Client Connection Manager to new .rdp connection files. Syntax mstsc.exe {ConnectionFile | /v:ServerName[:Port]} [/console] [/f] [/w:Width /h:Height] ConnectionFile Specifies the name of an .rdp file for the connection. /console /f /w:Width /h:Height /edit”ConnectionFile” /migrate Remarks To connect to the console session of a server, type: To open a file called filename.rdp for editing, type: |
Process to Install CollabNet SVN Command Line Client in Windows
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.