1254 |
mateusz.vi |
1 |
|
|
|
2 |
|
|
|
3 |
SVN QUICKSTART
|
|
|
4 |
|
|
|
5 |
[authored by Mateusz Viste, the 29th July 2023]
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
=== INTRO =====================================================================
|
|
|
9 |
|
|
|
10 |
This document is aimed at people that are committing changes to the SvarDOS
|
|
|
11 |
svn repository: developers, packagers, translators...
|
|
|
12 |
|
|
|
13 |
If you are reading this, then you probably received a write access to the
|
|
|
14 |
SvarDOS svn server at svn.svardos.org, ie. a login and password.
|
|
|
15 |
|
|
|
16 |
Subversion isn't hugely popular these days, hence people are less and less
|
|
|
17 |
comfortable with it. But worry not - subversion is extremely straightforward!
|
|
|
18 |
|
|
|
19 |
Here you will learn the few most basic operations that will allow you to
|
|
|
20 |
interact with svn right away.
|
|
|
21 |
|
|
|
22 |
|
|
|
23 |
=== REPOSITORY CHECKOUT =======================================================
|
|
|
24 |
|
|
|
25 |
This is one time action that you need to perform so your svn client pulls the
|
|
|
26 |
current state of the SvarDOS repository to your disk. It's called a "checkout":
|
|
|
27 |
|
|
|
28 |
svn co svn://your.username@svn.svardos.org/svardos
|
|
|
29 |
|
|
|
30 |
This will create a "svardos" directory on your disk. All further actions will
|
|
|
31 |
be always performed from within this directory.
|
|
|
32 |
|
|
|
33 |
|
|
|
34 |
=== PERIODIC UPDATES ==========================================================
|
|
|
35 |
|
|
|
36 |
The repository changes with time, so you need to make sure that your local copy
|
|
|
37 |
is always up to date. To do so, you only need to execute a single command from
|
|
|
38 |
time to time. We call it an "update":
|
|
|
39 |
|
|
|
40 |
svn up
|
|
|
41 |
|
|
|
42 |
|
|
|
43 |
=== ADD NEW FILES OR DIRECTORIES ==============================================
|
|
|
44 |
|
|
|
45 |
If you need to create a new subdirectory somewhere in the repo, you can either
|
|
|
46 |
ask your svn client to do it, or do it yourself and then ask your svn client to
|
|
|
47 |
track it.
|
|
|
48 |
|
|
|
49 |
Option 1:
|
|
|
50 |
svn mkdir newdir
|
|
|
51 |
|
|
|
52 |
Option 2:
|
|
|
53 |
mkdir newdir
|
|
|
54 |
svn add newdir
|
|
|
55 |
|
|
|
56 |
If you creates a new file (new translation, new package, new code file...), you
|
|
|
57 |
need to tell svn about it so it starts to version it:
|
|
|
58 |
|
|
|
59 |
svn add newfile.txt
|
|
|
60 |
|
|
|
61 |
Once done, you should review your changes and commit them (we will talk about
|
|
|
62 |
it below).
|
|
|
63 |
|
|
|
64 |
|
|
|
65 |
=== DELETE A FILE OR DIRECTORY ================================================
|
|
|
66 |
|
|
|
67 |
Deleting a file or directory via svn is as simple as this:
|
|
|
68 |
|
|
|
69 |
svn del file_to_dele.txt
|
|
|
70 |
svn del dir_to_delete
|
|
|
71 |
|
|
|
72 |
And of course, you need to commit the changes to apply them on the server.
|
|
|
73 |
|
|
|
74 |
|
|
|
75 |
=== REVIEWING YOUR CHANGES BEFORE COMMIT ======================================
|
|
|
76 |
|
|
|
77 |
You have done some changes on your local data, and are ready to push them to
|
|
|
78 |
the server? Thath's great, but I encourage you to review your changes one last
|
|
|
79 |
time, asking svn to list them.
|
|
|
80 |
|
|
|
81 |
1. Display the list of changed files or directories:
|
|
|
82 |
|
|
|
83 |
svn st
|
|
|
84 |
|
|
|
85 |
2. Display the difference between your local files and the server's content:
|
|
|
86 |
|
|
|
87 |
svn diff
|
|
|
88 |
|
|
|
89 |
|
|
|
90 |
Both these operations will show you the state compared to the last known
|
|
|
91 |
content of the server. To make sure nothing changed on the server in the mean
|
|
|
92 |
time, you should update your local copy (svn up) beforehand.
|
|
|
93 |
|
|
|
94 |
|
|
|
95 |
=== UNDOING (REVERTING) LOCAL CHANGES =========================================
|
|
|
96 |
|
|
|
97 |
You made some huge mistake and would like to erase your local changes to revert
|
|
|
98 |
back to the last known server's state? Easy:
|
|
|
99 |
|
|
|
100 |
svn revert file_or_dir_to_revert
|
|
|
101 |
|
|
|
102 |
It is worth mentionning that this works even if you deleted your local copy of
|
|
|
103 |
the file or dir.
|
|
|
104 |
|
|
|
105 |
|
|
|
106 |
=== COMMIT ====================================================================
|
|
|
107 |
|
|
|
108 |
Finally, you made your changes, reviewed them, made sure your local files are
|
|
|
109 |
up to date, and are ready to push things to the server. Awesome. To push all
|
|
|
110 |
your changes at once, do a general commit:
|
|
|
111 |
|
|
|
112 |
svn commit -m "short description of the changes"
|
|
|
113 |
|
|
|
114 |
If you prefer to push your changed files in separate commits for a better
|
|
|
115 |
visibility, then that' s no problem either:
|
|
|
116 |
|
|
|
117 |
svn commit -m "fixed bug #123" changed_file.c
|
|
|
118 |
svn commit -m "improved polish translations" pl.txt
|
|
|
119 |
svn commit -m "updated FDISK to ver 1.3.7" fdisk-1.3.7.svp fdisk-1.3.7.zip
|
|
|
120 |
|
|
|
121 |
|
|
|
122 |
=== WHY SVN? ==================================================================
|
|
|
123 |
|
|
|
124 |
Nowadays most project rely on git for their versioning. Many people think
|
|
|
125 |
that's because of some technical superiority of git. I think that's rather a
|
|
|
126 |
bandwagon trend.
|
|
|
127 |
|
|
|
128 |
Of course I have nothing against git. It is a very impressive technology and an
|
|
|
129 |
outstanding solution to the specific problem it was designed for: enabling
|
|
|
130 |
collaboration of huge, unorganized teams on a complex code base while having no
|
|
|
131 |
centralized authority. But when it comes to more limited projects, it is my
|
|
|
132 |
opinion that git is an unnecessary complication that presents no added value
|
|
|
133 |
over svn, while having a number of downsides:
|
|
|
134 |
- lack of a centrally managed repository,
|
|
|
135 |
- lack of monotonically increasing revisions,
|
|
|
136 |
- non-obvious usage,
|
|
|
137 |
- poor storage of binary files,
|
|
|
138 |
- inefficient client-side storage (stores the entire history)
|
|
|
139 |
- ...
|
|
|
140 |
|
|
|
141 |
Subversion, on the other hand, is simpler due to its centralized nature.
|
|
|
142 |
Syncing (updating) local files is both faster and leaner than with git, because
|
|
|
143 |
svn cares only about the latest available revision, it does not keep the entire
|
|
|
144 |
project's history on the client side. In a word - it's simpler, and I am always
|
|
|
145 |
in favor of technical simplicity as long as it does not come with significant
|
|
|
146 |
limitations.
|
|
|
147 |
|
|
|
148 |
|
|
|
149 |
======================================================================= EOF ===
|