3

I currently have a large problem on one of the file servers I manage for an Accounting Firm.

Quickbooks has a tendency to create multiple files of the same thing over and over to prevent data loss. This is a good thing when you handle just a few files. But at an accounting firm it becomes a problem.

Some of the older clients have 5-10 files in their respective folders, each with a different cut off date. Because of user error some of these file aren't labeled properly with their correct cutoff dates.

This is where Subversion came to mind. Using the revision system would allow for 1 file to be master and have all of its revisions. Has anyone ever tried this with Quickbooks files?

I've only used SVN with code for applications making each file size much smaller. How does SVN stand up with larger files like 10-25MB? I'm not exactly sure how SVN handles revisions - does it keep a duplicate of the files and duplicates the disk space space needed?

Kamil Kisiel
  • 11,946
  • 7
  • 46
  • 68
Jorge Fernandez
  • 143
  • 6

4 Answers4

2

I can answer one of your questions: We use Subversion for 20mb binary files regularly, and it handles them just fine. Obviously you can't do a diff or a blame on them, and thus you can't have any concurrency. We use reserved checkouts on our binary files to work around this.

The Subversion Book does a really good job of explaining how Subversion works and stores its files. The only part I can remember that's relevant is when you do branching it does not store a whole copy of each tree, but whether or not this applies to binary files I'm not sure.

Check it out at http://svnbook.red-bean.com/

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
1

I think a DVCS (like git, mercurial, or bzr) might be more suited to your application because it means you don't need a separate repository for the files... the working copy is in the same place as the repository. Admittedly setting up a repo in svn is easy, but it's just one more thing to manage... and all sysadmins know that one less thing to manage is a Good Thing.

pjz
  • 10,497
  • 1
  • 31
  • 40
0

I've been keeping QB files under svn for years now -- mostly with tortoise on Windows. It works, but QB is not particularly well-behaved with respect to touching files, so you just need to be careful not to end up with spurious conflicts.

For example, merely opening the file touches it, leading svn to think there's been a modification. Also, QB can insist on touching .nd files even when they're not remotely its business.

But it does work. And 20MB+ is not a problem.

0

Subversion can handle files that are large enough for your purposes... I have committed files in the 100's of MBs and had it work; had some issues when I got into the 2GB range though. (Nevermind why for now.)

An approach that might work well for you, depending on your setup would be to provide webdav access to the repository. OS/X makes using those pretty seamless; if you're running Windows clients you'll have to look into details, but there should be something. Webdav would essentially give you a shared folder that looks like part of your filesystem. You save the Quickbooks file to that share and work from it. All writes wind up as commits to svn, so there aren't any additional commit steps. Yes, you'll generate a large number of commits pretty quickly, but that shouldn't be a problem.

As for how svn stores its files, it gets kind of complicated, but it essentially stores deltas so you don't have hundreds of copies of a file when you have hundreds of commits.

retracile
  • 1,260
  • 7
  • 10