Live data from Hacker News

Subversion 1.7 is out

subversion.apache.org

11–20 of 41 posts

Re: Subversion 1.7 is out

#11
post #6
post #2

I probably should have linked to the release notes instead, which are available here: http://subversion.apache.org/docs/release-notes/1.7.html Some big changes in 1.7 extracted from the release notes: Working Copy Metadata Storage Improvements A key feature of the changes introduced in Subversion 1.7 is the centralization of working copy metadata storage into a single location. Instead of a .svn directory in every di…

I'm not trolling here, this is a genuine question: What are the advantages of using SVN over Git? (assuming one was starting a new project and hadn't yet chosen a VCS)

SVN is very easy to use compared to Git (or Mercurial etc.). This allows my team to provide version control for teams who aren't very technically skilled but who are nevertheless producing content that will appear on our website somewhere (e.g. static content).

Re: Subversion 1.7 is out

#12
post #6
post #2

I probably should have linked to the release notes instead, which are available here: http://subversion.apache.org/docs/release-notes/1.7.html Some big changes in 1.7 extracted from the release notes: Working Copy Metadata Storage Improvements A key feature of the changes introduced in Subversion 1.7 is the centralization of working copy metadata storage into a single location. Instead of a .svn directory in every di…

I'm not trolling here, this is a genuine question: What are the advantages of using SVN over Git? (assuming one was starting a new project and hadn't yet chosen a VCS)

SVN handles large binaries with ease. I'm an EE, and these are frequent occurrences in my projects. Git can choke on big binaries.

Re: Subversion 1.7 is out

#13
post #8
post #6

Earlier quoted context omitted.

I'm not trolling here, this is a genuine question: What are the advantages of using SVN over Git? (assuming one was starting a new project and hadn't yet chosen a VCS)

Setting up a SVN server takes seconds (infact it comes pre installed on all macs). Setting up a git server is a nightmare. If you have a small team like me (2-3 people max) then SVN easily meets all your needs. Naturally Git will catch up and supersede but currently they are focusing on other stuff.

Why is it a nightmare? You just run `git init --bare` and it all just works. SSH provides authentication, the filesystem provides authorisation.

As I remember, svn is more complicated, it has that separate svnadmin tool and relies on you to craft a suitable directory structure.

Re: Subversion 1.7 is out

#14
post #2

I probably should have linked to the release notes instead, which are available here: http://subversion.apache.org/docs/release-notes/1.7.html Some big changes in 1.7 extracted from the release notes: Working Copy Metadata Storage Improvements A key feature of the changes introduced in Subversion 1.7 is the centralization of working copy metadata storage into a single location. Instead of a .svn directory in every di…

Is SVN just slowly evolving DVCS features? That seems to be the progression I've been noticing.

No. They decided to focus on being the best centralized version control system: http://lwn.net/Articles/381794/

Re: Subversion 1.7 is out

#15
post #2

I probably should have linked to the release notes instead, which are available here: http://subversion.apache.org/docs/release-notes/1.7.html Some big changes in 1.7 extracted from the release notes: Working Copy Metadata Storage Improvements A key feature of the changes introduced in Subversion 1.7 is the centralization of working copy metadata storage into a single location. Instead of a .svn directory in every di…

While switching to a single .svn directory seems good, there's also a feature lost: you can no longer move parts of your working trees around the filesystem without hassle.

Re: Subversion 1.7 is out

#16
post #6

Earlier quoted context omitted.

I'm not trolling here, this is a genuine question: What are the advantages of using SVN over Git? (assuming one was starting a new project and hadn't yet chosen a VCS)

SVN is very easy to use compared to Git (or Mercurial etc.). This allows my team to provide version control for teams who aren't very technically skilled but who are nevertheless producing content that will appear on our website somewhere (e.g. static content).

Really?

I used Subversion for over 4 years and suffered through the regular merge issues, connectivity issues ("huh, can't commit because I'm not connected"), line ending issues, you name the problem I had it.

