|
|
| Line 1: |
Line 1: |
| − | You can find the updated information about contributors from [http://developer.pardus.org.tr/ here]. | + | You can find the updated information about this guide from [http://developer.pardus.org.tr/ here]. |
| − | | + | |
| − | == Pardus subversion repositories ==
| + | |
| − | The development process in Pardus is maintained via a Subversion version control system. Subversion is an open source version tracking system. Its a development infrastructure which makes it possible for more than one application developer to work together unconcerned about demolishing each others' changes. Thanks to this, any single software's development process can be tracked backwards, the changes made gradually can be watched and can be easily returned to any version of a particular time.
| + | |
| − | | + | |
| − | At the moment there are two subversion repositories we use in Pardus structure.
| + | |
| − | | + | |
| − | === Pardus repository (DEPRECATED) ===
| + | |
| − | Pardus repository is the one in which the products being developed within the project are kept. All the software developed for Pardus is kept in Pardus repository. The repository is at the address https://svn.pardus.org.tr/pardus. It keeps the source package repositories where the software's PiSi packages are found.
| + | |
| − | | + | |
| − | More information on the Pardus repository can be found in the document Pardus Depo Politikası (Pardus Repository Policy).
| + | |
| − | | + | |
| − | === Hierarchy of repository directories ===
| + | |
| − | Each Pardus subversion repository has the hierarchy of directories detailed below.
| + | |
| − | | + | |
| − | There are three main directories in a repository: trunk, tags and repos.
| + | |
| − | | + | |
| − | === trunk ===
| + | |
| − | Trunk is the directory in which continuous work is performed.
| + | |
| − | | + | |
| − | Each project module (document, Web pages, software projects, etc.) has its own directory under trunk/.
| + | |
| − | | + | |
| − | === tags ===
| + | |
| − | Tags directory is the place where, for any module, the work done under trunk is tagged and copied to. Within this directory, there exist 3 directories.
| + | |
| − | | + | |
| − | - tags/RELEASE/: This is the directory which software (or modules) use to tag their own version numbers. For example, version 0.2 of tasma is tagged in tags/RELEASE/tasma-0.2 directory.
| + | |
| − | | + | |
| − | - tags/BLACKHOLE/: Its a blackhole the projects for which the development is stopped (because of the lack of a developer to deal with it or no more need for that project) are '''thrown''' into. When the projects in it are desired to be used again, they are copied under trunk/ and worked on.
| + | |
| − | | + | |
| − | - tags/RESTRUCTURED/: Its the directory in which the module is put if the software (or module) undergoes a total restructuring and if the old files will not be used anymore. For example, '''abc''' project which was restarted to be written on 28th May 2005 is moved under tags/RESTRUCTURED/abc-2005-05-28/.
| + | |
| − | | + | |
| − | === repos ===
| + | |
| − | Repos is a directory in which developers can advance their work in an experimental nature without disturbing the other developers working on the same module under trunk. The developer can proceed her/his experimental work by creating her/his own directory under repos/.
| + | |
| − | | + | |
| − | (As a rule which is valid only for packeges repository, the documents related with this project are found under repos/doc directory.)
| + | |
| − | | + | |
| − | == Using Subversion ==
| + | |
| − | A very detailed user's manual3 is available. Besides that book, information about the project can be reached from the frequently asked questions page4 on the own Web site5 of Subversion project. In this section frequently needed commands for practical usage are tried to be told by examples.
| + | |
| − | | + | |
| − | === How do I check if I have subversion on my system? ===
| + | |
| − | As the quickest way to see if you have Subversion in your system or not, you can refer to the output of ``svn --version'' command. It's a good sign if you see something like this:
| + | |
| − | | + | |
| − | ozan@laptop:~$ svn --version
| + | |
| − | svn, version 1.5.3 (r33570)
| + | |
| − | compiled Oct 20 2008, 16:58:55
| + | |
| − | Copyright (C) 2000-2008 CollabNet.
| + | |
| − | Subversion is open source software, see http://subversion.tigris.org/
| + | |
| − | This product includes software developed by CollabNet (http://www.Collab.Net/).
| + | |
| − | The following repository access (RA) modules are available:
| + | |
| − |
| + | |
| − | * ra_neon : Module for accessing a repository via WebDAV (DeltaV) protocol using Neon.
| + | |
| − | - handles 'http' schema
| + | |
| − | - handles 'https' schema
| + | |
| − | * ra_svn : Module for accessing a repository using the svn network protocol.
| + | |
| − | - with Cyrus SASL authentication
| + | |
| − | - handles 'svn' schema
| + | |
| − | * ra_local : Module for accessing a repository on local disk.
| + | |
| − | - handles 'file' schema
| + | |
| − | ozan@laptop:~$
| + | |
| − | | + | |
| − | If it doesn't exist, from http://subversion.tigris.org/project_packages.html you can have the package prepared for your distribution or operating system and install it. To our knowledge, all of the general Linux distributions, including Pardus, has subversion (svn) packages prepackaged.
| + | |
| − | | + | |
| − | === What is a repository? ===
| + | |
| − | A repository is a disk area on which the last version, all the versions prior to the last version and the changes between versions of the software package(s) every developer works on, information including their user, date and cause are stored which can be reached by several methods.
| + | |
| − | | + | |
| − | === How can I see what directories exist in a repository? ===
| + | |
| − | A single repository may contain more than one directory in it. The hierarchy of a repository is just like the inside of a directory on a disk. So, you can browse without having to copy all the repository to your disk and just get a view of the part you want to work on or have a look at. The list of directories and files in a repository is displayed using ``svn ls repository_address'' format:
| + | |
| − | | + | |
| − | ozan@laptop ~ $ svn ls http://svn.pardus.org.tr/uludag
| + | |
| − | branches/
| + | |
| − | tags/
| + | |
| − | trunk/
| + | |
| − | ozan@laptop ~ $ svn ls http://svn.pardus.org.tr/uludag/trunk
| + | |
| − | CD-image/
| + | |
| − | PolicyKit-kde/
| + | |
| − | PyNotify/
| + | |
| − | artwork/
| + | |
| − | baselayout/
| + | |
| − | ..
| + | |
| − | ..
| + | |
| − |
| + | |
| − | ozan@laptop ~ $ svn ls http://svn.pardus.org.tr/uludag/trunk/PolicyKit-kde
| + | |
| − | CMakeLists.txt
| + | |
| − | COPYING
| + | |
| − | TODO
| + | |
| − | data/
| + | |
| − | dbus-qt3-backport/
| + | |
| − | po/
| + | |
| − | src/
| + | |
| − | | + | |
| − | === How do I get a copy of a directory in the repository? ===
| + | |
| − | In order to create a copy(checkout) of the repository '''''svn co''''' command is used. Once the copy is created, no more processing is performed on this command copy.
| + | |
| − | | + | |
| − | ozan@laptop ~ $ svn co http://svn.pardus.org.tr/uludag
| + | |
| − | A uludag/trunk
| + | |
| − | A uludag/trunk/PyNotify
| + | |
| − | A uludag/trunk/PyNotify/.project
| + | |
| − | A uludag/trunk/PyNotify/libPyNotify
| + | |
| − | A uludag/trunk/PyNotify/libPyNotify/genericDevice.py
| + | |
| − | A uludag/trunk/PyNotify/libPyNotify/genericActions.py
| + | |
| − | A uludag/trunk/PyNotify/libPyNotify/__init__.py
| + | |
| − | A uludag/trunk/PyNotify/libPyNotify/iconFinder.py
| + | |
| − | A uludag/trunk/PyNotify/icons
| + | |
| − | ..
| + | |
| − | ..
| + | |
| − | | + | |
| − | You can treat the repository as if its an URI. By doing so, you can get any subdirectory in the repository without checking out the whole repository:
| + | |
| − | | + | |
| − | ozan@laptop ~ $ svn co http://svn.pardus.org.tr/uludag/trunk/comar
| + | |
| − | A comar/belgeler
| + | |
| − | A comar/belgeler/comar-polkit.txt
| + | |
| − | A comar/belgeler/comar-python-types.txt
| + | |
| − | A comar/belgeler/PardusInitSystem.lyx
| + | |
| − | A comar/belgeler/Boot.Loader.txt
| + | |
| − | A comar/belgeler/ComarMimarisi.lyx
| + | |
| − | A comar/belgeler/comar-dbus.txt
| + | |
| − | A comar/belgeler/teknik-sunum.odp
| + | |
| − | A comar/belgeler/PardusAcilisSistemi.lyx
| + | |
| − | A comar/belgeler/temel-sunum.odp
| + | |
| − | A comar/betikler
| + | |
| − | A comar/betikler/pppoe.py
| + | |
| − | ..
| + | |
| − | ..
| + | |
| − | | + | |
| − | === How do I know if my local copy is up-to-date or not? ===
| + | |
| − | You have to update the copy of the repository you have periodically with '''''svn update''''' command in order to know about the last changes and to track the last version. If you call the command alone, all the files and the subdirectories in the current working directory will be updated recursively:
| + | |
| − | | + | |
| − | ozan@laptop trunk $ pwd
| + | |
| − | /home/ozan/pardus/uludag/trunk
| + | |
| − | ozan@laptop trunk $ svn update
| + | |
| − | G comar/mudur/bin/mudur.py
| + | |
| − | U comar/belgeler/comar-polkit.txt
| + | |
| − | A comar/belgeler/Boot.Loader.txt
| + | |
| − | U comar/comar/ChangeLog
| + | |
| − | U comar/comar/src/dbus.c
| + | |
| − | U comar/zorg/data/DriversDB
| + | |
| − | U comar/api/setup.py
| + | |
| − | A comar/api/examples/qt3
| + | |
| − | A comar/api/examples/qt3/mainform.ui
| + | |
| − | A comar/api/examples/qt3/app.py
| + | |
| − | A comar/api/examples/qt3/Makefile
| + | |
| − | A comar/api/examples/qt4
| + | |
| − | A comar/api/examples/qt4/mainform.ui
| + | |
| − | A comar/api/examples/qt4/app.py
| + | |
| − | A comar/api/examples/qt4/Makefile
| + | |
| − | U pisi/ChangeLog
| + | |
| − | ..
| + | |
| − | ..
| + | |
| − | Updated to revision 20808.
| + | |
| − | | + | |
| − | You can also append the file or the directory you want to update at the end of the command:
| + | |
| − | | + | |
| − | ozan@laptop branches $ svn update buildfarm-devel
| + | |
| − | U buildfarm-devel/templates.py
| + | |
| − | U buildfarm-devel/report.py
| + | |
| − | Updated to revision 20808.
| + | |
| − | | + | |
| − | === What does the capital letters beside the file names mean? ===
| + | |
| − | While you are working with SVN and during processes such as updating and searching, as in the previous example, the signs by the files are to inform you about what kind of a change related with the next file is performed.
| + | |
| − | | + | |
| − | One of the letters U, D, A, C or G may be found by files:
| + | |
| − | | + | |
| − | * A Added
| + | |
| − | * D Deleted
| + | |
| − | * U Updated
| + | |
| − | * G Merged (the last update you got from the repository is merged with the file you are performing local changes)
| + | |
| − | * C Conflicted (the last update you got from the repository is conflicted with the changes you performed localy)
| + | |
| − | | + | |
| − | === I modified some files, what shall I do now? ===
| + | |
| − | You can use '''''svn status''''' when you want to see the local modifications you did on a working copy. This command can run with an URI you add to the end of it as all the other commands. Below its seen that a file is added to, a file is deleted from and two files are changed regarding the last updated copy of the repository:
| + | |
| − | | + | |
| − | ozan@laptop $ svn status
| + | |
| − | A COMARd/csl/degisiklik
| + | |
| − | D COMARd/csl/loader.py
| + | |
| − | M COMARd/COMARValue.py
| + | |
| − | M comar-call/rpc.c
| + | |
| − |
| + | |
| − | ozan@laptop $ svn status COMARd/csl/COMARValue.py
| + | |
| − | M COMARd/COMARValue.py
| + | |
| − | ozan@laptop $
| + | |
| − | | + | |
| − | Also, you can learn what you particularly changed in changed files with '''''svn diff''''' command:
| + | |
| − | | + | |
| − | ozan@laptop $ svn diff comar-call/rpc.c
| + | |
| − | Index: comar-call/rpc.c
| + | |
| − | ===================================================================
| + | |
| − | --- comar-call/rpc.c (revision 158)
| + | |
| − | +++ comar-call/rpc.c (working copy)
| + | |
| − | @@ -146,6 +146,7 @@
| + | |
| − | if (len == 0) break;
| + | |
| − | if (len == -1) {
| + | |
| − | puts("connection broken too soon");
| + | |
| − | + //totally different change
| + | |
| − | break;
| + | |
| − | }
| + | |
| − | printf("RECV[%s]\n\n", buf);
| + | |
| − | ozan@laptop $
| + | |
| − | | + | |
| − | === I added a new file but there's a ''question mark'' beside it! ===
| + | |
| − | While you are working on the copy of the repository when you would like to create a new file, you should inform your local copy about your intention to add that file to the repository with the help of '''''svn add''''' (it has sister commands such as '''''svn copy''''', '''''svn del''''' as well). Let's explain why there's such a need as follows: Let's assume that you would like to compile and test an application which is in your local copy. In this case, some files that you don't prefer to send to the main repository will be created in your work copy such as Makefiles and *.m4 files which only you have any need for. In such cases, it will be very advantageous and convenient if the files added locally are not added to the repository as well, because when you change the source code of the software, recompile it and decide to send it to the repository at a proper time, you know that the other files are not going to the repository. With '''''svn add''''', you add to the repository the files you want to add. '''''svn del''''' will not mentioned again.
| + | |
| − | | + | |
| − | ozan@laptop $ svn status
| + | |
| − | ozan@laptop $ touch newscript.csl
| + | |
| − | ozan@laptop $ svn status
| + | |
| − | ? newscript.csl
| + | |
| − | ozan@laptop $ svn add newscript.csl
| + | |
| − | A newscript.csl
| + | |
| − | ozan@laptop $ svn status
| + | |
| − | A newscript.csl
| + | |
| − | ozan@laptop $
| + | |
| − | | + | |
| − | === How do I revert my local modifications? ===
| + | |
| − | You can revert the modifications you made using '''''svn revert''''' command anytime you like:
| + | |
| − | | + | |
| − | ozan@laptop $ svn status
| + | |
| − | A COMARd/csl/thechange
| + | |
| − | D COMARd/csl/loader.py
| + | |
| − | M COMARd/COMARValue.py
| + | |
| − | M comar-call/rpc.c
| + | |
| − |
| + | |
| − | ozan@laptop $ svn revert comar-call/rpc.c
| + | |
| − | Reverted 'comar-call/rpc.c'
| + | |
| − |
| + | |
| − | ozan@laptop $ svn status
| + | |
| − | A COMARd/csl/thechange
| + | |
| − | D COMARd/csl/loader.py
| + | |
| − | M COMARd/COMARValue.py
| + | |
| − |
| + | |
| − | ozan@laptop $
| + | |
| − | | + | |
| − | Its also possible to revert all of the files to their original state recursively:
| + | |
| − | | + | |
| − | ozan@laptop $ svn revert . -R
| + | |
| − | Reverted 'COMARd/csl/thechange'
| + | |
| − | Reverted 'COMARd/csl/loader.py'
| + | |
| − | Reverted 'COMARd/COMARValue.py'
| + | |
| − |
| + | |
| − | ozan@laptop $ svn status
| + | |
| − | ozan@laptop $
| + | |
| − | | + | |
| − | ===I want to send the files I modified ===
| + | |
| − | If you are sure of the last condition of the files you changed, you can use '''''svn commit''''' to transmit your changes to the repository. By using this command -as its true for all the rest- you can send to the repository a single file, a single directory and what is under it or all the changes you made. When you run '''''svn commit''''', svn -using your preferred text editor- opens a file for you with the changes you made listed in it in order to make sure others see what you changed and to enable your changes to be logged for backward tracking in the repository. To alter the text editor opened as the preferred one, you can make use of the environment variable EDITOR:
| + | |
| − | | + | |
| − | ozan@laptop $ EDITOR="vi" svn commit
| + | |
| − | ozan@laptop $ EDITOR="mcedit" svn commit
| + | |
| − | ozan@laptop $ EDITOR="kwrite" svn commit
| + | |
| − | | + | |
| − | As soon as you write the changes to the text editor, save what you wrote and close the editor, svn will commit the modifications in your local copy to the remote repository.
| + | |
| − | | + | |
| − | ===Other commands ===
| + | |
| − | You can run Subversion to learn Subversion commands as well. '''''svn help command_name''''' feeds you back with detailed information about command_name while '''''svn help''''' serves you with a list of commands you can use:
| + | |
| − | | + | |
| − | ozan@laptop branches $ svn help
| + | |
| − | usage: svn <subcommand> [options] [args]
| + | |
| − | Subversion command-line client, version 1.5.3.
| + | |
| − | Type 'svn help <subcommand>' for help on a specific subcommand.
| + | |
| − | Type 'svn --version' to see the program version and RA modules
| + | |
| − | or 'svn --version --quiet' to see just the version number.
| + | |
| − |
| + | |
| − | Most subcommands take file and/or directory arguments, recursing
| + | |
| − | on the directories. If no arguments are supplied to such a
| + | |
| − | command, it recurses on the current directory (inclusive) by default.
| + | |
| − |
| + | |
| − | Available subcommands:
| + | |
| − | add
| + | |
| − | blame (praise, annotate, ann)
| + | |
| − | cat
| + | |
| − | changelist (cl)
| + | |
| − | checkout (co)
| + | |
| − | cleanup
| + | |
| − | commit (ci)
| + | |
| − | copy (cp)
| + | |
| − | delete (del, remove, rm)
| + | |
| − | diff (di)
| + | |
| − | export
| + | |
| − | help (?, h)
| + | |
| − | import
| + | |
| − | info
| + | |
| − | list (ls)
| + | |
| − | lock
| + | |
| − | log
| + | |
| − | merge
| + | |
| − | mergeinfo
| + | |
| − | mkdir
| + | |
| − | move (mv, rename, ren)
| + | |
| − | propdel (pdel, pd)
| + | |
| − | propedit (pedit, pe)
| + | |
| − | propget (pget, pg)
| + | |
| − | proplist (plist, pl)
| + | |
| − | propset (pset, ps)
| + | |
| − | resolve
| + | |
| − | resolved
| + | |
| − | revert
| + | |
| − | status (stat, st)
| + | |
| − | switch (sw)
| + | |
| − | unlock
| + | |
| − | update (up)
| + | |
| − |
| + | |
| − | Subversion is a tool for version control.
| + | |
| − | For additional information, see http://subversion.tigris.org/
| + | |
| − | ozan@laptop branches $
| + | |
| − | | + | |
| − | In order to have detailed information about a Subversion command, call '''''svn help''''' with the command name:
| + | |
| − | | + | |
| − | ozan@laptop branches $ svn help add
| + | |
| − | add: Put files and directories under version control, scheduling
| + | |
| − | them for addition to repository. They will be added in next commit.
| + | |
| − | usage: add PATH...
| + | |
| − |
| + | |
| − | Valid options:
| + | |
| − | --targets ARG : pass contents of file ARG as additional args
| + | |
| − | -N [--non-recursive] : obsolete; try --depth=files or --depth=immediates
| + | |
| − | --depth ARG : limit operation by depth ARG ('empty', 'files',
| + | |
| − | 'immediates', or 'infinity')
| + | |
| − | -q [--quiet] : print nothing, or only summary information
| + | |
| − | --force : force operation to run
| + | |
| − | --no-ignore : disregard default and svn:ignore property ignores
| + | |
| − | --auto-props : enable automatic properties
| + | |
| − | --no-auto-props : disable automatic properties
| + | |
| − | --parents : add intermediate parents
| + | |
| − |
| + | |
| − | Global options:
| + | |
| − | --username ARG : specify a username ARG
| + | |
| − | --password ARG : specify a password ARG
| + | |
| − | --no-auth-cache : do not cache authentication tokens
| + | |
| − | --non-interactive : do no interactive prompting
| + | |
| − | --config-dir ARG : read user configuration files from directory ARG
| + | |
| − | | + | |
| − | == Rules for a correct Subversion usage ==
| + | |
| − | Subversion repository is a common place shared by all developers. In order to work together developers should be using the repository efficiently, properly and in an organized way.
| + | |
| − | | + | |
| − | Rules for using Subversion are the rules to be respected by the developers having the privilege to write to Pardus repositories.
| + | |
| − | | + | |
| − | === Always work with an up-to-date local copy ===
| + | |
| − | The updates on the Subversion repository will be more frequent as the quantity of the developers increase. In order to know about the rest of the process and to avoid a conflict between what you do and the rest to be done, before you begin to work, always update your repository by means of svn update command.
| + | |
| − | | + | |
| − | === Think before you commit ===
| + | |
| − | Think twice before you commit the modifications you made, to the Subversion repository. The data you commit to the repository will reach to all developers and affect their work. In this sense, its of great importance to follow the articles below:
| + | |
| − | | + | |
| − | '''1. Do not commit a non-running code to the Subversion repository,'''
| + | |
| − | | + | |
| − | '''2. Always update your repository before you commit by means of svn update in order to get the last changes. Be sure that the changes you made do not conflict with the others,'''
| + | |
| − | | + | |
| − | '''3. Pay attention to what you commit. To make sure of this, always control the changes you are about to commit by means of svn diff command before commitment,'''
| + | |
| − | | + | |
| − | '''4. Always test the changes you made. Even better, test them twice.'''
| + | |
| − | | + | |
| − | === Write descriptive commit log messages ===
| + | |
| − | Explanation messages used in the commit logs should focus on the modification and be as descriptive as possible. As much as you can, try to add explanation messages related with only the files you made changes on. However, in the limits of the context, you can include all the information which can not be derived from the output of a svn diff command in your explanation message.
| + | |
| − | | + | |
| − | Refraining from adding a proper explanation message will make it difficult to understand the changes you made.
| + | |
| − | | + | |
| − | === Abide by the work plans ===
| + | |
| − | If a work/time plan exists for the distribution in general or if the main developer of the component you are working on sets such a plan, abide by this plan regarding your commitments.
| + | |
| − | | + | |
| − | For example, an application developer might want to stop adding new features to the application at a particular time and might want to work on fixing the known issues. Its expected that the change you make is coherent with this rule.
| + | |
| − | | + | |
| − | If you are not sure of the coherency of the change you made with the plan, you have to refer the related e-mail lists or the main developer.
| + | |
| − | | + | |
| − | === Changes affecting other components ===
| + | |
| − | If you made a change affecting more than one component, inform all developers about the change.
| + | |
| − | In order to ensure all developers know about the ``major'' update you made, always send an informative message to the related e-mail list.
| + | |
| − | | + | |
| − | === Take responsibility for the changes you made ===
| + | |
| − | If the update you made is creating a problem, take the responsibility of it and make sure to solve it yourself or by getting help.
| + | |
| − | | + | |
| − | === Respect the generally accepted principles ===
| + | |
| − | Obey the general rules accepted during developers' discussions and be sure that your changes are not violating those rules. In any case you are unsure you can always choose the ``communication'' path.
| + | |
| − | | + | |
| − | === Enter the bug number when solving a bug from the bug tracking system ===
| + | |
| − | If the update you make is solving a reported bug, in order to synchronize the bug tracking system with the updates in the repository, notify the bug you solved and close the bug in the bug tracking system afterwards.
| + | |
| − | | + | |
| − | === Update the files for which you are responsible ===
| + | |
| − | Update only the files which are in your responsibility. If you find a bug in files which is in another developer's responsibility, first, discuss the situation either by directly contacting the responsible developer or by asking the other developers in e-mail lists and only after doing so make an attemp to update the repository. If the responsible developer does not accept the changes you made, behave respectfully.
| + | |
| − | | + | |
| − | === Do not add the automatically created files to the repository ===
| + | |
| − | Do not add the files such as Makefile, Makefile.in, configure scripts, etc. which are created afterwards by compilation tools. These files will be recreated in different forms in all developers' machines and will be perceived as an update by the other develepors. In general, adding these files to the repository is perceived as a bug.
| + | |
| − | | + | |
| − | === Perform atomic updates ===
| + | |
| − | Commit all the modifications related to a particular improvement/update at once. Subversion lets you commit more than one file at a time. Other developers might be confused because of seperate commits and they can miss the improvements you made.
| + | |
