trunk - 기본적으로 개발을 시작할 때 사용하는 디렉토리(소스의 주 개발 작업을 진행하는 폴더) - 모든 프로그램 개발 작업은 trunk 디렉토리에서 부터 시작 - main, mainline, production의 의미로 사용됨
brankches - trunk 에서 뻗어져 나온 나뭇가지(소스의 실험적인 작업을 진행하는 폴더, 소스의 현재 버전을 유지보수 하고, 현재 버전을 기반으로 차기 버전을 개발할 경우 이 폴더 이용) - trunk 디렉토리에서 프로그램을 개발하다보면 큰 프로젝트에서 또 다른 작은 분류로 빼서 개발하는 경우. - 프로젝트 안의 작은 프로젝트 - release 버전과 유지보수 버전을 분리하고 싶을 때 사용 - customizing이나 hot fix 목적으로 분리하여 수정함 - 수정이 계속해서 발생하다가 궁극적으로는 trunk에 merge 되는 것이 일반적임
tags - 꼬리표의 개념. - 현재 릴리즈된 소스를 관리하기 쉽게 따로 보관하는데 사용. 즉, 개발을 위한 것이 아니라 보관을 위한 것이기 때문에 export만 해야 한다. 체크아웃하여 커밋 할 경우 경고 메시지가 출력된다. - 프로그램을 개발하면서 정기적으로 릴리즈 할 때 0.1, 0.2, 1.0 식의 버전의 소스를 따로 저장하는 공간 - 한번 만들면 수정하지 않음 - releases, snapshots, baselines의 의미로 사용됨
Microsoft Windows HTTP Services (WinHTTP) is targeted at middle-tier and back-end server applications that require access to an HTTP client stack.Microsoft Windows Internet (WinINet) provides an HTTP client stack for client applications, as well as access to the File Transfer Protocol (FTP), SOCKSv4, and Gopher protocols. This overview can help determine whether porting your WinINet applications to WinHTTP would be beneficial. It also describes specific conversion requirements.
Opposite behavior of the ICU_ESCAPE flag: with InternetCrackUrl, this flag causes escape sequences (%xx) to be converted to characters, but with WinHttpCrackUrl, it causes characters that must be escaped from in an HTTP request to be converted to escape sequences.
Be aware that in WinINet and WinHTTP, some functions can complete asynchronous requests either synchronously or asynchronously. Your application must handle either situation. There are significant differences in how WinINet and WinHTTP handle these potentially asynchronous functions.
WinINet
Synchronous completion: If a potentially asynchronous WinINet function call completes synchronously, the OUT parameters of the function return the results of the operation. When an error occurs, retrieve the error code by calling GetLastError after the WinINet function call.
Asynchronous completion: If a potentially asynchronous function call completes asynchronously, the results of the operation, and any errors, are accessible in the callback function. The callback function is executed on a worker thread, not on the thread that made the initial function call.
In other words, your application must duplicate logic to handle the results of such operations in two places: both immediately after the function call and in the callback function.
WinHTTP simplifies this model by enabling you to implement the operational logic only in the callback function, which receives a completion notification regardless of whether the operation completed synchronously or asynchronously. When asynchronous operation is enabled, the OUT parameters of WinHTTP functions do not return meaningful data and must be set to NULL.
The only significant difference between asynchronous and synchronous completion in WinHTTP, from the application perspective, is in where the callback function is executed.
WinHTTP
Synchronous completion: When an operation completes synchronously, the results are returned in a callback function that executes in the same thread as the original function call.
Asynchronous completion: When an operation completes asynchronously, the results are returned in a callback function that executes in a worker thread.
Although most errors can also be handled entirely within the callback function, WinHTTP applications must still be prepared for a function to return FALSEbecause of an ERROR_INVALID_PARAMETER or other similar error retrieved by calling GetLastError.
Unlike WinINet, which can execute multiple asynchronous operations simultaneously, WinHTTP enforces a policy of one pending asynchronous operation per request handle. If one operation is pending and another WinHTTP function is called, the second function fails and GetLastError returns ERROR_INVALID_OPERATION.
WinHTTP simplifies this model by enabling you to implement the operational logic only in the callback function, which receives a completion notification regardless of whether the operation completed synchronously or asynchronously. When asynchronous operation is enabled, the OUT parameters of WinHTTP functions do not return meaningful data and must be set to NULL.
Differences in WinHTTP Callback Notifications
The status callback function receives updates on the status of operations through notification flags. In WinHTTP, notifications are selected using thedwNotificationFlags parameter of the WinHttpSetStatusCallback function. Use the WINHTTP_CALLBACK_FLAG_ALL_NOTIFICATIONS flag to be notified of all status updates.
Notifications that indicate a particular operation is complete are called completion notifications, or just completions. In WinINet, each time the callback function receives a completion, the lpvStatusInformation parameter contains an INTERNET_ASYNC_RESULT structure. In WinHTTP, this structure is not available for all completions. It is important to review the reference page for WINHTTP_STATUS_CALLBACK, which contains information about notifications and what type of data can be expected for each.
In WinHTTP, a single completion, WINHTTP_CALLBACK_STATUS_REQUEST_ERROR, indicates that an operation failed. All other completions indicate a successful operation.
Both WinINet and WinHTTP use a user-defined context value to pass information from the main thread to the status callback function, which can be executed on a worker thread. In WinINet, the context value used by the status callback function is set by calling one of several functions. In WinHTTP, the context value is set only with WinHttpSendRequest or WinHttpSetOption. Because of this, it is possible in WinHTTP for a notification to occur before a context value is set. If the callback function receives a notification before the context value is set, the application must be prepared to receive NULL in the dwContextparameter of the callback function.
Authentication Differences
In WinINet, user credentials are set by calling the InternetSetOption function, using code similar to that provided in the following code example.
// Use the WinINet InternetSetOption function to set the
// user credentials to the user name contained in strUsername
// and the password to the contents of strPassword.
InternetSetOption( hRequest, INTERNET_OPTION_PROXY_USERNAME,
strUsername, strlen(strUsername) + 1 );
InternetSetOption( hRequest, INTERNET_OPTION_PROXY_PASSWORD,
strPassword, strlen(strPassword) + 1 );
For compatibility, user credentials can similarly be set in WinHTTP using the WinHttpSetOption function, but this is not recommended because it can pose a security vulnerability.
Instead, when an application receives a 401 status code in WinHTTP, the recommended method of setting credentials is first to identify an authentication scheme using WinHttpQueryAuthSchemes and, second, set the credentials using WinHttpSetCredentials. The following code example shows how to do this.
DWORD dwSupportedSchemes;
DWORD dwPrefered;
DWORD dwTarget;
// Obtain the supported and first schemes.
WinHttpQueryAuthSchemes( hRequest, &dwSupportedSchemes, &dwPrefered, &dwTarget );
// Set the credentials before resending the request.
WinHttpSetCredentials( hRequest, dwTarget, dwPrefered, strUsername, strPassword, NULL );
Because there is no equivalent to InternetErrorDlg in WinHTTP, applications that obtain credentials through a user interface must provide their own interface.
Unlike WinINet, WinHTTP does not cache passwords. Valid user credentials must be supplied for each request.
WinHTTP does not support the Distributed Password Authentication (DPA) scheme supported by WinINet. WinHTTP does, however, support Microsoft Passport 1.4. For more information about using Passport authentication in WinHTTP, see Passport Authentication in WinHTTP.
WinHTTP does not rely on Internet Explorer settings to determine the automatic logon policy. Instead, the auto-logon policy is set with WinHttpSetOption. For more information about authentication in WinHTTP, including the auto-logon policy, see Authentication in WinHTTP.
In a secure HTTP transaction, server certificates can be used to authenticate a server to the client. In WinINet, if a server certificate contains errors,HttpSendRequest fails and provides details about the certificate errors.
In WinHttp, server certificate errors are handled according to the version as follows:
Starting with WinHttp 5.1, if a server certificate fails or contains errors, the call to WinHttpSendRequest reports aWINHTTP_CALLBACK_STATUS_SECURE_FAILURE in the callback function. If the error generated by WinHttpSendRequest is ignored, subsequent calls to WinHttpReceiveResponse fail with an ERROR_WINHTTP_OPERATION_CANCELLED error.
In WinHTTP 5.0, errors in server certificates do not, by default, cause a request to fail. Instead, the errors are reported in the callback function with theWINHTTP_CALLBACK_STATUS_SECURE_FAILURE notification.
On some earlier platforms, WinINet supported the Private Communication Technology (PCT) and/or Fortezza protocols, although not on Windows XP.
WinHTTP does not support the PCT and Fortezza protocols on any platform, and instead relies on Secure Sockets Layer (SSL) 2.0, SSL 3.0, or Transport Layer Security (TLS) 1.0.
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).
Important
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.
D.1. TortoiseSVN
Commands
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.
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.
You can also specify a file which contains a list of paths, separated by
newlines. The file must be in UTF-16 format, without a BOM. 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.
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.
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.
To close the progress dialog at the end of a command automatically without
using the permanent setting you can pass the /closeonend parameter.음.. Log Dialog는 안 된다;; 당연한가.. Progress Dialog만 된다. 이건 잘 된다.
/closeonend:0 don't close the dialog automatically
/closeonend:1 auto close if no errors
/closeonend:2 auto close if no errors and conflicts
/closeonend:3 auto close if no errors, conflicts
and merges
To close the progress dialog for local operations if there were no errors or
conflicts, pass the /closeforlocal parameter.
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.
Table D.1. List of available commands and options
Command
Description
:about
Shows the about dialog. This is also shown if no command is given.
:log
Opens the log dialog. The /path specifies the file
or folder for which the log should be shown. Additional options can be set:
/startrev:xxx, /endrev:xxx,
/strict enables the 'stop-on-copy' checkbox, /merge enables the 'include merged revisions' checkbox,
/findstring:"filterstring" fills in the filter text,
/findtext forces the filter to use text, not regex, or
/findregex forces the filter to use regex, not simple
text search, and /findtype:X with X being a number
between 0 and 511. The numbers are the sum of the following options:
/findtype:0 filter by everything
/findtype:1 filter by messages
/findtype:2 filter by path
/findtype:4 filter by authors
/findtype:8 filter by revisions
/findtype:16 not used
/findtype:32 filter by bug ID
/findtype:64 not used
/findtype:128 filter by date
/findtype:256 filter by date range
If /outfile:path\to\file is
specified, the selected revisions are written to that file when the log dialog
is closed. The revisions are written in the same format as is used to specify
revisions in the merge dialog.
:checkout
Opens the checkout dialog. The /path specifies the
target directory and the /url specifies the URL to
checkout from. If you specify the key /blockpathadjustments, the automatic checkout path
adjustments are blocked. The /revision:XXX specifies
the revision to check out.
:import
Opens the import dialog. The /path specifies the
directory with the data to import. You can also specify the /logmsg switch to pass a predefined log message to the
import dialog. Or, if you don't want to pass the log message on the command
line, use /logmsgfile:path, where path points to a file containing the log message.
:update
Updates the working copy in /path to HEAD. If the
option /rev 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 /rev:1234. Other options are /nonrecursive, /ignoreexternals
and /includeexternals. The /stickydepth indicates that the specified depth should be
sticky, creating a sparse checkout.
:commit
Opens the commit dialog. The /path specifies the
target directory or the list of files to commit. You can also specify the /logmsg 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 /logmsgfile:path, where path 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 /bugid:"the bug id here" to
do that.
:add
Adds the files in /path to version control.
:revert
Reverts local modifications of a working copy. The /path tells which items to revert.
:cleanup
Cleans up interrupted or aborted operations and unlocks the working copy in
/path. Use /noui to prevent
the result dialog from popping up (either telling about the cleanup being
finished or showing an error message). /noprogressui
also disables the progress dialog. /nodlg disables
showing the cleanup dialog where the user can choose what exactly should be done
in the cleanup. The available actions can be specified with the options /cleanup for status cleanup, /revert, /delunversioned, /delignored, /refreshshell and
/externals.
:resolve
Marks a conflicted file specified in /path as
resolved. If /noquestion is given, then resolving is
done without asking the user first if it really should be done.
:repocreate
Creates a repository in /path
:switch
Opens the switch dialog. The /path specifies the
target directory.
:export
Exports the working copy in /path to another
directory. If the /path points to an unversioned
directory, a dialog will ask for an URL to export to the directory in /path. If you specify the key /blockpathadjustments, the automatic export path adjustments
are blocked.
:dropexport
Exports the working copy in /path to the directory
specified in /droptarget. This exporting does not use
the export dialog but executes directly. The option /overwrite specifies that existing files are overwritten
without user confirmation, and the option /autorename
specifies that if files already exist, the exported files get automatically
renamed to avoid overwriting them.
:merge
Opens the merge dialog. The /path specifies the
target directory. For merging a revision range, the following options are
available: /fromurl:URL, /revrange:string. For merging two repository trees, the
following options are available: /fromurl:URL, /tourl:URL, /fromrev:xxx and /torev:xxx. For doing a reintegrate merge, use the following
options: /fromurl:URL and /reintegrate. These pre-fill the relevant fields in the
merge dialog.
:mergeall
Opens the merge all dialog. The /path specifies
the target directory.
:copy
Brings up the branch/tag dialog. The /path is the
working copy to branch/tag from. And the /url is the
target URL. You can also specify the /logmsg 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 /logmsgfile:path, where path
points to a file containing the log message.
:settings
Opens the settings dialog.
:remove
Removes the file(s) in /path from version control.
:rename
Renames the file in /path. The new name for the
file is asked with a dialog. To avoid the question about renaming similar files
in one step, pass /noquestion.
:diff
Starts the external diff program specified in the TortoiseSVN settings. The
/path specifies the first file. If the option /path2 is set, then the diff program is started with those
two files. If /path2 is omitted, then the diff is done
between the file in /path and its BASE. To explicitly
set the revision numbers use /startrev:xxx and /endrev:xxx, and for the optional peg revision use /pegrevision:xxx. If /blame is set
and /path2 is not set, then the diff is done by first
blaming the files with the given revisions. The parameter /line:xxx specifies the line to jump to when the diff is
shown.
:showcompare
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.
The options url1, url2,
revision1 and revision2 must
be specified. The options pegrevision, ignoreancestry, blame and unified are optional.
:conflicteditor
Starts the conflict editor specified in the TortoiseSVN settings with the
correct files for the conflicted file in /path.
:relocate
Opens the relocate dialog. The /path specifies the
working copy path to relocate.
:help
Opens the help file.
:repostatus
Opens the check-for-modifications dialog. The /path specifies the working copy directory. If /remote is specified, the dialog contacts the repository
immediately on startup, as if the user clicked on the Check
repository button.
:repobrowser
Starts the repository browser dialog, pointing to the URL of the working copy
given in /path or /path
points directly to an URL.
An additional option /rev:xxx can be used to
specify the revision which the repository browser should show. If the /rev:xxx is omitted, it defaults to HEAD.
If /path points to an URL, the /projectpropertiespath:path/to/wc specifies the path from
where to read and use the project properties.
If /outfile:path\to\file is specified, the selected
URL and revision are written to that file when the repository browser is closed.
The first line in that text file contains the URL, the second line the revision
in text format.
:ignore
Adds all targets in /path to the ignore list, i.e.
adds the svn:ignore property to those files.
:blame
Opens the blame dialog for the file specified in /path.
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.
If the option /line:nnn is set, TortoiseBlame will
open with the specified line number showing.
The options /ignoreeol, /ignorespaces and /ignoreallspaces
are also supported.
:cat
Saves a file from an URL or working copy path given in /path to the location given in /savepath:path. The revision is given in /revision:xxx. This can be used to get a file with a
specific revision.
:createpatch
Creates a patch file for the path given in /path.
:revisiongraph
Shows the revision graph for the path given in /path.
To create an image file of the revision graph for a specific path, but
without showing the graph window, pass /output:path
with the path to the output file. The output file must have an extension that
the revision graph can actually export to. These are: .svg, .wmf, .png, .jpg, .bmp and .gif.
Since the revision graph has many options that affect how it is shown, you
can also set the options to use when creating the output image file. Pass these
options with /options:XXXX, where XXXX is a decimal value. The best way to find the required
options is to start the revision graph the usual way, set all user-interface
options and close the graph. Then the options you need to pass on the command
line can be read from the registry HKCU\Software\TortoiseSVN\RevisionGraphOptions.
:lock
Locks a file or all files in a directory given in /path. The 'lock' dialog is shown so the user can enter a
comment for the lock.
:unlock
Unlocks a file or all files in a directory given in /path.
:rebuildiconcache
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 /noquestion.
:properties
Shows the properties dialog for the path given in /path.