This is very useful content to know aboutr hook in SVN

svnbook.red-bean.com/en/1.1/ch05s02.html

pre-commit hook, what is the best way of implementing using ActiveDirectory accounts, and the right way to test it before implementing it in real?

The post Hook Implementation in Subversion appeared first on scmGalaxy.

Code development has its negative and positive sides, but anything that brings more relief and gains time in a project is the developer’s best friend. CVS was for a long time the best solution for version control, adopted by all programmers in major projects. While CVS has slowly evolved into other more successful concurrent version systems like Subversion, the latest trend that manifests across the development world is the usage of DCVSs (distributed version control systems) as the main project tracking managers.

Since its launch in the mid ‘80’s and till 2000, CVS was the only real alternative as a revision control system for programmers. Not a very good one, but better than anything else. Built in 2000 by CollabNet Inc., Subversion was marketed from the start as “a better CVS” and “CVS done right.” It was truly better than CVS; unfortunately, it didn’t bring in that many new features, and under the hood, nothing has changed its core.

Because of that, there was a surge in revision control software development at the start of the 2000’s, which led to the birth and development of many DCVS projects. GNU arch and Monotone where about the first to be launched, followed by Darcs and BitKeeper.

A serious step in DVCS’ development took place after the quarrel between Linux developers and BitKeeper’s management, after BitKeeper accused one of the Linux developers of reverse engineering one of their commercially licensed features. Soon after, Linux programmers led by Linus Torvalds himself released Git as an improved open source solution to BitKeeper’s soft. Besides Git, Mercurial and Bazaar were also very successful alternatives to SVN, sharing many of Git’s features, but lagging in performance.

While SVN (Subversion) was extremely popular at the beginning, it established itself as the premiere solution in code development. Soon after, as DVCSs were developed and released, users migrated to them, abandoning SVN, opting for the more loose and faster solutions.

Nevertheless, old CVS users still tend to linger around SVN due to its familiar interface and old coding habits established over the years. Many of them question to this day Git’s efficiency in quickly putting versions together, while Git supporters, on the other hand, criticize SVN’s stiffness regarding offline work.

In many cases, the debate between Git and SVN supporters usually starts with the following features, or lack.

Git features

Offline work: Git permits any developer to branch a project and store it in a local folder as a standalone repository. After doing all the work offline, the central server or storage unit, they can than simply merge it with the central repository committing all the changes already made. This permits developers that don’t have Internet access all the time to work on a project with ease.

Central project information: Unlike SVN, which uses a .svn folder in each directory, Git uses a central .git folder in the checkout root for all project data and logs. This way, it’s easier to track changes to specific folders, on specific dates or by certain development teams. Thus, project code management is much more simplified. This also allows easy renaming of files or folders, Git automatically transmitting these changes in its history.

Easy branching: Branches and tags are much easier to create and switch in Git.

Merge history: While SVN has a branch merge history, it records all the events as coming from one user (the merger). In case a user has previously worked on a file and has not merged it, if that file is merged by another user, all the changes will be attributed to the user that merged the branch. Git, unlike SVN, can remember file changes beyond a merging point and track every user’s actions beyond project commits. Git also automatically starts the next merge at the last point it recorded.

Disk space: When the Mozilla project was ported from SVN to Mercurial (very similar to Git in performance), disk space usage went down from 12GB to 420MB, 30 times smaller than the original size. Git is supposed to use the same storage algorithms, so file size should be around the same value.

Speed: This is a no-brainer. Because all operations except for push or fetch are performed locally, Git’s speed is overwhelmingly faster than SVN could ever supply.

Better access and administration: SVN relies on an authentication module and access lists to permit users to push and merge branches. Git reduces the time spent for providing commit access to users and just lets the administration team decide what to merge and from whom.

Synchronization: It can occur over various types of media like an SSH channel, over FTP, HTTP, WebDAV, or by emails holding attached patches.

SVN features

GUI: From the beginning, SVN users have been using a GUI when managing their repository. This feature is not found at all in Git, a port for TortoiseSVN still being in the works. Besides the lack of a GUI, Git, coming from a UNIX environment, has a very complicated CLI interface with many options and arguments for its base commands.

Single major repository: Other may say this is not a good thing, but it’s a strictly SVN-specific feature. While Git allows each individual user to copy the entire repository on their computer and work on the project’s code, Subversion has always relied on permissions being given to users to only work on one single repository stored online. This feature allows the developer to always be able to download the latest version of their project without having to wait for all that work on the project to log online, upload and merge their latest branch. This is very useful in fast development environments or application troubleshooting.

Partial checkouts: Git doesn’t offer the possibility to download only a single folder from the repository. This may be a disadvantage to developers not having great bandwidth or speed.

Version numbers: Another keeper from the UNIX fathers of Git is the complicated version control numbers. While SVN uses a simple incremented decimal system, Git employs an SHA1 algorithm to output a 40-character hexadecimal string as the version number. This could get very tiring when having hundreds or more versions.

The abovementioned features are only a scratch on the surface when discussing about the version control system war between CVS/SVN supporters and DVCS users. More on the topic can be read here, which puts all the major platforms’ features next to one another so they can be compared.

Let’s now take a look at the parties involved and analyze their impact on the current programming and development world.

Subversion, as of 2009, was recently included in the Apache Incubator project, mainly because of its long usage history in most of the Apache Foundation’s projects. More details are available in one of my past articles on this topic. Other famous open source or commercial projects that have a weakness for SVN include market players like Ruby, Mono, Free Pascal, ExtJS, Tigris, PHP, MediaWiki, GCC, Django and FreeBSD. All having their source code administrated from an SVN repository.

On the other hand, the community’s favorite project, Git, is currently expanding its horizon every day, recently taking GNOME and The Perl Foundation away from SVN, placing them alongside other notable Git-powered projects like Android, Linux, openSUSE, Yahoo User Interface, x264, Digg, jQuery, X.org, Samba, Ruby on Rails, CakePHP, Fedora, Merb, Freenet, GIMP, Parrot, Qt, rsync, Wine and VLC.

Other Git-like products like Mercurial (originally designed to replace BitKeeper for Linux development) have also been adopted by major corporations and programs like Mozilla, OpenJDK, OpenSolaris, Netbeans, OpenOffice, Vim, SAGE, Growl, Wget, Symbian OS and Adblock Plus. In 2010, The Python Foundation is going to join this list, migrating from SVN.

