3

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.

Improve this question

3 Answers 3

Reset to default
3

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.

Improve this answer
2
  • 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, 2009 at 17:26
  • In that case, you can always diff the two trees and export only the modified files ;)
    – Dana the Sane
    May 12, 2009 at 2:51
3

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.

Improve this answer
1
  • 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, 2009 at 17:28
1

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .