TortoiseSVN runs on Windows Vista or higher and is available in both 32-bit and 64-bit flavours. The installer for 64-bit Windows also includes the 32-bit extension parts. Which means you don't need to install the 32-bit version separately to get the TortoiseSVN context menu and overlays in 32-bit applications.

Support for Windows 98, Windows ME and Windows NT4 was dropped in version 1.2.0, and Windows 2000 and XP up to SP2 support was dropped in 1.7.0. Support for Windows XP with SP3 was dropped in 1.9.0. You can still download and install older versions if you need them.

TortoiseSVN hadir dengan instalatur yang mudah digunakan. Klik ganda pada file instalatur dan ikuti petunjuknya. Instalatur akan mengurus sisanya. Jangan lupa untuk reboot setelah instalasi.

Paket bahasa tersedia sesuai terjemahan antarmuka pengguna TortoiseSVN ke dalam berbagai bahasa. Silahkan periksa Lampiran G, Language Packs and Spell Checkers untuk informasi lebih lanjut tentang cara memasang ini.

If you encounter any problems during or after installing TortoiseSVN please refer to our online FAQ at https://tortoisesvn.net/faq.html.

For a real project you will have a repository set up somewhere safe and a Subversion server to control it. For the purposes of this tutorial we are going to use Subversion's local repository feature which allows direct access to a repository created on your hard drive without needing a server at all.

First create a new empty directory on your PC. It can go anywhere, but in this tutorial we are going to call it C:\svn_repos. Now right click on the new folder and from the context menu choose TortoiseSVN → Create Repository here.... The repository is then created inside the folder, ready for you to use. We will also create the default internal folder structure by clicking the Create folder structure button.

Now we have a repository, but it is completely empty at the moment. Let's assume I have a set of files in C:\Projects\Widget1 that I would like to add. Navigate to the Widget1 folder in Explorer and right click on it. Now select TortoiseSVN → Import... which brings up a dialog

Gambar 1.2. Dialog Impor

A Subversion repository is referred to by URL, which allows us to specify a repository anywhere on the Internet. In this case we need to point to our own local repository which has a URL of file:///c:/svn_repos/trunk, and to which we add our own project name Widget1. Note that there are 3 slashes after file: and that forward slashes are used throughout.

The other important feature of this dialog is the Import Message box which allows you to enter a message describing what you are doing. When you come to look through your project history, these commit messages are a valuable guide to what changes have been made and why. In this case we can say something simple like “Import the Widget1 project”. Click on OK and the folder is added to your repository.

Now that we have a project in our repository, we need to create a working copy to use for day-to-day work. Note that the act of importing a folder does not automatically turn that folder into a working copy. The Subversion term for creating a fresh working copy is Checkout. We are going to checkout the Widget1 folder of our repository into a development folder on the PC called C:\Projects\Widget1-Dev. Create that folder, then right click on it and select TortoiseSVN → Checkout.... Then enter the URL to checkout, in this case file:///c:/svn_repos/trunk/Widget1 and click on OK. Our development folder is then populated with files from the repository.

You will notice that the appearance of this folder is different from our original folder. Every file has a green check mark in the bottom left corner. These are TortoiseSVN's status icons which are only present in a working copy. The green state indicates that the file is unchanged from the version in the repository.

Time to get to work. In the Widget1-Dev folder we start editing files - let's say we make changes to Widget1.c and ReadMe.txt. Notice that the icon overlays on these files have now changed to red, indicating that changes have been made locally.

But what are the changes? Right click on one of the changed files and select TortoiseSVN → Diff. TortoiseSVN's file compare tool starts, showing you exactly which lines have changed.

Gambar 1.3. File Difference Viewer

OK, so we are happy with the changes, let's update the repository. This action is referred to as a Commit of the changes. Right click on the Widget1-Dev folder and select TortoiseSVN → Commit. The commit dialog lists the changed files, each with a checkbox. You might want to choose only a subset of those files, but in this case we are going to commit the changes to both files. Enter up a message to describe what the change is all about and click on OK. The progress dialog shows the files being uploaded to the repository and you're done.

As the project develops you will need to add new files - let's say you add some new features in Extras.c and add a reference in the existing Makefile. Right click on the folder and TortoiseSVN → Add. The Add dialog now shows you all unversioned files and you can select which ones you want to add. Another way of adding files would be to right click on the file itself and select TortoiseSVN → Add.

Now when you go to commit the folder, the new file shows up as Added and the existing file as Modified. Note that you can double click on the modified file to check exactly what changes were made.

One of the most useful features of TortoiseSVN is the Log dialog. This shows you a list of all the commits you made to a file or folder, and shows those detailed commit messages that you entered (you did enter a commit message as suggested? If not, now you see why this is important).

Gambar 1.4. The Log Dialog

OK, so I cheated a little here and used a screenshot from the TortoiseSVN repository.

The top pane shows a list of revisions committed along with the start of the commit message. If you select one of these revisions, the middle pane will show the full log message for that revision and the bottom pane will show a list of changed files and folders.

Each of these panes has a context menu which provides you with lots more ways of using the information. In the bottom pane you can double click on a file to see exactly what changes were made in that revision. Read bagian bernama “Dialog Log Revisi” to get the full story.

One feature of all revision control systems is that they let you undo changes that you made previously. As you would expect, TortoiseSVN makes this easy to access.

If you want to get rid of changes that you have not yet committed and reset your file to the way it was before you started editing, TortoiseSVN → Revert is your friend. This discards your changes (to the Recycle bin, just in case) and reverts to the committed version you started with. If you want to get rid of just some of the changes, you can use TortoiseMerge to view the differences and selectively revert changed lines.

If you want to undo the effects of a particular revision, start with the Log dialog and find the offending revision. Select Context Menu → Revert changes from this revision and those changes will be undone.

Pertimbangkan skenario ini: anggap kami mempunyai dua teman kerja, Harry dan Sally. Mereka masing-masing memutuskan untuk mengedit file pada repositori yang sama pada saat yang sama. Jika Harry menyimpan ke repositori lebih dulu, lalu mungkin saja (beberapa waktu kemudian) Sally bisa menimpanya dengan file tulisan versi barunya sendiri secara tidak sengaja. Sementara versi file Harry tidak akan hilang selamanya (karena sistem mengingat setiap perubahan), setiap perubahan yang dibuat Harry tidak akan ada dalam versi file terbaru Sally, karena ia tidak pernah melihat perubahan Harry untuk dimulainya. Pekerjaan Harry masih secara efektif hilang - atau setidaknya hilang dari versi file terbaru dan mungkin karena kecelakaan. Ini betul-betul situasi yang ingin kami hindari!

Gambar 2.2. Masalah yang Dihindari

Many version control systems use a lock-modify-unlock model to address this problem, which is a very simple solution. In such a system, the repository allows only one person to change a file at a time. First Harry must lock the file before he can begin making changes to it. Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then Sally cannot make any changes to it. If she tries to lock the file, the repository will deny the request. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, his turn is over, and now Sally can take her turn by locking and editing.

Gambar 2.3. Solusi Kunci-Ubah-Buka Kunci

Masalah dengan model kunci-ubah-buka kunci adalah bahwa itu sedikit membatasi, dan sering menjadi halangan bagi pengguna:

Subversion, CVS, and other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client reads the repository and creates a personal working copy of the file or project. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.

Here's an example. Say that Harry and Sally each create working copies of the same project, copied from the repository. They work concurrently, and make changes to the same file A within their copies. Sally saves her changes to the repository first. When Harry attempts to save his changes later, the repository informs him that his file A is out-of-date. In other words, that file A in the repository has somehow changed since he last copied it. So Harry asks his client to merge any new changes from the repository into his working copy of file A. Chances are that Sally's changes don't overlap with his own; so once he has both sets of changes integrated, he saves his working copy back to the repository.

Gambar 2.4. Solusi Copy-Ubah-Gabung

Gambar 2.5. ...Copy-Ubah-Gabung Lanjutan

Tapi bagaimana jika perubahan-perubahan Sally benar-benar bertumpukan dengan perubahan-perubahan Harry? Lalu apa? Situasi ini disebut konflik, dan biasanya tidak begitu bermasalah. Ketika Harry meminta kliennya untuk menggabung perubahan repositori terbaru ke dalam copy pekerjaannya, copy file A miliknya ditandai sebagai dalam keadaan konflik: dia akan bisa melihat kedua set dari perubahan-perubahan yang konflik, dan memilih diantaranya secara manual. Perlu dicatat bahwa perangkat lunak tidak bisa menyelesaikan konflik secara otomatis; hanya manusia yang mampu mengerti dan membuat pilihan-pilihan pintar yang diperlukan. Sekali Harry sudah menyelesaikan perubahan yang saling tindih secara manual (mungkin dengan mendiskusikannya bersama Sally!), dia bisa menyimpan file gabungan dengan aman kembali ke repositori.

Model copy-ubah-gabung mungkin terdengar sedikit kacau, tapi dalam prakteknya, ia berjalan dengan sangat baik. Para pengguna bisa bekerja secara paralel, tidak pernah menunggu yang lain. Saat mereka bekerja pada file yang sama, tampak bahwa kebanyakan perubahan-perubahan konkuren mereka tidak tumpang tindih sama sekali; konflik jarang terjadi. Dan jumlah waktu untuk menyelesaikan konflik jauh lebih sedikit daripada jumlah waktu yang hilang oleh suatu sistem penguncian.

Akhirnya, itu semua berujung pada satu faktor kritis: komunikasi pengguna. Ketika para pengguna berkomunikasi dengan buruk, konflik-konflik baik sintatik maupun semantik meningkat. Tidak ada sistem yang memaksa pengguna untuk berkomunikasi dengan sempurna, dan tidak ada sistem yang dapat mendeteksi konflik semantik. Jadi tidak ada gunanya untuk mencegah konflik; dalam praktek, penguncian nampak untuk menghambat produktivitas lebih dari pada yang lain.

There is one common situation where the lock-modify-unlock model comes out better, and that is where you have unmergeable files. For example if your repository contains some graphic images, and two people change the image at the same time, there is no way for those changes to be merged together. Either Harry or Sally will lose their changes.

Subversion menggunakan solusi copy-ubah-gabung secara bawaan, dan dalam banyak kasus ini adalah semua yang akan Anda perlukan. Akan tetapi, sejak Versi 1.2, Subversion juga mendukung penguncian file. Jadi jika Anda mempunyai file yang tidak bisa digabung, atau jika Anda dipaksa menggunakan kebijakan penguncian oleh manajemen, Subversion akan masih menyediakan fitur yang Anda butuhkan.

Anda sudah membaca tentang copy pekerjaan; sekarang kami akan mendemonstrasikan bagaimana klien Subversion membuat dan menggunakannya.

Copy pekerjaan Subversion adalah susunan direktori biasa pada sistem lokal Anda, dan berisi koleksi file. Anda bisa mengedit file-file ini sesuka Anda, dan jika ada file kode sumber, Anda bisa mengompilasi program Anda darinya seperti biasa. Copy pekerjaan Anda adalah area kerja pribadi Anda sendiri: Subversion tidak akan pernah menyatukan perubahan orang lain, maupun membuat perubahan Anda sendiri tersedia bagi yang lain, sampai Anda memberitahukan secara eksplisit untuk melakukannya.

After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to publish your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working directory (by reading from the repository).

A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, your working copy contains a subdirectory named .svn, also known as the working copy administrative directory . The files in this administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work. Prior to 1.7 Subversion maintained .svn administrative subdirectories in every versioned directory of your working copy. Subversion 1.7 takes a completely different approach and each working copy now has only one administrative subdirectory which is an immediate child of the root of that working copy.

Suatu repositori Subversion umum sering menampung file (atau kode sumber) untuk beberapa proyek; biasanya, setiap proyek adalah subdirektori dalam susunan sistem file repositori. Dalam pengaturan ini, copy pekerjaan pengguna akan terhubung ke subpohon tertentu dari repositori.

Sebagai contoh, anggap Anda mempunyai repositori yang berisi dua proyek software.

Gambar 2.6. Sistem File Repositori

Dengan kata lain, akar direktori repositori mempunyai dua subdirektori: gambar dan hitung.

To get a working copy, you must check out some subtree of the repository. (The term check out may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.)

Suppose you make changes to button.c. Since the .svn directory remembers the file's modification date and original contents, Subversion can tell that you've changed the file. However, Subversion does not make your changes public until you explicitly tell it to. The act of publishing your changes is more commonly known as committing (or checking in ) changes to the repository.

Untuk menerbitkan perubahan Anda bagi yang lain, Anda bisa menggunakan perintah Subversion komit.

Sekarang perubahan Anda ke button.c sudah dikomit ke repositori; jika pengguna lain melakukan check out copy pekerjaan dari /hitung, mereka akan melihat perubahan Anda dalam file versi terbaru.

Anggap Anda mempunyai kolaborator, Sally, yang melakukan check out copy pekerjaan /hitung pada saat yang sama seperti yang Anda lakukan. Ketika Anda mengkomit perubahan Anda ke button.c, copy pekerjaan Sally dibiarkan tidak berubah; Subversion hanya mengubah copy pekerjaan atas permintaan pengguna.

Agar proyeknya mutahir, Sally bisa meminta Subversion untuk memutahirkan copy pekerjaannya, dengan menggunakan perintah Subversion mutahirkan. Ini akan menyertakan perubahan Anda ke dalam copy pekerjaannya, juga bagi perubahan-perubahan lain yang telah dikomit sejak Sally melakukan check out.

Catatan bahwa Sally tidak perlu untuk menetapkan file yang mana yang dimutahirkan; Subversion menggunakan informasi dalam direktori .svn, dan informasi lebih lanjut dalam repositori, untuk memutuskan file yang perlu dimutahirkan.

