Saturday, December 24, 2011

Use of Subversion client with sourceforge

             Subversion (SVN) is Centralized, open-source Version Control System. SVN  manages files and directories and changes made to them over a period of time, while supporting to shared development with features like rollback code conflict resolve. As well this allows to recover older versions of the software (data) or examine the history of how the code-base changed. SVN is developed in order to overcome the bugs and misfeatures of CVS.

                 In SVN there are two ends to deal with. One is the Subversion Repository which contains all the managed files and directories, and the other one is commandline or GUI client application to manage files from the client's end. It is important to know the concept of SVN repository before starting work with SVN.

           Repository is a file server which is not behave like an usual one. It has it's own revisioning system. After any authorized person change a file in repository, the state of the code-base will change and it is given a index to identify that state which is new code-base. This index is called revision number. At the initial state of the repository revision number is '0'. For any change in repository the revision number will increase by one (Figure 1). So that people can refer the older versions of the code-base.

Figure 1

Usually repository contain three main directories containing the code-base.
  • trunk   - code-base of main development process
  • branch - copy of specific revision, to implement new features(which takes some time to finish) concurrently and independently on top of that (Figure 2)
  • tag      - some snapshots of the trunk. Can store stable versions of the code-base

Figure 2

Even in branching process, the revision numbers are depend on changes of the branches (Figure 3). How ever at the end of the branching process of a particular branch, containing code should be merge with the main code-base (in trunk).

Figure 3

     Now I think you have an idea on how the repository behave. To access SVN repository there are several methods. Following table shows the URL schemes map to each access method.


SchemeAccess Method
file:///Direct repository access (on local disk)
http://Access via WebDAV protocol to Subversionaware Apache server
https://Same as http://, but with SSL encryption
svn://Access via custom protocol to an svnserve server
svn+ssh://Same as svn://, but through an SSH tunnel

              As I mentioned earlier, the second end of SVN is the application, in client's end. I'll explain how we can generally use SVN client applications with Linux & windows environment.


Setup a repository

                  We can get use of sourceforge in order to setup a repository. sourceforge is free repository provider for open-source projects. What you have to do is register for the sourceforge and create a project. Make sure to select the version control system as SVN (default is git) while you are creating the project. sourceforge itself can add folders and files. But since we are in another track forget it for a moment. Under the code tab of your project home page, you can see the command you should use to get a checkout for linux based system. (make sure you have login)


With UBUNTU-10.04 OS

         SVN commandline client can be used with Linux based systems. After installing the SVN commandline client, files can managed via executing the commands in command prompt.

install SVNcommandline client on your machine
$ sudo apt-get install subversion libapache2-svn
first go inside that directory and add source files to the repository.
$ cd /home/source_folder
$ svn import --username=your_username -m "Meaningfull_message_about_the_source_changes_for_users" url_of_repository
note : the repository url you can obtain from the sourceforge (sourceforge -> your project -> code tab)

In sourceforge project your initial file upload will appear as revision number 2. This is due to sourceforge itself create the general folder structure of repository and it will appear as revision number 1.


To start developing with SVN, first create a new folder and then get a checkout from the repository (copy of the latest code-base in repository)
$ sudo mkdir /var/www/myproject
$ cd /var/www
$ svn co --username your_username url_of_repository myproject
Now you can start further implementation on that checkout. If you modify an existing file it will already prepared to commit (upload) to the repository. But if you add a new file or a directory first you have to make prepare it to commit.
$ svn add new_file_1 new_file_2
$ svn ci -m "Meaningful_Message" new_file_1 existing_file_1 existing_file_2
If you want to commit all the files you changed, you use above code without the file paths. A summery of some useful SVN commands are shown below.

information on usage of SVN
$ svn --help
initial commit
$ svn import --username=your_username -m "Message" URL
get a checkout
$ svn co --username your_username URL project_folder
make prepare to commit the newly added files (unversioned files)
$ svn add file_path
see the states of the files (whether versioned or unversioned)
$ svn st
note: The meaning of the symbols shown for statuses,
? - unversioned file
M - locally modified file
A - schedule to add the file
D - schedule to delete the file
G - merged file
C - conflicted file while updating (file is waiting for user resolve the conflict)
! - file is missing or incomplete (removed by non-svn command)
~ - versioned file obstructed by some file of a different kind
I - file ignored

get latest code to working copy without changing local modifications
$ svn up
note: If any file is about to conflict (overwrite) commandline client itself give some options to user to agree,
p - mark the conflict to be resolved later (postpone)
df - show all changes made to merged file (diff-full)
e - change merged file in an editor (edit)
r - accept merged version of file (resolved)
mf - accept my version of entire file and ignore their changes (mine-full)
tf - accept their version of entire file and lose my changes (theirs-full)
l - launch external tool to resolve conflict (launch)

