As the saying goes Software never die until the last user die, every developer in a software project work towards improving the state of the software project. The team is engaged in adding new features, enhancing existing functionalities and fixing bugs. The Subversion project is not an exception. The Subversion development team is constantly working towards producing the good quality version control system, by defining standards for versioning methodologies.
In this article, we'll take a tour on various new features added in Subversion 1.5 release. It is not a complete list, but it gives an overview of important features the users have been waiting for so long. In this article, we cover few new features added in Subversion 1.5 release. It also provide a list of other features and improvements added in this release. However, we do not cover various bugs that are fixed in this release.
Merge Tracking
In pre 1.5 releases, merge is a utility outside of Subversion. The users are responsible to keep track of what to merge and record the merge information on the resulting revision. It is completely a manual process, the user should be intelligent to keep track of the merges. The following diagram illustrates the problem that exists in pre 1.5 releases.
In the above diagram, the user might face an error when he attempts to merge the revisions, revision 11 through revision 17, since revision 11 and revision 13 has been merged to the branch in the past.
This is one of use case addressed by the merge tracking feature in 1.5 release. It automatically handle the situations such a duplicate merges. It records the revisions that exists on a given path, and provides a traceability of what path made it to which revision. By automating the merging process, the information stored in repository is reliable. It is vital to certain industries with high demands on product safety.
It supports cherry picking changesets and it documents what changesets have been merged to where. It also records the merge done outside of the merge tool, probably using a manual process. The merge history is consistently recorded. The svn mergeinfo command answers various merge questions, what changes have been merged to any branch and what changes are eligible for merging from any source path.
Change Lists
At any given point in time, the developer may be working on multiple issues involving multiple source code files. The changelist feature gives the developer a flexibility to associate set of files with human readable changelist name. He can refer to these set of files using the changelist name.
For instance, the developer can create a changelist pointing to 10 source code files. Whenever he want to commit the changes in any of these files in the repository, he can use svn commit –changelist changelist_name command. This command will check if there are any changes in those 10 files and include the changed files for committing in the repository. The user can manage changelists using svn changelist subcommand.
Sparse Checkouts
In Subversion 1.5 release, a facility is added to effect the operation for files and directories to a certain level. The --depth option is added to most for Subversion commands. This option is similar to --non-recursive (-N) and --recursive (-R) and improves upon these options making these options obsolete.
For example, the command svn checkout repos_url wc_path --depth files will checkout immediate target of the operation and all of its immediate file children. Similarly, the command svn checkout repos_url wc_path --depth immediates will checkout immediate target of the operation and all immediate files and directories. The directory children will themselves be empty.
Interactive Conflict Resolution
The conflicts may occur during following operations: merge, update and switch. In 1.5 release, an interactive conflict handling interface is provided for the user to fix the conflict instantly. The user can configure the default behavior during conflict resolution process.
The following table illustrates the list of options among which the user an choose while resolving the conflict:
$ svn merge proto://hostname/svn/branches/B1 .
Conflict discovered in 'B1/greek/iota'.
Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : h
(p)ostpone - mark the conflict to be resolved later
(d)iff - show all changes made to merged file
(e)dit - change merged file in an editor
(r)esolved - accept merged version of file
(m)ine - accept my version of file
(t)heirs - accept repository's version of file
(l)aunch - use third-party tool to resolve conflict
(h)elp - show this list
Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options :
FSFS Sharding
Before Subversion 1.5 release, the FSFS repositories contain files that describe the changes made in a single revision, and files that contain revision properties associated with a single revision. These files are kept in two directories, one for each type. As new revisions are committed to the repository, Subversion adds more files in these directories -- over time, the number of files can grow to quite large.
In Subversion 1.5 release, the FSFS backed repositories are created by slightly modified layout. The content of these directories are sharded, or in other words, scattered across several subdirectories. This can greatly reduce the time it takes the system to locate any one of these files, and therefore increases the overall performance of Subversion when reading from the repository.
Other key features and improvements
In Subversion 1.5 release, few more features have been added. The functionality of existing features have been improved dramatically. The key features that are not covered in this article are as follows.
WebDAV transparent write-thru proxies
Cyrus SASL support for ra_svn and svnserve
The substantial improvements for existing features are as follows:
Copy/move improvements
Externals improvements
Cancellation improvements
Easier to try out ra_serf DAV access module
Lots of API improvements and miscellaneous bug fixes
Conclusion
So far, you have been using Subversion as a standard for Version control system. After Subversion 1.5 release, you would be surprised to see the comfortableness it provides for any developer while working on any software project. The Subversion version control system can be downloaded from following websites:
http://subversion.tigris.org
http://open.collab.net
About the Author
By: Bhuvaneswaran A. The author is currently employed in CollabNet working for their Operations Engineering group. He is an Official Member of Ubuntu Linux and a Partial Committer for Subversion project.
The article is published in Linux For You Magazine May 2008 Edition. The article in PDF format can be downloaded from here.
- Location:office
Contributing to Open source project
Nowadays, we find at least one open source project for any given software requirement. Always someone find time to do things open source way. Isn't that cool? Who do you think they are? They are one among us who identify that the commercial tool is not affordable, or, it is a handicap in someway or the other.
When it comes to inventing a new successful open source project or, contributing to an existing one, we should agree that the contributors from APAC region is deficient compared to rest of the world. The APAC region is one of highly consumable region for open source software, but when it comes to contributing back to the community, the statistics are not impressive.
In this article, we attempt to give an introduction to what it takes to contribute to any open source software. We take Ubuntu project and Subversion project as case studies. The Ubuntu project comprises many individual teams working on various software tools around Ubuntu Linux Distribution. The Subversion is a version control system. It is a compelling replacement for CVS in the open source community.
The procedure to contribute to any other open source project should be closely similar. The article provides an overview of various teams in Ubuntu project, role of each team and other aspects considered for contributing to this project. It also provides an overview of development process, patch submission guidelines and how to write log message for Subversion project.
Ubuntu Project
There are reasons why you should contribute to Ubuntu project. There are so many teams in which you can join and contribute. Each team has well defined road map and schedule. They also concentrate on embarrassing and guiding the new contributors by conducting the mentoring program.
Depending on your exposure to technologies, you can choose one of these area for contributing to this project:
- Programming and Packaging
- Documentation
- Translation and Localization
- Ubuntu Artwork
- Advocacy and Support
- QA and Bug report
Depending on your exposure and interest, you can join any of these teams. When we say join, we mean to join the mailing list and designated IRC channels. You can monitor the process for few days, before pitching in with your contribution.
Desktop Team -- The foremost task of this team is to maintain GNOME packages. They are responsible to keep up to date with latest release, discuss and fix issues. You can refer to team wiki page for more details: https://wiki.ubuntu.com/DesktopTeam
MOTU -- Masters of the Universe. They spend time by adding, maintaining and supporting as many software in the Universe repository. If you are good in packaging, this should be the place to begin. You can refer to team wiki page for more details: https://wiki.ubuntu.com/MOTU
Documentation -- The team is responsible to create and maintain documents belonging to various applications for each Ubuntu release. They work on writing, editing and updating the system documentation for Ubuntu. If you think you are a good documenter, this is the place for you. You can refer to team wiki page for more details: https://wiki.ubuntu.com/DocumentationTe
Installer Team -- The team is responsible to maintain the Ubuntu Installer. They are also responsible to keep the Ubuntu installer in sync with the Debian installer. You can refer to team wiki page for more details: https://wiki.ubuntu.com/InstallerTe
Kernel Team -- The team is responsible to provide a Stable kernel version with every Ubuntu release. They are also responsible to maintain high-quality, consistent package across different architectures. You can refer to team wiki page for more details: https://wiki.ubuntu.com/KernelTeam
These are few teams to name. There are so many other teams which you can explore depending on your interest. Each team has a dedicated mailing list. The developers and volunteers discuss in the mailing list. The patches, code reviews and discussion over various issues are performed in the mailing list.
Ubuntu Code of Conduct
When you contribute to this project, you should adhere to the Ubuntu Code of Conduct. It defines the ground rules that each member should follow during his association with this project.
Be considerate -- You will depend on the work done by others, and in turn your work will be used by other people. Any decision you take will affect users and team members, and they expect you to take those consequences into account when making decisions.
Be respectful -- You should treat the community and its members with due respect. You should make the community a productive place. You should make the community a place where people feel comfortable and inspired by other members. You are expected to be respectful while dealing with other contributors.
Be collaborative -- Free software is about collaboration and working together. You should collaborate with other contributors and reduce the redundancy of work done in the Free software world.
When you disagree, consult others -- Each one of us tend disagree at some point in time. When disagreements happen, we should turn to the community and the process to seek advice and resolve conflicts.
When you are unsure, ask for help -- Nobody knows everything and it is impossible to be perfect always. When you are not sure, ask questions and get it clarified before forming your own assumptions. The doubts should be asked in appropriate forum and we should avoid posting unrelated and off-topic questions.
Step down considerately -- No place is permanent for anyone. People come & go and Ubuntu project is not an exception. When you leave, you should tell people and take proper steps to ensure that your successor can pick up where you leave off.
Becoming a Official Ubuntu Member
The membership role is granted based on substantial contribution to this project. You should continue to contribute to this project for few months. If you are convinced that you are eligible to become a member, you can apply for membership. You should put up a wiki page showcasing the testimonials of the work you have done so far for this project. It could be for any of these teams. The members of Ubuntu Community Council team would verify the testimonials and depending on the recommendation from other members and team leaders, they may either grant the role or defer it. If the request is deferred, you can apply again after few months making more contribution for this project.
When you become the member, you get an email address@ubuntu.com. You get the right to carry Ubuntu business cards. The artwork is supplied by the team and you can print your own cards. The membership lasts for two years and it is renewable.
Subversion
Subversion is a version control system. It is a compelling replacement for CVS in the open source community. The Subversion community is one of highly respected community in the open source world. The Subversion is written in C language. The test suites and other tools around the system is written in Python. The bindings are available for various languages including Perl, Java and Ruby.
To participate in the community, you can join "dev", "svn" and "announce" mailing lists in http://subversion.tigris.org website. The development mailing list, dev@subversion.tigris.org is where all discussion among the developers take place. You can join the development mailing list and monitor how other developers interact with each other. Before you ask a question, please ensure you search the archive and ratify that it is appropriate to be asked in this mailing list.
You can get a copy of the latest development sources of the project from the repository: http://svn.collab.net/repos/svn/trunk/
There are many ways to participate in the community, either by writing code, reviewing code, testing and/or helping to manage the bug database. Another way to help is setup automated build and test suites.
Submitting Patches
The patches can be sent to the development mailing list. A pre-defined set of guidelines are followed while submitting the patch. For instance, the email should start with the subject line "[PATCH]". This helps the corresponding component owner or the patch manager to spot patches right away. If the patch addresses a particular issue, please specify the issue number in the email subject like "[PATCH] issue #1234: ...". The developers interested in that particular issue will read and comment on the patch.
When submitting a patch, you should include the log message. A good log message helps potential reviewers understand the changes in the patch and increases the likelihood that it will be committed.
Please refer to this web page for more details on how to submit patches for this project: http://subversion.tigris.org/hacking.ht
Writing Log Message
It is obvious that every commit needs a log message. The log message is very important and it gives an introduction to the change. The log message not only helps the developers, but also plays well with IRC bots like CIA that echoss first line of each commit to real time forums like IRC.
The log message should name every affected function, variable, macro, grammar rule, etc.
* subversion/libsvn_ra_pigeons/twirl.c
(twirling_baton_fast, twirling_baton_slow): Removed these
obsolete structures.
(handle_parser_warning): Pass data directly to callees, instead
of storing in twirling_baton_*.
* subversion/libsvn_ra_pigeons/twirl.h: Fix indentation.
These are few guidelines to name. You can refer to the Hacker's Guide to Subversion for complete set of guidelines to be followed while participating in this community.
Glad to hear ... so what?
Always, someone asks this question. Let it be easy to contribute to a open source project. but, why should I contribute? Alright, let me try to convince them in this section!
- We get a chance to work with international developers from whom we can gain diverse knowledge. We get to know their style of thinking and learn to groom new contributors.
- All open source projects are developed in an open environment. The quality of the code, document and communication is reviewed instantly from someone sitting in a different continent. These kind of activities is literally impossible in most of commercial softares developed in closed doors.
- The communication skill is tremendously improved. When we continue to communicate our thinking, our skill to articulate the idea is improved.
- No one forgets what we did. The search engine remembers what we do and we do not need an introduction and reference to prove who we are.
- Above all, we get complete satisfaction and pride about what we do. It is a pay back time to the open source community.
- No need to mention, our resume looks rich!
About the Author
By: Bhuvaneswaran A. The author is currently employed in CollabNet working for their Operations Engineering group. He is an Official Member of Ubuntu Linux and a Partial Committer for Subversion project.
- Location:home
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
bhuvanbk- bhuvan
- Bhuvan's eHome
Syndicate
