Subversion Repositories SvarDOS

Rev

Rev 1255 | Details | Compare with Previous | Last modification | View Log | RSS feed

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