19

TL;DR: Why use something like Apache Archiva or Sonatype Nexus as an artifact repository instead of Subversion?

The build system I use currently has a lot of binary blobs (images, sound files, compiled binaries, etc), both as input and output to our builds. Our system for managing these is very ad hoc; some are checked into our Subversion repository alongside our code, some are stored elsewhere outside any formal version control.

I'm looking at consolidating this, so we have something that's more self-consistent and easy to use, and which separates binary artifacts from code.

Google tells me there are a selection of artifact repositories available (Archiva, Nexus, Artifactory, …), but from reading around, I can't see any advantage to using these over Subversion. That will look after the binaries for us – it already does that for some of our binaries, we'd just want to rearrange the repository layout to separate them from code – and has the notable advantage that we already have Subversion servers and expertise.

So. What's the advantage of using a dedicated artifact management system over using a general version control tool like Subversion?

Improve this question
2

2 Answers 2

Reset to default
13

Short answer: Generally, you don't need a history of binary artifacts and changes to those artifacts, you just need specific versions.

Longer answer: Every time you commit a small change to a binary file, version control systems don't have any way to create a delta -- a diff between the two files -- so it creates a whole new copy.

In a CVCS, like SVN, that's not such a big pain, because you only have one central copy of your repository -- your local copy is only one version. (Although, even then, your repository can become very large, making checkins slower.) But what happens if you later switch to a DVCS, where every copy of a repository has the full history of every file? The size of changes becomes very relevant there.

And what does it give you in return for the pain? The only thing it offers is being able to go back to a previous version of your repository and know that you have the correct binaries for that version.

But do you need the whole binary in your repository to do that? Or can you get away with simply having a text file, telling the build process which versions to pull from another repository elsewhere?

The latter is what is offered by artifact repositories generally.

In addition, some of the more professional ones, such as Nexus, will also give you information about licensing for third-party artifacts, so that you don't risk falling afoul of some subtle clause in what you believe to be a FOSS library.

Improve this answer
5
  • Ok, I should avoid using my current Subversion repository as an artifact repository, but why not set up a new Subversion repository? That seems to have all the same advantages and disadvantages; an artifact repository would presumably have the same issues about storing large binary data.
    – me_and
    Commented Jan 23, 2013 at 9:47
  • @me_and: You could do that. But then you've got to manage which revision provides which version of the artifact. Why give yourself that extra work when an artifact repository does it for you? It's like saying "So I could use Notepad to write my code? Why bother with Eclipse then?" Also, you'll never be able to truly remove old versions to save space. You can with an artifact repository.
    – pdr
    Commented Jan 23, 2013 at 11:12
  • 1
    To emphasise and extend the answer by @pdr, if you were to use svn as a binary artifact repository, you will likely run into storage problems because svn is designed not to delete data ever. At one place I worked we used svn for artifacts storage, and we regularly exceeded storage limits because it was hard (not impossible, but tricky) to remove old unused artifacts from the store. Native binary repository tools like Artifactory and Nexus allow deletion of unneeded artifacts.
    – Matthew Skelton
    Commented Mar 17, 2014 at 13:07
  • 4
    Correction: Subversion uses binary deltas internally (and AFAIK only those). I did experiments many years ago with storing MS Office files and it was extremely effective. Repository size grew very slowly, even when heavily re-shuffling 200 PowerPoint slides. But the effectiveness of the binary delta algorithm will vary heavily by file type and I think the lack of retention policy is the real issue here (something you could work around with a filtered dump/load, but then you start writing your own solution).
    – Peter Becker
    Commented Feb 19, 2015 at 23:00
  • 1
    "version control systems don't have any way to create a delta" - the problem is they do exactly that - since 2006... subversion.apache.org/docs/release-notes/1.4.html#svndiff1 en.wikipedia.org/wiki/Xdelta
    – RnR
    Commented Oct 26, 2017 at 9:36
2

We use SVN as a repository for release builds and it does very well. We have in one release repository better than 30gb of various release builds and it performs well pulling builds out for deploy.

some of the advantages of doing this are..

  • Binaries added to SVN are compressed nearly 60-70 percent on avg saving space.
  • SVN serves as a library (artifactory) for releases and the repository is backed up for Disaster Recovery purposes.
  • SVN via https allows for secure delivery of release code into a DMZ.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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