No question that the majority of debates over programmer tools distill to either personal choice (by the user) or design emphasis, that is, optimizing design according to particular uses cases (by the tool builder). Text editors are probably the most prominent example--a coder who works on Windows at work and codes in Haskell on the Mac at home, values cross-platform and compiler integration and so chooses Emacs over TextMate, etc.

It's less common that a newly introduced technology is genuinely, demonstrably superior to the extant options.

Is this in fact the case with version-control systems (VCS), in particular, centralized VCS (CVS and SVN) versus distributed VCS (Git and Mercurial)?

I used SVN for about five years, and SVN is currently used where I work. A little less than three years ago, I switched to Git (and GitHub) for all of my personal projects.

I can think of a number of advantages of Git over Subversion (and which for the most part abstract to advantages of distributed over centralized VCS), but I cannot think of one contra example--some task (that's relevant and arises in a programmers usual workflow) that Subversion does better than Git.

The only conclusion I have drawn from this is that I don't have any data--not that Git is better, etc.

My guess is that such counter-examples exist, hence this question.

  • 3
    @jokoon: Efficient in terms of what? Surely not speed since even fast Ethernet is slow compared to local operations.
    – maaartinus
    Commented Sep 30, 2011 at 20:59
  • 4
    See this StackOverflow Q: Why to use SVN? Any hidden pros (over GIT/Mercurial/Bazaar) there?
    – detly
    Commented Oct 1, 2011 at 5:00
  • 4
    I've always thought Git was highly over-esteemed. It's a fad, and programmers are not impervious to fads - despite the many oppositions to this thought. Like everyone else in this world, everyone wants the shiny new toy (Git). Git may be good - or even great to some people - but it's never been better than SVN when thinking objectively.
    – bought777
    Commented Sep 24, 2012 at 20:41
  • 3
    I thought SVN still good to use, the learning curve is good then GIT.
    – Cheung
    Commented Nov 9, 2012 at 8:13
  • 5
    This question was recently put on hold as primarily opinion based. That classification is wrong; note that the question was open for a long time; that there are many questions about the virtues of DVCS, and that the question doesn't ask whether it's better (opinion), but what it does better. The differences are not opinion but whether the overall product is - that's tricky (but not the point of this question). Commented Nov 18, 2013 at 10:28

20 Answers 20


Subversion is a central repository

While many people will want to have distributed repositories for the obvious benefits of speed and multiple copies, there are situations where a central repository is more desirable. For example, if you've got some critical piece of code that you don't want anyone to access, you'd probably not want to put it under Git. Many corporations want to keep their code centralized, and (I guess) all (serious) government projects are under central repositories.

Subversion is conventional wisdom

This is to say that many people (especially managers and bosses) have the usual way to number the versions and seeing the development as a "single line" along time hardcoded into their brain. No offense, but Git's liberality is not easy to swallow. The first chapter of any Git book tells you to blank out all the conventional ideals from your mind and start anew.

Subversion does it one way, and nothing else

SVN is a version control system. It has one way to do its job and everybody does it the same way. Period. This makes it easy to transition to/from SVN from/to other centralized VCS. Git is NOT even a pure VCS -- it's a file-system, has many topologies for how to set up repositories in different situations -- and there isn't any standard. That makes it harder to choose one.

Other advantages are:

  • SVN supports empty directories
  • SVN has better Windows support
  • SVN can check out/clone a sub-tree
  • SVN supports exclusive access control svn lock which is useful for hard-to-merge files
  • SVN supports binary files and large files more easily (and doesn't require copying old versions everywhere).
  • Adding a commit involves considerably fewer steps since there isn't any pull/push and your local changes are always implicitly rebased on svn update.
  • 55
    "Subversion does it in one way" -- I thought so too, until I started my current job. In my current job, my boss, who claims not to have trust issues, configured the server to require locking. No merging happens in our system. Files are locked on the repository and nobody else can write them without the lock. Top-down control, for those whose constitutions demand it, is definitely something svn does better than git.
    – Dan Ray
    Commented Sep 30, 2011 at 12:16
  • 14
    One advantage of the central repository is ease of backups. If all the checked in code is in one place, and that one place has off-site backup, you don't lose everything if your office burns down. With a DVCS, unless you do off-site backups of the developer's machines, you lose everything that hasn't been pushed to the server that's backed up off-site. Commented Sep 30, 2011 at 12:27
  • 95
    Why can't git be used in a centralized manner? Just have one central repository, and your devs can clone and pull and push like they checkout and update and commit. Commented Sep 30, 2011 at 14:12
  • 29
    @PaulTomblin - Depending on workflow, Git can provide better backups. For instance, we use private github repos and I frequently push my code up to feature branches. If my coworkers do git fetch origin, each of them has a backup of my code, along with whatever backup Github itself provides. (We regularly prune merged branches, both locally and on Github.) Commented Sep 30, 2011 at 15:27
  • 56
    You seem to imply that central is more secure for large companies or governmental work. This is simply not true. If you have a copy of the code on your computer, you have a copy of the code. It doesn't matter if it came from a central server or a central file system holding a DVCS repository. Commented Sep 30, 2011 at 17:32

One benefit of Subversion over Git can be that Subversion allows checking out sub-trees only. With Git the whole repository is a unit, you can get only all or nothing. With modular code, this can be quite nice compared to Git submodules. (While Git submodules have their place, too, obviously.)

And a small tiny benefit: Subversion can track empty directories. Git tracks file contents, so a directory without any file won't show up.

  • 11
    Working with sub trees is IMHO the only thing SVN has over GIT. Point taken, empty directories are nice, but not necessary either (and can be worked around). If git submodules and git subtree were less confusing there would be nothing holding many people back from migrating to GIT. The other advantages some people mentioned boil down to (developer) mentality. E.g. if you need top to bottom, that's fine. I wouldn't have any work for you though.
    – Till
    Commented Sep 30, 2011 at 15:13
  • 3
    It's funny how these are the only kinds of things that can be argued in favour of SVN (and other centralized version control) Commented Mar 7, 2012 at 6:39
  • 2
    Why is it funny? - Newer systems learn from older systems. There's even a benefit with RCS over git: The history files can easily be edited by hand and you can have per-file branches. But eolution involves that features are lost ...
    – johannes
    Commented Mar 8, 2012 at 22:03
  • 4
    I heard of a games company that uses SVN over GIT for exactly this reason - when your talking about a repository many GB in size, it suddenly becomes important!
    – James
    Commented Jun 5, 2012 at 23:45
  • 19
    As of git version 1.8.0, you can now use the git subtree command to accomplish exactly this. Last subversion advantage bites the dust :) Details here: github.com/gitster/git/blob/… Note: Even though this is a link to a github project, git-subtree is now part of the core git distribution.
    – Carl
    Commented Nov 19, 2012 at 4:25

I can think of three. First, it is quite a bit easier to grok, especially for non developers. Conceptually it is much simpler than DCVS options. Second is maturity, especially TortoiseSVN on Windows. TortoiseHg is catching up fast though. Third, the nature of the beast--just an image of a filesystem where you can check things out from any level of the tree--can come in pretty handy in some scenarios -- like versioning a variety of widely different configuration files across dozens of servers without dozens of repositories.

This isn't to say we aren't moving all development over to Mercurial.

  • 26
    Being easier to grok is an important advantage, since that makes it more likely to be used. SVN is certainly way better than no version control, and if someone is stubborn about old ways then maybe SVN is the best choice for them.
    – jhocking
    Commented Sep 30, 2011 at 11:58
  • 12
    @jhocking: I don't love SVN, but if someone tells me "I don't like these new DVCS things, so I'll stay with CVS", then I'll definitely recommend it: it's the easy road to at least partially sane VCS ;-) Commented Sep 30, 2011 at 12:10
  • 4
    @jhocking New ways aren't always the best for every circumstance. It brings to mind the old story about NASA spending millions of dollars developing a pen that can write in 0g. The cosmonauts on the other hand made due with pencils. Sometimes the old ways are better, NOW GET OFF MY LAWN!
    – maple_shaft
    Commented Sep 30, 2011 at 12:14
  • 25
    @maple_shaft, and sometimes they aren't. snopes.com/business/genius/spacepen.asp Commented Sep 30, 2011 at 12:19
  • 3
    Easily grokked is highly subjective, and is largely based on how you try to fit the new knowledge into what you already may know. It also makes a great deal of difference what your source of learning is. If you are going by man pages, good luck. If you are being taught by a good teacher who already groks it, you've got it made. I found git made tremendous sense after watching several good videos on YouTube. If you get your understanding from someone who has already distilled it down to the simple core, then anything is easier to understand.
    – WarrenT
    Commented Aug 30, 2012 at 23:13
  • SVN repositories are more manageable from a manager's and administrator's point of view (ACL + authentication methods + hotcopy + mirrors + dumps)
  • SVN *-hooks are easier to implement and support
  • svn:external has more power and flexibility than submodules
  • Filesystem-based repository trees are easier to use than monolithic repositories with logical-only separation
  • SVN has more different client-tools
  • SVN has third-party usable web-frontends, much better than Git's
  • SVN doesn't break your brain
  • 23
    Doesn't break your brain? Wanna teach me how to easily merge branches with conflicts in SVN?
    – WarrenT
    Commented Aug 30, 2012 at 23:17
  • 4
    "Better" tools / front-ends, that's a moving target. Tools improve on both sides. None of us know what tools will be available several years from now. That assessment 10 months ago might easily change over time, and might be stale now. I would prefer to see substantive answers.
    – WarrenT
    Commented Aug 30, 2012 at 23:23
  • 6
    Tree conflicts? Check. Yes or no to all options? No. Svn is designed to infuriate. Clean working copy command? No. Revert cannot clean unversioned files.
    – Warren P
    Commented Nov 16, 2013 at 15:10
  • 1
    Deleting everything and checking out again will clean unversioned files.
    – jgmjgm
    Commented Sep 28, 2017 at 17:23
  • I love your last idea, Git broke my brain :'(
    – Luke
    Commented May 7, 2018 at 16:06

I wrote this as a comment on somebody else's answer, but I guess it deserves to be an answer in and of itself.

My company's carefully-chosen configuration for SVN requires file-level locking to edit content, and never ever ever uses merge. As a result, multiple developers contend for locks, and it can be a major bottleneck, and there's never ever any chance of a merge conflict.

SVN definitely does top-down managerial control better than Git. In my skunkworks migration to Git (asking forgiveness rather than permission) I've terrified my manager many times with the notion that there isn't any software-enforced central master controlling server to which we are all slaves.

  • Centrality is a matter of myth not fact. Nobody can stop me from changing anything. With a cvcs they can stop me from centrally changing something. Same thing in a dvcs. The word commit in cvcs conflates commit and push.
    – Warren P
    Commented Nov 16, 2013 at 15:19
  • @JonathanHenson: that is definitely not the only reason Torvalds hates SVN. SVN may be centralized and may be a better CVS but that hardly make it a good software. Torvalds hates CVS / SVN not because they're centralized but because he considers they are pathetically bad software. Whether he's right or not is up to you to decide but seen the immense success of both Linux (and Android) --running on billions of devices-- and Git --which is pretty much taking the world by storm--, I'd think twice before disagreeing with him. The lecture Torvalds gave at Google on Git years ago is amazing. Commented Nov 16, 2013 at 19:32
  • lol. Your manager is right to be terrified there's no proper backup system in place. Just saying "but its DVCS so someone will have a copy" doesn't fly - I know, when I saw git used at my last place, they literally didn't have any copies of some repos. Mind you, locking can be good for some situations and git fails in this regard - unless you have a magical merge tool for images or other binary files. git only really works for text files.
    – gbjbaanb
    Commented Jan 6, 2014 at 14:27

I appreciate that you are looking for good information, but this kind of question just invites, "I think Git is so much win, and svn teh suxorz!" answers.

I tried and personally found Git a little too much for my small team. It seemed like it would be great for a large distributed team or group of teams that are geographically dispersed. I understand greatly the benefits of Git, but source control in my opinion isn't something that keeps me up at night.

I am a deer hunter, and when me and my friends go out they are armed to the teeth, bristled with ammo and high tech gear. I show up with a single rifle, seven bullets and a buck knife. If I need more than seven rounds then I am doing something wrong, and I do as well as anybody else.

The point I am trying to make is that if you are a small team working on a medium to small project and you are already familiar with SVN then use it. It is certainly better than CVS or (shudder) SourceSafe, and it doesn't take me more than five minutes to set up a repository. Git can sometimes be overkill.

  • 3
    Really? Then I'd suggest you have a look at fossil. Commented Sep 30, 2011 at 12:39
  • 8
    let's not sound the alarm at the slightest possibility of controversy. Important topics are often the most controversial and the ones most likely to invoke strongly held views. So "This kind of question" is important and the possibility of an out-of-bounds response is not a plausible to not post it. I assume the users on this Site are adults. What's more the way my Q was phrased, was if not neutral, then deferential to subversion folks--responsive answers to my Q will have to recite advantages of subversion over git, not the other way around.
    – doug
    Commented Sep 30, 2011 at 12:39
  • @SpencerRathbun, Thanks! I will have to take a look at that. It is not so much that I love svn as I have a distaste for git.
    – maple_shaft
    Commented Sep 30, 2011 at 12:46
  • 10
    @Spencer - Contrariwise, as a user of both git and hg, I would suggest mercurial for anyone who thinks git is too much. TortoiseHG would be very familiar to anyone used to TortoiseSVN (it even shares the same Explorer overlays on Windows). It's certainly a lot easier than VSS and I would be surprised if it took more than a few seconds to set up an hg repo, commit the initial state and clone it to a shared drive.
    – Mark Booth
    Commented Sep 30, 2011 at 13:16
  • @MarkBooth As stated in the original question, I think it's a matter of wants and needs. At my current workplace, there was no repo before I got there. I needed something that had all, or most, the project tools I wanted wrapped together, was easy to use, kept everything instead of deltas, and would work distributed for teams of 1 or 2 people across multiple machines. Commented Sep 30, 2011 at 14:34

My reasons:

  • maturity - both the server, and the tools (e.g. TortoiseSVN)
  • simplicity - less steps involved, a commit is a commit. DVCS such as Git and Mercurial involve commit, then push.
  • binary handling - SVN handles binary executables and images better than Git/Hg. Especially useful with .NET projects since I like to check build-related tools into source control.
  • numbering - SVN has a readable commit numbering scheme, using just digits - easier to track revision numbers. Git and Hg do this quite differently.
  • 1
    "commit numbering scheme" is only possible if you have canonical trunks. Otherwise which one gets the major numbering?
    – user1249
    Commented Mar 10, 2012 at 13:32
  • 1
    +1 the numbring in svn. This number is unique. there are tools to use this number as part of the app-versionnumber xx.yy.zz.12882 where 12882 is the svn version-number. If there is a production problem you can ask vor the versionnumber and you have the exact svn-revision where the software was build with
    – k3b
    Commented Jan 7, 2013 at 18:57

This is all relative, and like maple_shaft said, if one works for you, don't change!

But if you really want something, I'd say it is maybe better for designers, web programmers and such - it handles images and binary files a bit better.

  • 2
    How does SVN handle them better? Git considers every file a BLOB.
    – WarrenT
    Commented Aug 30, 2012 at 22:59
  • 4
    @WarrenT because of the workflows, with git you're branching and merging a lot (or why bother using it) and you just can't realistically merge binaries. Hence, you often put the "needs lock" property on binary files in SVN.
    – gbjbaanb
    Commented Oct 19, 2012 at 19:03
  • 1
    Some binaries can (theoretically) be merged, e.g., an ODT document. Commented Mar 27, 2013 at 10:32

Usability. It's not really Subversion's merit but rather TortoiseSVN's.. TortoiseGit exists, but it still has a long way to go to match TortoiseSVN.

If you asked what Git does better than SVN I would reply GitHub. It's funny how third-party tools make such a huge difference.

  • 1
    Assembla (for any supported SCM - SVN in list) is better than github, I think Commented Oct 1, 2011 at 6:56
  • there is also smartgit, GitXL, etc. now, programs that make using git way more simple
    – wirrbel
    Commented Nov 16, 2013 at 20:04
  • @LazyBadger, Never heard of it.
    – Pacerier
    Commented Mar 25, 2015 at 17:25

When you don’t need to branch and merge, SVN (with TortoiseSVN on Windows) is very easy to understand and use. Git is overly complex for the simple cases, as it tries to making branching/merging easy.

(A lot of small projects never have to branch if they are managed well. Git is aimed at the complex cases; therefore most Git documentation assumes you need to do complex operations like branching and merging.)

  • 8
    Using git branching and merging are no complex operations. I even use branches in a one-man project, even when there are no requirements for multiple version. Keeping work you can't continue at the moment in a branch, branching when you find out that trying another solution may be much better... However, I agree that git is a bit harder to learn.
    – maaartinus
    Commented Sep 30, 2011 at 21:16
  • Any time you need to do bugfixes in old versions you need branching and merging.
    – user1249
    Commented Mar 10, 2012 at 13:31
  • 1
    Why don't people consider the idea that mercurial is easier than svn or git?
    – Warren P
    Commented Nov 16, 2013 at 15:17
  • I think part of it is that as SVN has until recently not supported branching and merging without a very high cost, it has allowed programmer to stand up more to managers when they wanted to keep changing what someone is working on. A tool has to work within the polities of a company and also helps shapes a companies’ polities.
    – Ian
    Commented Nov 16, 2013 at 19:08

Well, my grandpa could use SVN on his Windows XP computer, but he'd have trouble using Git. Maybe this is more an accomplishment of TortoiseSVN over TortoiseGit, but I think it's rather tied to the fact, that Git is inherently more powerful and thus more complex, and it would be pointless to dumb it down to the same level.

Now it doesn't really matter for my grandpa, because he hasn't done any programming as of late. However, I was once on a team, where our graphic artists were using our source control as well.

And those are people who simply expect their tools to work (so do I, but I have a realistic chance to get them to work in case of failure) and be intuitive. Apart from the fact, that it would had been quite an effort to get them to get along with a DVCS, there was little to be gained. And with only two programmers in the team, it made sense for us to also just stick with SVN.

  • git is the more "philosophical" approach to version control. you start to think about semantics of commits, branches, etc. So people who want to use a VCS as a "backup" and distribution tool have a harder time, but git is not much more difficult
    – wirrbel
    Commented Nov 16, 2013 at 20:06

At work I couldn't switch the developers from SVN to any DVCS for two reasons:

  • Partial checkouts (like only three folders from different depths in the project tree)
  • File locking (binary format reports)
  • Sense of security when doing an 'svn commit'. Since commits go to the server, there's no possible screwup that I can do that will erase my changes after they are committed. In git, commits are local, so until I push, a stray 'rm -rf' and it's all over.
  • Commits are authenticated. By default in git I can tell it I'm committing as anyone.
  • Fewer commands to learn for everyday use. 'svn checkout', 'svn up', and 'svn commit' will get you pretty far.
  • Shared checkouts work a lot nicer. When you go to commit, it asks you for your username/password, you don't have to remember to pass certain command line arguments. Sometimes at work we have a shared machine with a shared svn checkout of some project. Someone might say "Bob can you look at this on this machine" and he can, and he can commit his changes as his user without any screw ups.
  • Repository layout. You can have an umbrella project and subprojects and choose what to check out when.
  • Revision numbers are incrementing integers.
  • Designed for the central repository workflow.
  • +1 for the authentication issue. Git commits need to be signed, and the signings need to be checked which is difficult.
    – Christian
    Commented Nov 16, 2013 at 22:03

Speed. Sometimes takes 10 or 15 minutes to clone a big git repository, while a similar sized subversion repository takes a couple of minute to check out.

  • 6
    But checkout/cloning is a rare operation. In most scenarios, git is faster than subversion.
    – rds
    Commented Nov 9, 2011 at 11:16
  • 6
    git clone --depth=1 is your friend if you don't care for history Commented Jan 7, 2013 at 14:53

Other people have posted some pretty good answers, but what about Permissions? Using Subversion over SSH, you can make a separate account on your server for SVN. Different developers can be given different access to different parts of the repository. Can GIT do that? I guess there is gitolite, but it just doesn't seem as flexible or robust to me, nor do I know anyone who is actually using it.

  • 2
    Others have hit this in mentioning "top-down managerial control". This is a key element for my environment - we have certain areas of our repositories that need to be locked down to read-only or even no-read for some user groups. We also need to have a single location we can point at and say "this is the authoritative master copy, if your copy doesn't match what's here, it's not official."
    – alroc
    Commented Jan 7, 2013 at 19:23
  • 1
    blessed repository of the project lead and lieutenants is giving control over who can commit. Git repo published on http-auth enabled server (using the same apache modules svn does) do authentication and say who can clone/checkout what. Sure, it's not as granular as svn per directory permissions can be, but to me it looks more like micro management than actual need. Commented Jan 7, 2013 at 20:17
  • @HubertKario - this raises the question, "Should your best programmers be spending their time checking in other people's code?" Actually, I'm so interested in the answer to this question, that I posted it here: programmers.stackexchange.com/questions/181817/… Commented Jan 7, 2013 at 20:41

I post this as a response rather than a comment.

I admit than DVCS are quite in the trend right now, but I'll try to tell why.

DVCS are better because just like lots of people have been saying, "this is the way we should have been working from the beginning". It's true, you can do with a DVCS what you used to with SVN, so in a way that makes SVN obsolete.

However, not every software project is as good as it gets:

  • Long term project have a lot benefited from DVCS, because it uses less overhead, allows much better management (branching etc), and is greatly supported by hosts like google code and github.

  • Those projects are not the only ones, there are other kind of projects that are being developed in companies without any assistance from the outside world or internet: everything is done internally, and often on a short term. A good example: a video game. Code evolves rapidly.

For the latter case, developers don't really need branching or sophisticated features DVCS can offer, they just want to share source code and assets. The code they make is not likely to be reused, because there is a deadline. They rely on SVN rather than a DVCS because of several reasons:

  • Developers have machines that belong to the company, and this might change rapidly. Configuring a repo is a loss of time.
  • If those guys don't have their own machine, they are less likely to be working on the same source code/part of the project. Plus one for the centralized data.
  • network speeds and big money allows the use of a centralized server that deal with everything SVN, it's bad practice but backups are made etc.
  • SVN is just simpler to use, even if it's the wrong way: synchronizing files on peers without redundancy is not a simple problem, and "do it the right way" just cannot make it in time if you always want it to be perfect.

Think about the game industry machine and how SVN is a time saver; people communicates much more on those projects because games are about repetitive programming and adaptive code: there is nothing hard to code, but it has to be done the right way, ASAP. Programmers are hired, they code their part, compile it, test it a little, commit, done, game testers will deal with the rest.

DVCS are made for the internet and for very complex project. SVN are for small, short term, tight team projects. You don't need to learn a lot from SVN, it's almost a FTP with a dumb diff.

  • Can you explain the game industry example?
    – johnny
    Commented Apr 20, 2015 at 23:02

Subversion and Git both encourage particular (and very different) approaches to development and collaboration. Some organizations will get more out of Git, and others will get more out of Subversion, depending on their organization and culture.

Git and Mercurial are both excellent for distributed and loosely organized teams of highly competent professional programmers. Both of these popular DVCS tools encourage small repositories, with reuse between developers taking place via published libraries with (relatively) stable interfaces.

Subversion, on the other hand, encourages a more centralized and tightly coupled management structure, with more communication between developers and a greater degree of organizational control over day-to-day development activities. Within these more compactly organized teams, reuse between developers tends to take place via unpublished libraries with (relatively) unstable interfaces. TortoiseSVN also permits Subversion to support multidisciplinary teams with members who are not professional programmers (e.g. systems engineers, algorithms engineers or other subject-area specialists).

If your team is distributed, with members either working from home or from many different international sites, or if they prefer to work alone and in silence, with little face-to-face communication, then a DVCS like Git or Mercurial will be a good cultural fit.

If, on the other hand, your team is located on a single site, with an active "team" approach to development, and lots of face-to-face communication, with a "buzz" in the air, then SVN may be a better cultural fit, particularly if you have lots of cross-disciplinary teams.

Of course, it is possible to configure Git and Hg (powerful and flexible as they are) to do pretty much whatever you want, but it is definitely more work, and they are definitely harder to use, particularly for those members of the team who would not naturally be inclined to use any form of version control whatsoever.

Finally, I also find that sharing functionality using "hot" library development under Svn (with CI & a test-driven approach) permits a pace of coordinated development that is difficult to achieve with a more distributed and loosely-coupled team.


Below are the two reasons that I still stay with SVN.

  1. The learning curve. SVN is easier than Git, even the setup (server or client too), usability, and commands.
  2. Better server packages like Subversion Edge, VisualSVN, uberSVN etc.

There are two major trends in version control right now; Distribution, and Integration.

Git is great at decentralization.

SVN has lots of tools built that integrate with it. It's common to set up your SVN server so that when you check in a fix, you mention the bug number in the checkin comment, and it automatically sets that but to an "in testing" state, and alerts the assigned tester that they need to look at it. Then you can tag a release and get a list of all the bugs fixed in this release.

The tools that do this with SVN are mature, and used every day.


In Subversion, you can edit log messages (also called "commit messages") after the commit is done and pushed. For most practical uses, this is impossible by design in decentralized systems, including git. Of course, in git you can do "git commit --amend", but that doesn't help you after your commit has been pushed elsewhere. In SVN, when you edit the log message, you're doing it on the central repository that everyone shares, so everyone will get the edit, and without the revision's identifier changing.

Editing log messages after the fact is often very useful. Aside from just fixing a mistake or an omission in a log message, it enables you to do things like update a log message to refer to a future commit (such as a revision that fixes a bug or completes the work introduced in the current revision).

There need be no danger of losing information, by the way. The pre-revprop-change and post-revprop-change hooks can save a history of the old messages if you're really concerned, or send out emails with the log message diff (this is more common, actually), so that there's an audit trail.

  • 1
    this is also straightforward to do in git; e.g., git --amend; another way to do this is via git reset --soft HEAD^, which just walks back but doesn't alter the index, and so you can edit/re-write the commit message.
    – doug
    Commented Nov 17, 2013 at 0:03
  • Hi, doug. Yes, you can do it for your local repository, but I'm talking about once you've pushed the change elsewhere -- "git commit --amend" doesn't help you much then. In SVN, you can edit the log message on the central server, precisely because there is a concept of a central server. That's what I meant by "impossible by design in decentralized systems". I'll edit my answer to make this clearer.
    – Karl Fogel
    Commented Nov 17, 2013 at 19:32
  • 1
    I love how "you can fiddle around with history" is allegedly a feature. I'd consider it a bug if it weren't intentional.
    – cHao
    Commented Jan 13, 2015 at 15:49

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