h - show this list (help)

resolve conflicted file before commit (after postpone conflict we can manually resolve it)
$ svn resolved conflicted_file_path
commit all local changes
$ svn ci -m "Message"
note: to commit specific files, add file paths at the end of the above command separating each by a space

remove all the local changes of a working copy (become to base revision)
$ svn revert -R .
note: to revert specific file replace '-R .' with file path

information on base revision (revision of working copy on top)
$ svn info
modifications between working copy and base revision
$ svn diff
get file differences to a file
$ svn diff > ~/Desktop/path/filename.diff
apply patch (diff file) to working copy
$ svn patch -p0 ~/Desktop/path/filename.diff

With Widows 7 OS

             SVN GUI client can be used for windows based systems. TortoiseSVN is the GUI client of SVN. After Installing Tortoise SVN on a machine, files can be managed in UI level. To start the development, go to any directory, under which this project should be created, then right click and select 'SVN checkout' option. Then you can give the repository URL and the local project directory name. If you have already created a project in sourceforge, from the SVN command appeared under 'code' tab, you can fetch out the repository URL.


After any improvement in the code, the corresponding file and all it's parent directories are shown as modified by a red mark on the file or directory. Using the right click options, the modified code can be committed (SVN commit) even while neglecting some of the modified files by selecting them. As well you can see lot of SVN operations can be done from this interface (Figure 4).

Figure 4
 So if you are new to SVN, hope this will helpful to you.

Tuesday, December 20, 2011

Version Control Systems (Source/Revision Control Systems)

                                Version Control Systems are playing an important role in software source controlling. Most of the software industry used Version Control Systems to keep their source code in a central space so that any authorized person can access to it and do the changes in source files concurrently. The main purpose of a Version Control System is to enable collaborative editing and sharing of data, and keep the older states of the software code base (keep revisions).


                    In a project with large number of remote developers, there is a big probability to accidentally overwrite each other's changes in a regular file system (Figure 1). That's how the Version Control Systems come in to the picture in order to solve this problem.

Figure 1
                          So, to avoid above problem Version Control Systems used a strategy called Lock-Modify-Unlock model (Figure 2). This repository allows only one person to change specific file at a time. To do this it is using a lock system. The user who is going to change a file must lock the file so that any other user cannot lock the file again (it means file can be read but cannot change). After he made the change and commit the file to the repository he must unlock the particular file.

Figure 2
                                   But in this model, the developing process will be unnecessarily serialized, and by mistakes some users may not unlock a file, though others are waiting for unlocking that files. As well concurrent developing of two files by different users cannot have idea of each other file which have some dependencies between them.


                  Therefore another method called Copy-Modify-Merge model (Figure 3) is used as alternative to this problem. In here, users can concurrently develop the same file and commit it by after merging the new changes in repository to the working copy (locally changed copy).

Figure 3                                                                    
                            Version Control Systems such as SVN and CVS are using the above method to file managing.Using this method user have the full control of managing codes in conflicts (overwrite some code).

                  It's possible to classify the Version Control Systems as Centralized and Distributed. Centralized Version Control Systems means there is only one repository which developers are directly deals with. But in Distributed Version Control Systems are some kind of modification of the concept of Centralized Version Control Systems. The concept is to having two levels of Source Control Systems rather than one. So that, without all ways connecting with the main  Source Control System(main repository in server), using an own Source Control System(local host) until completing any specific work (can be a story of project). So that the main repository contains only working copies of the software. As well the operations (commit, revert) are faster due to using the own Source Control System more than Centralized Control System.


Some examples for Version Control Systems are as follows.

1). CVS (Concurrent Versioning Systems)
          Older technology. Simple system for make sure files and revisions kept up to date.

2). SVN (Subversion)
          Popular Version Control System. Most of the open-source projects use SVN.

3). git
          A fast populating, open-source Distributed Version Control System.

4). Mercurial
          Open-source Distributed Version Control System. Very faster and much simpler system than 'git'.

5). Bazaar
          Distributed Version Control System with different types of workflow than other Distributed Version Control Systems.

6). LibreSource
          Web portal, with a built-in subversion repositories. Useful for manage collaborative projects.

7). Monotone
          Fairly easy to learn. Places higher value on integrity than performance.


                               I think you may have some idea on Version Control Systems. And I'm willing to have another article soon on use of Subversion client.