Version Control with Subversion phần 8 pps

Move a file in your working copy: $ svn move foo.c bar.c Move a file in the repository an immediate commit, so it requires a commit message: $ svn move -m "Move a file" http://svn.red-be

When you're concatenating the results of multiple calls to the log command, you may want touse the incrementaloption svn log normally prints out a dashed line at the beginning of

a log message, after each subsequent log message, and following the final log message If

you ran svn log on a range of two revisions, you would get this:

$ svn log -r 14:15

r14 | …

r15 | …

-r19 | …

-r27 | …

-You can avoid the clutter of the double dashed lines in your output by using the incrementaloption:

$ svn log incremental -r 14 > mylog

$ svn log incremental -r 19 >> mylog

$ svn log incremental -r 27 >> mylog

$ cat mylog

r14 | …

r19 | …

r27 | …

-The incrementaloption provides similar output control when using the xmloption

If you run svn log on a specific path and provide a specific revision and get no

output at all

$ svn log -r 20 http://svn.red-bean.com/untouched.txt

-That just means that the path was not modified in that revision If you log from the

top of the repository, or know the file that changed in that revision, you can specify

it explicitly:

$ svn log -r 20 touched.txt

r20 | sally | 2003-01-17 22:56:19 -0600 (Fri, 17 Jan 2003) | 1 lineMade a change

svn merge — Apply the differences between two sources to a working copy path

Synopsis

svn merge [-c M | -r N:M] SOURCE[@REV] [WCPATH]

svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]

svn merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]

Description

In the first and second forms, the source paths (URLs in the first form, working copy paths inthe second) are specified at revisions N and M These are the two sources to be compared.The revisions default toHEADif omitted

The-c Moption is equivalent to-r N:MwhereN = M-1 Using-c -Mdoes the reverse:-rM:NwhereN = M-1

In the third form,SOURCEcan be a URL or working copy item, in which case the correspondingURL is used This URL, at revisionsNandM, defines the two sources to be compared

WCPATHis the working copy path that will receive the changes IfWCPATHis omitted, a defaultvalue of “.” is assumed, unless the sources have identical basenames that match a file within

“.”: in which case, the differences will be applied to that file

Unlike svn diff, the merge command takes the ancestry of a file into consideration when

per-forming a merge operation This is very important when you're merging changes from onebranch into another and you've renamed a file on one branch but not the other

$ svn mkdir -m "Making a new dir." http://svn.red-bean.com/repos/newdirCommitted revision 26.

This command moves a file or directory in your working copy or in the repository.

This command is equivalent to an svn copy followed by svn delete.

Subversion does not support moving between working copies and URLs In tion, you can only move files within a single repository—Subversion does not sup-port cross-repository moving

Move a file in your working copy:

$ svn move foo.c bar.c

Move a file in the repository (an immediate commit, so it requires a commit message):

$ svn move -m "Move a file" http://svn.red-bean.com/repos/foo.c \

http://svn.red-bean.com/repos/bar.cCommitted revision 27

svn propdel — Remove a property from an item

Synopsis

svn propdel PROPNAME [PATH ]

svn propdel PROPNAME revprop -r REV [TARGET]

Delete a property from a file in your working copy

$ svn propdel svn:mime-type some-script

property 'svn:mime-type' deleted from 'some-script'

Delete a revision property:

$ svn propdel revprop -r 26 release-date

property 'release-date' deleted from repository revision '26'

svn propedit — Edit the property of one or more items under version control

Synopsis

svn propedit PROPNAME PATH

svn propedit PROPNAME revprop -r REV [TARGET]

Description

Edit one or more properties using your favorite editor The first form edits versioned properties

in your working copy, while the second edits unversioned remote properties on a repository vision (TARGETonly determines which repository to access)

svn propedit makes it easy to modify properties that have multiple values:

$ svn propedit svn:keywords foo.c

<svn will launch your favorite editor here, with a buffer opencontaining the current contents of the svn:keywords property Youcan add multiple values to a property easily here by entering onevalue per line.>

Set new value for property 'svn:keywords' on 'foo.c'

svn propget — Print the value of a property

Synopsis

svn propget PROPNAME [TARGET[@REV] ]

svn propget PROPNAME revprop -r REV [URL]

Description

Print the value of a property on files, directories, or revisions The first form prints the sioned property of an item or items in your working copy, while the second prints unversionedremote property on a repository revision See the section called “Properties” for more informa-tion on properties

Examine a property of a file in your working copy:

$ svn propget svn:keywords foo.c

$ svn propget svn:log revprop -r 20

Began journal

$ svn proplist verbose foo.c

Properties on 'foo.c':

svn:mime-type : text/plain

svn:keywords : Author Date Rev

owner : sally

svn propset — Set PROPNAME to PROPVAL on files, directories, or revisions

Synopsis

svn propset PROPNAME [PROPVAL | -F VALFILE] PATH

svn propset PROPNAME revprop -r REV [PROPVAL | -F VALFILE] [TARGET]

Description

SetPROPNAMEtoPROPVALon files, directories, or revisions The first example creates a sioned, local property change in the working copy, and the second creates an unversioned, re-mote property change on a repository revision (TARGET only determines which repository toaccess)

ver-Subversion has a number of “special” properties that affect its behavior See thesection called “Subversion properties” for more on these properties

$ svn propset svn:mime-type image/jpeg foo.jpg

property 'svn:mime-type' set on 'foo.jpg'

On a UNIX system, if you want a file to have the executable permission set:

$ svn propset svn:executable ON somescript

property 'svn:executable' set on 'somescript'

Perhaps you have an internal policy to set certain properties for the benefit of your coworkers:

$ svn propset owner sally foo.c

property 'owner' set on 'foo.c'

If you made a mistake in a log message for a particular revision and want to change it, use

revpropand setsvn:logto the new log message:

$ svn propset revprop -r 25 svn:log "Journaled about trip to New York."

property 'svn:log' set on repository revision '25'

Or, if you don't have a working copy, you can provide a URL

$ svn propset revprop -r 26 svn:log "Document nap." http://svn.red-bean.com/reposproperty 'svn:log' set on repository revision '25'

Lastly, you can tell propset to take its input from a file You could even use this to set the

con-tents of a property to something binary:

$ svn propset owner-pic -F sally.jpg moo.c

property 'owner-pic' set on 'moo.c'

By default, you cannot modify revision properties in a Subversion repository Your

repository administrator must explicitly enable revision property modifications by

creating a hook named pre-revprop-change See the section called

“Implementing Repository Hooks” for more information on hook scripts

Once you've resolved the conflict andfoo.cis ready to be committed, run svn resolved to let

your working copy know you've taken care of everything

You can just remove the conflict files and commit, but svn resolved fixes up some

bookkeeping data in the working copy administrative area in addition to removingthe conflict files, so we recommend that you use this command

Reverts any local changes to a file or directory and resolves any conflicted states svn revert

will not only revert the contents of an item in your working copy, but also any propertychanges Finally, you can use it to undo any scheduling operations that you may have done(e.g files scheduled for addition or deletion can be “unscheduled”)

Lastly, you can undo any scheduling operations:

$ svn add mistake.txt whoops

svn revert is inherently dangerous, since its entire purpose is to throw away

data—namely, your uncommitted changes Once you've reverted, Subversion

provides no way to get back those uncommitted changes.

If you provide no targets to svn revert, it will do nothing—to protect you from dentally losing changes in your working copy, svn revert requires you to provide

acci-at least one target

The first six columns in the output are each one character wide, and each column gives you formation about different aspects of each working copy item.

in-The first column indicates that an item was added, deleted, or otherwise changed

dele-The contents (as opposed to the properties) of the item conflict with updates received fromthe repository

Item is missing (e.g you moved or deleted it without using svn) This also indicates that a

directory is incomplete (a checkout or update was interrupted)

'~'

Item is versioned as one kind of object (file, directory, link), but has been replaced by

dif-ferent kind of object.

The second column tells the status of a file's or directory's properties

Properties for this item are in conflict with property updates received from the repository

The third column is populated only if the working copy directory is locked (See the sectioncalled “Sometimes You Just Need to Clean Up”.)

History scheduled with commit

The fifth column is populated only if the item is switched relative to its parent (see the sectioncalled “Traversing Branches”)

When show-updates is used, the file is not locked If show-updatesis not used,

this merely means that the file is not locked in this working copy

K

File is locked in this working copy

File was locked in this working copy, but the lock has been “stolen” and is invalid The file

is currently locked in the repository This only appears when show-updatesis used.B

File was locked in this working copy, but the lock has been “broken” and is invalid The file

is no longer locked This only appears when show-updatesis used

The out-of-date information appears in the seventh column (only if you pass the -show-updatesoption)

-' -'

The item in your working copy is up-to-date

'*'

A newer revision of the item exists on the server

