Search/Navigation:
Related:
SLAC
/EPP/HPS Public
Jefferson Lab/Hall B/HPS Run Wiki
S30XL-LESA/LDMX
Page History
...
Note that some (most) arguments to these commands like path/to/file are completely bogus and should be replaced by valid files in your working copy or the remote repository (depending on the command).
Checkout a Structure Node
| No Format |
|---|
svn co svn://repo/some/dir |
Show Working Copy
...
Information
This command will print out general repository information like your current revision number and the repository root.
...
| No Format |
|---|
svn ls svn://repo/some/path/ |
Update Working Copy
Periodically, you will need to pull changes to the repository into working copy to keep it up to date.
You can update your entire local working copy by executing this command from its root directory.
| No Format |
|---|
svn up |
The command may also be executed with files or directories to limit the local files that are affected.
| No Format |
|---|
svn up some/dir some/file another/file |
Add
...
Files to the
...
Repository
This command can be used to add files:
...
The deletion will occur when you commit.
...
Delete Files
To delete files use this command:
...
You also need to perform a commit to delete the files in the repository and not just the local copy.
Commit
...
Local Changes
This command is used to commit your local changes to the repository:
...
The list of files or directories to commit is optional, but it is usually a good idea to include it.
Copy
...
Files
svn cp src/dir/or/file target/dir/or/file
Create a
...
Directory
svn mkdir path/to/dir
...
Merge Changes
| Warning | ||
|---|---|---|
| ||
Merging is an advanced operation. Always use '--dry-run' to check the results of the command before actually executing it. And always merge equivalent structure nodes when merging a branch back into the trunk, or you will screw up the trunk. |
...
svn cp m "making a branch" ^/projects/foo/trunk ^/projects/foo/branches/foo-dev
...
Making a
...
Tag
| Warning | ||
|---|---|---|
| ||
Making tags is an advanced operation. Most general users do not need to make tags, and for Maven projects this is done automatically during the release procedures. Never change a tag once it is made. Should changes be required, the preferred method is making them in the trunk and then making a new tag. |
...
svn cp -m "making a tag" ^/projects/foo/trunk ^/projects/foo/tags/foo-1.2.3
Reverting
...
Changes to Working Copy
svn revert path/to/broken/local/file
Setting properties
...
...
This command should usually be done by the repository administrator. To have Subversion ignore files in your local copy, see the section above entitle "Global config for ignoring files".
Files can have properties on them. This can be used to alter the behavior of Subversion.
For instance, this command will cause all files with the .log extension to be ignored in the current directory.
svn propset svn:ignore "*.log" .
Warnings and Tips
- Do not
...
- checkout an SVN project into another, local working copy of a Subversion structure node. This has the potential to create some serious issues when executing Subversion commands, and it will also confuse you.
- Do not checkout and modify tags of the code.
...
- By convention, a directory representing a tag in SVN, usually with "tag" someplace in the path, should not be modified once created. Changes should only be made on branches or the trunk
...
- .
- Be careful when using 'svn add' on a directory
...
- . When used without file arguments, the svn add command will include all files all files and subdirectories under that directory into the commit, which may not be your intended outcome.
...
- Be careful when using 'svn add' and 'svn commit' without any arguments or with directories
...
- . This may cause many files to be added to the repository that should not actually be tracked and will subsequently need to be removed. Once a file is added, it is tracked
...
- "forever
...
- " by the repository and
...
- never really deleted unless the repository is rebuilt without that commit included. So please double check that you are adding only the files which are intended. Before making a large or complicated commit, first use
...
- svn status
...
- in your working copy to see what files will be committed or
...
- use the -
...
- dry-
...
- run argument with commit to check first.
- Use
...
- the '--dry-run' argument
...
- before executing complex or dangerous commands. This will show you what will happen without the command actually being executed.
- Do not be too dependent on the IDE for using Subversion. Make sure to have a compatible SVN command line client available e.g. where the SVN minor version number is the same as your IDE's "connector" version (Eclipse), so that you are able to execute shell commands. This can be a pain to setup properly when using Eclipse, so the preferred method of keeping these tools compatible is installing the version of the connector from Eclipse that matches your existing command line client ( e.g. 1.6, 1.7 etc.).
...
- Update your working copy
...
- regularly. This will make sure you do not cause conflicts by modifying a file that someone has already made changes to in the repository.
- Do not develop code in your working copy for an extended period of time without committing
...
- it
...
- . This is especially true if there is the possibility that someone else is working on the same file. When possible, prefer checking in your work at the end of each day, or, at a minimum, the end of every week.
...
- Use branches when making an extensive set of complex changes to the trunk. This will ensure that the trunk is not broken by committing unstable code, and it will also allow you to commit changes that "break everything" without affecting anyone else using the trunk.
Overview
Content Tools