Repositori Subversion bisa diakses melalui banyak metode berbeda - pada diska lokal, atau melalui berbagai protokol jaringan. Lokasi repositori, bagaimanapun juga, selalu URL. Skema URL menunjukan metode akses:

For the most part, Subversion's URLs use the standard syntax, allowing for server names and port numbers to be specified as part of the URL. The file:// access method is normally used for local access, although it can be used with UNC paths to a networked host. The URL therefore takes the form file://hostname/path/to/repos. For the local machine, the hostname portion of the URL is required to be either absent or localhost. For this reason, local paths normally appear with three slashes, file:///path/to/repos.

Also, users of the file:// scheme on Windows platforms will need to use an unofficially “standard” syntax for accessing repositories that are on the same machine, but on a different drive than the client's current working drive. Either of the two following URL path syntaxes will work where X is the drive on which the repository resides:

file:///X:/path/to/repos
...
file:///X|/path/to/repos
...
      

Perlu dicatat bahwa URL menggunakan garis miring biasa meskipun bentuk asli (non-URL) suatu path pada Windows menggunakan garis miring terbalik.

You can access a FSFS repository via a network share, but this is not recommended for various reasons:

A svn commit operation can publish changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents, create, delete, rename and copy files and directories, and then commit the complete set of changes as a unit.

In the repository, each commit is treated as an atomic transaction: either all the commits changes take place, or none of them take place. Subversion retains this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.

Setiap kali repositori menerima komit, ia membuat kondisi baru pada susunan sistem file, disebut revisi. Setiap revisi ditempati angka alami unik, satu lebih besar dari jumlah revisi sebelumnya. Revisi awal dari repositori yang baru dibuat diberi angka nol, dan tidak terdiri dari apapun tapi direktori akar kosong.

Cara yang baik untuk memvisualisasikan repositori adalah sebagai satu seri pohon-pohon. Bayangkan jajaran dari angka revisi, dimulai dari 0, terentang dari kiri ke kanan. Setiap angka revisi mempunyai pohon sistem file bergantung dibawahnya, dan setiap pohon merupakan “potret” dari cara repositori terlihat setelah setiap komit.

Gambar 2.7. Repositori

Penting untuk dicatat bahwa copy pekerjaan tidak selalu sesuai dengan setiap revisi tunggal dalam repositori; mereka bisa berisi file dari beberapa revisi. Sebagai contoh, anggaplah Anda melakukan check out copy pekerjaan dari repositori di mana revisi paling baru ialah 4:

calc/Makefile:4
integer.c:4
button.c:4
      

Sampai saat ini, direktori pekerjaan ini tepat sesuai terhadap revisi 4 dalam repositori. Tetapi, anggap Anda membuat perubahan pada button.c, dan mengkomit perubahan itu. Dengan menganggap tidak ada yang lain telah mengkomit, komit Anda akan membuat revisi 5 dari repositori, dan copy pekerjaan Anda sekarang akan terlihat seperti ini:

calc/Makefile:4
integer.c:4
button.c:5
      

Anggap bahwa pada titik ini Sally mengkomit perubahan integer.c yang menyebabkan pembuatan revisi 6. Jika Anda menggunakan svn update untuk menjadikan copy pekerjaan Anda mutahir, maka ia akan terlihat seperti ini:

calc/Makefile:6
integer.c:6
button.c:6
      

Perubahan Sally pada integer.c akan terlihat dalam copy pekerjaan Anda, dan perubahan Anda masih akan ada dalam button.c. Dalam contoh ini, teks Makefile sama persis dalam revisi 4, 5, dan 6, tapi Subversion akan menandai copy pekerjaan Anda untuk Makefile dengan revisi 6 untuk menunjukan bahwa ia masih saat ini. Maka, setelah Anda melakukan pemutahiran bersih pada puncak dari copy pekerjaan Anda, ia umumnya akan merujuk ke tepat satu revisi dalam repositori.

Untuk setiap file dalam direktori pekerjaan, Subversion merekam dua bagian esensial dari informasi dalam area administratif .svn/:

Melalui informasi ini, dengan menghubungi repositori, Subversion bisa memberitahu suatu file pekerjaan dalam keadaan apa dari empat keadaan berikut:

Sekarang Anda sudah mendapatkan repositori baru ditempatkan di D:\SVN\MyNewRepository.

Untuk mengakses repositori lokal Anda memerlukan path ke folder itu. Ingatlah bahwa Subversion mengharapkan semua path repositori dalam bentuk file:///C:/SVNRepository/. Perlu dicatat penggunaan dari garis miring maju.

Untuk mengakses repositori yang ditempatkan pada jaringan berbagi Anda bisa menggunakan pemetaan drive, atau Anda bisa menggunakan path UNC. Untuk path UNC, bentuknya adalah file://ServerName/path/to/repos/. Catatan bahwa hanya ada 2 garis miring didepannya disini.

Sebelum SVN 1.2, path UNC harus diberikan dalam bentuk lebih kabur file:///\ServerName/path/to/repos. Bentuk ini masih didukung, tapi tidak direkomendasikan.

Although in theory it is possible to put a FSFS repository on a network share and have multiple users access it using file:// protocol, this is most definitely not recommended. In fact we would strongly discourage it, and do not support such use for various reasons:

file:// access is intended for local, single-user access only, particularly testing and debugging. When you want to share the repository you really need to set up a proper server, and it is not nearly as difficult as you might think. Read bagian bernama “Akses ke Repositori” for guidelines on choosing and setting up a server.

Sebelum Anda mengimpor data Anda ke dalam repositori, pertama Anda harus memikirkan tentang bagaimana Anda ingin mengatur data Anda. Jika Anda menggunakan salah satu tata letak yang direkomendasikan nantinya akan lebih mudah.

There are some standard, recommended ways to organize a repository. Most people create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies. If a repository holds only one project, then often people create these top-level directories:

/trunk
/branches
/tags
    

Because this layout is so commonly used, when you create a new repository using TortoiseSVN, it will also offer to create the directory structure for you.

Jika repositori berisi multipel proyek, orang sering mengindeks tata letaknya dengan cabang:

/trunk/paint
/trunk/calc
/branches/paint
/branches/calc
/tags/paint
/tags/calc
    

...atau dengan proyek:

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags
    

Mengindeks dengan proyek masuk akal jika proyek tidak terkait erat dengan salah satu yang di-check out secara individu. Untuk proyek terkait dimana Anda mungkin ingin melakukan check out semua proyek dalam sekali jalan, atau dimana proyek adalah terkait semua dalam satu paket distribusi, sering lebih baik untuk diindeks dengan cabang. Dengan cara ini Anda hanya mempunyai satu trunk untuk di-checkout, dan hubungan antara sub-proyek nampak lebih mudah.

Jika Anda mengadopsi pendekatan tingkat atas /trunk /tags /branches, Anda harus mengcopy seluruh trunk untuk setiap cabang dan tag, dan dalam beberapa cara struktur ini menawarkan fleksibilitas terbanyak.

Untuk proyek tidak terkait Anda mungkin lebih ingin menggunakan repositori terpisah. Ketika Anda mengkomit perubahan, angka revisi dari seluruh repositori yang berubah, bukan angka revisi proyek. Mempunyai 2 proyek tidak terkait berbagi repositori bisa membuat ruang besar dalam angka revisi. Proyek Subversion dan TortoiseSVN nampak di alamat host yang sama, tapi sebenarnya memisahkan sepenuhnya repositori yang membolehkan pengembangan independen, dan tidak ada kebingungan pada angka pembuatan.

Tentu saja, Anda bebas untuk mengabaikan tata letak umum ini. Anda bisa membuat variasi apapun, apa saja yang bekerja terbaik bagi Anda atau tim Anda. Ingat bahwa apapun pilihan Anda, itu bukan komitmen permanen. Anda bisa mengatur ulang repositori Anda kapan saja. Karena cabang dan tag sebenarnya direktori, TortoiseSVN bisa memindahkan atau mengganti namanya sesuai yang Anda inginkan.

Menukar dari satu tata letak ke lainnya hanyalah masalah menerbitkan seri perpindahan dari sisi-server; Jika Anda tidak menyukai cara kerja yang diatur dalam repositori, aturlah kembali direktori.

So if you haven't already created a basic folder structure inside your repository you should do that now. There are two ways to achieve this. If you simply want to create a /trunk /tags /branches structure, you can use the repository browser to create the three folders (in three separate commits). If you want to create a deeper hierarchy then it is simpler to create a folder structure on disk first and import it in a single commit, like this:

Note that the name of the folder you are importing does not appear in the repository, only its contents. For example, create the following folder structure:

C:\Temp\New\trunk
C:\Temp\New\branches
C:\Temp\New\tags
      

Import C:\Temp\New into the repository root, which will then look like this:

/trunk
/branches
/tags
      

Gambar 4.1. Explorer menampilkan lapisan ikon

Salah satu fitur yang paling terlihat dari TortoiseSVN adalah lapisan ikon yang muncul pada file dalam copy pekerjaan Anda. Ini memperlihatkan kepada Anda sekilas file mana yang sudah dimodifikasi. Lihat bagian bernama “Lapisan Ikon” untuk mengetahui apa yang diwakili oleh lapisan yang berbeda.

Gambar 4.2. Menu konteks untuk direktori dibawah kontrol versi

Semua perintah TortoiseSVN dijalankan dari menu konteks dari windows explorer. Kebanyakan terlihat secara langsung, ketika Anda mengklik kanan pada file atau folder. Perintah yang tersedia tergantung pada apakah file atau folder atau folder leluhurnya dibawah kontrol versi atau tidak. Anda juga bisa melihat menu TortoiseSVN sebagai bagian dari menu file Explorer.

Dalam beberapa kasus Anda mungkin melihat beberapa entri TortoiseSVN. Ini bukan bug!

Gambar 4.3. Menu file Explorer untuk jalan pintas dalam folder berversi

Contoh ini adalah untuk jalan pintas tidak berversi di dalam folder berversi, dan dalam menu file Explorer ada tiga entri untuk TortoiseSVN. Satu untuk folder, satu untuk jalan pintas sendiri, dan ketiga untuk obyek yang dirujuk jalan pintas. Untuk membantu Anda membedakannya, ikon mempunyai indikator di pojok kanan dibawahnya untuk memperlihatkan apakah entri menu untuk file, folder, jalan pintas atau item multipel yang dipilih.

Gambar 4.4. Menu drag kanan untuk direktori dibawah kontrol versi

Perintah lain yang tersedia sebgagi pengendali drag, ketika Anda men-drag kanan file atau folder ke lokasi baru di dalam copy pekerjaan atau ketika Anda men-drag kanan file atau folder tidak-berversi ke dalam direktori yang dibawah kontrol versi.

Some common operations have well-known Windows shortcuts, but do not appear on buttons or in menus. If you can't work out how to do something obvious, like refreshing a view, check here.

If the repository that you are trying to access is password protected, an authentication Dialog will show up.

Gambar 4.5. Dialog Otentikasi

Enter your username and password. The checkbox will make TortoiseSVN store the credentials in Subversion's default directory: %APPDATA%\Subversion\auth in three subdirectories:

If you want to clear the authentication cache, you can do so from the Saved Data page of TortoiseSVN's settings dialog. The button Clear all will clear the cached authentication data for all repositories. The button Clear... however will show a dialog where you can chose which cached authentication data should be deleted. Refer to bagian bernama “Seting Data Tersimpan”.

Some people like to have the authentication data deleted when they log off Windows, or on shutdown. The way to do that is to use a shutdown script to delete the %APPDATA%\Subversion\auth directory, e.g.

@echo off
rmdir /s /q "%APPDATA%\Subversion\auth"
      

You can find a description of how to install such scripts at http://www.windows-help-central.com/windows-shutdown-script.html.

For more information on how to set up your server for authentication and access control, refer to bagian bernama “Akses ke Repositori”.

Many of TortoiseSVN's dialogs have a lot of information to display, but it is often useful to maximize only the height, or only the width, rather than maximizing to fill the screen. As a convenience, there are shortcuts for this on the Maximize button. Use the middle mouse button to maximize vertically, and right mouse to maximize horizontally.

If you are importing into an existing repository which already contains some projects, then the repository structure will already have been decided. If you are importing data into a new repository, then it is worth taking the time to think about how it will be organised. Read bagian bernama “Tata Letak Repositori” for further advice.

This section describes the Subversion import command, which was designed for importing a directory hierarchy into the repository in one shot. Although it does the job, it has several shortcomings:

For these reasons we recommend that you do not use the import command at all but rather follow the two-step method described in bagian bernama “Impor di tempat”, unless you are performing the simple step of creating an initial /trunk /tags /branches structure in your repository. Since you are here, this is how the basic import works ...

Sebelum Anda mengimpor proyek Anda ke dalam repositori Anda harus:

Sekarang pilih folder tingkat-atas dari struktur direktori proyek Anda dalam windows explorer dan klik kanan untuk membuka menu konteks. Pilih perintah TortoiseSVN → Impor... yang membawa kotak dialog:

Gambar 4.6. Dialog Impor

In this dialog you have to enter the URL of the repository location where you want to import your project. It is very important to realise that the local folder you are importing does not itself appear in the repository, only its content. For example if you have a structure:

C:\Projects\Widget\source
C:\Projects\Widget\doc
C:\Projects\Widget\images
      

and you import C:\Projects\Widget into http://mydomain.com/svn/trunk then you may be surprised to find that your subdirectories go straight into trunk rather than being in a Widget subdirectory. You need to specify the subdirectory as part of the URL, http://mydomain.com/svn/trunk/Widget-X. Note that the import command will automatically create subdirectories within the repository if they do not exist.

Pesan impor digunakan sebagai pesan log.

Secara bawaan, file dan folder yang sama dengan pola abaikan-global tidak diimpor. Untuk menimpa perlaku ini Anda bisa menggunakan kotak centang Sertakan file diabaikan. Lihat bagian bernama “Seting Umum” untuk informasi lebih jauh pada menyeting pola abaikan global.

As soon as you press OK TortoiseSVN imports the complete directory tree including all files into the repository. The project is now stored in the repository under version control. Please note that the folder you imported is NOT under version control! To get a version-controlled working copy you need to do a Checkout of the version you just imported. Or read on to find out how to import a folder in place.

Dengan berasumsi bahwa Anda sudah memiliki sebuah repositori, dan Anda ingin menambahkan sebuah struktur folder baru ke dalamnya, cukup ikuti langkah-langkah berikut:

Ada kalanya Anda perlu mempunyai file dibawah kontrol versi yang berisi data pengguna tertentu. Itu berarti Anda mempunyai file yang perlu dimodifikasi oleh setiap pengembang/pengguna untuk memenuhi setup lokalnya. Tapi memversi file demikian sulit karena setiap pengguna akan mengkomit perubahannya setiap kali ke repositori.

In such cases we suggest to use template files. You create a file which contains all the data your developers will need, add that file to version control and let the developers check this file out. Then, each developer has to make a copy of that file and rename that copy. After that, modifying the copy is not a problem anymore.

As an example, you can have a look at TortoiseSVN's build script. It calls a file named default.build.user which doesn't exist in the repository. Only the file default.build.user.tmpl. default.build.user.tmpl is the template file which every developer has to create a copy from and rename that file to default.build.user. Inside that file, we added comments so that the users will see which lines they have to edit and change according to their local setup to get it working.

So as not to disturb the users, we also added the file default.build.user to the ignore list of its parent folder, i.e. we've set the Subversion property svn:ignore to include that filename. That way it won't show up as unversioned on every commit.

You can choose the depth you want to checkout, which allows you to specify the depth of recursion into child folders. If you want just a few sections of a large tree, You can checkout the top level folder only, then update selected folders recursively.

To easily select only the items you want for the checkout and force the resulting working copy to keep only those items, click the Choose items... button. This opens a new dialog where you can check all items you want in your working copy and uncheck all the items you don't want. The resulting working copy is then known as a sparse checkout. An update of such a working copy will not fetch the missing files and folders but only update what you already have in your working copy.

If you check out a sparse working copy (i.e., by choosing something other than fully recursive for the checkout depth), you can easily add or remove sub-folders later using one of the following methods.

This feature is very useful when you only want to checkout parts of a large tree, but you want the convenience of updating a single working copy. Suppose you have a large tree which has sub-folders Project01 to Project99, and you only want to checkout Project03, Project25 and Project76/SubProj. Use these steps:

Jika copy pekerjaan Anda mutahir dan di sana tidak ada konflik, Anda siap untuk mengkomit perubahan Anda. Pilih file/folder mana saja yang ingin Anda komit, lalu TortoiseSVN → Komit....

Gambar 4.8. Dialog Komit

Dialog komit akan memperlihatkan kepada Anda setiap file yang diubah, termasuk yang ditambahkan, dihapus dan file tidak berversi. Jika Anda tidak ingin file yang diubah dikomit, cukup jangan centang file itu. Jika Anda ingin menyertakan file tidak berversi, centang file itu untuk ditambahkan ke komit.

To quickly check or uncheck types of files like all versioned files or all modified files, click the link items just above the list of shown items.

For information on the coloring and overlays of the items according to their status, please see bagian bernama “Status Lokal dan Remote”.

Item-item yang sudah ditukar ke path repositori yang berbeda juga ditunjukan menggunakan tanda (s). Anda mungkin telah menukar sesuatu sementara bekerja pada cabang dan lupa untuk menukarnya kembali ke trunk. Ini adalah tanda peringatan Anda!

Double clicking on any modified file in the commit dialog will launch the external diff tool to show your changes. The context menu will give you more options, as shown in the screenshot. You can also drag files from here into another application such as a text editor or an IDE.

You can select or deselect items by clicking on the checkbox to the left of the item. For directories you can use Shift-select to make the action recursive.

Kolom yang ditampilkan di pane bawah bisa diatur sesuai kesukaan Anda. Jika Anda mengklik kanan pada header kolom apa saja, Anda akan melihat suatu menu konteks yang membolehkan Anda untuk memilih kolom mana yang ditampilkan. Anda juga bisa mengubah panjang kolom dengan menggunakan kendali drag yang muncul ketika Anda memindahkan mouse melalui batas kolom. Kustomisasi ini tersimpan sehingga Anda akan melihat heading yang sama nantinya.

By default when you commit changes, any locks that you hold on files are released automatically after the commit succeeds. If you want to keep those locks, make sure the Keep locks checkbox is checked. The default state of this checkbox is taken from the no_unlock option in the Subversion configuration file. Read bagian bernama “Seting Umum” for information on how to edit the Subversion configuration file.

The commit dialog supports Subversion's changelist feature to help with grouping related files together. Find out about this feature in bagian bernama “Daftar Perubahan”.

Sometimes you want to only commit parts of the changes you made to a file. Such a situation usually happens when you're working on something but then an urgent fix needs to be committed, and that fix happens to be in the same file you're working on.

right click on the file and use Context Menu → Restore after commit. This will create a copy of the file as it is. Then you can edit the file, e.g. in a text editor and undo all the changes you don't want to commit. After saving those changes you can commit the file.

After the commit is done, the copy of the file is restored automatically, and you have the file with all your modifications that were not committed back.

Sometimes you have versioned files that change frequently but that you really don't want to commit. Sometimes this indicates a flaw in your build process - why are those files versioned? should you be using template files? But occasionally it is inevitable. A classic reason is that your IDE changes a timestamp in the project file every time you build. The project file has to be versioned as it includes all the build settings, but it doesn't need to be committed just because the timestamp changed.

To help out in awkward cases like this, we have reserved a changelist called ignore-on-commit. Any file added to this changelist will automatically be unchecked in the commit dialog. You can still commit changes, but you have to select it manually in the commit dialog.

Pastikan untuk memasukkan log pesan yang menjelaskan perubahan yang Anda komit. Ini akan membantu Anda untuk melihat apa yang terjadi dan kapan saat Anda melihat pesan log proyek pada lain waktu. Pesan bisa sepanjang atau sesingkat yang Anda inginkan; banyak proyek mempunyai petunjuk untuk apa yang seharusnya disertakan, bahasa yang digunakan, dan ada kalanya bahkan format ketat.

Anda bisa menyediakan format sederhana ke log pesan Anda menggunakan konvensi mirip ke yang digunakan di dalam email. Untuk menerapkan ke teks, gunakan *text* untuk tebal, _text_ untuk garis bawah, dan ^text^ untuk miring.

Gambar 4.9. Pemeriksa Ejaan Dialog Komit

TortoiseSVN menyertakan pemeriksa ejaan untuk membantu Anda mendapatkan log pesan yang benar. Ini akan menerangi setiap kata yang salah eja. Gunakan menu konteks untuk mengakses koreksi yang disarankan. Tentu saja, ia tidak mengetahui setiap istilah teknis yang Anda ketahui sehingga ejaan kata yang benar akan tetap muncul sebagai kesalahan. Tapi jangan khawatir. Anda bisa menambahkannya ke kamus pribadi Anda menggunakan menu konteks.

The log message window also includes a filename and function auto-completion facility. This uses regular expressions to extract class and function names from the (text) files you are committing, as well as the filenames themselves. If a word you are typing matches anything in the list (after you have typed at least 3 characters, or pressed Ctrl+Space), a drop-down appears allowing you to select the full name. The regular expressions supplied with TortoiseSVN are held in the TortoiseSVN installation bin folder. You can also define your own regexes and store them in %APPDATA%\TortoiseSVN\autolist.txt. Of course your private autolist will not be overwritten when you update your installation of TortoiseSVN. If you are unfamiliar with regular expressions, take a look at the introduction at https://en.wikipedia.org/wiki/Regular_expression, and the online documentation and tutorial at http://www.regular-expressions.info/.

Getting the regex just right can be tricky, so to help you sort out a suitable expression there is a test dialog which allows you to enter an expression and then type in filenames to test it against. Start it from the command prompt using the command TortoiseProc.exe /command:autotexttest.

The log message window also includes a commit message snippet facility. These snippets are shown in the autocomplete dropdown once you type a snippet shortcut, and selecting the snippet in the autocomplete dropdown then inserts the full text of the snippet. The snippets supplied with TortoiseSVN are held in the TortoiseSVN installation bin folder. You can also define your own snippets and store them in %APPDATA%\TortoiseSVN\snippet.txt. # is the comment character. Newlines can be inserted by escaping them like this: \n and \r. To insert a backslash, escape it like this: \\.

You can re-use previously entered log messages. Just click on Recent messages to view a list of the last few messages you entered for this working copy. The number of stored messages can be customized in the TortoiseSVN settings dialog.

You can clear all stored commit messages from the Saved data page of TortoiseSVN's settings, or you can clear individual messages from within the Recent messages dialog using the Delete key.

If you want to include the checked paths in your log message, you can use the command Context Menu → Paste filename list in the edit control.

Another way to insert the paths into the log message is to simply drag the files from the file list onto the edit control.

Setelah menekan OK, dialog muncul menampilkan progres dari komit.

Gambar 4.10. Dialog Progres menampilkan komit dalam proses

Dialog progres menggunakan kode warna untuk menerangi tindakan komit yang berbeda

Ini adalah skema warna standar, tapi Anda bisa mengkustomisasi warna menggunakan dialog seting. Baca bagian bernama “Seting Warna TortoiseSVN” untuk informasi lengkap.

A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. The conflicting area in a text file is marked like this:

<<<<<<< filename
your changes
=======
code merged from repository
>>>>>>> revision
      

Also, for every conflicted file Subversion places three additional files in your directory:

You can either launch an external merge tool / conflict editor with TortoiseSVN → Edit Conflicts or you can use any text editor to resolve the conflict manually. You should decide what the code should look like, do the necessary changes and save the file. Using a merge tool such as TortoiseMerge or one of the other popular tools is generally the easier option as they generally present the files involved in a 3-pane view and you don't have to worry about the conflict markers. If you do use a text editor then you should search for lines starting with the string <<<<<<<.

Selanjutnya jalankan perintah TortoiseSVN → Diselesaikan dan komit modifikasi Anda ke repositori. Harap dicatat bahwa perintah Selesaikan tidak benar-benar menyelesaikan konflik. Ia hanya menghapus file filename.ext.mine dan filename.ext.r*, untuk membolehkan Anda mengkomit perubahan Anda.

Jika Anda mempunyai konflik dengan file biner, Subversion tidak mencoba untuk menggabung file itu sendiri. File lokal tetap tidak diubah (persis seperti perubahan terakhir Anda) dan Anda mempunyai file filename.ext.r*. Jika Anda ingin mengabaikan perubahan Anda dan membiarkan versi repositori, cukup gunakan perintah Pulihkan. Jika Anda ingin memelihara versi Anda dan menimpa versi repositori, gunakan perintah Diselesaikan, lalu komit versi Anda.

Anda bisa menggunakan perintah Diselesaikan untuk multipel file jika Anda mengklik kanan pada folder leluhur dan memilih TortoiseSVN → Diselesaikan... Ini akan memunculkan dialog yang mendaftarkan semua file yang konflik dalam folder itu, dan Anda bisa memilih yang mana untuk ditandai sebagai diselesaikan.

A property conflict occurs when two or more developers have changed the same property. As with file content, resolving the conflict can only be done by the developers.

If one of the changes must override the other then choose the option to Resolve using local property or Resolve using remote property. If the changes must be merged then select Manually edit property, sort out what the property value should be and mark as resolved.

A tree conflict occurs when a developer moved/renamed/deleted a file or folder, which another developer either also has moved/renamed/deleted or just modified. There are many different situations that can result in a tree conflict, and all of them require different steps to resolve the conflict.

When a file is deleted locally in Subversion, the file is also deleted from the local file system, so even if it is part of a tree conflict it cannot show a conflicted overlay and you cannot right click on it to resolve the conflict. Use the Check for Modifications dialog instead to access the Edit conflicts option.

TortoiseSVN bisa membantu untuk mencari tempat yang benar untuk menggabungkan perubahan perubahan, tetapi pekerjaan tambahan mungkin diperlukan untung menyelesaikan konflik. Ingat, setelah pembaruan (an update), dasar kerjanya akan selalu mengandung revisi untuk setiap hal seperti didalam repositori di saat pembaruan. Jika anda mengembalikan perubahan setelah mempembarukan, itu akan mengembalikan ke keadaan repositori, bukan kembali ke keadaan disaat anda memulai mengubah lokal copy anda.

Gambar 4.12. Explorer menampilkan lapisan ikon

Sekarang bahwa Anda sudah melakukan check out copy pekerjaan dari repositori Subversion Anda bisa melihat file dalam windows explorer dengan ikon yang diubah. Ini adalah salah satu alasan mengapa TortoiseSVN sangat populer. TortoiseSVN menambahkan apa yang disebut lapisan ikon ke setiap file yang menimpa ikon file aslinya. Lapisan ikon berbeda tergantung pada status Subversion terhadap file.

A fresh checked out working copy has a green checkmark as overlay. That means the Subversion status is normal.

As soon as you start editing a file, the status changes to modified and the icon overlay then changes to a red exclamation mark. That way you can easily see which files were changed since you last updated your working copy and need to be committed.

If during an update a conflict occurs then the icon changes to a yellow exclamation mark.

If you have set the svn:needs-lock property on a file, Subversion makes that file read-only until you get a lock on that file. Such files have this overlay to indicate that you have to get a lock first before you can edit that file.

If you hold a lock on a file, and the Subversion status is normal, this icon overlay reminds you that you should release the lock if you are not using it to allow others to commit their changes to the file.

This icon shows you that some files or folders inside the current folder have been scheduled to be deleted from version control or a file under version control is missing in a folder.

