Just did an update that caused a conflict so reading about Subversion’s handling.

One thing it does is create 3 copies of a conflicted file. One with an extension of mine, which is what the file looked like before any conflict information was inserted. Two copies are for the revision prior to doing the update, and the revision the update just retrieved. This way you can see where you were, where Subversion had problems, and where the file stands. Much better than CVS’ handling.

The only thing here is the Subversion diff utility isn’t very good. Minor changes in 2 places of a group of lines, and it just shows huge chunks of deletions and additions, rather than marking lines that have changed. I’m going to have to find a diff utility that can work with Subversion so I can replace it…

Another big difference between conflict resolution here and CVS is CVS assumed the conflicts were gone if all the conflict markers were removed from the file. With Subversion, you have to explicitly run svn resolved on the file in question. This will tidy up the 3 temp files created above, and let Subversion know you are satisfied with the results.

Just finished looking at the reason for the conflict, and basically in my case it was the poor diff utility. Since it couldn’t accurately resolve minor line deletions, it needed to flag it as a conflict. REALLY need a better diff!!!

Today I figured out how to handle ignoring certain file types when doing a status check. There are 2 methods of doing it. One is in the global configuration, namely the config file stored in Application Data\Subversion (assuming windows).

The other is to define a value for the property on a directory, and it will only affect that directory. The global would have to be set by all users. The property on a directory only has to be set once, and then everyone that checkouts out the directory will have the same ignores. The only problem is it appears the ignore only works on the directory it’s assigned to. It doesn’t affect sub-directories (or at least I haven’t figured out how to have it do that just yet).

Anyhow, the procedure is quite simple. Using svn propedit svn:ignore {directory} and it will bring up a file in your defined editor. If the directory already has values for the property, these will show in the file. Otherwise it will start empty.

Then you just list the filetypes and directory names you want ignored, each on one line. It appears to be case sensitive, so you have to do *.bak *.BAK etc to ensure full coverage.

As I said, it also appears necessary to do it on sub-directories as the property appears to only apply to the current directory.

Been using it a bit more, so have some further comments. It’s definitely setup to allow for offline work. Basically having a local copy of the repository attached to your working directory means all diffs and reverts could be done without having server access. In my case, this doesn’t matter as I’m running locally, but could be very useful if you wanted to do some work away from server access.

One shortcoming I’ve come across is removing a group of files. Quite often you will delete a file outside Subversion, and then want to remove all the deleted files from version control. With CVS, all you did was do a cvs remove in the directory, and it would schedule all the missing files for removal. Subversion lists the missing files, but I haven’t found a way to tell it with one command to remove all the missing files from version control. I have to do a svn delete on each file. Hopefully I’ll find a way to do this.

Just recently started using a CVS replacement called Subversion. Thus far, seems very good.

It’s big advantage is it recognizes directories as well as files. Uses binary differences for binary files, rather than storing a completely new copy of the file. Allows for renaming/copying of files and directories. Understands what deletion of a directory means.

The other big thing is it understands a big change. i.e. it treats a commit of multiple files as a unit of work. The revision numbers are updated for an entire directory when a commit is done, and are global across a repository. This means can see all the files changed for a given commit, rather than CVSs approach of merely incrementing the revision of each file individually.

The claim is that Subversion is more network friendly. It does this by basically keeping a local copy of the files in your working directory. The feeling is that hard drive space is really inexpensive, and network traffic is best minimized.

Supports branching more elegantly than CVS ever did. A branch is created by making a copy of a repository directory. Has commands for retrieving some changes and merging, but I haven’t used this portion yet, so don’t know how useful it is.

There is a tool for converting a CVS repository to an SVN one. I tried running it, but I must have mixed up my tags when I originally created my repository as it complained. Since I don’t really care that much about my change history, I didn’t bother trying to track it down to get my repository imported to SVN. I just started fresh.

Well worth a look.