Another Git-like DVCS platform, generally regarded by the community as being slower than Git, but much easier to learn is Bazaar. This is a product developed especially for Ubuntu, but which saw adoption in many other projects around the web, some of them like Squid, APT, MySQL, GNU Emacs, Gnash and Inkscape.

The trend is easy to see. DVCSs are adopted in more and more projects, while SVN is headed for the history books alongside its precursor, CVS. The final battle in this version control systems war is being waged on the grounds of project storing platforms the likes of SourceForge, Google Code or CodePlex. The winner of this confrontation will surely decide whether SVN will be used in the coming future or whether it will fade away from our minds like the early PC consoles.

Currently, SourceForge and GNU Savannah have the biggest and widest hosting platforms, providing version control platforms like CVS, SVN, Git, Bazaar and Mercurial to all of their users free of charge. For SourceForge, by default, a project will be hosted on Subversion. The same happens in Google Code, where SVN is the default, but the Mountain View-based crew also provides Mercurial as a DVCS alternative. Renowned hosting platform, CodePlex, provides SVN, Mercurial and Microsoft TFS hosting, while the smaller service on Project Kenai offers SVN, Git and Mercurial.

Also lately, due to high technical costs, services are starting to opt only for one version control system, putting some heat in the discussions between the CVS communities. The list is as follows: Mercurial has exclusivity on Bitbucket, Bazaar on Launchpad; Git on Github, Codaset and Gitorious, and SVN on BountySource, Freepository, GridyZone and Origo. A slim crop for SVN, but being the default service on Google Code and SourceForge might give it a fighting chance against the up-and-coming Github.

Some of you might not agree with the previous claim that this is a “battle” and should not be at all compared with the browser wars, but the community deeply rooted in the tech world already knows this is more of a fact than a myth. As proof of concept, we bring you this video from a conference at Google back in 2007, where Linus Torvalds, the inventor of Linux and Git, made some outrageous statements regarding SVN, and especially its users.

If you don’t have the time to view this one-hour long video, we’ve listened to the conference and taken some interesting quotes from Mr. Torvalds: “Subversion has been the most pointless project ever started,” continuing with “Subversion used to say CVS done right: with that slogan there is nowhere you can go. There is no way to do CVS right” and ending with “If you like using CVS, you should be in some kind of mental institution or somewhere else.”

Not very heart-warming comments from a public person like Linus Torvalds. Especially being made in the headquarters of one of the companies that have ignored Git and failed to include it in the Google Code project. Nevertheless, Mr. Torvalds might also be under the influence of an inner demon, specific to most UNIX users to prove that any project developed and coming from a Linux environment is better than anything else.

True or not, Git has seen a rise in usage, as proved by the 2008 and 2009 Kernel.org surveys, which had it ranked above any other versioning control platform like SVN, Bazaar and Mercurial, and with a crushing 94.6% rate of overall satisfaction toward the Git user experience. As a conclusion, it is generally acknowledged that future versions of Git will be adopted in more and more environments, and Git will have to fight only against other DVCSs for supremacy in the programming world.

One more good link for Advantahe of git over SVN(Subversion) …

http://markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/

The post Advantages of Git over SVN and perforce appeared first on scmGalaxy.

Next Generation Software Configuration Management with Subversion

The post Next Generation Software Configuration Management with Subversion appeared first on scmGalaxy.

When do you need branching?

You may need to adopt branching in many different scenarios. Let us assume that on a day to day basis you use agile methodologies such as extreme programming or scrum and you have finally released a reasonably complex project with Version 1.0.0.0. Couple of days after the release, you get a request for a new feature that must go as Version 1.1.0.0. You envision it will take couple of weeks to get that feature coded, tested and released. Meanwhile, simple modifications and patches are requested on a day to day basis in the Version 1.0.0.0.

Essentially, with the changing business needs you are required to do a deployment every other day or so i.e. your deployment cycle is 2 days or less.

With a team of 10 developers it will be a nightmare in the absence of a proper branching strategy.

Trunk, branch, and tag are the 3 main divisions in subversion repository.

Trunk:
The code in trunk is always maintained as close to release state as possible. Any developer making changes to the trunk must be absolutely certain that his or her part can be coded, tested and is ready to deploy within 2 days (can vary depending on your length of deployment cycle). If it takes more than 2 days, they are not allowed to directly change the code in the trunk. They have to create a branch.

Branch:
Developer Branch:
Each developer must create his or her own branch if their code will take more time to program than your normal deployment cycle. It is the responsibility of the developer to regularly (timeframe depends on your development environment) merge changes from trunk to his branch.

Feature branch:
Create a feature branch if 2 or more developers are going to work on a new feature that will take considerable time to complete. It is the responsibility of the team lead to merge changes from trunk to this feature branch on a regular basis.

It is always beneficial to merge changes from trunk frequently. Because, after a couple of days conflict between trunk version and branch version can get out of hand and merging will practically be impossible.

When the developer branch or feature branch is ready for release, merge changes back from the branch to trunk.

Tags:
Tag is similar to branch. When you create a branch simply rename the folder from branch/branches to tag. I always use Tags to tag a release whenever a new release version is deployed. This will come in handy if a very minor patch has to be made on the release version when your trunk is temporarily dirty. Ideally, you do not merge from trunk to the tag.

Finally, remember that there is no ideal branching and merging strategy. It pretty much depends on your unique development environment. If you have any other strategy, I would like to hear about that.

It is an exciting time for Subversion as its adoption continues at a dizzying pace in enterprises. I’m out there helping that adoption so I’m a bit late in posting the questions and answers I promised around the three basic branching strategies that I covered in the last two webinars in which I presented (Branching and Merging Strategies for Subversion 1.5 and Advanced Merge Tracking and Branching with Subversion 1.5). Hopefully these will be useful to many of you.

First, a quick reminder on what the three branching strategies were:

1. The unstable trunk which mimics the way that Subversion itself is developed. In this model, development is done on the trunk and a release branch is created around the time of feature completion with the formal promotion process carried out on that branch.

2. The stable trunk where development is done on system version branches and the promotion process is also conducted on that branch. The trunk is the branch point where the production releases are merged in and parallel development efforts are branched out.

3. The agile release strategy where development is done on individual feature branches and a release branch is created late in the process with the feature branches merged to it that will define that release. The formal promotion process is conducted on the release branch and the production version merged to the trunk as well as to all remaining active feature branches.

So on to the questions, first general branching questions:

Does the number of branches affect performance of the Subversion server?

No, branches are not just cheap in space and fast to create, they are alo just additional paths not unlike directories in the directory structure of your project. Of course, every tool has scalability issues at some point and Subversion logically has its limits, but in practical use, a scalability issue for Subversion around branches has not yet been experienced.

Can we use multiple strategies on one project?

Absolutely, there are many times when you may find a need to mix at least two branching models on the same project. For example, Internet applications may have very frequent releases focused primarily to address defects along with longer term release efforts to address broader feature development. The frequent releases may follow the unstable branch approach where they are worked primarily on the trunk and are branched, sometimes weekly or even more frequently, to do the formal QA to get to the release. The longer running enhancement releases may use the stable trunk philosophy though obviously the trunk isn’t actually stable, but the rest of the strategy is followed.

What strategy is best for a repository with multiple projects?

There is no need to have a single strategy in such a case. Instead one should use the appropriate method for each of the projects. Since each project should have its own top level directory for its branching model, there is no reason to force a particular method on all projects.

How does continuous integration affect branching strategies?

I’d hope that this isn’t the deciding factor in determining an appropriate branching strategy, but certainly the feasibility of continuous integration is impacted by the strategy chosen. With the unstable branch, continuous integration would be focused on the trunk and thus is stable as well as very useful as it identifies issues in the daily development commits. This is still relatively true when you look at the stable branch strategy where there may be multiple system version branches under development at the same time, but each is the focus of the majority of the development commits. The agile release model is the least accessible for this approach because of the number of active branches to try and monitor. That doesn’t mean continuous integration can’t be used but just that it is more difficult to implement and maintain.

Unstable Trunk questions:

Can this model handle parallel development if it only happens occasionally?

Any model can be morphed to handle exceptional situations, but this isn’t recommended. It is important to use a strategy consistently so that everyone understands where to find things during development and historically. That said, we’ve already talked about the potential of using multiple strategies on the same project so that’s certainly a possibility where the parallel development need could be addressed like with the stable trunk strategy.

Do I ever recommend merging from the trunk to the branch?

Never say never, but the situation would be pretty rare. I could potentially envision where a nearly complete bug fix or even an enhancement of importance is completed quickly enough on the trunk that there could be a compelling reason to merge it into the unreleased, but branched version.

How would you handle branches for customers that will have ongoing customizations for individual customers in this model?

Branches for this purpose can really be applied to any of the three basic branches we’ve discussed. The concept is that the base product continues to evolve and the branching strategy addresses that evolution. As production releases are made, the new revisions are merged to the customer-specific branches which contain customizations for that customer. There is also the potential of customer customizations being merged into the base product. The customer branches support the unique nature of customer specific changes while allowing for an upgrade path and the potential of contributing back to the base product.

Stable Trunk questions:

Version 1.0.1 didn’t get merged back into the trunk, shouldn’t it have been merged back?

Possibly, but I actually didn’t do so on purpose. With all the models, there is the potential that multiple releases are deployed in production and thus need to be supported. Therefore, there is the potential that bug fix releases are being made for multiple releases and merging all of them back to the trunk could mean intertwined versus serial releases. I therefore usually suggest that the actual production releases may be the only ones merged. Obviously, in my diagram that situation didn’t occur so it is a fair question.

There is a merge to the trunk outside of a release point, doesn’t that violate the stable trunk idea?

Yes, that can violate the stable trunk concept, but stability isn’t necessarily limited to just production releases. In this case, the purpose is to have a more up-to-date starting point for the system version branch. How strict you implement the idea of stability is up to you.

Should the development team develop the first version in the trunk or in a release branch?

Since my base principle is keeping it simple, I tend to say do the development on the trunk since there is no reason for creating a branch. The assumption is that parallel development won’t happen until the first release is made and other work won’t be merged until the release. This isn’t being pure to the strategy, but true to the base principle.

Agile Release questions:

In this strategy, is there any attempt to keep the task branches in sync with each other?

No, there really isn’t any way to define how you would keep isolated tasks in sync since there is no idea what will be released together until we get to the definition of the release branch. There is a need to keep the branches sync’d with production releases, but no way to do more.

Is there any reason that an Internet application should NOT be using the agile release method?

Sure, there are still many such applications that are released in a waterfall manner and are unquestionably successful. For example, release agility may not be required if releases are being made frequently enough. Keep in mind that there is more to keep in sync in this model which has to be balanced against any benefits.

Where is the release package built from?

I think the package would be built from the release branch since that’s logically where the promotion model process is conducted, but it can certainly be argued that the testing can be done on the release branch and then the approved revision merged to be tagged from the trunk. My absolute expectation is that you be consistent where you do build and tag.

How can a CM manager make sure all task branches were merged to the release branch?

Today, I would suggest the use of svnmerge.py where merge tracking is recorded in a property for all branch merges. Obviously, this will be easier with 1.5 where the log command can expose this information. Another approach would come from integrating issue management with Subversion where the merges would be reflected in the record for the release.

I’m sure I’ll return to answer some more questions around these branching models and merge tracking before long. Right now, I’m off to help another enterprise successfully implement Subversion.

Reference:

http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/

http://stackoverflow.com/questions/34975/branching-strategies

http://blogs.open.collab.net/svn/2007/11/branching-strat.html

http://www.javaworld.com/javaworld/jw-01-2008/jw-01-svnmerging.html

http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html

http://www.cmcrossroads.com/forums?func=view&catid=75&id=78871

The post SVN (Subversion) Branching Strategy appeared first on scmGalaxy.

There are several ways to enable user authentication for web based applications, like .htaccess files, plain tekst files, databases, LDAP, etc. They all have their pros and cons. In case a central, flexible solution is needed, either a database or LDAP solution can be used.

I chose for an LDAP solution since it can be reused by many web and application servers and the applications that run on them while many LDAP solutions provide excellent tooling and easy configuration. Since Yenlo strongly focuses on GlassFish and other Sun tools, I chose OpenDS to authenticate against.The idea is to create a bunch of users and put them into one or more groups. Each group gets access to one specific Subversion repository and every user that needs access to a certain subversion repositoy needs to be in the corresponding group.

This blog describes the basic steps I took to get Basic HTTP authentication for Subversion using Apache2 and OpenDS.
Setting up the server

The server is running on Debian Etch, for which most of the required software is available via the Debian package repository. The packages I installed are
apache2
apache2-mpm-prefork
libapache2-svn
subversion
sun-java6-bin
sun-java6-jdk
sun-java6-jre

