Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Subversion 1.7 is out

subversion.apache.org

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Subversion 1.7 is out

#31

Post by lucisferre »

fragsworth wrote: post #25
udp wrote: 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)

In my experience, if you are writing a game and you have artists committing assets to your repository, git can be very difficult to work with because it requires quite a bit of training to handle properly. SVN is something they're more used to.

Submodules are a good approach for separating large assets from the code repository.

Re: Subversion 1.7 is out

#32

Post by dlsspy »

dchest wrote: post #18
DannoHung wrote: post #9

Earlier quoted context omitted.

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?…

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

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.

Re: Subversion 1.7 is out

#33

Post by dchest »

dlsspy wrote: post #32
dchest wrote: post #18

Earlier quoted context omitted.

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?…

> 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/mo…

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

Re: Subversion 1.7 is out

#34

Post by alttag »

andrewljohnson wrote: post #27

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.

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/

Re: Subversion 1.7 is out

#35

Post by andrewljohnson »

alttag wrote: post #34
andrewljohnson wrote: post #27

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.

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/

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.

Re: Subversion 1.7 is out

#37

Post by gurkendoktor »

metajack wrote: post #7
udp wrote: 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)

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.

Two simpler use cases:

* Using a big repository for a bunch of related projects. Settings up a new project (not a new repository, but who can tell the difference?) is as simple as creating a new folder, then commiting it. Then you can directly checkout that folder if you need the single project. This beats SSH one-liners to set up new repositories.

* I usually have something like a "httpdocs"/"website" subfolder in my bigger projects. With svn, I just check out that folder on my web server. With git, I'd have to check out the whole project, which feels more like a kludge.

Re: Subversion 1.7 is out

#38

Post by hyperrail »

fragsworth wrote: post #25
udp wrote: 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)

In my experience, if you are writing a game and you have artists committing assets to your repository, git can be very difficult to work with because it requires quite a bit of training to handle properly. SVN is something they're more used to.

Please elaborate on "training". Do users check in things they shouldn't? Complain that clones take forever because of the sheer size of the files in a tree? Something else?

Re: Subversion 1.7 is out

#39

Post by mey »

dchest wrote: post #21
mey wrote: post #17

Earlier quoted context omitted.

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

Use case... just moving stuff around. It was nice to have the freedom to treat any subdirectory as a separate working copy. Why is this dangerous? (note: I no longer use Subversion).

The system wasn't designed with that consideration in mind, locking mechanisms can break when you do this and don't know that the folder is in use by another system (functionality varies per OS). If you are moving files to reorganize structure of a project, the .svn folders will cause conflicts, and you'll also loose the history of the move, (instead a continuous history of that structure, it'll appear as a new structure)

Lastly, when supporting my developer pool with SVN, resolving corrupted .svn folders because of moving folders in correctly is a time consuming procedure and usually ends with an export command to kill all the .svn files, and risking blowing away changes in with a commit that ignores history.

Re: Subversion 1.7 is out

#40

Post by DannoHung »

nirvdrum wrote: post #26
DannoHung wrote: post #9

Earlier quoted context omitted.

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.

Version control doesn't need to be restricted to code and builds. In my previous startup we revisioned all of our hardware schematics, product manuals, BOMs, etc. Most of it was binary data, so we didn't gain much from diffing. But we had a process in place, required for most forms of documentation control. And it worked exceptionally well (with the obvious caveat two people couldn't work on the same file at the same…

I don't know enough about your domain to make a coherent statement. Maybe the SVN style is superior for it, but I thought we were talking about code, which is why I was talking about build processes.
Post reply on HN