I’ve now uploaded my Subversion Configuration Suite (svn-meta) repository to Google Code so that the files are publicly available for anyone to use.
Archive for the ‘Version Control’ Category
By default, Subversion tends to regard UTF-16 files as binary. It assigns them a MIME type of application/octet-stream. As a result, when an attempt is made to merge a change from a branched version of the file, there is always a conflict that must be hand-edited.
However, there is a solution. By giving the UTF-16 files a correct MIME type, SVN is able to perform merges just like a basic text file.
Here I give Linux commands to allow the searching for filenames or strings within files without descending into the <.svn> subdirectories.
Suppose you have a set of changes on a Windows machine ready for commit. However, before committing, you’d like to check compilation on your Linux box. So, you create a patch file with a command such as
C:\my-dir> svn diff > patch.diff
Having copied the patch to your Linux box, you try the command
/home/me/my-dir$ patch -p0 < patch.diff
Unfortunately, you see many problems of the form
Hunk #1 FAILED at 234.
What is wrong?
If you have a collection of SVN repositories with common hook scripts, it makes sense to have a single copy of them in a separate directory (say _common_/) alongside the repository directories.
The hook files can then just be ‘wrappers’ that call out to the real scripts. To make things really easy, there’s no reason why those wrappers couldn’t be identical.
In this post, I describe why Subversion sometimes seems to commit too much.
Suppose that you have an SVN repository
in which you have a project
to which you wish to add some source files from a third-party source
(SVN or otherwise). You wish to make some modifications to that source specific to your project, but also to be able to take advantage of any future bug-fixes or enhancements to the 3rd-party source.
Here is a suggestion for how this might be managed.