Lets start with creating a directory where we want to install

you can manually download the installable from one of the available mirrors or you can use wget for same I prefer using wget

than we need to unzip the contents of the zip file and we are almost done

You can set the eclipse executable to your path

This is not the best way to do it but still does the job alternatively you can create a simple shell file and keep it in bin directory whcih just calls eclipse and you are good to go.

So now what do I do with my personal Jira installation :

Tracking my own progress on things: My jira Installation has project name learning which I have components as shown below so the differnet sources of my learning has become components of my jira project learning and not forget the title of my Jira installation is Personal life Jira

Personal Jira Components

Similarly versions are quarters of year and I create few Jira issues for each components each quarter like say I have a traget of reading two books each quarter, write ten blog posts each quarter; Jira helps in setting my personal goals.

We all agree that putting down things on paper or in genral documenting it somehwere helps alot especially putting down what we want to do and what we are suppose to do. People might say Jira might be to big application for managing personal taks but in my humble opinion its not about tool its more about the intent.

Developing some plugins and customization for Jira: Being a developer at heart I was not able to refrain my self from trying my hands on Jira’s plugin development environment with so much help available its pretty easy to get started though maven may suck you at start but once set it works as bread and butter.

So Jira as whole as impacted my learning process; I would like to thank Atlassian for providing such a nice tool and great licensing options.

Disclaimer: I am not associated with Atlassian by any means.

Comic on Microsoft and OpenSource

Step1: Changes in Apache httpd.conf

Add SVNAutoversioning directive in your Apache’s configuration file as shown below, which can be found in conf directory Apache installation.

When SVNAutoversioning is active, write requests from WebDAV clients result in automatic commits. A generic log message is auto-generated and attached to each revision. Before activating this feature, however, understand what you’re getting into. WebDAV clients tend to do many write requests, resulting in a huge number of automatically committed revisions. For example, when saving data, many clients will do a

of a 0-byte file (as a way of reserving a name) followed by another

with the real file data. The single file-write results in two separate commits. Also consider that many applications auto-save every few minutes, resulting in even more commits.

If you have a post-commit hook program that sends email or generates RSS feeds, you may want to disable email and feed generation either altogether, or on certain sections of the repository.

<Location /repos>

DAV svn

SVNPath /path/to/repository

SVNAutoversioning on

ModMimeUsePathInfo on

</Location>

ModMimeUsePathInfo allows

which is Apache’s module to attempt automatic deduction of the mime-type on new files that enter the repository via autoversioning. The module looks at the file’s named extension and possibly the contents as well; if the file matches some common patterns, then the the file’s

property will be set automatically. For this you will have to uncomment or add the load module directive for mod_mime.

LoadModule mime_module modules/mod_mime.so

Make sure that this line is present in load module section of httpd.conf and uncommented.

Now your Apache is set to accept DeltaV or WebDAV Clients.

Step2: Creating Network Share

Create network share i.e. a web share on some client machine or you can do it on same machine.

Go to My Network places -> add network place

You will see add a network place wizard click on next, than you will ask where you want to create this network place click next.

You will see a window as shown below asking you to enter Internet or network address

Enter http path to your repository, please don’t forget to add port number to it. e.g. http://myserver/repos and click next than you will be asked for authentication enter your credentials for repository access and than it will ask you the name of your network share enter any name you want.

Your repository is mounted as network or Web Share.

Now you can edit your files and cross check your repositories log messages to see auto commits and auto generated log messages. Which say’s commit by a non DeltaV client.

But before really using it you should make sure that you should know what you are doing. As far as I see this can be of great help to people who are non-developer and want to manage documentations with customers and among there team with actually needing a Subversion client lie Tortoise, many people think it’s a killer feature and I am no exception to it but the bottom line is that it comes at cost and you should know what the cost is and you are willing to pay it.

CVS was pretty good for me. I was not too happy but didn’t have many options either. Then one day, my friend told me about Subversion, the new age version control system. I decided to give it a shot and today I proudly admit that was one of the best decisions I ever took.

Why you should avoid using CVS

Commits are not atomic: that means if your commits fail in between the commit process then you end up in an inconsistent state and after that CVS gives you a lot of pain if you try to commit something.

Un-versioned Directories: As CVS deals at file level there is no versioning at the directory level

Pretty slow branching and tagging

No History of copy, move and rename: No history is maintained while renaming files i.e. if you rename a file all history associated with it is lost and we say it’s a version control! Same is true with moving and copying.

There are a lot many things that I can write, but my aim is not to criticize CVS, but to tell you why you should use Subversion.

Atomic commits: Commits are truly atomic which means either your commits succeed completely or fail completely; you will never be in inconsistent state.

File and Directory rename without losing history: You can happily rename your files without losing history at all.

Copy and Move: Restructure your directory anytime you feel with losing your revision history.

Branching and tagging is cheap operation: Branch as you like and as much you like; it’s fast and simple.

Sends diffs both ways: No bandwidth issues at all, whether you use it through intranet or the internet; as it sends diffs both ways.

Secure network access through https using ssl: It’s pretty important for teams working at different geographical locations to have secure access.

Support for binary files: Subversion treats binary files same as text files. Whether a file is binary or not does not affect the amount of repository space used to store changes to that file, nor does it affect the amount of traffic between client and server. For storage and transmission purposes, Subversion uses a diffing method that works equally well on binary and text files.

Easy backups: You can take backups pretty easily using svnadmin ‘dump’ and ‘hotcopy’.

Migration support for CVS and VSS: Migration scripts are readily available for CVS as well as VSS but people using CVSNT might not have enough luck to migrate successfully using the cvs2svn script.

