Setting up the SVN server

CentOS 7 Install the SVN server program

Install command

yum install -y subversion
Copy the code

validation

svn --version
Copy the code

Create and configure the repository

Create the repository directory

mkdir -p /var/svn/repository
Copy the code

Create a specific project directory under the repository directory

mkdir helloworld
Copy the code

Create the SVN version library

svnadmin create /var/svn/repository/helloworld
Copy the code

See the effect

  • conf: is the repository configuration file (repository user access accounts, permissions, etc.)
  • db: is the storage file for all version control data
  • hooks: Directory for storing hook script files
  • locksThis directory is used to keep track of clients accessing file libraries

Configure services on the SVN

The default port of the SVN is 3690

The client requests the URL of the helloWorld project on the server side: SVN :// IP :3690/ helloWorld

Modify the configuration of the service (hand over the version library we created to SVN service management)

vim /etc/sysconfig/svnserve
Copy the code

Change the path to the repository root directory you created earlier

Start the SVN service

Viewing SVN Services

systemctl list-unit-files | grep svn
Copy the code

Set boot to start automatically

systemctl enable svnserve.service
Copy the code

Start the service

systemctl start svnserve.service
Copy the code

Verify that the service is started successfully

Permission management of the SVN

There are three configuration files under the repository configuration folder on the server side

authz: Configuration file for assigning permissions