Apart form these packages I downloaded and installed the OpenDS 2.2 zip file from the OpenDS homepage. For this purpose I created a user and a group called “opends” and the directory /usr/local/opends which I gave both ownership and group “opends”. Next I logged in as user opends and extracted the zip file into that directory. Finally, as root, I created a start and stop script and used the update-rc.d script to make sure OpenDS is automatically started and stopped when the server is started and stopped.

Setting up Subversion

Let’s suppose that our organisation has decided to create a Subversion repository for each development project that we do. This means that we would get a directory structure like this, with the leaves being the root directories of each repository:
/usr/share/subversion
/repository1
/repository2

The repositories were created as root using these commands in the /usr/share/subversion directory
# svnadmin create repository1
# svnadmin create repository2

That’s all the configuration that was done to the Subversion repositories.

Configuring OpenDS

First, a basic setup of OpenDS needed to be done using the command
$ /usr/local/opends/OpenDS-2.2.0/bin/setup

For more info about this, see Setting Up the Directory Server. Please note that if you are not running OpenDS as root user, it will listen on port 1389.

The next step was to configure OpenDS so it contains a few users and groups. The main configuration tool for OpenDS is called control-panel and, in my case, it can be started as user “opends” by issuing this command:
$ /usr/local/opends/OpenDS-2.2.0/bin/control-panel

With this tool, among other things, you can manage the entries in the directory. For my purpose I created the next layout
base dn (dc=yenlo,dc=nl)
organisation (o=yenlo)
organisational unit (ou=devel)
user (uid=wouter1, password = wouter1)
user (uid=wouter2, password = wouter2)
user (uid=wouter3, password = wouter3)
group (cn=group1, uniqueMember=wouter1,wouter2)
group (cn=group2, uniqueMember=wouter2,wouter3)

which is a very simple layout but sufficient for now. Note that I created two Subversion repositories and therefore two LDAP groups, one for each Subversion repository.

Setting up Apache2 to get access to the Subversion repositories

First I configured Apache2 so the two repositories were accessible to anyone using e.g. a web browser. After libapache2-svn is installed, the module should be enabled in the Apache2 configuration files automatically. To verify this, check the
/etc/apache2/mods-enabled/

directory and make sure these symbolic links exist
dav.load -> ../mods-available/dav.load
dav_svn.conf -> ../mods-available/dav_svn.conf
dav_svn.load -> ../mods-available/dav_svn.load

If the first link is missing, create it as root using
# a2enmod dav

If the second and third are missing, create it as root using
# a2enmod dav_svn

To make sure the modules are loaded by Apache2, restart the server as root using
# /etc/init.d/apache2 restart

Now some modifications need to be made to the dav_svn configuration file
/etc/apache2/mods-available/dav_svn.conf

The idea is that there are two Subversion repositories that need to be configured individually. So, these two entries need to be put in the above mentioned configuration file

DAV svn
SVNPath /usr/share/subversion/repository1
SVNListParentPath On
SVNAutoversioning On
SVNReposName “Repository1 Subversion Repository”


DAV svn
SVNPath /usr/share/subversion/repository2
SVNListParentPath On
SVNAutoversioning On
SVNReposName “Repository2 Subversion Repository”

Now, if you point your browser to either http:///svn/repository1 or http:///svn/repository2 you should see the root of your repository.

Adding LDAP support using OpenDS

In order to use LDAP atuentication with Apache2, these two entries should be present in /etc/apache2/mods-enabled:
authnz_ldap.load -> ../mods-available/authnz_ldap.load
ldap.load -> ../mods-available/ldap.load

If they aren’t present, you can enable them as root with these commands
# a2enmod authnz_ldap
# a2enmod ldap
# /etc/init.d/apache2 restart

Now, each entry in /etc/apache2/mods-available/dav_svn.conf should be extended with these lines in order to get LDAP authentication working with OpenDS. Please note that you should pay attention to the group you assign to each subversion repository location. I am only showing the configuration addition for repository1 and leave it as an excercise to you to setup the second repository configuration. Also please note you make sure the correct password for the Directory Manager is provided. For more info about these configuration settings, please consult the OpenDS WIKI page on Apache Web Server.
AuthType Basic
AuthName “Repository1 Subversion Repository”
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL ldap://localhost:1389/dc=yenlo,dc=nl?uid
AuthLDAPBindDN “cn=Directory Manager”
AuthLDAPBindPassword mypassword
AuthLDAPGroupAttribute uniqueMember
AuthLDAPGroupAttributeIsDN on
Require ldap-group cn=repository1,ou=devel,o=yenlo,dc=yenlo,dc=nl

Issue a final
# /etc/init.d/apache2 restart

and you should be prompted for a username and password when you try to access either repository. Using the correct uid and password combination should grant you access to the repository.

Next stepts

The authentication mechanism we chose, Basic autentication, posts usernames and passwords in plain text, which potentially could be harmful in case someone sniffes the connection. I would strongly recommend to setup SSL based connections. Moreover, this blog post only shows how to secure one repository layout using LDAP. Both Subversion and Apache are sufficiently flexible that other layouts are possible. Those layouts most likely require tweaking of the Apache2 configuration options. Finally, I am not an LDAP expert so the directory structure I chose in OpenDS most likely can be much improved. However, following the steps in this article should get you on your way to using OpenDS incombination with Apache2.

Reference: Referencehttp://www.yenlo.nl/woutervanreeven/2010/03/15/apache2-ldap-authorization-for-subversion-with-opends/
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: Re:Apache2 LDAP authorization for Subversion with Opends
Subversion authorization through LDAP with OpenDS

If you building a centralized development environment for a team or large group of users, the question of centralizing user identities, authentication and authorization is always popping up and the answer is often to use an LDAP directory server. The developer section of the OpenDS documentation wiki has a set of tutorials for using the OpenDS LDAP directory server with various web servers and open source project like GlassFish, Apache Tomcat, SugarCRM… But not yet for Subversion. Thankfully, Wooter van Reeven, Senior Consultant at Yenlo has just published a long and detailed tutorial for setting up Subversion authentication and authorization through LDAP, with OpenDS and Apache2.

blogs.sun.com/Ludo/entry/subversion_auth…on_through_ldap_with
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post Apache2 LDAP authorization for Subversion with OpenDS appeared first on scmGalaxy.

