
Subversion 1.7 is out - mmastrac
http://subversion.apache.org/news.html
======
mmastrac
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 directory in the working copy, Subversion
1.7 working copies have just one .svn directory—in the root of the working
copy. This directory includes (among other things) an SQLite-backed database
which contains all of the metadata Subversion needs for that working copy.

svn patch

Subversion 1.7 features a new subcommand called svn patch which can apply
patch files in unidiff format (as produced by svn diff and other diff tools)
to a working copy.

Improved HTTP protocol usage

Subversion 1.7 offers a simpler HTTP protocol variant that can be used when
connecting to supported servers. This simpler protocol (sometimes referred to
as HTTPv2) requires fewer client-server round trips to establish a connection,
making Subversion much more performant on high-latency network connections.

~~~
udp
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)

~~~
metajack
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.

~~~
DannoHung
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.

~~~
dchest
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/>

~~~
dlsspy
> Want to checkout all Apache Software Foundation projects? > svn checkout
> <http://svn.apache.org/repos/asf/>

Correction, that's all branches and all tags of all ASF projects. Not useful.

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

Again, all versions and all tags thereof.

> Maybe you only care about mod_proxy? > svn checkout
> [http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/pr...](http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/)

That's just the one version.

Similarly, my project wants the latest sources under under specific branches
from repositories from five different administrative domains. That's trivial
in git. I can move them around freely, lock a revision of a particular
repository while letting others move forward, have custom (potentially
unpublished or unwelcome upstream) patches to fit into my build system or
supported OSes that are tracked along with them.

Subversion has externals for this same reason. It's no excuse for poor
repository management.

~~~
dchest
> Correction, that's all branches and all tags of all ASF projects. Not
> useful.

Yes, I should have used the FreeBSD repository as an example, which is not
organized in {trunk,branch,tags} form.

------
andrewljohnson
I know there are a lot of reasons to keep using Subversion, but I don't think
there are many good reasons to start using Subversion. Git-e-up.

* SVN is no simpler than Git

* Working with a team is easier to branch and merge

* The tools and community around Git are vibrant

Go use TRAC and SVN, and then hit yourself in the face with a brick a few
times, and see which you enjoy more.

~~~
alttag
Likely because I used SVN for several years (and spent a good deal of time
with the excellent free online book [1]), but I find subversion significantly
easier than git. Checkout, commit. That's it.

Maybe I'm in the minority.

1:<http://svnbook.red-bean.com/>

~~~
andrewljohnson
You can use Git just like SVN. Just limit yourself to these 4 commands:

* git clone

* git pull origin master

* git commit -a -m "ch ch ch ch changes"

* git push origin master

You really don't need to know any commands other than that, and if you find
those too verbose, you can alias them. But then if you want the power of git
branch and git merge, they are there for the using.

I used to use SVN, and at some point I took the leap and converted to Git, and
I am a happy camper. As we have more and more developers working on various
branches and projects, the power of Git becomes clear.

------
HeroNote
Free Subversion eBook:

<http://www.heronote.com/files/Subversion.htm>

------
dextorious
"Subversion 1.7 is out"

Subversion has been "out" for years now! Please move on to a DVCS as soon as
you can and leave it to die a respectable death.

------
elouise
yawn

