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.

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.

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.

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.

Syncro SVN Client makes easier the document and code sharing between content authors or developers. This multiplatform Subversion front-end allows you to browse repositories, check for changes, commit changes, update your working copy and examiner the revision history. The Syncro SVN Client was initially developed as an embedded application in the XML Editor and starting with version 8.1 of the editor it is available also as a separate product.

Features
• Why Subversion?
– The advantages of the SVN version control system that recommend it as a replacement for the CVS system.
• Flexible Layout of the User Interface
– The layout of the user interface can be arranged by dragging dockable and floating views in the window and outside the window of the application.
• SVN Repository
– Special view for managing SVN repositories accessed through different protocols: SVN, SVN+SSH, HTTP(S).
• SVN Resource History
– The History view contains the revision number, author name, commit message and date of each revision of a file or folder from the SVN repository.
• Local Working Copy of a SVN Repository
– Each author that shares the SVN repository with other authors works on local versions of the repository resources called a working copy of the repository. The changes applied to the local copy of the repository must be synchronized with the repository hosted on the SVN server.
• Author Information at Line Level
– For each line of a file stored on a SVN server the author (user name) and the revision number of the last change applied to that line is displayed.
• Check Differences Between Local Version and Repository Version
– Compare the local working copy version of a file with the SVN repository version.
• Visual Conflict Editing
– Visually edit the conflicts generated in the local version of a file by an update operation.
• Revision Graph
– The history of a SVN resource can be viewed as a graph in which a node represents one revision of the resource committed to the trunk or a branch of the SVN repository.
• Directory Change Set
– The Directory Change Set view presents a set with all the resources changed between two revision numbers of a SVN folder.
• Integration with Bug Tracking Tools
– The commit message can include a bug ID which links the committed revision with a bug tracking tool. Special SVN properties configure the format and location of the bug ID in the commit message.

Home Page – http://www.syncrosvnclient.com/

The post Syncro SVN Client v5.1 for Windows, Linux & MacOSX – Features appeared first on scmGalaxy.

Syncro Soft Announces New Release of Syncro SVN Client

# # #

Syncro Soft provides consulting services that are focused on creating Java based XML solutions. Other aspect is the integration of the XML Editor within your content management system.

The post Syncro Soft Announces New Release of Syncro SVN Client appeared first on scmGalaxy.

As I have mentioned in a previous blog entry, I have come to love using ANT in my development environment. One of the things that I like about it is how well it integrates with my Subversion repository using SVNAnt. If you are not using either ANT or Subversion, you owe it to yourself and your team to check it out.

Here we’ll go over a simple build script that exports application files from the Subversion repository into a local folder in the CFEclipse project. You can then view the following entry on how to ftp that into your production/staging server.
First we need to make sure that your ANT install has the necessary SVNAnt jar files. You can download them here: http://subclipse.tigris.org/svnant.html. Once you unpack the svnant-1.0.0.zip file, you’ll find three jar files: svnant.jar, svnClientAdapter.jar, svnjavahl.jar. Place them on your
[ANTInstall]/lib* folder.

Once you have the jar files in place, you can define them in your build file’s property section like so:
<!– svnant lib –>
<property name=”svnant.lib” value=”lib” />
<property name=”svnant.jar” value=”${svnant.lib}/svnant.jar” />
<property name=”svnClientAdapter.jar” value=”${svnant.lib}/svnClientAdapter.jar” />
<property name=”svnjavahl.jar” value=”${svnant.lib}/svnjavahl.jar” />
Followed by this path definition after all your properties have been defined:

<!– path to the svnant libraries. Usually they will be located in ANT_HOME/lib –>
<path id=”project.classpath”>
<pathelement location=”${svnjavahl.jar}” />
<pathelement location=”${svnant.jar}” />
<pathelement location=”${svnClientAdapter.jar}” />
</path>

Now all you have left to do is add the following task definition:
<!– load the svn task –>
<taskdef resource=”svntask.properties” classpathref=”project.classpath”/>

Now you are all set! You can now call tasks like the following export target:

<!– define properties –>
<!– svn repo url –>
<property name=”svn.url” value=”http://[mysvnhost]/svn/repo/myprojectFiles/” />
<property name=”svn.exportPath” value=”[yourDirectory]:\\[pathToYourCFEclipseProject\\build” />

<target name=”svn.export”>
<echo message=”Exporting application files from svn repository:” />
<input message=”Please enter svn repo username:” addproperty=”svn.username” />
<input message=”Please enter svn repo password:” addproperty=”svn.password” />
<mkdir dir=”${svn.destPath}” />
<svn username=”${svn.username}” password=”${svn.password}”>
<export srcUrl=”${svn.url}” destPath=”${svn.exportPath}” revision=”HEAD” />
</svn>
<echo message=” … finished exporting files.” />
</target>

That’s it. No more running command line tasks to get your subversion commands. For additional info and other SVN tasks you can go to http://subclipse.tigris.org/svnant/svn.html

The post ANT Builds and Subversion (SVN) | Ant integration with Subversion guide appeared first on scmGalaxy.

This post is about using ANT to perform some of the most common source-control related tasks such as export, tagging, and branching. I am using ANT version 1.7.0 and SVN Ant version 1.1-rc3, bound against Subversion 1.4.0.

The related software can be downloaded here:
1.    SVN Ant = http://subclipse.tigris.org/svnant.html
2.    ANT = http://ant.apache.org/
I shall start with build.properties, which lists a few key/value pairs used in our SVN Ant task build file, referred as svn-tasks.xml:

Content of build.properties:
####START of SVN Properties ####
svn.repository.url=http://xyz.com/repos/somereponame
svn.project.base.path=someprojectname
svn.username=user name to access repo
svn.password=password to access repo
#This shall be name of the tag,
#This property should always be updated before build starts
#This property shall be used to export
tag.name=SOME_TAG_NAME_12222008
#This shall be name of new branch,
#this property should be used only when new branch is to be created
new.branch.name=NEW_BRANCH_12222008
####END of SVN Properties ####
Content of svn-tasks.xml:
<property file=”build.properties”></property>

<!– SVN and SVN-ANT Tasks properties –>
<property name=”svn.repository.url” value=”${svn.repository.url}”/>
<property name=”svn.project.base.path” value=”${svn.project.base.path}” />
<property name=”svn.base.url” value=”${svn.repository.url}/${svn.project.base.path}”/>
<property name=”svnant.lib.dir” location=”svn-ant-lib”/>
<property name=”svnant.javahl” value=”false” />
<property name=”svnant.svnkit” value=”true” />
<!– SVN and SVN-ANT Tasks properties –>

<!– *************************************************************** –>
<!–   Set-Up of SVN-ANT classpath                                   –>
<!– *************************************************************** –>
<path id=”svnant.classpath”>
<fileset dir=”${svnant.lib.dir}”>
<include name=”**/*.jar” />
</fileset>
</path>

<!– *************************************************************** –>
<!–   Loading of SVN task                                           –>
<!– *************************************************************** –>
<typedef resource=”org/tigris/subversion/svnant/svnantlib.xml” classpathref=”svnant.classpath” />

<!– *************************************************************** –>
<!– tool-availability: Determine if SVN-ANT is available.           –>
<!– *************************************************************** –>
<target name=”tool-availability”>
<available resource=”org/tigris/subversion/svnant/svnantlib.xml”
classpathref=”svnant.classpath”
property=”available.svnant”
/>
<echo message=”SVN-ANT is available = ${available.svnant}”/>
</target>

<!– **************************************************************** –>
<!– does-svnant-exist: depends on tool-availablility and     –>
<!–                    displays error message                                   –>
<!– ***************************************************************** –>
<target name=”does-svnant-exist” depends=”tool-availability”>
<fail unless=”available.svnant”>
SVN-ANT is not available, cannot perform tagging or checkout/export svn ant task.
</fail>
</target>

<!– ****************************************************************** –>
<!– svntag: performs tagging using properties from                              –>
<!–         build.properties and uses SVNANT tasks                              –>
<!– ******************************************************************* –>
<target name=”svntag” description=”tags individual project using svnant task”>
<property name=”svn.tag.message” value=”Tagging Project ${project.name} with tag name ${tag.name} from trunk “/>
<property name=”src.url”  value=”${svn.base.url}/${project.name}/trunk/”/>
<property name=”dest.url” value=”${svn.base.url}/${project.name}/tags/${tag.name}”/>

<echo message=”${svn.tag.message}”/>
<echo message=”${src.url}”/>
<echo message=”${dest.url}”/>

<svn javahl=”${svnant.javahl}” svnkit=”${svnant.svnkit}” username=”${svn.username}” password=”${svn.password}”>
<copy srcUrl=”${src.url}” destUrl=”${dest.url}” message=”${svn.tag.message}”/>
</svn>
</target>

<!– ****************************************************************** –>
<!– svnexport: performs export using properties from                            –>
<!–            build.properties and uses SVNANT tasks                           –>
<!– ****************************************************************** –>
<target name=”svnexport” description=”exports individual project using svnant task”>
<property name=”svn.tag.message” value=”Exporting Project ${project.name} with tag name ${tag.name}”/>
<property name=”src.url”  value=”${svn.base.url}/${project.name}/tags/${tag.name}”/>
<property name=”destPath” value=”${dest.path}”/>
<echo message=”${svn.tag.message}”/>
<svn javahl=”${svnant.javahl}” svnkit=”${svnant.svnkit}” username=”${svn.username}” password=”${svn.password}”>
<export srcUrl=”${src.url}” destPath=”${destPath}/${project.name}”/>
</svn>
</target>

<!– ****************************************************************** –>
<!– svnbranch: creates a new branch using properties from                       –>
<!–            build.properties and uses SVNANT tasks                           –>
<!– ****************************************************************** –>
<target name=”svnbranch” description=”creates a new branch for individual project using svnant task”>

<property name=”svn.branch.message” value=”Creating new branch for
Project ${project.name} with new branch name ${new.branch.name} from
trunk”/>
<property name=”src.url”  value=”${svn.base.url}/${project.name}/trunk/”/>
<property name=”dest.url” value=”${svn.base.url}/${project.name}/branches/${new.branch.name}”/>

<echo message=”${svn.branch.message}”/>
<echo message=”${src.url}”/>
<echo message=”${dest.url}”/>

<svn javahl=”${svnant.javahl}” svnkit=”${svnant.svnkit}”
username=”${svn.username}” password=”${svn.password}”>
<copy srcUrl=”${src.url}” destUrl=”${dest.url}” message=”${svn.branch.message}”/>
</svn>
</target>

Link: http://java.dzone.com/articles/how-use-svn-tasks-with-ant

The post How to Use SVN Tasks with ANT ? appeared first on scmGalaxy.

Install CollabNet SVN Command Line Client in Red Hat

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

1. Platform and configuration

Product: CollabNet Subversion client

Platforms: Red Hat Enterprise Linux releases 4 and 5 (all versions, 32 bit)

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

CollabNet Subversion.

2. Import CollabNet GPG key

CollabNet Subversion RPMs are signed using our GPG key. As a one-time task,

import the CollabNet GPG key using the command:

    sudo rpm –import /path/to/RPM-GPG-KEY-csvn.asc

The CollabNet GPG key is available for download at:

http://www.collab.net/nonav/downloads/subversion/gpg-key/RPM-GPG-KEY-csvn.asc

3. First installation

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

has not already been installed, is:

    sudo rpm -ivh /path/to/client.rpm

4. Updating an existing installation

If you have a previous version of the CollabNet Subversion client RPM installed,

update to the new version by running this command:

    sudo rpm -Uvh /path/to/client.rpm

If you also have a previous version of the CollabNet Subversion server RPM

installed, add the –force option to the command:

    sudo rpm -Uvh –force /path/to/client.rpm

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

Setup SVN proxy setup

After Successful installation of SVN

Step 1: Go to /root  ex. $ cd /root

Step 2: List the all the hidden files.

Ex. $ ls –a

You will be getting .subversion folder underneath.

Step 3: go to ./subversion

Ex: $ cd .subversion

Step 4: List all the files under .subversion folder

$ ls

Step 5: Open severs file with vi editor

$ vi services

Step 6: Scroll down to [global] section and make the changes by uncommenting follwing lines and putting proxy information.

http-proxy-exceptions =

http-proxy-host =

http-proxy-port =

http-proxy-username =

http-proxy-password =

Step 7: Save and exit the vi editor

The post SVN Installation | Subversion Installation guide | Subversion Setup appeared first on scmGalaxy.