| 0,0 → 1,149 |
|---|
| |
| |
| SVN QUICKSTART |
| |
| [authored by Mateusz Viste, the 29th July 2023] |
| |
| |
| === INTRO ===================================================================== |
| |
| This document is aimed at people that are committing changes to the SvarDOS |
| svn repository: developers, packagers, translators... |
| |
| If you are reading this, then you probably received a write access to the |
| SvarDOS svn server at svn.svardos.org, ie. a login and password. |
| |
| Subversion isn't hugely popular these days, hence people are less and less |
| comfortable with it. But worry not - subversion is extremely straightforward! |
| |
| Here you will learn the few most basic operations that will allow you to |
| interact with svn right away. |
| |
| |
| === REPOSITORY CHECKOUT ======================================================= |
| |
| This is one time action that you need to perform so your svn client pulls the |
| current state of the SvarDOS repository to your disk. It's called a "checkout": |
| |
| svn co svn://your.username@svn.svardos.org/svardos |
| |
| This will create a "svardos" directory on your disk. All further actions will |
| be always performed from within this directory. |
| |
| |
| === PERIODIC UPDATES ========================================================== |
| |
| The repository changes with time, so you need to make sure that your local copy |
| is always up to date. To do so, you only need to execute a single command from |
| time to time. We call it an "update": |
| |
| svn up |
| |
| |
| === ADD NEW FILES OR DIRECTORIES ============================================== |
| |
| If you need to create a new subdirectory somewhere in the repo, you can either |
| ask your svn client to do it, or do it yourself and then ask your svn client to |
| track it. |
| |
| Option 1: |
| svn mkdir newdir |
| |
| Option 2: |
| mkdir newdir |
| svn add newdir |
| |
| If you creates a new file (new translation, new package, new code file...), you |
| need to tell svn about it so it starts to version it: |
| |
| svn add newfile.txt |
| |
| Once done, you should review your changes and commit them (we will talk about |
| it below). |
| |
| |
| === DELETE A FILE OR DIRECTORY ================================================ |
| |
| Deleting a file or directory via svn is as simple as this: |
| |
| svn del file_to_dele.txt |
| svn del dir_to_delete |
| |
| And of course, you need to commit the changes to apply them on the server. |
| |
| |
| === REVIEWING YOUR CHANGES BEFORE COMMIT ====================================== |
| |
| You have done some changes on your local data, and are ready to push them to |
| the server? Thath's great, but I encourage you to review your changes one last |
| time, asking svn to list them. |
| |
| 1. Display the list of changed files or directories: |
| |
| svn st |
| |
| 2. Display the difference between your local files and the server's content: |
| |
| svn diff |
| |
| |
| Both these operations will show you the state compared to the last known |
| content of the server. To make sure nothing changed on the server in the mean |
| time, you should update your local copy (svn up) beforehand. |
| |
| |
| === UNDOING (REVERTING) LOCAL CHANGES ========================================= |
| |
| You made some huge mistake and would like to erase your local changes to revert |
| back to the last known server's state? Easy: |
| |
| svn revert file_or_dir_to_revert |
| |
| It is worth mentionning that this works even if you deleted your local copy of |
| the file or dir. |
| |
| |
| === COMMIT ==================================================================== |
| |
| Finally, you made your changes, reviewed them, made sure your local files are |
| up to date, and are ready to push things to the server. Awesome. To push all |
| your changes at once, do a general commit: |
| |
| svn commit -m "short description of the changes" |
| |
| If you prefer to push your changed files in separate commits for a better |
| visibility, then that' s no problem either: |
| |
| svn commit -m "fixed bug #123" changed_file.c |
| svn commit -m "improved polish translations" pl.txt |
| svn commit -m "updated FDISK to ver 1.3.7" fdisk-1.3.7.svp fdisk-1.3.7.zip |
| |
| |
| === WHY SVN? ================================================================== |
| |
| Nowadays most project rely on git for their versioning. Many people think |
| that's because of some technical superiority of git. I think that's rather a |
| bandwagon trend. |
| |
| Of course I have nothing against git. It is a very impressive technology and an |
| outstanding solution to the specific problem it was designed for: enabling |
| collaboration of huge, unorganized teams on a complex code base while having no |
| centralized authority. But when it comes to more limited projects, it is my |
| opinion that git is an unnecessary complication that presents no added value |
| over svn, while having a number of downsides: |
| - lack of a centrally managed repository, |
| - lack of monotonically increasing revisions, |
| - non-obvious usage, |
| - poor storage of binary files, |
| - inefficient client-side storage (stores the entire history) |
| - ... |
| |
| Subversion, on the other hand, is simpler due to its centralized nature. |
| Syncing (updating) local files is both faster and leaner than with git, because |
| svn cares only about the latest available revision, it does not keep the entire |
| project's history on the client side. In a word - it's simpler, and I am always |
| in favor of technical simplicity as long as it does not come with significant |
| limitations. |
| |
| |
| ======================================================================= EOF === |