SVN, GIT or Mercurial for local servers [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I am开发者_如何学C looking to install on our local server a version control system. I've been looking at the pros/cons of the SVN and GIT, and even Mercurial.

We have about 30-35 different websites currently. Would I create 1 repo that contained all of them as folders? Also which would be better to handle all of these as individual website projects? GIT or SVN?

I am also going to have to install this on our Linux server, and create development sandboxes for developers. The people involved also use Windows and MAC.

I'm just looking for recommendations from experience, also instructional links on how to install them locally on the server.

As for APPS, I believe TourtiousGIT/SVN is good on windows, and Tower and Versions are good on MAC.

Let's try a balanced comparison, based on the premise that in your scenario you're probably not going to need any of the advanced features anyway.

Comparison

Storage

Layout on filesystem: SVN requires two things, a working directory and a repository, for working with your data. Not only does this impose unnecessary duplication of metadata, but it makes things slightly more unwieldy. Both Git and Mercurial can keep your complete history inside the working directory (every working directory is a full repository). This is not too relevant if you don't intend on having a checked out copy of your files on the server (but it's a bit more complicated than that, anyway, so keep in mind that there might be other situations in which this whole bullet point does not apply at all).
Cluttering of working dir: SVN adds .svn subdirs in every subdir of your repository; Git and Mercurial only add a single .git/.hg directory at the top level.
Space consumption: Git and Mercurial use storage mechanisms that tends to be much more efficient than SVN's. The downside in Git is that the repository has to be optimized occasionally (which tends to be reasonably fast if you don't have extremely large files); I have no idea whether this is necessary for Mercurial but I suspect it isn't.

Conclusion: I recommend Git or Mercurial.

Features

Since you probably won't even need the way better merging capabilities of Git/Mercurial, I don't see this as a deciding factor. This does not apply if you are planning on working on several sets of changes simultaneously; in that case, Git/Mercurial will probably make things much easier on you.

Speed

Git and Mercurial are notoriously faster than SVN, especially since their design allows many operations to be performed locally.

Looking at old stuff: in SVN looking at your history of changes means that SVN has to connect to the remote repository and look there; in (for example) Git the history usually displays before SVN has even established that connection.
OS-dependent: many of Git's optimizations apply mostly to Linux; you may experience worse performance on, say, Windows. The same might be true for the other contenders to a lesser degree, I don't know.
Transmissions: Git and Mercurial send and receive new changes much more quickly than SVN in almost any scenario.

Conclusion: Git and Mercurial are preferable if you like things fast. On Windows Mercurial might be a better choice, but please consult/perform actual benchmarks if you want to be sure.

DVCS

Git and Mercurial allow developers to continue working on their things, and organise them in a sensible set of commits, even if they are not currently connected to your network. In SVN, commits can only be made at the same time as they end up on the server, so SVN users tend to use more monolithic (and thus more difficult to understand) commits. At least Git, on the other hand, even has a tool for quickly finding the commit that introduced a bug, using binary search. Again, SVN might come out on the bottom here.

Complexity

I'm a huge fan of Git and I'll easily agree that Git is not the most user-friendly VCS, at least if you don't understand its design. For more advanced use cases, I believe that the toolchain makes up for that; in your case, you might prefer Mercurial or SVN unless you expect to be using the same VCS for more complex projects in the future.

Tools, interfaces

I don't know Mercurial very well, so I'm not very familiar with what interfaces there exist for it. In fact I don't use any fancy-shmancy interfaces for Git, either, but I believe that there are plenty of tools for all of the contenders that allow basic usage for, shall we say, people who don't appreciate command lines. However, I'd strongly recommend that you do a bunch of small tests before you spring anything specific on your team.

Your questions

Repositories tend to be structured differently for the different systems. In SVN it's okay to have a whole bunch of projects inside the same repository; Git and Mercurial strongly prefer having one repository per project. For shared code, Git has at least three tools (two of them third-party) for using external repositories, Mercurial probably has something as well. I know SVN has something like that, anyway.

If you do manage them as individual repositories, I would probably recommend Git or Mercurial because, as already said, they tend to have less overhead per repository.

