Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes, svn would support this use case.

If I remember right, svn used to be a bit more involved than eg git for just starting tracking of a local project. I think you used to need to set up a (local) server etc?

They seemed to have fixed that, so the barrier to entry is lower than it used to be.

Almost any version control is better than manual mucking around with files.

Git is probably the better investment, if you are new to version control systems; if even just because everyone else uses it these days.

But svn would work ok-ish, too. And you can always convert your history later, if necessary.



Subversion doesn't need a local server, a directory for the repo will do.

In fact, the only reason I use git instead of subversion is that I am required to do so.

Most people use git as subversion anyway, and when they mess the local development, re-create the local development.

No one wants to take a PhD in git command line flags.


Maybe people are wired differently but I have always thought that git is way more intuitive than Subversion and I was more productive after 1 week of git than I previously had been after 1 year of using Subversion. I am sure Subversion has improved since then, but so has git.


It would be really interesting to learn what git users think is less intuitive in Subversion than in git.


Quite a lot.

* Syntax - in svn different commands use different conventions on how to use revision

* In svn moving directories breaks "subdirectory as branch" abstraction. I.e. there are no actual branches. Only files and versions of them.

* "Svn up" can fail, leaving working copy in broken, unpredictable state. This breaks abstraction, revealing that svn is little but copying files around. Git forces you to save your work and only then merge. That doesn't fail even when it fails to merge cleanly.


* ahem. Revision is always a revision in SVN. It’s rN and all commands accept it.

* ahem. All branches in SVN are copies of an existing tree at a particular revision. Call it a branch or whatever you want. But if you make a copy of your main development tree, you make a branch and you can work on it in the same fashion as if it was git. Merge it back to trunk when done or continue your work and sync with trunk or other branches. The principle is the same.

* Failing “svn up” is an unexpected technical problem that occurs due to problems with the server or network. The problem should never happen in normal cases.


First point: Here is an official svn doc with lots of mentioning of @revision

https://edoras.sdsu.edu/doc/svn-book-html-chunk/svn.ref.svn....

Two styles of revisions is super confusing to users like me. Git confuses me a bit, but not in command syntax. Hope this illustration helps to see what I mean.


Maybe a more up to date version of the doc will help: https://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs...


To be honest, Git is pretty good about dealing with 'unexpected technical problems'.

It even handles running multiple instances of git commands at the same time rather well.


The xkcd carton is still quite up to date.


>No one wants to take a PhD in git command line flags.

Yep that's why i still use bitkeeper....and it's great :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: