Installation of SVN Server:
SVN – Subversion is a versioning and revision control system used by developers to track and keep up earlier versions of their source codes. Apache Subversion, which is commonly referred to in its abbreviated form as SVN, (named after the command name SVN) is a popular software versioning and revision control system which is distributed as a free software under the Apache License. Mainly used by developers to maintain present and historic file versions like documentation, source code, and web pages, it primarily aims to be a compatible successor to the extensively used CVS (Concurrent Versions System).
Step 12 » Create basic repository structure with the below commands
[root@kvit ~]# mkdir -p /tmp/svn/{trunk,branches,tags}
Step 13 » Now you can see updated revision and structure details .
Access control lists: Usually, you don’t want to give every user access to every repository. You can restrict repository access per user by using ACLs. ACLs can be enabled with the AuthzSVNAccessFile file option, which takes a file name as its parameter. Add following to subversion.conf file.
Now create two more repository newrep1, newrep2 for kvit1 and kvit2 user.
[root@kvit ~]# svnadmin create /svn/newrep1
[root@kvit ~]# svnadmin create /svn/newrep2
In order to start learning how to configure SVN Server , lets begin with the installation of SVN server on CentOS 6.2
Install svn server on centos 6.2:
Install and configure Apache:
Step 1 » Type the below command to install apache along with dependencies.
[root@kvit ~]# yum install httpd
Step 1 » Type the below command to install apache along with dependencies.
[root@kvit ~]# yum install httpd
Step 2 » Open the file /etc/httpd/conf/httpd.conf .
And at the end of file add this line below. “ServerName your server ip address: 80”
#ServerName www.example.com:80
ServerName 192.168.0.151:80
And at the end of file add this line below. “ServerName your server ip address: 80”
#ServerName www.example.com:80
ServerName 192.168.0.151:80
Step 3 » Issue the below command to start apache service
[root@kvit ~]# Service httpd start
[root@kvit ~]# chkconfig httpd on
[root@kvit ~]# Service httpd start
[root@kvit ~]# chkconfig httpd on
Disable firewall (Iptables) »
[root@kvit ~] # Service iptables stop
[root@kvit ~] # chkconfig iptables off
Disable Selinux »
open file /etc/selinux/config and find the line
SELINUX=enforcing
And replace with
SELINUX=disabled
And reboot the server.
[root@kvit ~] # Service iptables stop
[root@kvit ~] # chkconfig iptables off
Disable Selinux »
open file /etc/selinux/config and find the line
SELINUX=enforcing
And replace with
SELINUX=disabled
And reboot the server.
Install and configure SVN Server:
Step 4 » Now start installing svn packages, Just type the below command
[root@kvit ~]# yum install subversion mod_dav_svn
[root@kvit ~]# yum install subversion mod_dav_svn
Step 5 » Now create new directory for svn repository.
[root@kvit ~]# mkdir /svn
[root@kvit ~]# mkdir /svn
Step 6 » Create a new repository in the svn by issuing the below command
[root@kvit ~]# svnadmin create /svn/newrep
[root@kvit ~]# svnadmin create /svn/newrep
Step 7 » Now issue the below commands one by one for necessary permissions.
[root@kvit ~]# chown -R apache.apache /svn/newrep/
[root@kvit ~]# chcon -h system_u:object_r:httpd_sys_content_t /svn/newrep/
[root@kvit ~]# chcon -R -h apache:object_r:httpd_sys_content_t /svn/newrep/
[root@kvit ~]# chown -R apache.apache /svn/newrep/
[root@kvit ~]# chcon -h system_u:object_r:httpd_sys_content_t /svn/newrep/
[root@kvit ~]# chcon -R -h apache:object_r:httpd_sys_content_t /svn/newrep/
Step 8 » Now create a password file newrep.users with different usernames by typing below command
[root@kvit ~]# htpasswd -cm /svn/newrep.users kvit
[root@kvit ~]# htpasswd -cm /svn/newrep.users kvit
Step 9 » Now open the SVN apache config file ( /etc/httpd/conf.d/subversion.conf ) and add the below lines at the end of the file .
[root@kvit ~]# vim /etc/httpd/conf.d/subversion.conf
[root@kvit ~]# vim /etc/httpd/conf.d/subversion.conf
Step 10 » Restart apache service
[root@kvit ~]# service httpd restart
[root@kvit ~]# service httpd restart
Step 11 » Now open your svn path http://yourserverip/repos/newrep in a browser( Ex:http://192.168.0.151/repos/newrep ) . you can see newrep revision page after typing username and password created (step 8).i.e. username: kvit and password: 123
Step 12 » Create basic repository structure with the below commands[root@kvit ~]# mkdir -p /tmp/svn/{trunk,branches,tags}
Importing files and directories:The svn import command is a quick way to copy an unversioned tree of files into a repository, creating intermediate directories as necessary.svn import doesn’t require a working copy, and your files are immediately committed to the repository.
[root@kvit ~]# svn import -m ‘Initializing basic repository’ /tmp/svn/ http://192.168.0.151/repos/newrep/
Step 13 » Now you can see updated revision and structure details .
Access control lists: Usually, you don’t want to give every user access to every repository. You can restrict repository access per user by using ACLs. ACLs can be enabled with the AuthzSVNAccessFile file option, which takes a file name as its parameter. Add following to subversion.conf file.
“AuthzSVNAccessFile /etc/svnusers”
[root@kvit ~]# vim /etc/httpd/conf.d/subversion.conf
Create two more users:
[root@kvit ~]# htpasswd -m /svn/newrep.users kvit1
[root@kvit ~]# htpasswd -m /svn/newrep.users kvit2
[root@kvit ~]# htpasswd -m /svn/newrep.users kvit1
[root@kvit ~]# htpasswd -m /svn/newrep.users kvit2
You can then create /etc/svnusers. This file consist of sections of the following form:
[reponame:repopath]
user = access
user = access
[root@kvit ~]# vim /etc/svnusers
Now create two more repository newrep1, newrep2 for kvit1 and kvit2 user.[root@kvit ~]# svnadmin create /svn/newrep1
[root@kvit ~]# svnadmin create /svn/newrep2
Now, issue the below commands one by one for necessary permissions
[root@kvit ~]# chown -R apache.apache /svn/newrep1/
[root@kvit ~]# chcon -h system_u:object_r:httpd_sys_content_t /svn/newrep1/
[root@kvit ~]# chcon -R -h apache:object_r:httpd_sys_content_t /svn/newrep1/
[root@kvit ~]# chown -R apache.apache /svn/newrep2/
[root@kvit ~]# chcon -h system_u:object_r:httpd_sys_content_t /svn/newrep2/
[root@kvit ~]# chcon -R -h apache:object_r:httpd_sys_content_t /svn/newrep2/
[root@kvit ~]# service httpd restart
[root@kvit ~]# chown -R apache.apache /svn/newrep1/
[root@kvit ~]# chcon -h system_u:object_r:httpd_sys_content_t /svn/newrep1/
[root@kvit ~]# chcon -R -h apache:object_r:httpd_sys_content_t /svn/newrep1/
[root@kvit ~]# chown -R apache.apache /svn/newrep2/
[root@kvit ~]# chcon -h system_u:object_r:httpd_sys_content_t /svn/newrep2/
[root@kvit ~]# chcon -R -h apache:object_r:httpd_sys_content_t /svn/newrep2/
[root@kvit ~]# service httpd restart
Step 14 » Create basic repository structure with the below commands
[root@kvit ~]# mkdir -p /tmp/svn1/{trunk,branches,tags}
[root@kvit ~]# mkdir -p /tmp/svn2/{trunk,branches,tags}
[root@kvit ~]# mkdir -p /tmp/svn1/{trunk,branches,tags}
[root@kvit ~]# mkdir -p /tmp/svn2/{trunk,branches,tags}
Importing:
[root@kvit ~]# svn import -m ‘Initializing basic repository’ /tmp/svn1/ http://localhost/repos/newrep1/
[root@kvit ~]# svn import -m ‘Initializing basic repository’ /tmp/svn2/ http://localhost/repos/newrep2/
[root@kvit ~]# svn import -m ‘Initializing basic repository’ /tmp/svn1/ http://localhost/repos/newrep1/
[root@kvit ~]# svn import -m ‘Initializing basic repository’ /tmp/svn2/ http://localhost/repos/newrep2/
Now, by using browser you can check that on all 3 repository different users have access like:
Newrep repository: kvit user
Newrep1 repository: kvit1 user
Newrep2 repository: kvit2 user
Newrep repository: kvit user
Newrep1 repository: kvit1 user
Newrep2 repository: kvit2 user
To see these virtual directories type:
[root@kvit ~]# svn ls file:///svn/newrep
[root@kvit ~]# svn ls file:///svn/newrep1
[root@kvit ~]# svn ls file:///svn/newrep2
[root@kvit ~]# svn ls file:///svn/newrep
[root@kvit ~]# svn ls file:///svn/newrep1
[root@kvit ~]# svn ls file:///svn/newrep2
You can go there and do ls but it won’t be very explicit to you. Actually, you should not look at /svn/newrep as a regular directory but rather as a virtualone whose content is far different from the “real” one displayed by ls.
Checking out: (by using co or checkout):
Now, just to check it out across the web browser: http://localhost/repos . You’ll get whatever you have imported showing up to peruse. Once you upload your original layout from the local SVN server, you’re now free to use it remotely on another machine. As long as you are connecting to the Subversion server with the user account(s) that you created earlier.
[root@kvit ~]# svn co http://localhost/repos/newrep –username kvit
[root@kvit ~]# svn checkout http://localhost/repos/newrep1 –username kvit1
[root@kvit ~]# svn co http://localhost/repos/newrep2 –username kvit2
Checking logs:
[root@kvit ~]# svn log file:///svn/newrep
[root@kvit ~]# svn log file:///svn/newrep1
[root@kvit ~]# svn log file:///svn/newrep2
Now, just to check it out across the web browser: http://localhost/repos . You’ll get whatever you have imported showing up to peruse. Once you upload your original layout from the local SVN server, you’re now free to use it remotely on another machine. As long as you are connecting to the Subversion server with the user account(s) that you created earlier.
[root@kvit ~]# svn co http://localhost/repos/newrep –username kvit
[root@kvit ~]# svn checkout http://localhost/repos/newrep1 –username kvit1
[root@kvit ~]# svn co http://localhost/repos/newrep2 –username kvit2
Checking logs:
[root@kvit ~]# svn log file:///svn/newrep
[root@kvit ~]# svn log file:///svn/newrep1
[root@kvit ~]# svn log file:///svn/newrep2
You can also use “list” to check contents in repository:
[root@kvit ~]# svn list http://localhost/repos/newrep2 –username kvit2
[root@kvit ~]# svn list http://localhost/repos/newrep1 –username kvit1
[root@kvit ~]# svn list http://localhost/repos/newrep –username kvit
[root@kvit ~]# svn list http://localhost/repos/newrep2 –username kvit2
[root@kvit ~]# svn list http://localhost/repos/newrep1 –username kvit1
[root@kvit ~]# svn list http://localhost/repos/newrep –username kvit
Creating a working copy:
You will start using Subversion repository by performing a checkout of your project. Checking out a directory from a repository creates a working copy of that directory on your local machine. This copy contains the youngest (that is, most recently created or modified) versions of the directory and its children found in the Subversion repository:
[root@kvit ~]# svn checkout http://localhost/repo/newrep –username kvit
You will start using Subversion repository by performing a checkout of your project. Checking out a directory from a repository creates a working copy of that directory on your local machine. This copy contains the youngest (that is, most recently created or modified) versions of the directory and its children found in the Subversion repository:
[root@kvit ~]# svn checkout http://localhost/repo/newrep –username kvit
Update your working copy:
When working on a project that is being modified via multiple working copies, you’ll want to update your working copy to receive any changes committed from other working copies since your last update. These might be changes that other members of your project team have made, or they might simply be changes you’ve made yourself from a different computer. To protect your data, Subversion won’t allow you commit new changes to out-of-date files and directories, so it’s best to have the latest versions of all your project’s files and directories before making new changes of your own.
Use svn update to bring your working copy into sync with the latest revision in the repository:
Use this command under working directory:
[root@kvit ~]# svn update
When working on a project that is being modified via multiple working copies, you’ll want to update your working copy to receive any changes committed from other working copies since your last update. These might be changes that other members of your project team have made, or they might simply be changes you’ve made yourself from a different computer. To protect your data, Subversion won’t allow you commit new changes to out-of-date files and directories, so it’s best to have the latest versions of all your project’s files and directories before making new changes of your own.
Use svn update to bring your working copy into sync with the latest revision in the repository:
Use this command under working directory:
[root@kvit ~]# svn update
Example:
On pc1 and pc2 we created working directory for repository newrep with user kvit.
[root@pc1 ~]# svn checkout http://192.168.0.151/repo/newrep –username kvit
[root@pc1 ~]# cd newrep
[root@pc1 newrep]# ls
branches tags trunk
[root@pc1 newrep]# cd trunk/
[root@pc1 trunk]# ls
file1.cfg file2.cfg
[root@pc1 trunk]# touch file3.cfg
[root@pc1 trunk]# vim file3.cfg
[root@pc1 trunk]# svn add file3.cfg
A file3.cfg
[root@pc1 trunk]# svn commit -m “file3″
Adding file3.cfg
Transmitting file data
Committed revision 5
Now, we added file3.cfg to directory trunk on repository newrep for user kvit. As on pc2 the working directory already established and user2 is working over there but he don’t know about changes made by user1 on pc1. User2 wants to update his working copy to receive any changes committed from other working copies since his last update. So, user1 will run svn update command to see the changes in his working directory.
[root@pc2 ~]# cd newrep/
[root@pc2 newrep]# ls
branches tags trunk
[root@pc2 newrep]# cd trunk/
[root@pc2 trunk]# ls
file1.cfg file2.cfg
[root@pc2 newrep]# svn update
A trunk/file3.cfg
Updated to revision 5
[root@pc2 trunk]# ls
file1.cfg file2.cfg file3.cfg
Now user2 will be able to see file3.cfg in trunk folder.
On pc1 and pc2 we created working directory for repository newrep with user kvit.
[root@pc1 ~]# svn checkout http://192.168.0.151/repo/newrep –username kvit
[root@pc1 ~]# cd newrep
[root@pc1 newrep]# ls
branches tags trunk
[root@pc1 newrep]# cd trunk/
[root@pc1 trunk]# ls
file1.cfg file2.cfg
[root@pc1 trunk]# touch file3.cfg
[root@pc1 trunk]# vim file3.cfg
[root@pc1 trunk]# svn add file3.cfg
A file3.cfg
[root@pc1 trunk]# svn commit -m “file3″
Adding file3.cfg
Transmitting file data
Committed revision 5
Now, we added file3.cfg to directory trunk on repository newrep for user kvit. As on pc2 the working directory already established and user2 is working over there but he don’t know about changes made by user1 on pc1. User2 wants to update his working copy to receive any changes committed from other working copies since his last update. So, user1 will run svn update command to see the changes in his working directory.
[root@pc2 ~]# cd newrep/
[root@pc2 newrep]# ls
branches tags trunk
[root@pc2 newrep]# cd trunk/
[root@pc2 trunk]# ls
file1.cfg file2.cfg
[root@pc2 newrep]# svn update
A trunk/file3.cfg
Updated to revision 5
[root@pc2 trunk]# ls
file1.cfg file2.cfg file3.cfg
Now user2 will be able to see file3.cfg in trunk folder.
Make your changes:
Overview of five Subversion subcommands that you’ll use most often to make changes:
“svn add file4″
Overview of five Subversion subcommands that you’ll use most often to make changes:
“svn add file4″
Use this to add the file, directory, or symbolic link file4 to be added to the repository. When you next commit, file4 will become a child of its parent directory. Note that if File4 is a directory, everything underneath File4 will be scheduled for addition.
Adding file to online repository:
[root@kvit trunk]# touch file4.cfg
[root@kvit trunk]# svn add file4.cfg
[root@kvit trunk]# svn commit -m “file4″
Adding file4.cfg
Transmitting file data
Committed revision 6
[root@kvit trunk]# touch file4.cfg
[root@kvit trunk]# svn add file4.cfg
[root@kvit trunk]# svn commit -m “file4″
Adding file4.cfg
Transmitting file data
Committed revision 6
Adding directory to online repository:
[root@kvit newrep]# mkdir kvit
[root@kvit newrep]# ls
branches kvit tags trunk
[root@kvit newrep]# svn commit -m “kvit dir”
[root@kvit newrep]# svn add kvit
A kvit
[root@kvit newrep]# svn commit -m “kvit dir”
Adding kvit
Committed revision 8
# svn delete file5
Use this to delete the file, directory, or symbolic link, File5
to be deleted from the repository. If File5 is a file or link, it is immediately deleted from your working copy. If File5 is a directory, it is not deleted, but once you run “svn commit” it will be deleted.
When you commit your changes, File5 will be entirely removed from your working copy and the repository.
Deleting files from working directory:
[root@client trunk]# ls
file1.cfg file2.cfg file3.cfg file4.cfg file5
[root@client trunk]# svn delete file5
D file5
[root@client trunk]# ls
file1.cfg file2.cfg file3.cfg file4.cfg
svn delete can operate directly on repository URLs:
for example:
[root@client ~]# svn delete -m “delete” http://192.168.0.151/repos/newrep2/trunk –username kvit2
As you saw file5 is no more in working directory. But if you delete kvit directory it still shows you in working directory. And once you run svn commit it will removed from working directory as well as from repository.
[root@kvit newrep]# mkdir kvit
[root@kvit newrep]# ls
branches kvit tags trunk
[root@kvit newrep]# svn commit -m “kvit dir”
[root@kvit newrep]# svn add kvit
A kvit
[root@kvit newrep]# svn commit -m “kvit dir”
Adding kvit
Committed revision 8
# svn delete file5
Use this to delete the file, directory, or symbolic link, File5
to be deleted from the repository. If File5 is a file or link, it is immediately deleted from your working copy. If File5 is a directory, it is not deleted, but once you run “svn commit” it will be deleted.
When you commit your changes, File5 will be entirely removed from your working copy and the repository.
Deleting files from working directory:
[root@client trunk]# ls
file1.cfg file2.cfg file3.cfg file4.cfg file5
[root@client trunk]# svn delete file5
D file5
[root@client trunk]# ls
file1.cfg file2.cfg file3.cfg file4.cfg
svn delete can operate directly on repository URLs:
for example:
[root@client ~]# svn delete -m “delete” http://192.168.0.151/repos/newrep2/trunk –username kvit2
As you saw file5 is no more in working directory. But if you delete kvit directory it still shows you in working directory. And once you run svn commit it will removed from working directory as well as from repository.
Deleting directory from working directory:
[root@client newrep]# ls
branches kvit tags trunk
[root@client newrep]# svn delete kvit
D kvit
[root@client newrep]# ls
branches kvit tags trunk
[root@client newrep]# svn commit -m “delete kvit”
Deleting kvit
Committed revision 10
[root@client newrep]# ls
branches tags trunk
[root@client newrep]# ls
branches kvit tags trunk
[root@client newrep]# svn delete kvit
D kvit
[root@client newrep]# ls
branches kvit tags trunk
[root@client newrep]# svn commit -m “delete kvit”
Deleting kvit
Committed revision 10
[root@client newrep]# ls
branches tags trunk
###########################################################
Create a new item kvit as a duplicate of trunk and automatically schedule kvit for addition. When kvit is added to the repository on the next commit, its copy history is recorded (as having originally come from trunk).
“svn copy trunk kvit”
Example:
[root@client newrep]# ls
branches tags trunk
[root@client newrep]# svn copy trunk kvit
A kvit
[root@client newrep]# ls
branches kvit tags trunk
[root@client newrep]# svn commit -m “copy trunk to kvit”
Adding kvit
Committed revision 11.
[root@client newrep]# ls
branches tags trunk
[root@client newrep]# svn copy trunk kvit
A kvit
[root@client newrep]# ls
branches kvit tags trunk
[root@client newrep]# svn commit -m “copy trunk to kvit”
Adding kvit
Committed revision 11.
##############################################################
“svn move linux redhat”
This command is exactly same as running svn copy linux redhat; and svn delete linux. That is, redhat is scheduled for addition as a copy of linux, and linux is scheduled for removal.
Example:
[root@client newrep]# ls
branches linux openpath tags trunk
[root@client newrep]# svn move linux redhat
A redhat
D linux/file2.cfg
D linux/file3.cfg
D linux/file4.cfg
D linux/file1.cfg
D linux
[root@client newrep]# svn commit -m “redhat1″
Deleting linux
Adding redhat
Committed revision 17.
[root@client newrep]# ls
branches linux openpath tags trunk
[root@client newrep]# svn move linux redhat
A redhat
D linux/file2.cfg
D linux/file3.cfg
D linux/file4.cfg
D linux/file1.cfg
D linux
[root@client newrep]# svn commit -m “redhat1″
Deleting linux
Adding redhat
Committed revision 17.
#############################################################
“svn mkdir kvit”
This command is exactly the same as running mkdir kvit; svn add kvit. That is, a new directory named kvit is created and scheduled for addition.
[root@client newrep]# svn mkdir kvit
A kvit
[root@client newrep]# ls
branches kvit openpath redhat tags trunk
[root@client newrep]# svn commit -m “kvit dir”
Adding kvit
Committed revision 8
Review your changes:
Once you’ve finished making changes, you need to commit them to the repository, but before you do so, it’s usually a good idea to take a look at exactly what you’ve changed.
To get an overview of your changes, use the svn status command.
If you run svn status at the top of your working copy with no additional arguments, it will detect and report all file and tree changes you’ve made.
[root@client newrep]# svn status
? scratch.c
A stuff/loot
A stuff/loot/new.c
D stuff/old.c
M bar.c
A kvit
[root@client newrep]# ls
branches kvit openpath redhat tags trunk
[root@client newrep]# svn commit -m “kvit dir”
Adding kvit
Committed revision 8
Review your changes:
Once you’ve finished making changes, you need to commit them to the repository, but before you do so, it’s usually a good idea to take a look at exactly what you’ve changed.
To get an overview of your changes, use the svn status command.
If you run svn status at the top of your working copy with no additional arguments, it will detect and report all file and tree changes you’ve made.
[root@client newrep]# svn status
? scratch.c
A stuff/loot
A stuff/loot/new.c
D stuff/old.c
M bar.c
“svn status” prints seven columns of characters, followed by several whitespace characters, followed by a file or directory name. The first column tells the status of a file or directory and/or its contents. Some of the most common codes that svn status displays are:
“?” item the file, directory, or symbolic link item is not under version control.
“A” item the file, directory, or symbolic link item has been scheduled for addition into the repository.
“C” item the file item is in a state of conflict. That is, changes received from the server during an update overlap with local changes that you have in your working copy (and weren’t resolved during the update). You must resolve this conflict before committing your changes to the repository.
“D” item the file, directory, or symbolic link item has been scheduled for deletion from the repository.
“M” item the contents of the file item have been modified.
If you pass a specific path to svn status, you get information about that item alone:
[root@client newrep]# svn status stuff/fish.c
D stuff/fish.c
[root@client newrep]# svn status stuff/fish.c
D stuff/fish.c
svn status also has a –verbose(-v) option, which will show you the status of every item in your working copy, even if it has not been changed.
[root@client newrep]# svn status -v
M 44 23 sally README
44 30 sally INSTALL
M 44 20 harry bar.c
44 18 ira stuff
44 35 harry stuff/trout.c
D 44 19 ira stuff/fish.c
44 21 sally stuff/things
A 0 ? ? stuff/things/bloo.h
44 36 harry stuff/things/gloo.c
M 44 23 sally README
44 30 sally INSTALL
M 44 20 harry bar.c
44 18 ira stuff
44 35 harry stuff/trout.c
D 44 19 ira stuff/fish.c
44 21 sally stuff/things
A 0 ? ? stuff/things/bloo.h
44 36 harry stuff/things/gloo.c
This is the “long form” output of svn status. The letters in the first column mean the same as before, but the second column shows the working revision of the item. The third and fourth columns show the revision in which the item last changed, and who changed it.
Sometimes it is useful to see which of the items in your working copy have been modified in the repository since the last time you updated your working copy. For this, svn status offers the –show-updates (-u) option, which contacts the repository and adds information about items that are out of date:
[root@client newrep]# svn status -u -v
14 5 kvit trunk/file3.cfg
14 6 kvit trunk/file4.cfg
* trunk/file5.cfg
14 3 root kvit/file1.cfg
* 14 11 kvit kvit
Status against revision: 20
14 5 kvit trunk/file3.cfg
14 6 kvit trunk/file4.cfg
* trunk/file5.cfg
14 3 root kvit/file1.cfg
* 14 11 kvit kvit
Status against revision: 20
Notice in the above example the two asterisks: if you were to run svn update at this point, you would receive changes to file5.cfg and kvit.
SVN Diff:
Another way to examine your changes is with the svn diff command, which displays differences in file content. When you run svn diff at the top of your working copy with no arguments, Subversion will print the changes you’ve made to human-readable files in your working copy. It displays those changes in unified diff format, a format which describes changes as “hunks” (or “snippets”) of a file’s content where each line of text is prefixed with a single-character code: a space, which means the line was unchanged; a minus sign (-), which means the line was removed from the file; or a plus sign (+), which means the line was added to the file. In the context of svn diff, those minus-sign- and plus-sign-prefixed lines show how the lines looked before and after your modifications, respectively.
[root@client newrep]# svn diff
Index: trunk/file2.cfg
===================================================================
— trunk/file2.cfg (revision 19)
+++ trunk/file2.cfg (working copy)
@@ -1,2 +1,10 @@
this is file 2
+3
+4
+5
Index: trunk/file4.cfg
===================================================================
— trunk/file4.cfg (revision 19)
+++ trunk/file4.cfg (working copy)
@@ -1 +1 @@
-this is file4
+this is
Index: trunk/file5.cfg
===================================================================
— trunk/file5.cfg (revision 20)
+++ trunk/file5.cfg (working copy)
@@ -0,0 +1,2 @@
+this is file 5
+
You can share the changes you’ve made in your working copy with someone else without first committing those changes by creating a patch file from the redirected output of svn diff:
[root@client newrep]# svn diff > patchfile
Index: trunk/file2.cfg
===================================================================
— trunk/file2.cfg (revision 19)
+++ trunk/file2.cfg (working copy)
@@ -1,2 +1,10 @@
this is file 2
+3
+4
+5
Index: trunk/file4.cfg
===================================================================
— trunk/file4.cfg (revision 19)
+++ trunk/file4.cfg (working copy)
@@ -1 +1 @@
-this is file4
+this is
Index: trunk/file5.cfg
===================================================================
— trunk/file5.cfg (revision 20)
+++ trunk/file5.cfg (working copy)
@@ -0,0 +1,2 @@
+this is file 5
+
You can share the changes you’ve made in your working copy with someone else without first committing those changes by creating a patch file from the redirected output of svn diff:
[root@client newrep]# svn diff > patchfile
Fix your mistakes:
Suppose while viewing the output of svn diff you determine that all the changes you made to a particular file are mistakes. Just use the svn revert command to restore your file to previous state.
[root@client trunk]# svn revert file4.cfg
Reverted ‘file4.cfg’
[root@client trunk]# svn revert file5.cfg
Reverted ‘file5.cfg’
[root@client trunk]# svn revert file2.cfg
Reverted ‘file2.cfg’
Perhaps you mistakenly removed a file from version control:
[root@client trunk]# svn delete file5.cfg
D file5.cfg
[root@client trunk]# ls
file1.cfg file2.cfg file3.cfg file4.cfg
[root@client trunk]# svn revert file5.cfg
Reverted ‘file5.cfg’
[root@client trunk]# ls
file1.cfg file2.cfg file3.cfg file4.cfg file5.cfg
File5.cfg is recovered.
Reverted ‘file4.cfg’
[root@client trunk]# svn revert file5.cfg
Reverted ‘file5.cfg’
[root@client trunk]# svn revert file2.cfg
Reverted ‘file2.cfg’
Perhaps you mistakenly removed a file from version control:
[root@client trunk]# svn delete file5.cfg
D file5.cfg
[root@client trunk]# ls
file1.cfg file2.cfg file3.cfg file4.cfg
[root@client trunk]# svn revert file5.cfg
Reverted ‘file5.cfg’
[root@client trunk]# ls
file1.cfg file2.cfg file3.cfg file4.cfg file5.cfg
File5.cfg is recovered.
Commit your changes:
The svn commit command sends all of your changes to the repository. When you commit a change, you need to supply a log message describing your change. Your log message will be attached to the new revision you create.
[root@client newrep]# svn commit -m “changes”
Sending sandwich.txt
Transmitting file data .
Committed revision 3.
Creating Locks:
In the Subversion repository, a lock is a piece of metadata that grants exclusive access to one user to change a file. This user is said to be the lock owner.
[root@client newrep]# svn lock newrep/project/trunk/file1.cfg -m “lock for release ”
‘file1.cfg’ locked by user ‘kvit’.
[root@client ~]# svn status newrep/
M K newrep/project/trunk/file1.cfg
The svn status command shows a K next to the file (short for locKed), indicating that the lock token is present
Sending sandwich.txt
Transmitting file data .
Committed revision 3.
Creating Locks:
In the Subversion repository, a lock is a piece of metadata that grants exclusive access to one user to change a file. This user is said to be the lock owner.
[root@client newrep]# svn lock newrep/project/trunk/file1.cfg -m “lock for release ”
‘file1.cfg’ locked by user ‘kvit’.
[root@client ~]# svn status newrep/
M K newrep/project/trunk/file1.cfg
The svn status command shows a K next to the file (short for locKed), indicating that the lock token is present
svn info command, which does not contact the repository when run against working copy paths, can display the lock token reveals an important piece of information about those tokens: they are cached in the working copy.As shown below in an example.
[root@client ~]# svn info newrep/project/trunk/file1.cfg
Path: newrep/project/trunk/file1.cfg
Name: file1.cfg
URL: http://192.168.0.150/repos/newrep/project/trunk/file1.cfg
Repository Root: http://192.168.0.150/repos/newrep
Repository UUID: c08fd4d1-82b1-495a-91b0-dd4e51d1aafd
Revision: 5
Node Kind: file
Schedule: normal
Last Changed Author: kvit
Last Changed Rev: 5
Last Changed Date: 2015-04-02 04:13:57 +0530 (Thu, 02 Apr 2015)
Text Last Updated: 2015-04-04 07:46:01 +0530 (Sat, 04 Apr 2015)
Checksum: 6cc46187cdb10f16ed51f05f7f85a51c
Lock Token: opaquelocktoken:5afd2538-29da-4268-ba56-c57e30db9c4c
Lock Owner: kvit
Lock Created: 2015-04-06 21:41:49 +0530 (Mon, 06 Apr 2015)
Lock Comment (1 line):
lock for release
Now that kvit has locked file1.cfg, kvit1 is unable to change or delete file1.cfg:
[root@client1 ~]# svn delete newrep/project/trunk/file1.cfg
D newrep/project/trunk/file1.cfg
[root@client1 ~]# cd newrep
[root@client1 newrep]# svn commit -m “delete useless file”
Deleting project/trunk/file1.cfg
svn: E195022: Commit failed (details follow):
svn: E195022: File ‘/root/newrep/project/trunk/file1.cfg’ is locked in another working copy
svn: E160038: ‘/repos/newrep/!svn/txr/5-6/project/trunk/file1.cfg': no lock token available
svn: E175002: Additional errors:
svn: E175002: DELETE of ‘/repos/newrep/!svn/txr/5-6/project/trunk/file1.cfg': 423 Locked
Path: newrep/project/trunk/file1.cfg
Name: file1.cfg
URL: http://192.168.0.150/repos/newrep/project/trunk/file1.cfg
Repository Root: http://192.168.0.150/repos/newrep
Repository UUID: c08fd4d1-82b1-495a-91b0-dd4e51d1aafd
Revision: 5
Node Kind: file
Schedule: normal
Last Changed Author: kvit
Last Changed Rev: 5
Last Changed Date: 2015-04-02 04:13:57 +0530 (Thu, 02 Apr 2015)
Text Last Updated: 2015-04-04 07:46:01 +0530 (Sat, 04 Apr 2015)
Checksum: 6cc46187cdb10f16ed51f05f7f85a51c
Lock Token: opaquelocktoken:5afd2538-29da-4268-ba56-c57e30db9c4c
Lock Owner: kvit
Lock Created: 2015-04-06 21:41:49 +0530 (Mon, 06 Apr 2015)
Lock Comment (1 line):
lock for release
Now that kvit has locked file1.cfg, kvit1 is unable to change or delete file1.cfg:
[root@client1 ~]# svn delete newrep/project/trunk/file1.cfg
D newrep/project/trunk/file1.cfg
[root@client1 ~]# cd newrep
[root@client1 newrep]# svn commit -m “delete useless file”
Deleting project/trunk/file1.cfg
svn: E195022: Commit failed (details follow):
svn: E195022: File ‘/root/newrep/project/trunk/file1.cfg’ is locked in another working copy
svn: E160038: ‘/repos/newrep/!svn/txr/5-6/project/trunk/file1.cfg': no lock token available
svn: E175002: Additional errors:
svn: E175002: DELETE of ‘/repos/newrep/!svn/txr/5-6/project/trunk/file1.cfg': 423 Locked
But kvit, after touching up the file1.cfg, is able to commit his changes to the file. That’s because he authenticates as the lock owner and also because his working copy holds the correct lock token: As shown below
[root@client newrep]# svn status
M K project/trunk/file1.cfg
[root@client newrep]# svn commit -m “file1.cfg changes”
Sending project/trunk/file1.cfg
Transmitting file data .
Committed revision 6.
[root@client newrep]# svn status
M K project/trunk/file1.cfg
[root@client newrep]# svn commit -m “file1.cfg changes”
Sending project/trunk/file1.cfg
Transmitting file data .
Committed revision 6.
[root@client newrep]# svn status
Notice that after the commit is finished, svn status shows that the lock token is no longer present in the working copy. This is the standard behavior of svn commit it searches the working copy (or list of targets, if you provide such a list) for local modifications and sends all the lock tokens it encounters during this walk to the server as part of the commit transaction. After the commit completes successfully, all of the repository locks that were mentioned are released even on files that weren’t committed.
Of course, locking a file doesn’t oblige one to commit a change to it. The lock can be released at any time with a simple svn unlock command:
[root@client newrep]# svn unlock file1.cfg
‘file1.cfg’ unlocked.
Discovering Locks:
When a commit fails due to someone else’s locks, it’s fairly easy to learn about them. The easiest way is to run svn status –u
[root@client newrep]# svn status -u
K 6 project/trunk/file1.cfg
Status against revision: 6
Breaking and Stealing Locks:
From the administrator’s chair, it’s simple to break locks. The svnlook and svnadmin programs have the ability to display and remove locks directly from the repository.
[root@client newrep]# svn unlock file1.cfg
‘file1.cfg’ unlocked.
Discovering Locks:
When a commit fails due to someone else’s locks, it’s fairly easy to learn about them. The easiest way is to run svn status –u
[root@client newrep]# svn status -u
K 6 project/trunk/file1.cfg
Status against revision: 6
Breaking and Stealing Locks:
From the administrator’s chair, it’s simple to break locks. The svnlook and svnadmin programs have the ability to display and remove locks directly from the repository.
To remove lock as an administrator logon to pc having the repository and then run svnadmin lslocks command with repository path will show you the lock info and also the path. Note that path name and then run command svnadmin rmlocks with repository and filepath, this will remove the lock from file7.cfg.
[root@client newrep]# svnadmin lslocks /svn/newrep
Path: /file7.cfg
UUID Token: opaquelocktoken:94dfad0a-6955-426b-9494-526b0c8a6400
Owner: kvit
Created: 2015-04-04 09:08:05 +0530 (Sat, 04 Apr 2015)
Expires:
Comment (0 lines):
[root@client ~]# svnadmin rmlocks /svn/newrep /file7.cfg
Removed lock on ‘/file7.cfg’.
[root@client ~]# svn status -u /root/newrep/
M B 23 /root/newrep/file7.cfg
Status against revision: 23
[root@client newrep]# svn status -u
M T 23 file7.cfg
Status against revision: 23
If the repository lock was broken, then svn status –show-updates(-u)displays a B(Broken) symbol next to the file. If a new lock exists in place of the old one, then a T(sTolen) symbol is shown.
Path: /file7.cfg
UUID Token: opaquelocktoken:94dfad0a-6955-426b-9494-526b0c8a6400
Owner: kvit
Created: 2015-04-04 09:08:05 +0530 (Sat, 04 Apr 2015)
Expires:
Comment (0 lines):
[root@client ~]# svnadmin rmlocks /svn/newrep /file7.cfg
Removed lock on ‘/file7.cfg’.
[root@client ~]# svn status -u /root/newrep/
M B 23 /root/newrep/file7.cfg
Status against revision: 23
[root@client newrep]# svn status -u
M T 23 file7.cfg
Status against revision: 23
If the repository lock was broken, then svn status –show-updates(-u)displays a B(Broken) symbol next to the file. If a new lock exists in place of the old one, then a T(sTolen) symbol is shown.
Available subcommands:
add
blame (praise, annotate, ann)
cat
changelist (cl)
checkout (co)
cleanup
commit (ci)
copy (cp)
delete (del, remove, rm)
diff (di)
export
help (?, h)
import
info
list (ls)
lock
log
merge
mergeinfo
mkdir
move (mv, rename, ren)
propdel (pdel, pd)
propedit (pedit, pe)
propget (pget, pg)
proplist (plist, pl)
propset (pset, ps)
resolve
resolved
revert
status (stat, st)
switch (sw)
unlock
update (up)
add
blame (praise, annotate, ann)
cat
changelist (cl)
checkout (co)
cleanup
commit (ci)
copy (cp)
delete (del, remove, rm)
diff (di)
export
help (?, h)
import
info
list (ls)
lock
log
merge
mergeinfo
mkdir
move (mv, rename, ren)
propdel (pdel, pd)
propedit (pedit, pe)
propget (pget, pg)
proplist (plist, pl)
propset (pset, ps)
resolve
resolved
revert
status (stat, st)
switch (sw)
unlock
update (up)
Post a Comment