Installing Git/Mercurial/SVN on your server is probably easy if you use any of the bigger Linux distributions; there are almost certainly ready-made packages available. If you anticipate having to manage a number of repositories with different per-user access control, there is a nice management system for Git called gitolite. Managing several repositories can be a bit of a hassle without something like that.

I would say don't use SVN because in my opinion the DVCS ability to do branching and merging is almost essential. Having never used hg I would recommend git. To learn git give the first couple chapters here a read.

http://progit.org/book/

After you get it setup I would just setup a different repo for each site and use a development branch with git and just merge it to master when you are ready to launch. Check out gitflow for a bit more on a workflow for using git.

http://nvie.com/posts/a-successful-git-branching-model/

That is a post about the workflow and a link is on there if you want to install extensions for git. There is also a couple of video tutorials around on using it as well.

You might also checkout tekpub for their git series if you are more of a visual learner.

http://tekpub.com/productions/git

Good luck.

If all you're doing is local development (that is, within your network.. not just on one machine), then SVN is probably the best solution. Even if you have a few distributed developers, if all they need to do is connect to a central repository and check files in and out then SVN is a fine tool. Certainly, SVN has it's own quirks and gotchas.

GIT adds a ton of complexity, and it has a very high learning curve because they tend to redefine comon workflows and even meanings of common vcs terms. Plus, GIT adds extra steps to the process (syncronizing local repositories with the server). SVN has more mature IDE integration, and the tools work a lot more smoothly. TortoiseGIT is not very mature yet.

If you decide you want to move to GIT later, there's lots of tools to import SVN into GIT, so there will be no lost work.

GIT is designed to allow lots of disparate people to work independantly and then merge and syncronize their changes. If you don't need that, use SVN.

GIT has a number of advantages over SVN, but SVN also has it's advantages. For example, SVN uses diffs, while GIT uses snapshots. This means GIT repositories can be much larger SVN repositories with the same data in them. Basically, GIT stores each changed copy of the file in its entirety, while SVN only stores the delta. Make one change in GIT to a 1MB file, and it stores another 1MB file. make one change in SVN to a 1MB file, then only the change (plus some overhead) is stored. Depending on the kind of data you're storing, this can be significant.

Svn vs. git is well into holy war territory, and therefore really off topic, not to mention frequently duplicated. Your branching model question is much more amenable to objective answers, though. Here are some general guidelines:

Code that is common between websites should be drawn from a single official repository. If you ever find yourself going outside your source control to propagate the same change, like copying and pasting a file between folders, it's not set up correctly.
Code that is customized for different websites should ideally be architected so it's in separate directories from the common code. This makes common and custom code fairly independent, which lets you assemble your configuration using git submodules or svn partial checkouts.
If you can't separate the architecture for historical reasons, you can maintain a branch with each individual website's customizations. However, whenever you make a change to the common code that you need to propagate to all sites, you run a much higher risk of merge conflicts that must be manually resolved. You also have to be careful in which branch you make common code changes. Note that the possibility of merge conflicts isn't really a good excuse to forgo source control branches altogether. Your architecture means those conflicts are happening anyway, so you may as well let your source control help you out with the merge. That way you only have to worry about the real conflicts.

First off, AFAIK SVN is the only one that will allow you to store all your sites in a single repo and selectively check them out individually (see sparse checkouts). DVCSs (by their off-line, all-local nature) rely on the entire repo to be present.

The next thing to note is that git support on Windows is .. not what most Windows users are used to, and I'm led to believe that TortoiseGit isn't 100% ready for prime time. Mercurial is probably a better choice for a Windows DVCS.

I think the thing you need to do is sit down and work out the workflow your team uses - how much merging do you do, how much parallel development, how much is your master repo used as a definitive source, how much offline work do you do, etc. If you don't do any of the things that DVCSs excel at, then SVN is probably the better choice for you - better tools and simpler to understand usage. If you do some of the things that SVN isn't good at (offline working, massive amounts of refactoring) then I'd probably go with Mercurial.

Git is your best option. You may have a bit more of a learning curve but you'll end up more productive in the end.