One, install SVN
sudo apt-get install subversion
Second, add SVN administrative users and subversion user groups
sudo adduser svnuser
sudo addgroup subversion
sudo addgroup svnuser subversion
Three, create a project directory
sudo mkdir /home/svn
cd /home/svn
sudo mkdir mt
sudo chown -R root:subversion mt //You can change it in root, and replace it with your usual user under Linux
sudo chmod -R g+rws mt
Fourth, create the SVN file library name
sudo svnadmin create /home/svn/mt
5. Access the LAN and checkout the files in the SVN library
svn checkout http://192.168.10.121:8010/svn/mt/
Reposted from: https://my.oschina.net/u/1375497/blog/171395
Start up the service:
1. The root user enters the ubuntu system
2. Enter the etc directory (cd ./etc)
3. View the file and find the rc.local file (ls)
4. Edit the rc.local file (vi ./rc.cocal), press the i key to enter the editing mode
5. Insert the SVN startup command (svnserve -d -r /usr/svn/) before exit0, press the esc key, :wq to save, and finish
Detailed SVN Permission Configuration
This chapter will introduce in detail the two configuration files involved in SVN permission configuration, svnserve.conf and authz.conf. Through the line-by-line description of the configuration, some of the details will be clarified. In addition, other configuration, installation, etc. are not the focus of this article. If readers have any questions, please refer to some of the documents listed in the "References" below.
The first thing to note here is that no leading spaces are allowed in any valid configuration line of the configuration file, otherwise the program may make an error and give you a ``Option expected'' prompt. In other words, if you copy the relevant configuration lines directly from the plain text format of this article, you need to manually delete all the preceding 4 spaces. Of course, if you think it is a hard work to delete the same number of leading spaces in many lines at once, then maybe the "Column Mode" editing mode of UltraEdit can help you a lot.
1. The svnserve.conf
``SVN\conf\ svnserve.conf '' file is the configuration file of the svnserve.exe server process. We explain it line by line as follows.
First, we tell svnserve.exe that the username and password are placed in the passwd.conf file. Of course, you can change it to any valid file name. For example, the default is passwd::
password-db = passwd.conf. The
next two lines mean that only authenticated users are allowed to access the code base. So who are "verified" users? Oh, of course, those guys who hold usernames and passwords in the passwd.conf file. After the equal sign of these two lines, currently only three values of read write none are allowed. If you want to achieve some special values, such as "read-once", it is recommended that you modify the source code yourself. Anyway, it is also free. software::
anon-access = none
auth-access = write
Next is the most critical sentence. It tells svnserve.exe that the relevant configuration of project directory access permissions is placed in the authz.conf file ::
authz-db = authz.conf
Of course , When svn 1.3.2 introduced this function, the system defaulted to use authz instead of authz.conf as the configuration file.
The above-mentioned passwd.conf and authz.conf files can also be shared as multiple code libraries. We only need to put them in a public directory, for example, in the ``D:\svn'' directory, and then in each In the svnserve.conf file of a code base, use the following statement::
password-db = ..\..\passwd.conf
authz-db = ..\..\authz.conf
or ::
password-db = .. /../passwd.conf
authz-db = ../../authz.conf
This allows multiple code bases to share the same user password and directory control configuration file, which is very convenient in some cases.
2.
The configuration section of the user grouping ``SVN\conf\authz.conf'' file of authz.conf can be divided into two types, ``[group]'' is one type, and all user grouping information is placed inside. The rest start with ``[SVN:/]'' is another category, each paragraph corresponds to a directory of the project, and its directory related permissions are set in this paragraph.
First of all, we manage the personnel in groups, so that when the permissions need to be reset due to personnel changes in the future, we will try to change things as little as possible. We have set up 5 user groups in total, and the group names are uniformly prefixed with ``g_'' to facilitate identification. Of course, the group members are separated by commas::
[groups]
# Any person who is not in the department who wants to view all documents
g_vip = morson
# 经理
g_manager = michael
# Beijing Office staff
g_beijing = scofield
# Shanghai Office staff
g_shanghai = lincon
# HQ General Staff
g_headquarters = rory, linda
# Little secretary, write a document
g_docs = linda
noticed that no, linda account exists in the two groups of "headquarters" and "documentation staff" at the same time, it's not that I am dizzy and make a mistake, yes Because Subversion allows me to set this up. It means that this guy will have more permissions than his colleague rory, which is really convenient. What are more specific? Please look down!
3. The project root directory of authz.conf
Next, we have restricted the project root directory, which can only be modified by the manager of the SVN business department, and everyone else can only look at it::
[SVN:/]
@g_manager = rw
* = r
- `` [ SVN:/]`` represents the relative root node of this directory structure, or the root directory of the SVN project. The word SVN in it is actually the name of the code base, that is, the SVN created with the svnadmin create command.
-The ``@'' here means that the next is a group name, not a user name. Because currently there is only one michael in the g_manager group, you can of course replace the line ``@g_manager = rw`` with ``michael = rw'', and the meaning is exactly the same.
-``*`` means "everyone except those mentioned above", that is, "everyone except the department manager", of course, including the weird old man of the general manager
-``* = r `` means "those people can only read but not write"
4. The project subdirectory of authz.conf
Then, we need to open the read and write permissions of the log directory to the headquarters staff::
[SVN:/diary/headquarters]
@g_manager = rw
@g_headquarters = rw
@g_vip = r
* =
The setting of this subdirectory has some characteristics, because we know from the demand analysis that the permission range of this subdirectory is smaller than that of its parent directory, and it does not allow other than the specified ones Anyone visits. In this setting, we need to pay attention to the following points:
-I bet that most of the guys who design svn work on unix-like platforms, so they always like to use ``/`` to identify subdirectories, and completely ignore the use of ``\` under MS Windows `To do the same thing. So here, in order to represent the directory ``diary\headquarters``, we must use the format ``[SVN:/diary/headquarters]''. Of course, if you must use ``\``, then the only result is that Subversion will ignore this part of your settings and ignore it.
-The ``* ='' in the last line here means that anyone except managers, headquarters personnel, and special persons are prohibited from accessing this directory. Can this line be omitted? No, because **permissions are inherited**, the sub-directory will automatically have the permissions of the parent directory. Without this line, all accounts can read the files in the ``/diary/headquarters`` directory. Because although we have not set the parent directory permissions of this directory, the default rules make the permissions of the ``/diary'' directory exactly the same as the root directory, so that the rest of the accounts can get access to the ``/diary/headquarters`` directory. Permissions. So in simple terms,
the purpose of the sentence ``* ='' is to cut off the inheritance of permissions, so that the administrator can customize the permissions of a certain directory and its subdirectories, thereby completely avoiding the influence of the permission settings of its parent directory.
-The reason why the sentence ``@g_vip = r`` needs to be added here is because of the above explanation. If you do not explicitly grant the general manager the right to read, he will be excluded by ``* ='' just like everyone else.
-If anyone among the judges has played with firewall configuration, you may feel that the above configuration is very familiar. However, there is one point different from the firewall configuration, that is, there is no **sequence** between each configuration line. In other words, if I move the ``* ='' line of the configuration in this paragraph to the front, it will not affect the final effect of the entire configuration at all.
Next, let’s take a look at this paragraph::
[SVN:/ref]
@g_manager = rw
@g_docs = rw
* = r
The main point here is that the g_docs group contains a linda account, which also appears in the g_headquarters group. , Which means that linda will have read and write permissions to the two directories ``/ref`` and ``diary\headquarters``.
6. The directory representation of authz.conf
In the previous description, we all use the format ``[repos:/some/dir]'' to represent a certain directory of the project, such as the ``[ SVN:/diary/headquarters]''. In fact, Subversion allows you to use the format ```[/some/dir]``, which means that you do not specify a code base to represent a directory, and the directory at this time matches all items.
For users who use svnserve, only when svnserve is running with the ``-r'' parameter, and multiple code libraries share the same directory permissions file (ie authz.conf or authz), the code library is not specified The name can cause trouble. Under normal circumstances, we use configuration files independently for each code base. After all, the directory structure of each project is very different, and it makes little sense to mix them together. Therefore, in general, for the sake of brevity, it is not necessary to specify the code base name. This article all specify the code base name, mainly for future expansion into the same configuration file to facilitate the cooperation with the Apache server.
For users of Apache, the two can be very different, because at this time they are often used to using a common directory permissions configuration file. If you use the SVNParentPath command, it is important to specify the name of the repository, because if you use the latter, the ``[/some/dir]`` part will be the same as the ``[/some /dir]'' directory matches. If you use the SVNPath instruction, there is no difference between the two representations, after all, there is only one version library.
Other notes of 7authz.conf
7.1. The ``r'' permission of the parent directory and the influence of the ``w'' permission of the subdirectory
raised this issue specifically because in 1.3.1 and previous versions, There is a bug that in order for an account to have write access to a subdirectory, it must have read access to its parent directory. So now using version 1.3.2 and higher, it is convenient for those administrators who want to put multiple independent projects in a code repository to assign permissions. For example, Sun Sun has established a large code base for storing all employee logs, called diary, and the SVN division is only one of the departments, you can do this:
[diary:/]
@g_chief_manager = rw
[diary:/SVN ]
@g_SVN_manager = rw
@g_SVN = r In
this way, for all SVN business department personnel, you can use the URL svn://192.168.0.1/diary/SVN as the root directory for daily operations, regardless of it. In fact, it's just a subdirectory, and when a few people with strong curiosity want to try to check out svn://192.168.0.1/diary, they will immediately get a warning "Access denied", wow, that's cool.
7.2. Default permissions
What if I don’t set any permissions for a certain directory? Immediately do an experiment and change::
[diary:/]
@g_chief_manager = rw
to::
[diary:/]
# @g_chief_manager = rw
This is equivalent to not setting anything. On my svn 1.3.2 version, any access is forbidden at this time. In other words, if you want someone to access a certain directory, you must explicitly indicate this. This strategy seems to be consistent with the firewall strategy.
7.3. A minor side effect caused by read-only permission.
If you set::
[SVN:/diary]
* = r
, Subversion will think that no one is allowed to change the diary directory, including deletion, **rename**, and * *New**.
In other words, if you accidentally write the directory name incorrectly when creating the directory in the early stage of the project, for example, it is written as dairy due to a spelling error, unless you change this line of settings in authz.conf in the future, you cannot use the svn mv command to make it wrong. Catalog corrections.
7.4. The impact of anon-access attribute on directory permissions
You want to open your code base to everyone, so you open anonymous access, add a line in the svnserve.conf file: ``anon-access=read``. But for some directories, you don't want others to see them, so for those special directories, you configure in authz.conf, add the authorized access person, and add the ``* ='' mark. You think everything is OK, but you are missing that the special directory is inaccessible, and it always prompts ``Not authorized to open root of edit operation'' or ``Unauthorized to open root of edit operation''
. You double check the user name and password you configured to confirm that everything is correct, and the problem still cannot be solved.
It turns out that Subversion has a small bug. When ``anon-access=read`` and a directory is set with the ``* ='' mark, the above problem will occur. This bug still exists in the latest version (v1.4), and maybe it can be corrected in the next version.
The solution is to set anon-access to none in svnserve.conf.
8. Improvement, support for Chinese catalogs. When
working in the morning, Morson came to Michael's desk and said: "Can you change our Beijing office and Shanghai office catalogs to Chinese? Looking at the pinyin, I think It's uncomfortable?" Michael thought. Fortunately, I just learned some knowledge related to unicode encoding in the past two days, so he smiled and replied: "Of course, you can see the Chinese directory name tomorrow afternoon."
8.1. Use svn mv command, rename some of the original directories and commit them into the code base, the directory structure after the rename is as follows::
SVN
├─work
log│ ├─headquarters staff
│ ├─ Beijing Office
│ └─ Shanghai Office
├─ company public reference file directory
└─ temporary file storage at
8.2. Authz.conf modify the code library file, rename the corresponding directory one by one
8.3. Authz.conf file UTF-8 format , And after the BOM
converts the configuration file into UTF-8 format, Subversion can correctly recognize Chinese characters. But one thing to note here is that UTF-8 files must not contain BOM. BOM is the abbreviation of Byte Order Mark, which refers to the several characters used to indicate the order of high and low bytes in the header of UNICODE files, usually ``FF FE'', and after encoding it with UTF-8, it is ``EF BB BF``. Since the UTF-8 file itself does not have a byte order problem, the BOM that is of great significance to UTF-16 and other encoding methods has only one function for UTF-8-indicating that the file is in
UTF-8 format. Because BOM will bring many problems to text processing, many software now require the use of UTF-8 files without BOM, especially some software that processes text, such as PHP, UNIX script files, etc. The same is true for svn.
Among the commonly used text editing tools, the UTF-8 format files saved in the "Save As" menu in the "Notepad" that comes with MS Windows will automatically bring the BOM. The new version of UltraEdit provides options to allow users to choose whether or not to require a BOM, while the old version will not add a BOM. Please check the documentation of your favorite editor to see if it supports this function.
For UTF-8 files with existing BOM, for example, Microsoft "Notepad" made it, we can use UltraEdit to remove the BOM. The method is to first use the "UTF-8TO ASCII" menu to convert the file to local encoding, usually GB2312 code, and then use "ASCII TO UTF-8 (UNICODE Editing)" to convert to UTF-8. Of course, before doing this, you must first ensure that the UTF-8 file saved by your UltraEdit does not have a BOM.
Why does Subversion hate BOM? I don't know, after all, I am just an ordinary user, not a developer. If you are interested and the English is good enough, you may wish to refer to this discussion: http://subversion.tigris.org/ser ... ers&msgNo=51334
————————————————
Copyright statement: This article is the original article of the CSDN blogger "Siege Lion". It follows the CC 4.0 BY-SA copyright agreement. Please attach the original source link and this statement for reprinting.
Original link: https://blog.csdn.net/dsw846169600/article/details/6745322