[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average
# user group
[groups]
chengdu = user1,user2
beijing = user3
Set permissions to the repository root directory
[/]
@beijing = rw
Set the specified repository permission
[/helloworld]
@chengdu = rw
user5 = r
# * = indicates that no user has any permissions except the user with the above configured permissions
* = 
Copy the code

passwd: Configuration file for setting the user name and password

### This file is an example password file for svnserve.
### Its format is similar to that of svnserve.conf. As shown in the
### example below it contains one section labelled [users].
### The name and password for each user follow, one account per line.

[users]
user1 = passwd01
user2 = 123456
user3 = abcdefg
user4 = aaaa
user5 = bbbb
Copy the code

svnserve.conf: Repository service configuration file

### Visit http://subversion.apache.org/ for more information.

[general]
### The anon-access and auth-access options control access to the
### repository for unauthenticated (a.k.a. anonymous) users and
### authenticated users, respectively.
### Valid values are "write", "read", and "none".
### Setting the value to "none" prohibits both reading and writing;
### "read" allows read-only access, and "write" allows complete 
### read/write access to the repository.
### The sample settings below are the defaults and specify that anonymous
### users have read-only access to the repository, while authenticated
### users have read and write access to the repository.
anon-access = none
Enable authorized access
auth-access = write
### The password-db option controls the location of the password
### database file. Unless you specify a path starting with a /,
### the file's location is relative to the directory containing
### this configuration file.
### If SASL is enabled (see below), this file will NOT be used.
### Uncomment the line below to use the default password file.
password-db = passwd
### The authz-db option controls the location of the authorization
### rules for path-based access control. Unless you specify a path
### starting with a /, the file's location is relative to the the
### directory containing this file. If you don't specify an
### authz-db, no path-based access control is done.
### Uncomment the line below to use the default authorization file.
authz-db = authz
### This option specifies the authentication realm of the repository.
### If two repositories have the same authentication realm, they should
### have the same password database, and vice versa. The default realm
### is repository's uuid.
# realm = My First Repository
### The force-username-case option causes svnserve to case-normalize
### usernames before comparing them against the authorization rules in the
### authz-db file configured above. Valid values are "upper" (to upper-
### case the usernames), "lower" (to lowercase the usernames), and
### "none" (to compare usernames as-is without case conversion, which
### is the default behavior).
# force-username-case = none

[sasl]
### This option specifies whether you want to use the Cyrus SASL
### library for authentication. Default is false.
### This section will be ignored if svnserve is not built with Cyrus
### SASL support; to check, run 'svnserve --version' and look for a line
### reading 'Cyrus SASL authentication is available.'
# use-sasl = true
### These options specify the desired strength of the security layer
### that you want SASL to provide. 0 means no encryption, 1 means
### integrity-checking only, values larger than 1 are correlated
### to the effective key length for encryption (e.g. 128 means 128-bit
### encryption). The values below are the defaults.
# min-encryption = 0
# max-encryption = 256
                                                                                                                                                 33, 1          Bot
Copy the code

The CLI client operates the SVN

Checkout checkout | co

Used to download the entire contents of the library.

SVN co SVN: / / 47.106.183.193 / helloworld /The SVN can specify the user name and password when checking outSVN co SVN: / / 47.106.183.193 / helloworld - username XXX - password yyy. /Copy the code

A copy of the work

  • The directory where SVN resides. For the example above, user1 is the working copy

  • Version-control operations must be performed in the working copy directory. For example: submit, update, etc

    This operation

  • To ensure that the working copy can interact with the server normally, do not delete or modify it

    Contents of the record

Add the add

The SVN requires that a new file be added to the version control system before it is submitted

svn add hello.txt
Copy the code

The hello. TXT status is A, which means that the file has been successfully added to version control. If the state is? , it has not been added to version control.

Commit | CI

Requirement 1: Additional log information

  • Log information is similar to comments during Java code writing, marking the changes made during this operation
  • SVN commit -m “XXX” [filename]

Requirement 2: You must have corresponding permissions

Modify the configuration file /conf/ SVNserve. conf of the server version library to enable comments for anonymous access configuration items

svn ci -m "First submission" hello.txt
Copy the code

After submission, the version number is automatically increased by 1.

Display all version information log

This parameter is used to display the version author, date, and path of the SVN. If you only want to view the information between two specific versions, you can carry the -r start version: End version parameter

svn log
svn log-r Start version: Indicates the end versionCopy the code

Look at the list

View the content of the SVN version library

SVN list SVN: / / 47.106.183.193 / helloworldCopy the code

Update Update | up

Download all changes made to the server-side files locally

svn up
Copy the code

Rollback version revert

Has not been submitted

When you want to undo a change to a file, you can use SVN Revert, which undoes a local change in any file or directory. The revert operation restores not just a single file, but an entire directory. The recovery directory needs to carry the -r parameter

SVN Revert file name SVN Revert -r Directory nameCopy the code

Have submitted

For the submitted changes, you need to use the merge command to roll back the changes, carrying the -r parameter

SVN merge -r Latest version: indicates the directory or file name of the target versionCopy the code

conflict

Obsolete document

A file that has been modified from an older version of the server, and will fail to commit!

All outdated files must be updated before files that have been updated based on the latest version can be submitted.

After the update, user1’s changes to the file are also synchronized to user2’s working copy, after which User2 can commit normally

Emergence of conflict

The changes updated from the server and the local changes are inconsistent in the same file and location, that is, the same line is changed

Now that both users have modified the same row at the same time, user2 is committed first, and user1 finds a conflict when updating

Expression of conflict

Inside the file

  • <<<<<<<|||||||Is the local modification of the content
  • |||||||= = = = = = =That’s what we did before we changed it
  • = = = = = = =>>>>>>>Is the modification on the server side

Directory inside

The following three files are generated as a result of the conflict

  • Xxx. mine file: contents of a local file when a conflict occurs

  • Xxx. r[minor version number] file: the contents of the file before the conflict occurred

  • Xxx. r[large version number] file: the contents of the server side file when the conflict occurred

Manual Conflict Resolution

  1. Delete three redundant files that were created when the conflict occurred
  2. Remove redundant symbols from conflicting files
  3. Edit the file to a satisfactory state
  4. submit

Semi-automatic conflict resolution

  • (p): Delay, and then manually process
  • (df): Displays all differences
  • (e)Editor:
  • (m): merging
  • (s): Displays all options
# skip this conflict, (p) -accept incoming version of the entire file and leave it unresolved [unresolved] # (tf) -accept incoming Version of entire file [possessive -full] # reject all incoming changes to this file [using my own file] (MF) - reject all incoming changes to this file [mine-full] # accept incoming changes from conflict (TC) - Accept incoming changes only where they conflict (MC) - reject incoming changes which conflict and accept the rest [mine-conflict] # As it appears in the working copy [working] # Postpone all remaining conflicts (Q) -postpone all remaining conflicts # Change merged file in the editor (e) -change Merged file in an editor [edit] # display all changes made to merged file (df) - show all changes made to merged file # display all conflicts (ignore merged version) (dc) - Show all conflicts (ignoring merged version) # Use merge tool to resolve conflict # (l) - Launch external merge tool to resolve conflict [launch conflictCopy the code

Press E to edit the page

Then it is the same as above, delete the special symbols, and then edit the file to a satisfactory state, save and exit

Press r to mark resolved, and you can commit again

To avoid conflict

  • Try to update the file before modifying it, and try to modify the file content on the basis of the latest version
  • Minimize the possibility of multiple people modifying the same file
  • Enhance communication between team members