TSVN poChecker

This tool, to be used before committing your work, should help you locate problems in translation files. Please consider it as work-in-progress, as we are still working on it.

First of all, it will help you find missing accelerators - Luebbe's translation status page shows counts but not strings themselves, so the table below will help you fix these problems.

The analysis also includes some other useful lists, it checks for instance for correct new line styles, untranslated strings and spelling mistakes. As we prefer to err on the side of caution, you may find a lot of false positives. Anyway I hope this will help you improve the quality of your translation.

Oto

---

---

For new translators

Please follow this link if you think you may help with translation.
-> TortoiseSVN translation

---

Precommit checker

You can upload file for check before you make actual commit, so you can fix errors in one commit.

Make sure you are going to check translation against proper branch.

Choose a file to upload:

---

Revision: 20088 of trunk

Last update: September 05 2010 17:08 CET (GMT+1/GMT+2(DST))
Go to STABLE.

Language	GUI check								DOC		Author(s)
	Flag	PAR!!	ACC!	NLS	UNT	FUZ	ESC	Note
Greek					2654	8			2654/8	-	George Marselis, Joseph Megkousoglou, John Stratoudakis, Stavros Labrou, Vasilios Will

---

GUI history graph:

---

TSVN doc history graph:

---

TMerge doc history graph:

---

Revision: 20088

PO Check (el)

Parameter strings test

This test is necessary to pass or you can expect crashing of TSVN - specially true when you use longer type as is in English like %s instead of %d, %ld instead of %d, etc. Also having more parameters lead to crash TSVN. When TSVN not crash, the information is still wrong. For example number instead of text.

PASS

Missing/Unexpected Key Accelerator test

This is accessibility test. Passing this test is recommended. If you are interesting in more details about accelerator key overlapping I may enable such test for your language, but in fact there not too much to do against it. According Luebbe and Stefan there is no problem about it you just have to use accelerator more time to select element and then use enter or space for activate button.

PASS

Differences in new line style

This tests if new line style from pot match localized new line style. This test may have false positives when English text has new line style inconsistence. Using more lines for Native when English use just one is also alowed for most of translation even here reported.

PASS

Not translated strings test

This tests if all strings has been translated. Translated mean that there in native string set. If English and native are same it is not marked as not translated, this just can happen.

Index	Line	English	Line
1	65	version control	82
2	69	Version control is the art of managing changes to information. It has long been a critical tool for programmers, who typically spend their time making small changes to software and then undoing or checking some of those changes the next day. Imagine a team of such developers working concurrently - and perhaps even simultaneously on the very same files! - and you can see why a good system is needed to manage the potential chaos.	86
3	77	TortoiseSVN is a free open-source Windows client for the Subversion version control system. That is, TortoiseSVN manages files and directories over time. Files are stored in a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories. This allows you to recover older versions of your files and examine the history of how and when your data changed, and who changed it. This is why many people think of Subversion and version control systems in general as a sort of time machine.	94
4	81	Some version control systems are also software configuration management (SCM) systems. These systems are specifically tailored to manage trees of source code, and have many features that are specific to software development - such as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems; it is a general system that can be used to manage any collection of files, including source code.	98
5	109	And you are not limited to using the Windows Explorer; TortoiseSVN's context menus work in many other file managers, and also in the File/Open dialog which is common to most standard Windows applications. You should, however, bear in mind that TortoiseSVN is intentionally developed as an extension for the Windows Explorer. Thus it is possible that in other applications the integration is not as complete and e.g. the icon overlays may not be shown.	127
6	113	Icon overlays	131
7	117	The status of every versioned file and folder is indicated by small overlay icons. That way you can see right away what the status of your working copy is.	135
8	121	Graphical User Interface	139
9	125	When you list the changes to a file or folder, you can click on a revision to see the comments for that commit. You can also see a list of changed files - just double click on a file to see exactly what changed.	143
10	129	The commit dialog lists all the items that will be included in a commit, and each item has a checkbox so you can choose which items you want to include. Unversioned files can also be listed, in case you forgot to add that new file.	147
11	133	Easy access to Subversion commands	151
12	137	All Subversion commands are available from the explorer context menu. TortoiseSVN adds its own submenu there.	155
13	141	Since TortoiseSVN is a Subversion client, we would also like to show you some of the features of Subversion itself:	159
14	145	Directory versioning	163
15	149	CVS only tracks the history of individual files, but Subversion implements a virtual versioned filesystem that tracks changes to whole directory trees over time. Files and directories are versioned. As a result, there are real client-side move and copy commands that operate on files and directories.	167
16	153	Atomic commits	171
17	157	A commit either goes into the repository completely, or not at all. This allows developers to construct and commit changes as logical chunks.	175
18	161	Versioned metadata	179
19	165	Each file and directory has an invisible set of properties attached. You can invent and store any arbitrary key/value pairs you wish. Properties are versioned over time, just like file contents.	183
20	169	Choice of network layers	187
21	173	Subversion has an abstracted notion of repository access, making it easy for people to implement new network mechanisms. Subversion's advanced network server is a module for the Apache web server, which speaks a variant of HTTP called WebDAV/DeltaV. This gives Subversion a big advantage in stability and interoperability, and provides various key features for free: authentication, authorization, wire compression, and repository browsing, for example. A smaller, standalone Subversion server process is also available. This server speaks a custom protocol which can be easily tunneled over ssh.	191
22	177	Consistent data handling	195
23	181	Subversion expresses file differences using a binary differencing algorithm, which works identically on both text (human-readable) and binary (human-unreadable) files. Both types of files are stored equally compressed in the repository, and differences are transmitted in both directions across the network.	199
24	185	Efficient branching and tagging	203
25	189	The cost of branching and tagging need not be proportional to the project size. Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard-link. Thus these operations take only a very small, constant amount of time, and very little space in the repository.	207
26	193	License	211
27	197	TortoiseSVN is an Open Source project developed under the GNU General Public License (GPL). It is free to download and free to use, either personally or commercially, on any number of PCs.	215
28	201	Although most people just download the installer, you also have full read access to the source code of this program. You can browse it on this link http://code.google.com/p/tortoisesvn/source/browse/. The current development line is located under /trunk/, and the released versions are located under /tags/.	219
29	205	Development	223
30	217	In 2002, Tim Kemp found that Subversion was a very good version control system, but it lacked a good GUI client. The idea for a Subversion client as a Windows shell integration was inspired by the similar client for CVS named TortoiseCVS. Tim studied the source code of TortoiseCVS and used it as a base for TortoiseSVN. He then started the project, registered the domain tortoisesvn.org and put the source code online.	236
31	221	Around that time, Stefan Küng was looking for a good and free version control system and found Subversion and the source for TortoiseSVN. Since TortoiseSVN was still not ready for use, he joined the project and started programming. He soon rewrote most of the existing code and started adding commands and features, up to a point where nothing of the original code remained.	240
32	225	As Subversion became more stable it attracted more and more users who also started using TortoiseSVN as their Subversion client. The user base grew quickly (and is still growing every day). That's when Lübbe Onken offered to help out with some nice icons and a logo for TortoiseSVN. He now takes care of the website and manages the many translations.	244
33	269	for the log cache and revision graph	290
34	277	for the great introduction to Subversion and its chapter 2 which we copied here	298
35	285	for some of the styles which are reused in this documentation	306
36	293	for the patches, bug reports and new ideas, and for helping others by answering questions on our mailing list	314
37	313	This explains what TortoiseSVN is, a little about the TortoiseSVN project and the community of people who work on it, and the licensing conditions for using it and distributing it.	335
38	317	The explains how to install TortoiseSVN on your PC, and how to start using it straight away.	339
39	321	In we give a short introduction to the Subversion revision control system which underlies TortoiseSVN. This is borrowed from the documentation for the Subversion project and explains the different approaches to version control, and how Subversion works.	343
40	325	The chapter on explains how to set up a local repository, which is useful for testing Subversion and TortoiseSVN using a single PC. It also explains a bit about repository administration which is also relevant to repositories located on a server. There is also a section here on how to setup a server if you need one.	347
41	329	The is the most important section as it explains all the main features of TortoiseSVN and how to use them. It takes the form of a tutorial, starting with checking out a working copy, modifying it, committing your changes, etc. It then progresses to more advanced topics.	351
42	333	is a separate program included with TortoiseSVN which can extract the information from your working copy and write it into a file. This is useful for including build information in your projects.	355
43	337	The section answers some common questions about performing tasks which are not explicitly covered elsewhere.	359
44	341	The section on shows how the TortoiseSVN GUI dialogs can be called from the command line. This is useful for scripting where you still need user interaction.	363
45	345	The give a correlation between TortoiseSVN commands and their equivalents in the Subversion command line client svn.exe.	367
46	353	To make reading the docs easier, the names of all the screens and Menus from TortoiseSVN are marked up in a different font. The Log Dialog for instance.	375
47	357	A menu choice is indicated with an arrow. TortoiseSVNShow Log means: select Show Log from the TortoiseSVN context menu.	379
48	361	Where a local context menu appears within one of the TortoiseSVN dialogs, it is shown like this: Context MenuSave As ...	383
49	365	User Interface Buttons are indicated like this: Press OK to continue.	387
50	369	User Actions are indicated using a bold font. Alt+A: press the Alt-Key on your keyboard and while holding it down press the A-Key as well. Right-drag: press the right mouse button and while holding it down drag the items to the new location.	391
51	373	System output and keyboard input is indicated with a different font as well.	395
52	385	Places where you have to be careful what you are doing.	407
53	389	Where extreme care has to be taken. Data corruption or other nasty things may occur if these warnings are ignored.	411
54	394	Getting Started	416
55	398	This section is aimed at people who would like to find out what TortoiseSVN is all about and give it a test drive. It explains how to install TortoiseSVN and set up a local repository, and it walks you through the most commonly used operations.	420
56	402	Installing TortoiseSVN	424
57	406	System requirements	428
58	410	TortoiseSVN runs on Windows XP or higher and is available in both 32-bit and 64-bit flavours. If you are running 64-bit Windows you may want to install both versions.	432
59	414	Support for Windows 98, Windows ME and Windows NT4 was dropped in version 1.2.0 and Windows 2000 support was dropped in 1.7.0. You can still download and install older versions if you need them.	436
60	418	Installation	440
61	422	install	444
62	426	TortoiseSVN comes with an easy to use installer. Double click on the installer file and follow the instructions. The installer will take care of the rest. Don't forget to reboot after installation.	448
63	430	You need Administrator privileges to install TortoiseSVN.	452
64	434	Language packs are available which translate the TortoiseSVN user interface into many different languages. Please check for more information on how to install these.	456
65	438	If you encounter any problems during or after installing TortoiseSVN please refer to our online FAQ at http://tortoisesvn.tigris.org/faq.html	460
66	442	Basic Concepts	464
67	446	Before we get stuck into working with some real files, it is important to get an overview of how subversion works and the terms that are used.	468
68	453	The Repository	475
69	457	Subversion uses a central database which contains all your version-controlled files with their complete history. This database is referred to as the repository. The repository normally lives on a file server running the Subversion server program, which supplies content to Subversion clients (like TortoiseSVN) on request. If you only back up one thing, back up your repository as it is the definitive master copy of all your data.	479
70	466	This is where you do the real work. Every developer has his own working copy, sometimes known as a sandbox, on his local PC. You can pull down the latest version from the repository, work on it locally without affecting anyone else, then when you are happy with the changes you made commit them back to the repository.	488
71	470	A Subversion working copy does not contain the history of the project, but it does keep a copy of the files as they exist in the repository before you started making changes. This means that it is easy to check exactly what changes you have made.	492
72	475	The TortoiseSVN menu for unversioned folders	497
73	479	You also need to know where to find TortoiseSVN because there is not much to see from the Start Menu. This is because TortoiseSVN is a Shell extension, so first of all, start Windows Explorer. Right click on a folder in Explorer and you should see some new entries in the context menu like this:	501
74	483	Go for a Test Drive	505
75	487	This section shows you how to try out some of the most commonly used features on a small test repository. Naturally it doesn't explain everything - this is just the Quick Start Guide after all. Once you are up and running you should take the time to read the rest of this user guide, which takes you through things in much more detail. It also explains more about setting up a proper Subversion server.	509
76	495	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.	518
77	499	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 TortoiseSVNCreate Repository here.... The repository is then created inside the folder, ready for you to use.	522
78	503	The local repository feature is very useful for test and evaluation but unless you are working as a sole developer on one PC you should always use a proper Subversion server. It is tempting in a small company to avoid the work of setting up a server and just access your repository on a network share. Don't ever do that. You will lose data. Read to find out why this is a bad idea, and how to set up a server.	526
79	507	Importing a Project	530
80	512	The Import dialog	535
81	516	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 TortoiseSVNImport... which brings up a dialog 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/Widget1 Note that there are 3 slashes after file: and that the forward slashes are used throughout.	539
82	520	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.	543
83	528	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 TortoiseSVNCheckout.... Enter the URL to checkout, in this case file:///c:/svn_repos/Widget1 and click on OK. Our development folder is then populated with files from the repository.	552
84	532	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.	556
85	536	Making Changes	560
86	540	Time to get to work. In the Widget1-Dev 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.	564
87	544	File Difference Viewer	568
88	548	But what are the changes? Right click on one of the changed files and select TortoiseSVNDiff. TortoiseSVN's file compare tool starts, showing you exactly which lines have changed.	572
89	552	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 TortoiseSVNCommit. 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.	576
90	556	Adding More Files	580
91	560	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 TortoiseSVNAdd. 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 TortoiseSVNAdd.	584
92	564	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.	588
93	568	Viewing the Project History	592
94	572	The Log Dialog	596
95	576	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 ;-) OK, so I cheated a little here and used a screenshot from the TortoiseSVN repository.	600
96	580	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.	604
97	584	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 to get the full story.	608
98	588	Undoing Changes	612
99	592	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.	616
100	596	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, TortoiseSVNRevert 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.	620
101	600	If you want to undo the effects of a particular revision, start with the Log dialog and find the offending revision. Select Context MenuRevert changes from this revision and those changes will be undone.	624
102	604	Moving On ...	628
103	608	This guide has given you a very quick tour of some of TortoiseSVN's most important and useful features, but of course there is far more that we haven't covered. We strongly recommend that you take the time to read the rest of this manual, especially which gives you a lot more detail on day-to-day operations.	632
104	612	We have taken a lot of trouble to make sure that it is both informative and easy to read, but we recognise that there is a lot of it! Take your time and don't be afraid to try things out on a test repository as you go along. The best way to learn is by using it.	636
105	616	Basic Version-Control Concepts	640
106	620	Subversion book	644
107	624	This chapter is a slightly modified version of the same chapter in the Subversion book. An online version of the Subversion book is available here: http://svnbook.red-bean.com/.	648
108	628	This chapter is a short, casual introduction to Subversion. If you're new to version control, this chapter is definitely for you. We begin with a discussion of general version control concepts, work our way into the specific ideas behind Subversion, and show some simple examples of Subversion in use.	652
109	632	Even though the examples in this chapter show people sharing collections of program source code, keep in mind that Subversion can manage any sort of file collection - it's not limited to helping computer programmers.	656
110	637	repository	661
111	641	Subversion is a centralized system for sharing information. At its core is a repository, which is a central store of data. The repository stores information in the form of a filesystem tree - a typical hierarchy of files and directories. Any number of clients connect to the repository, and then read or write to these files. By writing data, a client makes the information available to others; by reading data, the client receives information from others.	665
112	645	A Typical Client/Server System	669
113	649	So why is this interesting? So far, this sounds like the definition of a typical file server. And indeed, the repository is a kind of file server, but it's not your usual breed. What makes the Subversion repository special is that it remembers every change ever written to it: every change to every file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangement of files and directories.	673
114	653	When a client reads data from the repository, it normally sees only the latest version of the filesystem tree. But the client also has the ability to view previous states of the filesystem. For example, a client can ask historical questions like, what did this directory contain last Wednesday?, or who was the last person to change this file, and what changes did they make? These are the sorts of questions that are at the heart of any version control system: systems that are designed to record and track changes to data over time.	677
115	657	Versioning Models	681
116	661	All version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.	685
117	665	The Problem of File-Sharing	689
118	669	Consider this scenario: suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost - or at least missing from the latest version of the file - and probably by accident. This is definitely a situation we want to avoid!	693
119	673	The Problem to Avoid	697
120	678	The Lock-Modify-Unlock Solution	702
121	682	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.	706
122	686	The problem with the lock-modify-unlock model is that it's a bit restrictive, and often becomes a roadblock for users:	710
123	690	Locking may cause administrative problems. Sometimes Harry will lock a file and then forget about it. Meanwhile, because Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an administrator to release Harry's lock. The situation ends up causing a lot of unnecessary delay and wasted time.	714
124	694	Locking may cause unnecessary serialization. What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don't overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There's no need for them to take turns in this situation.	718
125	698	Locking may create a false sense of security. Pretend that Harry locks and edits file A, while Sally simultaneously locks and edits file B. But suppose that A and B depend on one another, and the changes made to each are semantically incompatible. Suddenly A and B don't work together anymore. The locking system was powerless to prevent the problem - yet it somehow provided a sense of false security. It's easy for Harry and Sally to imagine that by locking files, each is beginning a safe, insulated task, and thus inhibits them from discussing their incompatible changes early on.	722
126	703	The Copy-Modify-Merge Solution	727
127	707	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.	731
128	711	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.	735
129	715	...Copy-Modify-Merge Continued	739
130	720	conflict	744
131	724	But what if Sally's changes do overlap with Harry's changes? What then? This situation is called a conflict, and it's usually not much of a problem. When Harry asks his client to merge the latest repository changes into his working copy, his copy of file A is somehow flagged as being in a state of conflict: he'll be able to see both sets of conflicting changes, and manually choose between them. Note that software can't automatically resolve conflicts; only humans are capable of understanding and making the necessary intelligent choices. Once Harry has manually resolved the overlapping changes (perhaps by discussing the conflict with Sally!), he can safely save the merged file back to the repository.	748
132	728	The copy-modify-merge model may sound a bit chaotic, but in practice, it runs extremely smoothly. Users can work in parallel, never waiting for one another. When they work on the same files, it turns out that most of their concurrent changes don't overlap at all; conflicts are infrequent. And the amount of time it takes to resolve conflicts is far less than the time lost by a locking system.	752
133	732	In the end, it all comes down to one critical factor: user communication. When users communicate poorly, both syntactic and semantic conflicts increase. No system can force users to communicate perfectly, and no system can detect semantic conflicts. So there's no point in being lulled into a false promise that a locking system will somehow prevent conflicts; in practice, locking seems to inhibit productivity more than anything else.	756
134	736	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.	760
135	740	What does Subversion Do?	764
136	744	Subversion uses the copy-modify-merge solution by default, and in many cases this is all you will ever need. However, as of Version 1.2, Subversion also supports file locking, so if you have unmergeable files, or if you are simply forced into a locking policy by management, Subversion will still provide the features you need.	768
137	748	Subversion in Action	772
138	752	Working Copies	776
139	756	working copy	780
140	760	You've already read about working copies; now we'll demonstrate how the Subversion client creates and uses them.	784
141	764	A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish, and if they're source code files, you can compile your program from them in the usual way. Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so.	788
142	768	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).	792
143	772	A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, each directory in your working copy contains a subdirectory named .svn, also known as the working copy administrative directory. The files in each administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work.	796
144	776	A typical Subversion repository often holds the files (or source code) for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository.	800
145	780	For example, suppose you have a repository that contains two software projects.	804
146	784	The Repository's Filesystem	808
147	788	In other words, the repository's root directory has two subdirectories: paint and calc.	812
148	792	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).	816
149	796	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.	820
150	800	To publish your changes to others, you can use Subversion's commit command.	824
151	804	Now your changes to button.c have been committed to the repository; if another user checks out a working copy of /calc, they will see your changes in the latest version of the file.	828
152	808	Suppose you have a collaborator, Sally, who checked out a working copy of /calc at the same time you did. When you commit your change to button.c, Sally's working copy is left unchanged; Subversion only modifies working copies at the user's request.	832
153	812	To bring her project up to date, Sally can ask Subversion to update her working copy, by using the Subversion update command. This will incorporate your changes into her working copy, as well as any others that have been committed since she checked it out.	836
154	816	Note that Sally didn't need to specify which files to update; Subversion uses the information in the .svn directory, and further information in the repository, to decide which files need to be brought up to date.	840
155	820	Repository URLs	844
156	824	Subversion repositories can be accessed through many different methods - on local disk, or through various network protocols. A repository location, however, is always a URL. The URL schema indicates the access method:	848
157	828	Repository Access URLs	852
158	832	Schema	856
159	836	Access Method	860
160	844	Direct repository access on local or network drive.	868
161	853	Access via WebDAV protocol to Subversion-aware Apache server.	877
162	861	Same as , but with SSL encryption.	885
163	876	Unauthenticated TCP/IP access via custom protocol to a server.	900
164	884	authenticated, encrypted TCP/IP access via custom protocol to a server.	908
165	888	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.	912
166	892	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:	916
167	896	\n file:///X:/path/to/repos\n ...\n file:///X|/path/to/repos\n ...\n	920
168	901	Note that a URL uses ordinary slashes even though the native (non-URL) form of a path on Windows uses backslashes.	930
169	905	You can safely access a FSFS repository via a network share, but you cannot access a BDB repository in this way.	934
170	910	Do not create or access a Berkeley DB repository on a network share. It cannot exist on a remote filesystem. Not even if you have the network drive mapped to a drive letter. If you attempt to use Berkeley DB on a network share, the results are unpredictable - you may see mysterious errors right away, or it may be months before you discover that your repository database is subtly corrupted.	939
171	914	Revisions	943
172	919	revision	948
173	923	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.	952
174	927	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.	956
175	931	Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered zero, and consists of nothing but an empty root directory.	960
176	935	A nice way to visualize the repository is as a series of trees. Imagine an array of revision numbers, starting at 0, stretching from left to right. Each revision number has a filesystem tree hanging below it, and each tree is a snapshot of the way the repository looked after each commit.	964
177	939	Global Revision Numbers	968
178	943	Unlike those of many other version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit. When a Subversion user talks about ``revision 5 of foo.c'', they really mean ``foo.c as it appears in revision 5.'' Notice that in general, revisions N and M of a file do not necessarily differ!	972
179	947	It's important to note that working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions. For example, suppose you check out a working copy from a repository whose most recent revision is 4:	976
180	956	At the moment, this working directory corresponds exactly to revision 4 in the repository. However, suppose you make a change to button.c, and commit that change. Assuming no other commits have taken place, your commit will create revision 5 of the repository, and your working copy will now look like this:	993
181	965	Suppose that, at this point, Sally commits a change to integer.c, creating revision 6. If you use svn update to bring your working copy up to date, then it will look like this:	1010
182	974	Sally's changes to integer.c will appear in your working copy, and your change will still be present in button.c. In this example, the text of Makefile is identical in revisions 4, 5, and 6, but Subversion will mark your working copy of Makefile with revision 6 to indicate that it is still current. So, after you do a clean update at the top of your working copy, it will generally correspond to exactly one revision in the repository.	1027
183	978	How Working Copies Track the Repository	1031
184	982	For each file in a working directory, Subversion records two essential pieces of information in the .svn/ administrative area:	1035
185	986	what revision your working file is based on (this is called the file's working revision), and	1039
186	990	a timestamp recording when the local copy was last updated by the repository.	1043
187	994	Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in:	1047
188	998	Unchanged, and current	1051
189	1002	The file is unchanged in the working directory, and no changes to that file have been committed to the repository since its working revision. A commit of the file will do nothing, and an update of the file will do nothing.	1055
190	1006	Locally changed, and current	1059
191	1010	The file has been changed in the working directory, and no changes to that file have been committed to the repository since its base revision. There are local changes that have not been committed to the repository, thus a commit of the file will succeed in publishing your changes, and an update of the file will do nothing.	1063
192	1014	Unchanged, and out-of-date	1067
193	1018	The file has not been changed in the working directory, but it has been changed in the repository. The file should eventually be updated, to make it current with the public revision. A commit of the file will do nothing, and an update of the file will fold the latest changes into your working copy.	1071
194	1022	Locally changed, and out-of-date	1075
195	1026	The file has been changed both in the working directory, and in the repository. A commit of the file will fail with an out-of-date error. The file should be updated first; an update command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.	1079
196	1030	Summary	1083
197	1034	We've covered a number of fundamental Subversion concepts in this chapter:	1087
198	1038	We've introduced the notions of the central repository, the client working copy, and the array of repository revision trees.	1091
199	1042	We've seen some simple examples of how two collaborators can use Subversion to publish and receive changes from one another, using the 'copy-modify-merge' model.	1095
200	1046	We've talked a bit about the way Subversion tracks and manages information in a working copy.	1099
201	1050	No matter which protocol you use to access your repositories, you always need to create at least one repository. This can either be done with the Subversion command line client or with TortoiseSVN.	1103
202	1054	If you haven't created a Subversion repository yet, it's time to do that now.	1107
203	1058	Repository Creation	1111
204	1062	create repository	1115
205	1066	You can create a repository with the FSFS backend or with the older Berkeley Database (BDB) format. The FSFS format is generally faster and easier to administer, and it works on network shares and Windows 98 without problems. The BDB format was once considered more stable simply because it has been in use for longer, but since FSFS has now been in use in the field for several years, that argument is now rather weak. Read Choosing a Data Store in the Subversion book for more information.	1119
206	1070	Creating a Repository with the Command Line Client	1123
207	1075	Create	1128
208	1079	Create an empty folder with the name SVN (e.g. D:\\SVN\\), which is used as root for all your repositories.	1132
209	1083	Create another folder MyNewRepository inside D:\\SVN\\.	1136
210	1087	Open the command prompt (or DOS-Box), change into D:\\SVN\\ and type \n svnadmin create --fs-type bdb MyNewRepository\n or \n svnadmin create --fs-type fsfs MyNewRepository\n	1140
211	1091	Now you've got a new repository located at D:\\SVN\\MyNewRepository.	1149
212	1095	Creating The Repository With TortoiseSVN	1153
213	1099	Open the windows explorer	1157
214	1103	Create a new folder and name it e.g. SVNRepository	1161
215	1107	Right-click on the newly created folder and select TortoiseSVNCreate Repository here....	1165
216	1111	A repository is then created inside the new folder. Don't edit those files yourself!!!. If you get any errors make sure that the folder is empty and not write protected.	1169
217	1115	You will also be asked whether you want to create a directory structure within the repository. Find out about layout options in .
218	1119	TortoiseSVN will set a custom folder icon when it creates a repository so you can identify local repositories more easily. If you create a repository using the official command line client this folder icon is not assigned.
219	1123	TortoiseSVN no longer offers the option to create BDB repositories, although you can still use the command line client to create them. FSFS repositories are generally easier for you to maintain, and also makes it easier for us to maintain TortoiseSVN due to compatibility issues between the different BDB versions.	1173
220	1127	TortoiseSVN does not support file:// access to BDB repositories due to these compatibility issues, although it will of course always support this repository format when accessed via a server through the svn://, http:// or https:// protocols.	1177
221	1131	Of course we also recommend that you don't use file:// access at all, apart from local testing purposes. Using a server is more secure and more reliable for all but single-developer use.	1181
222	1135	Local Access to the Repository	1185
223	1139	Access	1189
224	1143	UNC paths	1193
225	1147	To access your local repository you need the path to that folder. Just remember that Subversion expects all repository paths in the form file:///C:/SVNRepository/. Note the use of forward slashes throughout.	1197
226	1151	To access a repository located on a network share you can either use drive mapping, or you can use the UNC path. For UNC paths, the form is file://ServerName/path/to/repos/. Note that there are only 2 leading slashes here.	1201
227	1155	Prior to SVN 1.2, UNC paths had to be given in the more obscure form file:///\\ServerName/path/to/repos. This form is still supported, but not recommended.	1205
228	1159	Do not create or access a Berkeley DB repository on a network share. It cannot exist on a remote file system. Not even if you have the network drive mapped to a drive letter. If you attempt to use Berkeley DB on a network share, the results are unpredictable - you may see mysterious errors right away, or it may be months before you discover that your repository database is subtly corrupted.	1209
229	1163	Accessing a Repository on a Network Share	1213
230	1167	Network share	1217
231	1171	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.	1221
232	1175	Firstly you are giving every user direct write access to the repository, so any user could accidentally delete the entire repository or make it unusable in some other way.	1225
233	1179	Secondly not all network file sharing protocols support the locking that Subversion requires, so you may find your repository gets corrupted. It may not happen straight away, but one day two users will try to access the repository at the same time.	1229
234	1183	Thirdly the file permissions have to be set just so. You may just about get away with it on a native Windows share, but SAMBA is particularly difficult.	1233
235	1187	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 for guidelines on choosing and setting up a server.	1237
236	1191	Repository Layout	1241
237	1195	Before you import your data into the repository you should first think about how you want to organize your data. If you use one of the recommended layouts you will later have it much easier.	1245
238	1199	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:	1249
239	1208	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.
240	1212	If a repository contains multiple projects, people often index their layout by branch:	1266
241	1216	\n /trunk/paint\n /trunk/calc\n /branches/paint\n /branches/calc\n /tags/paint\n /tags/calc\n	1270
242	1221	...or by project:	1282
243	1225	\n /paint/trunk\n /paint/branches\n /paint/tags\n /calc/trunk\n /calc/branches\n /calc/tags\n	1286
244	1230	Indexing by project makes sense if the projects are not closely related and each one is checked out individually. For related projects where you may want to check out all projects in one go, or where the projects are all tied together in a single distribution package, it is often better to index by branch. This way you have only one trunk to checkout, and the relationships between the sub-projects is more easily visible.	1298
245	1234	If you adopt a top level /trunk /tags /branches approach, there is nothing to say that you have to copy the entire trunk for every branch and tag, and in some ways this structure offers the most flexibility.	1302
246	1238	For unrelated projects you may prefer to use separate repositories. When you commit changes, it is the revision number of the whole repository which changes, not the revision number of the project. Having 2 unrelated projects share a repository can mean large gaps in the revision numbers. The Subversion and TortoiseSVN projects appear at the same host address, but are completely separate repositories allowing independent development, and no confusion over build numbers.	1306
247	1242	Of course, you're free to ignore these common layouts. You can create any sort of variation, whatever works best for you or your team. Remember that whatever you choose, it's not a permanent commitment. You can reorganize your repository at any time. Because branches and tags are ordinary directories, TortoiseSVN can move or rename them however you wish.	1310
248	1246	Switching from one layout to another is just a matter of issuing a series of server-side moves; If you don't like the way things are organized in the repository, just juggle the directories around.	1314
249	1250	create a new empty folder on your hard drive	1318
250	1254	create your desired top-level folder structure inside that folder - don't put any files in it yet!	1322
251	1258	import this structure into the repository via a right click on the folder that contains this folder structure and selecting TortoiseSVNImport... In the import dialog enter the URL to your repository and click OK. This will import your temp folder into the repository root to create the basic repository layout.	1326
252	1262	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:	1330
253	1266	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: \n C:\\Temp\\New\\trunk\n C:\\Temp\\New\\branches\n C:\\Temp\\New\\tags\n Import C:\\Temp\\New into the repository root, which will then look like this: \n /trunk\n /branches\n /tags\n	1334
254	1270	Repository Backup	1347
255	1274	backup	1351
256	1278	Whichever type of repository you use, it is vitally important that you maintain regular backups, and that you verify the backup. If the server fails, you may be able to access a recent version of your files, but without the repository all your history is lost forever.	1355
257	1282	The simplest (but not recommended) way is just to copy the repository folder onto the backup medium. However, you have to be absolutely sure that no process is accessing the data. In this context, access means any access at all. A BDB repository is written to even when the operation only appears to require reading, such as getting status. If your repository is accessed at all during the copy, (web browser left open, WebSVN, etc.) the backup will be worthless.	1359
258	1286	The recommended method is to run \n svnadmin hotcopy path/to/repository path/to/backup --clean-logs\n to create a copy of your repository in a safe manner. Then backup the copy. The --clean-logs option is not required, but removes any redundant log files when you backup a BDB repository, which may save some space.	1363
259	1290	The svnadmin tool is installed automatically when you install the Subversion command line client. If you are installing the command line tools on a Windows PC, the best way is to download the Windows installer version. It is compressed more efficiently than the .zip version, so the download is smaller, and it takes care of setting the paths for you. You can download the latest version of the Subversion command line client from http://subversion.apache.org/getting.html.	1370
260	1294	Server side hook scripts	1374
261	1298	hooks	1378
262	1303	hook scripts	1383
263	1307	server side hook scripts	1387
264	1311	A hook script is a program triggered by some repository event, such as the creation of a new revision or the modification of an unversioned property. Each hook is handed enough information to tell what that event is, what target(s) it's operating on, and the username of the person who triggered the event. Depending on the hook's output or return status, the hook program may continue the action, stop it, or suspend it in some way. Please refer to the chapter on Hook Scripts in the Subversion Book for full details about the hooks which are implemented.	1391
265	1315	These hook scripts are executed by the server that hosts the repository. TortoiseSVN also allows you to configure client side hook scripts that are executed locally upon certain events. See for more information.	1395
266	1319	Sample hook scripts can be found in the hooks directory of the repository. These sample scripts are suitable for Unix/Linux servers but need to be modified if your server is Windows based. The hook can be a batch file or an executable. The sample below shows a batch file which might be used to implement a pre-revprop-change hook. \n rem Only allow log messages to be changed.\n if \"%4\" == \"svn:log\" exit 0\n echo Property '%4' cannot be changed >&2\n exit 1\n Note that anything sent to stdout is discarded. if you want a message to appear in the Commit Reject dialog you must send it to stderr. In a batch file this is achieved using >&2	1399
267	1323	Overriding Hooks	1409
268	1327	If a hook script rejects your commit then its decision is final. But you can build an override mechanism into the script itself using the Magic Word technique. If the script wants to reject the operation it first scans the log message for a special pass phrase, either a fixed phrase or perhaps the filename with a prefix. If it finds the magic word then it allows the commit to proceed. If the phrase is not found then it can block the commit with a message like You didn't say the magic word :-)	1413
269	1331	Checkout Links	1417
270	1335	checkout link	1421
271	1339	TortoiseSVN link	1425
272	1343	link	1429
273	1347	website	1433
274	1351	If you want to make your Subversion repository available to others you may want to include a link to it from your website. One way to make this more accessible is to include a checkout link for other TortoiseSVN users.	1437
275	1355	When you install TortoiseSVN, it registers a new tsvn: protocol. When a TortoiseSVN user clicks on such a link, the checkout dialog will open automatically with the repository URL already filled in.	1441
276	1359	\n <a href=\"tsvn:http://project.domain.org/svn/trunk\">\n </a>\n	1445
277	1364	To include such a link in your own html page, you need to add code which looks something like this:	1453
278	1368	\n <a href=\"tsvn:http://project.domain.org/svn/trunk\">\n <img src=TortoiseCheckout.png></a>\n	1457
279	1373	Of course it would look even better if you included a suitable picture. You can use the TortoiseSVN logo or you can provide your own image.	1465
280	1377	\n <a href=\"tsvn:http://project.domain.org/svn/trunk?100\">\n </a>\n	1469
281	1382	You can also make the link point to a specific revision, for example	1477
282	1386	Accessing the Repository	1481
283	1390	To use TortoiseSVN (or any other Subversion client), you need a place where your repositories are located. You can either store your repositories locally and access them using the file:// protocol or you can place them on a server and access them with the http:// or svn:// protocols. The two server protocols can also be encrypted. You use https:// or svn+ssh://, or you can use svn:// with SASL.	1485
284	1394	If you are using a public hosting service such as Google Code or your server has already been setup by someone else then there is nothing else you need to do. Move along to .	1489
285	1398	If you don't have a server and you work alone, or if you are just evaluating Subversion and TortoiseSVN in isolation, then local repositories are probably your best choice. Just create a repository on your own PC as described earlier in . You can skip the rest of this chapter and go directly to to find out how to start using it.	1493
286	1402	If you were thinking about setting up a multi-user repository on a network share, think again. Read to find out why we think this is a bad idea. Setting up a server is not as hard as it sounds, and will give you better reliability and probably speed too.	1497
287	1406	The next sections are a step-by-step guide on how you can set up such a server on a Windows machine. Of course you can also set up a server on a Linux machine, but that is beyond the scope of this guide. More detailed information on the Subversion server options, and how to choose the best architecture for your situation, can be found in the Subversion book under Server Configuration.	1501
288	1410	Svnserve Based Server	1505
289	1419	Subversion includes Svnserve - a lightweight stand-alone server which uses a custom protocol over an ordinary TCP/IP connection. It is ideal for smaller installations, or where a full blown Apache server cannot be used.	1514
290	1423	In most cases svnserve is easier to setup and runs faster than the Apache based server, although it doesn't have some of the advanced features. And now that SASL support is included it is easy to secure as well.	1518
291	1427	Installing svnserve	1522
292	1431	Get the latest version of Subversion from http://subversion.apache.org/getting.html. Alternatively get a pre-packaged installer from CollabNet at http://www.collab.net/downloads/subversion. This installer will setup svnserve as a Windows service, and also includes some of the tools you need if you are going to use SASL for security.	1526
293	1435	If you already have a version of Subversion installed, and svnserve is running, you will need to stop it before continuing.	1530
294	1439	Run the Subversion installer. If you run the installer on your server (recommended) you can skip step 4.	1534
295	1443	Open the windows-explorer, go to the installation directory of Subversion (usually C:\\Program Files\\Subversion) and in the bin directory, find the files svnserve.exe, intl3_svn.dll, libapr.dll, libapriconv.dll, libapriutil.dll, libdb*.dll, libeay32.dll and ssleay32.dll - copy these files, or just copy all of the bin directory, into a directory on your server e.g. c:\\svnserve	1538
296	1447	Running svnserve	1542
297	1451	Now that svnserve is installed, you need it running on your server. The simplest approach is to run the following from a DOS shell or create a windows shortcut: \n svnserve.exe --daemon\n svnserve will now start waiting for incoming requests on port 3690. The --daemon switch tells svnserve to run as a daemon process, so it will always exist until it is manually terminated.	1546
298	1455	If you have not yet created a repository, follow the instructions given with the Apache server setup .	1553
299	1459	To test that svnserve is working, use TortoiseSVNRepo-Browser to view a repository.	1557
300	1463	Assuming your repository is located in c:\\repos\\TestRepo, and your server is called localhost, enter: \n svn://localhost/repos/TestRepo\n when prompted by the repo browser.	1561
301	1467	You can also increase security and save time entering URLs with svnserve by using the --root switch to set the root location and restrict access to a specified directory on the server: \n svnserve.exe --daemon --root drive:\\path\\to\\repository\\root\n Using the previous test as a guide, svnserve would now run as: \n svnserve.exe --daemon --root c:\\repos\n And in TortoiseSVN our repo-browser URL is now shortened to: \n svn://localhost/TestRepo\n Note that the --root switch is also needed if your repository is located on a different partition or drive than the location of svnserve on your server.	1568
302	1471	Svnserve will service any number of repositories. Just locate them somewhere below the root folder you just defined, and access them using a URL relative to that root.	1579
303	1475	Run svnserve as a Service	1583
304	1479	Running svnserve as a user is usually not the best way. It means always having a user logged in on your server, and remembering to restart it after a reboot. A better way is to run svnserve as a windows service. Starting with Subversion 1.4, svnserve can be installed as a native windows service.	1587
305	1483	To install svnserve as a native windows service, execute the following command all on one line to create a service which is automatically started when windows starts. \n sc create svnserve binpath= \"c:\\svnserve\\svnserve.exe --service\n --root c:\\repos\" displayname= \"Subversion\" depend= tcpip\n start= auto\n If any of the paths include spaces, you have to use (escaped) quotes around the path, like this: \n sc create svnserve binpath= \"\n \\\"C:\\Program Files\\Subversion\\bin\\svnserve.exe\\\"\n --service --root c:\\repos\" displayname= \"Subversion\"\n depend= tcpip start= auto\n You can also add a description after creating the service. This will show up in the Windows Services Manager. \n sc description svnserve \"Subversion server (svnserve)\"\n	1591
306	1487	Note the rather unusual command line format used by sc. In the key= value pairs there must be no space between the key and the = but there must be a space before the value.	1607
307	1491	Microsoft now recommend services to be run as under either the Local Service or Network Service account. Refer to The Services and Service Accounts Security Planning Guide. To create the service under the Local Service account, append the following to the example above. \n obj= \"NT AUTHORITY\\LocalService\"\n Note that you would have to give the Local Service account appropriate rights to both Subversion and your repositories, as well as any applications which are used by hook scripts. The built-in group for this is called \"LOCAL SERVICE\".	1611
308	1495	Once you have installed the service, you need to go to the services manager to start it (this time only; it will start automatically when the server reboots).	1618
309	1499	For more detailed information, refer to Windows Service Support for Svnserve.	1622
310	1503	If you installed an earlier version of svnserve using the SVNService wrapper, and you now want to use the native support instead, you will need to unregister the wrapper as a service (remember to stop the service first!). Simply use the command \n svnservice -remove\n to remove the service registry entry.	1626
311	1507	Basic Authentication with svnserve	1633
312	1511	The default svnserve setup provides anonymous read-only access. This means that you can use an svn:// URL to checkout and update, or use the repo-browser in TortoiseSVN to view the repository, but you won't be able to commit any changes.	1637
313	1515	To enable write access to a repository, you need to edit the conf/svnserve.conf file in your repository directory. This file controls the configuration of the svnserve daemon, and also contains useful documentation.	1641
314	1519	You can enable anonymous write access by simply setting: \n [general]\n anon-access = write\n However, you will not know who has made changes to a repository, as the svn:author property will be empty. You will also be unable to control who makes changes to a repository. This is a somewhat risky setup!	1645
315	1523	One way to overcome this is to create a password database: \n [general]\n anon-access = none\n auth-access = write\n password-db = userfile\n Where userfile is a file which exists in the same directory as svnserve.conf. This file can live elsewhere in your file system (useful for when you have multiple repositories which require the same access rights) and may be referenced using an absolute path, or a path relative to the conf directory. If you include a path, it must be written /the/unix/way. Using \\ or drive letters will not work. The userfile should have a structure of: \n [users]\n username = password\n ...\n This example would deny all access for unauthenticated (anonymous) users, and give read-write access to users listed in userfile.	1653
316	1527	If you maintain multiple repositories using the same password database, the use of an authentication realm will make life easier for users, as TortoiseSVN can cache your credentials so that you only have to enter them once. More information can be found in the Subversion book, specifically in the sections Create a 'users' file and realm and Client Credentials Caching	1667
317	1531	Better Security with SASL	1671
318	1539	What is SASL?	1679
319	1543	The Cyrus Simple Authentication and Security Layer is open source software written by Carnegie Mellon University. It adds generic authentication and encryption capabilities to any network protocol, and as of Subversion 1.5 and later, both the svnserve server and TortoiseSVN client know how to make use of this library.	1683
320	1547	For a more complete discussion of the options available, you should look at the Subversion book in the section Using svnserve with SASL. If you are just looking for a simple way to set up secure authentication and encryption on a Windows server, so that your repository can be accessed safely over the big bad Internet, read on.	1687
321	1551	SASL Authentication	1691
322	1555	To activate specific SASL mechanisms on the server, you'll need to do three things. First, create a [sasl] section in your repository's svnserve.conf file, with this key-value pair: \n use-sasl = true\n	1695
323	1559	Second, create a file called svn.conf in a convenient location - typically in the directory where subversion is installed.	1702
324	1563	Thirdly, create two new registry entries to tell SASL where to find things. Create a registry key named [HKEY_LOCAL_MACHINE\\SOFTWARE\\Carnegie Mellon\\Project Cyrus\\SASL Library] and place two new string values inside it: SearchPath set to the directory path containing the sasl*.dll plug-ins (normally in the Subversion install directory), and ConfFile set to the directory containing the svn.conf file. If you used the CollabNet installer, these registry keys will already have been created for you.	1706
325	1567	Edit the svn.conf file to contain the following: \n pwcheck_method: auxprop\n auxprop_plugin: sasldb\n mech_list: DIGEST-MD5\n sasldb_path: C:\\TortoiseSVN\\sasldb\n The last line shows the location of the authentication database, which is a file called sasldb. This could go anywhere, but a convenient choice is the repository parent path. Make sure that the svnserve service has read access to this file.	1710
326	1571	If svnserve was already running, you will need to restart it to ensure it reads the updated configuration.	1720
327	1575	Now that everything is set up, all you need to do is create some users and passwords. To do this you need the saslpasswd2 program. If you used the CollabNet installer, that program will be in the install directory. Use a command something like this: \n saslpasswd2 -c -f C:\\TortoiseSVN\\sasldb -u realm username\n The -f switch gives the database location, realm must be the same as the value you defined in your repository's svnserve.conf file, and username is exactly what you expect it to be. Note that the realm is not allowed to contain space characters.	1724
328	1579	You can list the usernames stored in the database using the sasldblistusers2 program.	1731
329	1583	SASL Encryption	1735
330	1587	To enable or disable different levels of encryption, you can set two values in your repository's svnserve.conf file: \n [sasl]\n use-sasl = true\n min-encryption = 128\n max-encryption = 256\n	1739
331	1591	The min-encryption and max-encryption variables control the level of encryption demanded by the server. To disable encryption completely, set both values to 0. To enable simple checksumming of data (i.e., prevent tampering and guarantee data integrity without encryption), set both values to 1. If you wish to allow (but not require) encryption, set the minimum value to 0, and the maximum value to some bit-length. To require encryption unconditionally, set both values to numbers greater than 1. In our previous example, we require clients to do at least 128-bit encryption, but no more than 256-bit encryption.	1749
332	1595	Authentication with svn+ssh	1753
333	1599	Another way to authenticate users with a svnserve based server is to use a secure shell (SSH) to tunnel requests through. It is not as simple to set up as SASL, but it may be useful is some cases.	1757
334	1603	With this approach, svnserve is not run as a daemon process, rather, the secure shell starts svnserve for you, running it as the SSH authenticated user. To enable this, you need a secure shell daemon on your server.	1761
335	1607	A basic method for setting up your server is given in . You can find other SSH topics within the FAQ by searching for SSH.	1765
336	1611	Further information about svnserve can be found in the Version Control with Subversion.	1769
337	1615	Path-based Authorization with svnserve	1773
338	1619	Starting with Subversion 1.3, svnserve supports the same mod_authz_svn path-based authorization scheme that is available with the Apache server. You need to edit the conf/svnserve.conf file in your repository directory and add a line referring to your authorization file. \n [general]\n authz-db = authz\n Here, authz is a file you create to define the access permissions. You can use a separate file for each repository, or you can use the same file for several repositories. Read for a description of the file format.	1777
339	1623	Apache Based Server	1785
340	1631	The most flexible of all possible server setups for Subversion is the Apache based one. Although a bit more complicated to set up, it offers benefits that other servers cannot:	1793
341	1640	The Apache based Subversion server uses the WebDAV protocol which is supported by many other programs as well. You could e.g. mount such a repository as a Web folder in the Windows explorer and then access it like any other folder in the file system.	1802
342	1644	Browsing The Repository	1806
343	1648	You can point your browser to the URL of your repository and browse the contents of it without having a Subversion client installed. This gives access to your data to a much wider circle of users.	1810
344	1653	Authentication	1815
345	1657	You can use any authentication mechanism Apache supports, including SSPI and LDAP.	1819
346	1661	Security	1823
347	1665	Since Apache is very stable and secure, you automatically get the same security for your repository. This includes SSL encryption.	1827
348	1669	Installing Apache	1831
349	1673	Please note that Windows XP without the service pack 1 will lead to bogus network data and could therefore corrupt your repository!	1835
350	1677	Download the latest version of the Apache web server from http://httpd.apache.org/download.cgi. Make sure that you download the version 2.2.x - the version 1.3.xx won't work!	1839
351	1681	The msi installer for Apache can be found by clicking on other files, then browse to binaries/win32. You may want to choose the msi file apache-2.2.x-win32-x86-openssl-0.9.x.msi (the one that includes OpenSSL).	1843
352	1685	Once you have the Apache2 installer you can double click on it and it will guide you through the installation process. Make sure that you enter the server-URL correctly (if you don't have a DNS name for your server just enter the IP-address). I recommend to install Apache for All Users, on Port 80, as a Service. Note: if you already have IIS or any other program running which listens on port 80 the installation might fail. If that happens, go to the programs directory, \\Apache Group\\Apache2\\conf and locate the file httpd.conf. Edit that file so that Listen 80 is changed to a free port, e.g. Listen 81. Then restart the installation - this time it should finish without problems.	1847
353	1689	Now test if the Apache web server is running correctly by pointing your web browser to http://localhost/ - a preconfigured Website should show up.	1851
354	1693	If you decide to install Apache as a service, be warned that by default it will run as the local system account. It would be a more secure practice for you to create a separate account for Apache to run as.	1855
355	1697	Make sure that the account on the server that Apache is running as has an explicit entry in the repository directory's access control list (right-click directory | properties | security), with full control. Otherwise, users will not be able to commit their changes.	1859
356	1701	Even if Apache runs as local system, you still need such an entry (which will be the SYSTEM account in this case).	1863
357	1705	If Apache does not have this permission set up, your users will get Access denied error messages, which show up in the Apache error log as error 500.	1867
358	1709	The first thing you need before installing Apache is a computer with Windows 2000, Windows XP+SP1, Windows 2003, Vista or Server 2008.	1871
359	1713	Installing Subversion	1875
360	1717	Download the latest version of the Subversion Win32 binaries for Apache. Be sure to get the right version to integrate with your version of Apache, otherwise you will get an obscure error message when you try to restart. If you have Apache 2.2.x go to http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100.	1879
361	1721	Run the Subversion installer and follow the instructions. If the Subversion installer recognized that you've installed Apache, then you're almost done. If it couldn't find an Apache server then you have to do some additional steps.	1883
362	1726	mod_authz_svn	1888
363	1730	Using the windows explorer, go to the installation directory of Subversion (usually c:\\program files\\Subversion) and find the files /httpd/mod_dav_svn.so and mod_authz_svn.so. Copy these files to the Apache modules directory (usually c:\\program files\\apache group\\apache2\\modules ).	1892
364	1734	Copy the file /bin/libdb*.dll and /bin/intl3_svn.dll from the Subversion installation directory to the Apache bin directory.	1896
365	1738	Edit Apache's configuration file (usually C:\\Program Files\\Apache Group\\Apache2\\conf\\httpd.conf) with a text editor such as Notepad and make the following changes:	1900
366	1742	Uncomment (remove the '#' mark) the following lines: \n #LoadModule dav_fs_module modules/mod_dav_fs.so\n #LoadModule dav_module modules/mod_dav.so\n Add the following two lines to the end of the LoadModule section. \n LoadModule dav_svn_module modules/mod_dav_svn.so\n LoadModule authz_svn_module modules/mod_authz_svn.so\n	1904
367	1746	Configuration	1915
368	1750	At the end of the config file add the following lines: \n <Location /svn>\n DAV svn\n SVNListParentPath on\n SVNParentPath D:\\SVN\n #SVNIndexXSLT \"/svnindex.xsl\"\n AuthType Basic\n AuthName \"Subversion repositories\"\n AuthUserFile passwd\n #AuthzSVNAccessFile svnaccessfile\n Require valid-user\n </Location>\n This configures Apache so that all your Subversion repositories are physically located below D:\\SVN. The repositories are served to the outside world from the URL: http://MyServer/svn/ . Access is restricted to known users/passwords listed in the passwd file.	1919
369	1754	To create the passwd file, open the command prompt (DOS-Box) again, change to the apache2 folder (usually c:\\program files\\apache group\\apache2) and create the file by entering \n bin\\htpasswd -c passwd <username>\n This will create a file with the name passwd which is used for authentication. Additional users can be added with \n bin\\htpasswd passwd <username>\n	1936
370	1758	Restart the Apache service again.	1945
371	1762	Point your browser to http://MyServer/svn/MyNewRepository (where MyNewRepository is the name of the Subversion repository you created before). If all went well you should be prompted for a username and password, then you can see the contents of your repository.	1949
372	1766	Now you have set up Apache and Subversion, but Apache doesn't know how to handle Subversion clients like TortoiseSVN yet. To get Apache to know which URL will be used for Subversion repositories you have to edit the Apache configuration file (usually located in c:\\program files\\apache group\\apache2\\conf\\httpd.conf) with any text editor you like (e.g. Notepad):	1953
373	1780	Apache httpd.conf Settings	1967
374	1784	Setting	1971
375	1788	Explanation	1975
376	1796	means that the Subversion repositories are available from the URL	1983
377	1800	tells Apache which module will be responsible to serve that URL - in this case the Subversion module.	1987
378	1804	For Subversion version 1.3 and higher, this directive enables listing all the available repositories under .	1991
379	1812	tells Subversion to look for repositories below	1999
380	1816	Used to make the browsing with a web browser prettier.	2003
381	1820	is to activate basic authentication, i.e. Username/password	2007
382	1824	is used as an information whenever an authentication dialog pops up to tell the user what the authentication is for	2011
383	1828	specifies which password file to use for authentication	2015
384	1832	Location of the Access file for paths inside a Subversion repository	2019
385	1836	specifies that only users who entered a correct username/password are allowed to access the URL	2023
386	1840	If you want your repository to have read access for everyone but write access only for specific users you can change the line \n Require valid-user\n to \n <LimitExcept GET PROPFIND OPTIONS REPORT>\n Require valid-user\n </LimitExcept>\n	2027
387	1844	Using a passwd file limits and grants access to all of your repositories as a unit. If you want more control over which users have access to each folder inside a repository you can uncomment the line \n #AuthzSVNAccessFile svnaccessfile\n and create a Subversion access file. Apache will make sure that only valid users are able to access your /svn location, and will then pass the username to Subversion's AuthzSVNAccessFile module so that it can enforce more granular access based upon rules listed in the Subversion access file. Note that paths are specified either as repos:path or simply path. If you don't specify a particular repository, that access rule will apply to all repositories under SVNParentPath. The format of the authorization-policy file used by mod_authz_svn is described in	2038
388	1848	To make browsing the repository with a web browser 'prettier', uncomment the line \n #SVNIndexXSLT \"/svnindex.xsl\"\n and put the files svnindex.xsl, svnindex.css and menucheckout.ico in your document root directory (usually C:/Program Files/Apache Group/Apache2/htdocs). The directory is set with the DocumentRoot directive in your Apache config file.	2045
389	1852	You can get those three files directly from our source repository at http://tortoisesvn.googlecode.com/svn/trunk/contrib/svnindex. ( explains how to access the TortoiseSVN source repository).	2052
390	1856	The XSL file from the TortoiseSVN repository has a nice gimmick: if you browse the repository with your web browser, then every folder in your repository has an icon on the right shown. If you click on that icon, the TortoiseSVN checkout dialog is started for this URL.	2056
391	1860	A short explanation of what you just entered: But that's just an example. There are many, many more possibilities of what you can do with the Apache web server.	2060
392	1864	Multiple Repositories	2064
393	1868	Index of projects	2068
394	1872	If you used the SVNParentPath directive then you don't have to change the Apache config file every time you add a new Subversion repository. Simply create the new repository under the same location as the first repository and you're done! In my company I have direct access to that specific folder on the server via SMB (normal windows file access). So I just create a new folder there, run the TortoiseSVN command TortoiseSVNCreate repository here... and a new project has a home...	2072
395	1876	If you are using Subversion 1.3 or later, you can use the SVNListParentPath on directive to allow Apache to produce a listing of all available projects if you point your browser at the parent path rather than at a specific repository.	2076
396	1880	Path-Based Authorization	2080
397	1884	Authorization	2084
398	1888	The mod_authz_svn module permits fine-grained control of access permissions based on user names and repository paths. This is available with the Apache server, and as of Subversion 1.3 it is available with svnserve as well.	2088
399	1892	An example file would look like this: \n [groups]\n admin = john, kate\n devteam1 = john, rachel, sally\n devteam2 = kate, peter, mark\n docs = bob, jane, mike\n training = zak\n # Default access rule for ALL repositories\n # Everyone can read, admins can write, Dan German is excluded.\n [/]\n * = r\n @admin = rw\n dangerman =\n # Allow developers complete access to their project repos\n [proj1:/]\n @devteam1 = rw\n [proj2:/]\n @devteam2 = rw\n [bigproj:/]\n @devteam1 = rw\n @devteam2 = rw\n trevor = rw\n # Give the doc people write access to all the docs folders\n [/trunk/doc]\n @docs = rw\n # Give trainees write access in the training repository only\n [TrainingRepos:/]\n @training = rw\n	2092
400	1896	Note that checking every path can be an expensive operation, particularly in the case of the revision log. The server checks every changed path in each revision and checks it for readability, which can be time-consuming on revisions which affect large numbers of files.	2125
401	1900	Authentication and authorization are separate processes. If a user wants to gain access to a repository path, she has to meet both, the usual authentication requirements and the authorization requirements of the access file.	2129
402	1904	Authentication With a Windows Domain	2133
403	1908	Windows domain	2137
404	1912	domaincontroller	2141
405	1916	As you might have noticed you need to make a username/password entry in the passwd file for each user separately. And if (for security reasons) you want your users to periodically change their passwords you have to make the change manually.	2145
406	1920	But there's a solution for that problem - at least if you're accessing the repository from inside a LAN with a windows domain controller: mod_auth_sspi!	2149
407	1932	The original SSPI module was offered by Syneapps including source code. But the development for it has been stopped. But don't despair, the community has picked it up and improved it. It has a new home on SourceForge.	2161
408	1936	Download the module which matches your apache version, then copy the file mod_auth_sspi.so into the Apache modules folder.	2165
409	1940	Edit the Apache config file: add the line \n LoadModule sspi_auth_module modules/mod_auth_sspi.so\n to the LoadModule section. Make sure you insert this line before the line \n LoadModule auth_module modules/mod_auth.so\n	2169
410	1944	To make the Subversion location use this type of authentication you have to change the line \n AuthType Basic\n to \n AuthType SSPI\n also you need to add \n SSPIAuth On\n SSPIAuthoritative On\n SSPIDomain <domaincontroller>\n SSPIOmitDomain on\n SSPIUsernameCase lower\n SSPIPerRequestAuth on\n SSPIOfferBasic On\n within the <Location /svn> block. If you don't have a domain controller, leave the name of the domain control as <domaincontroller>.	2178
411	1948	Note that if you are authenticating using SSPI, then you don't need the AuthUserFile line to define a password file any more. Apache authenticates your username and password against your windows domain instead. You will need to update the users list in your svnaccessfile to reference DOMAIN\\username as well.	2195
412	1952	The SSPI authentication is only enabled for SSL secured connections (https). If you're only using normal http connections to your server, it won't work.	2199
413	1956	To enable SSL on your server, see the chapter:	2203
414	1960	Subversion AuthzSVNAccessFile files are case sensitive in regard to user names (JUser is different from juser).	2207
415	1964	In Microsoft's world, Windows domains and user names are not case sensitive. Even so, some network administrators like to create user accounts in CamelCase (e.g. JUser).	2211
416	1968	This difference can bite you when using SSPI authentication as the windows domain and user names are passed to Subversion in the same case as the user types them in at the prompt. Internet Explorer often passes the username to Apache automatically using whatever case the account was created with.	2215
417	1972	The end result is that you may need at least two entries in your AuthzSVNAccessFile for each user -- a lowercase entry and an entry in the same case that Internet Explorer passes to Apache. You will also need to train your users to also type in their credentials using lower case when accessing repositories via TortoiseSVN.	2219
418	1976	Apache's Error and Access logs are your best friend in deciphering problems such as these as they will help you determine the username string passed onto Subversion's AuthzSVNAccessFile module. You may need to experiment with the exact format of the user string in the svnaccessfile (e.g. DOMAIN\\user vs. DOMAIN//user) in order to get everything working.	2223
419	1980	Multiple Authentication Sources	2227
420	1984	Multiple authentication	2231
421	1988	It is also possible to have more than one authentication source for your Subversion repository. To do this, you need to make each authentication type non-authoritative, so that Apache will check multiple sources for a matching username/password.	2235
422	1992	A common scenario is to use both Windows domain authentication and a passwd file, so that you can provide SVN access to users who don't have a Windows domain login.	2239
423	1996	To enable both Windows domain and passwd file authentication, add the following entries within the <Location> block of your Apache config file: \n AuthBasicAuthoritative Off\n SSPIAuthoritative Off\n	2243
424	2000	Here is an example of the full Apache configuration for combined Windows domain and passwd file authentication: \n <Location /svn>\n DAV svn\n SVNListParentPath on\n SVNParentPath D:\\SVN\n \n AuthName \"Subversion repositories\"\n AuthzSVNAccessFile svnaccessfile.txt\n \n # NT Domain Logins.\n AuthType SSPI\n SSPIAuth On\n SSPIAuthoritative Off\n SSPIDomain <domaincontroller>\n SSPIOfferBasic On\n \n # Htpasswd Logins.\n AuthType Basic\n AuthBasicAuthoritative Off\n AuthUserFile passwd\n \n Require valid-user\n </Location>\n	2251
425	2004	Securing the server with SSL	2279
426	2012	Even though Apache 2.2.x has OpenSSL support, it is not activated by default. You need to activate this manually.	2287
427	2016	In the apache config file, uncomment the lines: \n #LoadModule ssl_module modules/mod_ssl.so\n and at the bottom \n #Include conf/extra/httpd-ssl.conf\n then change the line (on one line) \n SSLMutex \"file:C:/Program Files/Apache Software Foundation/\\\n Apache2.2/logs/ssl_mutex\"\n to \n SSLMutex default\n	2291
428	2020	Next you need to create an SSL certificate. To do that open a command prompt (DOS-Box) and change to the Apache folder (e.g. C:\\program files\\apache group\\apache2) and type the following command: \n bin\\openssl req -config conf\\openssl.cnf -new -out my-server.csr\n You will be asked for a passphrase. Please don't use simple words but whole sentences, e.g. a part of a poem. The longer the phrase the better. Also you have to enter the URL of your server. All other questions are optional but we recommend you fill those in too.	2305
429	2024	Normally the privkey.pem file is created automatically, but if it isn't you need to type this command to generate it: \n bin\\openssl genrsa -out conf\\privkey.pem 2048\n	2312
430	2028	Next type the commands \n bin\\openssl rsa -in conf\\privkey.pem -out conf\\server.key\n and (on one line) \n bin\\openssl req -new -key conf\\server.key -out conf\\server.csr \\\n -config conf\\openssl.cnf\n and then (on one line) \n bin\\openssl x509 -in conf\\server.csr -out conf\\server.cert\n -req -signkey conf\\server.key -days 4000\n This will create a certificate which will expire in 4000 days. And finally enter (on one line): \n bin\\openssl x509 -in conf\\server.cert -out conf\\server.der.crt\n -outform DER\n These commands created some files in the Apache conf folder (server.der.crt, server.csr, server.key, .rnd, privkey.pem, server.cert).	2319
431	2032	Restart the Apache service.	2335
432	2036	Point your browser to https://servername/svn/project ...	2339
433	2040	SSL and Internet Explorer	2343
434	2044	If you're securing your server with SSL and use authentication against a windows domain you will encounter that browsing the repository with the Internet Explorer doesn't work anymore. Don't worry - this is only the Internet Explorer not able to authenticate. Other browsers don't have that problem and TortoiseSVN and any other Subversion client are still able to authenticate.	2347
435	2048	define a separate <Location /path> directive in the Apache config file, and add the SSPIBasicPreferred On. This will allow IE to authenticate again, but other browsers and Subversion won't be able to authenticate against that location.	2351
436	2052	Offer browsing with unencrypted authentication (without SSL) too. Strangely IE doesn't have any problems with authenticating if the connection is not secured with SSL.	2355
437	2056	In the SSL \"standard\" setup there's often the following statement in Apache's virtual SSL host: \n SetEnvIf User-Agent \".*MSIE.*\" \\\n nokeepalive ssl-unclean-shutdown \\\n downgrade-1.0 force-response-1.0\n There are (were?) good reasons for this configuration, see http://www.modssl.org/docs/2.8/ssl_faq.html#ToC49 But if you want NTLM authentication you have to use keepalive. If You uncomment the whole SetEnvIf you should be able to authenticate IE with windows authentication over SSL against the Apache on Win32 with included mod_auth_sspi.	2359
438	2060	If you still want to use IE to browse the repository you can either:	2368
439	2064	Forcing SSL access	2372
440	2068	When you've set up SSL to make your repository more secure, you might want to disable the normal access via non-SSL (http) and only allow https access. To do this, you have to add another directive to the Subversion <Location> block: SSLRequireSSL.	2376
441	2072	An example <Location> block would look like this: \n <Location /svn>\n DAV svn\n SVNParentPath D:\\SVN\n SSLRequireSSL\n AuthType Basic\n AuthName \"Subversion repositories\"\n AuthUserFile passwd\n #AuthzSVNAccessFile svnaccessfile\n Require valid-user\n </Location>\n	2380
442	2076	Using client certificates with virtual SSL hosts	2396
443	2080	Sent to the TortoiseSVN mailing list by Nigel Green. Thanks!	2400
444	2084	In some server configurations you may need to setup a single server containing 2 virtual SSL hosts: The first one for public web access, with no requirement for a client certificate. The second one to be secure with a required client certificate, running a Subversion server.	2404
445	2088	Adding an SSLVerifyClient Optional directive to the per-server section of the Apache configuration (i.e. outside of any VirtualHost and Directory blocks) forces Apache to request a client Certificate in the initial SSL handshake. Due to a bug in mod_ssl it is essential that the certificate is requested at this point as it does not work if the SSL connection is re-negotiated.	2408
446	2092	The solution is to add the following directive to the virtual host directory that you want to lock down for Subversion: \n SSLRequire %{SSL_CLIENT_VERIFY} eq \"SUCCESS\"\n This directive grants access to the directory only if a client certificate was received and verified successfully.	2412
447	2096	To summarise, the relevant lines of the Apache configuration are: \n SSLVerifyClient Optional\n \n ### Virtual host configuration for the PUBLIC host\n ### (not requiring a certificate)\n \n <VirtualHost 127.0.0.1:443>\n <Directory \"pathtopublicfileroot\">\n </Directory>\n </VirtualHost>\n \n ### Virtual host configuration for SUBVERSION\n ### (requiring a client certificate)\n <VirtualHost 127.0.0.1:443>\n <Directory \"subversion host root path\">\n SSLRequire %{SSL_CLIENT_VERIFY} eq \"SUCCESS\"\n </Directory>\n \n <Location /svn>\n DAV svn\n SVNParentPath /pathtorepository\n </Location>\n </VirtualHost>\n	2419
448	2100	Daily Use Guide	2447
449	2104	This document describes day to day usage of the TortoiseSVN client. It is not an introduction to version control systems, and not an introduction to Subversion (SVN). It is more like a place you may turn to when you know approximately what you want to do, but don't quite remember how to do it.	2451
450	2108	If you need an introduction to version control with Subversion, then we recommend you read the fantastic book: Version Control with Subversion.	2455
451	2112	This document is also a work in progress, just as TortoiseSVN and Subversion are. If you find any mistakes, please report them to the mailing list so we can update the documentation. Some of the screenshots in the Daily Use Guide (DUG) might not reflect the current state of the software. Please forgive us. We're working on TortoiseSVN in our free time.	2459
452	2116	You should have installed TortoiseSVN already.	2463
453	2120	You should be familiar with version control systems.	2467
454	2124	You should know the basics of Subversion.	2471
455	2128	You should have set up a server and/or have access to a Subversion repository.	2475
456	2132	In order to get the most out of the Daily Use Guide:	2479
457	2138	Icon Overlays	2485
458	2143	Explorer showing icon overlays	2490
459	2147	One of the most visible features of TortoiseSVN is the icon overlays which appear on files in your working copy. These show you at a glance which of your files have been modified. Refer to to find out what the different overlays represent.	2494
460	2151	Context Menus	2498
461	2155	context menu	2502
462	2159	right-click	2506
463	2163	Context menu for a directory under version control	2510
464	2167	All TortoiseSVN commands are invoked from the context menu of the windows explorer. Most are directly visible, when you right click on a file or folder. The commands that are available depend on whether the file or folder or its parent folder is under version control or not. You can also see the TortoiseSVN menu as part of the Explorer file menu.	2514
465	2171	Some commands which are very rarely used are only available in the extended context menu. To bring up the extended context menu, hold down the Shift key when you right-click.	2518
466	2175	Explorer file menu for a shortcut in a versioned folder	2522
467	2179	In some cases you may see several TortoiseSVN entries. This is not a bug! This example is for an unversioned shortcut within a versioned folder, and in the Explorer file menu there are three entries for TortoiseSVN. One is for the folder, one for the shortcut itself, and the third for the object the shortcut is pointing to. To help you distinguish between them, the icons have an indicator in the lower right corner to show whether the menu entry is for a file, a folder, a shortcut or for multiple selected items.	2526
468	2183	If you are using Windows 2000 you will find that the context menus are shown as plain text, without the menu icons shown above. We are aware that this was working in previous versions, but Microsoft has changed the way its icon handlers work for Vista, requiring us to use a different display method which unfortunately does not work on Windows 2000.	2530
469	2188	Drag and Drop	2535
470	2192	drag handler	2539
471	2196	drag-n-drop	2543
472	2200	right drag	2547
473	2205	Right drag menu for a directory under version control	2552
474	2209	Other commands are available as drag handlers, when you right drag files or folders to a new location inside working copies or when you right drag a non-versioned file or folder into a directory which is under version control.	2556
475	2213	Common Shortcuts	2560
476	2221	Help, of course.	2568
477	2229	Refresh the current view. This is perhaps the single most useful one-key command. For example ... In Explorer this will refresh the icon overlays on your working copy. In the commit dialog it will re-scan the working copy to see what may need to be committed. In the Revision Log dialog it will contact the repository again to check for more recent changes.	2576
478	2237	Select all. This can be used if you get an error message and want to copy and paste into an email. Use Ctrl-A to select the error message and then ...	2584
479	2245	... Copy the selected text.	2592
480	2249	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.	2596
481	2253	authentication	2600
482	2257	authentication cache	2604
483	2261	Authentication Dialog	2608
484	2265	svn.simple contains credentials for basic authentication (username/password). Note that passwords are stored using the WinCrypt API, not in plain text form.	2612
485	2269	svn.ssl.server contains SSL server certificates.	2616
486	2273	svn.username contains credentials for username-only authentication (no password needed).	2620
487	2277	If the repository that you are trying to access is password protected, an authentication Dialog will show up. Enter your username and password. The checkbox will make TortoiseSVN store the credentials in Subversion's default directory: %APPDATA%\\Subversion\\auth in three subdirectories:	2624
488	2281	If you want to clear the authentication cache for all servers, you can do so from the Saved Data page of TortoiseSVN's settings dialog. That button will clear all cached authentication data from the Subversion auth directories, as well as any authentication data stored in the registry by earlier versions of TortoiseSVN. Refer to .	2628
489	2285	If you want to clear authentication for one realm only then you will have to dig into those directories, find the file which contains the information you want to clear and delete the file.	2632
490	2289	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. \n @echo off\n rmdir /s /q \"%APPDATA%\\Subversion\\auth\"\n You can find a description of how to install such scripts at windows-help-central.com.	2636
491	2293	For more information on how to set up your server for authentication and access control, refer to	2644
492	2297	Maximizing Windows	2648
493	2301	maximize	2652
494	2305	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.	2656
495	2309	Importing Data Into A Repository	2660
496	2313	import	2664
497	2317	add files to repository	2668
498	2324	Import	2675
499	2328	temporary files	2679
500	2332	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 for further advice.	2683
501	2336	There is no way to select files and folders to include, aside from using the global ignore settings.	2687
502	2340	The folder imported does not become a working copy. You have to do a checkout to copy the files back from the server.	2691
503	2344	It is easy to import to the wrong folder level in the repository.	2695
504	2348	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 . But since you are here, this is how the basic import works ...	2699
505	2352	Remove all files which are not needed to build the project (temporary files, files which are generated by a compiler e.g. *.obj, compiled binaries, ...)	2703
506	2356	Organize the files in folders and sub-folders. Although it is possible to rename/move files later it is highly recommended to get your project's structure straight before importing!	2707
507	2360	Before you import your project into a repository you should:	2711
508	2364	Now select the top-level folder of your project directory structure in the windows explorer and right click to open the context menu. Select the command TortoiseSVNImport... which brings up a dialog box:	2715
509	2368	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: \n C:\\Projects\\Widget\\source\n C:\\Projects\\Widget\\doc\n C:\\Projects\\Widget\\images\n 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.	2719
510	2372	The import message is used as a log message.	2728
511	2376	By default, files and folders which match the global-ignore patterns are not imported. To override this behaviour you can use the Include ignored files checkbox. Refer to for more information on setting a global ignore pattern.	2732
512	2380	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.	2736
513	2384	Import in Place	2740
514	2388	import in place	2744
515	2392	Use the repository browser to create a new project folder directly in the repository.	2748
516	2396	Checkout the new folder over the top of the folder you want to import. You will get a warning that the local folder is not empty. Now you have a versioned top level folder with unversioned content.	2752
517	2400	Use TortoiseSVNAdd... on this versioned folder to add some or all of the content. You can add and remove files, set svn:ignore properties on folders and make any other changes you need to.	2756
518	2404	Commit the top level folder, and you have a new versioned tree, and a local working copy, created from your existing folder.	2760
519	2408	Assuming you already have a repository, and you want to add a new folder structure to it, just follow these steps:	2764
520	2412	Special Files	2768
521	2416	special files	2772
522	2420	Sometimes you need to have a file under version control which contains user specific data. That means you have a file which every developer/user needs to modify to suit his/her local setup. But versioning such a file is difficult because every user would commit his/her changes every time to the repository.	2776
523	2424	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.	2780
524	2428	As an example, you can have a look at TortoiseSVN's build script. It calls a file named TortoiseVars.bat which doesn't exist in the repository. Only the file TortoiseVars.tmpl. TortoiseVars.tmpl is the template file which every developer has to create a copy from and rename that file to TortoiseVars.bat. 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.	2784
525	2432	So as not to disturb the users, we also added the file TortoiseVars.bat 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.	2788
526	2436	Checking Out A Working Copy	2792
527	2440	checkout	2796
528	2444	create working copy	2800
529	2448	To obtain a working copy you need to do a checkout from a repository.	2804
530	2452	The Checkout dialog	2808
531	2456	Select a directory in windows explorer where you want to place your working copy. Right click to pop up the context menu and select the command TortoiseSVNCheckout..., which brings up the following dialog box: If you enter a folder name that does not yet exist, then a directory with that name is created.	2812
532	2460	Checkout Depth	2816
533	2464	Fully recursive	2820
534	2468	Checkout the entire tree, including all child folders and sub-folders.	2824
535	2472	Immediate children, including folders	2828
536	2476	Checkout the specified directory, including all files and child folders, but do not populate the child folders.	2832
537	2480	Only file children	2836
538	2484	Checkout the specified directory, including all files but do not checkout any child folders.	2840
539	2488	Only this item	2844
540	2492	Checkout the directory only. Do not populate it with files or child folders.	2848
541	2498	Working copy	2854
542	2502	Retain the depth specified in the working copy. This option is not used in the checkout dialog, but it is the default in all other dialogs which have a depth setting.	2858
543	2506	Exclude	2862
544	2510	Used to reduce working copy depth after a folder has already been populated. This option is only available in the Update to revision dialog.	2866
545	2514	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.	2870
546	2518	If you check out a sparse working copy (i.e., by choosing something other than fully recursive for the checkout depth), you can fetch additional sub-folders by using the repository browser () or the check for modifications dialog ().	2874
547	2522	In windows explorer, Right click on the checked out folder, then use TortoiseSVNRepo-Browser to bring up the repository browser. Find the sub-folder you would like to add to your working copy, then use Context menuUpdate item to revision... That menu will only be visible if the selected item does not exist yet in your working copy, but the parent item does exist.
548	2526	In the check for modifications dialog, first click on the button Check repository. The dialog will show all the files and folders which are in the repository but which you have not checked out as remotely added. Right click on the folder(s) you would like to add to your working copy, then use Context menuUpdate.	2882
549	2530	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:	2886
550	2534	Checkout the parent folder with depth Only this item You now have an empty top level folder.	2890
551	2538	Select the new folder and use TortoiseSVNRepo browser to display the repository content.	2894
552	2542	Right click on Project03 and Context menuUpdate item to revision.... Keep the default settings and click on OK. You now have that folder fully populated.	2898
553	2546	Repeat the same process for Project25.	2902
554	2550	Navigate to Project76/SubProj and do the same. This time note that the Project76 folder has no content except for SubProj, which itself is fully populated. Subversion has created the intermediate folders for you without populating them.	2906
555	2554	Changing working copy depth	2910
556	2558	Once you have checked out a working copy to a particular depth you can change that depth later to get more or less content using Context menuUpdate item to revision....	2914
557	2562	Using an older server	2918
558	2566	Pre-1.5 servers do not understand the working copy depth request, so they cannot always deal with requests efficiently. The command will still work, but an older server may send all the data, leaving the client to filter out what is not required, which may mean a lot of network traffic. If possible you should upgrade your server to 1.5.	2922
559	2570	If the project contains references to external projects which you do not want checked out at the same time, use the Omit externals checkbox.	2926
560	2574	If Omit externals is checked, or if you wish to increase the depth value, you will have to perform updates to your working copy using TortoiseSVNUpdate to Revision... instead of TortoiseSVNUpdate. The standard update will include all externals and keep the existing depth.	2930
561	2578	It is recommended that you check out only the trunk part of the directory tree, or lower. If you specify the parent path of the directory tree in the URL then you might end up with a full hard disk since you will get a copy of the entire repository tree including every branch and tag of your project!	2934
562	2582	Exporting	2938
563	2586	Sometimes you may want to create a local copy without any of those .svn directories, e.g. to create a zipped tarball of your source. Read to find out how to do that.	2942
564	2590	Committing Your Changes To The Repository	2946
565	2594	commit	2950
566	2598	send changes	2954
567	2602	check in	2958
568	2606	Sending the changes you made to your working copy is known as committing the changes. But before you commit you have to make sure that your working copy is up to date. You can either use TortoiseSVNUpdate directly. Or you can use TortoiseSVNCheck for Modifications first, to see which files have changed locally or on the server.	2962
569	2610	The Commit Dialog	2966
570	2614	The Commit dialog	2970
571	2618	If your working copy is up to date and there are no conflicts, you are ready to commit your changes. Select any file and/or folders you want to commit, then TortoiseSVNCommit....	2974
572	2622	The commit dialog will show you every changed file, including added, deleted and unversioned files. If you don't want a changed file to be committed, just uncheck that file. If you want to include an unversioned file, just check that file to add it to the commit.	2978
573	2627	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!	2983
574	2631	Commit files or folders?	2987
575	2635	When you commit files, the commit dialog shows only the files you have selected. When you commit a folder the commit dialog will select the changed files automatically. If you forget about a new file you created, committing the folder will find it anyway. Committing a folder does not mean that every file gets marked as changed; It just makes your life easier by doing more work for you.	2991
576	2639	If you have modified files which have been included from a different repository using svn:externals, those changes cannot be included in the same atomic commit. A warning symbol below the file list tells you if this has happened, and the tooltip explains that those external files have to be committed separately.	2995
577	2643	Many unversioned files in the commit dialog	2999
578	2647	add the file (or a wildcard extension) to the list of files to exclude on the settings page. This will affect every working copy you have.	3003
579	2651	add the file to the svn:ignore list using TortoiseSVNAdd to ignore list This will only affect the directory on which you set the svn:ignore property. Using the SVN Property Dialog, you can alter the svn:ignore property for a directory.	3007
580	2655	If you think that the commit dialog shows you too many unversioned (e.g. compiler generated or editor backup) files, there are several ways to handle this. You can: Read for more information.	3011
581	2659	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.	3015
582	2663	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.	3019
583	2667	The columns displayed in the bottom pane are customizable. If you right click on any column header you will see a context menu allowing you to select which columns are displayed. You can also change column width by using the drag handle which appears when you move the mouse over a column boundary. These customizations are preserved, so you will see the same headings next time.	3023
584	2671	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 for information on how to edit the Subversion configuration file.	3027
585	2675	You can drag files into the commit dialog from elsewhere, so long as the working copies are checked out from the same repository. For example, you may have a huge working copy with several explorer windows open to look at distant folders of the hierarchy. If you want to avoid committing from the top level folder (with a lengthy folder crawl to check for changes) you can open the commit dialog for one folder and drag in items from the other windows to include within the same atomic commit.	3031
586	2679	You can drag unversioned files which reside within a working copy into the commit dialog, and they will be SVN added automatically.	3035
587	2684	Repairing External Renames	3040
588	2689	Sometimes files get renamed outside of Subversion, and they show up in the file list as a missing file and an unversioned file. To avoid losing the history you need to notify Subversion about the connection. Simply select both the old name (missing) and the new name (unversioned) and use Context MenuRepair Move to pair the two files as a rename.	3045
589	2694	Repairing External Copies	3050
590	2699	If you made a copy of a file but forgot to use the Subversion command to do so, you can repair that copy so the new file doesn't lose its history. Simply select both the old name (normal or modified) and the new name (unversioned) and use Context MenuRepair Copy to pair the two files as a copy.	3055
591	2704	Change Lists	3060
592	2708	The commit dialog supports Subversion's changelist feature to help with grouping related files together. Find out about this feature in .	3064
593	2712	Excluding Items from the Commit List	3068
594	2716	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.	3072
595	2720	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.	3076
596	2724	Commit Log Messages	3080
597	2728	Be sure to enter a log message which describes the changes you are committing. This will help you to see what happened and when, as you browse through the project log messages at a later date. The message can be as long or as brief as you like; many projects have guidelines for what should be included, the language to use, and sometimes even a strict format.	3084
598	2732	You can apply simple formatting to your log messages using a convention similar to that used within emails. To apply styling to text, use *text* for bold, _text_ for underlining, and ^text^ for italics.	3088
599	2736	The Commit Dialog Spellchecker	3092
600	2740	TortoiseSVN includes a spellchecker to help you get your log messages right. This will highlight any mis-spelled words. Use the context menu to access the suggested corrections. Of course, it doesn't know every technical term that you do, so correctly spelt words will sometimes show up as errors. But don't worry. You can just add them to your personal dictionary using the context menu.	3096
601	2744	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 http://en.wikipedia.org/wiki/Regular_expression, and the online documentation and tutorial at http://www.regular-expressions.info/.	3100
602	2748	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	3104
603	2752	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.	3108
604	2756	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.	3112
605	2760	If you want to include the checked paths in your log message, you can use the command Context MenuPaste filename list in the edit control.	3116
606	2764	Another way to insert the paths into the log message is to simply drag the files from the file list onto the edit control.	3120
607	2768	Special Folder Properties	3124
608	2772	There are several special folder properties which can be used to help give more control over the formatting of commit log messages and the language used by the spellchecker module. Read for further information.	3128
609	2776	Integration with Bug Tracking Tools	3132
610	2780	If you have activated the bug tracking system, you can set one or more Issues in the Bug-ID / Issue-Nr: text box. Multiple issues should be comma separated. Alternatively, if you are using regex-based bug tracking support, just add your issue references as part of the log message. Learn more in .	3136
611	2784	Commit Progress	3140
612	2788	The Progress dialog showing a commit in progress	3144
613	2792	After pressing OK, a dialog appears displaying the progress of the commit.	3148
614	2797	Blue	3153
615	2801	Committing a modification.	3157
616	2807	Purple	3163
617	2811	Committing a new addition.	3167
618	2817	Dark red	3173
619	2821	Committing a deletion or a replacement.	3177
620	2827	Black	3183
621	2831	All other items.	3187
622	2835	The progress dialog uses colour coding to highlight different commit actions	3191
623	2841	This is the default colour scheme, but you can customise those colours using the settings dialog. Read for more information.	3197
624	2845	Update Your Working Copy With Changes From Others	3201
625	2850	update	3206
626	2854	fetch changes	3210
627	2858	Progress dialog showing finished update	3214
628	2862	Periodically, you should ensure that changes done by others get incorporated in your local working copy. The process of getting changes from the server to your local copy is known as updating. Updating may be done on single files, a set of selected files, or recursively on entire directory hierarchies. To update, select the files and/or directories you want, right click and select TortoiseSVNUpdate in the explorer context menu. A window will pop up displaying the progress of the update as it runs. Changes done by others will be merged into your files, keeping any changes you may have done to the same files. The repository is not affected by an update.	3218
629	2866	New item added to your WC.	3222
630	2870	Redundant item deleted from your WC, or missing item replaced in your WC.	3226
631	2875	Green	3231
632	2879	Changes from repository successfully merged with your local changes.	3235
633	2884	Bright red	3240
634	2888	Changes from repository merged with local changes, resulting in conflicts which you need to resolve.	3244
635	2892	Unchanged item in your WC updated with newer version from the repository.	3248
636	2896	The progress dialog uses colour coding to highlight different update actions	3252
637	2900	If you get any conflicts during an update (this can happen if others changed the same lines in the same file as you did and those changes don't match) then the dialog shows those conflicts in red. You can double click on these lines to start the external merge tool to resolve the conflicts.	3256
638	2904	When the update is complete, the progress dialog shows a summary of the number of items updated, added, removed, conflicted, etc. below the file list. This summary information can be copied to the clipboard using Ctrl+C.	3260
639	2908	The standard Update command has no options and just updates your working copy to the HEAD revision of the repository, which is the most common use case. If you want more control over the update process, you should use TortoiseSVNUpdate to Revision... instead. This allows you to update your working copy to a specific revision, not only to the most recent one. Suppose your working copy is at revision 100, but you want it to reflect the state which it had in revision 50 - then simply update to revision 50. In the same dialog you can also choose the depth at which to update the current folder. The terms used are described in . The default depth is Working copy, which preserves the existing depth setting. You can also choose whether to ignore any external projects in the update (i.e. projects referenced using svn:externals).	3264
640	2912	If you update a file or folder to a specific revision, you should not make changes to those files. You will get out of date error messages when you try to commit them! If you want to undo changes to a file and start afresh from an earlier revision, you can rollback to a previous revision from the revision log dialog. Take a look at for further instructions, and alternative methods.	3268
641	2916	Update to Revision can occasionally be useful to see what your project looked like at some earlier point in its history. But in general, updating individual files to an earlier revision is not a good idea as it leaves your working copy in an inconsistent state. If the file you are updating has changed name, you may even find that the file just disappears from your working copy because no file of that name existed in the earlier revision. You should also note that the item will show a normal green overlay, so it is indistinguishable from files which are up-to-date.	3272
642	2920	If you simply want a local copy of an old version of a file it is better to use the Context MenuSave revision to... command from the log dialog for that file.	3276
643	2924	Multiple Files/Folders	3280
644	2928	If you select multiple files and folders in the explorer and then select Update, all of those files/folders are updated one by one. TortoiseSVN makes sure that all files/folders which are from the same repository are updated to the exact same revision! Even if between those updates another commit occurred.	3284
645	2932	Local File Already Exists	3288
646	2936	Sometimes when you try to update, the update fails with a message to say that there is already a local file of the same name. This typically happens when Subversion tries to checkout a newly versioned file, and finds that an unversioned file of the same name already exists in your working folder. Subversion will never overwrite an unversioned file - it might contain something you are working on, which coincidentally has the same filename as another developer has used for his newly committed file.	3292
647	2940	If you get this error message, the solution is simply to rename the local unversioned file. After completing the update, you can check whether the renamed file is still needed.	3296
648	2944	If you keep getting error messages, use TortoiseSVNCheck for Modifications instead to list all the problem files. That way you can deal with them all at once.	3300
649	2948	Resolving Conflicts	3304
650	2952	tree conflict	3308
651	2956	resolve	3312
652	2960	file conflicts	3316
653	2964	A file conflict occurs if two (or more) developers have changed the same few lines of a file.	3320
654	2968	tree conflicts	3324
655	2972	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.	3328
656	2976	Once in a while, you will get a conflict when you update/merge your files from the repository or when you switch your working copy to a different URL. There are two kinds of conflicts:	3332
657	2980	File Conflicts	3336
658	2988	This is your file as it existed in your working copy before you updated your working copy - that is, without conflict markers. This file has your latest changes in it and nothing else.	3344
659	2996	This is the file that was the BASE revision before you updated your working copy. That is, it the file that you checked out before you made your latest edits.	3352
660	3004	This is the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository.	3360
661	3008	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. Whenever a conflict is reported, you should open the file in question, and search for lines starting with the string <<<<<<<. The conflicting area is marked like this: \n <<<<<<< filename\n your changes\n =======\n code merged from repository\n >>>>>>> revision\n Also, for every conflicted file Subversion places three additional files in your directory:	3364
662	3012	You can either launch an external merge tool / conflict editor with TortoiseSVNEdit Conflicts or you can use any other editor to manually resolve the conflict. You should decide what the code should look like, do the necessary changes and save the file.	3375
663	3016	Afterwards execute the command TortoiseSVNResolved and commit your modifications to the repository. Please note that the Resolve command does not really resolve the conflict. It just removes the filename.ext.mine and filename.ext.r* files, to allow you to commit your changes.	3379
664	3020	If you have conflicts with binary files, Subversion does not attempt to merge the files itself. The local file remains unchanged (exactly as you last changed it) and you have filename.ext.r* files. If you want to discard your changes and keep the repository version, just use the Revert command. If you want to keep your version and overwrite the repository version, use the Resolved command, then commit your version.	3383
665	3024	You can use the Resolved command for multiple files if you right click on the parent folder and select TortoiseSVNResolved... This will bring up a dialog listing all conflicted files in that folder, and you can select which ones to mark as resolved.	3387
666	3028	Tree Conflicts	3391
667	3032	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.	3395
668	3036	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.	3399
669	3040	TortoiseSVN can help find the right place to merge changes, but there may be additional work required to sort out the conflicts. Remember that after an update the working BASE will always contain the revision of each item as it was in the repository at the time of update. If you revert a change after updating it goes back to the repository state, not to the way it was when you started making your own local changes.	3403
670	3044	Local delete, incoming edit upon update	3407
671	3048	Developer A modifies Foo.c and commits it to the repository	3411
672	3052	Developer B has simultaneously moved Foo.c to Bar.c in his working copy, or simply deleted Foo.c or its parent folder.	3415
673	3056	Foo.c has been deleted from working copy, but is marked with a tree conflict.	3419
674	3060	If the conflict results from a rename rather than a delete then Bar.c is marked as added, but does not contain developer A's modifications.	3423
675	3065	An update of developer B's working copy results in a tree conflict:	3428
676	3069	Developer B now has to choose whether to keep Developer A's changes. In the case of a file rename, he can merge the changes to Foo.c into the renamed file Bar.c. For simple file or directory deletions he can choose to keep the item with Developer A's changes and discard the deletion. Or, by marking the conflict as resolved without doing anything he effectively discards Developer A's changes.	3432
677	3073	The conflict edit dialog offers to merge changes if it can find the original file of the renamed Bar.c. Depending on where the update was invoked, it may not be possible to find the source file.	3436
678	3077	Local edit, incoming delete upon update	3440
679	3081	Developer A moves Foo.c to Bar.c and commits it to the repository.	3444
680	3086	Developer B modifies Foo.c in his working copy.	3449
681	3090	Or in the case of a folder move ...	3453
682	3094	Developer A moves parent folder FooFolder to BarFolder and commits it to the repository.	3457
683	3098	Bar.c is added to the working copy as a normal file.	3461
684	3102	Foo.c is marked as added (with history) and has a tree conflict.	3465
685	3106	An update of developer B's working copy results in a tree conflict. For a simple file conflict:	3469
686	3110	BarFolder is added to the working copy as a normal folder.	3473
687	3114	FooFolder is marked as added (with history) and has a tree conflict.	3477
688	3118	Foo.c is marked as modified.	3481
689	3122	For a folder conflict:	3485
690	3127	Developer B now has to decide whether to go with developer A's reorganisation and merge her changes into the corresponding file in the new structure, or simply revert A's changes and keep the local file.	3490
691	3131	To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog. The changes must then be merged by hand as there is currently no way to automate or even simplify this process. Once the changes have been ported across, the conflicted path is redundant and can be deleted. In this case use the Remove button in the conflict editor dialog to clean up and mark the conflict as resolved.	3494
692	3135	If Developer B decides that A's changes were wrong then she must choose the Keep button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog helps to track down what was moved.	3498
693	3139	Local delete, incoming delete upon update	3502
694	3143	Developer A moves Foo.c to Bar.c and commits it to the repository	3506
695	3147	Developer B moves Foo.c to Bix.c	3510
696	3151	Bix.c is marked as added with history.	3514
697	3155	Bar.c is added to the working copy with status 'normal'.	3518
698	3159	Foo.c is marked as deleted and has a tree conflict.	3522
699	3163	To resolve this conflict, Developer B has to find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog.	3526
700	3168	Then developer B has to decide which new filename of Foo.c to keep - the one done by developer A or the rename done by himself.	3531
701	3173	After developer B has manually resolved the conflict, the tree conflict has to be marked as resolved with the button in the conflict editor dialog.	3536
702	3177	Local missing, incoming edit upon merge	3540
703	3181	Developer A working on trunk modifies Foo.c and commits it to the repository	3544
704	3185	Developer B working on a branch moves Foo.c to Bar.c and commits it to the repository	3548
705	3189	Bar.c is already in the working copy with status 'normal'.	3552
706	3193	Foo.c is marked as missing with a tree conflict.	3556
707	3199	A merge of developer A's trunk changes to developer B's branch working copy results in a tree conflict:	3562
708	3203	To resolve this conflict, Developer B has to mark the file as resolved in the conflict editor dialog, which will remove it from the conflict list. She then has to decide whether to copy the missing file Foo.c from the repository to the working copy, whether to merge Developer A's changes to Foo.c into the renamed Bar.c or whether to ignore the changes by marking the conflict as resolved and doing nothing else.	3566
709	3207	Note that if you copy the missing file from the repository and then mark as resolved, your copy will be removed again. You have to resolve the conflict first.	3570
710	3211	Local edit, incoming delete upon merge	3574
711	3216	Developer A working on trunk moves Foo.c to Bar.c and commits it to the repository	3579
712	3220	Developer B working on a branch modifies Foo.c and commits it to the repository.	3583
713	3224	There is an equivalent case for folder moves, but it is not yet detected in Subversion 1.6 ...	3587
714	3228	Developer A working on trunk moves parent folder FooFolder to BarFolder and commits it to the repository.	3591
715	3232	Developer B working on a branch modifies Foo.c in her working copy.	3595
716	3236	Bar.c is marked as added.	3599
717	3240	Foo.c is marked as modified with a tree conflict.	3603
718	3244	To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source. The conflict editor only shows the log for the working copy as it does not know which path was used in the merge, so you will have to find that yourself. The changes must then be merged by hand as there is currently no way to automate or even simplify this process. Once the changes have been ported across, the conflicted path is redundant and can be deleted. In this case use the Remove button in the conflict editor dialog to clean up and mark the conflict as resolved.	3607
719	3248	If Developer B decides that A's changes were wrong then she must choose the Keep button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog for the merge source helps to track down what was moved.	3611
720	3252	Local delete, incoming delete upon merge	3615
721	3256	Developer B working on a branch moves Foo.c to Bix.c and commits it to the repository	3619
722	3260	Bix.c is marked with normal (unmodified) status.	3623
723	3264	Bar.c is marked as added with history.	3627
724	3268	Foo.c is marked as missing and has a tree conflict.	3631
725	3272	To resolve this conflict, Developer B has to find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source. The conflict editor only shows the log for the working copy as it does not know which path was used in the merge, so you will have to find that yourself.	3635
726	3276	Other tree conflicts	3639
727	3280	There are other cases which are labelled as tree conflicts simply because the conflict involves a folder rather than a file. For example if you add a folder with the same name to both trunk and branch and then try to merge you will get a tree conflict. If you want to keep the folder from the merge target, just mark the conflict as resolved. If you want to use the one in the merge source then you need to SVN delete the one in the target first and run the merge again. If you need anything more complicated then you have to resolve manually.	3643
728	3284	Getting Status Information	3647
729	3289	status	3652
730	3293	view changes	3656
731	3297	working copy status	3660
732	3301	While you are working on your working copy you often need to know which files you have changed/added/removed or renamed, or even which files got changed and committed by others.	3664
733	3306	overlays	3669
734	3310	icons	3673
735	3314	Now that you have checked out a working copy from a Subversion repository you can see your files in the windows explorer with changed icons. This is one of the reasons why TortoiseSVN is so popular. TortoiseSVN adds a so called overlay icon to each file icon which overlaps the original file icon. Depending on the Subversion status of the file the overlay icon is different.	3677
736	3318	A fresh checked out working copy has a green checkmark as overlay. That means the Subversion status is normal.	3681
737	3322	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.	3685
738	3326	If during an update a conflict occurs then the icon changes to a yellow exclamation mark.	3689
739	3330	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.	3693
740	3334	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.	3697
741	3338	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.	3701
742	3342	The plus sign tells you that a file or folder has been scheduled to be added to version control.	3705
743	3346	The bar sign tells you that a file or folder is ignored for version control purposes. This overlay is optional.	3709
744	3350	This icon shows files and folders which are not under version control, but have not been ignored. This overlay is optional.	3713
745	3354	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.	3717
746	3358	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 :-)	3721
747	3362	For a description of how icon overlays correspond to Subversion status and other technical details, read .	3725
748	3366	TortoiseSVN Columns In Windows Explorer	3729
749	3370	Explorer Columns	3733
750	3374	The same information which is available from the icon overlays (and much more) can be displayed as additional columns in Windows Explorer's Details View.	3737
751	3378	Simply right click on one of the headings of a column, choose More... from the context menu displayed. A dialog will appear where you can specify the columns and their order, which is displayed in the Detailed View. Scroll down until the entries starting with SVN come into view. Check the ones you would like to have displayed and close the dialog by pressing OK. The columns will be appended to the right of those currently displayed. You can reorder them by drag and drop, or resize them, so that they fit your needs.	3741
752	3382	The additional columns in the Windows Explorer are not available on Vista, since Microsoft decided to not allow such columns for all files anymore but only for specific file types.	3745
753	3386	If you want the current layout to be displayed in all your working copies, you may want to make this the default view.	3749
754	3390	Local and Remote Status	3753
755	3394	modifications	3757
756	3399	Check for Modifications	3762
757	3403	It's often very useful to know which files you have changed and also which files got changed and committed by others. That's where the command TortoiseSVNCheck For Modifications... comes in handy. This dialog will show you every file that has changed in any way in your working copy, as well as any unversioned files you may have.	3766
758	3407	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.	3770
759	3411	Locally modified items.	3774
760	3415	Added items. Items which have been added with history have a + sign in the Text status column, and a tooltip shows where the item was copied from.	3778
761	3419	Deleted or missing items.	3782
762	3423	Items modified locally and in the repository. The changes will be merged on update. These may produce conflicts on update.	3786
763	3427	Items modified locally and deleted in repository, or modified in repository and deleted locally. These will produce conflicts on update.	3790
764	3431	Unchanged and unversioned items.	3794
765	3435	The dialog uses colour coding to highlight the status.	3798
766	3439	From the context menu of the dialog you can show a diff of the changes. Check the local changes you made using Context MenuCompare with Base. Check the changes in the repository made by others using Context MenuShow Differences as Unified Diff.	3802
767	3443	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.	3806
768	3447	Unversioned and ignored files can be sent to the recycle bin from here using Context MenuDelete. If you want to delete files permanently (bypassing the recycle bin) hold the Shift key while clicking on Delete.	3810
769	3451	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.	3814
770	3455	The columns are customizable. If you right click on any column header you will see a context menu allowing you to select which columns are displayed. You can also change column width by using the drag handle which appears when you move the mouse over a column boundary. These customizations are preserved, so you will see the same headings next time.	3818
771	3459	If you are working on several unrelated tasks at once, you can also group files together into changelists. Read for more information.	3822
772	3463	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.	3826
773	3467	If you want a flat view of your working copy, i.e. showing all files and folders at every level of the folder hierarchy, then the Check for Modifications dialog is the easiest way to achieve that. Just check the Show unmodified files checkbox to show all files in your working copy.	3830
774	3471	Viewing Diffs	3834
775	3475	diffing	3838
776	3479	Often you want to look inside your files, to have a look at what you've changed. You can accomplish this by selecting a file which has changed, and selecting Diff from TortoiseSVN's context menu. This starts the external diff-viewer, which will then compare the current file with the pristine copy (BASE revision), which was stored after the last checkout or update.	3842
777	3483	Even when not inside a working copy or when you have multiple versions of the file lying around, you can still display diffs:	3846
778	3487	Select the two files you want to compare in explorer (e.g. using Ctrl and the mouse) and choose Diff from TortoiseSVN's context menu. The file clicked last (the one with the focus, i.e. the dotted rectangle) will be regarded as the later one.	3850
779	3491	changelist	3854
780	3495	In an ideal world, you only ever work on one thing at a time, and your working copy contains only one set of logical changes. OK, back to reality. It often happens that you have to work on several unrelated tasks at once, and when you look in the commit dialog, all the changes are mixed in together. The changelist feature helps you group files together, making it easier to see what you are doing. Of course this can only work if the changes do not overlap. If two different tasks affect the same file, there is no way to separate the changes.	3858
781	3499	The changelist feature in TortoiseSVN is only available in Windows XP and later, as it depends on a shell capability which is not present in Windows 2000. Sorry, but Win2K is really quite old now, so please don't complain.	3862
782	3503	You can see changelists in several places, but the most important ones are the commit dialog and the check-for-modifications dialog. Let's start in the check-for-modifications dialog after you have worked on several features and many files. When you first open the dialog, all the changed files are listed together. Suppose you now want to organise things and group those files according to feature.	3866
783	3507	Select one or more files and use Context MenuMove to changelist to add an item to a changelist. Initially there will be no changelists, so the first time you do this you will create a new changelist. Give it name which describes what you are using it for, and click OK. The dialog will now change to show groups of items.	3870
784	3511	Once you have created a changelist you can drag and drop items into it, either from another changelist, or from Windows Explorer. Dragging from Explorer can be useful as it allows you to add items to a changelist before the file is modified. You could do that from the check-for-modifications dialog, but only by displaying all unmodified files.	3874
785	3515	Commit dialog with Changelists	3878
786	3519	In the commit dialog you can see those same files, grouped by changelist. Apart from giving an immediate visual indication of groupings, you can also use the group headings to select which files to commit.	3882
787	3523	On XP, there is a context menu when you right click on a group heading which gives you the choice to check or uncheck all group entries. On Vista however the context menu is not necessary. Click on the group header to select all entries, then check one of the selected entries to check all.	3886
788	3527	TortoiseSVN reserves one changelist name for its own use, namely ignore-on-commit. This is used to mark versioned files which you almost never want to commit even though they have local changes. This feature is described in .	3890
789	3531	When you commit files belonging to a changelist then normally you would expect that the changelist membership is no longer needed. So by default, files are removed from changelists automatically on commit. If you wish to retain the file in its changelist, use the Keep changelists checkbox at the bottom of the commit dialog.	3894
790	3535	Changelists are purely a local client feature. Creating and removing changelists will not affect the repository, nor anyone else's working copy. They are simply a convenient way for you to organise your files.	3898
791	3539	Revision Log Dialog	3902
792	3543	log	3906
793	3547	history	3910
794	3551	commit messages	3914
795	3555	log messages	3918
796	3559	For every change you make and commit, you should provide a log message for that change. That way you can later find out what changes you made and why, and you have a detailed log for your development process.	3922
797	3563	The top pane shows a list of revisions where changes to the file/folder have been committed. This summary includes the date and time, the person who committed the revision and the start of the log message.	3926
798	3567	Lines shown in blue indicate that something has been copied to this development line (perhaps from a branch).	3930
799	3571	The middle pane shows the full log message for the selected revision.	3934
800	3575	The bottom pane shows a list of all files and folders that were changed as part of the selected revision.	3938
801	3579	The Revision Log Dialog retrieves all those log messages and shows them to you. The display is divided into 3 panes. But it does much more than that - it provides context menu commands which you can use to get even more information about the project history.	3942
802	3583	Invoking the Revision Log Dialog	3946
803	3587	The Revision Log Dialog	3950
804	3591	From the TortoiseSVN context submenu	3954
805	3595	From the property page	3958
806	3599	From the Progress dialog after an update has finished. Then the Log dialog only shows those revisions which were changed since your last update	3962
807	3603	There are several places from where you can show the Log dialog:	3966
808	3607	If the repository is unavailable you will see the Want to go offline? dialog, described in .	3970
809	3611	Revision Log Actions	3974
810	3615	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.	3978
811	3619	If a revision modified a file or directory, the modified icon is shown in the first column.	3982
812	3623	If a revision added a file or directory, the added icon is shown in the second column.	3986
813	3627	If a revision deleted a file or directory, the deleted icon is shown in the third column.	3990
814	3631	If a revision replaced a file or directory, the replaced icon is shown in the fourth column.	3994
815	3635	Getting Additional Information	3998
816	3639	The Revision Log Dialog Top Pane with Context Menu	4002
817	3643	Compare with working copy	4006
818	3647	Compare the selected revision with your working copy. The default Diff-Tool is TortoiseMerge which is supplied with TortoiseSVN. If the log dialog is for a folder, this will show you a list of changed files, and allow you to review the changes made to each file individually.	4010
819	3651	Compare and blame with working BASE	4014
820	3655	Blame the selected revision, and the file in your working BASE and compare the blame reports using a visual diff tool. Read for more detail. (files only).	4018
821	3659	Show changes as unified diff	4022
822	3663	View the changes made in the selected revision as a Unified-Diff file (GNU patch format). This shows only the differences with a few lines of context. It is harder to read than a visual file compare, but will show all file changes together in a compact format.	4026
823	3667	Compare with previous revision	4030
824	3671	Compare the selected revision with the previous revision. This works in a similar manner to comparing with your working copy. For folders this option will first show the changed files dialog allowing you to select files to compare.	4034
825	3675	Compare and blame with previous revision	4038
826	3679	Show the changed files dialog allowing you to select files. Blame the selected revision, and the previous revision, and compare the results using a visual diff tool. (folders only).	4042
827	3684	Save revision to...	4047
828	3688	Save the selected revision to a file so you have an older version of that file. (files only).	4051
829	3693	Open / Open with...	4056
830	3697	Open the selected file, either with the default viewer for that file type, or with a program you choose. (files only).	4060
831	3702	Blame...	4065
832	3706	Blame the file up to the selected revision. (files only).	4069
833	3710	Browse repository	4073
834	3714	Open the repository browser to examine the selected file or folder in the repository as it was at the selected revision.	4077
835	3718	Create branch/tag from revision	4081
836	3722	Create a branch or tag from a selected revision. This is useful e.g. if you forgot to create a tag and already committed some changes which weren't supposed to get into that release.	4085
837	3726	Update item to revision	4089
838	3730	Update your working copy to the selected revision. Useful if you want to have your working copy reflect a time in the past, or if there have been further commits to the repository and you want to update your working copy one step at a time. It is best to update a whole directory in your working copy, not just one file, otherwise your working copy could be inconsistent.	4093
839	3734	If you want to undo an earlier change permanently, use Revert to this revision instead.	4097
840	3738	Revert to this revision	4101
841	3742	Revert to an earlier revision. If you have made several changes, and then decide that you really want to go back to how things were in revision N, this is the command you need. The changes are undone in your working copy so this operation does not affect the repository until you commit the changes. Note that this will undo all changes made after the selected revision, replacing the file/folder with the earlier version.	4105
842	3747	If your working copy is in an unmodified state, after you perform this action your working copy will show as modified. If you already have local changes, this command will merge the undo changes into your working copy.	4110
843	3751	What is happening internally is that Subversion performs a reverse merge of all the changes made after the selected revision, undoing the effect of those previous commits.	4114
844	3755	If after performing this action you decide that you want to undo the undo and get your working copy back to its previous unmodified state, you should use TortoiseSVNRevert from within Windows Explorer, which will discard the local modifications made by this reverse merge action.	4118
845	3759	If you simply want to see what a file or folder looked like at an earlier revision, use Update to revision or Save revision as... instead.	4122
846	3764	Revert changes from this revision	4127
847	3768	Undo changes from which were made in the selected revision. The changes are undone in your working copy so this operation does not affect the repository at all! Note that this will undo the changes made in that revision only; it does not replace your working copy with the entire file at the earlier revision. This is very useful for undoing an earlier change when other unrelated changes have been made since.	4131
848	3772	What is happening internally is that Subversion performs a reverse merge of that one revision, undoing its effect from a previous commit.	4135
849	3776	You can undo the undo as described above in Revert to this revision.	4139
850	3780	Merge revision to...	4143
851	3784	Merge 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.	4147
852	3788	Checkout...	4151
853	3792	Make a fresh checkout of the selected folder at the selected revision. This brings up a dialog for you to confirm the URL and revision, and select a location for the checkout.	4155
854	3796	Export...	4159
855	3800	Export the selected file/folder at the selected revision. This brings up a dialog for you to confirm the URL and revision, and select a location for the export.	4163
856	3804	Edit author / log message	4167
857	3808	Edit the log message or author attached to a previous commit. Read to find out how this works.	4171
858	3812	Show revision properties	4175
859	3816	View and edit any revision property, not just log message and author. Refer to .	4179
860	3821	Copy to clipboard	4184
861	3825	Copy the log details of the selected revisions to the clipboard. This will copy the revision number, author, date, log message and the list of changed items for each revision.	4188
862	3830	Search log messages...	4193
863	3834	Search log messages for the text you enter. This searches the log messages that you entered and also the action summaries created by Subversion (shown in the bottom pane). The search is not case sensitive.	4197
864	3838	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.	4201
865	3842	Top Pane Context Menu for 2 Selected Revisions	4205
866	3846	Compare revisions	4209
867	3850	Compare the two selected revisions using a visual difference tool. The default Diff-Tool is TortoiseMerge which is supplied with TortoiseSVN.	4213
868	3854	If you select this option for a folder, a further dialog pops up listing the changed files and offering you further diff options. Read more about the Compare Revisions dialog in .	4217
869	3858	Blame revisions	4221
870	3862	Blame the two revisions and compare the blame reports using a visual difference tool. Read for more detail.	4225
871	3866	Show differences as unified diff	4229
872	3870	View the differences between the two selected revisions as a Unified-Diff file. This works for files and folders.	4233
873	3874	Copy log messages to clipboard as described above.	4237
874	3878	Search log messages as described above.	4241
875	3882	If you select two revisions at once (using the usual Ctrl-modifier), the context menu changes and gives you fewer options:	4245
876	3886	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.	4249
877	3890	You can also choose to merge the selected revisions to another working copy, as described above.	4253
878	3894	If all selected revisions have the same author, you can edit the author of all those revisions in one go.	4257
879	3898	The Log Dialog Bottom Pane with Context Menu	4261
880	3902	Show changes	4265
881	3906	Show changes made in the selected revision for the selected file.	4269
882	3910	Blame changes	4273
883	3914	Blame the selected revision and the previous revision for the selected file, and compare the blame reports using a visual diff tool. Read for more detail.	4277
884	3918	Show as unified diff	4281
885	3922	Show file changes in unified diff format. This context menu is only available for files shown as modified.	4285
886	3927	Open the selected file, either with the default viewer for that file type, or with a program you choose.	4290
887	3931	Opens the Blame dialog, allowing you to blame up to the selected revision.	4294
888	3935	Revert the changes made to the selected file in that revision.	4298
889	3939	Show properties	4302
890	3943	View the Subversion properties for the selected item.	4306
891	3947	Show log	4310
892	3951	Show the revision log for the selected single file.	4314
893	3955	Get merge logs	4318
894	3959	Show the revision log for the selected single file, including merged changes. Find out more in .	4322
895	3963	Save the selected revision to a file so you have an older version of that file.	4326
896	3967	The bottom pane of the Log dialog also has a context menu that allows you to	4330
897	3971	You may notice that sometimes we refer to changes and other times to differences. What's the difference?	4334
898	3975	Subversion uses revision numbers to mean 2 different things. A revision generally represents the state of the repository at a point in time, but it can also be used to represent the changeset which created that revision, eg. Done in r1234 means that the changes committed in r1234 implement feature X. To make it clearer which sense is being used, we use two different terms.	4338
899	3979	If you select two revisions N and M, the context menu will offer to show the difference between those two revisions. In Subversion terms this is diff -r M:N.	4342
900	3983	If you select a single revision N, the context menu will offer to show the changes made in that revision. In Subversion terms this is diff -r N-1:N or diff -c N.	4346
901	3987	The bottom pane shows the files changed in all selected revisions, so the context menu always offers to show changes.	4350
902	3991	Getting more log messages	4354
903	3995	For a large repository there may be hundreds or even thousands of changes and fetching them all could take a long time. Normally you are only interested in the more recent changes. By default, the number of log messages fetched is limited to 100, but you can change this value in TortoiseSVNSettings (),	4358
904	3999	When the Stop on copy/rename box is checked, Show Log will stop at the point that the selected file or folder was copied from somewhere else within the repository. This can be useful when looking at branches (or tags) as it stops at the root of that branch, and gives a quick indication of changes made in that branch only.	4362
905	4003	Normally you will want to leave this option unchecked. TortoiseSVN remembers the state of the checkbox, so it will respect your preference.	4366
906	4007	When the Show Log dialog is invoked from within the Merge dialog, the box is always checked by default. This is because merging is most often looking at changes on branches, and going back beyond the root of the branch does not make sense in that instance.	4370
907	4011	Note that Subversion currently implements renaming as a copy/delete pair, so renaming a file or folder will also cause the log display to stop if this option is checked.	4374
908	4015	The Log dialog does not always show all changes ever made for a number of reasons:	4378
909	4019	If you want to see more log messages, click the Next 100 to retrieve the next 100 log messages. You can repeat this as many times as needed.	4382
910	4023	Next to this button there is a multi-function button which remembers the last option you used it for. Click on the arrow to see the other options offered.	4386
911	4027	Use Show Range ... if you want to view a specific range of revisions. A dialog will then prompt you to enter the start and end revision.	4390
912	4031	Use Show All if you want to see all log messages from HEAD right back to revision 1.	4394
913	4035	Current Working Copy Revision	4398
914	4039	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.	4402
915	4043	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.	4406
916	4047	Merge Tracking Features	4410
917	4051	merge tracking log	4414
918	4055	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.	4418
919	4059	The Log Dialog Showing Merge Tracking Revisions	4422
920	4063	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.	4426
921	4067	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.	4430
922	4071	Changing the Log Message and Author	4434
923	4075	edit log/author	4438
924	4079	revision properties	4442
925	4083	revprops	4446
926	4087	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).	4450
927	4091	Sometimes you might want to change a log message you once entered, maybe because there's a spelling error in it or you want to improve the message or change it for other reasons. Or you want to change the author of the commit because you forgot to set up authentication or...	4454
928	4095	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 to find some further notes on implementing hooks on a Windows machine.	4458
929	4099	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.	4462
930	4103	Because Subversion's revision properties are not versioned, making modifications to such a property (for example, the svn:log commit message property) will overwrite the previous value of that property forever.	4466
931	4107	Filtering Log Messages	4470
932	4111	filter	4474
933	4115	If you want to restrict the log messages to show only those you are interested in rather than scrolling through a list of hundreds, you can use the filter controls at the top of the Log Dialog. The start and end date controls allow you to restrict the output to a known date range. The search box allows you to show only messages which contain a particular phrase.	4478
934	4119	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.	4482
935	4123	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 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: \n Alice Bob -Eve\n searches for strings containing both Alice and Bob but not Eve \n !Alice Bob\n searches for strings which do not contain both Alice and Bob \n !-Alice -Bob\n do you remember De Morgan's theorem? NOT(NOT Alice AND NOT Bob) reduces to (Alice OR Bob). \n \"Alice and Bob\"\n searches for the literal expression Alice and Bob\n \"\"\n searches for a double-quote anywhere in the text \n \"Alice says \"\"hi\"\" to Bob\"\n searches for the literal expression Alice says \"hi\" to Bob	4486
936	4127	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/.	4503
937	4131	Note that these filters act on the messages already retrieved. They do not control downloading of messages from the repository.	4507
938	4135	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.	4511
939	4139	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 to find out how to use this property.	4515
940	4143	No Log Formatting from Repository Browser	4519
941	4147	Because the formatting depends upon accessing subversion properties, you will only see the results when using a checked out working copy. Fetching properties remotely is a slow operation, so you will not see this feature in action from the repo browser.	4523
942	4151	Statistical Information	4527
943	4155	statistics	4531
944	4159	The Statistics button brings up a box showing some interesting information about the revisions shown in the Log dialog. This shows how many authors have been at work, how many commits they have made, progress by week, and much more. Now you can see at a glance who has been working hardest and who is slacking ;-)	4535
945	4163	Statistics Page	4539
946	4167	This page gives you all the numbers you can think of, in particular the period and number of revisions covered, and some min/max/average values.	4543
947	4171	Commits by Author Page	4547
948	4175	Commits-by-Author Histogram	4551
949	4179	Commits-by-Author Pie Chart	4555
950	4183	This graph shows you which authors have been active on the project as a simple histogram, stacked histogram or pie chart.	4559
951	4187	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.	4563
952	4191	Commits by date Page	4567
953	4195	Commits-by-date Graph	4571
954	4199	This page gives you a graphical representation of project activity in terms of number of commits and author. This gives some idea of when a project is being worked on, and who was working at which time.	4575
955	4203	When there are several authors, you will get many lines on the graph. There are two views available here: normal, where each author's activity is relative to the base line, and stacked, where each author's activity is relative to the line underneath. The latter option avoids the lines crossing over, which can make the graph easier to read, but less easy to see one author's output.	4579
956	4207	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.	4583
957	4211	Note that the statistics cover the same period as the Log dialog. If that is only displaying one revision then the statistics will not tell you very much.	4587
958	4215	Offline Mode	4591
959	4219	Go Offline Dialog	4595
960	4223	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.	4599
961	4227	Offline for now	4603
962	4231	Complete the current operation in offline mode, but retry the repository next time log data is requested.	4607
963	4235	Permanently offline	4611
964	4239	Remain in offline mode until a repository check is specifically requested. See .	4615
965	4243	Cancel	4619
966	4247	If you don't want to continue the operation with possibly stale data, just cancel.	4623
967	4251	Here you have three options:	4627
968	4255	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 TortoiseSVNSettings.	4631
969	4260	Refreshing the View	4636
970	4264	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.	4640
971	4268	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.	4644
972	4272	Viewing Differences	4648
973	4277	diff	4653
974	4281	compare	4657
975	4285	One of the commonest requirements in project development is to see what has changed. You might want to look at the differences between two revisions of the same file, or the differences between two separate files. TortoiseSVN provides a built-in tool named TortoiseMerge for viewing differences of text files. For viewing differences of image files, TortoiseSVN also has a tool named TortoiseIDiff. Of course, you can use your own favourite diff program if you like.	4661
976	4289	File Differences	4665
977	4293	Local changes	4669
978	4297	If you want to see what changes you have made in your working copy, just use the explorer context menu and select TortoiseSVNDiff.	4673
979	4301	Difference to another branch/tag	4677
980	4305	If you want to see what has changed on trunk (if you are working on a branch) or on a specific branch (if you are working on trunk), you can use the explorer context menu. Just hold down the Shift key while you right click on the file. Then select TortoiseSVNDiff with URL. In the following dialog, specify the URL in the repository with which you want to compare your local file to.	4681
981	4309	You can also use the repository browser and select two trees to diff, perhaps two tags, or a branch/tag and trunk. The context menu there allows you to compare them using Compare revisions. Read more in .	4685
982	4313	Difference from a previous revision	4689
983	4317	If you want to see the difference between a particular revision and your working copy, use the Revision Log dialog, select the revision of interest, then select Compare with working copy from the context menu.	4693
984	4321	If you want to see the difference between the last committed revision and your working copy, assuming that the working copy hasn't been modified, just right click on the file. Then select TortoiseSVNDiff with previous version. This will perform a diff between the revision before the last-commit-date (as recorded in your working copy) and the working BASE. This shows you the last change made to that file to bring it to the state you now see in your working copy. It will not show changes newer than your working copy.	4697
985	4325	Difference between two previous revisions	4701
986	4329	If you want to see the difference between two revisions which are already committed, use the Revision Log dialog and select the two revisions you want to compare (using the usual Ctrl-modifier). Then select Compare revisions from the context menu.	4705
987	4333	If you did this from the revision log for a folder, a Compare Revisions dialog appears, showing a list of changed files in that folder. Read more in .	4709
988	4337	All changes made in a commit	4713
989	4341	If you want to see the changes made to all files in a particular revision in one view, you can use Unified-Diff output (GNU patch format). This shows only the differences with a few lines of context. It is harder to read than a visual file compare, but will show all the changes together. From the Revision Log dialog select the revision of interest, then select Show Differences as Unified-Diff from the context menu.	4717
990	4345	Difference between files	4721
991	4349	If you want to see the differences between two different files, you can do that directly in explorer by selecting both files (using the usual Ctrl-modifier). Then from the explorer context menu select TortoiseSVNDiff.	4725
992	4353	Difference between WC file/folder and a URL	4729
993	4357	If you want to see the differences between a file in your working copy, and a file in any Subversion repository, you can do that directly in explorer by selecting the file then holding down the Shift key whilst right clicking to obtain the context menu. Select TortoiseSVNDiff with URL. You can do the same thing for a working copy folder. TortoiseMerge shows these differences in the same way as it shows a patch file - a list of changed files which you can view one at a time.	4733
994	4361	Difference with blame information	4737
995	4365	If you want to see not only the differences but also the author, revision and date that changes were made, you can combine the diff and blame reports from within the revision log dialog. Read for more detail.	4741
996	4369	Difference between folders	4745
997	4373	The built-in tools supplied with TortoiseSVN do not support viewing differences between directory hierarchies. But if you have an external tool which does support that feature, you can use that instead. In we tell you about some tools which we have used.	4749
998	4377	If you have configured a third party diff tool, you can use Shift when selecting the Diff command to use the alternate tool. Read to find out about configuring other diff tools.	4753
999	4381	Line-end and Whitespace Options	4757
1000	4385	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.	4761
1001	4389	Ignore line endings excludes changes which are due solely to difference in line-end style.	4765
1002	4393	Compare whitespaces includes all changes in indentation and inline whitespace as added/removed lines.	4769
1003	4397	Ignore whitespace changes excludes changes which are due solely to a change in the amount or type of whitespace, eg. 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.	4773
1004	4401	Ignore all whitespaces excludes all whitespace-only changes.	4777
1005	4405	Naturally, any line with changed content is always included in the diff.	4781
1006	4409	Comparing Folders	4785
1007	4413	compare revisions	4789
1008	4417	export changes	4793
1009	4421	The Compare Revisions Dialog	4797
1010	4425	When you select two trees within the repository browser, or when you select two revisions of a folder in the log dialog, you can Context menuCompare revisions.	4801
1011	4429	This dialog shows a list of all files which have changed and allows you to compare or blame them individually using context menu.	4805
1012	4433	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 menuExport selection to.... You will be prompted for a location to save the change tree.	4809
1013	4437	You can also export the list of changed files to a text file using Context menuSave list of selected files to....	4813
1014	4441	If you want to export the list of files and the actions (modified, added, deleted) as well, you can do that using Context menuCopy selection to clipboard.	4817
1015	4445	The button at the top allows you to change the direction of comparison. You can show the changes need to get from A to B, or if you prefer, from B to A.	4821
1016	4449	The buttons with the revision numbers on can be used to change to a different revision range. When you change the range, the list of items which differ between the two revisions will be updated automatically.	4825
1017	4453	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.	4829
1018	4457	Diffing Images Using TortoiseIDiff	4833
1019	4461	image diff	4837
1020	4469	There are many tools available for diffing text files, including our own TortoiseMerge, but we often find ourselves wanting to see how an image file has changed too. That's why we created TortoiseIDiff.	4845
1021	4473	The image difference viewer	4849
1022	4477	TortoiseSVNDiff 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.	4853
1023	4481	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.	4857
1024	4485	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 ViewImage Info to hide it. You can get the same information in a tooltip if you hover the mouse over the image title bar.	4861
1025	4489	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.	4865
1026	4493	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.	4869
1027	4497	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.	4873
1028	4501	External Diff/Merge Tools	4877
1029	4505	diff tools	4881
1030	4509	merge tools	4885
1031	4513	If the tools we provide don't do what you need, try one of the many open-source or commercial programs available. Everyone has their own favourites, and this list is by no means complete, but here are a few that you might consider:	4889
1032	4521	WinMerge is a great open-source diff tool which can also handle directories.	4897
1033	4525	Perforce Merge	4901
1034	4529	Perforce is a commercial RCS, but you can download the diff/merge tool for free. Get more information from Perforce.	4905
1035	4537	KDiff3 is a free diff tool which can also handle directories. You can download it from here.	4913
1036	4545	ExamDiff Standard is freeware. It can handle files but not directories. ExamDiff Pro is shareware and adds a number of goodies including directory diff and editing capability. In both flavours, version 3.2 and above can handle unicode. You can download them from PrestoSoft.	4921
1037	4549	Beyond Compare	4925
1038	4553	Similar to ExamDiff Pro, this is an excellent shareware diff tool which can handle directory diffs and unicode. Download it from Scooter Software.	4929
1039	4561	Araxis Merge is a useful commercial tool for diff and merging both files and folders. It does three-way comparison in merges and has synchronization links to use if you've changed the order of functions. Download it from Araxis.	4937
1040	4569	This text editor includes syntax colouring for unified diffs, making them much easier to read. Download it from Scintilla.	4945
1041	4577	Notepad2 is designed as a replacement for the standard Windows Notepad program, and is based on the Scintilla open-source edit control. As well as being good for viewing unified diffs, it is much better than the Windows notepad for most jobs. Download it for free here.	4953
1042	4581	Read for information on how to set up TortoiseSVN to use these tools.	4957
1043	4585	Adding New Files And Directories	4961
1044	4589	add	4965
1045	4593	version new files	4969
1046	4598	Explorer context menu for unversioned files	4974
1047	4602	If you created new files and/or directories during your development process then you need to add them to source control too. Select the file(s) and/or directory and use TortoiseSVNAdd.	4978
1048	4606	After you added the files/directories to source control the file appears with a added icon overlay which means you first have to commit your working copy to make those files/directories available to other developers. Adding a file/directory does not affect the repository!	4982
1049	4610	Many Adds	4986
1050	4614	You can also use the Add command on already versioned folders. In that case, the add dialog will show you all unversioned files inside that versioned folder. This helps if you have many new files and need to add them all at once.	4990
1051	4618	select the files you want to add	4994
1052	4623	right-drag them to the new location inside the working copy	4999
1053	4628	release the right mouse button	5004
1054	4632	select Context MenuSVN Add files to this WC. The files will then be copied to the working copy and added to version control.	5008
1055	4636	To add files from outside your working copy you can use the drag-and-drop handler:	5012
1056	4640	You can also add files within a working copy simply by left-dragging and dropping them onto the commit dialog.	5016
1057	4644	If you add a file or folder by mistake, you can undo the addition before you commit using TortoiseSVNUndo add....	5020
1058	4648	Copying/Moving/Renaming Files and Folders	5024
1059	4652	copy files	5028
1060	4656	rename files	5032
1061	4660	move files	5036
1062	4665	branch	5041
1063	4670	tag	5046
1064	4674	It often happens that you already have the files you need in another project in your repository, and you simply want to copy them across. You could simply copy the files and add them as described above, but that would not give you any history. And if you subsequently fix a bug in the original files, you can only merge the fix automatically if the new copy is related to the original in Subversion.	5050
1065	4678	The easiest way to copy files and folders from within a working copy is to use the right-drag menu. When you right-drag a file or folder from one working copy to another, or even within the same folder, a context menu appears when you release the mouse. Now you can copy existing versioned content to a new location, possibly renaming it at the same time.	5054
1066	4682	You can also copy or move versioned files within a working copy, or between two working copies, using the familiar cut-and-paste method. Use the standard Windows Copy or Cut to copy one or more versioned items to the clipboard. If the clipboard contains such versioned items, you can then use TortoiseSVNPaste (note: not the standard Windows Paste) to copy or move those items to the new working copy location.	5058
1067	4686	You can copy files and folders from your working copy to another location in the repository using TortoiseSVNBranch/Tag. Refer to to find out more.	5062
1068	4690	You can locate an older version of a file or folder in the log dialog and copy it to a new location in the repository directly from the log dialog using Context menuCreate branch/tag from revision. Refer to to find out more.	5066
1069	4694	You can also use the repository browser to locate content you want, and copy it into your working copy directly from the repository, or copy between two locations within the repository. Refer to to find out more.	5070
1070	4698	Cannot copy between repositories	5074
1071	4702	Whilst you can copy or move files and folders within a repository, you cannot copy or move from one repository to another while preserving history using TortoiseSVN. Not even if the repositories live on the same server. All you can do is copy the content in its current state and add it as new content to the second repository.	5078
1072	4706	If you are uncertain whether two URLs on the same server refer to the same or different repositories, use the repo browser to open one URL and find out where the repository root is. If you can see both locations in one repo browser window then they are in the same repository.	5082
1073	4710	Ignoring Files And Directories	5086
1074	4714	ignore	5090
1075	4718	unversioned files/folders	5094
1076	4722	In most projects you will have files and folders that should not be subject to version control. These might include files created by the compiler, *.obj, *.lst, maybe an output folder used to store the executable. Whenever you commit changes, TortoiseSVN shows your unversioned files, which fills up the file list in the commit dialog. Of course you can turn off this display, but then you might forget to add a new source file.	5098
1077	4726	The best way to avoid these problems is to add the derived files to the project's ignore list. That way they will never show up in the commit dialog, but genuine unversioned source files will still be flagged up.	5102
1078	4730	If you right click on a single unversioned file, and select the command TortoiseSVNAdd to Ignore List from the context menu, a submenu appears allowing you to select just that file, or all files with the same extension. If you select multiple files, there is no submenu and you can only add those specific files/folders.	5106
1079	4734	If you want to remove one or more items from the ignore list, right click on those items and select TortoiseSVNRemove from Ignore List You can also access a folder's svn:ignore property directly. That allows you to specify more general patterns using filename globbing, described in the section below. Read for more information on setting properties directly. Please be aware that each ignore pattern has to be placed on a separate line. Separating them by spaces does not work.	5110
1080	4738	The Global Ignore List	5114
1081	4742	Another way to ignore files is to add them to the global ignore list. The big difference here is that the global ignore list is a client property. It applies to all Subversion projects, but on the client PC only. In general it is better to use the svn:ignore property where possible, because it can be applied to specific project areas, and it works for everyone who checks out the project. Read for more information.	5118
1082	4746	Ignoring Versioned Items	5122
1083	4750	Versioned files and folders can never be ignored - that's a feature of Subversion. If you versioned a file by mistake, read for instructions on how to unversion it.	5126
1084	4754	Pattern Matching in Ignore Lists	5130
1085	4758	globbing	5134
1086	4762	pattern matching	5138
1087	4770	Matches any string of characters, including the empty string (no characters).	5146
1088	4778	Matches any single character.	5154
1089	4786	Matches any one of the characters enclosed in the square brackets. Within the brackets, a pair of characters separated by - matches any character lexically between the two. For example [AGm-p] matches any one of A, G, m, n, o or p.	5162
1090	4790	Subversion's ignore patterns make use of filename globbing, a technique originally used in Unix to specify files using meta-characters as wildcards. The following characters have special meaning:	5166
1091	4794	Pattern matching is case sensitive, which can cause problems on Windows. You can force case insensitivity the hard way by pairing characters, eg. to ignore *.tmp regardless of case, you could use a pattern like *.[Tt][Mm][Pp].	5170
1092	4798	If you want an official definition for globbing, you can find it in the IEEE specifications for the shell command language Pattern Matching Notation.	5174
1093	4802	No Paths in Global Ignore List	5178
1094	4806	You should not include path information in your pattern. The pattern matching is intended to be used against plain file names and folder names. If you want to ignore all CVS folders, just add CVS to the ignore list. There is no need to specify CVS */CVS as you did in earlier versions. If you want to ignore all tmp folders when they exist within a prog folder but not within a doc folder you should use the svn:ignore property instead. There is no reliable way to achieve this using global ignore patterns.	5182
1095	4810	Deleting, Moving and Renaming	5186
1096	4814	Explorer context menu for versioned files	5190
1097	4818	Unlike CVS, Subversion allows renaming and moving of files and folders. So there are menu entries for delete and rename in the TortoiseSVN submenu.	5194
1098	4822	Deleting files and folders	5198
1099	4826	delete	5202
1100	4830	remove	5206
1101	4834	Use TortoiseSVNDelete to remove files or folders from subversion.	5210
1102	4838	When you TortoiseSVNDelete a file, it is removed from your working copy immediately as well as being marked for deletion in the repository on next commit. The file's parent folder shows a deleted icon overlay. Up until you commit the change, you can get the file back using TortoiseSVNRevert on the parent folder.	5214
1103	4842	When you TortoiseSVNDelete a folder, it remains in your working copy, but the overlay changes to indicate that it is marked for deletion. Up until you commit the change, you can get the folder back using TortoiseSVNRevert on the folder itself. This difference in behaviour between files and folders is a part of Subversion, not TortoiseSVN.	5218
1104	4846	If you want to delete an item from the repository, but keep it locally as an unversioned file/folder, use Extended Context MenuDelete (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.	5222
1105	4850	If a file is deleted via the explorer instead of using the TortoiseSVN context menu, the commit dialog shows those files and lets you remove them from version control too before the commit. However, if you update your working copy, Subversion will spot the missing file and replace it with the latest version from the repository. If you need to delete a version-controlled file, always use TortoiseSVNDelete so that Subversion doesn't have to guess what you really want to do.	5226
1106	4854	If a folder is deleted via the explorer instead of using the TortoiseSVN context menu, your working copy will be broken and you will be unable to commit. If you update your working copy, Subversion will replace the missing folder with the latest version from the repository and you can then delete it the correct way using TortoiseSVNDelete.	5230
1107	4858	Getting a deleted file or folder back	5234
1108	4862	If you have deleted a file or a folder and already committed that delete operation to the repository, then a normal TortoiseSVNRevert can't bring it back anymore. But the file or folder is not lost at all. If you know the revision the file or folder got deleted (if you don't, use the log dialog to find out) open the repository browser and switch to that revision. Then select the file or folder you deleted, right-click and select Context MenuCopy to... as the target for that copy operation select the path to your working copy.	5238
1109	4866	Moving files and folders	5242
1110	4872	rename	5248
1111	4876	move	5252
1112	4880	If you want to do a simple in-place rename of a file or folder, use Context MenuRename... Enter the new name for the item and you're done.	5256
1113	4884	select the files or directories you want to move	5260
1114	4888	in the popup menu select Context MenuSVN Move versioned files here	5264
1115	4892	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:	5268
1116	4896	Commit the parent folder	5272
1117	4900	Since renames and moves are done as a delete followed by an add you must commit the parent folder of the renamed/moved file so that the deleted part of the rename/move will show up in the commit dialog. If you don't commit the removed part of the rename/move, it will stay behind in the repository and when your co-workers update, the old file will not be removed. i.e. they will have both the old and the new copies.	5276
1118	4904	You must commit a folder rename before changing any of the files inside the folder, otherwise your working copy can get really messed up.	5280
1119	4908	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 MenuCopy from the explorer context menu. Then browse to the target folder, right-click and choose TortoiseSVNPaste. For moving files, choose Context MenuCut instead of Context MenuCopy.	5284
1120	4912	You can also use the repository browser to move items around. Read to find out more.	5288
1121	4916	Do Not SVN Move Externals	5292
1122	4920	You should not use the TortoiseSVN Move or Rename commands on a folder which has been created using svn:externals. This action would cause the external item to be deleted from its parent repository, probably upsetting many other people. If you need to move an externals folder you should use an ordinary shell move, then adjust the svn:externals properties of the source and destination parent folders.	5296
1123	4924	Changing case in a filename	5300
1124	4928	case change	5304
1125	4932	Making case-only changes to a filename is tricky with Subversion on Windows, because for a short time during a rename, both filenames have to exist. As Windows has a case-insensitive file system, this does not work using the usual Rename command.	5308
1126	4936	Fortunately there are (at least) two possible methods to rename a file without losing its log history. It is important to rename it within subversion. Just renaming in the explorer will corrupt your working copy!	5312
1127	4940	Commit the changes in your working copy.	5316
1128	4944	Rename the file from UPPERcase to upperCASE directly in the repository using the repository browser.	5320
1129	4948	Update your working copy.	5324
1130	4952	Solution A) (recommended)	5328
1131	4956	Rename from UPPERcase to UPPERcase_ with the rename command in the TortoiseSVN submenu.	5332
1132	4961	Commit the changes.	5337
1133	4965	Rename from UPPERcase_ to upperCASE.	5341
1134	4969	Solution B)	5345
1135	4973	Dealing with filename case conflicts	5349
1136	4977	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.	5353
1137	4981	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.	5357
1138	4985	In that case, you have to decide which one of them you want to keep and delete (or rename) the other one from the repository.	5361
1139	4989	Preventing two files with the same name	5365
1140	4993	There is a server hook script available at: http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/ that will prevent checkins which result in case conflicts.	5369
1141	4997	Repairing File Renames	5373
1142	5001	Sometimes your friendly IDE will rename files for you as part of a refactoring exercise, and of course it doesn't tell Subversion. If you try to commit your changes, Subversion will see the old filename as missing and the new one as an unversioned file. You could just check the new filename to get it added in, but you would then lose the history tracing, as Subversion does not know the files are related.	5377
1143	5005	A better way is to notify Subversion that this change is actually a rename, and you can do this within the Commit and Check for Modifications dialogs. Simply select both the old name (missing) and the new name (unversioned) and use Context MenuRepair Move to pair the two files as a rename.	5381
1144	5009	Deleting Unversioned Files	5385
1145	5013	Usually you set your ignore list such that all generated files are ignored in Subversion. But what if you want to clear all those ignored items to produce a clean build? Usually you would set that in your makefile, but if you are debugging the makefile, or changing the build system it is useful to have a way of clearing the decks.	5389
1146	5017	TortoiseSVN provides just such an option using Extended Context MenuDelete unversioned items.... You have to hold the Shift while right clicking on a folder in the explorer list pane (right pane) in order to see this in the extended context menu. This will produce a dialog which lists all unversioned files anywhere in your working copy. You can then select or deselect items to be removed.	5393
1147	5021	When such items are deleted, the recycle bin is used, so if you make a mistake here and delete a file that should have been versioned, you can still recover it.	5397
1148	5025	Undo Changes	5401
1149	5030	revert	5406
1150	5034	undo	5410
1151	5038	clean	5414
1152	5042	Revert dialog	5418
1153	5046	If you want to undo all changes you made in a file since the last update you need to select the file, right click to pop up the context menu and then select the command TortoiseSVNRevert A dialog will pop up showing you the files that you've changed and can revert. Select those you want to revert and click on OK.	5422
1154	5050	If you want to undo a deletion or a rename, you need to use Revert on the parent folder as the deleted item does not exist for you to right-click on.	5426
1155	5054	If you want to undo the addition of an item, this appears in the context menu as TortoiseSVNUndo add.... This is really a revert as well, but the name has been changed to make it more obvious.	5430
1156	5059	The columns in this dialog can be customized in the same way as the columns in the Check for modifications dialog. Read for further details.	5435
1157	5063	Since revert is sometimes used to clean up a working copy, there is an extra button which allows you to delete unversioned items as well. When you click this button another dialog comes up listing all the unversioned items, which you can then select for deletion.	5439
1158	5067	Undoing Changes which have been Committed	5443
1159	5071	Revert will only undo your local changes. It does not undo any changes which have already been committed. If you want to undo all the changes which were committed in a particular revision, read for further information.	5447
1160	5075	Revert is Slow	5451
1161	5079	When you revert changes you may find that the operation takes a lot longer than you expect. This is because the modified version of the file is sent to the recycle bin, so you can retrieve your changes if you reverted by mistake. However, if your recycle bin is full, Windows takes a long time to find a place to put the file. The solution is simple: either empty the recycle bin or deactivate the Use recycle bin when reverting box in TortoiseSVN's settings.	5455
1162	5086	Cleanup	5462
1163	5090	cleanup	5466
1164	5094	If a Subversion command cannot complete successfully, perhaps due to server problems, your working copy can be left in an inconsistent state. In that case you need to use TortoiseSVNCleanup on the folder. It is a good idea to do this at the top level of the working copy.	5470
1165	5098	Cleanup has another useful side effect. If a file date changes but its content doesn't, Subversion cannot tell whether it has really changed except by doing a byte-by-byte comparison with the pristine copy. If you have a lot of files in this state it makes acquiring status very slow, which will make many dialogs slow to respond. Executing a Cleanup on your working copy will repair these broken timestamps and restore status checks to full speed.	5474
1166	5102	Use Commit Timestamps	5478
1167	5106	Some earlier releases of Subversion were affected by a bug which caused timestamp mismatch when you check out with the Use commit timestamps option checked. Use the Cleanup command to speed up these working copies.	5482
1168	5110	Project Settings	5486
1169	5114	properties	5490
1170	5118	Explorer property page, Subversion tab	5494
1171	5122	Sometimes you want to have more detailed information about a file/directory than just the icon overlay. You can get all the information Subversion provides in the explorer properties dialog. Just select the file or directory and select Windows Menuproperties in the context menu (note: this is the normal properties menu entry the explorer provides, not the one in the TortoiseSVN submenu!). In the properties dialog box TortoiseSVN has added a new property page for files/folders under Subversion control, where you can see all relevant information about the selected file/directory.	5498
1172	5126	Subversion Properties	5502
1173	5130	Subversion properties	5506
1174	5134	Subversion property page	5510
1175	5138	You can read and set the Subversion properties from the Windows properties dialog, but also from TortoiseSVNproperties and within TortoiseSVN's status lists, from Context menuproperties.	5514
1176	5142	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 .	5518
1177	5150	keywords	5526
1178	5154	expand keywords	5530
1179	5158	Date of last known commit. This is based on information obtained when you update your working copy. It does not check the repository to find more recent changes.	5534
1180	5162	Revision of last known commit.	5538
1181	5166	Author who made the last known commit.	5542
1182	5170	The full URL of this file in the repository.	5546
1183	5174	A compressed combination of the previous four keywords.	5550
1184	5178	Subversion supports CVS-like keyword expansion which can be used to embed filename and revision information within the file itself. Keywords currently supported are:	5554
1185	5182	To find out how to use these keywords, look at the svn:keywords section in the Subversion book, which gives a full description of these keywords and how to enable and use them.	5558
1186	5186	For more information about properties in Subversion see the Special Properties.	5562
1187	5190	Adding and Editing Properties	5566
1188	5194	Adding properties	5570
1189	5198	To add a new property, first click on Add.... Select the required property name from the combo box, or type in a name of your own choice, then enter a value in the box below. Properties which take multiple values, such as an ignore list, can be entered on multiple lines. Click on OK to add that property to the list.	5574
1190	5202	If you want to apply a property to many items at once, select the files/folders in explorer, then select Context menuproperties	5578
1191	5206	If you want to apply the property to every file and folder in the hierarchy below the current folder, check the Recursive checkbox.	5582
1192	5210	Some properties, for example svn:needs-lock, can only be applied to files, so the property name doesn't appear in the drop down list for folders. You can still apply such a property recursively to all files in a hierarchy, but you have to type in the property name yourself.	5586
1193	5214	If you wish to edit an existing property, select that property from the list of existing properties, then click on Edit....	5590
1194	5218	If you wish to remove an existing property, select that property from the list of existing properties, then click on Remove.	5594
1195	5222	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 .	5598
1196	5226	Edit properties at HEAD revision
1197	5230	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.
1198	5234	Exporting and Importing Properties	5602
1199	5238	Often you will find yourself applying the same set of properties many times, for example bugtraq:logregex. To simplify the process of copying properties from one project to another, you can use the Export/Import feature.	5606
1200	5242	From the file or folder where the properties are already set, use TortoiseSVNproperties, select the properties you wish to export and click on Export.... You will be prompted for a filename where the property names and values will be saved.	5610
1201	5246	From the folder(s) where you wish to apply these properties, use TortoiseSVNproperties and click on Import.... You will be prompted for a filename to import from, so navigate to the place you saved the export file previously and select it. The properties will be added to the folders non-recursively.	5614
1202	5250	If you want to add properties to a tree recursively, follow the steps above, then in the property dialog select each property in turn, click on Edit..., check the Apply property recursively box and click on OK.	5618
1203	5254	The Import file format is binary and proprietary to TortoiseSVN. Its only purpose is to transfer properties using Import and Export, so there is no need to edit these files.	5622
1204	5258	Binary Properties	5626
1205	5262	TortoiseSVN can handle binary property values using files. To read a binary property value, Save... to a file. To set a binary value, use a hex editor or other appropriate tool to create a file with the content you require, then Load... from that file.	5630
1206	5266	Although binary properties are not often used, they can be useful in some applications. For example if you are storing huge graphics files, or if the application used to load the file is huge, you might want to store a thumbnail as a property so you can obtain a preview quickly.	5634
1207	5270	Automatic property setting	5638
1208	5278	You can configure Subversion and TortoiseSVN to set properties automatically on files and folders when they are added to the repository. There are two ways of doing this.	5646
1209	5282	You can edit the subversion configuration file to enable this feature on your client. The General page of TortoiseSVN's settings dialog has an edit button to take you there directly. The config file is a simple text file which controls some of subversion's workings. You need to change two things: firstly in the section headed miscellany uncomment the line enable-auto-props = yes. Secondly you need to edit the section below to define which properties you want added to which file types. This method is a standard subversion feature and works with any subversion client. However it has to be defined on each client individually - there is no way to propagate these settings from the repository.	5650
1210	5286	An alternative method is to set the tsvn:autoprops property on folders, as described in the next section. This method only works for TortoiseSVN clients, but it does get propagated to all working copies on update.	5654
1211	5290	Whichever method you choose, you should note that auto-props are only applied to files at the time they are added to the repository. Auto-props will never change the properties of files which are already versioned.	5658
1212	5294	If you want to be absolutely sure that new files have the correct properties applied, you should set up a repository pre-commit hook to reject commits where the required properties are not set.	5662
1213	5298	Commit properties	5666
1214	5302	Subversion properties are versioned. After you change or add a property you have to commit your changes.	5670
1215	5306	Conflicts on properties	5674
1216	5310	If there's a conflict on committing the changes, because another user has changed the same property, Subversion generates a .prej file. Delete this file after you have resolved the conflict.	5678
1217	5314	TortoiseSVN Project Properties	5682
1218	5318	project properties	5686
1219	5322	TortoiseSVN properties	5690
1220	5326	tsvn:logminsize sets the minimum length of a log message for a commit. If you enter a shorter message than specified here, the commit is disabled. This feature is very useful for reminding you to supply a proper descriptive message for every commit. If this property is not set, or the value is zero, empty log messages are allowed.	5694
1221	5330	tsvn:lockmsgminsize sets the minimum length of a lock message. If you enter a shorter message than specified here, the lock is disabled. This feature is very useful for reminding you to supply a proper descriptive message for every lock you get. If this property is not set, or the value is zero, empty lock messages are allowed.	5698
1222	5334	tsvn:logwidthmarker is used with projects which require log messages to be formatted with some maximum width (typically 80 characters) before a line break. Setting this property to a non-zero will do 2 things in the log message entry dialog: it places a marker to indicate the maximum width, and it disables word wrap in the display, so that you can see whether the text you entered is too long. Note: this feature will only work correctly if you have a fixed-width font selected for log messages.	5702
1223	5338	tsvn:logtemplate is used with projects which have rules about log message formatting. The property holds a multi-line text string which will be inserted in the commit message box when you start a commit. You can then edit it to include the required information. Note: if you are also using tsvn:logminsize, be sure to set the length longer than the template or you will lose the protection mechanism.	5706
1224	5342	Subversion allows you to set autoprops which will be applied to newly added or imported files, based on the file extension. This depends on every client having set appropriate autoprops in their subversion configuration file. tsvn:autoprops can be set on folders and these will be merged with the user's local autoprops when importing or adding files. The format is the same as for subversion autoprops, e.g. *.sh = svn:eol-style=native;svn:executable sets two properties on files with the .sh extension.	5710
1225	5346	If there is a conflict between the local autoprops and tsvn:autoprops, the project settings take precedence because they are specific to that project.	5714
1226	5350	In the Commit dialog you have the option to paste in the list of changed files, including the status of each file (added, modified, etc). tsvn:logfilelistenglish defines whether the file status is inserted in English or in the localized language. If the property is not set, the default is true.	5718
1227	5354	TortoiseSVN can use spell checker modules which are also used by OpenOffice and Mozilla. If you have those installed this property will determine which spell checker to use, i.e. in which language the log messages for your project should be written. tsvn:projectlanguage sets the language module the spell checking engine should use when you enter a log message. You can find the values for your language on this page: MSDN: Language Identifiers.	5722
1228	5358	You can enter this value in decimal, or in hexadecimal if prefixed with 0x. For example English (US) can be entered as 0x0409 or 1033.	5726
1229	5362	The property tsvn:logsummary is used to extract a portion of the log message which is then shown in the log dialog as the log message summary.	5730
1230	5366	The value of the tsvn:logsummary property must be set to a one line regex string which contains one regex group. Whatever matches that group is used as the summary.	5734
1231	5370	An example: \\[SUMMARY\\]:\\s+(.*) Will catch everything after [SUMMARY] in the log message and use that as the summary.	5738
1232	5374	The property tsvn:logrevregex defines a regular expression which matches references to revisions in a log message. This is used in the log dialog to turn such references into links which when clicked will either scroll to that revision (if the revision is already shown in the log dialog, or if it's available from the log cache) or open a new log dialog showing that revision.	5742
1233	5378	The regular expression must match the whole reference, not just the revision number. The revision number is extracted from the matched reference string automatically.	5746
1234	5382	If this property is not set, a default regular expression is used to link revision references.	5750
1235	5386	When you want to add a new property, you can either pick one from the list in the combo box, or you can enter any property name you like. If your project uses some custom properties, and you want those properties to appear in the list in the combo box (to avoid typos when you enter a property name), you can create a list of your custom properties using tsvn:userfileproperties and tsvn:userdirproperties. Apply these properties to a folder. When you go to edit the properties of any child item, your custom properties will appear in the list of pre-defined property names.	5754
1236	5390	TortoiseSVN has a few special properties of its own, and these begin with tsvn:.	5758
1237	5395	Some tsvn: properties require a true/false value. TortoiseSVN also understands yes as a synonym for true and no as a synonym for false.	5763
1238	5399	TortoiseSVN can integrate with some bug tracking tools. This uses project properties that start with bugtraq:. Read for further information.	5767
1239	5403	It can also integrate with some web-based repository browsers, using project properties that start with webviewer:. Read for further information.	5771
1240	5407	Set the project properties on folders	5775
1241	5411	These special project properties must be set on folders for the system to work. When you commit a file or folder the properties are read from that folder. If the properties are not found there, TortoiseSVN will search upwards through the folder tree to find them until it comes to an unversioned folder, or the tree root (eg. C:\\) is found. If you can be sure that each user checks out only from e.g trunk/ and not some sub-folder, then it is sufficient to set the properties on trunk/. If you can't be sure, you should set the properties recursively on each sub-folder. A property setting deeper in the project hierarchy overrides settings on higher levels (closer to trunk/).	5779
1242	5417	For project properties only, i.e. tsvn:, bugtraq: and webviewer: you can use the Recursive checkbox to set the property to all sub-folders in the hierarchy, without also setting it on all files.	5785
1243	5423	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.	5791
1244	5428	Limitations Using the Repository Browser	5796
1245	5432	Fetching properties remotely is a slow operation, so some of the features described above will not work in the repository browser as they do in a working copy.	5800
1246	5436	When you add a property using the repo browser, only the standard svn: properties are offered in the pre-defined list. Any other property name must be entered manually.	5804
1247	5440	Properties cannot be set or deleted recursively using the repo browser.	5808
1248	5444	Project properties will not be propagated automatically when a child folder is added using the repo browser.	5812
1249	5448	tsvn:autoprops will not set properties on files which are added using the repo browser.	5816
1250	5452	Although TortoiseSVN's project properties are extremely useful, they only work with TortoiseSVN, and some will only work in newer versions of TortoiseSVN. If people working on your project use a variety of Subversion clients, or possibly have old versions of TortoiseSVN, you may want to use repository hooks to enforce project policies. project properties can only help to implement a policy, they cannot enforce it.	5820
1251	5456	External Items	5824
1252	5460	external repositories	5828
1253	5465	externals	5833
1254	5469	Sometimes it is useful to construct a working copy that is made out of a number of different checkouts. For example, you may want different files or subdirectories to come from different locations in a repository, or perhaps from different repositories altogether. If you want every user to have the same layout, you can define the svn:externals properties to pull in the specified resource at the locations where they are needed.	5837
1255	5473	External Folders	5841
1256	5477	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 MenuProperties from the context menu. The Properties Dialog comes up. Then go to the Subversion tab. There, you can set properties. Click Add.... Select the svn:externals property from the combobox and write in the edit box the repository URL in the format url folder or if you want to specify a particular revision, -rREV url folder You can add multiple external projects, 1 per line. Suppose that you have set these properties on D:\\dev\\project1: \n http://sounds.red-bean.com/repos sounds\n http://graphics.red-bean.com/repos/fast%20graphics \"quick graphs\"\n -r21 http://svn.red-bean.com/repos/skin-maker skins/toolkit\n Now click Set and commit your changes. When you (or any other user) update your working copy, Subversion will create a sub-folder D:\\dev\\project1\\sounds and checkout the sounds project, another sub-folder D:\\dev\\project1\\quick_graphs containing the graphics project, and finally a nested sub-folder D:\\dev\\project1\\skins\\toolkit containing revision 21 of the skin-maker project.	5845
1257	5481	URLs must be properly escaped or they will not work, e.g. you must replace each space with %20 as shown in the second example above.	5854
1258	5485	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.	5858
1259	5489	Use explicit revision numbers	5862
1260	5493	You should strongly consider using explicit revision numbers in all of your externals definitions, as described above. Doing so means that you get to decide when to pull down a different snapshot of external information, and exactly which snapshot to pull. Besides the common sense aspect of not being surprised by changes to third-party repositories that you might not have any control over, using explicit revision numbers also means that as you backdate your working copy to a previous revision, your externals definitions will also revert to the way they looked in that previous revision, which in turn means that the external working copies will be updated to match they way they looked back when your repository was at that previous revision. For software projects, this could be the difference between a successful and a failed build of an older snapshot of your complex code base.	5866
1261	5497	Older svn:externals definitions	5870
1262	5501	The format shown here was introduced in Subversion 1.5. You may also see the older format which has the same information in a different order. The new format is preferred as it supports several useful features described below, but it will not work on older clients. The differences are shown in the Subversion Book.	5874
1263	5506	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.	5879
1264	5511	If the external project is in a different repository, any changes you make to the external project will be notified when you commit the main project, but you have to commit those external changes separately.	5884
1265	5515	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.	5888
1266	5519	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.	5892
1267	5523	Relative to parent directory	5896
1268	5527	These URLs always begin with the string ../ for example: \n ../../widgets/foo common/foo-widget\n This will extract http://example.com/svn/repos-1/widgets/foo into C:\\Working\\common\\foo-widget.	5900
1269	5531	Note that the URL is relative to the URL of the directory with the svn:externals property, not to the directory where the external is written to disk.	5907
1270	5535	Relative to repository root	5911
1271	5539	These URLs always begin with the string ^/ for example: \n ^/widgets/foo common/foo-widget\n This will extract http://example.com/svn/repos-1/widgets/foo into C:\\Working\\common\\foo-widget.	5915
1272	5543	You can easily refer to other repositories with the same SVNParentPath (a common directory holding several repositories). For example: \n ^/../repos-2/hammers/claw common/claw-hammer\n This will extract http://example.com/svn/repos-2/hammers/claw into C:\\Working\\common\\claw-hammer.	5922
1273	5547	Relative to scheme	5929
1274	5551	URLs beginning with the string // copy only the scheme part of the URL. This is useful when the same hostname must the accessed with different schemes depending upon network location; e.g. clients in the intranet use http:// while external clients use svn+ssh://. For example: \n //example.com/svn/repos-1/widgets/foo common/foo-widget\n This will extract http://example.com/svn/repos-1/widgets/foo or svn+ssh://example.com/svn/repos-1/widgets/foo depending on which method was used to checkout C:\\Working.	5933
1275	5555	Relative to the server's hostname	5940
1276	5559	URLs beginning with the string / copy the scheme and the hostname part of the URL, for example: \n /svn/repos-1/widgets/foo common/foo-widget\n This will extract http://example.com/svn/repos-1/widgets/foo into C:\\Working\\common\\foo-widget. But if you checkout your working copy from another server at svn+ssh://another.mirror.net/svn/repos-1/project1/trunk then the external reference will extract svn+ssh://another.mirror.net/svn/repos-1/widgets/foo.	5944
1277	5563	You can also specify a peg revision after the URL if required, e.g. http://sounds.red-bean.com/repos@19.	5951
1278	5567	If you need more information how TortoiseSVN handles Properties read .	5955
1279	5571	To find out about different methods of accessing common sub-projects read .	5959
1280	5575	External Files	5963
1281	5579	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.	5967
1282	5583	The path to the file external must place the file in an existing versioned folder. In general it makes most sense to place the file directly in the folder that has svn:externals set, but it can be in a versioned sub-folder if necessary. By contrast, directory externals will automatically create any intermediate unversioned folders as required.	5971
1283	5587	The URL for a file external must be in the same repository as the URL that the file external will be inserted into; inter-repository file externals are not supported.	5975
1284	5591	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.	5979
1285	5595	File externals support incomplete in Subversion 1.6	5983
1286	5599	In subversion 1.6 it is not possible to remove a file external from your working copy once you have added it, even if you delete the svn:externals property altogether. You have to checkout a fresh working copy to remove the file.	5987
1287	5603	Branching / Tagging	5991
1288	5608	copy	5996
1289	5612	mark release	6000
1290	5616	One of the features of version control systems is the ability to isolate changes onto a separate line of development. This line is known as a branch. Branches are often used to try out new features without disturbing the main line of development with compiler errors and bugs. As soon as the new feature is stable enough then the development branch is merged back into the main branch (trunk).	6004
1291	5620	Another feature of version control systems is the ability to mark particular revisions (e.g. a release version), so you can at any time recreate a certain build or environment. This process is known as tagging.	6008
1292	5624	Subversion does not have special commands for branching or tagging, but uses so-called cheap copies instead. Cheap copies are similar to hard links in Unix, which means that instead of making a complete copy in the repository, an internal link is created, pointing to a specific tree/revision. As a result branches and tags are very quick to create, and take up almost no extra space in the repository.	6012
1293	5628	Creating a Branch or Tag	6016
1294	5632	The Branch/Tag Dialog	6020
1295	5636	If you have imported your project with the recommended directory structure, creating a branch or tag version is very simple: Select the folder in your working copy which you want to copy to a branch or tag, then select the command TortoiseSVNBranch/Tag....	6024
1296	5640	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 \n http://svn.collab.net/repos/ProjectName/trunk\n you might now use something like \n http://svn.collab.net/repos/ProjectName/tags/Release_1.10\n 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.	6028
1297	5645	HEAD revision in the repository	6038
1298	5649	The new branch is copied directly in the repository from the HEAD revision. No data needs to be transferred from your working copy, and the branch is created very quickly.	6042
1299	5653	Specific revision in the repository	6046
1300	5657	The new branch is copied directly in the repository but you can choose an older revision. This is useful if you forgot to make a tag when you released your project last week. If you can't remember the revision number, click the button on the right to show the revision log, and select the revision number from there. Again no data is transferred from your working copy, and the branch is created very quickly.	6050
1301	5661	The new branch is an identical copy of your local working copy. If you have updated some files to an older revision in your WC, or if you have made local changes, that is exactly what goes into the copy. Naturally this sort of complex tag may involve transferring data from your WC back to the repository if it does not exist there already.	6054
1302	5665	Now you have to select the source of the copy. Here you have three options:	6058
1303	5669	If you want your working copy to be switched to the newly created branch automatically, use the Switch working copy to new branch/tag checkbox. But if you do that, first make sure that your working copy does not contain modifications. If it does, those changes will be merged into the branch WC when you switch.	6062
1304	5673	Press OK to commit the new copy to the repository. Don't forget to supply a log message. Note that the copy is created inside the repository.	6066
1305	5677	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.	6070
1306	5681	Other ways to create a branch or tag	6074
1307	5685	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.	6078
1308	5689	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.	6082
1309	5693	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...	6086
1310	5697	To Checkout or to Switch...	6090
1311	5701	switch	6094
1312	5705	...that is (not really) the question. While a checkout downloads everything from the desired branch in the repository to your working directory, TortoiseSVNSwitch... only transfers the changed data to your working copy. Good for the network load, good for your patience. :-)	6098
1313	5709	TortoiseSVNCheckout to make a fresh checkout in an empty folder. You can check out to any location on your local disk and you can create as many working copies from your repository as you like.	6102
1314	5713	Switch your current working copy to the newly created copy in the repository. Again select the top level folder of your project and use TortoiseSVNSwitch... from the context menu.	6106
1315	5717	In the next dialog enter the URL of the branch you just created. Select the Head Revision radio button and click on OK. Your working copy is switched to the new branch/tag.	6110
1316	5721	Switch works just like Update in that it never discards your local changes. Any changes you have made to your working copy which have not yet been committed will be merged when you do the Switch. If you do not want this to happen then you must either commit the changes before switching, or revert your working copy to an already-committed revision (typically HEAD).	6114
1317	5725	If you want to work on trunk and branch, but don't want the expense of a fresh checkout, you can use Windows Explorer to make a copy of your trunk checkout in another folder, then TortoiseSVNSwitch... that copy to your new branch.	6118
1318	5729	The Switch Dialog	6122
1319	5733	To be able to work with your freshly generated branch or tag you have several ways to handle it. You can:	6126
1320	5737	Tags are typically used to create a static snapshot of the project at a particular stage. As such they are not normally used for development - that's what branches are for, which is the reason we recommended the /trunk /branches /tags repository structure in the first place. Working on a tag revision is not a good idea, but because your local files are not write protected there is nothing to stop you doing this by mistake. However, if you try to commit to a path in the repository which contains /tags/, TortoiseSVN will warn you.	6130
1321	5741	It may be that you need to make further changes to a release which you have already tagged. The correct way to handle this is to create a new branch from the tag first and commit the branch. Do your Changes on this branch and then create a new tag from this new branch, e.g. Version_1.0.1.	6134
1322	5745	If you modify a working copy created from a branch and commit, then all changes go to the new branch and not the trunk. Only the modifications are stored. The rest remains a cheap copy.	6138
1323	5749	Although Subversion itself makes no distinction between tags and branches, the way they are typically used differs a bit.	6142
1324	5753	Merging	6146
1325	5760	merge	6153
1326	5764	Where branches are used to maintain separate lines of development, at some stage you will want to merge the changes made on one branch back into the trunk, or vice versa.	6157
1327	5768	It is important to understand how branching and merging works in Subversion before you start using it, as it can become quite complex. It is highly recommended that you read the chapter Branching and Merging in the Subversion book, which gives a full description and many examples of how it is used.	6161
1328	5772	The next point to note is that merging always takes place within a working copy. If you want to merge changes into a branch, you have to have a working copy for that branch checked out, and invoke the merge wizard from that working copy using TortoiseSVNMerge....	6165
1329	5776	In general it is a good idea to perform a merge into an unmodified working copy. If you have made other changes in your WC, commit those first. If the merge does not go as you expect, you may want to revert the changes, and the Revert command will discard all changes including any you made before the merge.	6169
1330	5780	There are three common use cases for merging which are handled in slightly different ways, as described below. The first page of the merge wizard asks you to select the method you need.	6173
1331	5784	Merge a range of revisions	6177
1332	5788	This method covers the case when you have made one or more revisions to a branch (or to the trunk) and you want to port those changes across to a different branch.	6181
1333	5792	What you are asking Subversion to do is this: Calculate the changes necessary to get [FROM] revision 1 of branch A [TO] revision 7 of branch A, and apply those changes to my working copy (of trunk or branch B).	6185
1334	5797	Reintegrate a branch	6190
1335	5801	This method covers the case when you have made a feature branch as discussed in the Subversion book. All trunk changes have been ported to the feature branch, week by week, and now the feature is complete you want to merge it back into the trunk. Because you have kept the feature branch synchronized with the trunk, the latest versions of branch and trunk will be absolutely identical except for your branch changes.	6194
1336	5805	This is a special case of the tree merge described below, and it requires only the URL to merge from (normally) your development branch. It uses the merge-tracking features of Subversion to calculate the correct revision ranges to use, and perform additional checks which ensure that the branch has been fully updated with trunk changes. This ensures that you don't accidentally undo work that others have committed to trunk since you last synchronized changes.	6198
1337	5809	After the merge, all branch development has been completely merged back into the main development line. The branch is now redundant and can be deleted.	6202
1338	5813	Once you have performed a reintegrate merge you should not continue to use it for development. The reason for this is that if you try to resynchronize your existing branch from trunk later on, merge tracking will see your reintegration as a trunk change that has not yet been merged into the branch, and will try to merge the branch-to-trunk merge back into the branch! The solution to this is simply to create a new branch from trunk to continue the next phase of your development.	6206
1339	5817	Merge two different trees	6210
1340	5821	This is a more general case of the reintegrate method. What you are asking Subversion to do is: Calculate the changes necessary to get [FROM] the head revision of the trunk [TO] the head revision of the branch, and apply those changes to my working copy (of the trunk). The net result is that trunk now looks exactly like the branch.	6214
1341	5825	If your server/repository does not support merge-tracking then this is the only way to merge a branch back to trunk. Another use case occurs when you are using vendor branches and you need to merge the changes following a new vendor drop into your trunk code. For more information read the chapter on vendor branches in the Subversion Book.	6218
1342	5829	Merging a Range of Revisions	6222
1343	5833	revision range	6226
1344	5837	The Merge Wizard - Select Revision Range	6230
1345	5841	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.	6234
1346	5845	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.	6238
1347	5849	There is an important difference in the way a revision range is specified with TortoiseSVN compared to the command line client. The easiest way to visualise it is to think of a fence with posts and fence panels.	6242
1348	5853	With the command line client you specify the changes to merge using two fence post revisions which specify the before and after points.	6246
1349	5857	With TortoiseSVN you specify the changeset to merge using fence panels. The reason for this becomes clear when you use the log dialog to specify revisions to merge, where each revision appears as a changeset.	6250
1350	5861	If you are merging revisions in chunks, the method shown in the subversion book will have you merge 100-200 this time and 200-300 next time. With TortoiseSVN you would merge 100-200 this time and 201-300 next time.	6254
1351	5865	This difference has generated a lot of heat on the mailing lists. We acknowledge that there is a difference from the command line client, but we believe that for the majority of GUI users it is easier to understand the method we have implemented.	6258
1352	5869	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.	6262
1353	5873	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.	6266
1354	5877	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.	6270
1355	5881	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 to find out more.	6274
1356	5885	If other people may be committing changes then be careful about using the HEAD revision. It may not refer to the revision you think it does if someone else made a commit after your last update.	6278
1357	5889	Click Next and go to	6282
1358	5893	reintegrate	6286
1359	5897	The Merge Wizard - Reintegrate Merge	6290
1360	5901	To merge a feature branch back into the trunk you must start the merge wizard from within a working copy of the trunk.	6294
1361	5905	In the From URL: field enter the full folder URL of the branch that you want to merge back. You may also click ... to browse the repository.	6298
1362	5909	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.	6302
1363	5913	Merging Two Different Trees	6306
1364	5917	two trees	6310
1365	5921	The Merge Wizard - Tree Merge	6314
1366	5925	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.	6318
1367	5929	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.	6322
1368	5933	In the To: field enter the full folder URL of the feature branch.	6326
1369	5937	In both the From Revision field and the To Revision field, enter the last revision number at which the two trees were synchronized. If you are sure no-one else is making commits you can use the HEAD revision in both cases. If there is a chance that someone else may have made a commit since that synchronization, use the specific revision number to avoid losing more recent commits.	6330
1370	5941	You can also use Show Log to select the revision.	6334
1371	5945	Merge Options	6338
1372	5949	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.	6342
1373	5953	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 . The default depth is Working copy, which uses the existing depth setting, and is almost always what you want.	6346
1374	5957	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	6350
1375	5961	You can specify the way that line ending and whitespace changes are handled. These options are described in . The default behaviour is to treat all whitespace and line-end differences as real changes to be merged.	6354
1376	5965	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.	6358
1377	5969	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.	6362
1378	5973	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.	6366
1379	5977	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.	6370
1380	5981	Reviewing the Merge Results	6374
1381	5985	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.	6378
1382	5989	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.	6382
1383	5993	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.	6386
1384	5997	Branch management is important. If you want to keep this branch up to date with the trunk, you should be sure to merge often so that the branch and trunk do not drift too far apart. Of course, you should still avoid repeated merging of changes, as explained above.	6390
1385	6001	If you have just merged a feature branch back into the trunk, the trunk now contains all the new feature code, and the branch is obsolete. You can now delete it from the repository if required.	6394
1386	6005	Subversion can't merge a file with a folder and vice versa - only folders to folders and files to files. If you click on a file and open up the merge dialog, then you have to give a path to a file in that dialog. If you select a folder and bring up the dialog, then you must specify a folder URL for the merge.	6398
1387	6009	Merge Tracking	6402
1388	6013	merge tracking	6406
1389	6017	You can avoid the danger of merging the same revision twice (repeated merge problem). Once a revision is marked as having been merged, future merges which include that revision in the range will skip over it.	6410
1390	6021	When you merge a branch back into trunk, the log dialog can show you the branch commits as part of the trunk log, giving better traceability of changes.	6414
1391	6025	When you show the log dialog from within the merge dialog, revisions already merged are shown in grey.	6418
1392	6029	When showing blame information for a file, you can choose to show the original author of merged revisions, rather than the person who did the merge.	6422
1393	6033	You can mark revisions as do not merge by including them in the list of merged revisions without actually doing the merge.	6426
1394	6037	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.	6430
1395	6041	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.	6434
1396	6045	Find out more about merge tracking from Subversion's Merge tracking documentation.	6438
1397	6049	Handling Conflicts during Merge	6442
1398	6053	merge conflicts	6446
1399	6057	The Merge Conflict Callback Dialog	6450
1400	6061	Merging does not always go smoothly. Sometimes there is a conflict, and if you are merging multiple ranges, you generally want to resolve the conflict before merging of the next range starts. TortoiseSVN helps you through this process by showing the merge conflict callback dialog.	6454
1401	6065	Choosing Prefer local will select your local changes in every conflict. Likewise, Prefer repository will select the repository changes in every conflict. This sounds easy, but the conflicts often cover more lines than you think they will and you may get unexpected results.
1402	6069	Normally you will want to look at the conflicts and resolve them yourself. In that case, choose the Edit Conflict which will start up your merge tool. When you are satisfied with the result, click Resolved.
1403	6073	The last option is to postpone resolution and continue with merging. You can choose to do that for the current conflicted file, or for all files in the rest of the merge. However, if there are further changes in that file, it will not be possible to complete the merge.	6466
1404	6077	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 Callback dialog gives you three different ways of handling the lines which are in conflict.
1405	6081	If you do not want to use this interactive callback, there is a checkbox in the merge progress dialog Merge non-interactive. If this is set for a merge and the merge would result in a conflict, the file is marked as in conflict and the merge goes on. You will have to resolve the conflicts after the whole merge is finished. If it is not set, then before a file is marked as conflicted you get the chance to resolve the conflict during the merge. This has the advantage that if a file gets multiple merges (multiple revisions apply a change to that file), subsequent merges might succeed depending on which lines are affected. But of course you can't walk away to get a coffee while the merge is running ;)	6474
1406	6085	Merge a Completed Branch	6478
1407	6089	merge reintegrate	6482
1408	6093	The Merge reintegrate Dialog	6486
1409	6097	If you want to merge all changes from a feature branch back to trunk, then you can use the TortoiseSVNMerge reintegrate... from the extended context menu (hold down the Shift key while you right click on the file). This dialog is very easy. All you have to do is set the options for the merge, as described in . The rest is done by TortoiseSVN automatically using merge tracking.	6490
1410	6101	Feature Branch Maintenance	6494
1411	6105	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.	6498
1412	6109	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.	6502
1413	6113	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.	6506
1414	6117	Locking	6510
1415	6121	locking	6514
1416	6125	readonly	6518
1417	6129	You are using unmergeable files, for example, graphics files. If two people change the same file, merging is not possible, so one of you will lose their changes.	6522
1418	6133	Your company has always used a locking revision control system in the past and there has been a management decision that locking is best.	6526
1419	6137	Subversion generally works best without locking, using the Copy-Modify-Merge methods described earlier in . However there are a few instances when you may need to implement some form of locking policy.	6530
1420	6141	Firstly you need to ensure that your Subversion server is upgraded to at least version 1.2. Earlier versions do not support locking at all. If you are using file:// access, then of course only your client needs to be updated.	6534
1421	6145	How Locking Works in Subversion	6538
1422	6149	By default, nothing is locked and anyone who has commit access can commit changes to any file at any time. Others will update their working copies periodically and changes in the repository will be merged with local changes.	6542
1423	6153	If you Get a Lock on a file, then only you can commit that file. Commits by all other users will be blocked until you release the lock. A locked file cannot be modified in any way in the repository, so it cannot be deleted or renamed either, except by the lock owner.	6546
1424	6157	However, other users will not necessarily know that you have taken out a lock. Unless they check the lock status regularly, the first they will know about it is when their commit fails, which in most cases is not very useful. To make it easier to manage locks, there is a new Subversion property svn:needs-lock. When this property is set (to any value) on a file, whenever the file is checked out or updated, the local copy is made read-only unless that working copy holds a lock for the file. This acts as a warning that you should not edit that file unless you have first acquired a lock. Files which are versioned and read-only are marked with a special overlay in TortoiseSVN to indicate that you need to acquire a lock before editing.	6550
1425	6161	Locks are recorded by working copy location as well as by owner. If you have several working copies (at home, at work) then you can only hold a lock in one of those working copies.	6554
1426	6165	If one of your co-workers acquires a lock and then goes on holiday without releasing it, what do you do? Subversion provides a means to force locks. Releasing a lock held by someone else is referred to as Breaking the lock, and forcibly acquiring a lock which someone else already holds is referred to as Stealing the lock. Naturally these are not things you should do lightly if you want to remain friends with your co-workers.	6558
1427	6169	Locks are recorded in the repository, and a lock token is created in your local working copy. If there is a discrepancy, for example if someone else has broken the lock, the local lock token becomes invalid. The repository is always the definitive reference.	6562
1428	6173	Getting a Lock	6566
1429	6177	The Locking Dialog	6570
1430	6181	Select the file(s) in your working copy for which you want to acquire a lock, then select the command TortoiseSVNGet Lock.... A dialog appears, allowing you to enter a comment, so others can see why you have locked the file. The comment is optional and currently only used with Svnserve based repositories. If (and only if) you need to steal the lock from someone else, check the Steal lock box, then click on OK.	6574
1431	6185	If you select a folder and then use TortoiseSVNGet 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 ...	6578
1432	6189	Releasing a Lock	6582
1433	6193	To make sure you don't forget to release a lock you don't need any more, locked files are shown in the commit dialog and selected by default. If you continue with the commit, locks you hold on the selected files are removed, even if the files haven't been modified. If you don't want to release a lock on certain files, you can uncheck them (if they're not modified). If you want to keep a lock on a file you've modified, you have to enable the Keep locks checkbox before you commit your changes.	6586
1434	6197	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 TortoiseSVNRelease Lock There is nothing further to enter so TortoiseSVN will contact the repository and release the locks. You can also use this command on a folder to release all locks recursively.	6590
1435	6201	Checking Lock Status	6594
1436	6205	The Check for Modifications Dialog	6598
1437	6209	To see what locks you and others hold, you can use TortoiseSVNCheck for Modifications.... Locally held lock tokens show up immediately. To check for locks held by others (and to see if any of your locks are broken or stolen) you need to click on Check Repository.	6602
1438	6213	From the context menu here, you can also get and release locks, as well as breaking and stealing locks held by others.	6606
1439	6217	Avoid Breaking and Stealing Locks	6610
1440	6221	If you break or steal someone else's lock without telling them, you could potentially cause loss of work. If you are working with unmergeable file types and you steal someone else's lock, once you release the lock they are free to check in their changes and overwrite yours. Subversion doesn't lose data, but you have lost the team-working protection that locking gave you.	6614
1441	6225	Making Non-locked Files Read-Only	6618
1442	6229	As mentioned above, the most effective way to use locking is to set the svn:needs-lock property on files. Refer to for instructions on how to set properties. Files with this property set will always be checked out and updated with the read-only flag set unless your working copy holds a lock. As a reminder, TortoiseSVN uses a special overlay to indicate this.	6622
1443	6233	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 for further information.	6626
1444	6237	The Locking Hook Scripts	6630
1445	6241	When you create a new repository with Subversion 1.2 or higher, four hook templates are created in the repository hooks directory. These are called before and after getting a lock, and before and after releasing a lock.	6634
1446	6245	It is a good idea to install a post-lock and post-unlock hook script on the server which sends out an email indicating the file which has been locked. With such a script in place, all your users can be notified if someone locks/unlocks a file. You can find an example hook script hooks/post-lock.tmpl in your repository folder.	6638
1447	6249	You might also use hooks to disallow breaking or stealing of locks, or perhaps limit it to a named administrator. Or maybe you want to email the owner when one of their locks is broken or stolen.	6642
1448	6253	Read to find out more.	6646
1449	6257	Creating and Applying Patches	6650
1450	6261	patch	6654
1451	6265	unified diff	6658
1452	6269	For open source projects (like this one) everyone has read access to the repository, and anyone can make a contribution to the project. So how are those contributions controlled? If just anyone could commit changes, the project would be permanently unstable and probably permanently broken. In this situation the change is managed by submitting a patch file to the development team, who do have write access. They can review the patch first, and then either submit it to the repository or reject it back to the author.	6662
1453	6273	Patch files are simply Unified-Diff files showing the differences between your working copy and the base revision.	6666
1454	6277	Creating a Patch File	6670
1455	6281	First you need to make and test your changes. Then instead of using TortoiseSVNCommit... on the parent folder, you select TortoiseSVNCreate Patch...	6674
1456	6285	The Create Patch dialog	6678
1457	6289	you can now select the files you want included in the patch, just as you would with a full commit. This will produce a single file containing a summary of all the changes you have made to the selected files since the last update from the repository.	6682
1458	6293	You can produce separate patches containing changes to different sets of files. Of course, if you create a patch file, make some more changes to the same files and then create another patch, the second patch file will include both sets of changes.	6686
1459	6297	Just save the file using a filename of your choice. Patch files can have any extension you like, but by convention they should use the .patch or .diff extension. You are now ready to submit your patch file.	6690
1460	6301	You can also save the patch to the clipboard instead of to a file. You might want to do this so that you can paste it into an email for review by others. Or if you have two working copies on one machine and you want to transfer changes from one to the other, a patch on the clipboard is a convenient way of doing this.	6694
1461	6305	Applying a Patch File	6698
1462	6309	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.	6702
1463	6313	In order to apply a patch file to your working copy, you need to have at least read access to the repository. The reason for this is that the merge program must reference the changes back to the revision against which they were made by the remote developer.	6706
1464	6317	From the context menu for that folder, click on TortoiseSVNApply 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 TortoiseSVNCreate Patch.... Copying a patch to the clipboard from another app will not make the button appear.	6710
1465	6321	Alternatively, if the patch file has a .patch or .diff extension, you can right click on it directly and select TortoiseSVNApply Patch.... In this case you will be prompted to enter a working copy location.	6714
1466	6325	These two methods just offer different ways of doing the same thing. With the first method you select the WC and browse to the patch file. With the second you select the patch file and browse to the WC.	6718
1467	6329	Once you have selected the patch file and working copy location, TortoiseMerge runs to merge the changes from the patch file with your working copy. A small window lists the files which have been changed. Double click on each one in turn, review the changes and save the merged files.	6722
1468	6333	The remote developer's patch has now been applied to your working copy, so you need to commit to allow everyone else to access the changes from the repository.	6726
1469	6337	Who Changed Which Line?	6730
1470	6341	blame	6734
1471	6345	annotate	6738
1472	6349	praise	6742
1473	6353	Sometimes you need to know not only what lines have changed, but also who exactly changed specific lines in a file. That's when the TortoiseSVNBlame... command, sometimes also referred to as annotate command comes in handy.	6746
1474	6357	This command lists, for every line in a file, the author and the revision the line was changed.	6750
1475	6361	Blame for Files	6754
1476	6365	The Annotate / Blame Dialog	6758
1477	6369	If you're not interested in changes from earlier revisions you can set the revision from which the blame should start. Set this to 1, if you want the blame for every revision.	6762
1478	6373	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	6766
1479	6377	You can specify the way that line ending and whitespace changes are handled. These options are described in . 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.	6770
1480	6381	Once you press OK TortoiseSVN starts retrieving the data to create the blame file. Please note: This can take several minutes to finish, depending on how much the file has changed and of course your network connection to the repository. Once the blame process has finished the result is written into a temporary file and you can view the results.	6774
1481	6389	TortoiseBlame, which is included with TortoiseSVN, makes the blame file easier to read. When you hover the mouse over a line in the blame info column, all lines with the same revision are shown with a darker background. Lines from other revisions which were changed by the same author are shown with a light background. The colouring may not work as clearly if you have your display set to 256 colour mode.	6782
1482	6393	If you left click on a line, all lines with the same revision are highlighted, and lines from other revisions by the same author are highlighted in a lighter colour. This highlighting is sticky, allowing you to move the mouse without losing the highlights. Click on that revision again to turn off highlighting.	6786
1483	6397	The revision comments (log message) are shown in a hint box whenever the mouse hovers over the blame info column. If you want to copy the log message for that revision, use the context menu which appears when you right click on the blame info column.	6790
1484	6401	You can search within the Blame report using EditFind.... This allows you to search for revision numbers, authors and the content of the file itself. Log messages are not included in the search - you should use the Log Dialog to search those.	6794
1485	6405	You can also jump to a specific line number using EditGo To Line....	6798
1486	6409	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 menuBlame 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 menuShow changes starts your diff viewer, showing you what changed in the referenced revision. Context menuShow log displays the revision log dialog starting with the referenced revision.	6802
1487	6413	If you need a better visual indicator of where the oldest and newest changes are, select ViewColor 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.	6806
1488	6417	If you are using Merge Tracking, where lines have 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. If you do not want merged lines shown in this way, uncheck the Include merge info checkbox.	6810
1489	6421	If you want to see the paths involved in the merge, select ViewMerge paths.	6814
1490	6425	The settings for TortoiseBlame can be accessed using TortoiseSVNSettings... on the TortoiseBlame tab. Refer to .	6818
1491	6429	Blame Differences	6822
1492	6433	One of the limitations of the Blame report is that it only shows the file as it was in a particular revision, and shows the last person to change each line. Sometimes you want to know what change was made, as well as who made it. What you need here is a combination of the diff and blame reports.	6826
1493	6437	Blame Revisions	6830
1494	6441	In the top pane, select 2 revisions, then select Context menuBlame revisions. This will fetch the blame data for the 2 revisions, then use the diff viewer to compare the two blame files.	6834
1495	6445	Blame Changes	6838
1496	6449	Select one revision in the top pane, then pick one file in the bottom pane and select Context menuBlame changes. This will fetch the blame data for the selected revision and the previous revision, then use the diff viewer to compare the two blame files.	6842
1497	6453	Compare and Blame with Working BASE	6846
1498	6457	Show the log for a single file, and in the top pane, select a single revision, then select Context menuCompare and Blame with Working BASE. This will fetch the blame data for the selected revision, and for the file in the working BASE, then use the diff viewer to compare the two blame files.	6850
1499	6461	The revision log dialog includes several options which allow you to do this.	6854
1500	6466	The Repository Browser	6859
1501	6470	repo-browser	6863
1502	6474	server-side actions	6867
1503	6478	server viewer	6871
1504	6482	Sometimes you need to work directly on the repository, without having a working copy. That's what the Repository Browser is for. Just as the explorer and the icon overlays allow you to view your working copy, so the Repository Browser allows you to view the structure and status of the repository. With the Repository Browser you can execute commands like copy, move, rename, ... directly on the repository.	6875
1505	6486	The repository browser looks very similar to the Windows explorer, except that it is showing the content of the repository at a particular revision rather than files on your computer. In the left pane you can see a directory tree, and in the right pane are the contents of the selected directory. At the top of the Repository Browser Window you can enter the URL of the repository and the revision you want to browse.	6879
1506	6490	Just like Windows explorer, you can click on the column headings in the right pane if you want to set the sort order. And as in explorer there are context menus available in both panes.	6883
1507	6494	Save an unversioned copy of the file to your hard drive.	6887
1508	6498	Show the revision log for that file, or show a graph of all revisions so you can see where the file came from.	6891
1509	6502	Blame the file, to see who changed which line and when.	6895
1510	6506	Delete or rename the file.	6899
1511	6510	Make a copy of the file, either to a different part of the repository, or to a working copy rooted in the same repository.	6903
1512	6514	View/Edit the file's properties.	6907
1513	6518	The context menu for a file allows you to:	6911
1514	6522	Show the revision log for that folder, or show a graph of all revisions so you can see where the folder came from.	6915
1515	6526	Export the folder to a local unversioned copy on your hard drive.	6919
1516	6530	Checkout the folder to produce a local working copy on your hard drive.	6923
1517	6534	Create a new folder in the repository.	6927
1518	6538	Add files or folders directly to the repository.	6931
1519	6542	Delete or rename the folder.	6935
1520	6546	Make a copy of the folder, either to a different part of the repository, or to a working copy rooted in the same repository. This can also be used to create a branch/tag without the need to have a working copy checked out.	6939
1521	6550	View/Edit the folder's properties.	6943
1522	6554	Mark the folder for comparison. A marked folder is shown in bold.	6947
1523	6558	Compare the folder with a previously marked folder, either as a unified diff, or as a list of changed files which can then be visually diffed using the default diff tool. This can be particularly useful for comparing two tags, or trunk and branch to see what changed.	6951
1524	6562	The context menu for a folder allows you to:	6955
1525	6566	If you select two folders in the right pane, you can view the differences either as a unified-diff, or as a list of files which can be visually diffed using the default diff tool.	6959
1526	6570	If you select multiple folders in the right pane, you can checkout all of them at once into a common parent folder.	6963
1527	6574	If you select 2 tags which are copied from the same root (typically /trunk/), you can use Context MenuShow Log... to view the list of revisions between the two tag points.	6967
1528	6578	You can use F5 to refresh the view as usual. This will refresh everything which is currently displayed. If you want to pre-fetch or refresh the information for nodes which have not been opened yet, use Ctrl-F5. After that, expanding any node will happen instantly without a network delay while the information is fetched.	6971
1529	6582	You can also use the repository browser for drag-and-drop operations. If you drag a folder from explorer into the repo-browser, it will be imported into the repository. Note that if you drag multiple items, they will be imported in separate commits.	6975
1530	6586	If you want to move an item within the repository, just left drag it to the new location. If you want to create a copy rather than moving the item, Ctrl-left drag instead. When copying, the cursor has a plus symbol on it, just as it does in Explorer.	6979
1531	6590	If you want to copy/move a file or folder to another location and also give it a new name at the same time, you can right drag or Ctrl-right drag the item instead of using left drag. In that case, a rename dialog is shown where you can enter a new name for the file or folder.	6983
1532	6594	Whenever you make changes in the repository using one of these methods, you will be presented with a log message entry dialog. If you dragged something by mistake, this is also your chance to cancel the action.	6987
1533	6598	Sometimes when you try to open a path you will get an error message in place of the item details. This might happen if you specified an invalid URL, or if you don't have access permission, or if there is some other server problem. If you need to copy this message to include it in an email, just right click on it and use Context MenuCopy error message to clipboard, or simply use Ctrl+C.	6991
1534	6602	Revision Graphs	6995
1535	6606	graph	6999
1536	6610	revision graph	7003
1537	6614	A Revision Graph	7007
1538	6618	Sometimes you need to know where branches and tags were taken from the trunk, and the ideal way to view this sort of information is as a graph or tree structure. That's when you need to use TortoiseSVNRevision Graph...	7011
1539	6622	This command analyses the revision history and attempts to create a tree showing the points at which copies were taken, and when branches/tags were deleted.	7015
1540	6626	In order to generate the graph, TortoiseSVN must fetch all log messages from the repository root. Needless to say this can take several minutes even with a repository of a few thousand revisions, depending on server speed, network bandwidth, etc. If you try this with something like the Apache project which currently has over 500,000 revisions you could be waiting for some time.	7019
1541	6630	The good news is that if you are using log caching, you only have to suffer this delay once. After that, log data is held locally. Log caching is enabled in TortoiseSVN's settings.	7023
1542	6634	Revision Graph Nodes	7027
1543	6638	Added or copied items	7031
1544	6642	Items which have been added, or created by copying another file/folder are shown using a rounded rectangle. The default colour is green. Tags and trunks are treated as a special case and use a different shade, depending on the TortoiseSVNSettings	7035
1545	6646	Deleted items	7039
1546	6650	Deleted items eg. a branch which is no longer required, are shown using an octagon (rectangle with corners cut off). The default colour is red.	7043
1547	6654	Renamed items	7047
1548	6658	Renamed items are also shown using an octagon, but the default colour is blue.	7051
1549	6662	Branch tip revision	7055
1550	6666	The graph is normally restricted to showing branch points, but it is often useful to be able to see the respective HEAD revision for each branch too. If you select Show HEAD revisions, each HEAD revision nodes will be shown as an ellipse. Note that HEAD here refers to the last revision committed on that path, not to the HEAD revision of the repository.	7059
1551	6670	Working copy revision	7063
1552	6674	If you invoked the revision graph from a working copy, you can opt to show the BASE revision on the graph using Show WC revision, which marks the BASE node with a bold outline.	7067
1553	6678	Modified working copy	7071
1554	6682	If you invoked the revision graph from a working copy, you can opt to show an additional node representing your modified working copy using Show WC modifications. This is an elliptical node with a bold outline in red by default.	7075
1555	6686	Normal item	7079
1556	6690	All other items are shown using a plain rectangle.	7083
1557	6694	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 TortoiseSVNSettings	7087
1558	6698	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.	7091
1559	6702	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.	7095
1560	6706	Changing the View	7099
1561	6710	Group branches	7103
1562	6714	The default behavior (grouping off) has all rows sorted strictly by revision. As a result, long-living branches with sparse commits occupy a whole column for only a few changes and the graph becomes very broad.	7107
1563	6718	This mode groups changes by branch, so that there is no global revision ordering: Consecutive revisions on a branch will be shown in (often) consecutive lines. Sub-branches, however, are arranged in such a way that later branches will be shown in the same column above older branches to keep the graph slim. As a result, a given row may contain changes from different revisions.	7111
1564	6722	Oldest on top	7115
1565	6726	Normally the graph shows the oldest revision at the bottom, and the tree grows upwards. Use this option to grow down from the top instead.	7119
1566	6730	Align trees on top	7123
1567	6734	When a graph is broken into several smaller trees, the trees may appear either in natural revision order, or aligned at the bottom of the window, depending on whether you are using the Group Branches option. Use this option to grow all trees down from the top instead.	7127
1568	6738	Reduce cross lines	7131
1569	6742	If the layout of the graph has produced a lot of crossing lines, use this option to clean it up. This may make the layout columns appear in less logical places, for example in a diagonal line rather than a column, and the graph may require a larger area to draw.	7135
1570	6746	Differential path names	7139
1571	6750	Long path names can take a lot of space and make the node boxes very large. Use this option to show only the changed part of a path, replacing the common part with dots. E.g. if you create a branch /branches/1.2.x/doc/html from /trunk/doc/html the branch could be shown in compact form as /branches/1.2.x/.. because the last two levels, doc and html, did not change.	7143
1572	6754	Show all revisions	7147
1573	6758	This does just what you expect and shows every revision where something (in the tree that you are graphing) has changed. For long histories this can produce a truly huge graph.	7151
1574	6762	Show HEAD revisions	7155
1575	6766	This ensures that the latest revision on every branch is always shown on the graph.	7159
1576	6770	Exact copy sources	7163
1577	6774	When a branch/tag is made, the default behaviour is to show the branch as taken from the last node where a change was made. Strictly speaking this is inaccurate since the branches are often made from the current HEAD rather than a specific revision. So it is possible to show the more correct (but less useful) revision that was used to create the copy. Note that this revision may be younger than the HEAD revision of the source branch.	7167
1578	6778	Fold tags	7171
1579	6782	When a project has many tags, showing every tag as a separate node on the graph takes a lot of space and obscures the more interesting development branch structure. At the same time you may need to be able to access the tag content easily so that you can compare revisions. This option hides the nodes for tags and shows them instead in the tooltip for the node that they were copied from. A tag icon on the right side of the source node indicates that tags were made.	7175
1580	6786	Hide deleted paths	7179
1581	6790	Hides paths which are no longer present at the HEAD revision of the repository, e.g. deleted branches.	7183
1582	6794	Hide unchanged branches	7187
1583	6798	Hides branches where no changes were committed to the respective file or sub-folder. This does not necessarily indicate that the branch was not used, just that no changes were made to this part of it.	7191
1584	6802	Show WC revision	7195
1585	6806	Marks the revision on the graph which corresponds to the update revision of the item you fetched the graph for. If you have just updated, this will be HEAD, but if others have committed changes since your last update your WC may be a few revisions lower down. The node is marked by giving it a bold outline.	7199
1586	6810	Show WC modifications	7203
1587	6814	If your WC contains local changes, this option draws it as a separate elliptical node, linked back to the node that your WC was last updated to. The default outline colour is red. You may need to refresh the graph using F5 to capture recent changes.	7207
1588	6818	Filter	7211
1589	6822	Sometimes the revision graph contains more revisions than you want to see. This option opens a dialog which allows you to restrict the range of revisions displayed, and to hide particular paths by name.	7215
1590	6826	Tree stripes	7219
1591	6830	Where the graph contains several trees, it is sometimes useful to use alternating colours on the background to help distinguish between trees.	7223
1592	6834	Show overview	7227
1593	6838	Shows a small picture of the entire graph, with the current view window as a rectangle which you can drag. This allows you to navigate the graph more easily. Note that for very large graphs the overview may become useless due to the extreme zoom factor and will therefore not be shown in such cases.	7231
1594	6842	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.	7235
1595	6846	Using the Graph	7239
1596	6850	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.	7243
1597	6854	The revision date, author and comments are shown in a hint box whenever the mouse hovers over a revision box.	7247
1598	6858	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.	7251
1599	6862	You can view the differences as a Unified-Diff file, which shows all differences in a single file with minimal context. If you opt to Context MenuCompare Revisions you will be presented with a list of changed files. Double click on a file name to fetch both revisions of the file and compare them using the visual difference tool.	7255
1600	6866	If you right click on a revision you can use Context MenuShow Log to view the history.	7259
1601	6870	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.	7263
1602	6874	Learn to Read the Revision Graph	7267
1603	6878	First-time users may be surprised by the fact that the revision graph shows something that does not match the user's mental model. If a revision changes multiple copies or branches of a file or folder, for instance, then there will be multiple nodes for that single revision. It is a good practice to start with the leftmost options in the toolbar and customize the graph step-by-step until it comes close to your mental model.	7271
1604	6882	All filter options try lose as little information as possible. That may cause some nodes to change their color, for instance. Whenever the result is unexpected, undo the last filter operation and try to understand what is special about that particular revision or branch. In most cases, the initially expected outcome of the filter operation would either be inaccurate or misleading.	7275
1605	6886	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.	7279
1606	6890	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.	7283
1607	6894	Pruning Trees	7287
1608	6898	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.	7291
1609	6902	Click on the minus button to collapse the attached sub-tree.	7295
1610	6906	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.	7299
1611	6910	Click on the cross button to split the attached sub-tree and show it as a separate tree on the graph.	7303
1612	6914	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.	7307
1613	6918	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.	7311
1614	6922	Exporting a Subversion Working Copy	7315
1615	6926	export	7319
1616	6930	unversioned 'working copy'	7323
1617	6934	Sometimes you may want a copy of your working tree without any of those .svn directories, e.g. to create a zipped tarball of your source, or to export to a web server. Instead of making a copy and then deleting all those .svn directories manually, TortoiseSVN offers the command TortoiseSVNExport.... Exporting from a URL and exporting from a working copy are treated slightly differently.	7327
1618	6938	The Export-from-URL Dialog	7331
1619	6942	If you execute this command on an unversioned folder, TortoiseSVN will assume that the selected folder is the target, and open a dialog for you to enter the URL and revision to export from. This dialog has options to export only the top level folder, to omit external references, and to override the line end style for files which have the svn:eol-style property set.	7335
1620	6946	Of course you can export directly from the repository too. Use the Repository Browser to navigate to the relevant subtree in your repository, then use Context MenuExport. You will get the Export from URL dialog described above.	7339
1621	6950	If you execute this command on your working copy you'll be asked for a place to save the clean working copy without the .svn folders. By default, only the versioned files are exported, but you can use the Export unversioned files too checkbox to include any other unversioned files which exist in your WC and not in the repository. External references using svn:externals can be omitted if required.	7343
1622	6954	Another way to export from a working copy is to right drag the working copy folder to another location and choose Context MenuSVN Export here or Context MenuSVN Export all here. The second option includes the unversioned files as well.	7347
1623	6958	When exporting from a working copy, if the target folder already contains a folder of the same name as the one you are exporting, you will be given the option to overwrite the existing content, or to create a new folder with an automatically generated name, eg. Target (1).	7351
1624	6962	Exporting single files	7355
1625	6966	The export dialog does not allow exporting single files, even though Subversion can.	7359
1626	6970	To export single files with TortoiseSVN, you have to use the repository browser (). Simply drag the file(s) you want to export from the repository browser to where you want them in the explorer, or use the context menu in the repository browser to export the files.	7363
1627	6974	Exporting a Change Tree	7367
1628	6978	If you want to export a copy of your project tree structure but containing only the files which have changed in a particular revision, or between any two revisions, use the compare revisions feature described in .	7371
1629	6982	Removing a working copy from version control	7375
1630	6987	unversion	7380
1631	6991	Sometimes you have a working copy which you want to convert back to a normal folder without the .svn directories. What you really need is an export-in-place command, that just removes the control directories rather than generating a new clean directory tree.	7384
1632	6995	The answer is surprisingly simple - export the folder to itself! TortoiseSVN detects this special case and asks if you want to make the working copy unversioned. If you answer yes the control directories will be removed and you will have a plain, unversioned directory tree.	7388
1633	6999	Relocating a working copy	7392
1634	7003	relocate	7396
1635	7007	URL changed	7400
1636	7011	repository URL changed	7404
1637	7015	server moved	7408
1638	7019	moved server	7412
1639	7023	The Relocate Dialog	7416
1640	7027	If your repository has for some reason changed it's location (IP/URL). Maybe you're even stuck and can't commit and you don't want to checkout your working copy again from the new location and to move all your changed data back into the new working copy, TortoiseSVNRelocate is the command you are looking for. It basically does very little: it scans all entries files in the .svn folder and changes the URL of the entries to the new value.	7420
1641	7031	You may be surprised to find that TortoiseSVN contacts the repository as part of this operation. All it is doing is performing some simple checks to make sure that the new URL really does refer to the same repository as the existing working copy.	7424
1642	7035	The IP address of the server has changed.	7428
1643	7039	The protocol has changed (e.g. http:// to https://).	7432
1644	7043	The repository root path in the server setup has changed.	7436
1645	7047	This is a very infrequently used operation. The relocate command is only used if the URL of the repository root has changed. Possible reasons are: Put another way, you need to relocate when your working copy is referring to the same location in the same repository, but the repository itself has moved.	7440
1646	7051	You want to move to a different Subversion repository. In that case you should perform a clean checkout from the new repository location.	7444
1647	7055	You want to switch to a different branch or directory within the same repository. To do that you should use TortoiseSVNSwitch.... Read for more information.	7448
1648	7059	It does not apply if:	7452
1649	7063	If you use relocate in either of the cases above, it will corrupt your working copy and you will get many unexplainable error messages while updating, committing, etc. Once that has happened, the only fix is a fresh checkout.	7456
1650	7067	Integration with Bug Tracking Systems / Issue Trackers	7460
1651	7071	bug tracking	7464
1652	7075	bug tracker	7468
1653	7080	issue tracker	7473
1654	7084	bugtracker	7477
1655	7088	It is very common in Software Development for changes to be related to a specific bug or issue ID. Users of bug tracking systems (issue trackers) would like to associate the changes they make in Subversion with a specific ID in their issue tracker. Most issue trackers therefore provide a pre-commit hook script which parses the log message to find the bug ID with which the commit is associated. This is somewhat error prone since it relies on the user to write the log message properly so that the pre-commit hook script can parse it correctly.	7481
1656	7092	When the user enters a log message, a well defined line including the issue number associated with the commit can be added automatically. This reduces the risk that the user enters the issue number in a way the bug tracking tools can't parse correctly.	7485
1657	7096	Or TortoiseSVN can highlight the part of the entered log message which is recognized by the issue tracker. That way the user knows that the log message can be parsed correctly.	7489
1658	7100	When the user browses the log messages, TortoiseSVN creates a link out of each bug ID in the log message which fires up the browser to the issue mentioned.	7493
1659	7104	TortoiseSVN can help the user in two ways:	7497
1660	7108	Adding Issue Numbers to Log Messages	7501
1661	7112	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: ()	7505
1662	7116	Set this property to the URL of your bug tracking tool. It must be properly URI encoded and it has to contain %BUGID%. %BUGID% is replaced with the Issue number you entered. This allows TortoiseSVN to display a link in the log dialog, so when you are looking at the revision log you can jump directly to your bug tracking tool. You do not have to provide this property, but then TortoiseSVN shows only the issue number and not the link to it. e.g the TortoiseSVN project is using http://issues.tortoisesvn.net/?do=details&id=%BUGID%	7509
1663	7120	You can also use relative URLs instead of absolute ones. This is useful when your issue tracker is on the same domain/server as your source repository. In case the domain name ever changes, you don't have to adjust the bugtraq:url property. There are two ways to specify a relative URL:	7513
1664	7124	If it begins with the string ^/ it is assumed to be relative to the repository root. For example, ^/../?do=details&id=%BUGID% will resolve to http://tortoisesvn.net/?do=details&id=%BUGID% if your repository is located on http://tortoisesvn.net/svn/trunk/.	7517
1665	7128	A URL beginning with the string / is assumed to be relative to the server's hostname. For example /?do=details&id=%BUGID% will resolve to http://tortoisesvn.net/?do=details&id=%BUGID% if your repository is located anywhere on http://tortoisesvn.net.	7521
1666	7132	Set this to true, if you want TortoiseSVN to warn you because of an empty issue-number text field. Valid values are true/false. If not defined, false is assumed.	7525
1667	7136	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:	7529
1668	7140	Issue Number in Text Box	7533
1669	7144	This property activates the bug tracking system in Input field mode. If this property is set, then TortoiseSVN will prompt you to enter an issue number when you commit your changes. It's used to add a line at the end of the log message. It must contain %BUGID%, which is replaced with the issue number on commit. This ensures that your commit log contains a reference to the issue number which is always in a consistent format and can be parsed by your bug tracking tool to associate the issue number with a particular commit. As an example you might use Issue : %BUGID%, but this depends on your Tool.	7537
1670	7148	This property defines if the bug-ID is appended (true) to the end of the log message or inserted (false) at the start of the log message. Valid values are true/false. If not defined, true is assumed, so that existing projects don't break.	7541
1671	7152	This text is shown by TortoiseSVN on the commit dialog to label the edit box where you enter the issue number. If it's not set, Bug-ID / Issue-Nr: will be displayed. Keep in mind though that the window will not be resized to fit this label, so keep the size of the label below 20-25 characters.	7545
1672	7156	If set to true only numbers are allowed in the issue-number text field. An exception is the comma, so you can comma separate several numbers. Valid values are true/false. If not defined, true is assumed.	7549
1673	7160	In the simple approach, TortoiseSVN shows the user a separate input field where a bug ID can be entered. Then a separate line is appended/prepended to the log message the user entered.	7553
1674	7164	Issue Numbers Using Regular Expressions	7557
1675	7168	This property activates the bug tracking system in Regex mode. It contains either a single regular expressions, or two regular expressions separated by a newline.	7561
1676	7172	If two expressions are set, then the first expression is used as a pre-filter to find expressions which contain bug IDs. The second expression then extracts the bare bug IDs from the result of the first regex. This allows you to use a list of bug IDs and natural language expressions if you wish. e.g. you might fix several bugs and include a string something like this: This change resolves issues #23, #24 and #25	7565
1677	7176	If you want to catch bug IDs as used in the expression above inside a log message, you could use the following regex strings, which are the ones used by the TortoiseSVN project: [Ii]ssues?:?(\\s*(,|and)?\\s*#\\d+)+ and (\\d+)	7569
1678	7180	The first expression picks out issues #23, #24 and #25 from the surrounding log message. The second regex extracts plain decimal numbers from the output of the first regex, so it will return 23, 24 and 25 to use as bug IDs.	7573
1679	7184	Breaking the first regex down a little, it must start with the word issue, possibly capitalised. This is optionally followed by an s (more than one issue) and optionally a colon. This is followed by one or more groups each having zero or more leading whitespace, an optional comma or and and more optional space. Finally there is a mandatory # and a mandatory decimal number.	7577
1680	7188	If only one expression is set, then the bare bug IDs must be matched in the groups of the regex string. Example: [Ii]ssue(?:s)? #?(\\d+) This method is required by a few issue trackers, e.g. trac, but it is harder to construct the regex. We recommend that you only use this method if your issue tracker documentation tells you to.	7581
1681	7192	If you are unfamiliar with regular expressions, take a look at the introduction at http://en.wikipedia.org/wiki/Regular_expression, and the online documentation and tutorial at http://www.regular-expressions.info/.	7585
1682	7196	In the approach with regular expressions, TortoiseSVN doesn't show a separate input field but marks the part of the log message the user enters which is recognized by the issue tracker. This is done while the user writes the log message. This also means that the bug ID can be anywhere inside a log message! This method is much more flexible, and is the one used by the TortoiseSVN project itself.	7589
1683	7200	If both the bugtraq:message and bugtraq:logregex properties are set, logregex takes precedence.	7593
1684	7204	Even if you don't have an issue tracker with a pre-commit hook parsing your log messages, you still can use this to turn the issues mentioned in your log messages into links!	7597
1685	7208	And even if you don't need the links, the issue numbers show up as a separate column in the log dialog, making it easier to find the changes which relate to a particular issue.	7601
1686	7213	Set the Properties on Folders	7606
1687	7218	These properties must be set on folders for the system to work. When you commit a file or folder the properties are read from that folder. If the properties are not found there, TortoiseSVN will search upwards through the folder tree to find them until it comes to an unversioned folder, or the tree root (eg. C:\\) is found. If you can be sure that each user checks out only from e.g trunk/ and not some sub-folder, then it's enough if you set the properties on trunk/. If you can't be sure, you should set the properties recursively on each sub-folder. A property setting deeper in the project hierarchy overrides settings on higher levels (closer to trunk/).	7611
1688	7222	No Issue Tracker Information from Repository Browser	7615
1689	7226	Because the issue tracker integration depends upon accessing subversion properties, you will only see the results when using a checked out working copy. Fetching properties remotely is a slow operation, so you will not see this feature in action from the repo browser unless you started the repo browser from your working copy. If you started the repo browser by entering the URL of the repository you won't see this feature.	7619
1690	7231	For the same reason, project properties will not be propagated automatically when a child folder is added using the repo browser.	7624
1691	7235	This issue tracker integration is not restricted to TortoiseSVN; it can be used with any Subversion client. For more information, read the full Issue Tracker Integration Specification in the TortoiseSVN source repository. ( explains how to access the repository).	7628
1692	7239	Getting Information from the Issue Tracker	7632
1693	7243	The previous section deals with adding issue information to the log messages. But what if you need to get information from the issue tracker? The commit dialog has a COM interface which allows integration an external program that can talk to your tracker. Typically you might want to query the tracker to get a list of open issues assigned to you, so that you can pick the issues that are being addressed in this commit.	7636
1694	7247	Any such interface is of course highly specific to your issue tracker system, so we cannot provide this part, and describing how to create such a program is beyond the scope of this manual. The interface definition and sample plugins in C# and C++/ATL can be obtained from the contrib folder in the TortoiseSVN repository. ( explains how to access the repository). A summary of the API is also given in Another (working) example plugin in C# is Gurtle which implements the required COM interface to interact with the Google Code issue tracker.	7640
1695	7251	Example issue tracker query dialog	7644
1696	7255	For illustration purposes, let's suppose that your system administrator has provided you with an issue tracker plugin which you have installed, and that you have set up some of your working copies to use the plugin in TortoiseSVN's settings dialog. When you open the commit dialog from a working copy to which the plugin has been assigned, you will see a new button at the top of the dialog. In this example you can select one or more open issues. The plugin can then generate specially formatted text which it adds to your log message.	7648
1697	7259	Integration with Web-based Repository Viewers	7652
1698	7263	web view	7656
1699	7267	repo viewer	7660
1700	7279	There are several web-based repository viewers available for use with Subversion such as ViewVC and WebSVN. TortoiseSVN provides a means to link with these viewers.	7672
1701	7283	You can integrate a repo viewer of your choice in TortoiseSVN. To do this, you have to define some properties which define the linkage. They must be set on Folders: ()	7676
1702	7287	Set this property to the URL of your repo viewer to view all changes in a specific revision. It must be properly URI encoded and it has to contain %REVISION%. %REVISION% is replaced with the revision number in question. This allows TortoiseSVN to display a context menu entry in the log dialog Context MenuView revision in webviewer	7680
1703	7291	Set this property to the URL of your repo viewer to view changes to a specific file in a specific revision. It must be properly URI encoded and it has to contain %REVISION% and %PATH%. %PATH% is replaced with the path relative to the repository root. This allows TortoiseSVN to display a context menu entry in the log dialog Context MenuView revision for path in webviewer For example, if you right-click in the log dialog bottom pane on a file entry /trunk/src/file then the %PATH% in the URL will be replaced with /trunk/src/file.	7684
1704	7295	You can also use relative URLs instead of absolute ones. This is useful in case your web viewer is on the same domain/server as your source repository. In case the domain name ever changes, you don't have to adjust the webviewer:revision and webviewer:pathrevision property. The format is the same as for the bugtraq:url property. See .	7688
1705	7299	Because the repo viewer integration depends upon accessing subversion properties, you will only see the results when using a checked out working copy. Fetching properties remotely is a slow operation, so you will not see this feature in action from the repo browser unless you started the repo browser from your working copy. If you started the repo browser by entering the URL of the repository you won't see this feature.	7692
1706	7303	TortoiseSVN's Settings	7696
1707	7307	settings	7700
1708	7311	To find out what the different settings are for, just leave your mouse pointer a second on the editbox/checkbox... and a helpful tooltip will popup.	7704
1709	7315	General Settings	7708
1710	7319	sounds	7712
1711	7323	The Settings Dialog, General Page	7716
1712	7327	This dialog allows you to specify your preferred language, and the Subversion-specific settings.	7720
1713	7331	Language	7724
1714	7335	Selects your user interface language. What else did you expect?	7728
1715	7339	Check for updates
1716	7343	TortoiseSVN will contact its download site periodically to see if there is a newer version of the program available. If there is it will show a notification link in the commit dialog. Use Check now if you want an answer right away. The new version will not be downloaded; you simply receive an information dialog telling you that the new version is available.
1717	7347	System sounds	7740
1718	7351	Error	7744
1719	7355	Notice	7748
1720	7359	Warning	7752
1721	7363	TortoiseSVN has three custom sounds which are installed by default. You can select different sounds (or turn these sounds off completely) using the Windows Control Panel. Configure is a shortcut to the Control Panel.	7756
1722	7367	Global ignore pattern	7760
1723	7371	exclude pattern	7764
1724	7375	global ignore	7768
1725	7379	Global ignore patterns are used to prevent unversioned files from showing up e.g. in the commit dialog. Files matching the patterns are also ignored by an import. Ignore files or directories by typing in the names or extensions. Patterns are separated by spaces e.g. bin obj *.bak *.~?? *.jar *.[Tt]mp. These patterns should not include any path separators. Note also that there is no way to differentiate between files and directories. Read for more information on the pattern-matching syntax.	7772
1726	7383	Note that the ignore patterns you specify here will also affect other Subversion clients running on your PC, including the command line client.	7776
1727	7387	If you use the Subversion configuration file to set a global-ignores pattern, it will override the settings you make here. The Subversion configuration file is accessed using the Edit as described below.	7780
1728	7391	This ignore pattern will affect all your projects. It is not versioned, so it will not affect other users. By contrast you can also use the versioned svn:ignore property to exclude files or directories from version control. Read for more information.	7784
1729	7395	Set file dates to the last commit time	7788
1730	7399	This option tells TortoiseSVN to set the file dates to the last commit time when doing a checkout or an update. Otherwise TortoiseSVN will use the current date. If you are developing software it is generally best to use the current date because build systems normally look at the date stamps to decide which files need compiling. If you use last commit time and revert to an older file revision, your project may not compile as you expect it to.	7792
1731	7403	Subversion configuration file	7796
1732	7407	Use Edit to edit the Subversion configuration file directly. Some settings cannot be modified directly by TortoiseSVN, and need to be set here instead. For more information about the Subversion config file see the Runtime Configuration Area. The section on Automatic Property Setting is of particular interest, and that is configured here. Note that Subversion can read configuration information from several places, and you need to know which one takes priority. Refer to Configuration and the Windows Registry to find out more.	7800
1733	7411	Use _svn instead of .svn directories	7804
1734	7415	VS.NET when used with web projects can't handle the .svn folders that Subversion uses to store its internal information. This is not a bug in Subversion. The bug is in VS.NET and the frontpage extensions it uses. Read to find out more about this issue.	7808
1735	7419	If you want to change the behaviour of Subversion and TortoiseSVN, you can use this checkbox to set the environment variable which controls this.	7812
1736	7423	You should note that changing this option will not automatically convert existing working copies to use the new admin directory. You will have to do that yourself using a script (See our FAQ) or simply check out a fresh working copy.	7816
1737	7427	Context Menu Settings	7820
1738	7431	The Settings Dialog, Context Menu Page	7824
1739	7435	This page allows you to specify which of the TortoiseSVN context menu entries will show up in the main context menu, and which will appear in the TortoiseSVN submenu. By default most items are unchecked and appear in the submenu.	7828
1740	7439	There is a special case for Get Lock. You can of course promote it to the top level using the list above, but as most files don't need locking this just adds clutter. However, a file with the svn:needs-lock property needs this action every time it is edited, so in that case it is very useful to have at the top level. Checking the box here means that when a file is selected which has the svn:needs-lock property set, Get Lock will always appear at the top level.	7832
1741	7443	If there are some paths on your computer where you just don't want TortoiseSVN's context menu to appear at all, you can list them in the box at the bottom.	7836
1742	7447	TortoiseSVN Dialog Settings 1	7840
1743	7451	The Settings Dialog, Dialogs 1 Page	7844
1744	7455	This dialog allows you to configure some of TortoiseSVN's dialogs the way you like them.	7848
1745	7459	Default number of log messages	7852
1746	7463	Limits the number of log messages that TortoiseSVN fetches when you first select TortoiseSVNShow Log Useful for slow server connections. You can always use Show All or Next 100 to get more messages.	7856
1747	7467	Font for log messages	7860
1748	7471	Selects the font face and size used to display the log message itself in the middle pane of the Revision Log dialog, and when composing log messages in the Commit dialog.	7864
1749	7475	Short date / time format in log messages	7868
1750	7479	If the standard long messages use up too much space on your screen use the short format.	7872
1751	7483	Can double-click in log list to compare with previous revision	7876
1752	7487	If you frequently find yourself comparing revisions in the top pane of the log dialog, you can use this option to allow that action on double-click. It is not enabled by default because fetching the diff is often a long process, and many people prefer to avoid the wait after an accidental double-click, which is why this option is not enabled by default.	7880
1753	7491	Auto-close
1754	7495	TortoiseSVN can automatically close all progress dialogs when the action is finished without error. This setting allows you to select the conditions for closing the dialogs. The default (recommended) setting is Close manually which allows you to review all messages and check what has happened. However, you may decide that you want to ignore some types of message and have the dialog close automatically if there are no critical changes.	7888
1755	7499	Auto-close if no merges, adds or deletes means that the progress dialog will close if there were simple updates, but if changes from the repository were merged with yours, or if any files were added or deleted, the dialog will remain open. It will also stay open if there were any conflicts or errors during the operation.	7892
1756	7503	Auto-close if no conflicts relaxes the criteria further and will close the dialog even if there were merges, adds or deletes. However, if there were any conflicts or errors, the dialog remains open.	7900
1757	7507	Auto-close if no errors always closes the dialog even if there were conflicts. The only condition that keeps the dialog open is an error condition, which occurs when Subversion is unable to complete the task. For example, an update fails because the server is inaccessible, or a commit fails because the working copy is out-of-date.	7904
1758	7511	Always close dialogs for local operations
1759	7515	Local operations like adding files or reverting changes do not need to contact the repository and complete quickly, so the progress dialog is often of little interest. Select this option if you want the progress dialog to close automatically after these operations, unless there are errors.
1760	7519	Use recycle bin when reverting	7908
1761	7523	When you revert local modifications, your changes are discarded. TortoiseSVN gives you an extra safety net by sending the modified file to the recycle bin before bringing back the pristine copy. If you prefer to skip the recycle bin, uncheck this option.	7912
1762	7527	Use URL of WC as the default From: URL	7916
1763	7531	In the merge dialog, the default behaviour is for the From: URL to be remembered between merges. However, some people like to perform merges from many different points in their hierarchy, and find it easier to start out with the URL of the current working copy. This can then be edited to refer to a parallel path on another branch.	7920
1764	7535	Default checkout path	7924
1765	7539	You can specify the default path for checkouts. If you keep all your checkouts in one place, it is useful to have the drive and folder pre-filled so you only have to add the new folder name to the end.	7928
1766	7543	Default checkout URL	7932
1767	7547	You can also specify the default URL for checkouts. If you often checkout sub-projects of some very large project, it can be useful to have the URL pre-filled so you only have to add the sub-project name to the end.	7936
1768	7551	TortoiseSVN Dialog Settings 2	7940
1769	7555	The Settings Dialog, Dialogs 2 Page	7944
1770	7559	Recurse into unversioned folders	7948
1771	7563	If this box is checked (default state), then whenever the status of an unversioned folder is shown in the Add, Commit or Check for Modifications dialog, every child file and folder is also shown. If you uncheck this box, only the unversioned parent is shown. Unchecking reduces clutter in these dialogs. In that case if you select an unversioned folder for Add, it is added recursively.	7952
1772	7567	In the Check for Modifications dialog you can opt to see ignored items. If this box is checked then whenever an ignored folder is found, all child items will be shown as well.	7956
1773	7571	Use auto-completion of file paths and keywords	7960
1774	7575	The commit dialog includes a facility to parse the list of filenames being committed. When you type the first 3 letters of an item in the list, the auto-completion box pops up, and you can press Enter to complete the filename. Check the box to enable this feature.	7964
1775	7579	Timeout in seconds to stop the auto-completion parsing	7968
1776	7583	The auto-completion parser can be quite slow if there are a lot of large files to check. This timeout stops the commit dialog being held up for too long. If you are missing important auto-completion information, you can extend the timeout.	7972
1777	7587	Only use spellchecker when tsvn:projectlanguage is set	7976
1778	7591	If you don't wish to use the spellchecker for all commits, check this box. The spellchecker will still be enabled where the project properties require it.	7980
1779	7595	Max. items to keep in the log message history	7984
1780	7599	When you type in a log message in the commit dialog, TortoiseSVN stores it for possible re-use later. By default it will keep the last 25 log messages for each repository, but you can customize that number here. If you have many different repositories, you may wish to reduce this to avoid filling your registry.	7988
1781	7603	Note that this setting applies only to messages that you type in on this computer. It has nothing to do with the log cache.	7992
1782	7607	Re-open commit and branch/tag dialog after a commit failed	7996
1783	7611	When a commit fails for some reason (working copy needs updating, pre-commit hook rejects commit, network error, etc), you can select this option to keep the commit dialog open ready to try again. However, you should be aware that this can lead to problems. If the failure means you need to update your working copy, and that update leads to conflicts you must resolve those first.	8000
1784	7615	Select items automatically	8004
1785	7619	The normal behaviour in the commit dialog is for all modified (versioned) items to be selected for commit automatically. If you prefer to start with nothing selected and pick the items for commit manually, uncheck this box.	8008
1786	7623	Contact the repository on startup	8012
1787	7627	The Check for Modifications dialog checks the working copy by default, and only contacts the repository when you click Check repository. If you always want to check the repository, you can use this setting to make that action happen automatically.	8016
1788	7631	Show Lock dialog before locking files	8020
1789	7635	When you select one or more files and then use TortoiseSVNLock to take out a lock on those files, on some projects it is customary to write a lock message explaining why you have locked the files. If you do not use lock messages, you can uncheck this box to skip that dialog and lock the files immediately.	8024
1790	7639	If you use the lock command on a folder, you are always presented with the lock dialog as that also gives you the option to select files for locking.	8028
1791	7643	If your project is using the tsvn:lockmsgminsize property, you will see the lock dialog regardless of this setting because the project requires lock messages.	8032
1792	7647	TortoiseSVN Colour Settings	8036
1793	7651	The Settings Dialog, Colours Page	8040
1794	7655	This dialog allows you to configure the text colours used in TortoiseSVN's dialogs the way you like them.	8044
1795	7659	Possible or real conflict / obstructed	8048
1796	7663	A conflict has occurred during update, or may occur during merge. Update is obstructed by an existing unversioned file/folder of the same name as a versioned one.	8052
1797	7667	This colour is also used for error messages in the progress dialogs.	8056
1798	7671	Added files	8060
1799	7675	Items added to the repository.	8064
1800	7679	Missing / deleted / replaced	8068
1801	7683	Items deleted from the repository, missing from the working copy, or deleted from the working copy and replaced with another file of the same name.	8072
1802	7687	Merged	8076
1803	7691	Changes from the repository successfully merged into the WC without creating any conflicts.	8080
1804	7695	Modified / copied	8084
1805	7699	Add with history, or paths copied in the repository. Also used in the log dialog for entries which include copied items.	8088
1806	7703	Deleted node	8092
1807	7707	An item which has been deleted from the repository.	8096
1808	7711	Added node	8100
1809	7715	An item which has been added to the repository, by an add, copy or move operation.	8104
1810	7719	Renamed node	8108
1811	7723	An item which has been renamed within the repository.	8112
1812	7727	Replaced node	8116
1813	7731	The original item has been deleted and a new item with the same name replaces it.	8120
1814	7735	Filter match
1815	7739	When using filtering in the log dialog, search terms are highlighted in the results using this colour.
1816	7743	Revision Graph Settings	8124
1817	7747	The Settings Dialog, Revision Graph Page	8128
1818	7751	Classification Patterns	8132
1819	7755	The revision graph attempts to show a clearer picture of your repository structure by distinguishing between trunk, branches and tags. As there is no such classification built into Subversion, this information is extracted from the path names. The default settings assume that you use the conventional English names as suggested in the Subversion documentation, but of course your usage may vary.	8136
1820	7759	Specify the patterns used to recognise these paths in the three boxes provided. The patterns will be matched case-insensitively, but you must specify them in lower case. Wild cards * and ? will work as usual, and you can use ; to separate multiple patterns. Do not include any extra white space as it will be included in the matching specification.	8140
1821	7763	Modify Colors	8144
1822	7767	Colors are used in the revision graph to indicate the node type, i.e. whether a node is added, deleted, renamed. In order to help pick out node classifications, you can allow the revision graph to blend colors to give an indication of both node type and classification. If the box is checked, blending is used. If the box is unchecked, color is used to indicate node type only. Use the color selection dialog to allocate the specific colors used.	8148
1823	7771	Revision Graph Colors	8152
1824	7775	The Settings Dialog, Revision Graph Colors Page	8156
1825	7779	This page allows you to configure the colors used. Note that the color specified here is the solid color. Most nodes are colored using a blend of the node type color, the background color and optionally the classification color.	8160
1826	7783	Deleted Node	8164
1827	7787	Items which have been deleted and not copied anywhere else in the same revision.	8168
1828	7791	Added Node	8172
1829	7795	Items newly added, or copied (add with history).	8176
1830	7799	Renamed Node	8180
1831	7803	Items deleted from one location and added in another in the same revision.	8184
1832	7807	Modified Node	8188
1833	7811	Simple modifications without any add or delete.	8192
1834	7815	Unchanged Node	8196
1835	7819	May be used to show the revision used as the source of a copy, even when no change (to the item being graphed) took place in that revision.	8200
1836	7823	HEAD node	8204
1837	7827	Current HEAD revision in the repository.	8208
1838	7831	WC Node	8212
1839	7835	If you opt to show an extra node for your modified working copy, attached to its last-commit revision on the graph, use this color.	8216
1840	7839	WC Node Border	8220
1841	7843	If you opt to show whether the working copy is modified, use this color border on the WC node when modifications are found.	8224
1842	7847	Tag Nodes	8228
1843	7851	Nodes classified as tags may be blended with this color.	8232
1844	7855	Trunk Nodes	8236
1845	7859	Nodes classified as trunk may be blended with this color.	8240
1846	7863	Folded Tag Markers	8244
1847	7867	If you use tag folding to save space, tags are marked on the copy source using a block in this color.	8248
1848	7871	Selected Node Markers	8252
1849	7875	When you left click on a node to select it, the marker used to indicate selection is a block in this color.	8256
1850	7879	Stripes	8260
1851	7883	These colors are used when the graph is split into sub-trees and the background is colored in alternating stripes to help pick out the separate trees.	8264
1852	7887	Icon Overlay Settings	8268
1853	7891	The Settings Dialog, Icon Overlays Page	8272
1854	7895	This page allows you to choose the items for which TortoiseSVN will display icon overlays.	8276
1855	7899	Default	8292
1856	7903	Caches all status information in a separate process (TSVNCache.exe). That process watches all drives for changes and fetches the status again if files inside a working copy get modified. The process runs with the least possible priority so other programs don't get hogged because of it. That also means that the status information is not real time but it can take a few seconds for the overlays to change.	8296
1857	7907	Advantage: the overlays show the status recursively, i.e. if a file deep inside a working copy is modified, all folders up to the working copy root will also show the modified overlay. And since the process can send notifications to the shell, the overlays on the left tree view usually change too.	8300
1858	7911	Disadvantage: the process runs constantly, even if you're not working on your projects. It also uses around 10-50 MB of RAM depending on number and size of your working copies.	8304
1859	7915	Shell	8308
1860	7919	Caching is done directly inside the shell extension dll, but only for the currently visible folder. Each time you navigate to another folder, the status information is fetched again.	8312
1861	7923	Advantage: needs only very little memory (around 1 MB of RAM) and can show the status in real time.	8316
1862	7927	Disadvantage: Since only one folder is cached, the overlays don't show the status recursively. For big working copies, it can take more time to show a folder in explorer than with the default cache. Also the mime-type column is not available.	8320
1863	7931	None	8324
1864	7935	With this setting, the TortoiseSVN does not fetch the status at all in Explorer. Because of that, files don't get an overlay and folders only get a 'normal' overlay if they're versioned. No other overlays are shown, and no extra columns are available either.	8328
1865	7939	Advantage: uses absolutely no additional memory and does not slow down the Explorer at all while browsing.	8332
1866	7943	Disadvantage: Status information of files and folders is not shown in Explorer. To see if your working copies are modified, you have to use the Check for modifications dialog.	8336
1867	7947	Since it takes quite a while to fetch the status of a working copy, TortoiseSVN uses a cache to store the status so the explorer doesn't get hogged too much when showing the overlays. You can choose which type of cache TortoiseSVN should use according to your system and working copy size here:	8340
1868	7951	By default, overlay icons and context menus will appear in all open/save dialogs as well as in Windows Explorer. If you want them to appear only in Windows Explorer, check the Show overlays and context menu only in explorer box.	8280
1869	7955	You can also choose to mark folders as modified if they contain unversioned items. This could be useful for reminding you that you have created new files which are not yet versioned. This option is only available when you use the default status cache option (see below).	8288
1870	7959	The next group allows you to select which classes of storage should show overlays. By default, only hard drives are selected. You can even disable all icon overlays, but where's the fun in that?	8344
1871	7963	Network drives can be very slow, so by default icons are not shown for working copies located on network shares.	8348
1872	7967	USB Flash drives appear to be a special case in that the drive type is identified by the device itself. Some appear as fixed drives, and some as removable drives.	8352
1873	7971	The Exclude Paths are used to tell TortoiseSVN those paths for which it should not show icon overlays and status columns. This is useful if you have some very big working copies containing only libraries which you won't change at all and therefore don't need the overlays, or if you only want TortoiseSVN to look in specific folders.
1874	7975	Any path you specify here is assumed to apply recursively, so none of the child folders will show overlays either. If you want to exclude only the named folder, append ? after the path.
1875	7979	The same applies to the Include Paths. Except that for those paths the overlays are shown even if the overlays are disabled for that specific drive type, or by an exclude path specified above.	8368
1876	7983	Users sometimes ask how these three settings interact. For any given path check the include and exclude lists, seeking upwards through the directory structure until a match is found. When the first match is found, obey that include or exclude rule. If there is a conflict, a single directory spec takes precedence over a recursive spec, then inclusion takes precedence over exclusion.
1877	7987	An example will help here: \n Exclude:\n C:\n C:\\develop\\?\n C:\\develop\\tsvn\\obj\n C:\\develop\\tsvn\\bin\n \n Include:\n C:\\develop\n These settings disable icon overlays for the C: drive, except for c:\\develop. All projects below that directory will show overlays, except the c:\\develop folder itself, which is specifically ignored. The high-churn binary folders are also excluded.
1878	7991	TSVNCache.exe also uses these paths to restrict its scanning. If you want it to look only in particular folders, disable all drive types and include only the folders you specifically want to be scanned.	8382
1879	7995	Exclude SUBST Drives	8386
1880	7999	SUBST drives	8390
1881	8003	It is often convenient to use a SUBST drive to access your working copies, e.g. using the command \n subst T: C:\\TortoiseSVN\\trunk\\doc\n However this can cause the overlays not to update, as TSVNCache will only receive one notification when a file changes, and that is normally for the original path. This means that your overlays on the subst path may never be updated.	8394
1882	8007	An easy way to work around this is to exclude the original path from showing overlays, so that the overlays show up on the subst path instead.	8401
1883	8011	Sometimes you will exclude areas that contain working copies, which saves TSVNCache from scanning and monitoring for changes, but you still want a visual indication that such folders are versioned. The Show excluded folders as 'normal' checkbox allows you to do this. With this option, versioned folders in any excluded area (drive type not checked, or specifically excluded) will show up as normal and up-to-date, with a green check mark. This reminds you that you are looking at a working copy, even though the folder overlays may not be correct. Files do not get an overlay at all. Note that the context menus still work, even though the overlays are not shown.	8405
1884	8015	As a special exception to this, drives A: and B: are never considered for the Show excluded folders as 'normal' option. This is because Windows is forced to look on the drive, which can result in a delay of several seconds when starting Explorer, even if your PC does have a floppy drive.	8409
1885	8019	Icon Set Selection	8413
1886	8023	The Settings Dialog, Icon Set Page	8417
1887	8027	You can change the overlay icon set to the one you like best. Note that if you change overlay set, you may have to restart your computer for the changes to take effect.	8421
1888	8031	Enabled Overlay Handlers
1889	8035	The Settings Dialog, Icon Handlers Page
1890	8039	Because the number of overlays available is severely restricted, you can choose to disable some handlers to ensure that the ones you want will be loaded. Because TortoiseSVN uses the common TortoiseOverlays component which is shared with other Tortoise clients (e.g. TortoiseCVS, TortoiseHG) this setting will affect those clients too.
1891	8043	Network Settings	8425
1892	8047	proxy server	8429
1893	8051	The Settings Dialog, Network Page	8433
1894	8055	Here you can configure your proxy server, if you need one to get through your company's firewall.	8437
1895	8059	If you need to set up per-repository proxy settings, you will need to use the Subversion servers file to configure this. Use Edit to get there directly. Consult the Runtime Configuration Area for details on how to use this file.	8441
1896	8063	You can also specify which program TortoiseSVN should use to establish a secure connection to a svn+ssh repository. We recommend that you use TortoisePlink.exe. This is a version of the popular Plink program, and is included with TortoiseSVN, but it is compiled as a Windowless app, so you don't get a DOS box popping up every time you authenticate.	8445
1897	8067	You must specify the full path to the executable. For TortoisePlink.exe this is the standard TortoiseSVN bin directory. Use the Browse button to help locate it. Note that if the path contains spaces, you must enclose it in quotes, e.g. \n \"C:\\Program Files\\TortoiseSVN\\bin\\TortoisePlink.exe\"\n	8449
1898	8071	One side-effect of not having a window is that there is nowhere for any error messages to go, so if authentication fails you will simply get a message saying something like Unable to write to standard output. For this reason we recommend that you first set up using standard Plink. When everything is working, you can use TortoisePlink with exactly the same parameters.	8456
1899	8075	TortoisePlink does not have any documentation of its own because it is just a minor variant of Plink. Find out about command line parameters from the PuTTY website	8460
1900	8079	To avoid being prompted for a password repeatedly, you might also consider using a password caching tool such as Pageant. This is also available for download from the PuTTY website.	8464
1901	8083	Finally, setting up SSH on server and clients is a non-trivial process which is beyond the scope of this help file. However, you can find a guide in the TortoiseSVN FAQ listed under Subversion/TortoiseSVN SSH How-To.	8468
1902	8087	External Program Settings	8472
1903	8091	The Settings Dialog, Diff Viewer Page	8476
1904	8095	Here you can define your own diff/merge programs that TortoiseSVN should use. The default setting is to use TortoiseMerge which is installed alongside TortoiseSVN.	8480
1905	8099	Read for a list of some of the external diff/merge programs that people are using with TortoiseSVN.	8484
1906	8103	Diff Viewer	8488
1907	8107	The original file without your changes	8492
1908	8112	The window title for the base file	8497
1909	8116	Your own file, with your changes	8501
1910	8121	The window title for your file	8506
1911	8125	An external diff program may be used for comparing different revisions of files. The external program will need to obtain the filenames from the command line, along with any other command line options. TortoiseSVN uses substitution parameters prefixed with %. When it encounters one of these it will substitute the appropriate value. The order of the parameters will depend on the Diff program you use.	8510
1912	8129	The window titles are not pure filenames. TortoiseSVN treats that as a name to display and creates the names accordingly. So e.g. if you're doing a diff from a file in revision 123 with a file in your working copy, the names will be filename : revision 123 and filename : working copy	8514
1913	8133	For example, with ExamDiff Pro: \n C:\\Path-To\\ExamDiff.exe %base %mine --left_display_name:%bname\n --right_display_name:%yname\n or with KDiff3: \n C:\\Path-To\\kdiff3.exe %base %mine --L1 %bname --L2 %yname\n or with WinMerge: \n C:\\Path-To\\WinMerge.exe -e -ub -dl %bname -dr %yname %base %mine\n or with Araxis: \n C:\\Path-To\\compare.exe /max /wait /title1:%bname /title2:%yname\n %base %mine\n or with UltraCompare: \n C:\\Path-To\\uc.exe %base %mine -title1 %bname -title2 %yname\n	8518
1914	8137	If you use the svn:keywords property to expand keywords, and in particular the revision of a file, then there may be a difference between files which is purely due to the current value of the keyword. Also if you use svn:eol-style = native the BASE file will have pure LF line endings whereas your file will have CR-LF line endings. TortoiseSVN will normally hide these differences automatically by first parsing the BASE file to expand keywords and line endings before doing the diff operation. However, this can take a long time with large files. If Convert files when diffing against BASE is unchecked then TortoiseSVN will skip pre-processing the files.	8535
1915	8141	You can also specify a different diff tool to use on Subversion properties. Since these tend to be short simple text strings, you may want to use a simpler more compact viewer.	8539
1916	8145	If you have configured an alternate diff tool, you can access TortoiseMerge and the third party tool from the context menus. Context menuDiff uses the primary diff tool, and Shift+ Context menuDiff uses the secondary diff tool.	8543
1917	8149	Merge Tool	8547
1918	8153	the original file without your or the others changes	8551
1919	8157	your own file, with your changes	8555
1920	8161	the file as it is in the repository	8559
1921	8165	The window title for the file in the repository	8563
1922	8169	the conflicted file, the result of the merge operation	8567
1923	8173	The window title for the merged file	8571
1924	8177	An external merge program used to resolve conflicted files. Parameter substitution is used in the same way as with the Diff Program.	8575
1925	8181	For example, with Perforce Merge: \n C:\\Path-To\\P4Merge.exe %base %theirs %mine %merged\n or with KDiff3: \n C:\\Path-To\\kdiff3.exe %base %mine %theirs -o %merged\n --L1 %bname --L2 %yname --L3 %tname\n or with Araxis: \n C:\\Path-To\\compare.exe /max /wait /3 /title1:%tname /title2:%bname\n /title3:%yname %theirs %base %mine %merged /a2\n or with WinMerge (2.8 or later): \n C:\\Path-To\\WinMerge.exe %merged\n	8579
1926	8185	Diff/Merge Advanced Settings	8594
1927	8189	The Settings Dialog, Diff/Merge Advanced Dialog	8598
1928	8193	In the advanced settings, you can define a different diff and merge program for every file extension. For instance you could associate Photoshop as the Diff Program for .jpg files :-) You can also associate the svn:mime-type property with a diff or merge program.	8602
1929	8197	To associate using a file extension, you need to specify the extension. Use .bmp to describe Windows bitmap files. To associate using the svn:mime-type property, specify the mime type, including a slash, for example text/xml.	8606
1930	8201	Unified Diff Viewer	8610
1931	8205	A viewer program for unified-diff files (patch files). No parameters are required. The Default option is to check for a file association for .diff files, and then for .txt files. If you don't have a viewer for .diff files, you will most likely get NotePad.	8614
1932	8209	The original Windows NotePad program does not behave well on files which do not have standard CR-LF line-endings. Since most unified diff files have pure LF line-endings, they do not view well in NotePad. However, you can download a free NotePad replacement Notepad2 which not only displays the line-endings correctly, but also colour codes the added and removed lines.	8618
1933	8213	Saved Data Settings	8622
1934	8217	The Settings Dialog, Saved Data Page	8626
1935	8221	For your convenience, TortoiseSVN saves many of the settings you use, and remembers where you have been lately. If you want to clear out that cache of data, you can do it here.	8630
1936	8225	URL history	8634
1937	8229	Whenever you checkout a working copy, merge changes or use the repository browser, TortoiseSVN keeps a record of recently used URLs and offers them in a combo box. Sometimes that list gets cluttered with outdated URLs so it is useful to flush it out periodically.	8638
1938	8233	If you want to remove a single item from one of the combo boxes you can do that in-place. Just click on the arrow to drop the combo box down, move the mouse over the item you want to remove and type Shift+Del.	8642
1939	8237	Log messages (Input dialog)	8646
1940	8241	TortoiseSVN stores recent commit log messages that you enter. These are stored per repository, so if you access many repositories this list can grow quite large.	8650
1941	8245	Log messages (Show log dialog)	8654
1942	8249	TortoiseSVN caches log messages fetched by the Show Log dialog to save time when you next show the log. If someone else edits a log message and you already have that message cached, you will not see the change until you clear the cache. Log message caching is enabled on the Log Cache tab.	8658
1943	8253	Dialog sizes and positions	8662
1944	8257	Many dialogs remember the size and screen position that you last used.	8666
1945	8261	Authentication data	8670
1946	8265	When you authenticate with a Subversion server, the username and password are cached locally so you don't have to keep entering them. You may want to clear this for security reasons, or because you want to access the repository under a different username ... does John know you are using his PC?	8674
1947	8269	If you want to clear authentication data for one particular server only, read for instructions on how to find the cached data.	8678
1948	8273	Action log	8682
1949	8277	TortoiseSVN keeps a log of everything written to its progress dialogs. This can be useful when, for example, you want to check what happened in a recent update command.	8686
1950	8281	The log file is limited in length and when it grows too big the oldest content is discarded. By default 4000 lines are kept, but you can customize that number.	8690
1951	8285	From here you can view the log file content, and also clear it.	8694
1952	8289	Log Caching	8698
1953	8293	log cache	8702
1954	8297	The Settings Dialog, Log Cache Page	8706
1955	8301	This dialog allows you to configure the log caching feature of TortoiseSVN, which retains a local copy of log messages and changed paths to avoid time-consuming downloads from the server. Using the log cache can dramatically speed up the log dialog and the revision graph. Another useful feature is that the log messages can still be accessed when offline.	8710
1956	8305	Enable log caching	8714
1957	8309	Enables log caching whenever log data is requested. If checked, data will be retrieved from the cache when available, and any messages not in the cache will be retrieved from the server and added to the cache.	8718
1958	8313	If caching is disabled, data will always be retrieved directly from the server and not stored locally.	8722
1959	8317	Allow ambiguous URLs	8726
1960	8321	Occasionally you may have to connect to a server which uses the same URL for all repositories. Older versions of svnbridge would do this. If you need to access such repositories you will have to check this option. If you don't, leave it unchecked to improve performance.	8730
1961	8325	Allow ambiguous UUIDs	8734
1962	8329	Some hosting services give all their repositories the same UUID. You may even have done this yourself by copying a repository folder to create a new one. For all sorts of reasons this is a bad idea - a UUID should be unique. However, the log cache will still work in this situation if you check this box. If you don't need it, leave it unchecked to improve performance.	8738
1963	8333	If the repository cannot be contacted	8742
1964	8337	If you are working offline, or if the repository server is down, the log cache can still be used to supply log messages already held in the cache. Of course the cache may not be up-to-date, so there are options to allow you to select whether this feature should be used.	8746
1965	8341	When log data is being taken from the cache without contacting the server, the dialog using those message will show the offline state in its title bar.	8750
1966	8345	Timeout before updating the HEAD revision	8754
1967	8349	When you invoke the log dialog you will normally want to contact the server to check for any newer log messages. If the timeout set here is non-zero then the server will only be contacted when the timeout has elapsed since the last time contact. This can reduce server round-trips if you open the log dialog frequently and the server is slow, but the data shown may not be completely up-to-date. If you want to use this feature we suggest using a value of 300 (5 minutes) as a compromise.	8758
1968	8353	Days of inactivity until small caches get removed	8762
1969	8357	If you browse around a lot of repositories you will accumulate a lot of log caches. If you're not actively using them, the cache will not grow very big, so TortoiseSVN purges them after a set time by default. Use this item to control cache purging.	8766
1970	8361	Maximum size of removed inactive caches	8770
1971	8365	Larger caches are more expensive to reacquire, so TortoiseSVN only purges small caches. Fine tune the threshold with this value.	8774
1972	8369	Maximum number of tool failures before cache removal	8778
1973	8373	Occasionally something goes wrong with the caching and causes a crash. If this happens the cache is normally deleted automatically to prevent a recurrence of the problem. If you use the less stable nightly build you may opt to keep the cache anyway.	8782
1974	8377	Cached Repositories	8786
1975	8381	On this page you can see a list of the repositories that are cached locally, and the space used for the cache. If you select one of the repositories you can then use the buttons underneath.	8790
1976	8385	Click on the Update to completely refresh the cache and fill in any holes. For a large repository this could be very time consuming, but useful if you are about to go offline and want the best available cache.	8794
1977	8389	Click on the Export button to export the entire cache as a set of CSV files. This could be useful if you want to process the log data using an external program, although it is mainly useful to the developers.	8798
1978	8393	Click on Delete to remove all cached data for the selected repositories. This does not disable caching for the repository so the next time you request log data, a new cache will be created.	8802
1979	8397	Log Cache Statistics	8806
1980	8401	The Settings Dialog, Log Cache Statistics	8810
1981	8409	The amount of memory required to service this cache.	8818
1982	8413	Disk	8822
1983	8417	The amount of disk space used for the cache. Data is compressed, so disk usage is generally fairly modest.	8826
1984	8421	Connection	8830
1985	8425	Shows whether the repository was available last time the cache was used.	8834
1986	8429	Last update	8838
1987	8433	The last time the cache content was changed.	8842
1988	8437	Last head update	8846
1989	8441	The last time we requested the HEAD revision from the server.	8850
1990	8445	Authors	8854
1991	8449	The number of different authors with messages recorded in the cache.	8858
1992	8453	Paths	8862
1993	8457	The number of paths listed, as you would see using svn log -v.	8866
1994	8461	Skip ranges	8870
1995	8465	The number of revision ranges which we have not fetched, simply because they haven't been requested. This is a measure of the number of holes in the cache.	8874
1996	8469	Max revision	8878
1997	8473	The highest revision number stored in the cache.	8882
1998	8477	Revision count	8886
1999	8481	The number of revisions stored in the cache. This is another measure of cache completeness.	8890
2000	8485	Click on the Details button to see detailed statistics for a particular cache. Many of the fields shown here are mainly of interest to the developers of TortoiseSVN, so they are not all described in detail.	8894
2001	8489	Client Side Hook Scripts	8898
2002	8493	client hooks	8902
2003	8497	The Settings Dialog, Hook Scripts Page	8906
2004	8501	This dialog allows you to set up hook scripts which will be executed automatically when certain Subversion actions are performed. As opposed to the hook scripts explained in , these scripts are executed locally on the client.	8910
2005	8505	One application for such hooks might be to call a program like SubWCRev.exe to update version numbers after a commit, and perhaps to trigger a rebuild.	8914
2006	8509	For various security and implementation reasons, hook scripts are defined locally on a machine, rather than as project properties. You define what happens, no matter what someone else commits to the repository. Of course you can always choose to call a script which is itself under version control.	8918
2007	8513	The Settings Dialog, Configure Hook Scripts	8922
2008	8517	To add a new hook script, simply click Add and fill in the details.	8926
2009	8522	Start-commit	8931
2010	8526	Called before the commit dialog is shown. You might want to use this if the hook modifies a versioned file and affects the list of files that need to be committed and/or commit message. However you should note that because the hook is called at an early stage, the full list of objects selected for commit is not available.	8935
2011	8531	Pre-commit	8940
2012	8535	Called after the user clicks OK in the commit dialog, and before the actual commit begins. This hook has a list of exactly what will be committed.	8944
2013	8540	Post-commit	8949
2014	8544	Called after the commit finishes (whether successful or not).	8953
2015	8549	Start-update	8958
2016	8553	Called before the update-to-revision dialog is shown.	8962
2017	8558	Pre-update	8967
2018	8562	Called before the actual Subversion update or switch begins.	8971
2019	8567	Post-update	8976
2020	8571	Called after the update, switch or checkout finishes (whether successful or not).	8980
2021	8576	Pre-connect
2022	8580	Called before an attempt to contact the repository. Called at most once in five minutes.
2023	8584	There are currently six types of hook script available	8984
2024	8588	A hook is defined for a particular working copy path. You only need to specify the top level path; if you perform an operation in a sub-folder, TortoiseSVN will automatically search upwards for a matching path.	8988
2025	8592	Next you must specify the command line to execute, starting with the path to the hook script or executable. This could be a batch file, an executable file or any other file which has a valid windows file association, eg. a perl script. Note that the script must not be specified using a UNC path as Windows shell execute will not allow such scripts to run due to security restrictions.
2026	8596	The command line includes several parameters which get filled in by TortoiseSVN. The parameters passed depend upon which hook is called. Each hook has its own parameters which are passed in the following order:	8996
2027	8600	A path to a temporary file which contains all the paths for which the operation was started. Each path is on a separate line in the temp file.	9000
2028	8604	The depth with which the commit/update is done.	9004
2029	8632	Possible values are:	9032
2030	8636	Path to a file containing the log message for the commit. The file contains the text in UTF-8 encoding. After successful execution of the start-commit hook, the log message is read back, giving the hook a chance to modify it.	9036
2031	8640	The repository revision to which the update should be done or after a commit completes.	9040
2032	8644	Path to a file containing the error message. If there was no error, the file will be empty.	9044
2033	8648	The current working directory with which the script is run. This is set to the common root directory of all affected paths.	9048
2034	8652	The meaning of each of these parameters is described here:	9052
2035	8656	Note that although we have given these parameters names for convenience, you do not have to refer to those names in the hook settings. All parameters listed for a particular hook are always passed, whether you want them or not ;-)	9056
2036	8660	If you want the Subversion operation to hold off until the hook has completed, check Wait for the script to finish.	9060
2037	8664	Normally you will want to hide ugly DOS boxes when the script runs, so Hide the script while running is checked by default.	9064
2038	8668	Sample client hook scripts can be found in the contrib folder in the TortoiseSVN repository. ( explains how to access the repository).	9068
2039	8672	A small tool is included in the TortoiseSVN installation folder named ConnectVPN.exe. You can use this tool configured as a pre-connect hook to connect automatically to your VPN before TortoiseSVN tries to connect to a repository. Just pass the name of the VPN connection as the first parameter to the tool.
2040	8676	Issue Tracker Integration	9072
2041	8680	TortoiseSVN can use a COM plugin to query issue trackers when in the commit dialog. The use of such plugins is described in . If your system administrator has provided you with a plugin, which you have already installed and registered, this is the place to specify how it integrates with your working copy.	9076
2042	8684	The Settings Dialog, Issue Tracker Integration Page	9080
2043	8688	Click on Add... to use the plugin with a particular working copy. Here you can specify the working copy path, choose which plugin to use from a drop down list of all registered issue tracker plugins, and any parameters to pass. The parameters will be specific to the plugin, but might include your user name on the issue tracker so that the plugin can query for issues which are assigned to you.	9084
2044	8692	This property specifies the COM UUID of the IBugtraqProvider, for example {91974081-2DC7-4FB1-B3BE-0DE1C8D6CE4E}. (this example is the UUID of the Gurtle bugtraq provider, which is a provider for the Google Code issue tracker).	9088
2045	8696	This is the same as bugtraq:provideruuid, but for the 64-bit version of the IBugtraqProvider.	9092
2046	8700	This property specifies the parameters passed to the IBugtraqProvider.	9096
2047	8704	If you want all users to use the same COM plugin for your project, you can specify the plugin also with the properties bugtraq:provideruuid, bugtraq:provideruuid64 and bugtraq:providerparams. Please check the documentation of your IBugtraqProvider plugin to find out what to specify in these two properties.	9100
2048	8708	TortoiseBlame Settings	9104
2049	8712	The Settings Dialog, TortoiseBlame Page	9108
2050	8716	The settings used by TortoiseBlame are controlled from the main context menu, not directly with TortoiseBlame itself.	9112
2051	8720	Colors	9116
2052	8724	TortoiseBlame can use the background colour to indicate the age of lines in a file. You set the endpoints by specifying the colours for the newest and oldest revisions, and TortoiseBlame uses a linear interpolation between these colours according to the repository revision indicated for each line.	9120
2053	8728	Font	9124
2054	8732	You can select the font used to display the text, and the point size to use. This applies both to the file content, and to the author and revision information shown in the left pane.	9128
2055	8736	Tabs	9132
2056	8740	Defines how many spaces to use for expansion when a tab character is found in the file content.	9136
2057	8744	Subversion Working Folders	9140
2058	8748	.svn folder	9144
2059	8752	_svn folder	9148
2060	8756	VS.NET 2003 when used with web projects can't handle the .svn folders that Subversion uses to store its internal information. This is not a bug in Subversion. The bug is in VS.NET 2003 and the frontpage extensions it uses.	9152
2061	8760	Note that the bug is fixed in VS2005 and later versions.	9156
2062	8764	As of Version 1.3.0 of Subversion and TortoiseSVN, you can set the environment variable SVN_ASP_DOT_NET_HACK. If that variable is set, then Subversion will use _svn folders instead of .svn folders. You must restart your shell for that environment variable to take effect. Normally that means rebooting your PC. To make this easier, you can now do this from the general settings page using a simple checkbox - refer to .	9160
2063	8768	For more information, and other ways to avoid this problem in the first place, check out the article about this in our FAQ.	9164
2064	8772	Advanced Settings	9168
2065	8776	registry	9172
2066	8780	A few infrequently used settings are available only in the advanced page of the settings dialog. These settings modify the registry directly and you have to know what each of these settings is used for and what it does. Do not modify these settings unless you are sure you need to change them.	9176
2067	8784	You can specify a different location for the Subversion configuration file here. This will affect all TortoiseSVN operations.	9180
2068	8788	Set this to true if you want a dialog to pop up for every command showing the command line used to start TortoiseProc.exe	9184
2069	8792	To add a cache tray icon for the TSVNCache program, set this value to true. This is really only useful for developers as it allows you to terminate the program gracefully.	9188
2070	8796	This can be useful if you use something other than the windows explorer or if you get problems with the context menu displaying incorrectly. Set this value to false if you don't want TortoiseSVN to show icons for the shell context menu items. Set this value to true to show the icons again.	9192
2071	8800	If you don't want TortoiseSVN to show icons for the context menus in its own dialogs, set this value to false.	9196
2072	8804	The log dialog shows the revision the working copy path is at in bold. But this requires that the log dialog fetches the status of that path. Since for very big working copies this can take a while, you can set this value to false to deactivate this feature.	9200
2073	8808	The status list control which is used in various dialogs (e.g., commit, check-for-modifications, add, revert, ...) uses full row selection (i.e., if you select an entry, the full row is selected, not just the first column). This is fine, but the selected row then also covers the background image on the bottom right, which can look ugly. To disable full row select, set this value to false.	9204
2074	8812	The commit and log dialog use styling (e.g. bold, italic) in commit messages (see for details). If you don't want to do this, set the value to false.	9208
2075	8816	TortoiseSVN uses accelerators for its explorer context menu entries. Since this can lead to doubled accelerators (e.g. the SVN Commit has the Alt-C accelerator, but so does the Copy entry of explorer). If you don't want or need the accelerators of the TortoiseSVN entries, set this value to false.	9212
2076	8820	As with the explorer, TortoiseSVN shows additional commands if the Shift key is pressed while the context menu is opened. To force TortoiseSVN to always show those extended commands, set this value to true.	9216
2077	8824	If you don't want the explorer to update the status overlays while another TortoiseSVN command is running (e.g. Update, Commit, ...) then set this value to true.	9220
2078	8828	This value contains the URL from which TortoiseSVN tries to download a text file to find out if there are updates available. This might be useful for company admins who don't want their users to update TortoiseSVN until they approve it.	9224
2079	8832	The extra columns the TortoiseSVN adds to the details view in Windows Explorer are normally only active in a working copy. If you want those to be accessible everywhere, not just in working copies, set this value to true. Note that the extra columns are only available in XP. Vista and later doesn't support that feature any more.	9228
2080	8836	If an update adds a new file from the repository which already exists in the local working copy as an unversioned file, the default action is to keep the local file, showing it as a (possibly) modified version of the new file from the repository. If you would prefer TortoiseSVN to create a conflict in such situations, set this value to false.	9232
2081	8840	TortoiseSVN checks whether there's a new version available about once a week. If an updated version is found, the commit dialog shows a link control with that info. If you prefer the old behavior back where a dialog pops up notifying you about the update, set this value to true.	9236
2082	8844	TortoiseSVN checks whether there's a new version available about once a week. If you don't want TortoiseSVN to do this check, set this value to false.	9240
2083	8848	The auto-completion list shown in the commit message editor displays the names of files listed for commit. To also include these names with extensions removed, set this value to true.	9244
2084	8852	When you merge revisions from another branch, and merge tracking information is available, the log messages from the revisions you merge will be collected to make up a commit log message. A pre-defined string is used to separate the individual log messages of the merged revisions. If you prefer, you can set this to a value containing a separator string of your choice.	9248
2085	8856	TortoiseSVN allows you to assign an external diff viewer. Most such viewers, however, are not suited for change blaming (), so you might wish to fall back to TortoiseMerge in this case. To do so, set this value to true.	9252
2086	8860	By default, TortoiseSVN always runs an update with externals included. This avoids problems with inconsistent working copies. If you have however a lot of externals set, an update can take quite a while. Set this value to false to run the default update with externals excluded. To update with externals included, either run the Update to revision... dialog or set this value to true again.	9256
2087	8864	In most dialogs in TortoiseSVN, you can use Ctrl+Enter to dismiss the dialog as if you clicked on the OK button. If you don't want this, set this value to false.	9260
2088	8868	Sometimes multiple users use the same account on the same computer. In such situations it's not really wanted to save the authentication data. Setting this value to false disables the save authentication button in the authentication dialog.
2089	8872	Final Step	9264
2090	8876	Donate!	9268
2091	8880	Even though TortoiseSVN and TortoiseMerge are free, you can support the developers by sending in patches and play an active role in the development. You can also help to cheer us up during the endless hours we spend in front of our computers.	9272
2092	8884	While working on TortoiseSVN we love to listen to music. And since we spend many hours on the project we need a lot of music. Therefore we have set up some wish-lists with our favourite music CDs and DVDs: http://tortoisesvn.tigris.org/donate.html Please also have a look at the list of people who contributed to the project by sending in patches or translations.	9276
2093	8888	The SubWCRev Program	9280
2094	8892	version extraction	9284
2095	8905	version number in files	9297
2096	8909	SubWCRev is Windows console program which can be used to read the status of a Subversion working copy and optionally perform keyword substitution in a template file. This is often used as part of the build process as a means of incorporating working copy information into the object you are building. Typically it might be used to include the revision number in an About box.	9301
2097	8913	The SubWCRev Command Line	9305
2098	8917	SubWCRev reads the Subversion status of all files in a working copy, excluding externals by default. It records the highest commit revision number found, and the commit timestamp of that revision, It also records whether there are local modifications in the working copy, or mixed update revisions. The revision number, update revision range and modification status are displayed on stdout.	9309
2099	8921	SubWCRev.exe is called from the command line or a script, and is controlled using the command line parameters. \n SubWCRev WorkingCopyPath [SrcVersionFile DstVersionFile] [-nmdfe]\n	9313
2100	8925	WorkingCopyPath is the path to the working copy being checked. You can only use SubWCRev on working copies, not directly on the repository. The path may be absolute or relative to the current working directory.	9320
2101	8929	If you want SubWCRev to perform keyword substitution, so that fields like repository revision and URL are saved to a text file, you need to supply a template file SrcVersionFile and an output file DstVersionFile which contains the substituted version of the template.	9324
2102	8934	List of available command line switches	9329
2103	8941	Switch	9336
2104	8949	Description	9344
2105	8957	If this switch is given, SubWCRev will exit with if the working copy contains local modifications. This may be used to prevent building with uncommitted changes present.	9352
2106	8965	If this switch is given, SubWCRev will exit with if the working copy contains mixed revisions. This may be used to prevent building with a partially updated working copy.	9360
2107	8973	If this switch is given, SubWCRev will exit with if the destination file already exists.	9368
2108	8977	If this switch is given, SubWCRev will include the last-changed revision of folders. The default behaviour is to use only files when getting the revision numbers.	9372
2109	8985	If this switch is given, SubWCRev will examine directories which are included with , but only if they are from the same repository. The default behaviour is to ignore externals.	9380
2110	8989	If this switch is given, SubWCRev will output the revision numbers in HEX.	9384
2111	8993	If this switch is given, SubWCRev will output the revision numbers in HEX, with '0X' prepended.	9388
2112	8997	There are a number of optional switches which affect the way SubWCRev works. If you use more than one, they must be specified as a single group, eg. -nm, not -n -m.	9392
2113	9001	Keyword Substitution	9396
2114	9005	Keyword	9400
2115	9009	Replaced with the highest commit revision in the working copy.	9404
2116	9025	online reference	9420
2117	9029	Replaced with the commit date/time of the highest commit revision. By default, international format is used: . Alternatively, you can specify a custom format which will be used with , for example: . For a list of available formatting characters, look at the .	9424
2118	9035	$WCDATE$	9430
2119	9039	Replaced with the current system date/time. This can be used to indicate the build time. Time formatting can be used as described for .	9434
2120	9043	Replaced with the update revision range in the working copy. If the working copy is in a consistent state, this will be a single revision. If the working copy contains mixed revisions, either due to being out of date, or due to a deliberate update-to-revision, then the range will be shown in the form 100:200	9438
2121	9065	is replaced with if there are mixed update revisions, or if not.	9462
2122	9073	is replaced with if there are local modifications, or if not.	9470
2123	9077	Replaced with the repository URL of the working copy path passed to SubWCRev.	9474
2124	9085	is replaced with if the entry is versioned, or if not.	9482
2125	9093	is replaced with if the entry is locked, or if not.	9503
2126	9097	Replaced with the lock date. Time formatting can be used as described for .	9507
2127	9101	Replaced with the name of the lock owner.	9511
2128	9105	Replaced with the comment of the lock.	9515
2129	9109	If a source and destination files are supplied, SubWCRev copies source to destination, performing keyword substitution as follows:	9519
2130	9113	Some of these keywords apply to single files rather than to an entire working copy, so it only makes sense to use these when SubWCRev is called to scan a single file. This applies to $WCINSVN$, $WCISLOCKED$, $WCLOCKDATE$, $WCLOCKOWNER$ and $WCLOCKCOMMENT$.
2131	9117	Keyword Example	9527
2132	9121	The example below shows how keywords in a template file are substituted in the output file.	9531
2133	9125	\n // Test file for SubWCRev: testfile.tmpl\n \n char *Revision = \"$WCREV$\";\n char *Modified = \"$WCMODS?Modified:Not modified$\";\n char *Date = \"$WCDATE$\";\n char *Range = \"$WCRANGE$\";\n char *Mixed = \"$WCMIXED?Mixed revision WC:Not mixed$\";\n char *URL = \"$WCURL$\";\n \n #if $WCMODS?1:0$\n #error Source is modified\n #endif\n \n // End of file\n	9535
2134	9130	After running SubWCRev.exe path\\to\\workingcopy testfile.tmpl testfile.txt, the output file testfile.txt would looks like this:	9555
2135	9134	\n // Test file for SubWCRev: testfile.txt\n \n char *Revision = \"3701\";\n char *Modified = \"Modified\";\n char *Date = \"2005/06/15 11:15:12\";\n char *Range = \"3699:3701\";\n char *Mixed = \"Mixed revision WC\";\n char *URL = \"http://project.domain.org/svn/trunk/src\";\n \n #if 1\n #error Source is modified\n #endif\n \n // End of file\n	9559
2136	9139	A file like this will be included in the build so you would expect it to be versioned. Be sure to version the template file, not the generated file, otherwise each time you regenerate the version file you need to commit the change, which in turn means the version file needs to be updated.	9579
2137	9143	COM interface	9583
2138	9147	COM SubWCRev interface	9587
2139	9151	COM/automation methods supported	9591
2140	9155	Method	9595
2141	9167	This method traverses the working copy gathering the revision information. Naturally you must call this before you can access the information using the remaining methods. The first parameter is the path. The second parameter should be true if you want to include folder revisions. Equivalent to the command line switch. The third parameter should be true if you want to include svn:externals. Equivalent to the command line switch.	9607
2142	9175	The highest commit revision in the working copy. Equivalent to	9615
2143	9179	The commit date/time of the highest commit revision. Equivalent to	9619
2144	9183	The author of the highest commit revision, that is, the last person to commit changes to the working copy.	9623
2145	9192	The minimum update revision, as shown in	9632
2146	9196	The maximum update revision, as shown in	9636
2147	9200	True if there are local modifications	9640
2148	9212	Replaced with the repository URL of the working copy path used in . Equivalent to	9652
2149	9216	True if the item is versioned.	9656
2150	9220	True if the item is locked.	9664
2151	9224	String representing the date when the lock was created, or an empty string if the item is not locked.	9668
2152	9228	String representing the lock owner, or an empty string if the item is not locked.	9672
2153	9232	The message entered when the lock was created.	9676
2154	9236	If you need to access Subversion revision information from other programs, you can use the COM interface of SubWCRev. The object to create is SubWCRev.object, and the following methods are supported:	9680
2155	9240	\n // testCOM.js - javascript file\n // test script for the SubWCRev COM/Automation-object\n \n filesystem = new ActiveXObject(\"Scripting.FileSystemObject\");\n \n revObject1 = new ActiveXObject(\"SubWCRev.object\");\n revObject2 = new ActiveXObject(\"SubWCRev.object\");\n revObject3 = new ActiveXObject(\"SubWCRev.object\");\n revObject4 = new ActiveXObject(\"SubWCRev.object\");\n \n revObject1.GetWCInfo(\n filesystem.GetAbsolutePathName(\".\"), 1, 1);\n revObject2.GetWCInfo(\n filesystem.GetAbsolutePathName(\"..\"), 1, 1);\n revObject3.GetWCInfo(\n filesystem.GetAbsolutePathName(\"SubWCRev.cpp\"), 1, 1);\n revObject4.GetWCInfo(\n filesystem.GetAbsolutePathName(\"..\\\\..\"), 1, 1);\n \n wcInfoString1 = \"Revision = \" + revObject1.Revision +\n \"\\n Min Revision = \" + revObject1.MinRev +\n \"\\n Max Revision = \" + revObject1.MaxRev +\n \"\\n Date = \" + revObject1.Date +\n \"\\n URL = \" + revObject1.Url + \"\\n Author = \" +\n revObject1.Author + \"\\n HasMods = \" +\n revObject1.HasModifications + \"\\n IsSvnItem = \" +\n revObject1.IsSvnItem + \"\\n NeedsLocking = \" +\n revObject1.IsLocked + \"\\n LockCreationDate = \" +\n revObject1.LockCreationDate + \"\\n LockOwner = \" +\n revObject1.LockOwner + \"\\n LockComment = \" +\n revObject1.LockComment;\n wcInfoString2 = \"Revision = \" + revObject2.Revision +\n \"\\n Min Revision = \" + revObject2.MinRev +\n \"\\n Max Revision = \" + revObject2.MaxRev +\n \"\\n Date = \" + revObject2.Date +\n \"\\n URL = \" + revObject2.Url + \"\\n Author = \" +\n revObject2.Author + \"\\n HasMods = \" +\n revObject2.HasModifications + \"\\n IsSvnItem = \" +\n revObject2.IsSvnItem + \"\\n NeedsLocking = \" +\n revObject2.IsLocked + \"\\n LockCreationDate = \" +\n revObject2.LockCreationDate + \"\\n LockOwner = \" +\n revObject2.LockOwner + \"\\n LockComment = \" +\n revObject2.LockComment;\n wcInfoString3 = \"Revision = \" + revObject3.Revision +\n \"\\n Min Revision = \" + revObject3.MinRev +\n \"\\n Max Revision = \" + revObject3.MaxRev +\n \"\\n Date = \" + revObject3.Date +\n \"\\n URL = \" + revObject3.Url + \"\\n Author = \" +\n revObject3.Author + \"\\n HasMods = \" +\n revObject3.HasModifications + \"\\n IsSvnItem = \" +\n revObject3.IsSvnItem + \"\\n NeedsLocking = \" +\n revObject3.IsLocked + \"\\n LockCreationDate = \" +\n revObject3.LockCreationDate + \"\\n LockOwner = \" +\n revObject3.LockOwner + \"\\n LockComment = \" +\n revObject3.LockComment;\n wcInfoString4 = \"Revision = \" + revObject4.Revision +\n \"\\n Min Revision = \" + revObject4.MinRev +\n \"\\n Max Revision = \" + revObject4.MaxRev +\n \"\\n Date = \" + revObject4.Date +\n \"\\n URL = \" + revObject4.Url + \"\\n Author = \" +\n revObject4.Author + \"\\n HasMods = \" +\n revObject4.HasModifications + \"\\n IsSvnItem = \" +\n revObject4.IsSvnItem + \"\\n NeedsLocking = \" +\n revObject4.IsLocked + \"\\n LockCreationDate = \" +\n revObject4.LockCreationDate + \"\\n LockOwner = \" +\n revObject4.LockOwner + \"\\n LockComment = \" +\n revObject4.LockComment;\n \n WScript.Echo(wcInfoString1);\n WScript.Echo(wcInfoString2);\n WScript.Echo(wcInfoString3);\n WScript.Echo(wcInfoString4);\n \n
2156	9245	The following example shows how the interface might be used.	9815
2157	9249	\n using LibSubWCRev;\n SubWCRev sub = new SubWCRev();\n sub.GetWCInfo(\"C:\\\\PathToMyFile\\\\MyFile.cc\", true, true);\n if (sub.IsSvnItem == true)\n {\n MessageBox.Show(\"versioned\");\n }\n else\n {\n MessageBox.Show(\"not versioned\");\n }\n	9819
2158	9254	The following listing is an example on how to use the SubWCRev COM object from C#:	9836
2159	9258	IBugtraqProvider interface	9840
2160	9262	plugin	9844
2161	9270	To get a tighter integration with issue trackers than by simply using the bugtraq: properties, TortoiseSVN can make use of COM plugins. With such plugins it is possible to fetch information directly from the issue tracker, interact with the user and provide information back to TortoiseSVN about open issues, verify log messages entered by the user and even run actions after a successful commit to e.g, close an issue.	9852
2162	9274	We can't provide information and tutorials on how you have to implement a COM object in your preferred programming language, but we have example plugins in C++/ATL and C# in our repository in the contrib/issue-tracker-plugins folder. In that folder you can also find the required include files you need to build your plugin. ( explains how to access the repository).	9856
2163	9278	You should provide both a 32-bit and 64-bit version of your plugin. Because the x64-Version of TortoiseSVN can not use a 32-bit plugin and vice-versa.	9860
2164	9282	The IBugtraqProvider interface	9864
2165	9286	TortoiseSVN 1.5 and later can use plugins which implement the IBugtraqProvider interface. The interface provides a few methods which plugins can use to interact with the issue tracker.	9868
2166	9290	\n HRESULT ValidateParameters (\n // Parent window for any UI that needs to be\n // displayed during validation.\n [in] HWND hParentWnd,\n \n // The parameter string that needs to be validated.\n [in] BSTR parameters,\n \n // Is the string valid?\n [out, retval] VARIANT_BOOL *valid\n );\n	9872
2167	9295	This method is called from the settings dialog where the user can add and configure the plugin. The parameters string can be used by a plugin to get additional required information, e.g., the URL to the issue tracker, login information, etc. The plugin should verify the parameters string and show an error dialog if the string is not valid. The hParentWnd parameter should be used for any dialog the plugin shows as the parent window. The plugin must return TRUE if the validation of the parameters string is successful. If the plugin returns FALSE, the settings dialog won't allow the user to add the plugin to a working copy path.	9889
2168	9299	\n HRESULT GetLinkText (\n // Parent window for any (error) UI that needs to be displayed.\n [in] HWND hParentWnd,\n \n // The parameter string, just in case you need to talk to your\n // web service (e.g.) to find out what the correct text is.\n [in] BSTR parameters,\n \n // What text do you want to display?\n // Use the current thread locale.\n [out, retval] BSTR *linkText\n );\n	9893
2169	9304	The plugin can provide a string here which is used in the TortoiseSVN commit dialog for the button which invokes the plugin, e.g., \"Choose issue\" or \"Select ticket\". Make sure the string is not too long, otherwise it might not fit into the button. If the method returns an error (e.g., E_NOTIMPL), a default text is used for the button.	9911
2170	9308	\n HRESULT GetCommitMessage (\n // Parent window for your provider's UI.\n [in] HWND hParentWnd,\n \n // Parameters for your provider.\n [in] BSTR parameters,\n [in] BSTR commonRoot,\n [in] SAFEARRAY(BSTR) pathList,\n \n // The text already present in the commit message.\n // Your provider should include this text in the new message,\n // where appropriate.\n [in] BSTR originalMessage,\n \n // The new text for the commit message.\n // This replaces the original message.\n [out, retval] BSTR *newMessage\n );\n	9915
2171	9313	This is the main method of the plugin. This method is called from the TortoiseSVN commit dialog when the user clicks on the plugin button.	9939
2172	9317	The parameters string is the string the user has to enter in the settings dialog when he configures the plugin. Usually a plugin would use this to find the URL of the issue tracker and/or login information or more.	9943
2173	9321	The commonRoot string contains the parent path of all items selected to bring up the commit dialog. Note that this is not the root path of all items which the user has selected in the commit dialog. For the branch/tag dialog, this is the path which is to be copied.	9947
2174	9325	The pathList parameter contains an array of paths (as strings) which the user has selected for the commit.	9951
2175	9329	The originalMessage parameter contains the text entered in the log message box in the commit dialog. If the user has not yet entered any text, this string will be empty.	9955
2176	9333	The newMessage return string is copied into the log message edit box in the commit dialog, replacing whatever is already there. If a plugin does not modify the originalMessage string, it must return the same string again here, otherwise any text the user has entered will be lost.	9959
2177	9337	The IBugtraqProvider2 interface	9963
2178	9341	In TortoiseSVN 1.6 a new interface was added which provides more functionality for plugins. This IBugtraqProvider2 interface inherits from IBugtraqProvider.	9967
2179	9345	\n HRESULT GetCommitMessage2 (\n // Parent window for your provider's UI.\n [in] HWND hParentWnd,\n \n // Parameters for your provider.\n [in] BSTR parameters,\n // The common URL of the commit\n [in] BSTR commonURL,\n [in] BSTR commonRoot,\n [in] SAFEARRAY(BSTR) pathList,\n \n // The text already present in the commit message.\n // Your provider should include this text in the new message,\n // where appropriate.\n [in] BSTR originalMessage,\n \n // You can assign custom revision properties to a commit\n // by setting the next two params.\n // note: Both safearrays must be of the same length.\n // For every property name there must be a property value!\n \n // The content of the bugID field (if shown)\n [in] BSTR bugID,\n \n // Modified content of the bugID field\n [out] BSTR * bugIDOut,\n \n // The list of revision property names.\n [out] SAFEARRAY(BSTR) * revPropNames,\n \n // The list of revision property values.\n [out] SAFEARRAY(BSTR) * revPropValues,\n \n // The new text for the commit message.\n // This replaces the original message\n [out, retval] BSTR * newMessage\n );\n	9971
2180	9350	This method is called from the TortoiseSVN commit dialog when the user clicks on the plugin button. This method is called instead of GetCommitMessage(). Please refer to the documentation for GetCommitMessage for the parameters that are also used there.	10014
2181	9354	The parameter commonURL is the parent URL of all items selected to bring up the commit dialog. This is basically the URL of the commonRoot path.	10018
2182	9358	The parameter bugID contains the content of the bug-ID field (if it is shown, configured with the property bugtraq:message).	10022
2183	9362	The return parameter bugIDOut is used to fill the bug-ID field when the method returns.	10026
2184	9366	The revPropNames and revPropValues return parameters can contain name/value pairs for revision properties that the commit should set. A plugin must make sure that both arrays have the same size on return! Each property name in revPropNames must also have a corresponding value in revPropValues. If no revision properties are to be set, the plugin must return empty arrays.	10030
2185	9370	\n HRESULT CheckCommit (\n [in] HWND hParentWnd,\n [in] BSTR parameters,\n [in] BSTR commonURL,\n [in] BSTR commonRoot,\n [in] SAFEARRAY(BSTR) pathList,\n [in] BSTR commitMessage,\n [out, retval] BSTR * errorMessage\n );\n	10034
2186	9375	This method is called right before the commit dialog is closed and the commit begins. A plugin can use this method to validate the selected files/folders for the commit and/or the commit message entered by the user. The parameters are the same as for GetCommitMessage2(), with the difference that commonURL is now the common URL of all checked items, and commonRoot the root path of all checked items.	10049
2187	9379	For the branch/tag dialog, the commonURL is the source URL of the copy, and commonRoot is set to the target URL of the copy.	10053
2188	9383	The return parameter errorMessage must either contain an error message which TortoiseSVN shows to the user or be empty for the commit to start. If an error message is returned, TortoiseSVN shows the error string in a dialog and keeps the commit dialog open so the user can correct whatever is wrong. A plugin should therefore return an error string which informs the user what is wrong and how to correct it.	10057
2189	9387	\n HRESULT OnCommitFinished (\n // Parent window for any (error) UI that needs to be displayed.\n [in] HWND hParentWnd,\n \n // The common root of all paths that got committed.\n [in] BSTR commonRoot,\n \n // All the paths that got committed.\n [in] SAFEARRAY(BSTR) pathList,\n \n \n // The text already present in the commit message.\n [in] BSTR logMessage,\n \n // The revision of the commit.\n [in] ULONG revision,\n \n \n // An error to show to the user if this function\n // returns something else than S_OK\n [out, retval] BSTR * error\n );\n	10061
2190	9392	This method is called after a successful commit. A plugin can use this method to e.g., close the selected issue or add information about the commit to the issue. The parameters are the same as for GetCommitMessage2.	10089
2191	9396	\n HRESULT HasOptions(\n // Whether the provider provides options\n [out, retval] VARIANT_BOOL *ret\n );\n	10093
2192	9401	This method is called from the settings dialog where the user can configure the plugins. If a plugin provides its own configuration dialog with ShowOptionsDialog, it must return TRUE here, otherwise it must return FALSE.	10103
2193	9405	\n HRESULT ShowOptionsDialog(\n // Parent window for the options dialog\n [in] HWND hParentWnd,\n \n // Parameters for your provider.\n [in] BSTR parameters,\n \n // The parameters string\n [out, retval] BSTR * newparameters\n );\n	10107
2194	9410	This method is called from the settings dialog when the user clicks on the \"Options\" button that is shown if HasOptions returns TRUE. A plugin can show an options dialog to make it easier for the user to configure the plugin.	10123
2195	9414	The parameters string contains the plugin parameters string that is already set/entered.	10127
2196	9418	The newparameters return parameter must contain the parameters string which the plugin constructed from the info it gathered in its options dialog. That paramameters string is passed to all other IBugtraqProvider and IBugtraqProvider2 methods.	10131
2197	9422	Frequently Asked Questions (FAQ)	10135
2198	9426	FAQ	10139
2199	9430	Because TortoiseSVN is being developed all the time it is sometimes hard to keep the documentation completely up to date. We maintain an online FAQ which contains a selection of the questions we are asked the most on the TortoiseSVN mailing lists dev@tortoisesvn.tigris.org and users@tortoisesvn.tigris.org.	10143
2200	9434	We also maintain a project Issue Tracker which tells you about some of the things we have on our To-Do list, and bugs which have already been fixed. If you think you have found a bug, or want to request a new feature, check here first to see if someone else got there before you.	10147
2201	9438	users@tortoisesvn.tigris.org is the one to use if you have questions about using TortoiseSVN.	10151
2202	9442	If you want to help out with the development of TortoiseSVN, then you should take part in discussions on dev@tortoisesvn.tigris.org.	10155
2203	9446	If you want to help with the translation of the TortoiseSVN user interface or the documentation, send an e-mail to translators@tortoisesvn.tigris.org.	10159
2204	9450	If you have a question which is not answered anywhere else, the best place to ask it is on one of the mailing lists:	10163
2205	9454	How Do I...	10167
2206	9458	This appendix contains solutions to problems/questions you might have when using TortoiseSVN.	10171
2207	9462	Move/copy a lot of files at once	10175
2208	9466	moving	10179
2209	9470	reorganize	10183
2210	9474	Moving/Copying single files can be done by using TortoiseSVNRename.... But if you want to move/copy a lot of files, this way is just too slow and too much work.	10187
2211	9478	The recommended way is by right-dragging the files to the new location. Simply right-click on the files you want to move/copy without releasing the mouse button. Then drag the files to the new location and release the mouse button. A context menu will appear where you can either choose Context MenuSVN Copy versioned files here. or Context MenuSVN Move versioned files here.	10191
2212	9482	Force users to enter a log message	10195
2213	9486	log message	10199
2214	9490	commit message	10203
2215	9494	empty message	10207
2216	9498	There are two ways to prevent users from committing with an empty log message. One is specific to TortoiseSVN, the other works for all Subversion clients, but requires access to the server directly.	10211
2217	9502	Hook-script on the server	10215
2218	9506	If you have direct access to the repository server, you can install a pre-commit hook script which rejects all commits with an empty or too short log message.	10219
2219	9510	In the repository folder on the server, there's a sub-folder hooks which contains some example hook scripts you can use. The file pre-commit.tmpl contains a sample script which will reject commits if no log message is supplied, or the message is too short. The file also contains comments on how to install/use this script. Just follow the instructions in that file.	10223
2220	9514	This method is the recommended way if your users also use other Subversion clients than TortoiseSVN. The drawback is that the commit is rejected by the server and therefore users will get an error message. The client can't know before the commit that it will be rejected. If you want to make TortoiseSVN have the OK button disabled until the log message is long enough then please use the method described below.	10227
2221	9518	Project properties	10231
2222	9522	TortoiseSVN uses properties to control some of its features. One of those properties is the tsvn:logminsize property.	10235
2223	9526	If you set that property on a folder, then TortoiseSVN will disable the OK button in all commit dialogs until the user has entered a log message with at least the length specified in the property.	10239
2224	9530	For detailed information on those project properties, please refer to	10243
2225	9534	Update selected files from the repository	10247
2226	9538	Normally you update your working copy using TortoiseSVNUpdate. But if you only want to pick up some new files that a colleague has added without merging in any changes to other files at the same time, you need a different approach.	10251
2227	9542	Use TortoiseSVNCheck for Modifications. and click on Check repository to see what has changed in the repository. Select the files you want to update locally, then use the context menu to update just those files.	10255
2228	9546	Roll back (Undo) revisions in the repository	10259
2229	9550	rollback	10263
2230	9554	undo commit	10267
2231	9558	undo change	10271
2232	9562	Use the revision log dialog	10275
2233	9566	The easiest way to revert the changes from a single revision, or from a range of revisions, is to use the revision log dialog. This is also the method to use of you want to discard recent changes and make an earlier revision the new HEAD.	10279
2234	9570	Select the file or folder in which you need to revert the changes. If you want to revert all changes, this should be the top level folder.	10283
2235	9574	Select TortoiseSVNShow Log to display a list of revisions. You may need to use Show All or Next 100 to show the revision(s) you are interested in.	10287
2236	9578	Select the revision you wish to revert. If you want to undo a range of revisions, select the first one and hold the Shift key while selecting the last one. Note that for multiple revisions, the range must be unbroken with no gaps. Right click on the selected revision(s), then select Context MenuRevert changes from this revision.	10291
2237	9582	Or if you want to make an earlier revision the new HEAD revision, right click on the selected revision, then select Context MenuRevert to this revision. This will discard all changes after the selected revision.	10295
2238	9587	You have reverted the changes within your working copy. Check the results, then commit the changes.	10300
2239	9591	Use the merge dialog	10304
2240	9595	To undo a larger range of revisions, you can use the Merge dialog. The previous method uses merging behind the scenes; this method uses it explicitly.	10308
2241	9599	In your working copy select TortoiseSVNMerge.	10312
2242	9603	In the From: field enter the full folder URL of the branch or tag containing the changes you want to revert in your working copy. This should come up as the default URL.	10316
2243	9607	In the From Revision field enter the revision number that you are currently at. If you are sure there is no-one else making changes, you can use the HEAD revision.	10320
2244	9611	make sure the Use \"From:\" URL checkbox is checked.	10324
2245	9615	In the To Revision field enter the revision number that you want to revert to, namely the one before the first revision to be reverted.	10328
2246	9619	Click OK to complete the merge.	10332
2247	9623	Use svndumpfilter	10336
2248	9627	Since TortoiseSVN never loses data, your rolled back revisions still exist as intermediate revisions in the repository. Only the HEAD revision was changed to a previous state. If you want to make revisions disappear completely from your repository, erasing all trace that they ever existed, you have to use more extreme measures. Unless there is a really good reason to do this, it is not recommended. One possible reason would be that someone committed a confidential document to a public repository.	10340
2249	9631	The only way to remove data from the repository is to use the Subversion command line tool svnadmin. You can find a description of how this works in the Repository Maintenance.	10344
2250	9635	Compare two revisions of a file or folder	10348
2251	9639	compare files	10352
2252	9643	compare folders	10356
2253	9647	changes	10360
2254	9651	If you want to compare two revisions in an item's history, for example revisions 100 and 200 of the same file, just use TortoiseSVNShow Log to list the revision history for that file. Pick the two revisions you want to compare then use Context MenuCompare Revisions.	10364
2255	9655	If you want to compare the same item in two different trees, for example the trunk and a branch, you can use the repository browser to open up both trees, select the file in both places, then use Context MenuCompare Revisions.	10368
2256	9659	If you want to compare two trees to see what has changed, for example the trunk and a tagged release, you can use TortoiseSVNRevision Graph Select the two nodes to compare, then use Context MenuCompare HEAD Revisions. This will show a list of changed files, and you can then select individual files to view the changes in detail. You can also export a tree structure containing all the changed files, or simply a list of all changed files. Read for more information. Alternatively use Context MenuUnified Diff of HEAD Revisions to see a summary of all differences, with minimal context.	10372
2257	9663	Include a common sub-project	10376
2258	9667	common projects	10380
2259	9671	vendor projects	10384
2260	9675	Sometimes you will want to include another project within your working copy, perhaps some library code. You don't want to make a duplicate of this code in your repository because then you would lose connection with the original (and maintained) code. Or maybe you have several projects which share core code. There are at least 3 ways of dealing with this.	10388
2261	9679	Use svn:externals	10392
2262	9683	Set the svn:externals property for a folder in your project. This property consists of one or more lines; each line has the name of a sub-folder which you want to use as the checkout folder for common code, and the repository URL that you want to be checked out there. For full details refer to .	10396
2263	9687	Commit the new folder. Now when you update, Subversion will pull a copy of that project from its repository into your working copy. The sub-folders will be created automatically if required. Each time you update your main working copy, you will also receive the latest version of all external projects.	10400
2264	9691	Of the three methods described, this is the only one which needs no setup on the client side. Once externals are specified in the folder properties, all clients will get populated folders when they update.	10404
2265	9695	Use a nested working copy	10408
2266	9699	Create a new folder within your project to contain the common code, but do not add it to Subversion	10412
2267	9703	Select TortoiseSVNCheckout for the new folder and checkout a copy of the common code into it. You now have a separate working copy nested within your main working copy.	10416
2268	9707	The two working copies are independent. When you commit changes to the parent, changes to the nested WC are ignored. Likewise when you update the parent, the nested WC is not updated.	10420
2269	9711	Use a relative location	10424
2270	9715	If you use the same common core code in several projects, and you do not want to keep multiple working copies of it for every project that uses it, you can just check it out to a separate location which is related to all the other projects which use it. For example: \n C:\\Projects\\Proj1\n C:\\Projects\\Proj2\n C:\\Projects\\Proj3\n C:\\Projects\\Common\n and refer to the common code using a relative path, eg. ..\\..\\Common\\DSPcore.	10428
2271	9719	If your projects are scattered in unrelated locations you can use a variant of this, which is to put the common code in one location and use drive letter substitution to map that location to something you can hard code in your projects, eg. Checkout the common code to D:\\Documents\\Framework or C:\\Documents and Settings\\{login}\\My Documents\\framework then use \n SUBST X: \"D:\\Documents\\framework\"\n to create the drive mapping used in your source code. Your code can then use absolute locations. \n #include \"X:\\superio\\superio.h\"\n	10438
2272	9723	This method will only work in an all-PC environment, and you will need to document the required drive mappings so your team know where these mysterious files are. This method is strictly for use in closed development environments, and not recommended for general use.	10447
2273	9727	Create a shortcut to a repository	10451
2274	9731	shortcut	10455
2275	9735	If you frequently need to open the repository browser at a particular location, you can create a desktop shortcut using the automation interface to TortoiseProc. Just create a new shortcut and set the target to: \n TortoiseProc.exe /command:repobrowser /path:\"url/to/repository\"\n Of course you need to include the real repository URL.	10459
2276	9739	Ignore files which are already versioned	10466
2277	9743	remove versioning	10470
2278	9747	detach from repository	10474
2279	9751	If you accidentally added some files which should have been ignored, how do you get them out of version control without losing them? Maybe you have your own IDE configuration file which is not part of the project, but which took you a long time to set up just the way you like it.	10478
2280	9755	If you have not yet committed the add, then all you have to do is use TortoiseSVNRevert... to undo the add. You should then add the file(s) to the ignore list so they don't get added again later by mistake.	10482
2281	9759	If the files are already in the repository, they have to be deleted from the repository and added to the ignore list. Fortunately TortoiseSVN has a convenient shortcut for doing this. TortoiseSVNUnversion and add to ignore list will first mark the file/folder for deletion from the repository, keeping the local copy. It also adds this item to the ignore list so that it will not be added back into Subversion again by mistake. Once this is done you just need to commit the parent folder.	10486
2282	9763	Unversion a working copy	10490
2283	9767	If you have a working copy which you want to convert back to a plain folder tree without the .svn directories, you can simply export it to itself. Read to find out how.	10494
2284	9771	Remove a working copy	10498
2285	9775	If you have a working copy which you no longer need, how do you get rid of it cleanly? Easy - just delete it in Windows Explorer! Working copies are private local entities, and they are self-contained.	10502
2286	9779	Useful Tips For Administrators	10506
2287	9783	This appendix contains solutions to problems/questions you might have when you are responsible for deploying TortoiseSVN to multiple client computers.	10510
2288	9787	Deploy TortoiseSVN via group policies	10514
2289	9792	group policies	10519
2290	9805	domain controller	10532
2291	9809	deploy	10536
2292	9813	The TortoiseSVN installer comes as an MSI file, which means you should have no problems adding that MSI file to the group policies of your domain controller.	10540
2293	9817	A good walk-through on how to do that can be found in the knowledge base article 314934 from Microsoft: http://support.microsoft.com/?kbid=314934.	10544
2294	9821	Versions 1.3.0 and later of TortoiseSVN must be installed under Computer Configuration and not under User Configuration. This is because those versions need the new CRT and MFC DLLs, which can only be deployed per computer and not per user. If you really must install TortoiseSVN on a per user basis, then you must first install the MFC and CRT package version 8 from Microsoft on each computer you want to install TortoiseSVN as per user.	10548
2295	9825	Redirect the upgrade check	10552
2296	9829	upgrade check	10556
2297	9833	check new version	10560
2298	9837	version	10564
2299	9841	TortoiseSVN checks if there's a new version available every few days. If there is a newer version available, a dialog shows up informing the user about that.	10568
2300	9845	The upgrade dialog	10572
2301	9849	If you're responsible for a lot of users in your domain, you might want your users to use only versions you have approved and not have them install always the latest version. You probably don't want that upgrade dialog to show up so your users don't go and upgrade immediately.	10576
2302	9853	Versions 1.4.0 and later of TortoiseSVN allow you to redirect that upgrade check to your intranet server. You can set the registry key HKCU\\Software\\TortoiseSVN\\UpdateCheckURL (string value) to an URL pointing to a text file in your intranet. That text file must have the following format: \n 1.4.1.6000\n A new version of TortoiseSVN is available for you to download!\n http://192.168.2.1/downloads/TortoiseSVN-1.4.1.6000-svn-1.4.0.msi\n The first line in that file is the version string. You must make sure that it matches the exact version string of the TortoiseSVN installation package. The second line is a custom text, shown in the upgrade dialog. You can write there whatever you want. Just note that the space in the upgrade dialog is limited. Too long messages will get truncated! The third line is the URL to the new installation package. This URL is opened when the user clicks on the custom message label in the upgrade dialog. You can also just point the user to a web page instead of the MSI file directly. The URL is opened with the default web browser, so if you specify a web page, that page is opened and shown to the user. If you specify the MSI package, the browser will ask the user to save the MSI file locally.	10580
2303	9857	Setting the SVN_ASP_DOT_NET_HACK environment variable	10589
2304	9869	ASP projects	10601
2305	9873	As of version 1.4.0 and later, the TortoiseSVN installer doesn't provide the user with the option to set the SVN_ASP_DOT_NET_HACK environment variable anymore, since that caused many problems and confusion for users who always install everything no matter whether they know what it is for.	10605
2306	9877	But that option is only hidden for the user. You still can force the TortoiseSVN installer to set that environment variable by setting the ASPDOTNETHACK property to TRUE. For example, you can start the installer like this: \n msiexec /i TortoiseSVN-1.4.0.msi ASPDOTNETHACK=TRUE\n	10609
2307	9881	Disable context menu entries	10616
2308	9885	context menu entries	10620
2309	9889	disable functions	10624
2310	9893	As of version 1.5.0 and later, TortoiseSVN allows you to disable (actually, hide) context menu entries. Since this is a feature which should not be used lightly but only if there is a compelling reason, there is no GUI for this and it has to be done directly in the registry. This can be used to disable certain commands for users who should not use them. But please note that only the context menu entries in the explorer are hidden, and the commands are still available through other means, e.g. the command line or even other dialogs in TortoiseSVN itself!	10628
2311	9897	The registry keys which hold the information on which context menus to show are HKEY_CURRENT_USER\\Software\\TortoiseSVN\\ContextMenuEntriesMaskLow and HKEY_CURRENT_USER\\Software\\TortoiseSVN\\ContextMenuEntriesMaskHigh.	10632
2312	9901	Each of these registry entries is a DWORD value, with each bit corresponding to a specific menu entry. A set bit means the corresponding menu entry is deactivated.	10636
2313	9905	Menu entries and their values	10640
2314	9909	Value	10644
2315	9913	Menu entry	10648
2316	9919	Checkout	10654
2317	9925	Update	10660
2318	9931	Commit	10666
2319	9937	Add	10672
2320	9943	Revert	10678
2321	9948	Resolve	10683
2322	9954	Export	10689
2323	9958	Create Repository here	10693
2324	9963	Branch/Tag	10698
2325	9969	Merge	10704
2326	9975	Delete	10710
2327	9980	Rename	10715
2328	9984	Update to revision	10719
2329	9990	Diff	10725
2330	9995	Show Log	10730
2331	10000	Edit Conflicts	10735
2332	10006	Relocate	10741
2333	10010	Check for modifications	10745
2334	10014	Ignore	10749
2335	10018	Repository Browser	10753
2336	10024	Blame	10759
2337	10029	Create Patch	10764
2338	10034	Apply Patch	10769
2339	10038	Revision graph	10773
2340	10043	Lock	10778
2341	10047	Remove Lock	10782
2342	10051	Properties	10786
2343	10055	Diff with URL	10790
2344	10059	Delete unversioned items	10794
2345	10063	Settings	10798
2346	10075	Example: to disable the Relocate the Delete unversioned items and the Settings menu entries, add the values assigned to the entries like this: \n 0x0000000000080000\n + 0x0000000080000000\n + 0x2000000000000000\n = 0x2000000080080000\n The lower DWORD value (0x80080000) must then be stored in HKEY_CURRENT_USER\\Software\\TortoiseSVN\\ContextMenuEntriesMaskLow, the higher DWORD value (0x20000000) in HKEY_CURRENT_USER\\Software\\TortoiseSVN\\ContextMenuEntriesMaskHigh.	10810
2347	10079	To enable the menu entries again, simply delete the two registry keys.	10820
2348	10083	Automating TortoiseSVN	10824
2349	10087	Since all commands for TortoiseSVN are controlled through command line parameters, you can automate it with batch scripts or start specific commands and dialogs from other programs (e.g. your favourite text editor).	10828
2350	10091	Remember that TortoiseSVN is a GUI client, and this automation guide shows you how to make the TortoiseSVN dialogs appear to collect user input. If you want to write a script which requires no input, you should use the official Subversion command line client instead.	10832
2351	10096	TortoiseSVN Commands	10837
2352	10102	automation	10843
2353	10107	command line	10848
2354	10111	The TortoiseSVN GUI program is called TortoiseProc.exe. All commands are specified with the parameter /command:abcd where abcd is the required command name. Most of these commands need at least one path argument, which is given with /path:\"some\\path\". In the following table the command refers to the /command:abcd parameter and the path refers to the /path:\"some\\path\" parameter.	10852
2355	10115	Since some of the commands can take a list of target paths (e.g. committing several specific files) the /path parameter can take several paths, separated by a * character.	10856
2356	10119	TortoiseSVN uses temporary files to pass multiple arguments between the shell extension and the main program. From TortoiseSVN 1.5.0 on and later, /notempfile parameter is obsolete and there is no need to add it anymore.	10860
2357	10123	You can also specify a file which contains a list of paths, separated by newlines. The file must be in UTF-16 format. If you pass such a file, use /pathfile instead of /path. To have TortoiseProc delete that file after the command is finished, you can pass the parameter /deletepathfile.	10864
2358	10127	The progress dialog which is used for commits, updates and many more commands usually stays open after the command has finished until the user presses the OK button. This can be changed by checking the corresponding option in the settings dialog. But using that setting will close the progress dialog, no matter if you start the command from your batch file or from the TortoiseSVN context menu.	10868
2359	10131	To specify a different location of the configuration file, use the parameter /configdir:\"path\\to\\config\\directory\". This will override the default path, including any registry setting.	10872
2360	10135	/closeonend:0 don't close the dialog automatically	10876
2361	10139	/closeonend:1 auto close if no errors	10880
2362	10143	/closeonend:2 auto close if no errors and conflicts	10884
2363	10147	/closeonend:3 auto close if no errors, conflicts and merges	10888
2364	10151	To close the progress dialog at the end of a command automatically without using the permanent setting you can pass the /closeonend parameter. To close the progress dialog for local operations if there were no errors or conflicts, pass the /closeforlocal parameter.	10892
2365	10155	The table below lists all the commands which can be accessed using the TortoiseProc.exe command line. As described above, these should be used in the form /command:abcd. In the table, the /command prefix is omitted to save space.	10896
2366	10159	List of available commands and options	10900
2367	10163	Command	10904
2368	10167	Shows the about dialog. This is also shown if no command is given.	10908
2369	10222	/findstring:\"filterstring\"	10963
2370	10238	/findtype:1 filter by everything	10979
2371	10242	/findtype:2 filter by messages	10983
2372	10246	/findtype:3 filter by path	10987
2373	10250	/findtype:4 filter by authors	10991
2374	10254	/findtype:5 filter by revisions	10995
2375	10258	/findtype:7 filter by bug ID	10999
2376	10262	Opens the log dialog. The specifies the file or folder for which the log should be shown. Six additional options can be set: , , enables the 'stop-on-copy' checkbox, fills in the filter text, forces the filter to use text, not regex, or forces the filter to use regex, not simple text search, and with X being a number between 1 and 7. The numbers correspond to:	11003
2377	10271	Opens the checkout dialog. The specifies the target directory and the specifies the URL to checkout from.	11012
2378	10275	Opens the import dialog. The specifies the directory with the data to import.	11016
2379	10299	Updates the working copy in to HEAD. If the option is given then a dialog is shown to ask the user to which revision the update should go. To avoid the dialog specify a revision number . Other options are , and .	11040
2380	10314	path	11055
2381	10318	/bugid:\"the bug id here\"	11059
2382	10322	Opens the commit dialog. The specifies the target directory or the list of files to commit. You can also specify the switch to pass a predefined log message to the commit dialog. Or, if you don't want to pass the log message on the command line, use , where points to a file containing the log message. To pre-fill the bug ID box (in case you've set up integration with bug trackers properly), you can use the to do that.	11063
2383	10326	Adds the files in to version control.	11067
2384	10330	Reverts local modifications of a working copy. The tells which items to revert.	11071
2385	10338	Cleans up interrupted or aborted operations and unlocks the working copy in . Use to prevent the result dialog from popping up (either telling about the cleanup being finished or showing an error message).	11079
2386	10348	Marks a conflicted file specified in as resolved. If is given, then resolving is done without asking the user first if it really should be done.	11089
2387	10352	Creates a repository in	11093
2388	10356	Opens the switch dialog. The specifies the target directory.	11097
2389	10360	Exports the working copy in to another directory. If the points to an unversioned directory, a dialog will ask for an URL to export to the directory in .	11101
2390	10385	Opens the merge dialog. The specifies the target directory. For merging a revision range, the following options are available: , . For merging two repository trees, the following options are available: , , and . These pre-fill the relevant fields in the merge dialog.	11126
2391	10389	Opens the merge all dialog. The specifies the target directory.	11130
2392	10393	Brings up the branch/tag dialog. The is the working copy to branch/tag from. And the is the target URL. You can also specify the switch to pass a predefined log message to the branch/tag dialog. Or, if you don't want to pass the log message on the command line, use , where points to a file containing the log message.	11134
2393	10397	Opens the settings dialog.	11138
2394	10401	Removes the file(s) in from version control.	11142
2395	10405	Renames the file in . The new name for the file is asked with a dialog. To avoid the question about renaming similar files in one step, pass .	11146
2396	10423	Starts the external diff program specified in the TortoiseSVN settings. The specifies the first file. If the option is set, then the diff program is started with those two files. If is omitted, then the diff is done between the file in and its BASE. To explicitly set the revision numbers use and . If is set and is not set, then the diff is done by first blaming the files with the given revisions. The parameter specifies the line to jump to when the diff is shown.	11164
2397	10427	Depending on the URLs and revisions to compare, this either shows a unified diff (if the option unified is set), a dialog with a list of files that have changed or if the URLs point to files starts the diff viewer for those two files.	11168
2398	10431	The options url1, url2, revision1 and revision2 must be specified. The options pegrevision, ignoreancestry, blame and unified are optional.	11172
2399	10435	Starts the conflict editor specified in the TortoiseSVN settings with the correct files for the conflicted file in .	11176
2400	10439	Opens the relocate dialog. The specifies the working copy path to relocate.	11180
2401	10443	Opens the help file.	11184
2402	10451	Check repository	11192
2403	10455	Opens the check-for-modifications dialog. The specifies the working copy directory. If is specified, the dialog contacts the repository immediately on startup, as if the user clicked on the button.	11196
2404	10464	/projectpropertiespath:path/to/wc	11205
2405	10468	Starts the repository browser dialog, pointing to the URL of the working copy given in or points directly to an URL. An additional option can be used to specify the revision which the repository browser should show. If the is omitted, it defaults to HEAD. If points to an URL, the specifies the path from where to read and use the project properties.	11209
2406	10476	Adds all targets in to the ignore list, i.e. adds the property to those files.	11217
2407	10480	Opens the blame dialog for the file specified in /path.	11221
2408	10484	If the options /startrev and /endrev are set, then the dialog asking for the blame range is not shown but the revision values of those options are used instead.	11225
2409	10488	If the option /line:nnn is set, TortoiseBlame will open with the specified line number showing.	11229
2410	10492	The options /ignoreeol, /ignorespaces and /ignoreallspaces are also supported.	11233
2411	10496	/savepath:path	11237
2412	10504	Saves a file from an URL or working copy path given in to the location given in . The revision is given in . This can be used to get a file with a specific revision.	11245
2413	10508	Creates a patch file for the path given in .	11249
2414	10512	Shows the revision graph for the path given in .	11253
2415	10516	Locks a file or all files in a directory given in . The 'lock' dialog is shown so the user can enter a comment for the lock.	11257
2416	10520	Unlocks a file or all files in a directory given in .	11261
2417	10524	Rebuilds the windows icon cache. Only use this in case the windows icons are corrupted. A side effect of this (which can't be avoided) is that the icons on the desktop get rearranged. To suppress the message box, pass .	11265
2418	10528	Shows the properties dialog for the path given in .	11269
2419	10532	Examples (which should be entered on one line): \n TortoiseProc.exe /command:commit\n /path:\"c:\\svn_wc\\file1.txt*c:\\svn_wc\\file2.txt\"\n /logmsg:\"test log message\" /closeonend:0\n \n TortoiseProc.exe /command:update /path:\"c:\\svn_wc\\\" /closeonend:0\n \n TortoiseProc.exe /command:log /path:\"c:\\svn_wc\\file1.txt\"\n /startrev:50 /endrev:60 /closeonend:0\n	11273
2420	10536	Tsvncmd URL handler	11287
2421	10540	URL handler	11291
2422	10544	Using special URLs, it is also possible to call TortoiseProc from a web page.	11295
2423	10548	TortoiseSVN registers a new protocol tsvncmd: which can be used to create hyperlinks that execute TortoiseSVN commands. The commands and parameters are the same as when automating TortoiseSVN from the command line.	11299
2424	10552	The format of the tsvncmd: URL is like this:	11303
2425	10556	tsvncmd:command:cmd?parameter:paramvalue?parameter:paramvalue	11307
2426	10560	with cmd being one of the allowed commands and with parameter being a parameter like path or revision, depending on the command used.	11311
2427	10564	The following commands are allowed with tsvncmd: URLs:	11315
2428	10568	\n <a href=\"tsvncmd:command:showcompare?\n url1:https://stexbar.googlecode.com/svn/trunk/StExBar/src/setup/Setup.wxs?\n url2:https://stexbar.googlecode.com/svn/trunk/StExBar/src/setup/Setup.wxs?\n revision1:188?revision2:189\">compare</a>\n	11319
2429	10573	An example URL might look like this:	11329
2430	10577	TortoiseIDiff Commands	11333
2431	10581	The image diff tool has a few command line options which you can use to control how the tool is started. The program is called TortoiseIDiff.exe.	11337
2432	10585	The table below lists all the options which can be passed to the image diff tool on the command line.	11341
2433	10589	List of available options	11345
2434	10593	Option	11349
2435	10597	Path to the file shown on the left.	11353
2436	10602	A title string. This string is used in the image view title instead of the full path to the image file.	11358
2437	10606	Path to the file shown on the right.	11362
2438	10610	If specified, the image diff tool switches to the overlay mode (alpha blend).	11366
2439	10614	If specified, the image diff tool fits both images together.	11370
2440	10618	Shows the image info box.	11374
2441	10622	Example (which should be entered on one line): \n TortoiseIDiff.exe /left:\"c:\\images\\img1.jpg\" /lefttitle:\"image 1\"\n /right:\"c:\\images\\img2.jpg\" /righttitle:\"image 2\"\n /fit /overlay\n	11378
2442	10626	Command Line Interface Cross Reference	11387
2443	10630	command line client	11391
2444	10642	Even though there are CLI equivalents to what TortoiseSVN does, remember that TortoiseSVN does not call the CLI but uses the Subversion library directly.	11403
2445	10646	If you think you have found a bug in TortoiseSVN, we may ask you to try to reproduce it using the CLI, so that we can distinguish TortoiseSVN issues from Subversion issues. This reference tells you which command to try.	11407
2446	10650	Conventions and Basic Rules	11411
2447	10654	In the descriptions which follow, the URL for a repository location is shown simply as URL, and an example might be http://tortoisesvn.googlecode.com/svn/trunk/. The working copy path is shown simply as PATH, and an example might be C:\\TortoiseSVN\\trunk.	11415
2448	10658	Because TortoiseSVN is a Windows Shell Extension, it is not able to use the notion of a current working directory. All working copy paths must be given using the absolute path, not a relative path.	11419
2449	10662	Certain items are optional, and these are often controlled by checkboxes or radio buttons in TortoiseSVN. These options are shown in [square brackets] in the command line definitions.	11423
2450	10666	\n svn checkout [-depth ARG] [--ignore-externals] [-r rev] URL PATH\n	11427
2451	10672	The depth combo box items relate to the -depth argument.	11435
2452	10677	If Omit externals is checked, use the --ignore-externals switch.	11440
2453	10681	If you are checking out a specific revision, specify that after the URL using -r switch.	11444
2454	10685	\n svn info URL_of_WC\n svn update [-r rev] PATH\n	11448
2455	10690	Updating multiple items is currently not an atomic operation in Subversion. So TortoiseSVN first finds the HEAD revision of the repository, and then updates all items to that particular revision number to avoid creating a mixed revision working copy.	11456
2456	10694	If only one item is selected for updating or the selected items are not all from the same repository, TortoiseSVN just updates to HEAD.	11460
2457	10698	No command line options are used here. Update to revision also implements the update command, but offers more options.	11464
2458	10702	Update to Revision	11468
2459	10706	\n svn info URL_of_WC\n svn update [-r rev] [-depth ARG] [--ignore-externals] PATH\n	11472
2460	10711	In TortoiseSVN, the commit dialog uses several Subversion commands. The first stage is a status check which determines the items in your working copy which can potentially be committed. You can review the list, diff files against BASE and select the items you want to be included in the commit.	11480
2461	10717	\n svn status -v PATH\n	11486
2462	10723	If Show unversioned files is checked, TortoiseSVN will also show all unversioned files and folders in the working copy hierarchy, taking account of the ignore rules. This particular feature has no direct equivalent in Subversion, as the svn status command does not descend into unversioned folders.	11494
2463	10727	If you check any unversioned files and folders, those items will first be added to your working copy.	11498
2464	10732	\n svn add PATH...\n	11503
2465	10737	When you click on OK, the Subversion commit takes place. If you have left all the file selection checkboxes in their default state, TortoiseSVN uses a single recursive commit of the working copy. If you deselect some files, then a non-recursive commit (-N) must be used, and every path must be specified individually on the commit command line.	11510
2466	10741	\n svn commit -m \"LogMessage\" [-depth ARG] [--no-unlock] PATH...\n	11514
2467	10748	LogMessage here represents the contents of the log message edit box. This can be empty.	11523
2468	10752	If Keep locks is checked, use the --no-unlock switch.	11527
2469	10756	\n svn diff PATH\n	11531
2470	10761	If you use Diff from the main context menu, you are diffing a modified file against its BASE revision. The output from the CLI command above also does this and produces output in unified-diff format. However, this is not what TortoiseSVN is using. TortoiseSVN uses TortoiseMerge (or a diff program of your choosing) to display differences visually between full-text files, so there is no direct CLI equivalent.	11538
2471	10765	You can also diff any 2 files using TortoiseSVN, whether or not they are version controlled. TortoiseSVN just feeds the two files into the chosen diff program and lets it work out where the differences lie.	11542
2472	10769	\n svn log -v -r 0:N --limit 100 [--stop-on-copy] PATH\n or\n svn log -v -r M:N [--stop-on-copy] PATH\n	11546
2473	10774	By default, TortoiseSVN tries to fetch 100 log messages using the --limit method. If the settings instruct it to use old APIs, then the second form is used to fetch the log messages for 100 repository revisions.	11555
2474	10778	If Stop on copy/rename is checked, use the --stop-on-copy switch.	11559
2475	10782	\n svn status -v PATH\n or\n svn status -u -v PATH\n	11563
2476	10787	The initial status check looks only at your working copy. If you click on Check repository then the repository is also checked to see which files would be changed by an update, which requires the -u switch.	11572
2477	10791	Revision Graph	11576
2478	10795	The revision graph is a feature of TortoiseSVN only. There's no equivalent in the command line client.	11580
2479	10799	What TortoiseSVN does is an \n svn info URL_of_WC\n svn log -v URL\n where URL is the repository root and then analyzes the data returned.	11584
2480	10803	Repo Browser	11592
2481	10807	\n svn info URL_of_WC\n svn list [-r rev] -v URL\n	11596
2482	10812	You can use svn info to determine the repository root, which is the top level shown in the repository browser. You cannot navigate Up above this level. Also, this command returns all the locking information shown in the repository browser.	11604
2483	10816	The svn list call will list the contents of a directory, given a URL and revision.	11608
2484	10820	This command has no CLI equivalent. It invokes TortoiseMerge or an external 3-way diff/merge tool to look at the files involved in the conflict and sort out which lines to use.	11612
2485	10824	Resolved	11616
2486	10828	\n svn resolved PATH\n	11620
2487	10833	\n svn rename CURR_PATH NEW_PATH\n	11627
2488	10838	\n svn delete PATH\n	11634
2489	10843	The first stage is a status check which determines the items in your working copy which can potentially be reverted. You can review the list, diff files against BASE and select the items you want to be included in the revert.	11641
2490	10847	When you click on OK, the Subversion revert takes place. If you have left all the file selection checkboxes in their default state, TortoiseSVN uses a single recursive (-R) revert of the working copy. If you deselect some files, then every path must be specified individually on the revert command line.	11645
2491	10851	\n svn revert [-R] PATH...\n	11649
2492	10856	\n svn cleanup PATH\n	11656
2493	10861	Get Lock	11663
2494	10865	The first stage is a status check which determines the files in your working copy which can potentially be locked. You can select the items you want to be locked.	11667
2495	10869	\n svn lock -m \"LockMessage\" [--force] PATH...\n	11671
2496	10874	LockMessage here represents the contents of the lock message edit box. This can be empty.	11678
2497	10878	If Steal the locks is checked, use the --force switch.	11682
2498	10882	Release Lock	11686
2499	10886	\n svn unlock PATH\n	11690
2500	10891	\n svn copy -m \"LogMessage\" URL URL\n or\n svn copy -m \"LogMessage\" URL@rev URL@rev\n or\n svn copy -m \"LogMessage\" PATH URL\n	11697
2501	10896	Specific revision in repository	11708
2502	10900	The Branch/Tag dialog performs a copy to the repository. There are 3 radio button options: which correspond to the 3 command line variants above.	11712
2503	10904	\n svn info URL_of_WC\n svn switch [-r rev] URL PATH\n	11716
2504	10909	\n svn merge [--dry-run] --force From_URL@revN To_URL@revM PATH\n	11724
2505	10914	The Test Merge performs the same merge with the --dry-run switch.	11731
2506	10918	\n svn diff From_URL@revN To_URL@revM\n	11735
2507	10923	The Unified diff shows the diff operation which will be used to do the merge.	11742
2508	10927	\n svn export [-r rev] [--ignore-externals] URL Export_PATH\n	11746
2509	10932	This form is used when accessed from an unversioned folder, and the folder is used as the destination.	11753
2510	10936	Exporting a working copy to a different location is done without using the Subversion library, so there's no matching command line equivalent.	11757
2511	10940	What TortoiseSVN does is to copy all files to the new location while showing you the progress of the operation. Unversioned files/folders can optionally be exported too.	11761
2512	10944	In both cases, if Omit externals is checked, use the --ignore-externals switch.	11765
2513	10948	\n svn switch --relocate From_URL To_URL\n	11769
2514	10953	Create Repository Here	11776
2515	10957	\n svnadmin create --fs-type fsfs PATH\n	11780
2516	10962	If you selected a folder, TortoiseSVN first scans it recursively for items which can be added.	11787
2517	10966	\n svn import -m LogMessage PATH URL\n	11791
2518	10971	\n svn blame -r N:M -v PATH\n svn log -r N:M PATH\n	11798
2519	10976	If you use TortoiseBlame to view the blame info, the file log is also required to show log messages in a tooltip. If you view blame as a text file, this information is not required.	11806
2520	10980	Add to Ignore List	11810
2521	10984	\n svn propget svn:ignore PATH > tempfile\n {edit new ignore item into tempfile}\n svn propset svn:ignore -F tempfile PATH\n	11814
2522	10989	Because the svn:ignore property is often a multi-line value, it is shown here as being changed via a text file rather than directly on the command line.	11823
2523	10993	\n svn diff PATH > patch-file\n	11827
2524	10998	TortoiseSVN creates a patch file in unified diff format by comparing the working copy with its BASE version.	11834
2525	11002	Applying patches is a tricky business unless the patch and working copy are at the same revision. Luckily for you, you can use TortoiseMerge, which has no direct equivalent in Subversion.	11838
2526	11010	This appendix contains a more detailed discussion of the implementation of some of TortoiseSVN's features.	11846
2527	11014	overlay priority	11850
2528	11018	Every file and folder has a Subversion status value as reported by the Subversion library. In the command line client, these are represented by single letter codes, but in TortoiseSVN they are shown graphically using the icon overlays. Because the number of overlays is very limited, each overlay may represent one of several status values.	11854
2529	11022	The Conflicted overlay is used to represent the conflicted state, where an update or switch results in conflicts between local changes and changes downloaded from the repository. It is also used to indicate the obstructed state, which can occur when an operation is unable to complete.	11858
2530	11026	The Modified overlay represents the modified state, where you have made local modifications, the merged state, where changes from the repository have been merged with local changes, and the replaced state, where a file has been deleted and replaced by another different file with the same name.	11862
2531	11030	The Deleted overlay represents the deleted state, where an item is scheduled for deletion, or the missing state, where an item is not present. Naturally an item which is missing cannot have an overlay itself, but the parent folder can be marked if one of its child items is missing.	11866
2532	11034	The Added overlay is simply used to represent the added status when an item has been added to version control.	11870
2533	11038	The In Subversion overlay is used to represent an item which is in the normal state, or a versioned item whose state is not yet known. Because TortoiseSVN uses a background caching process to gather status, it may take a few seconds before the overlay updates.	11874
2534	11042	The Needs Lock overlay is used to indicate when a file has the svn:needs-lock property set. For working copies which were created using Subversion 1.4.0 and later, the svn:needs-lock status is cached locally by Subversion and this is used to determine when to show this overlay. For working copies which are in pre-1.4.x format, TortoiseSVN shows this overlay when the file has read-only status. Note that Subversion automatically upgrades working copies when you update them, although the caching of the svn:needs-lock property may not happen until the file itself is updated.	11878
2535	11046	The Locked overlay is used when the local working copy holds a lock for that file.	11882
2536	11050	The Ignored overlay is used to represent an item which is in the ignored state, either due to a global ignore pattern, or the svn:ignore property of the parent folder. This overlay is optional.	11886
2537	11054	The Unversioned overlay is used to represent an item which is in the unversioned state. This is an item in a versioned folder, but which is not under version control itself. This overlay is optional.	11890
2538	11058	If an item has subversion status none (the item is not within a working copy) then no overlay is shown. If you have chosen to disable the Ignored and Unversioned overlays then no overlay will be shown for those files either.	11894
2539	11062	An item can only have one Subversion status value. For example a file could be locally modified and it could be marked for deletion at the same time. Subversion returns a single status value - in this case deleted. Those priorities are defined within Subversion itself.	11898
2540	11066	When TortoiseSVN displays the status recursively (the default setting), each folder displays an overlay reflecting its own status and the status of all its children. In order to display a single summary overlay, we use the priority order shown above to determine which overlay to use, with the Conflicted overlay taking highest priority.	11902
2541	11070	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 limited to 15. Windows uses 4 of those, and the remaining 11 can be used by other applications. If 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.	11906
2542	11074	Normal, Modified and Conflicted are always loaded and visible.	11910
2543	11078	Deleted is loaded if possible, but falls back to Modified if there are not enough slots.	11914
2544	11082	Read-Only is loaded if possible, but falls back to Normal if there are not enough slots.	11918
2545	11086	Locked is only loaded if there are fewer than 13 overlays already loaded. It falls back to Normal if there are not enough slots.	11922
2546	11090	Added is only loaded if there are fewer than 14 overlays already loaded. It falls back to Modified if there are not enough slots.	11926
2547	11094	Securing Svnserve using SSH	11930
2548	11098	This section provides a step-by-step guide to setting up Subversion and TortoiseSVN to use the svn+ssh protocol. If you already use authenticated SSH connections to login to your server, then you are already there and you can find more detail in the Subversion book. If you are not using SSH but would like to do so to protect your Subversion installation, this guide gives a simple method which does not involve creating a separate SSH user account on the server for every subversion user.	11934
2549	11102	In this implementation we create a single SSH user account for all subversion users, and use different authentication keys to differentiate between the real Subversion users.	11938
2550	11106	In this appendix we assume that you already have the subversion tools installed, and that you have created a repository as detailed elsewhere in this manual. Note that you should not start svnserve as a service or daemon when used with SSH.	11942
2551	11110	Much of the information here comes from a tutorial provided by Marc Logemann, which has been archived at http://tortoisesvn.net/ssh_howto Additional information on setting up a Windows server was provided by Thorsten Müller. Thanks guys!	11946
2552	11114	You can also watch a video tutorial created by Maximo Migliari which takes you through all the important steps. Watch it on Vimeo. or YouTube.	11950
2553	11118	Setting Up a Linux Server	11954
2554	11122	You need to have SSH enabled on the server, and here we assume that you will be using OpenSSH. On most distributions this will already be installed. To find out, type: \n ps xa | grep sshd\n and look for ssh jobs.	11958
2555	11126	One point to note is that if you build Subversion from source and do not provide any argument to ./configure, Subversion creates a bin directory under /usr/local and places its binaries there. If you want to use tunneling mode with SSH, you have to be aware that the user logging in via SSH needs to execute the svnserve program and some other binaries. For this reason, either place /usr/local/bin into the PATH variable or create symbolic links of your binaries to the /usr/sbin directory, or to any other directory which is commonly in the PATH.	11965
2556	11130	To check that everything is OK, login in as the target user with SSH and type: \n which svnserve\n This command should tell you if svnserve is reachable.	11969
2557	11134	Create a new user which we will use to access the svn repository: \n useradd -m svnuser\n Be sure to give this user full access rights to the repository.	11976
2558	11138	Setting Up a Windows Server	11983
2559	11142	Install Cygwin SSH daemon as described here: http://pigtail.net/LRP/printsrv/cygwin-sshd.html	11987
2560	11146	Create a new Windows user account svnuser which we will use to access the repository. Be sure to give this user full access rights to the repository.	11991
2561	11150	If there is no password file yet then create one from the Cygwin console using: \n mkpasswd -l > /etc/passwd\n	11995
2562	11154	SSH Client Tools for use with TortoiseSVN	12002
2563	11158	Grab the tools we need for using SSH on the windows client from this site: http://www.chiark.greenend.org.uk/~sgtatham/putty/ Just go to the download section and get Putty, Plink, Pageant and Puttygen.	12006
2564	11162	Creating OpenSSH Certificates	12010
2565	11166	The next step is to create a key pair for authentication. There are two possible ways to create keys. The first is to create the keys with PuTTYgen on the client, upload the public key to your server and use the private key with PuTTY. The other is to create the key pair with the OpenSSH tool ssh-keygen, download the private key to your client and convert the private key to a PuTTY-style private key.	12014
2566	11170	Create Keys using ssh-keygen	12018
2567	11174	Login to the server as root or svnuser and type: \n ssh-keygen -b 1024 -t dsa -N passphrase -f keyfile\n substituting a real pass-phrase (which only you know) and key file. We just created a SSH2 DSA key with 1024 bit key-phrase. If you type \n ls -l keyfile*\n you will see two files, keyfile and keyfile.pub. As you might guess, the .pub file is the public key file, the other is the private one.	12022
2568	11178	Append the public key to those in the .ssh folder within the svnuser home directory: \n cat keyfile.pub >> /home/svnuser/.ssh/authorized_keys\n	12031
2569	11182	In order to use the private key we generated, we have to convert it to a putty format. This is because the private key file format is not specified by a standards body. After you download the private key file to your client PC, start PuTTYgen and use ConversionsImport key. Browse to your file keyfile which you got from the server the passphrase you used when creating the key. Finally click on Save private key and save the file as keyfile.PPK.	12038
2570	11186	Create Keys using PuTTYgen	12042
2571	11190	Use PuTTYgen to generate a public-key/private-key pair and save it. Copy the public key to the server and append it to those in the .ssh folder within the svnuser home directory: \n cat keyfile.pub >> /home/svnuser/.ssh/authorized_keys\n	12046
2572	11194	Test using PuTTY	12053
2573	11198	To test the connection we will use PuTTY. Start the program and on the Session tab set the hostname to the name or IP address of your server, the protocol to SSH and save the session as SvnConnection or whatever name you prefer. On the SSH tab set the preferred SSH protocol version to 2 and from Auth set the full path to the .PPK private key file you converted earlier. Go back to the Sessions tab and hit the Save button. You will now see SvnConnection in the list of saved sessions.	12057
2574	11202	Click on Open and you should see a telnet style login prompt. Use svnuser as the user name and if all is well you should connect directly without being prompted for a password.	12061
2575	11206	You may need to edit /etc/sshd_config on the server. Edit lines as follows and restart the SSH service afterwards. \n PubkeyAuthentication yes\n PasswordAuthentication no\n PermitEmptyPasswords no\n ChallengeResponseAuthentication no\n	12065
2576	11210	Testing SSH with TortoiseSVN	12075
2577	11214	So far we have only tested that you can login using SSH. Now we need to make sure that the SSH connection can actually run svnserve. On the server modify /home/svnuser/.ssh/authorized_keys as follows to allow many subversion authors to use the same system account, svnuser. Note that every subversion author uses the same login but a different authentication key, thus you have to add one line for every author.	12079
2578	11218	Note: This is all on one very long line. \n command=\"svnserve -t -r <ReposRootPath> --tunnel-user=<author>\",\n no-port-forwarding,no-agent-forwarding,no-X11-forwarding,\n no-pty ssh-rsa <PublicKey> <Comment>\n There are several values that you need to set according to your setup.	12083
2579	11222	<ReposRootPath> should be replaced with the path to the directory containing your repositories. This avoids the need to specify full server paths within URLs. Note that you must use forward slashes even on a Windows server, e.g. c:/svn/reposroot. In the examples below we assume that you have a repository folder within the repository root called repos.	12092
2580	11226	<author> should be replaced with the svn author that you want to be stored on commit. This also allows svnserve to use its own access rights within svnserve.conf.	12096
2581	11230	<PublicKey> should be replaced with the public key that you generated earlier.	12100
2582	11234	<Comment> can be any comment you like, but it is useful for mapping an svn author name to the person's real name.	12104
2583	11238	Right click on any folder in Windows Explorer and select TortoiseSVNRepo-Browser. You will be prompted to enter a URL, so enter one in this form: \n svn+ssh://svnuser@SvnConnection/repos\n What does this URL mean? The Schema name is svn+ssh which tells TortoiseSVN how to handle the requests to the server. After the double slash, you specify the user to connect to the server, in our case svnuser. After the @ we supply our PuTTY session name. This session name contains all details like where to find the private key and the server's IP or DNS. Lastly we have to provide the path to the repository, relative to the repository root on the server, as specified in the authorized_keys file.	12108
2584	11242	Click on OK and you should be able to browse the repository content. If so you now have a running SSH tunnel in conjunction with TortoiseSVN.	12115
2585	11246	Note that by default TortoiseSVN uses its own version of Plink to connect. This avoids a console window popping up for every authentication attempt, but it also means that there is nowhere for error messages to appear. If you receive the error Unable to write to standard output, you can try specifying Plink as the client in TortoiseSVN's network settings. This will allow you to see the real error message generated by Plink.	12119
2586	11250	SSH Configuration Variants	12123
2587	11254	One way to simplify the URL in TortoiseSVN is to set the user inside the PuTTY session. For this you have to load your already defined session SvnConnection in PuTTY and in the Connection tab set Auto login user to the user name, e.g. svnuser. Save your PuTTY session as before and try the following URL inside TortoiseSVN: \n svn+ssh://SvnConnection/repos\n This time we only provide the PuTTY session SvnConnection to the SSH client TortoiseSVN uses (TortoisePlink.exe). This client will check the session for all necessary details.	12127
2588	11258	At the time of writing PuTTY does not check all saved configurations, so if you have multiple configurations with the same server name, it will pick the first one which matches. Also, if you edit the default configuration and save it, the auto login user name is not saved.	12134
2589	11262	Many people like to use Pageant for storing all their keys. Because a PuTTY session is capable of storing a key, you don't always need Pageant. But imagine you want to store keys for several different servers; in that case you would have to edit the PuTTY session over and over again, depending on the server you are trying to connect with. In this situation Pageant makes perfect sense, because when PuTTY, Plink, TortoisePlink or any other PuTTY-based tool is trying to connect to an SSH server, it checks all private keys that Pageant holds to initiate the connection.	12138
2590	11266	For this task, simply run Pageant and add the private key. It should be the same private key you defined in the PuTTY session above. If you use Pageant for private key storage, you can delete the reference to the private key file in your saved PuTTY session. You can add more keys for other servers, or other users of course.	12142
2591	11270	If you don't want to repeat this procedure after every reboot of your client, you should place Pageant in the auto-start group of your Windows installation. You can append the keys with complete paths as command line arguments to Pageant.exe	12146
2592	11274	The last way to connect to an SSH server is simply by using this URL inside TortoiseSVN: \n svn+ssh://svnuser@100.101.102.103/repos\n svn+ssh://svnuser@mydomain.com/repos\n As you can see, we don't use a saved PuTTY session but an IP address (or domain name) as the connection target. We also supply the user, but you might ask how the private key file will be found. Because TortoisePlink.exe is just a modified version of the standard Plink tool from the PuTTY suite, TortoiseSVN will also try all the keys stored in Pageant.	12150
2593	11278	If you use this last method, be sure you do not have a default username set in PuTTY. We have had reports of a bug in PuTTY causing connections to close in this case. To remove the default user, simply clear HKEY_CURRENT_USER\\Software\\SimonTatham\\Putty\\Sessions\\Default%20Settings\\HostName	12158
2594	11282	Language Packs and Spell Checkers	12162
2595	11286	The standard installer has support only for English, but you can download separate language packs and spell check dictionaries separately after installation.	12166
2596	11290	Language Packs	12170
2597	11294	language packs	12174
2598	11298	translations	12178
2599	11302	The TortoiseSVN user interface has been translated into many different languages, so you may be able to download a language pack to suit your needs. You can find the language packs on our translation status page. And if there is no language pack available, why not join the team and submit your own translation ;-)
2600	11306	Each language pack is packaged as a .msi installer. Just run the install program and follow the instructions. After the installation finishes, the translation will be available.
2601	11310	The documentation has also been translated into several different languages. You can download translated manuals from the support page on our website.	12190
2602	11314	Spellchecker	12194
2603	11318	spellchecker	12198
2604	11322	dictionary	12202
2605	11326	TortoiseSVN includes a spell checker which allows you to check your commit log messages. This is especially useful if the project language is not your native language. The spell checker uses the same dictionary files as OpenOffice and Mozilla.	12206
2606	11330	The installer automatically adds the US and UK English dictionaries. If you want other languages, the easiest option is simply to install one of TortoiseSVN's language packs. This will install the appropriate dictionary files as well as the TortoiseSVN local user interface. After the installation finishes, the dictionary will be available too.
2607	11334	Or you can install the dictionaries yourself. If you have OpenOffice or Mozilla installed, you can copy those dictionaries, which are located in the installation folders for those applications. Otherwise, you need to download the required dictionary files from http://wiki.services.openoffice.org/wiki/Dictionaries	12214
2608	11346	Once you have got the dictionary files, you probably need to rename them so that the filenames only have the locale chars in it. Example: Then just copy them to the bin sub-folder of the TortoiseSVN installation folder. Normally this will be C:\\Program Files\\TortoiseSVN\\bin. If you don't want to litter the bin sub-folder, you can instead place your spell checker files in C:\\Program Files\\TortoiseSVN\\Languages. If that folder isn't there, you have to create it first. The next time you start TortoiseSVN, the spell checker will be available.	12226
2609	11350	Check the tsvn:projectlanguage setting. Refer to for information about setting project properties.	12230
2610	11354	If no project language is set, or that language is not installed, try the language corresponding to the Windows locale.	12234
2611	11358	If the exact Windows locale doesn't work, try the Base language, eg. de_CH (Swiss-German) falls back to de_DE (German).	12238
2612	11362	If none of the above works, then the default language is English, which is included with the standard installation.	12242
2613	11366	If you install multiple dictionaries, TortoiseSVN uses these rules to select which one to use.	12246
2614	11374	A Subversion command that is used to add a file or directory to your working copy. The new items are added to the repository when you commit.	12254
2615	11382	The current base revision of a file or folder in your working copy. This is the revision the file or folder was in, when the last checkout, update or commit was run. The BASE revision is normally not equal to the HEAD revision.	12262
2616	11386	This command is for text files only, and it annotates every line to show the repository revision in which it was last changed, and the author who made that change. Our GUI implementation is called TortoiseBlame and it also shows the commit date/time and the log message when you hover the mouse of the revision number.	12266
2617	11402	A term frequently used in revision control systems to describe what happens when development forks at a particular point and follows 2 separate paths. You can create a branch off the main development line so as to develop a new feature without rendering the main line unstable. Or you can branch a stable release to which you make only bug fixes, while new developments take place on the unstable trunk. In Subversion a branch is implemented as a cheap copy.	12283
2618	11406	A Subversion command which creates a local working copy in an empty directory by downloading versioned files from the repository.	12287
2619	11410	To quote from the Subversion book: Recursively clean up the working copy, removing locks and resuming unfinished operations. If you ever get a working copy locked error, run this command to remove stale locks and get your working copy into a usable state again. Note that in this context lock refers to local filesystem locking, not repository locking.	12291
2620	11414	This Subversion command is used to pass the changes in your local working copy back into the repository, creating a new repository revision.	12295
2621	11422	When changes from the repository are merged with local changes, sometimes those changes occur on the same lines. In this case Subversion cannot automatically decide which version to use and the file is said to be in conflict. You have to edit the file manually and resolve the conflict before you can commit any further changes.	12303
2622	11430	In a Subversion repository you can create a copy of a single file or an entire tree. These are implemented as cheap copies which act a bit like a link to the original in that they take up almost no space. Making a copy preserves the history of the item in the copy, so you can trace changes made before the copy was made.	12311
2623	11434	When you delete a versioned item (and commit the change) the item no longer exists in the repository after the committed revision. But of course it still exists in earlier repository revisions, so you can still access it. If necessary, you can copy a deleted item and resurrect it complete with history.	12315
2624	11438	Shorthand for Show Differences. Very useful when you want to see exactly what changes have been made.	12319
2625	11442	This command produces a copy of a versioned folder, just like a working copy, but without the local .svn folders.	12323
2626	11450	A proprietary Subversion filesystem backend for repositories. Can be used on network shares. Default for 1.2 and newer repositories.	12331
2627	11454	Group policy object	12335
2628	11458	HEAD revision	12339
2629	11462	The latest revision of a file or folder in the repository.	12343
2630	11466	Subversion command to import an entire folder hierarchy into the repository in a single revision.	12347
2631	11470	When you take out a lock on a versioned item, you mark it in the repository as non-committable, except from the working copy where the lock was taken out.	12351
2632	11478	Show the revision history of a file or folder. Also known as History.	12359
2633	11486	Show the revision history of a file or folder. Also known as Log.	12367
2634	11490	The process by which changes from the repository are added to your working copy without disrupting any changes you have already made locally. Sometimes these changes cannot be reconciled automatically and the working copy is said to be in conflict.	12371
2635	11494	Merging happens automatically when you update your working copy. You can also merge specific changes from another branch using TortoiseSVN's Merge command.	12375
2636	11498	Patch	12379
2637	11502	If a working copy has changes to text files only, it is possible to use Subversion's Diff command to generate a single file summary of those changes in Unified Diff format. A file of this type is often referred to as a Patch, and it can be emailed to someone else (or to a mailing list) and applied to another working copy. Someone without commit access can make changes and submit a patch file for an authorized committer to apply. Or if you are unsure about a change you can submit a patch for others to review.	12383
2638	11510	In addition to versioning your directories and files, Subversion allows you to add versioned metadata - referred to as properties to each of your versioned directories and files. Each property has a name and a value, rather like a registry key. Subversion has some special properties which it uses internally, such as svn:eol-style. TortoiseSVN has some too, such as tsvn:logminsize. You can add your own properties with any name and value you choose.	12391
2639	11514	If your repository moves, perhaps because you have moved it to a different directory on your server, or the server domain name has changed, you need to relocate your working copy so that its repository URLs point to the new location.	12395
2640	11518	Note: you should only use this command if your working copy is referring to the same location in the same repository, but the repository itself has moved. In any other circumstance you probably need the Switch command instead.	12399
2641	11526	A repository is a central place where data is stored and maintained. A repository can be a place where multiple databases or files are located for distribution over a network, or a repository can be a location that is directly accessible to the user without having to travel across a network.	12407
2642	11530	When files in a working copy are left in a conflicted state following a merge, those conflicts must be sorted out by a human using an editor (or perhaps TortoiseMerge). This process is referred to as Resolving Conflicts. When this is complete you can mark the conflicted files as being resolved, which allows them to be committed.	12411
2643	11534	Subversion keeps a local pristine copy of each file as it was when you last updated your working copy. If you have made changes and decide you want to undo them, you can use the revert command to go back to the pristine copy.	12415
2644	11542	Every time you commit a set of changes, you create one new revision in the repository. Each revision represents the state of the repository tree at a certain point in its history. If you want to go back in time you can examine the repository as it was at revision N.	12423
2645	11546	In another sense, a revision can refer to the set of changes that were made when that revision was created.	12427
2646	11550	Revision Property (revprop)	12431
2647	11554	Just as files can have properties, so can each revision in the repository. Some special revprops are added automatically when the revision is created, namely: svn:date svn:author svn:log which represent the commit date/time, the committer and the log message respectively. These properties can be edited, but they are not versioned, so any change is permanent and cannot be undone.	12435
2648	11562	A frequently-used abbreviation for Subversion.	12443
2649	11566	The name of the Subversion custom protocol used by the svnserve repository server.	12447
2650	11570	Just as Update-to-revision changes the time window of a working copy to look at a different point in history, so Switch changes the space window of a working copy so that it points to a different part of the repository. It is particularly useful when working on trunk and branches where only a few files differ. You can switch your working copy between the two and only the changed files will be transferred.	12451
2651	11574	This Subversion command pulls down the latest changes from the repository into your working copy, merging any changes made by others with local changes in the working copy.	12455
2652	11578	This is your local sandbox, the area where you work on the versioned files, and it normally resides on your local hard disk. You create a working copy by doing a Checkout from a repository, and you feed your changes back into the repository using Commit.	12459
2653	11583	translator-credits	12464
2654	11588	translator-translation	12469

^{Note: Line numbers are as in committed file, it may differ when you update to use newer .pot, also edited multi line messages may shift line position.}

Total:2654

Fuzzy mark test

String marked as fuzzy is not in final shape.

Index	Line	English	Line	Native
1	-	TortoiseSVN integrates seamlessly into the Windows shell (i.e. the explorer). This means you can keep working with the tools you're already familiar with. And you do not have to change into a different application each time you need the functions of version control.	122	Το TortoiseSVN ενσωματώνεται απρόσκοπτα στο κέλυφος των Windows (δηλ. στον εξερευνητή). Αυτό σημαίνει ότι μπορείτε να συνεχίσετε να εργάζεστε με τα εργαλεία που είστε συνηθισμένοι. Δεν χρειάζεται να μεταβείτε σε διαφορετική εφαρμογή κάθε φορά που πρέπει να χρησιμοποιήσετε λειτουργίες για έλεγχο εκδόσεων!
2	-	Both TortoiseSVN and Subversion are developed by a community of people who are working on those projects. They come from different countries all over the world, working together to create great software.	227	Το TortoiseSVN και το Subversion έχουν αναπτυχθεί από μια κοινότητα ανθρώπων που εργάζονται σε αυτά τα έργα. Προέρχονται από διαφορετικές χώρες ανά τον κόσμο και εργάζονται μαζί για να δημιουργήσουν εκπληκτικά προγράμματα.
3	-	for the hard work to get TortoiseSVN to what it is now, and his leadership of the project	264	για την σκληρή δουλειά του να κάνει το TortoiseSVN αυτό που είναι τώρα
4	-	for maintaining the documentation	281	για τη βοήθεια στην τεκμηρίωση και την εύρεση λαθών
5	-	This book is written for computer-literate folk who want to use Subversion to manage their data, but prefer to use a GUI client rather than a command line client. TortoiseSVN is a windows shell extension and it is assumed that the user is familiar with the windows explorer and how to use it.	330	Το βιβλίο αυτό έχει γραφτεί για χρήστες / γνώστες υπολογιστών που θέλουν να χρησιμοποιήσουν το Subversion για την διαχείριση των δεδομένων τους, αλλά δεν είναι τους είναι εύχρηστη η γραμμή εντολών για να το κάνουν. Εφόσον το TortoiseSVN είναι επέκταση στο κέλυφος των Windows θεωρούμε ότι ο χρήστης είναι εξοικιωμένος με την εξερεύνηση των windows και γνωρίζει πως να τη χρησιμοποιήσει.
6	-	Creating a Repository	513	Αποθήκη
7	-	Checking out a Working Copy	547	Αντίγραφο Εργασίας
8	-	Berkeley DB. A well tested database backend for repositories, that cannot be used on network shares. Default for pre 1.2 repositories.	12274	Βάση Δεδομένων Berkeley

^{Note: Line numbers are as in committed file, it may differ when you update to use newer .pot, also edited multi line messages may shift line position.}

Total:8

Escaped chars test

This test check if all escaped chars are known and its using match with English. Even you get red here it may be legal for your language.
This test is in developing now. Ignored are: \r \n (wee new line style test) and \".

PASS

PASS

RC Checks

Next few sections informs about duplicate accelerators in translation. There is no reason to be stressed about this, but some translators like to know it. In a fact even English translation contains duplicate.

Proc RC Check (el)

RC checking is currently off for this language. If you like enable it for your translation drop me an email.