The plus sign tells you that a file or folder has been scheduled to be added to version control.

The bar sign tells you that a file or folder is ignored for version control purposes. This overlay is optional.

Icon ini menunjukan file file dan folder folder yang tidak di dalam versi kontrol, tetapi tidak di abaikan. Overlay ini adalah opsional.

In fact, you may find that not all of these icons are used on your system. This is because the number of overlays allowed by Windows is very limited and if you are also using an old version of TortoiseCVS, then there are not enough overlay slots available. TortoiseSVN tries to be a “Good Citizen (TM)” and limits its use of overlays to give other apps a chance too.

Now that there are more Tortoise clients around (TortoiseCVS, TortoiseHg, ...) the icon limit becomes a real problem. To work around this, the TortoiseSVN project introduced a common shared icon set, loaded as a DLL, which can be used by all Tortoise clients. Check with your client provider to see if this has been integrated yet :-)

For a description of how icon overlays correspond to Subversion status and other technical details, read bagian bernama “Lapisan Ikon”.

Gambar 4.13. Halaman properti Explorer, tab Subversion

Ada kalanya Anda ingin mempunyai informasi terinci tentang file/direktori daripada hanya lapisan ikon. Anda bisa mendapatkan semua informasi yang disediakan Subversion dalam dialog properti explorer. Pilih file atau direktori dan pilih Menu Windows → properti dalam menu konteks (catatan: ini properti normal entri menu yang disediakan explorer, bukan yang ada dalam submenu TortoiseSVN!). Dalam kotak dialog properti sudah ditambahkan halaman properti baru untuk file/folder dibawah kontrol Subversion, dimana Anda bisa melihat semua informasi relevan tenang file/direktori yang dipilih.

Gambar 4.14. Periksa Modifikasi

Ini sangat berguna untuk mengetahui file mana yang telah Anda ubah dan juga file yang diubah dan dikomit orang lain. Itulah dimana perintah TortoiseSVN → Periksa Modifikasi... akan berguna. Dialog ini akan memperlihatkan kepada Anda setiap file yang diubah dengan cara apapun dalam copy pekerjaan Anda, juga file tidak berversi yang mungkin Anda miliki.

If you click on the Check Repository then you can also look for changes in the repository. That way you can check before an update if there's a possible conflict. You can also update selected files from the repository without updating the whole folder. By default, the Check Repository button only fetches the remote status with the checkout depth of the working copy. If you want to see all files and folders in the repository, even those you have not checked out, then you have to hold down the Shift key when you click on the Check Repository button.

Dialog menggunakan kode warna untuk menerangi status.

Ini adalah skema warna standar, tapi Anda bisa mengkustomisasi warna menggunakan dialog seting. Baca bagian bernama “Seting Warna TortoiseSVN” untuk informasi lengkap.

Overlay icons are used to indicate other states as well. The screenshot below shows all the possible overlays that are shown if necessary.

Overlays are shown for the following states:

Items which have been switched to a different repository path are also indicated using an (s) marker. You may have switched something while working on a branch and forgotten to switch back to trunk. This is your warning sign! The context menu allows you to switch them back to the normal path again.

Dari menu konteks pada dialog Anda bisa menampilkan diff dari perubahan. Periksalah perubahan lokal yang sudah Anda buat dengan menggunakan Menu Konteks → Bandingkan dengan Base. Periksa perubahan dalam repositori yang dibuat orang lain dengan menggunakan Menu Konteks → Tampilkan Perbedaan sebagai Unified Diff.

You can also revert changes in individual files. If you have deleted a file accidentally, it will show up as Missing and you can use Revert to recover it.

File tidak berversi dan abaikan bisa dikirimkan ke recycle bin dari sini menggunakan Menu Konteks → Hapus. Jika Anda ingin menghapus file secara permanen (melewati recycle bin) tekan tombol Shift sementara mengklik Hapus.

If you want to examine a file in detail, you can drag it from here into another application such as a text editor or IDE, or you can save a copy simply by dragging it into a folder in explorer.

Kolom-kolom dapat disesuaikan dengan kebutuhan Anda. Jika Anda mengklik kanan pada setiap judul kolom, Anda akan melihat menu konteks yang membolehkan Anda untuk memilih kolom mana yang ditampilkan. Anda juga bisa mengubah panjang kolom dengan menggunakan kendali drag yang muncul ketika Anda memindahkan mouse melalui batas kolom. Kustomisasi ini tersimpan sehingga Anda akan melihat heading yang sama nantinya.

Jika Anda bekerja pada beberapa tugas yang tidak berhubungan sekaligus, Anda juga dapat mengelompokkan file-file menjadi satu dalam daftar perubahan. Baca bagian bernama “Daftar Perubahan” untuk informasi lanjut.

At the bottom of the dialog you can see a summary of the range of repository revisions in use in your working copy. These are the commit revisions, not the update revisions; they represent the range of revisions where these files were last committed, not the revisions to which they have been updated. Note that the revision range shown applies only to the items displayed, not to the entire working copy. If you want to see that information for the whole working copy you must check the Show unmodified files checkbox.

Seringkali Anda ingin melihat ke dalam file Anda, untuk melihat apa yang sudah Anda ubah. Anda bisa melaksanakan ini dengan memilih file yang sudah diubah dan memilih Diff dari menu konteks TortoiseSVN. Ini memulai peninjau-diff eksternal, yang akan membandingkan file saat ini dengan copy murni (revisi BASE), yang disimpan setelah checkout atau pemutahiran terakhir.

Gambar 4.18. Dialog Log Revisi

Ada beberapa tempat dari dimana Anda bisa menampilkan dialog Log:

Apabila repositori tidak tersedia anda akan melihat dialog Apakah anda ingin offline?, seperti pada bagian bernama “Offline Mode”.

The top pane has an Actions column containing icons that summarize what has been done in that revision. There are four different icons, each shown in its own column.

If a revision modified a file or directory, the modified icon is shown in the first column.

If a revision added a file or directory, the added icon is shown in the second column.

If a revision deleted a file or directory, the deleted icon is shown in the third column.

If a revision replaced a file or directory, the replaced icon is shown in the fourth column.

If a revision moved or renamed a file or directory, the moved icon is shown in the fourth column.

If a revision replaced a file or directory by moving/renaming it, the move replaced icon is shown in the fourth column.

If a revision merged a file or directory, the merged icon is shown in the fourth column.

If a revision reverse merged a file or directory, the reverse merged icon is shown in the fourth column.

Gambar 4.19. Pane Atas Dialog Log Revisi dengan Menu Konteks

The top pane of the Log dialog has a context menu that allows you to access much more information. Some of these menu entries appear only when the log is shown for a file, and some only when the log is shown for a folder.

Gambar 4.20. The Code Collaborator Settings Dialog

Gambar 4.21. Menu Konteks Pane Atas untuk 2 Revisi yang Dipilih

Jika Anda memilih dua revisi sekaligus (menggunakan Ctrl-modifier biasa), menu konteks berubah dan memberikan opsi lebih sedikit:

If you select two or more revisions (using the usual Ctrl or Shift modifiers), the context menu will include an entry to Revert all changes which were made in the selected revisions. This is the easiest way to rollback a group of revisions in one go.

You can also choose to merge the selected revisions to another working copy, as described above.

If all selected revisions have the same author, you can edit the author of all those revisions in one go.

Gambar 4.22. Pane Bawah Dialog Log dengan Menu Konteks

The bottom pane of the Log dialog also has a context menu that allows you to

When multiple files are selected in the bottom pane of the Log dialog, the context menu changes to the following:

Gambar 4.23. The Log Dialog Bottom Pane with Context Menu When Multiple Files Selected.

Dialog Log tidak selalu menampilkan semua perubahan yang dibuat untuk sejumlah alasan:

Jika Anda ingin melihat log pesan lebih, klik 100 Berikutnya untuk mengambil 100 pesan log berikutnya. Anda bisa mengulang ini sebanyak yang Anda butuhkan.

Disebelah tombol ini ada tombol multi-fungsi yang mengingat opsi terakhir yang Anda gunakan. Klik pada panah untuk melihat opsi lain yang ditawarkan.

Gunakan Tampilkan Jangkauan ... jika Anda ingin meninjau jangkauan revisi tertentu. Dialog akan meminta Anda untuk memasukan awal dan akhir revisi.

Gunakan Tampilkan Semua jika Anda ingin melihat semua pesan log dari HEAD kembali ke revisi 1.

To refresh the latest revision in case there were other commits while the log dialog was open, hit the F5 key.

To refresh the log cache, hit the Ctrl-F5 keys.

Because the log dialog shows you the log from HEAD, not from the current working copy revision, it often happens that there are log messages shown for content which has not yet been updated in your working copy. To help make this clearer, the commit message which corresponds to the revision you have in your working copy is shown in bold.

When you show the log for a folder the revision highlighted is the highest revision found anywhere within that folder, which requires a crawl of the working copy. The crawl takes place within a separate thread so as not to delay showing the log, but as a result highlighting for folders may not appear immediately.

Subversion 1.5 and later keeps a record of merges using properties. This allows us to get a more detailed history of merged changes. For example, if you develop a new feature on a branch and then merge that branch back to trunk, the feature development will show up on the trunk log as a single commit for the merge, even though there may have been 1000 commits during branch development.

Gambar 4.24. The Log Dialog Showing Merge Tracking Revisions

If you want to see the detail of which revisions were merged as part of that commit, use the Include merged revisions checkbox. This will fetch the log messages again, but will also interleave the log messages from revisions which were merged. Merged revisions are shown in grey because they represent changes made on a different part of the tree.

Of course, merging is never simple! During feature development on the branch there will probably be occasional merges back from trunk to keep the branch in sync with the main line code. So the merge history of the branch will also include another layer of merge history. These different layers are shown in the log dialog using indentation levels.

Revision properties are completely different from the Subversion properties of each item. Revprops are descriptive items which are associated with one specific revision number in the repository, such as log message, commit date and committer name (author).

Ada kalanya Anda mungkin ingin mengubah pesan log yang pernah Anda masukan, mungkin karena ada kesalahan ejaan didalamnya atau Anda ingin meningkatkan pesan atau mengubahnya untuk alasan lain. Atau Anda ingin mengubah pembuat dari komit karena Anda lupa untuk menyiapkan otentikasi atau ...

Subversion lets you change revision properties any time you want. But since such changes can't be undone (those changes are not versioned) this feature is disabled by default. To make this work, you must set up a pre-revprop-change hook. Please refer to the chapter on Hook Scripts in the Subversion Book for details about how to do that. Read bagian bernama “Server side hook scripts” to find some further notes on implementing hooks on a Windows machine.

Once you've set up your server with the required hooks, you can change the author and log message (or any other revprop) of any revision, using the context menu from the top pane of the Log dialog. You can also edit a log message using the context menu for the middle pane.

Jika Anda ingin membatasi pesan log untuk ditampilkan hanya yang menarik bagi Anda daripada menggulung melalui daftar ratusan, Anda bisa menggunakan kontrol filter di atas dari Dialog Log. Kontrol awal dan akhir tanggal membolehkan Anda untuk membatasi output ke jangkauan tanggal yang diketahui. Kotak pencarian membolehkan Anda untuk menampilkan hanya pesan yang berisi frase tertentu.

Click on the search icon to select which information you want to search in, and to choose regex mode. Normally you will only need a simple sub-string search, but if you need to more flexible search terms, you can use regular expressions. If you hover the mouse over the box, a tooltip will give hints on how to use the regex functions, or the sub-string functions. The filter works by checking whether your filter string matches the log entries, and then only those entries which match the filter string are shown.

Simple sub-string search works in a manner similar to a search engine. Strings to search for are separated by spaces, and all strings must match. You can use a leading - to specify that a particular sub-string is not found (invert matching for that term), and you can use ! at the start of the expression to invert matching for the entire expression. You can use a leading + to specify that a sub-string should be included, even if previously excluded with a -. Note that the order of inclusion/exclusion is significant here. You can use quote marks to surround a string which must contain spaces, and if you want to search for a literal quotation mark you can use two quotation marks together as a self-escaping sequence. Note that the backslash character is not used as an escape character and has no special significance in simple sub-string searches. Examples will make this easier:

Alice Bob -Eve
      

searches for strings containing both Alice and Bob but not Eve

Alice -Bob +Eve
      

searches for strings containing both Alice but not Bob, or strings which contain Eve.

-Case +SpecialCase
      

searches for strings which do not contain Case, but still include strings which contain SpecialCase.

!Alice Bob
      

searches for strings which do not contain both Alice and Bob

!-Alice -Bob
      

do you remember De Morgan's theorem? NOT(NOT Alice AND NOT Bob) reduces to (Alice OR Bob).

"Alice and Bob"
      

searches for the literal expression “Alice and Bob”

""
      

searches for a double-quote anywhere in the text

"Alice says ""hi"" to Bob"
      

searches for the literal expression “Alice says "hi" to Bob”.

Describing the use of regular expression searches is beyond the scope of this manual, but you can find online documentation and a tutorial at http://www.regular-expressions.info/.

Catatan bahwa filter ini bertindak pada pesan yang sudah diterima. Mereka tidak mengontrol pengambilan pesan dari repositori.

You can also filter the path names in the bottom pane using the Show only affected paths checkbox. Affected paths are those which contain the path used to display the log. If you fetch the log for a folder, that means anything in that folder or below it. For a file it means just that one file. Normally the path list shows any other paths which are affected by the same commit, but in grey. If the box is checked, those paths are hidden.

Sometimes your working practices will require log messages to follow a particular format, which means that the text describing the changes is not visible in the abbreviated summary shown in the top pane. The property tsvn:logsummary can be used to extract a portion of the log message to be shown in the top pane. Read bagian bernama “TortoiseSVN Project Properties” to find out how to use this property.

