问题
Both SVN and Nexus are widely used as repository for source code during development and integration. That said, why do we really need to use Nexus when we can have our repos set up via SVN? Even SVN has a proper version control schema and its widely acclaimed.
Skimmed through google , but nothing seems to provide a clear difference. Please clarify me.
回答1:
Imagine an automobile factory. In go blueprints like this, out comes a vehicle like this. SVN is like the filing cabinet where you store the blueprints, while Nexus is like the warehouse where you store the finished product.
Now there should be a 1-to-1 correlation between the input and the output. But let's say you change something about the environment of the factory itself. Then even if you use the same blueprints, the finished product might come out different or wrong.
Therefore, as a general rule, it's better to just work with the finished product from Nexus as much as possible, which has already been tested for quality.
Hope that helps.
回答2:
You can store everything in subversion. A subversion checkout would capture your file system at a point in time. In my opinion this approach has two main problems
- SCM systems are generally designed to store textual data
- Storing releases in your SCM creates a tight coupling between how your software is built and how it is deployed.
Subversion is one of the very few SCM systems that has an efficient mechanism for binary file storage, but for me the deal-breaker is using SCM's for deployment. I have seen development teams that cannot upgrade from tools like CVS and Subversion, because these tools are either directly or indirectly required to release and install software on customer sites.
While we might tag the source code at a point in time, but it is most important to keep a copy of the binary file you have sent to your customer. The same source code rarely creates exactly the same binary output. For example a metadata file might contain a build date, resulting in a zip/tar archive that has the same functional result, but a different checksum. Checksums are really important for auditing deployments, to prove the correct file was distributed and sometimes to reverse engineer the release version.
Rather than continue a favourite rant, I provide a number of blog articles on this subject:
- Why Nexus for the non-programmer
- Reasons to Use a Repository Manager
- Distributing Binaries: Why not just use a Shared Filesystem?
- Benefits of a repository manager part 1
- Benefits of a repository manager part 2 caching and collaboration
- Benefits of a repository manager part 3 continuous build deployment
回答3:
Subversion is source code management. You check in and out your source files from there, and it can diff text based source files, allow you to crete tags across an entire release, and branch.
Nexus is usually used for jar distribution. You can store artifacts, but they're usually compiled and unlike Subversion, you can end up replacing an older artifact with a newer one, and have no means of tracking the changes.
You can use both Subversion for source control and then use Nexus for what it's original purpose: To store compiled Jar files in a local Maven repository.
Can you store jar files in Subversion? Sure you can, but what does it get you? Jar files take up a lot of room, and you cannot see the changes from one to the other very easily. Instead, they take up a ton of room. It isn't unusual for jars to take up 80% to 90% of a Subversion repository.
This is why we use something like Nexus to store our jars, and then use Maven or Ant with Ivy to fetch them when we do our compiling.
回答4:
They're both widely used and they're both repositories... but svn is a repository for source code where nexus is a repository for artifacts (binary files like jars). They're very much complimentary systems.
来源：https://stackoverflow.com/questions/21601338/whats-the-difference-between-nexus-and-svn