Relative items adjust a date (or the current date if none) forward or backward. The effects of relative items accumulate. Here are some examples:
1 year
1 year ago
3 years
2 days
The unit of time displacement may be selected by the string `year' or `month' for moving by whole years or months. These are fuzzy units, as years and months are not all of equal duration. More precise units are `fortnight' which is worth 14 days, `week' worth 7 days, `day' worth 24 hours, `hour' worth 60 minutes, `minute' or `min' worth 60 seconds, and `second' or `sec' worth one second. An `s' suffix on these units is accepted and ignored.
The unit of time may be preceded by a multiplier, given as an optionally signed number. Unsigned numbers are taken as positively signed. No number at all implies 1 for a multiplier. Following a relative item by the string `ago' is equivalent to preceding the unit by a multiplier with value -1.
The string `tomorrow' is worth one day in the future (equivalent to `day'), the string `yesterday' is worth one day in the past (equivalent to `day ago').
The strings `now' or `today' are relative items corresponding to zero-valued time displacement, these strings come from the fact a zero-valued time displacement represents the current time when not otherwise change by previous items. They may be used to stress other items, like in `12:00 today'. The string `this' also has the meaning of a zero-valued time displacement, but is preferred in date strings like `this thursday'.
date --date=now
date --date=today # same thing
date --date='3 seconds'
date --date='3 seconds ago'
date --date='4 hours'
date --date='tomorrow'
date --date='1 day'
date --date='1 days'
date --date='yesterday'
date --date='1 day ago'
date --date='1 days ago'
date --date='1 week'
date --date='1 fortnight'
date --date='1 month'
date --date='1 year'
Recommended Repository Layout
While Subversion's flexibility allows you to lay out your repository in any way that you choose, we recommend that you 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. For example:
$ svn list file:///var/svn/repos
/trunk
/branches
/tags
You'll learn more about tags and branches in Chapter 4, Branching and Merging. For details and how to set up multiple projects, see the section called “Repository Layout” and the section called “Planning Your Repository Organization” to read more about project roots.
You'll need the following build tools to compile Subversion:
* autoconf 2.58 or later (Unix only)
* libtool 1.4 or later (Unix only)
* a reasonable C compiler (gcc, Visual Studio, etc.)
Subversion also depends on the following third-party libraries:
* libapr and libapr-util (REQUIRED for client and server)
The Apache Portable Runtime (APR) library provides an
abstraction of operating-system level services such as file
and network I/O, memory management, and so on. It also
provides convenience routines for things like hashtables,
checksums, and argument processing. While it was originally
developed for the Apache HTTP server, APR is a standalone
library used by Subversion and other products. It is a
critical dependency for all of Subversion; it's the layer
that allows Subversion clients and servers to run on
different operating systems.
* SQLite (REQUIRED for client and server)
Subversion uses SQLite to manage some internal databases.
* libz (REQUIRED for client and server)
Subversion uses zlib for compressing binary differences.
These diff streams are used everywhere -- over the network,
in the repository, and in the client's working copy.
* libserf (OPTIONAL for client)
The Serf libraries both allow the Subversion client
to send HTTP requests. This is necessary if you want your
client to access a repository served by the Apache HTTP
server. There is an alternate 'svnserve' server as well,
though, and clients automatically know how to speak the
svnserve protocol. Thus it's not strictly necessary for your
client to be able to speak HTTP... though we still recommend
that your client be built to speak both HTTP and svnserve
protocols.
* OpenSSL (OPTIONAL for client and server)
OpenSSL enables your client to access SSL-encrypted https://
URLs (using libserf) in addition to unencrypted http:// URLs.
To use SSL with Subversion's WebDAV server, Apache needs to
be compiled with OpenSSL as well.
* Berkeley DB (OPTIONAL for client and server)
There are two different repository 'back-end'
implementations. One implementation stores data in a flat
filesystem (known as FSFS); the other implementation stores
data in a Berkeley DB database (known as BDB). When you
create a repository, you have the option of specifying a
storage back-end. The Berkeley DB back-end will only be
available if the BDB libraries are discovered at compile
time.
* libsasl (OPTIONAL for client and server)
If the Cyrus SASL library is detected at compile time, then
the svn client (and svnserve server) will be able to utilize
SASL to do various forms of authentication when speaking the
svnserve protocol.
* Python, Perl, Java, Ruby (OPTIONAL)
Subversion is mostly a collection of C libraries with
well-defined APIs, with a small collection of programs that
use the APIs. If you want to build Subversion API bindings
for other languages, you need to have those languages
available at build time.
* KDELibs, GNOME Keyring (OPTIONAL for client)
Subversion contains optional support for storing passwords in
KWallet (KDE 4) or GNOME Keyring.
To create a new Subversion repository by converting an existing CVS repository, run the script like this: $ cvs2svn --svnrepos NEW_SVNREPOS CVSREPOS
To create a new Subversion repository containing only trunk commits,
and omitting all branches and tags from the CVS repository, do
$ cvs2svn --trunk-only --svnrepos NEW_SVNREPOS CVSREPOS
To create a Subversion dumpfile (suitable for 'svnadmin load') from a CVS repository, run it like this:
$ cvs2svn --dumpfile DUMPFILE CVSREPOS
To use an options file to define all of the conversion parameters, specify --options:
$ cvs2svn --options OPTIONSFILE
As it works, cvs2svn will create many temporary files in a temporary
directory called "cvs2svn-tmp" (or the directory specified with
--tmpdir). This is normal. If the entire conversion is successful,
however, those tempfiles will be automatically removed. If the
conversion is not successful, or if you specify the '--skip-cleanup'
option, cvs2svn will leave the temporary files behind for possible
debugging.
cvs2svn은 cvs 리파지터리를 svn으로 변환해주는 툴이다.
변환과정중에 하나라도 잘못된 ,v 파일(cvs의 history 파일)이 있으면 중지되고,
한글을 사용했을 경우, encoding 문제로 인해서 pass 2에서 문제가 발생한다.
ERROR: There were warnings converting author names and/or log messages
to unicode (see messages above). Please restart this pass
with one or more '--encoding' parameters or with '--fallback-encoding'.
$ man cvs2svn --encoding=encoding
Use encoding as the encoding for filenames, log messages, and
author names in the CVS repos. This option may be specified mul-
tiple times, in which case the encodings are tried in order until
one succeeds. Default: ascii. See
http://docs.python.org/lib/standard-encodings.html for a list of
other standard encodings.
--fallback-encoding=encoding
If none of the encodings specified with --encoding succeed in
decoding an author name or log message, then fall back to using
encoding in lossy 'replace' mode. Use of this option may cause
information to be lost, but at least it allows the conversion to
run to completion. This option only affects the encoding of log
messages and author names; there is no fallback encoding for
filenames. (By using an --options file, it is possible to spec-
ify a fallback encoding for filenames.) Default: disabled.