Tombol Statistik memunculkan kotak yang menampilkan beberapa informasi menarik tentang revisi yang ditampikan dalam dialog Log. Ini menampilkan berapa banyak pembuat sudah bekerja, berapa banyak komit yang telah dibuat, kemajuan dengan minggu, dan masih banyak lagi. Sekarang Anda bisa melihat sekaligus siap yang sudah bekerja paling keras dan siapa yang malas ;-)

Halaman Komit per Pembuat

Gambar 4.25. Histogram Komit-per-Pembuat

Grafik ini memperlihatkan kepada Anda pembuat yang aktif pada proyek sebagai histogram sederhana, histogram bertumpuk atau pie chart.

Gambar 4.26. Pie Chart Komit-per-Pembuat

Where there are a few major authors and many minor contributors, the number of tiny segments can make the graph more difficult to read. The slider at the bottom allows you to set a threshold (as a percentage of total commits) below which any activity is grouped into an Others category.

Halaman Komit menurut Tanggal

Gambar 4.27. Grafik Komit-Menurut-Tanggal

Halaman ini memberikan gambaran grafis dari aktivitas proyek dalam batasan jumlah komit dan pembuat. Ini memberikan ide kapan proyek dikerjakan, dan siapa yang mengerjakannya pada waktu kapan.

Ketika ada beberapa pembuat, Anda akan mendapatkan banyak baris pada grafik. Ada dua tampilan tersedia disini: normal, dimana setiap aktivitas pembuat relatif ke baris base, dan ditumpuk, dimana aktivitas pembuat relatif ke baris dibawahnya. Opsi terakhir menghindari baris saling silang, yang bisa membuat grafik mudah untuk dibaca, tapi kurang mudah bagi satu output pembuat.

By default the analysis is case-sensitive, so users PeterEgan and PeteRegan are treated as different authors. However, in many cases user names are not case-sensitive, and are sometimes entered inconsistently, so you may want DavidMorgan and davidmorgan to be treated as the same person. Use the Authors case insensitive checkbox to control how this is handled.

Catatan bahwa statistik mencakup periode yang sama dengan dialog Log. Jika itu hanya menampilkan satu revisi maka statistik tidak akan memberitahu lebih banyak.

Gambar 4.28. Go Offline Dialog

If the server is not reachable, and you have log caching enabled you can use the log dialog and revision graph in offline mode. This uses data from the cache, which allows you to continue working although the information may not be up-to-date or even complete.

Here you have three options:

The Make this the default checkbox prevents this dialog from re-appearing and always picks the option you choose next. You can still change (or remove) the default after doing this from TortoiseSVN → Settings.

If you want to check the server again for newer log messages, you can simply refresh the view using F5. If you are using the log cache (enabled by default), this will check the repository for newer messages and fetch only the new ones. If the log cache was in offline mode, this will also attempt to go back online.

If you are using the log cache and you think the message content or author may have changed, you can use Shift-F5 or Ctrl-F5 to re-fetch the displayed messages from the server and update the log cache. Note that this only affects messages currently shown and does not invalidate the entire cache for that repository.

If you have configured a third party diff tool, you can use Shift when selecting the Diff command to use the alternate tool. Read bagian bernama “Seting Program Eksternal” to find out about configuring other diff tools.

Sometimes in the life of a project you might change the line endings from CRLF to LF, or you may change the indentation of a section. Unfortunately this will mark a large number of lines as changed, even though there is no change to the meaning of the code. The options here will help to manage these changes when it comes to comparing and applying differences. You will see these settings in the Merge and Blame dialogs, as well as in the settings for TortoiseMerge.

Ignore line endings excludes changes which are due solely to difference in line-end style.

Compare whitespaces includes all changes in indentation and inline whitespace as added/removed lines.

Ignore whitespace changes excludes changes which are due solely to a change in the amount or type of whitespace, e.g. changing the indentation or changing tabs to spaces. Adding whitespace where there was none before, or removing a whitespace completely is still shown as a change.

Ignore all whitespaces excludes all whitespace-only changes.

Naturally, any line with changed content is always included in the diff.

Gambar 4.29. Dialog Pembandingan Revisi-Revisi

Ketika Anda memilih dua susunan dalam browser repositori, atau ketika Anda memilih dua revisi dari sebuah folder dalam dialog, Anda bisa Menu konteks → Bandingkan revisi.

Dialog ini memperlihatkan daftar dari semua file yang sudah diubah dan membolehkan Anda untuk membandingkan atau blame secara individu menggunakan menu konteks.

You can export a change tree, which is useful if you need to send someone else your project tree structure, but containing only the files which have changed. This operation works on the selected files only, so you need to select the files of interest - usually that means all of them - and then Context menu → Export selection to.... You will be prompted for a location to save the change tree.

You can also export the list of changed files to a text file using Context menu → Save list of selected files to....

If you want to export the list of files and the actions (modified, added, deleted) as well, you can do that using Context menu → Copy selection to clipboard.

Tombol di atas membolehkan Anda untuk mengubah arah dari perbandingan. Anda bisa menampilkan perubahan yang diperlukan dari A ke B, atau jika diinginkan, dari B ke A.

Tombol-tombol yang berisi nomor revisi dapat digunakan untuk mengubah suatu rentang revisi yang berbeda. Jika Anda memilih rentang tersebut, daftar hal-hal yang berbeda diantara kedua revisi akan dimutahirkan secara otomatis.

If the list of filenames is very long, you can use the search box to reduce the list to filenames containing specific text. Note that a simple text search is used, so if you want to restrict the list to C source files you should enter .c rather than *.c.

Ada banyak piranti tersedia untuk melakukan diff file teks, termasuk TortoiseMerge itu sendiri, tapi kami sering menemukan keinginan untuk melihat bagaimana file gambar diubah juga. Itulah mengapa kami membuat TortoiseIDiff.

Gambar 4.30. Peninjau perbedaan gambar

TortoiseSVN → Diff for any of the common image file formats will start TortoiseIDiff to show image differences. By default the images are displayed side-by-side but you can use the View menu or toolbar to switch to a top-bottom view instead, or if you prefer, you can overlay the images and pretend you are using a lightbox.

Naturally you can also zoom in and out and pan around the image. You can also pan the image simply by left-dragging it. If you select the Link images together option, then the pan controls (scrollbars, mousewheel) on both images are linked.

An image info box shows details about the image file, such as the size in pixels, resolution and colour depth. If this box gets in the way, use View → Image Info to hide it. You can get the same information in a tooltip if you hover the mouse over the image title bar.

When the images are overlaid, the relative intensity of the images (alpha blend) is controlled by a slider control at the left side. You can click anywhere in the slider to set the blend directly, or you can drag the slider to change the blend interactively. Ctrl+Shift-Wheel to change the blend.

The button above the slider toggles between 0% and 100% blends, and if you double click the button, the blend toggles automatically every second until you click the button again. This can be useful when looking for multiple small changes.

Sometimes you want to see a difference rather than a blend. You might have the image files for two revisions of a printed circuit board and want to see which tracks have changed. If you disable alpha blend mode, the difference will be shown as an XOR of the pixel colour values. Unchanged areas will be plain white and changes will be coloured.

When you want to diff non-text documents you normally have to use the software used to create the document as it understands the file format. For the commonly used Microsoft Office and Open Office suites there is indeed some support for viewing differences and TortoiseSVN includes scripts to invoke these with the right settings when you diff files with the well-known file extensions. You can check which file extensions are supported and add your own by going to TortoiseSVN → Settings and clicking Advanced in the External Programs section.

Jika piranti yang kami sediakan tidak mencukupi Anda, coba salah satu dari banyak sumber-terbuka atau program komersil yang tersedia. Setiap orang mempunyai favorit sendiri, dan daftar ini tidak berarti lengkap, tapi ini adalah beberapa yang bisa Anda pertimbangkan:

Baca bagian bernama “Seting Program Eksternal” untuk informasi bagaimana menyiapkan TortoiseSVN menggunakan piranti ini.

Pola abaikan Subversion menggunakan globbing nama file, satu teknik yang asalnya digunakan dalam Unix untuk menetapkan file menggunakan meta-karakter sebagai wildcard. Karakter berikut mempunyai arti khusus:

Pattern matching is case sensitive, which can cause problems on Windows. You can force case insensitivity the hard way by pairing characters, e.g. to ignore *.tmp regardless of case, you could use a pattern like *.[Tt][Mm][Pp].

Jika Anda ingin definisi resmi untuk globbing, Anda bisa menemukannya dalam spesifikasi IEEE untuk bahasa perintah shell Pattern Matching Notation.

Use TortoiseSVN → Delete to remove files or folders from Subversion.

When you TortoiseSVN → Delete a file or folder, it is removed from your working copy immediately as well as being marked for deletion in the repository on next commit. The item's parent folder shows a “modified” icon overlay. Up until you commit the change, you can get the file back using TortoiseSVN → Revert on the parent folder.

If you want to delete an item from the repository, but keep it locally as an unversioned file/folder, use Extended Context Menu → Delete (keep local). You have to hold the Shift key while right clicking on the item in the explorer list pane (right pane) in order to see this in the extended context menu.

If an item is deleted via the explorer instead of using the TortoiseSVN context menu, the commit dialog shows those items as missing and lets you remove them from version control too before the commit. However, if you update your working copy, Subversion will spot the missing item and replace it with the latest version from the repository. If you need to delete a version-controlled file, always use TortoiseSVN → Delete so that Subversion doesn't have to guess what you really want to do.

If you want to do a simple in-place rename of a file or folder, use Context Menu → Rename... Enter the new name for the item and you're done.

If you want to move files around inside your working copy, perhaps to a different sub-folder, use the right mouse drag-and-drop handler:

Another way of moving or copying files is to use the Windows copy/cut commands. Select the files you want to copy, right click and choose Context Menu → Copy from the explorer context menu. Then browse to the target folder, right click and choose TortoiseSVN → Paste. For moving files, choose Context Menu → Cut instead of Context Menu → Copy.

You can also use the repository browser to move items around. Read bagian bernama “Browser Repositori” to find out more.

If the repository already contains two files with the same name but differing only in case (e.g. TEST.TXT and test.txt), you will not be able to update or checkout the parent directory on a Windows client. Whilst Subversion supports case-sensitive filenames, Windows does not.

This sometimes happens when two people commit, from separate working copies, files which happen to have the same name, but with a case difference. It can also happen when files are committed from a system with a case-sensitive file system, like Linux.

Dalam hal itu, Anda harus memutuskan yang mana yang ingin Anda biarkan dan hapus (atau ganti nama) yang lain dari repositori.

Terkadang IDE Anda yang ramah akan mengubah nama file-file untuk Anda sebagai bagian praktek perefaktoran, dan tentu saja ia tidak memberitahu Subversion. Jika Anda mencoba untuk mengkomit perubahan-perubahan Anda, Subversion akan melihat nama file lama sebagai hilang dan yang baru sebagai file tidak berversi. Anda dapat saja mencawang nama file baru tersebut untuk membuatnya ditambahkan kedalamnya, tetapi Anda akan kehilangan jejak sejarahnya karena Subversion tidak mengetahui bahwa file-file tersebut berhubungan.

Cara yang lebih baik adalah memberitahu Subversion bahwa perubahan ini sebetulnya adalah perubahan nama dan Anda dapat melakukan ini dalam dialog Komit dan Periksa Modifikasi. Cukup pilih nama lama (hilang) dan nama baru (tidak berversi) dan gunakan Menu Konteks → Betulkan Pemindahan untuk memasangkan kedua file tersebut sebagai suatu perubahan nama.

Biasanya Anda mengeset daftar abaikan Anda sedemikian rupa sehingga semua file-file yang digenerasi diabaikan dalam Subversion. Tetapi bagaimana jika Anda ingin menghilangkan semua file-file diabaikan tersebut untuk menghasilkan suatu pembangunan bersih? Biasanya Anda akan mengesetnya dalam makefile Anda, tetapi jika Anda sedang mendebug makefile tersebut atau sedang mengganti sistem pembangunan, suatu cara untuk membersihkannya akan menjadi berguna.

TortoiseSVN menyediakan opsi demikian dengan Menu Konteks Lanjutan → Hapus item-item tidak berversi.... Anda harus menahan Shift sambil mengeklik kanan pada suatu folder dalam pane daftar explorer (pane kanan) untuk melihat ini pada menu konteks lanjutan. Ini akan menghasilkan sebuah dialog yang mendaftar semua file-file tidak berversi dimanapun dalam copy pekerjaan Anda. Anda selanjutnya dapat memilih atau tidak memilih item-item yang akan dihapus.

Saat item-item tersebut dihapus, tampungan daur ulang digunakan, jadi jika Anda membuat kesalahan disini dan menghapus suatu file yang seharusnya diversi, Anda masih dapat memulihkannya.

Gambar 4.37. Halaman properti Subversion

You can read and set the Subversion properties from the Windows properties dialog, but also from TortoiseSVN → properties and within TortoiseSVN's status lists, from Context menu → properties.

You can add your own properties, or some properties with a special meaning in Subversion. These begin with svn:. svn:externals is such a property; see how to handle externals in bagian bernama “External Items”.

For more information about properties in Subversion see the Special Properties.

Adding and Editing Properties

Gambar 4.38. Menambah properti

To add a new property, first click on New.... Select the required property name from the menu, and then fill in the required information in the specific property dialog. These specific property dialogs are described in more detail in bagian bernama “Property Editors”.

To add a property that doesn't have its own dialog, choose Advanced from the New... menu. Then either select an existing property in the combo box or enter a custom property name.

If you want to apply a property to many items at once, select the files/folders in explorer, then select Context menu → properties.

Jika Anda ingin menerapkan properti ke setiap file dan folder dalam hirarki dibawah folder saat ini, centang kotak centang Rekursif.

Jika Anda ingin mengedit properti yang sudah ada, pilih properti dari daftar properti yang sudah ada, lalu klik Edit....

Jika Anda ingin menghapus properti yang sudah ada, pilih properti itu dari daftar properti yang ada, lalu klik Hapus.

The svn:externals property can be used to pull in other projects from the same repository or a completely different repository. For more information, read bagian bernama “External Items”.

Edit properties at HEAD revision

Because properties are versioned, you cannot edit the properties of previous revisions. If you look at properties from the log dialog, or from a non-HEAD revision in the repository browser, you will see a list of properties and values, but no edit controls.

TortoiseSVN mempunyai beberapa properti khusus, dan ini dimulai dengan tsvn:.

TortoiseSVN can integrate with some bug tracking tools. This uses project properties that start with bugtraq:. Read bagian bernama “Integration with Bug Tracking Systems / Issue Trackers” for further information.

It can also integrate with some web-based repository browsers, using project properties that start with webviewer:. Read bagian bernama “Integrasi dengan Pelihat Repositori Berbasis Web” for further information.

When you add new sub-folders to a working copy using TortoiseSVN, any project properties present in the parent folder will automatically be added to the new child folder too.

Some properties have to use specific values, or be formatted in a specific way in order to be used for automation. To help get the formatting correct, TortoiseSVN presents edit dialogs for some particular properties which show the possible values or break the property into its individual components.

External Content

Gambar 4.44. svn:externals property page

The svn:externals property can be used to pull in other projects from the same repository or a completely different repository as described in bagian bernama “External Items”.

You need to define the name of the sub-folder that the external folder is checked out as, and the Subversion URL of the external item. You can check out an external at its HEAD revision, so when the external item changes in the repository, your working copy will receive those changes on update. However, if you want the external to reference a particular stable point then you can specify the specific revision to use. IN this case you may also want to specify the same revision as a peg revision. If the external item is renamed at some point in the future then Subversion will not be able to update this item in your working copy. By specifying a peg revision you tell Subversion to look for an item that had that name at the peg revision rather than at HEAD.

The button Find HEAD-Revision fetches the HEAD revision of every external URL and shows that HEAD revision in the rightmost column. After the HEAD revision is known, a simple right click on an external gives you the command to peg the selected externals to their explicit HEAD revision. In case the HEAD revision is not known yet, the right click command will fetch the HEAD revision first.

SVN Keywords

Gambar 4.45. svn:keywords property page

Select the keywords that you would like to be expanded in your file.

EOL Style

Gambar 4.46. svn:eol-style property page

Select the end-of-line style that you wish to use and TortoiseSVN will use the correct property value.

Issue Tracker Integration

Gambar 4.47. tsvn:bugtraq property page

Log Message Sizes

Gambar 4.48. Size of log messages property page

These 3 properties control the formatting of log messages. The first 2 disable the OK in the commit or lock dialogs until the message meets the minimum length. The border position shows a marker at the given column width as a guide for projects which have width limits on their log messages. Setting a value to zero will delete the property.

Project Language

Gambar 4.49. Language property page

Choose the language to use for spell-checking log messages in the commit dialog. The file lists checkbox comes into effect when you right click in the log message pane and select Paste file list. By default the Subversion status will be shown in your local language. When this box is checked the status is always given in English, for projects which require English-only log messages.

MIME-type

Gambar 4.50. svn:mime-type property page

svn:needs-lock

Gambar 4.51. svn:needs-lock property page

This property simply controls whether a file will be checked out as read-only if there is no lock held for it in the working copy.

svn:executable

Gambar 4.52. svn:executable property page

This property controls whether a file will be given executable status when checked out on a Unix/Linux system. It has no effect on a Windows checkout.

Merge log message templates

Whenever revisions are merged into a working copy, TortoiseSVN generates a log message from all the merged revisions. Those are then available from the Recent Messages button in the commit dialog.

You can customize that generated message with the following properties:

Gambar 4.53. Property dialog merge log message templates

tsvn:mergelogtemplatetitle, tsvn:mergelogtemplatereversetitle

This property specifies the first part of the generated log message. The following keywords can be used:

{revisions}

A comma separated list of the merged revisions, e.g., 3, 5, 6, 7

{revisionsr}

Like {revisions}, but with each revision preceded with an r, e.g., r3, r5, r6, r7

{revrange}

A comma separated list of the merged revisions, grouped into ranges if possible, e.g., 3, 5-7

{mergeurl}

The source URL of the merge, i.e., where the revisions are merged from.

The default value for this string is Merged revision(s) {revrange} from {mergeurl}: with a newline at the end.

tsvn:mergelogtemplatemsg

This property specifies how the text for each merged revision should look like. The following keywords can be used:

{msg}

The log message of the merged revision, as it was entered.

{msgoneline}

Like {msg}, but all newlines are replaced with a space, so that the whole log message appears on one single line.

{author}

The author of the merged revision.

{rev}

The merged revision itself.

{bugids}

The bug IDs of the merged revision, if there are any.

tsvn:mergelogtemplatemsgtitlebottom

This property specifies the position of the title string specified with the tsvn:mergelogtemplatetitle or tsvn:mergelogtemplatereversetitle. If the property is set to yes or true, then the title string is appended at the bottom instead of the top.

Penting

This only works if the merged revisions are already in the log cache. If you have disabled the log cache or not shown the log first before the merge, the generated message won't contain any information about the merged revisions.

Let's say you check out a working copy of /project1 to D:\dev\project1. Select the folder D:\dev\project1, right click and choose Windows Menu → Properties from the context menu. The Properties Dialog comes up. Then go to the Subversion tab. There, you can set properties. Click Properties.... In the properties dialog, either double click on the svn:externals if it already exists, or click on the New... button and select externals from the menu. To add a new external, click the New... and then fill in the required information in the shown dialog.

If you want the local path to include spaces or other special characters, you can enclose it in double quotes, or you can use the \ (backslash) character as a Unix shell style escape character preceding any special character. Of course this also means that you must use / (forward slash) as a path delimiter. Note that this behaviour is new in Subversion 1.6 and will not work with older clients.

If the external project is in the same repository, any changes you make there will be included in the commit list when you commit your main project.

If the external project is in a different repository, any changes you make to the external project will be shown or indicated when you commit the main project, but you have to commit those external changes separately.

If you use absolute URLs in svn:externals definitions and you have to relocate your working copy (i.e., if the URL of your repository changes), then your externals won't change and might not work anymore.

To avoid such problems, Subversion clients version 1.5 and higher support relative external URLs. Four different methods of specifying a relative URL are supported. In the following examples, assume we have two repositories: one at http://example.com/svn/repos-1 and another at http://example.com/svn/repos-2. We have a checkout of http://example.com/svn/repos-1/project/trunk into C:\Working and the svn:externals property is set on trunk.

You can also specify a peg and operative revision for the URL if required. To learn more about peg and operative revisions, please read the corresponding chapter in the Subversion book.

Jika Anda memerlukan informasi lebih lengkap bagaimana TortoiseSVN menangani Properti baca bagian bernama “Seting Proyek”.

Untuk mencari tentang metode yang berbeda dari pengaksesan sub-proyek umum baca bagian bernama “Sertakan sub-proyek umum”.

As of Subversion 1.6 you can add single file externals to your working copy using the same syntax as for folders. However, there are some restrictions.

A file external behaves just like any other versioned file in many respects, but they cannot be moved or deleted using the normal commands; the svn:externals property must be modified instead.

If you already have a working copy of the files or folders you want to include as externals in another working copy, you can simply add those via drag and drop from the windows explorer.

Simply right drag the file or folder from one working copy to where you want those to be included as externals. A context menu appears when you release the mouse button: SVN Add as externals here if you click on that context menu entry, the svn:externals property is automatically added. All you have to do after that is commit the property changes and update to get those externals properly included in your working copy.

Jika Anda sudah mengimpor proyek Anda dengan struktur direktori yang direkomendasikan, membuat sebuah cabang atau versi tag sangat sederhana:

Gambar 4.54. Dialog Cabang/Tag

Pilih folder dalam copy pekerjaan Anda yang ingin Anda copy ke cabang atau tag, lalu pilih perintah TortoiseSVN → Cabang/Tag....

The default destination URL for the new branch will be the source URL on which your working copy is based. You will need to edit that URL to the new path for your branch/tag. So instead of

http://svn.collab.net/repos/ProjectName/trunk
      

you might now use something like

http://svn.collab.net/repos/ProjectName/tags/Release_1.10
      

If you can't remember the naming convention you used last time, click the button on the right to open the repository browser so you can view the existing repository structure.

Sekarang Anda harus memilih sumber yang dicopy. Disini Anda mempunyai tiga opsi:

Jika Anda ingin copy pekerjaan Anda ditukar ke cabang yang baru dibuat secara otomatis, gunakan kotak centang Tukar copy pekerjaan ke cabang/tag baru. Tapi jika Anda melakukannya, pertama pastikan bahwa copy pekerjaan Anda tidak berisi modifikasi. Jika ada, perubahan itu akan digabung ke dalam cabang WC ketika Anda menukar.

If your working copy has other projects included with svn:externals properties, those externals will be listed at the bottom of the branch/tag dialog. For each external, the target path and the source URL is shown.

If you want to make sure that the new tag always is in a consistent state, check all the externals to have their revisions pinned. If you don't check the externals and those externals point to a HEAD revision which might change in the future, checking out the new tag will check out that HEAD revision of the external and your tag might not compile anymore. So it's always a good idea to set the externals to an explicit revision when creating a tag.

The externals are automatically pinned to either the current HEAD revision or the working copy BASE revision, depending on the source of the branch/tag:

Tekan OK untuk mengkomit copy baru ke repositori. Jangan lupa untuk menyertakan log pesan. Catatan bahwa copy dibuat di dalam repositori.

Note that unless you opted to switch your working copy to the newly created branch, creating a Branch or Tag does not affect your working copy. Even if you create the branch from your WC, those changes are committed to the new branch, not to the trunk, so your WC may still be marked as modified with respect to the trunk.

You can also create a branch or tag without having a working copy. To do that, open the repository browser. You can there drag folders to a new location. You have to hold down the Ctrl key while you drag to create a copy, otherwise the folder gets moved, not copied.

You can also drag a folder with the right mouse button. Once you release the mouse button you can choose from the context menu whether you want the folder to be moved or copied. Of course to create a branch or tag you must copy the folder, not move it.

Yet another way is from the log dialog. You can show the log dialog for e.g. trunk, select a revision (either the HEAD revision at the very top or an earlier revision), right click and choose create branch/tag from revision....

...that is (not really) the question. While a checkout downloads everything from the desired branch in the repository to your working directory, TortoiseSVN → Switch... only transfers the changed data to your working copy. Good for the network load, good for your patience. :-)

To be able to work with your freshly generated branch or tag you have several ways to handle it. You can:

Gambar 4.55. Dialog Tukar

Meskipun Subversion sendiri tidak membuat perbedaan antara tag dan cabang, cara mereka biasanya digunakan agak sedikit berbeda.

Gambar 4.56. The Merge Wizard - Select Revision Range

In the From: field enter the full folder URL of the branch or tag containing the changes you want to port into your working copy. You may also click ... to browse the repository and find the desired branch. If you have merged from this branch before, then just use the drop down list which shows a history of previously used URLs.

If you are merging from a renamed or deleted branch then you will have to go back to a revision where that branch still existed. In this case you will also need to specify that revision as a peg revision in the range of revisions being merged (see below), otherwise the merge will fail when it can't find that path at HEAD.

In the Revision range to merge field enter the list of revisions you want to merge. This can be a single revision, a list of specific revisions separated by commas, or a range of revisions separated by a dash, or any combination of these.

If you need to specify a peg revision for the merge, add the peg revision at the end of the revisions, e.g. 5-7,10@3. In the above example, the revisions 5,6,7 and 10 would be merged, with 3 being the peg revision.

The easiest way to select the range of revisions you need is to click on Show Log, as this will list recent changes with their log comments. If you want to merge the changes from a single revision, just select that revision. If you want to merge changes from several revisions, then select that range (using the usual Shift-modifier). Click on OK and the list of revision numbers to merge will be filled in for you.

If you want to merge changes back out of your working copy, to revert a change which has already been committed, select the revisions to revert and make sure the Reverse merge box is checked.

If you have already merged some changes from this branch, hopefully you will have made a note of the last revision merged in the log message when you committed the change. In that case, you can use Show Log for the Working Copy to trace that log message. Remembering that we are thinking of revisions as changesets, you should Use the revision after the end point of the last merge as the start point for this merge. For example, if you have merged revisions 37 to 39 last time, then the start point for this merge should be revision 40.

If you are using the merge tracking features of Subversion, you do not need to remember which revisions have already been merged - Subversion will record that for you. If you leave the revision range blank, all revisions which have not yet been merged will be included. Read bagian bernama “Merge Tracking” to find out more.

When merge tracking is used, the log dialog will show previously merged revisions, and revisions pre-dating the common ancestor point, i.e. before the branch was copied, as greyed out. The Hide non-mergeable revisions checkbox allows you to filter out these revisions completely so you see only the revisions which can be merged.

Jika orang lain boleh mengkomit perubahan maka hati-hati terhadap penggunaan revisi HEAD. Ia tidak boleh merujuk ke revisi yang Anda pikir benar jika orang lain mengkomit setetlah pemutahiran Anda yang terkahir.

If you leave the range of revisions empty or have the radio button all revisions checked, then Subversion merges all not-yet merged revisions. This is known as a reintegrate or automatic merge.

There are some conditions which apply to a reintegrate merge. Firstly, the server must support merge tracking. The working copy must be of depth infinite (no sparse checkouts), and it must not have any local modifications, switched items or items that have been updated to revisions other than HEAD. All changes to trunk made during branch development must have been merged across to the branch (or marked as having been merged). The range of revisions to merge will be calculated automatically.

Click Next and go to bagian bernama “Merge Options”.

Gambar 4.57. The Merge Wizard - Tree Merge

If you are using this method to merge a feature branch back to trunk, you need to start the merge wizard from within a working copy of trunk.

In the From: field enter the full folder URL of the trunk. This may sound wrong, but remember that the trunk is the start point to which you want to add the branch changes. You may also click ... to browse the repository.

In the To: field enter the full folder URL of the feature branch.

Dalam kedua field Dari Revisi dan field Ke Revisi, masukkan angka revisi terakhir dimana dua susunan disinkronisasi. Jika Anda yakin tidak-ada yang lain melakukan komit Anda bisa menggunakan revisi HEAD dalam kedua kasus. Jika ada kesempatan dimana orang lain sudah melakukan komit sejak sinkronisasi, gunakan angka revisi tertenu untuk menghindari kehilangan komit terbaru.

You can also use Show Log to select the revision.

This page of the wizard lets you specify advanced options, before starting the merge process. Most of the time you can just use the default settings.

You can specify the depth to use for the merge, i.e. how far down into your working copy the merge should go. The depth terms used are described in bagian bernama “Checkout Depth”. The default depth is Working copy, which uses the existing depth setting, and is almost always what you want.

Most of the time you want merge to take account of the file's history, so that changes relative to a common ancestor are merged. Sometimes you may need to merge files which are perhaps related, but not in your repository. For example you may have imported versions 1 and 2 of a third party library into two separate directories. Although they are logically related, Subversion has no knowledge of this because it only sees the tarballs you imported. If you attempt to merge the difference between these two trees you would see a complete removal followed by a complete add. To make Subversion use only path-based differences rather than history-based differences, check the Ignore ancestry box. Read more about this topic in the Subversion book, Noticing or Ignoring Ancestry.

You can specify the way that line ending and whitespace changes are handled. These options are described in bagian bernama “Line-end and Whitespace Options”. The default behaviour is to treat all whitespace and line-end differences as real changes to be merged.

The checkbox marked Force the merge is used to avoid a tree conflict where an incoming delete affects a file that is either modified locally or not versioned at all. If the file is deleted then there is no way to recover it, which is why that option is not checked by default.

If you are using merge tracking and you want to mark a revision as having been merged, without actually doing the merge here, check the Only record the merge checkbox. There are two possible reasons you might want to do this. It may be that the merge is too complicated for the merge algorithms, so you code the changes by hand, then mark the change as merged so that the merge tracking algorithm is aware of it. Or you might want to prevent a particular revision from being merged. Marking it as already merged will prevent the merge occurring with merge-tracking-aware clients.

Now everything is set up, all you have to do is click on the Merge button. If you want to preview the results Test Merge simulates the merge operation, but does not modify the working copy at all. It shows you a list of the files that will be changed by a real merge, and notes files where conflicts may occur. Because merge tracking makes the merge process a lot more complicated, there is no guaranteed way to find out in advance whether the merge will complete without conflicts, so files marked as conflicted in a test merge may in fact merge without any problem.

The merge progress dialog shows each stage of the merge, with the revision ranges involved. This may indicate one more revision than you were expecting. For example if you asked to merge revision 123 the progress dialog will report “ Merging revisions 122 through 123 ”. To understand this you need to remember that Merge is closely related to Diff. The merge process works by generating a list of differences between two points in the repository, and applying those differences to your working copy. The progress dialog is simply showing the start and end points for the diff.

The merge is now complete. It's a good idea to have a look at the merge and see if it's as expected. Merging is usually quite complicated. Conflicts often arise if the branch has drifted far from the trunk.

For Subversion clients and servers prior to 1.5, no merge information is stored and merged revisions have to be tracked manually. When you have tested the changes and come to commit this revision, your commit log message should always include the revision numbers which have been ported in the merge. If you want to apply another merge at a later time you will need to know what you have already merged, as you do not want to port a change more than once. For more information about this, refer to Best Practices for Merging in the Subversion book.

If your server and all clients are running Subversion 1.5 or higher, the merge tracking facility will record the revisions merged and avoid a revision being merged more than once. This makes your life much simpler as you can simply merge the entire revision range each time and know that only new revisions will actually be merged.

Manajemen cabang penting. Jika Anda ingin membiarkan cabang ini mutahir dengan trunk, Anda harus memastikan untuk sering menggabung agar cabang dan trunk tidak berselisih terlalu jauh. Tentu saja, Anda masih harus menghindari pengulangan penggabungan perubahan seperti dijelaskan di atas.

Subversion 1.5 introduced facilities for merge tracking. When you merge changes from one tree into another, the revision numbers merged are stored and this information can be used for several different purposes.

Merge tracking information is stored in the svn:mergeinfo property by the client when it performs a merge. When the merge is committed the server stores that information in a database, and when you request merge, log or blame information, the server can respond appropriately. For the system to work properly you must ensure that the server, the repository and all clients are upgraded. Earlier clients will not store the svn:mergeinfo property and earlier servers will not provide the information requested by new clients.

Find out more about merge tracking from Subversion's Merge tracking documentation.

Merging does not always go smoothly. Sometimes there is a conflict. TortoiseSVN helps you through this process by showing the merge conflict dialog.

Gambar 4.58. The Merge Conflict Dialog

It is likely that some of the changes will have merged smoothly, while other local changes conflict with changes already committed to the repository. All changes which can be merged are merged. The Merge Conflict dialog gives you different ways of handling the lines which are in conflict.

For normal conflicts that happen due to changes in the file content or its properties, the dialog shows buttons which allow you to chose which of the conflicting parts to keep or reject.

If there's a tree conflict, please first see bagian bernama “Tree Conflicts” about the various types of tree conflicts and how and why they can happen.

To resolve tree conflicts after a merge, a dialog is shown with various options on how to resolve the conflict:

Gambar 4.59. The Merge Tree Conflict Dialog

Since there are various possible tree conflict situations, the dialog will show buttons to resolve those depending on the specific conflict. The button texts and labels explain what the option to resolve the conflict does. If you're not sure, either cancel the dialog or use the Postpone button to resolve the conflict later.

When you develop a new feature on a separate branch it is a good idea to work out a policy for re-integration when the feature is complete. If other work is going on in trunk at the same time you may find that the differences become significant over time, and merging back becomes a nightmare.

If the feature is relatively simple and development will not take long then you can adopt a simple approach, which is to keep the branch entirely separate until the feature is complete, then merge the branch changes back into trunk. In the merge wizard this would be a simple Merge a range of revisions, with the revision range being the revision span of the branch.

If the feature is going to take longer and you need to account for changes in trunk, then you need to keep the branch synchronised. This simply means that periodically you merge trunk changes into the branch, so that the branch contains all the trunk changes plus the new feature. The synchronisation process uses Merge a range of revisions. When the feature is complete then you can merge it back to trunk using either Reintegrate a branch or Merge two different trees.

Another (fast) way to merge all changes from trunk to the feature branch is to use the TortoiseSVN → Merge all... from the extended context menu (hold down the Shift key while you right click on the file).

Gambar 4.60. The Merge-All Dialog

This dialog is very easy. All you have to do is set the options for the merge, as described in bagian bernama “Merge Options”. The rest is done by TortoiseSVN automatically using merge tracking.

Standarnya, tidak ada yang dikunci dan setiap orang yang mempunyai akses komit bisa mengkomit perubahan ke file apapun kapan saja. Yang lain akan memutahirkan copy pekerjaannya secara periodik dan perubahan dalam repositori akan digabung dengan perubahan lokal.

Jika Anda Mendapat Kunci pada file, maka hanya Anda yang bisa mengkomit file itu. Mengkomit dengan semua pengguna lain akan diblok sampai Anda melepas kuncian. File terkunci tidak bisa diubah dengan cara apapun dalam repositori, ia tidak bisa dihapus atau diganti nama juga, kecuali oleh pemilik kunci.

Akan tetapi, pengguna lain tidak perlu mengetahui bahwa Anda telah mengambil kunci. Kecuali mereka memeriksa status kunci secara reguler, pertama mereka akan mengetahuinya ketika komit mereka gagal, yang dalam banyak akasus tidak begitu berguna. Untuk memudahkan pengaturan kunci, ada properti baru Subversion svn:needs-lock. Bila properti ini di-set (ke nilai apapun) pada file, kapan saja filedi check out atau dimutahirkan, copy lokal dibuat hanya-baca kecuali copy pekerjaan itu menampung kuncian untuk file. Tindakan ini sebagai peringatan bahwa Anda tidak boleh mengedit file itu kecuali Anda mendapatkan kunci yang dibutuhkan. File yang diversi dan hanya-baca ditandai dengan lapisan khusus dalam TortoiseSVN untuk menunjukan bahwa Anda perlu mendapatkan kunci sebelum pengeditan.

Kuncian direkam oleh lokasi copy pekerjaan juga oleh pemilik. Jika Anda mempunyai beberapa copy pekerjaan (di rumah, di tempat kerja) maka Anda hanya bisa menampung kunci dalam salah satu dari copy pekerjaan itu.

Jika salah satu dari co-worker Anda memerlukan kunci dan kemudian pergi berlibur tanpa melepaskannya, apa yang Anda lakukan? Subversion menyediakan dalam artian untuk memaksa kuncian. Pelepasan kunci yang dipegang oleh orang lain dirujuk sebagai Membongkar kunci, dan dipaksa untuk mendapatkan kunci yang sudah dipegang orang lain dirujuk sebagai Pencurian kunci. Umumnya ini bukan hal yang harus Anda lakukan jika Anda ingin tetap berteman dengan co-worker Anda.

Kuncian direkam dalam repositori, dan token kunci dibuat dalam copy pekerjaan Anda. Jika ada ketidaksesuaian, sebagai contoh jika orang lain telah membongkar kunci, kunci lokal menjadi tidak benar. Repositori selalu menjadi referensi definitif.

Pilih file-file dalam copy pekerjaan Anda yang ingin Anda perlukan kunci, lalu pilih perintah TortoiseSVN → Dapatkan Kunci....

Gambar 4.61. Dialog Penguncian

Dialog muncul, membolehkan Anda untuk memasukan komentar, agar yang lain bisa melihat mengapa Anda mengunci file. Komentar bersifat opsional dan saat ini hanya digunakan dengan repositori berbasis Svnserve. Jika (dan hanya jika) Anda perlu mencuri kunci dari orang lain, centang kotak Curi kunci, lalu klik OK.

You can set the project property tsvn:logtemplatelock to provide a message template for users to fill in as the lock message. Refer to bagian bernama “Seting Proyek” for instructions on how to set properties.

If you select a folder and then use TortoiseSVN → Get Lock... the lock dialog will open with every file in every sub-folder selected for locking. If you really want to lock an entire hierarchy, that is the way to do it, but you could become very unpopular with your co-workers if you lock them out of the whole project. Use with care ...

Untuk memastikan Anda tidak lupa melepaskan kunci yang tidak Anda perlukan lagi, file terkunci ditampilkan dalam dialog komit dan dipilih secara standar. Jika Anda melanjurkan dengan komit, kuncian yang Anda pegang pada file yang dipilih akan dihapus, bahkan jika file belum diubah. Jika Anda tidak ingin melepaskan kunci pada file tertentu, Anda bisa tidak mencentangnya (jika tidak diubah). Jika Anda ingin membiarkan kunci pada file yang telah Anda ubah, Anda harus menghidupkan kotak centang Biarkan kunci sebelum Anda mengkomit perubahan Anda.

To release a lock manually, select the file(s) in your working copy for which you want to release the lock, then select the command TortoiseSVN → Lepaskan Kunci Tidak ada yang harus dimasukan selanjutnya maka TortoiseSVN akan menghubungi repositori dan melepaskan kunci. Anda juga bisa menggunakan perintah ini pada folder untuk melepaskan semua kunci secara rekursif.

Gambar 4.62. Dialog Pemeriksaan Modifikasi

Untuk melihat kunci apa yang Anda dan lainnya pegang, Anda bisa menggunakan TortoiseSVN → Periksa Modifikasi.... Secara lokal kunci yang dipegang segera tampil. Untuk memeriksa kunci yang dipegang orang lain (dan melihat jika kunci Anda rusak atau dicuri) Anda perlu untuk mengklik pada Periksa Repositori.

Dari menu konteks disini, Anda juga bisa mendapatkan dan melepaskan kunci, juga pembongkaran dan pencurian kunci yang dipegang orang lain.

Seperti telah disebutkan diatas, cara yang paling efektif untuk menggunakan kuncian adalah mengeset properti svn:needs-lock pada file. Lihat bagian bernama “Seting Proyek” untuk instruksi bagaimana mengeset properti. File dengan properti ini diset akan selalu di check out dan dimutahirkan dengan tanda hanya-baca di-set kecuali copy pekerjaan Anda memegang kunci.

Sebagai pengingat, TortoiseSVN menggunakan lapisan khusus untuk menunjukan ini.

If you operate a policy where every file has to be locked then you may find it easier to use Subversion's auto-props feature to set the property automatically every time you add new files. Read bagian bernama “Seting properti otomatis” for further information.

Ketika Anda membuat repositori baru dengan Subversion 1.2 atau lebih tinggi, empat template hook dibuat dalam direktori repositori hooks. Ini disebut sebelum dan setelah mendapatkan kunci, dan sebelum serta setelah melepaskan kunci.

Adalah ide yang baik untuk menginstalasi naskah hook setelah-kunci dan setelah-buka-kunci pada server yang mengirim email menunjukan file yang sedang dikunci. Dengan naskah itu ditempatnya, semua pengguna Anda bisa diberitahu jika seseorang mengunci/membuka kunci file. Anda bisa menemukan contoh naskah hook hooks/post-lock.tmpl dalam folder repositori Anda.