We have an existing Subversion repository that uses LDAP to manage users/passwords. There are some new users who we would like to provide read-only access to SVN. I did some Google searches and found a way to open up read-only access to anonymous users, but this is not what we want. We do not want to open up SVN to everyone. We still want to control login through LDAP, but we would like to prevent certain named users from being able to add/edit/delete.

I am assuming this can be done with a hook (pre-commit?), but I have no experience writing hooks. Can someone show me or point me to an example of how to do this?
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: Re:Hook to make Subversion Read Only for specific use
I use an LDAP setup with config similar to:

in /etc/apache2/sites-enabled/mysite

DAV svn
SVNParentPath /var/svn
SVNListParentPath on
AuthBasicProvider ldap
AuthType Basic
AuthzLDAPAuthoritative Off
AuthzSVNAccessFile “/var/svn/conf/svnaccess.conf”
AuthName “My SVN”
AuthLDAPBindDN “…..”
AuthLDAPBindPassword “…..”
AuthLDAPURL “…..”
Require valid-user

/var/svn/conf/svnaccess.conf
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: Re:Hook to make Subversion Read Only for specific use
I use an LDAP setup with config similar to:

in /etc/apache2/sites-enabled/mysite

DAV svn
SVNParentPath /var/svn
SVNListParentPath on
AuthBasicProvider ldap
AuthType Basic
AuthzLDAPAuthoritative Off
AuthzSVNAccessFile “/var/svn/conf/svnaccess.conf”
AuthName “My SVN”
AuthLDAPBindDN “…..”
AuthLDAPBindPassword “…..”
AuthLDAPURL “…..”
Require valid-user

/var/svn/conf/svnaccess.conf

[groups]
readonly = user1, user2

[/]
*=rw
@readonly=r
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post Hook to make Subversion Read Only for specific use appeared first on scmGalaxy.

rajeshkumar replied the topic: Re:Branch Managment in Subversion
Hi,

Can you redefine the questions. I may be able to help you out on this?

Regards,
Rajesh
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

mnanjala replied the topic: Re:Branch Managment in Subversion
Sure, what is the best way of branching in Subversion,

-Pravin

rajeshkumar replied the topic: Re:Branch Managment in Subversion
Hi praveen,
you can find SVN (Subversion) Branching Strategy information in url below…

community.scmgalaxy.com/pg/blog/rajeshku…n-branching-strategy
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

mnanjala replied the topic: Re:Branch Managment in Subversion
Thats Awsome and thanks Rajesh

-Pravin

Button replied the topic: Re:Branch Managment in Subversion
The problem with any branching approach, is how do you track what exactly has been merged into trunk, and what activity branches are contained in which tag etc. Check out agilescm, product from clearvision-cm, its pretty amazing and makes all of these tasks seemless, and its free for 10 or below users, see the link below

www.clearvision-cm.com/agilescm/overview

rajeshkumar replied the topic: Re:Branch Managment in Subversion
right now i am on Git. Will try soon
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post Branch Managment in Subversion appeared first on scmGalaxy.

Thanks

rajeshkumar replied the topic: Migrating to BitBucket from Subversion
This is the best tutorial i have come across for SVN to BitBucket migration….
www.atlassian.com/git/tutorials/migrating-overview/
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post Migrating to BitBucket from Subversion appeared first on scmGalaxy.

Key Features

The post Top 5 Open Source Code Management tools appeared first on scmGalaxy.

Our Subversion training courses are designed to provide the necessary hands-on experience to enable attendees to become productive immediately. We offer public classes at our training centers, private classes that can be held on-site at the customer’s location, as well as web based training.

Subversion user and administration training agenda as below;
Fundamental Concepts

• • The Repository
  • The Problem of File Sharing
  • The Lock-Modify-Unlock Solution
  • The Copy-Modify-Merge Solution

Subversion in Action

• • Subversion Repository URLs
  • Working Copies
  • Revisions
  • How Working Copies Track the Repository
  • Mixed Revision Working Copies

Basic Usage

• • Help!
  • svn import
  • Recommended Repository Layout
  • Disabling Password Caching
  • Authenticating As a Different User

Basic Work Cycle

• • Update Your Working Copy
  • Make Changes to Your Working Copy
  • Examine Your Changes
  • Undoing Working Changes
  • Resolve Conflicts (Merging Others’ Changes)
  • Commit Your Changes

Examining History

• • Generating a List of Historical Changes
  • Examining the Details of Historical Changes
  • Browsing the Repository
  • Fetching Older Repository Snapshots
  • Disposing of a Working Copy
  • Recovering from an Interruption

Advanced Topics

• • Revision Specifies
  • Properties
  • File Portability
  • Locking
  • Changelists
  • Network Model

Branching and Merging

• • Using Branches
  • Basic Merging
  • Advanced Merging
  • Tags
  • Branch Maintenance
  • Common Branching Patterns
  • Vendor Branches

Repository Administration

• • Strategies for Repository Deployment
  • Creating and Configuring Your Repository
  • Repository Maintenance
  • Server Configuration
  • Customizing Your Subversion Experience

About us:
scmGalaxy online platform is a community initiatives based on Software configuration management and DevOps that helps members and organizations to optimize their software development process, advocating agile methodologies and improve productivity across all aspects of Application lifecycle management. We provide consulting, training and mentoring services in agile development practices such as Source Code Management, Continuous Integration, Build management, Test-Driven development, Acceptance-Test driven development, Build automation, code quality practices and automated testing and continuous delivery.

We provide job oriented training in the area of Software Configuration management, Build and Release Engineering and DevOps domain . Candidates with engineering or software background and looking to either start or change their career to Build and Release Engineering, would benefit most from this training. This course offered online around the globe which include India, USA, Europe, Australia, Bangalore, Delhi, Pune, Mumbai, Chennai and Hydrabad. Instructor is an expert in Software configuration management, Build and release engineering and DevOps with more than 10 years industry experience in India.

• Contact us at info@scmGalaxy.com
• Call – +91 700 483 5930
• Skype – scmGalaxy

Course Objectives
To bring your team up to speed with agile development, We can also run the from Continuous Integration to Continuous Delivery with automated course within your premises.
Course Schedule
This course is an intensive 1-day & 2-day workshop with a mixture of teaching and lab exercises. Currently, this course is offered exclusively as an on-line course. Please contact us for more details.
Audience
This is a hands-on, practical course designed to teach specialized skills for real-world development situations. It is thus primarily aimed at a SCM Engineer, Build/Release Engineer, DevOps engineer and developer and QA audience.
Approach
The course is modular and flexible – depending on specific student needs and requests. Through our trainings, you benefit from the wide experience and architectural expertise of our team. We bring that experience to you in an highly interactive, intensely hands-on setting.
Assumptions
We assume participants have a reasonable understanding of Development in any language as well as a basic understanding of the Software Development Life Cycle.
Lab Work
All our courses are above all practical in nature. We believe that the best way to learn is by doing. So the course contains approximately 80% lab work.
Learning Resources
Each registrant will receive a copy of the student notes and lab solutions, a certificate of completion, and a CD containing all the tools covered in the course and CD containing all the tools covered in the course.
Contact Us
This course is provided on-site, and can be tailored to your particular requirements. If you would like our trainings delivered at your premises, or for any additional information please contact us. Please email us at info@scmGalaxy.com

The post Subversion user and administration training | SVN Course | SVN Training | India appeared first on scmGalaxy.

• What is SVN?

• What is “branch” , “Tag” and “Trunk” in SVN ?

• what do you mean by “Synchronizing with Repository” ? How is it different from “Update” ?

• Difference between Update and Commit ?

• How to apply a patch in SVN ?

• What if SVN Update gives Merge Conflicts and you just want your local files to be overriden with the repository versions ?

• trunk vs branch vs tag in subversion or SVN

• What is the process to take backuop and restore in SVN?

• How to setup SVN?

• How to setup authentication in SVN?

The post Top 10 Interview Questions and Answers in SVN (Subversion) appeared first on scmGalaxy.

Apache Subversion 1.7 has Arrived

Subversion 1.7.0 has been officially released today.  With the release of Subversion 1.7 comes the release of Subversion Edge 2.1.0.  This release of Subversion Edge brings you the server binaries for Subversion 1.7.0 as well as the latest release of Apache httpd.  In addition to the inclusion of the Subversion 1.7 server binaries this release of Subversion Edge brings a number of other nice improvements including the addition of a complete 64-bit Windows binary stack.  As with all previous Subversion Edge releases you can simply update your existing installation from the Subversion Edge web console.  There are no other special considerations, the update mechanism handles all details.

I encourage all users to update their Subversion Edge servers to this release so that you and your users can enjoy the new features brought from this release as well as the improved performance and fixes that comes with Subversion 1.7.  Look for updates to your favorite Subversion clients to follow shortly.

Source: http://blogs.collab.net/subversion/2011/10/subversion-1-7-0-released/

The post Apache Subversion 1.7 has Arrived | What’s new in Subversion 1.7 ? appeared first on scmGalaxy.

Examining History in Subversion

Your Subversion repository is like a time machine. It keeps a record of every change ever committed and allows you to explore this history by examining previous versions of files and directories as well as the metadata that accompanies them.

Several commands can provide you with historical data from the repository:

The post How to Examin History in Subversion (SVN)? appeared first on scmGalaxy.

Basic Work Cycle in Subversion (SVN)

Subversion has numerous features, options, bells, and whistles, but on a day-to-day basis, odds are that you will use only a few of them. In this artile, we’ll run through the most common things that you might find yourself doing with Subversion in the course of a day’s work.

The typical work cycle looks like this:

The post Basic Work Cycle in Subversion (SVN) – Overview appeared first on scmGalaxy.

Subversion, once installed, has a number of different pieces. The following is a quick overview of what you get. Don’t be alarmed if the brief descriptions leave you scratching your head—plenty more pages in this book are devoted to alleviating that confusion.

The post Subversion’s Components – SVN Components Overview appeared first on scmGalaxy.

| SVN | Subversion | SVN pros and Cons| SVN Repository Planning | SVN Repository layout |

Subversion (SVN) Repository Layout

Single Project – One project per repository location

Pros

· Isolated revision numbers

· Isolated codebase

· Isolated security model

Cons

· Isolated codebase

· Multiple Urls to remember

· Multiple locations to maintain

Multi-Project Layout – Several projects in one repository

Pros

· Easy to merge code between projects

· Single url for all projects

· One repository to maintain

Cons

· Revision numbers span across all projects

· Harder to isolate users to appropriate repositories

The post | SVN | Subversion | SVN pros and Cons| SVN Repository Planning | SVN Repository layout appeared first on scmGalaxy.

When you think of the cloud, Agile application lifecycle management may not be the first thing that comes to mind. CollabNet is hoping to change that with a beta distribution that combines Subversion, Apache and ViewVC with a web-based management interface.

Dubbed CollabNet Subversion Edge, the graphical user interface (GUI) works to simplify installation, administration, use, and governance of the software stack. It does this with a built-in update mechanism that alerts users when new software components are ready to install. Users can then install those updates directly from the browser.

The idea is to make it faster and easier to deploy Subversion servers by reducing administration time. And the promised end result is cost savings, says CollabNet in Brisbane, Calif. The graphical user interface on the open-source software is central to the promise. The interface aims to eliminate admin errors, make management of employee and external partner development teams more secure, and provide operational analytics.

CollabNet CEO Bill Portelli says the new product fits in with the company’s mission to advance the way in which Agile teams develop software. He went on to say that the company listened to the market and worked closely with global talent on the open source project.

“What’s clear is that Subversion installation, administration, security, and governance have historically been command-line-driven, requiring special expertise and up-to-the-minute knowledge,” Portelli says, adding that CollabNet Subversion Edge is a response to that challenge.

A closer look at Subversion Edge
In an effort to make it easier to deploy Subversion servers, CollabNet Subversion Edge includes a certified bundle of all the software components of a fully functioning, Apache-based Subversion stack. This bundle effectively does away with the need to search the web for software versions that work together. Then there’s the administration console that installs, manages, and updates the entire stack.

Beyond the deployment, the web-based user interface also works to streamline common administrative tasks, like creating and managing Subversion repositories, starting and stopping the Subversion server, and monitoring server health. The software automatically rotates and archives the logs, and an integrated auto-update feature lets users know when compatible updates are available for any of the distribution components.

On the security and governance front, CollabNet Subversion Edge offers web-based, role-based access control to manage all of the software’s administration features. It also lets admins manage internal and external user access to the Subversion repositories to bolster governance.

Free downloads of the beta version are available immediately on the CollabNet site. General availability is expected later this summer.

BriefingsDirect contributor Jennifer LeClaire provided editorial assistance and research on this post. She can be reached at http://www.linkedin.com/in/jleclaire and http://www.jenniferleclaire.com.

The post CollabNet delivers Subversion Edge to ease deployment, administration appeared first on scmGalaxy.

To install svn in linux and make it fully working , I found it really tough and it has taken my lots of time. I am thankful to Sanjay, who helped me in this and without him it won’t be possible.While installing this you will miss a small thing and you got stuck.But this is not at all tough like open source it’s really very easy.

Why I have choosed this topic to write is that, those who are using it first time will need some time to get full of subversion.

Now the latest version of svn is 1.6.9.

To install svn first you need svn tar file. Which can be downloaded easily from here or you can run these commands (depending on your required version).

wget http://subversion.tigris.org/downloads/subversion-1.6.9.tar.gz

wget http://subversion.tigris.org/downloads/subversion_deps-1.6.9.tar.gz (It contains the library required by svn)

This you can download any where, Here I am creating a folder svn inside /usr/local directory.(/usr/local/softwares/svn/).(So it will be easy for me to specify paths and you to understand).

To start the installation process first untar this two file.

tar -xvzf subversion-1.6.9.tar.gz

tar -xvzf subversion_deps-1.6.9.tar.gz (After untar you won’t find any particular folder named subversion_deps-1.6.9. Don’t worry for that it is keeping all the libraries files inside subversion-1.6.9)

Now have to configure it, but before that we have to check whether our system is having all the dependies or not, like APR(Apache Portable Runtime) and APR utility.

If it’s not there then we can get it from here,

apr-1.2.12.tar.gz

apr-util-1.2.12.tar.gz

once downloaded you can start configuring it.

tar -xvzf apr-1.2.12.tar.gz

cd apr-1.2.12

./buildconf

./configure

make

The apr util directory requires apr directory, so we need to specify path for that.

tar -xvzf apr-util-1.2.12.tar.gz

cd apr-util-1.2.12

./buildconf –with-apr=/path to apr directory (/usr/local/sofwares/svn/apr-1.2.12)

./configure –with-apr=/path to apr directory (/usr/local/sofwares/svn/apr-1.2.12)

make

The other directories we have to check before installation are,

autoconf 2.50 or newer (autoconf –version)

libtool 1.4 or newer (this you can find inside subversion-1.6.9 folder)

Neon Library 0.25.x or 0.26.x (inside subversion-1.6.9 folder)

Berkely DataBase (If it’s not there you have to install it.)

Download the file, db-4.6.21.tar.gz .

Apache web server greater then 2.0.49 (httpd -version)

zlib (inside subversion-1.6.9 folder)

After checking all this, we can start installation process,

cd subversion-1.6.9

./autogen.sh

./configure –with-berkelay-db=/usr/local/softwares/svn/db-4.6.21 (path of berkelay data base)

make

make install

Once we have finished that we need to map svn with apache.

Before that we have to check whether mod_dav_svn and mod_authz_svn modules are present or not,if not then install it.

yum install mod_dav_svn

and add this in /etc/httpd/conf/httpd.conf file

LoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

Make sure you will add these lines after LoadModule dav_module modules/mod_dav.so.

Now create one repository with svnadmin command.Run this command inside your subversion folder.

svnadmin create repos

after that you can check with,

ls repos

conf dav db format hooks locks README.txt

This full path you have to specify in SVNPath.

Then at the end of the httpd.conf file you have to add

#for svn path

DAV svn

SVNPath /usr/local/softwares/svn/subversion-1.6.9/repos

now restart ur apache.

For security purpose to give authentication to the user we have to create authentication file with the command,

htpasswd -cm /etc/svn-auth-file user_name (test)

New password : test123

Re-Type passwd : test123

And to specify which access you want to give the user, create svn-access-file inside /etc.

Inside this file add code as,

[/]

* = rw

This will give authentication to every user specified in Require user inside location.

You can specify this inside httpd.conf file as,

DAV svn

SVNPath /usr/local/softwares/svn/subversion-1.6.9/repos

AuthzSVNAccessFile /etc/svn-access-file

AuthType Basic

AuthName “Subversion repository”

AuthUserFile /etc/svn-auth-file

Require user user_name

Now you are ready to import files in the repository, with the following command.

svn import -m “Initial import.” path(from where you want to import file) file:///usr/local/softwares/svn/subversion-1.6.9/repos/(repository path)

after running this command don’t worry it is not goin to display any thing inside repos folder. To check that you can run it in the browser.

http://localhost(you have to give your domain name)/svn/repos

Now you are ready to checkout the files with any svn client. For linux user smartsvn is best.

After doin this you can start ur smartsvn client and can follow these steps,

check out project from repository -> manage -> add -> enter svn url

enter ur url here http://localhost/svn/repos

enter ->ok

server name and repository path it will take automatically. click next, choose user radio button and give user name and password.

follow the steps to fetch the files.

To install smartsvn, first get the smartsvn tar file.

untar the file, with the command

tar -xvzf smartsvn-version.gz

for smartsvn first check the correct version of java is available or not, with

java -version command.If it is coming like this then you can proceed.

java version “1.5.0_14?

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)

Java HotSpot(TM) Server VM (build 1.5.0_14-b03, mixed mode)

Sometimes java will be installed but not the JRE. In that case simply re-install java.

Can install the latest version of java with rpm bin file.

jdk-1_5_0_14-linux-i586-rpm.bin

./jdk-1_5_0_14-linux-i586-rpm.bin

go through the license and say yes.

It will installed in /usr/java/

Now have to make chnages in .bash_profile file.

cd /root

vi .bash_profile

give JAVA_HOME path.

JAVA_HOME = /usr/java/jdk1.5.0_14

Then compile it with the command,

source .bash_profile

then again check with java version.

Now you are ready to utilise the full feature of subversion

The post How to install subversion on Linux? appeared first on scmGalaxy.

Work on remote Subversion repositories locally with Git

Version control is great stuff, and being able to combine different version control mechanisms is even better. Subversion is a very popular version control system and a lot of repositories (public or otherwise) use Subversion to manage files. Git is another popular one, but what happens if you are working on a project where Subversion is used but Git is your preferred version control system?

With the git-svn plugin, you can have the best of both worlds. You can convert a Subversion repository to Git, use Git tools, then push the changes back to Subversion.

To begin, you will need the git-svn plugin installed. Most likely, if your distribution of choice provides Git, it will also provide git-svn. On Fedora, install it using:

# yum install git-svn