Folder level access controls: There’s better, more granular security as well; you can set folder level permissions.

There are a lot of points I have missed, as my article is drop in the ocean of the limitless possibilities with Subversion. I’d be happy to hear your feedback on such points and on the article in general.

]]> http://www.singhvishwajeet.com/2008/07/20/4/feed/ 1 http://www.singhvishwajeet.com/2008/07/17/git-vs-subversion/ http://www.singhvishwajeet.com/2008/07/17/git-vs-subversion/#comments Thu, 17 Jul 2008 16:48:54 +0000 Vishwajeet Singh http://www.singhvishwajeet.com/?p=3 There has been a lot of fuss about which is the better version control system among the likes of CVS, Subversion, Git, SVK, Perforce, Accurev, the list goes on and on. But I am going to limit myself to Git and Subversion which are frequently being compared in the arena of SCM. These two version control systems fall in two different categories

• Distributed version control systems like Git and Code Co-Op
• Centralized version control systems like CVS and SVN

Distributed Version Control system

• In a distributed version control system every developer has his own private copy of the complete source code on his or her machine.
• They can put changes in their modules and can sync their changes with other developers.
• If by any means, access to the developer’s machine with whom you generally sync is not available, you have options to sync it with others. Also there is no bottleneck as you can sync with anyone in your project.
• This system is generally structured as a pyramid, as developers at a particular level can deliver changes with other developers on their level or the level above them and at the top of the pyramid is the person who holds the decision of what actually goes in the main line of development.
• Developers can work on the source code their own way without affecting anyone else. These developers can work with their fellow developers and sync changes with each other.
• Each can decide what changes to accept or reject from their fellow developers.
• The advantage is that the code is distributed and there is no “point of failure”.
• Distributed systems enable a lot of private work in a way that is bad for the development.
• Maintenance tends to be sloppier on distributed systems.
• Git falls in this category; this type of development is not used very commonly. Perhaps the biggest example of this is Linux kernel development.

Centralized Version Control system

• In a centralized system there is a repository on the central server where all the source code goes.
• Every developer checks out the working copy of the same piece of code and then makes changes in their working copy and everyone can commit changes to the main line of development.
• Anybody can put changes in anyone’s module if no folder level control is exercised.
• In such a system every one gets the changes of other developers whether they are willing to do so or not. A centralized system is much more likely to be backed up and its hardware kept up to date.
• Subversion falls in this category. This type of development is very common. Sourceforge.net follows this type of version control.

The distributed systems do work by not needing a server (except for rsync and any web server). But truly speaking the server-less system they set up is more complicated in actual practice than a single well-maintained server.

The official claim is that a centralized server cannot handle distributed type of development. I disagree that centralized servers cannot handle this development methodology. Let’s imagine a centralized version control system that has excellent branch development capabilities. No developer directly works off the trunk. Instead, each developer has one branch that is created from the trunk. Developers can merge their branches into the trunk or in other branches as done in distributed systems. For this to work, branching and merging operations must be smooth. And even the pyramid structure of distributed system can be implemented by controlling which all branches are to be merged in the trunk.

Subversion can be better but this has nothing to do with centralization. With the benefits of a centralized system, Subversion also gives you the flexibility to be used as a distributed system if you use right approach to it.

This is my personal opinion based upon my experiences working in the software engineering field. Feel free to comment on it and point out errors in judgment, if any.

Merge Tracking: We all needed it desperately and it’s going to be out in some time. Presently Subversion offers branching and merging but does not record them in history. Subversion 1.5 will give auto merging facility and manual merging facility and will maintain its history which change sets were merged and when they were merged, so now it‘s not required to remember the merges performed. SVN command blame and log will also give the details of merges in history. The presently available client on collabnet is for Eclipse and it offers two types of merges: Standard merge based on URL and revision inputs and advanced merge (exposes all command line options). You will not get the installer for it; you can automatically install it through the update/install option available in eclipse menu.

Sparse Directory checkouts: This is also one of the much needed additions. Presently in Subversion when you check out a directory you get all the directories below it in your working copy whether you need it or not. You have the option of only checking out top level folder, which is not enough. This becomes a messy business in large projects. Now with Subversion 1.5 you can check out selected subdirectories by specifying depth. Something like giving _depth = files.

Backing up FSFS repositories Subversion 1.5 way: This is a nice little feature added that will help make administration of FSFS repositories a little bit easier, especially when it comes to backup. The new feature is that `svnadmin recover` has now something to do for FSFS repositories. Most of you might not have come across it. It is one of those little features that were invented for the Berkeley DB repositories.

Tree Structured FSFS repository: This might not be of much interest to many but its there for you. Presently we have revisions stored in a single directory as db\revs\0 for revision zero and so on and so forth for revprops. This can lead to a single directory with large number of files. People relate some speed issues with it which I cannot understand. If you get it, do let me know. In Subversion 1.5, the structure has changed slightly. Newly-created FSFS repositories will instead use a two-level tree with up to (by default) 1000 files per directory. This means that revisions 0-999 will be stored in a directory db/revs/0/, revisions 1000-1999 will be stored in db/revs/1/, and so on.

Copy/Move improvements: Presently available move and copy is not true move; it is a two step procedure – first the deletion of old files and then the addition of new ones. In Subversion 1.5 we can expect a true copy and move or even rename.

There are few more features, but I am not going to discuss them here. The above mentioned ones are what I thought might interest people.

]]> http://www.singhvishwajeet.com/2008/06/10/what-subversion-15-has-in-store-for-you/feed/ 4