We have released a new bug-fix release for our file and directory compare tool SmartSynchronize 3.1. A detailed list of changes can be found here.
I was asked by a couple of CVS users who want to start with SVN (using our SVN client SmartSVN) about some tips how to avoid common pitfalls. So, from my personal experience and from problems we have got reported by our users, I would consider following issues as notable:
With SVN you don’t have tags and branches as a built-in feature like in CVS. Instead, tags and branches are handled by using special paths and SVN’s cheap copy feature. Don’t try to reinvent the wheel but better stick with a default repository layout:
| [-] branches
| | [+] branch1
| | [+] branch2
| [-] tags
| | [+] tag1
| | [+] tag2
| [+] trunk
| [-] branches
| | [+] branch1
| | [+] branch2
| [-] tags
| | [+] tag1
| | [+] tag2
| [+] trunk
Quite often people check out the whole repository or project including all tags and branches. Don’t do that but only check out either the trunk or a specific tag or branch. It is quite easy to “switch” between them.
With CVS it often was common practice to add a certain tag to only a few files. Forget about tagging individual files in SVN.
SVN can tag (aka copy) large parts of the repository as effective as just a small part.
Another advantage of tagging always the full repository is that you are able to switch easily to that project state.
If you have used file-based (not (only) project-based) tags in CVS and history doesn’t really matter to you, better import fresh project states in the SVN repository and don’t convert the CVS repository to SVN.
A lot of projects consist of multiple parts. With CVS you might have used CVS modules or shell scripts to check out from different repository locations or different repositories.
SVN’s externals are a much better concept and should be used instead.
The 5th milestone of SmartGit, a client for the distributed version control system (DVCS) Git, is available.
The most notable changes in Milestone 5 are:
- basic submodule support
- log improvements
- configurable accelerators
All changes can be found in the change log.
We would like to invite everyone to give this milestone build a try and share your ideas with us. Join the SmartGit community!
SmartGit requires a Git installation on your system.
The first beta version of SmartCVS 7.1 beta 1 is available. The most new features and improves are:
- Transactions: ability to filter by branch and/or author
- for Windows there exists a portable bundle (e.g. for USB-stick usage)
- Transactions: ability to show for time or tag range
- external tools: option to use system open or edit command (requires Java 1.6)
- external file comparators: ability to use (e.g. graphic) viewers which only can accept one file, but can be invoked two times to open two files
- OS X: reveal in Finder
- file filter, speed search: configurable, e.g. with smart upper case (e.g. “FB” will match “FooBar.txt”)
- Commit dialog: ability to open change report
- working copies with :ssh: (instead of :ext:) are working now (to be compatible with other CVS clients)
- built-in File Compare: if binary files are compared, file size and hash code are shown
- built-in File Compare: option to deactivate synchronized scrolling
- built-in File Compare: optionally ignore case changes
- Conflict Solver: ability to pass left and right title to external tool
- Conflict Solver: shows Save toolbar button
- tables, time columns: show today/yesterday if applicable
SmartSVN Enterprise offers a Plugin-API which allows to add own functionality to SmartSVN. In this article I want to show how to configure IntelliJ IDEA to compile a sample plugin and how to launch SmartSVN to load this plugin. Of course you should be able to use any other Java IDE, too.
Ensure that SmartSVN is installed and configured. It must have an Enterprise (demo) license registered. How to get an Enterprise demo license.
Now create a project structure:
- create an empty directory (we will use C:\projects\mergeInfoColumn) as the root for the project
- create a lib directory and copy all .jar files from the SmartSVN installation into it (svnkit-cli.jar is not required and hence can be skipped)
- create a src directory and unpack the mergeInfoColumn directory from the plugin-sources.zip of the SmartSVN installation into it.
Create a new project in IDEA and add a Java module mergeInfoColumn and configure its Sources, Paths and Dependencies according to the following screenshots.
Remember this output path, we will need it later, so SmartSVN can load the plugin:
Every SmartSVN plugin depends on the openapi.jar, the mergeInfoColumn plugin also requires the svnkit.jar to compile:
Open the compiler settings and ensure that .properties files are copied from the sources to the classes directory.
To launch SmartSVN you will need all its jar files, hence we create another module named launcher just for launching purposes.
Add all the .jar files from the lib directory as dependency. To ensure that the mergeInfoColumn module is also compiled before launching, add it also as dependency:
Create a Run/Debug configuration. Use the main class SmartSVN and tell SmartSVN where to look for the plugin classes by setting the VM property smartsvn.pluginLocations. Use the compiler output path configured above. You can use absolute paths, but also, as shown in this screenshot, relative ones.
Now you should be able to launch SmartSVN. If everything is done right, you should see “Plugin … loaded.” message on the console immediately after SmartSVN start up.
On Wallace Lau’s blog I’ve found an entry how to install/configure SmartSVN on Ubuntu. Although it talks about an older SmartSVN version, most information is still valid for the current one.
I’m now having a couple of years experience in using our SVN-client SmartSVN, but I would not call me an "SVN expert". Since approximately a half year we are using Git to develop our Git-client SmartGit, but I’m definitely neither a Git expert nor an experienced Git user. To be honest, I’m only using the Git features which are available in SmartGit, because I can’t remember all the command line options. Nevertheless, I think I have a good overview over both tools, especially, because I use both for my daily work.
A couple of the following differences might not be just differences between SVN and Git, but differences between classical VCS and distributed VCS (DVCS) in general. Here are some sketched differences in random order which came to my mind when I was asked by a SmartSVN customer:
Git can be used off-line
With SVN you have pristine copies of the files available in the admin-areas which allow, e.g., to see the local uncommitted changes without connection to the SVN server. But if you have to commit your changes, you will need the network connection to the SVN server. With Git you can commit your changes as you like, because you have your own copy of the repository locally available. Only if you want to synchronize your repository with an external one, you need the network connection.
Git has incredible Log performance
Because Git has its own repository locally available, showing a log is a very fast operation. It is not necessary to transfer all the information over network. (We have put quite a lot of effort into SmartSVN’s Log Cache to obtain similar performance.)
Git versions files, SVN also directories
Git, just like CVS, versions only files. You can’t store an empty directory in the repository like with SVN.
Git has just one location for its admin files, the .git directory in the root of your working tree. SVN currently scatters its .svn directories over the whole working copy. This makes restructuring (moving or copying) files or directories with Git a no-brainer — with SVN you always have to take care to not move or copy the .svn files to not screw up your working copy. A side-effect is, that reading a Git working tree is much faster than reading a comparably large SVN working copy.
SVN supports file or directory properties, Git doesn’t. These SVN properties allow, for example, to
- store patterns for files to be ignored (you can define what files/directories should be ignored, but only using .gitignore files similar to the .cvsignore files in CVS)
- define the file type for certain files
- define the line separators which should be used for files
- define URL patterns for the issue tracker, so an SVN-client like SmartSVN can detect issue numbers in commit messages and show them as links
SVN has a clear definition of the encoding to use for storing file names or commit messages in the repository (UTF-8). This makes it very platform-independent.
You can configure Git to use some special encoding, but it does not enforce it. This reduces Gits inherent platform-independence significantly.
SVN does not have a special tag or branch feature, but the ability to create light-weight copies of whole directory structures can be used in combination with a special repository structure to achieve that. Unfortunately, a lot of SVN users don’t follow the standard repository structure suggested by the SVN team and reinvent their own. This makes it hard for tools like SmartSVN to "transparently" support tags and branches.
Git supports tagging and branching as a native feature. In combination with the locally available repository, this has the outstanding advantage that you can create as many local branches you like, e.g. to implement larger features, without the need to store such “shelves” in the central repository.
With SVN usually a couple of projects are stored in the same repository, separated only by a certain repository structure. Users can easily check out only certain parts of a larger repository. With Git you have one repository for one project. Everyone working on the project needs to have the complete repository.
With SVN it is very easy to refer to a repository state by a revision (a plain number). Git instead uses hash-codes which are hard to read and impossible to remember for humans.
When working frequently with binary files, SVN’s locking feature is a convenient way to exclusively reserve a certain file for editing for a while. Due to its distributed nature this is not possible with Git.