Then use git-svn to check out your Subversion repository into Git format:

% mkdir -p ~/git/code

$ cd ~/git/code

% git svn init http://svn.host.com/svn/code

Initialized empty Git repository in /home/user/git/code/.git/

% git svn fetch

This may take a while on large repositories

r267 = 079b7c1cff49187d1aabc4b16f316102088fdc0d (refs/remotes/git-svn)

W: +empty_dir: trunk

r268 = 3f1944530a092c811c55720bd9322b8c150a535b (refs/remotes/git-svn)

…

r351 = e2af3c12e5ed174d23ffc5917f03a6136f8ebb6b (refs/remotes/git-svn)

Checked out HEAD:

http://svn.host.com/svn/code r351

At this point, the Subversion repository located at http://svn.host.com/svn/code has now been checked out in Git format. On individual files and directories, you can use the git log command as you would the svn log command in order to get history information on the item in question. With git, you will also see the Subversion commit that corresponds to the log entry, for instance:

commit 23f705cd87e1e9c6dd841ca88a14d808e0c4292a

Author: user@HOST.COM

Date:   Sat Mar 20 18:25:38 2010 +0000

correct logic on the buildrequires extractor, add stats on BuildRequires to showdbstats output

git-svn-id: http://svn.host.com/svn/code@350 7a5473d1-2304-0410-9229-96f37a904fa4

With the above, you can see that user@HOST.COM did the commit, see the log message, and the Subversion revision (r350).

To work with these files, make changes as normal. git diff works like svn diff does, to see the changes made. To commit changes, use git commit like you would use svn:

% git commit -m “some minor change” file

[master 2454be1] some minor change

1 files changed, 2 insertions(+), 0 deletions(-)

To update your local copy from Subversion, instead of using svn update use git svn rebase. This will merge in any changes found in the Subversion repository.

When committing files using git commit, you are committing your changes to the Git repository. None of these changes are pushed to the Subversion repository until you specifically tell Git to do so. This is done with the git svn dcommit command, which then takes each commit made to Git and pushes them to Subversion as individual commits, which will retain all of your history and log comments:

% git svn dcommit

Committing to http://svn.host.com/svn/code …

M      trunk/rqp

Committed r352

M      trunk/rqp

r352 = 0557314a580c4390ff646380baa3aa33d1f6a5cd (refs/remotes/git-svn)

No changes between current HEAD and refs/remotes/git-svn

Resetting to the latest refs/remotes/git-svn

Unstaged changes after reset:

M      trunk/rqp

M      trunk/rqp

Committed r353

M      trunk/rqp

r353 = 249e97283ad28126bf84ccaffb32873e12d15b7b (refs/remotes/git-svn)

No changes between current HEAD and refs/remotes/git-svn

Resetting to the latest refs/remotes/git-svn

Now, if you were to look at the changed file(s) in Subversion (via another Subversion working copy or something like ViewVC), you will see the individual commits. Above, there were two changes made to the trunk/rqp file, each committed locally to Git. The “dcommit” command pushed those changes as individual commits to the Subversion repository. In this way you can do all local development with Git and when you have something you want to commit to the Subversion repository, you can push all of the relevant changes at once, retaining each separate commit.

Using the git-svn plugin makes it extremely easy to use Git locally with a remote Subversion repository. If you are in a project or organization that, for whatever reason, does not want to convert to Git, you can continue to work with that Subversion repository, without the restriction of using Subversion yourself.

The post Work on remote Subversion repositories locally with Git appeared first on scmGalaxy.

SVNAnt
SVNAnt is an Ant task allowing you to interact with Subversion within the convenience of your Ant build script. No more writing custom scripts to get the revision of your repository to tag your release jars. Nor do you have to make command line calls to checkout your latest and greatest as part of your continuous integration process. With SVNAnt, you have the familiarity of the Ant syntax and the flexibility you need for interacting with Subversion.
Features
SVNAnt is a full-featured Subversion client capable of using the native Java bindings or command-line wrappering depending on which is available. Beyond how it works, SVNAnt allows you to do all svn subcommands but the following:

If the svn subcommand is not listed here, you can use it in your Ant build file. Before we continue start using SVNAnt, we have to install it and configure Ant to use it.
Installation
Now that we know what SVNAnt is and what its features are, lets install SVNAnt so that you can begin to use SVNAnt to access Subversion within your Ant build cycle.

Step 1. (Download, Compile and Extract)
This step will download, compile, and “install” the latest version of SVNAnt.
1.1 Using Subversion, checkout the SVNAnt project located here: http://subclipse.tigris.org/svn/subclipse/trunk/svnant
1.2 From the command line, while inside of the location where you checked out SVNAnt to, run “ant makeDistrib”
1.3 Extract the .zip file created in the build directory of your SVNAnt source to a location of your choosing

Step 2. (Modify your build.xml)
The next step is to tell Ant how to find your SVNAnt task by adding the following to your build.xml file:
<path id= “svnant.classpath” >
<fileset dir= “/PATH/TO/YOUR/EXTRACTED/SVNANT-ZIP” >
<include name= “*.jar” />
</fileset>
</path>

<typedef resource=”org/tigris/subversion/svnant/svnantlib.xml” classpathref=”svnant.classpath” />
That should be it. I know that it appears to be too good to be true so lets verify this.

Step 3. (Verify installation)
Building upon Step 2, lets create a new ant task that will use the wcVersion feature of SVNAnt to get some information about your repository from a local working copy:
<target name=”testSVNAnt”>
<svn>
<wcVersion path= “PATH/TO/YOUR/WORKINGCOPY” />
</svn>

<echo message= “Subversion repository url: ${repository.url}” />
</target>
(Note: In the event that you need to pass credentials to Subversion, look here.)
The output should be something similar to this:
$ ant testSVNAnt

Buildfile: build.xml

testSVNAnt:
[svn] <WcVersion> started …
[svn]  finished.
[echo] Subversion repository url: http://svn.apache.org/repos/asf/incubator/openejb/trunk

BUILD SUCCESSFUL
Total time: 43 seconds

Pat yourself on the back. You have successfully installed SVNAnt and you are ready to implement Subversion into your Ant build cycle. Instead of us going through each available feature for SVNAnt, please view the SVNAnt Documentation. Now lets talk about why you may want to use SVNAnt to allow for Subversion interaction inside of your Ant build cycle.

The post How to Integrate Subversion Into Your Ant Build ? – Step by step guide appeared first on scmGalaxy.