The remaining fields are variable width and delimited by spaces The working revision is thenext field if the show-updatesor verboseoptions are passed

If the verboseoption is passed, the last committed revision and last committed author aredisplayed next

The working copy path is always the final field, so it can include spaces

This is the easiest way to find out what changes you have made to your working copy:

Status against revision: 981

show-updatesonly places an asterisk next to items that are out of date (that

is, items that will be updated from the repository if you run svn update). -show-updates does not cause the status listing to reflect the repository's ver-

-sion of the item (although you can see the revi-sion number in the repository bypassing the verboseoption)

And finally, the most information you can get out of the status subcommand:

$ svn status show-updates verbose wc

svn switch — Update working copy to a different URL

Synopsis

svn switch URL [PATH]

switch relocate FROM TO [PATH ]

Description

The first variant of this subcommand (without the relocate option) updates your workingcopy to point to a new URL—usually a URL which shares a common ancestor with your work-ing copy, although not necessarily This is the Subversion way to move a working copy to anew branch See the section called “Traversing Branches” for an in-depth look at switching.The relocateoption causes svn switch to do something different: it updates your working

copy to point to the same repository directory, only at a different URL (typically because an

ad-ministrator has moved the repository to another server, or to another URL on the same server)

check out a new working copy, you can have the svn switch command “rewrite” the

begin-nings of all the URLs in your working copy Use the relocateoption to do the substitution

No file contents are changed, nor is the repository contacted It's similar to running a Perl scriptover your working copy.svn/directories which runs s/OldRoot/NewRoot/.

$ svn checkout file:///tmp/repos test

svn: Unable to open an ra_local session to URL

svn: Unable to open repository 'file:///tmp/repos'

$ svn switch relocate file:///tmp/repos file:///tmp/newlocation

$ svn update

At revision 3

Be careful when using the relocate option If you mistype the argument, youmight end up creating nonsensical URLs within your working copy that render thewhole workspace unusable and tricky to fix It's also important to understand ex-actly when one should or shouldn't use relocate Here's the rule of thumb:

• If the working copy needs to reflect a new directory within the repository, then

use just svn switch.

the repository itself has changed, then use svn switch relocate.

Unlock two files in your working copy:

$ svn unlock tree.jpg house.jpg

'tree.jpg' unlocked

'house.jpg' unlocked

Unlock a file in your working copy that is currently locked by another user:

$ svn unlock tree.jpg

svn: 'tree.jpg' is not locked in this working copy

$ svn unlock force tree.jpg

$ svn unlock http://svn.red-bean.com/repos/test/tree.jpg'tree.jpg unlocked.

For further details, see the section called “Locking”

svn update brings changes from the repository into your working copy If no revision is given,

it brings your working copy up-to-date with theHEAD revision Otherwise, it synchronizes theworking copy to the revision given by the revisionoption As part of the synchronization,

svn update also removes any stale locks (see the section called “Sometimes You Just Need

to Clean Up”) found in the working copy

For each updated item, it prints a line that starts with a character reporting the action taken.These characters have the following meaning:

You can also “update” your working copy to an older revision (Subversion doesn't have the

concept of “sticky” files like CVS does; see Appendix B, Subversion for CVS Users):

If you want to examine an older revision of a single file, you may want to use svn

cat instead—it won't change your working copy.

svnadmin

svnadmin is the administrative tool for monitoring and repairing your Subversion repository.

For detailed information, see the section called “svnadmin”

Since svnadmin works via direct repository access (and thus can only be used on the

ma-chine that holds the repository), it refers to the repository with a path, not a URL

svnadmin Options

bdb-log-keep

(Berkeley DB specific) Disable automatic log removal of database log files Having theselog files around can be convenient if you need to restore from a catastrophic repository fail-ure

(Berkeley DB specific) Disables fsync when committing database transactions Used with

the svnadmin create command to create a Berkeley DB backed repository with

DB_TXN_NOSYNCenabled (which improves speed but has some risks associated with it). bypass-hooks

Bypass the repository hook system

clean-logs

Removes unused Berkeley DB logs

force-uuid

By default, when loading data into repository that already contains revisions, svnadmin

will ignore theUUIDfrom the dump stream This option will cause the repository'sUUIDto

be set to theUUIDfrom the stream

ignore-uuid

By default, when loading an empty repository, svnadmin will ignore the UUID from thedump stream This option will force that UUID to be ignored (useful for overriding your con-figuration file if it has force-uuidset)