Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We tried Subversion in several projects with clients. It has worked out better than I hoped for, but there are some rough edges.

Background:

  • The application will automatically register everything it needs so it it safe to just copy if from one computer to another.
  • It includes a lot of setting files both in text and binary (vector images).
  • The application is installed locally on every computer (so it can be used without network access).
  • The client updates files and we update files for them.

The current solution is that work with a Subversion repository on one of our web servers. They install TortoiseSVN if they are need to update files, otherwise they use a bat-file with a call to the command line client.

Since we introduced Subversion we have had zero problems with an installation being out of sync. We have also been able to trace when some messed up the settings (and figure out why it happened).

The problem:

Occasionally you get a conflict. Mostly it is because a novice user changed one of the settings by mistake. Is there a svn-client that makes it easy to resolve conflicts for novice users?

(The current solution at one of the companies is to delete the whole installation and perform a new checkout)

Edit: The project is normally a customized version of our standard application. The number of users at the customer location is 2-10.

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

In these cases, svn export is your friend as provides a 'clean' snapshot of the code. My suggestion is to stage your deployments this way for testing and production. This will help you find commit problems like missed check-ins or conflicts since you're only getting files at a particular revision.

To prevent some of these problems in the first place, especially if you're stuck with svn, try using a production branch. The production branch is maintained by an experienced dev, who can use a multi-way diff tool to pull changes from the branches of developers. As pointed out by others, svn merge (or even update) can be error prone, so this work flow allows changes to be selectively merged, which is how dscm's (as described by Richard) work.

share|improve this answer
    
Good suggestion, but one advantage we currently have is the small updates. Some clients do multiple commits every day (they add settings). The export would require a full download. –  Peter Olsson May 11 '09 at 17:26
    
In that case, you can always diff the two trees and export only the modified files ;) –  Dana the Sane May 12 '09 at 2:51
add comment

One of my fustrations of Subversion is it sees everything as a series of versions, other version control systems such as Mercurial look at changesets (as mentioned in the latest Stack Overflow Podcast). This facet of Subversion makes merging inherrently difficult as it dosn't really know what has changed.

As a solution, which isn't much better than your current solution I would suggest running svn revert to reset the install before updating.

share|improve this answer
    
Thanks, I probably add revert for some clients. For others I'm still afraid they will loose stuff, even if they shouldn't do any changes. –  Peter Olsson May 11 '09 at 17:28
add comment

The nice thing about a checkout vs. export is that you can see what changes were made by users working on the checked-out copy.

If you want an automated solution, you can have your deployment script save off a copy of the changes to some location (or email them to you) using svn diff and then do a revert before the update.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.