Mungkin Anda juga menggunakan hook untuk tidak membolehkan pemisahakan atau seting kuncian, atau barangkali membatasinya ke nama administrator. Atau mungkin Anda ingin mengirim email kepada pemilik ketika salah satu dari kunciannya rusak atau dicuri.

Baca selengkapnya bagian bernama “Server side hook scripts”.

Pertama Anda perlu membuat dan menguji perubahan Anda. Kemudian daripada menggunakan TortoiseSVN → Komit... pada folder di atasnya, Anda pilih TortoiseSVN → Buat Patch...

Gambar 4.63. Dialog Buat Patch

Sekarang Anda bisa memilih file yang ingin Anda sertakan dalam patch, seperti yang Anda inginkan dengan komit penuh. Ini akan menghasilkan file tunggal berisi ringkasan dari semua perubahan yang sudah Anda buat ke file yang dipilih sejak pemutahiran terakhir dari repositori.

Kolom dalam dialog ini bisa dikustomisasi dalam cara yang sama seperti kolom dalam dialog Periksa modifikasi. Baca bagian bernama “Status Lokal dan Remote” untuk detil selanjutnya.

By clicking on the Options button you can specify how the patch is created. For example you can specify that changes in line endings or whitespaces are not included in the final patch file.

Anda bisa menghasilkan patch terpisah yang berisi perubahan ke set file yang berbeda. Tentunya, jika Anda membuat file patch, buat beberapa perubahan lagi ke file yang sama dan kemudian buat patch lain, file patch kedua akan menyertakan kedua set perubahan.

Simpan file menggunakan nama file pilihan Anda. File patch bisa memiliki ekstensi yang Anda sukai, tapi konvensi seharusnya .patch atau ekstensi .diff. Sekarang Anda siap untuk mengirimkan file patch Anda.

Selain ke suatu file, Anda dapat juga menyimpan patch tersebut ke clipboard. Anda mungkin ingin untuk melakukannya supaya Anda dapat menempelkannya ke dalam email untuk dikaji ulang oleh orang-orang lain. Atau jika Anda memiliki dua copy pekerjaan di satu mesin dan Anda ingin memindahkan perubahan-perubahan dari satu ke yang lain, suatu patch ke clipboard adalah cara yang cukup nyaman untuk melakukannya.

If you prefer, you can create a patch file from within the Commit or Check for Modifications dialogs. Just select the files and use the context menu item to create a patch from those files. If you want to see the Options dialog you have to hold shift when you right click.

Patch files are applied to your working copy. This should be done from the same folder level as was used to create the patch. If you are not sure what this is, just look at the first line of the patch file. For example, if the first file being worked on was doc/source/english/chapter1.xml and the first line in the patch file is Index: english/chapter1.xml then you need to apply the patch to the doc/source/ folder. However, provided you are in the correct working copy, if you pick the wrong folder level, TortoiseSVN will notice and suggest the correct level.

Untuk menerapkan file patch ke copy pekerjaan Anda, Anda perlu mempunyai akses baca ke repositori. Alasan ini adalah bahwa program penggabung harus merujuk perubahan kembali ke revisi terhadap perubahan dibuat oleh pengembang secara remote.

From the context menu for that folder, click on TortoiseSVN → Apply Patch... This will bring up a file open dialog allowing you to select the patch file to apply. By default only .patch or .diff files are shown, but you can opt for “All files”. If you previously saved a patch to the clipboard, you can use Open from clipboard... in the file open dialog. Note that this option only appears if you saved the patch to the clipboard using TortoiseSVN → Create Patch.... Copying a patch to the clipboard from another app will not make the button appear.

Alternatifnya, jika file patch mempunyai ekstensi .patch atau .diff, Anda bisa mengklik kanan padanya secara langsung dan pilih TortoiseSVN → Terapkan Patch.... Dalam hal ini Anda akan ditanya untuk memasukan lokasi copy pekerjaan.

Dua metode ini menawarkan cara berbeda dalam melakukan hal yang sama. Dengan metode pertama Anda milih WC dan melihat file patch. Yang kedua Anda memilih file patch dan melihat ke WC.

Sekali Anda memilih file patch dan lokasi copy pekerjaan, TortoiseMerge dijalankan untuk menggabung perubahan dari file patch dengan copy pekerjaan Anda. Jendela kecil mendaftar file yang sudah diubah. Klik ganda pada setiap file untuk meninjau perubahan dan simpan file gabungan.

Patfh pengembang remote sekarang sudah menerapkan ke copy pekerjaan Anda, maka Anda perlu mengkomit untuk membolehkan orang lain untuk mengakses perubahan dari repositori.

Gambar 4.64. Dialog Anotasi / Blame

Jika Anda tidak tertarik dalam perubahan dari revisi sebelumnya Anda bisa men-set revisi dari dimana blame seharusnya dimulai. Set ini ke 1, jika Anda ingin blame untuk setiap revisi.

By default the blame file is viewed using TortoiseBlame, which highlights the different revisions to make it easier to read. If you wish to print or edit the blame file, select Use Text viewer to view blames.

You can specify the way that line ending and whitespace changes are handled. These options are described in bagian bernama “Line-end and Whitespace Options”. The default behaviour is to treat all whitespace and line-end differences as real changes, but if you want to ignore an indentation change and find the original author, you can choose an appropriate option here.

You can include merge information as well if you wish, although this option can take considerably longer to retrieve from the server. When lines are merged from another source, the blame information shows the revision the change was made in the original source as well as the revision when it was merged into this file.

Once you press OK TortoiseSVN starts retrieving the data to create the blame file. Once the blame process has finished the result is written into a temporary file and you can view the results.

Gambar 4.65. TortoiseBlame

TortoiseBlame, yang disertakan dengan TortoiseSVN, membuat file blame lebih mudah dibaca. Ketika Anda membawa mouse diatas baris dalam kolom info blame, semua baris dengan revisi sama ditampilkan dengan latar belakang lebih gelap. Baris dari revisi lain yang diubah oleh pembuat yang sama ditampilkan dengan latar belakang terang. Pewarnaan mungkin tidak bekerja dengan jelas jika Anda mempunyai layar yang di-set ke mode warna 256.

Jika Anda mengklik kiri pada sebuah baris, semua baris dengan revisi sama diterangi, dan baris dari revisi lain oleh pembuat yang sama diterangi dalam warna lebih terang. Penerangan ini lengket, membolehkan Anda untuk memindahkan mouse tanpa kehilangan penerangan. Klik pada revisi itu lagi untuk mematikan penerangan.

Komentar revisi ditampilkan dalam kotak petunjuk kapan saja mouse berjalan di atas kolom info blame. Jika Anda ingin menyalin pesan log untuk revisi itu, gunakan menu konteks yang muncul jika Anda mengeklik kanan pada kolom info blame.

Anda bisa mencari di dalam laporan Blame menggunakan Edit → Cari.... Ini membolehkan Anda untuk mencari angka revisi, pembuat dan isi dari file itu sendiri. Log pesan tidak disertakan dalam pencarian - Anda harus menggunakan Dialog Log untuk mencarinya.

Anda juga dapat lompat ke suatu baris spesifik menggunakan Edit → Pergi Ke Baris....

When the mouse is over the blame info columns, a context menu is available which helps with comparing revisions and examining history, using the revision number of the line under the mouse as a reference. Context menu → Blame previous revision generates a blame report for the same file, but using the previous revision as the upper limit. This gives you the blame report for the state of the file just before the line you are looking at was last changed. Context menu → Show changes starts your diff viewer, showing you what changed in the referenced revision. Context menu → Show log displays the revision log dialog starting with the referenced revision.

If you need a better visual indicator of where the oldest and newest changes are, select View → Color age of lines. This will use a colour gradient to show newer lines in red and older lines in blue. The default colouring is quite light, but you can change it using the TortoiseBlame settings.

If you are using Merge Tracking and you requested merge info when starting the blame, merged lines are shown slightly differently. Where a line has changed as a result of merging from another path, TortoiseBlame will show the revision and author of the last change in the original file rather than the revision where the merge took place. These lines are indicated by showing the revision and author in italics. The revision where the merge took place is shown separately in the tooltip when you hover the mouse over the blame info columns. If you do not want merged lines shown in this way, uncheck the Include merge info checkbox when starting the blame.

If you want to see the paths involved in the merge, select View → Merge paths. This shows the path where the line was last changed, excluding changes resulting from a merge.

The revision shown in the blame information represents the last revision where the content of that line changed. If the file was created by copying another file, then until you change a line, its blame revision will show the last change in the original source file, not the revision where the copy was made. This also applies to the paths shown with merge info. The path shows the repository location where the last change was made to that line.

The settings for TortoiseBlame can be accessed using TortoiseSVN → Settings... on the TortoiseBlame tab. Refer to bagian bernama “TortoiseBlame Settings”.

One of the limitations of the Blame report is that it only shows the file as it was in a particular revision, and the last person to change each line. Sometimes you want to know what change was made, as well as who made it. If you right click on a line in TortoiseBlame you have a context menu item to show the changes made in that revision. But if you want to see the changes and the blame information simultaneously then you need a combination of the diff and blame reports.

Dialog log revisi menyertakan beberapa opsi yang membolehkan Anda melakukan ini.

Each revision graph node represents a revision in the repository where something changed in the tree you are looking at. Different types of node can be distinguished by shape and colour. The shapes are fixed, but colours can be set using TortoiseSVN → Settings

Note that by default the graph only shows the points at which items were added, copied or deleted. Showing every revision of a project will generate a very large graph for non-trivial cases. If you really want to see all revisions where changes were made, there is an option to do this in the View menu and on the toolbar.

The default view (grouping off) places the nodes such that their vertical position is in strict revision order, so you have a visual cue for the order in which things were done. Where two nodes are in the same column the order is very obvious. When two nodes are in adjacent columns the offset is much smaller because there is no need to prevent the nodes from overlapping, and as a result the order is a little less obvious. Such optimisations are necessary to keep complex graphs to a reasonable size. Please note that this ordering uses the edge of the node on the older side as a reference, i.e. the bottom edge of the node when the graph is shown with oldest node at the bottom. The reference edge is significant because the node shapes are not all the same height.

Because a revision graph is often quite complex, there are a number of features which can be used to tailor the view the way you want it. These are available in the View menu and from the toolbar.

To make it easier to navigate a large graph, use the overview window. This shows the entire graph in a small window, with the currently displayed portion highlighted. You can drag the highlighted area to change the displayed region.

Tanggal revisi, pembuat dan komentar ditampilkan dalam kotak petunjuk kapan saja mouse melalui kotak revisi.

If you select two revisions (Use Ctrl-left click), you can use the context menu to show the differences between these revisions. You can choose to show differences as at the branch creation points, but usually you will want to show the differences at the branch end points, i.e. at the HEAD revision.

Anda bisa melihat perbedaan sebagai file Unified-Diff, yang menampilkan semua perbedaan dalam file tunggal dengan konteks minimal. Jika Anda memilih ke Menu Konteks → Bandingkan Revisi Anda akan disodorkan dengan daftar file yang diubah. Klik ganda pada nama file utnuk mengambil kedua revisi dari file dan membandingkannya menggunakan piranti pembeda visual.

Jika Anda mengklik kanan pada revisi Anda bisa menggunakan Menu Konteks → Tampilkan Log untuk melihat histori.

You can also merge changes in the selected revision(s) into a different working copy. A folder selection dialog allows you to choose the working copy to merge into, but after that there is no confirmation dialog, nor any opportunity to try a test merge. It is a good idea to merge into an unmodified working copy so that you can revert the changes if it doesn't work out! This is a useful feature if you want to merge selected revisions from one branch to another.

If you want to check the server again for newer information, you can simply refresh the view using F5. If you are using the log cache (enabled by default), this will check the repository for newer commits and fetch only the new ones. If the log cache was in offline mode, this will also attempt to go back online.

If you are using the log cache and you think the message content or author may have changed, you should use the log dialog to refresh the messages you need. Since the revision graph works from the repository root, we would have to invalidate the entire log cache, and refilling it could take a very long time.

A large tree can be difficult to navigate and sometimes you will want to hide parts of it, or break it down into a forest of smaller trees. If you hover the mouse over the point where a node link enters or leaves the node you will see one or more popup buttons which allow you to do this.

Click on the minus button to collapse the attached sub-tree.

Click on the plus button to expand a collapsed tree. When a tree has been collapsed, this button remains visible to indicate the hidden sub-tree.

Click on the cross button to split the attached sub-tree and show it as a separate tree on the graph.

Click on the circle button to reattach a split tree. When a tree has been split away, this button remains visible to indicate that there is a separate sub-tree.

Click on the graph background for the main context menu, which offers options to Expand all and Join all. If no branch has been collapsed or split, the context menu will not be shown.

Sometimes you have a working copy which you want to convert back to a normal folder without the .svn directory. All you need to do is delete the .svn directory from the working copy root.

Alternatively you can export the folder to itself. In Windows Explorer right drag the working copy root folder from the file pane onto itself in the folder pane. TortoiseSVN detects this special case and asks if you want to make the working copy unversioned. If you answer yes the control directory will be removed and you will have a plain, unversioned directory tree.

You can integrate a bug tracking tool of your choice in TortoiseSVN. To do this, you have to define some properties, which start with bugtraq:. They must be set on Folders: (bagian bernama “Seting Proyek”)

Gambar 4.70. The Bugtraq Properties Dialog

When you edit any of the bugtraq properties a special property editor is used to make it easier to set appropriate values.

There are two ways to integrate TortoiseSVN with issue trackers. One is based on simple strings, the other is based on regular expressions. The properties used by both approaches are:

Jika bugtraq:message dan bugtraq:logregex properti keduanya di-set, logregex diproses lebih dulu.

Some tsvn: properties require a true/false value. TortoiseSVN also understands yes as a synonym for true and no as a synonym for false.

When you add new sub-folders to a working copy using TortoiseSVN, any project properties present in the parent folder will automatically be added to the new child folder too.