Two days into using Mercurial I felt more confident with it than I had ever felt with Subversion. I could branch code without having to work with the server, I could commit on my own machine and later push changes... and the merges just worked. No praying for ten minutes, no stupid CR/LF vs. CR errors, nothing.

I guess you'd have a point about easy of use if you count on the excellent TortoiseSVN. In the beginning Mercurial and Git didn't have anything as nice as that.

Re: Subversion 1.7 is out

#17
post #15
post #2

I probably should have linked to the release notes instead, which are available here: http://subversion.apache.org/docs/release-notes/1.7.html Some big changes in 1.7 extracted from the release notes: Working Copy Metadata Storage Improvements A key feature of the changes introduced in Subversion 1.7 is the centralization of working copy metadata storage into a single location. Instead of a .svn directory in every di…

While switching to a single .svn directory seems good, there's also a feature lost: you can no longer move parts of your working trees around the filesystem without hassle.

This is dangerous and error prone... What use case are you solving for by doing that?

Re: Subversion 1.7 is out

#18
post #7

Earlier quoted context omitted.

One big one is that you can check out a working copy of a particular sub-path in the repository. This means you don't need the whole repo (or the repo's entire history) locally, which is necessary in workflows where build products and other giant binaries are stored in version control. I believe this is why many people still use Subversion and Perforce, etc.

Of course, this is probably a not-so-great reason for doing so and reflects an inability to change build procedures/organizational workflows if this feature is absolutely vital.

This is actually a really cool feature. Basically, you can have one large repository to administer instead of lots of smaller ones, and you can treat any subdirectory level as a single repository.

Want to checkout all Apache Software Foundation projects?

    svn checkout http://svn.apache.org/repos/asf/
Want to work on Apache httpd?

    svn checkout http://svn.apache.org/repos/asf/httpd/
Maybe you only care about mod_proxy?

    svn checkout http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/
Apache server becomes a subproject of the new Apache MegaOS? Just move /repos/asf/httpd/ to /repos/asf/megaos/httpd.

See also FreeBSD repository: http://svnweb.freebsd.org/base/

Re: Subversion 1.7 is out

#19

Earlier quoted context omitted.

SVN is very easy to use compared to Git (or Mercurial etc.). This allows my team to provide version control for teams who aren't very technically skilled but who are nevertheless producing content that will appear on our website somewhere (e.g. static content).

Really? I used Subversion for over 4 years and suffered through the regular merge issues, connectivity issues ("huh, can't commit because I'm not connected"), line ending issues, you name the problem I had it. Two days into using Mercurial I felt more confident with it than I had ever felt with Subversion. I could branch code without having to work with the server, I could commit on my own machine and later push chan…

The kinds of people we provide SVN for have almost no technical skills whatsoever. You could spend a month trying to explain what a merge was and they wouldn't understand.

But they do need to produce content (which they'd like to be version controlled) that they expect my team to put up on our website.

From our point of view, SVN is a near-perfect solution: explain how to check $SOMETHING out and how to check it back in when you've amended it (using the excellent TortoiseSVN).

Once they've checked their work back in they email our team email address and one of us runs SVN UP on the relevant server, and we're done.

Re: Subversion 1.7 is out

#20
post #8

Earlier quoted context omitted.

Setting up a SVN server takes seconds (infact it comes pre installed on all macs). Setting up a git server is a nightmare. If you have a small team like me (2-3 people max) then SVN easily meets all your needs. Naturally Git will catch up and supersede but currently they are focusing on other stuff.

Why is it a nightmare? You just run `git init --bare` and it all just works. SSH provides authentication, the filesystem provides authorisation. As I remember, svn is more complicated, it has that separate svnadmin tool and relies on you to craft a suitable directory structure.

Setting up both Subversion and Git repos (with access control for multiple users) is pain compared to Fossil ;-)
Post reply on HN