Subversion 1.8 Released But Will You Still Use Git?

darthcamaro writes "Remember back in the day when we all used CVS? Then we moved to SVN (subversion) but in the last three yrs or so everyone and their brother seems to have moved to Git, right? Well truth is Subversion is still going strong and just released version 1.8. While Git is still faster for some things, Greg Stein, the former chair of the Apache Software Foundation, figures SVN is better than Git at lots of things. From the article: '"With Subversion, you can have a 1T repository and check out just a small portion of it, The developers don't need full copies," Stein explained. "Git shops typically have many, smaller repositories, while svn shops typically have a single repository, which eases administration, backup, etc."'" Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.

Comments

yup

[Anonymous Coward]

short and simply, yes. If Linus says so, we obey.

Re:yup

[Anonymous Coward]

We obey

Re:yup

[Anonymous Coward]

Wrong one.

http://people.southwestern.edu/~bednarb/su_netWorks/projects/granger/obey1.jpg

First post!

[Anonymous Coward]

First post! muajaaa!

Re:First post!

[Anonymous Coward]

cat ./slashdot/posts/44049461.txt | sed 's/First/Second/g' | sed 's/muajaaa/bwaaa/g' > ./slashdot/posts/44049461.fixed
mv ./slashdot/posts/44049461.fixed ./slashdot/posts/44049461.txt
git add ./slashdot/posts/44049461.txt
git commit -m "Fixed that for you!"

Re:First post!

[Anonymous Coward]

The International Feline Association awards you with today's "Useless use of (a) cat"-award. Meeeeow!

Re: First post!

[Threni]

I tried the Subversion equivalent but got trapped in the familiar hell of Cleanup and Unlock to fix a problem that came out of nowhere. Perhaps the commit got interrupted and Subversion still can't handle that rare edge case properly with transactions. In the end I had to go back and Checkout everything again.

Re:First post!

[Anonymous Coward]

cat ./slashdot/posts/44049461.txt | sed 's/First/Second/g'

This should have been:

sed 's/First/Second/g' ./slashdot/posts/44049461.txt

See also: Useless use of cat.

Moreover,

sed 's/First/Second/g' | sed 's/muajaaa/bwaaa/g'

is a further waste of resources. In sed, you can use several commands in a row. So this pipeline could be written as

sed 's/First/Second/g;s/muajaaa/bwaaa/g'

Combining both, your first command simplifies significantly to

sed 's/First/Second/g;s/muajaaa/bwaaa/g' ./slashdot/posts/44049461.txt > ./slashdot/posts/44049461.fixed

Re:First post!

[Anonymous Coward]

you forgot:

git push

Re:First post!

[Anonymous Coward]

Using cat like that makes it easy to edit the filename. It's always in the beginning, instead of hidden somewhere later. Compare:

sed 's/something long here/something equally long here/g' 'some/file path/here.txt' | sed 's/again something long here/and more/'
cat 'some/file path/here.txt' | sed 's/something long here/something equally long here/g' | sed 's/again something long here/and more/'

If you really want to eliminate cat, you could also do further improvements:

sed -i -e 's/First/Second/g' -e 's/muajaaa/bwaaa/g' ./slashdot/posts/44049461.txt
git commit -m "Fixed that for you!" ./slashdot/posts/44049461.txt

Re:First post!

[Anonymous Coward]

Not to mention the redirect to a new file, only to mv the new file to an existing one.

He must use csh. Poor fool.

Re:First post!

[gomiam]

Which is why you can:

</path/to/file sed -e 's/what/ever/g ; s/foo/bar/g'

mkdir FP

[sgbett]

git --bare init

Re:mkdir FP

[TemporalBeing]

git --bare init

Or even better...

svnadmin create .

And that works on any platform - Windows or Linux/Unix/Mac; where git just doesn't do Windows very well (outside of Cygwin; the msys version is bleh).

Re:mkdir FP

[Anonymous Coward]

seriously. fuck windows. and fuck mac while we're at it.

Re:mkdir FP

[Anonymous Coward]

Seriously dude, lay off the viagra.

Re:mkdir FP

[Lennie]

Really ? Works just fine here.

github

[stoolpigeon]

I really started using github regularly at the same time that I started using github.

It's grown to so much more than the underlying version control software.

Re:github

[Arancaytar]

I really started using github regularly at the same time that I started using github.

Really?!

Re:github

[Anonymous Coward]

I really started using github regularly at the same time that I started using github.

Well then.

Good luck using github for anything with any sort of security/IP/audit requirement.

Re:github

[sjames]

I would imagine a shop with that requirement would install an in-house manager for Git repos.

One size does not fit all but it's nice to have a solution that can be fitted easily.

Re:github

[Anonymous Coward]

Pfft. I've been using Github for decades before I started using github.

Re:github

[stoolpigeon]

I didn't notice what I did until I read your reply.

Re:github

[liamevo]

You don't need to use github to use git, bit if you really like github, you can run it on your own servers, there is an enterprise version.

Re:github

[larry bagina]

Yo git, I github that you like to github so I github some github in your github so you can github while you github. Github?

Re:github

[Anonymous Coward]

...and github has received a $100M investment
http://go.bloomberg.com/tech-deals/2012-07-09-github-takes-100m-in-largest-investment-by-andreessen-horowitz/

Re:github

[rroman]

If I needed github on my server, I would choose gitlab.

Re:github

[Hatta]

I heard you really liked github...

Re:github

[DMUTPeregrine]

Actually, the original does make some sense, as it's possible to use github but not use it regularly. You could have a period of having a github account and putting up the occasional project/change, but not using it on a regular basis.

Re:github

[stoolpigeon]

Thanks but it was just a mistake on my part.

I didn't use git a lot until I got involved using github.

I think it's a great platform that, whatever it's weaknesses has managed to pull of something rather cool. I know sourceforge and others were around a long time before it but github seems to have taken things to another level in regards to involvement.

Re:github

[iMadeGhostzilla]

Anyone care to say more about this? I can understand the reasons, but was wondering what real-life experiences people had on this topic. Thanks.

Re:github

[stoploss]

I really started using github regularly at the same time that I started using github.

Really?!

He said what he said.

Re:github

[Anonymous Coward]

Yeah and it's pretty lame because the appliance is an OVF which is locked down so you can't take advantage of the real power of git which is its ability to be customized for your situation.

Re:github

[Anonymous Coward]

Right. But /enterprise/ has its price... It's quiet expensive even for small companies.

GIT sucks on windows

[Anonymous Coward]

If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.

Re:GIT sucks on windows

[ebno-10db]

If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.

What about Mercurial? (you know, the DVCS that fanbois dis because it's not used by Linus the ultimate cool kid). I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).

P.S. To put a little damper on the flame war that this will ignite, I swear that personally I would give my left kidney to crawl over broken glass for the privilege of reading man pages all night just to be able to do the same thing with Git that I could figure out in 5 minutes with any other version control system. However, other people on my team are very good at what they do (Ph.D.'s working on signal processing) but are not quite as enthusiastic as I about the broken glass.

Re:GIT sucks on windows

[Anonymous Coward]

? `git gui` in Linux...TortoiseGit in Windows. Yay, UI + Git. So hard.

Re:GIT sucks on windows

[DrXym]

TortoiseGit puts a nice UI over Git that does pretty much everything in the normal developer workflow. I'm not sure why you would be rebasing so much since that would typically be a final act for a large, long lived branch that you intended to squash and make relative to the head of another branch prior to merging it over.

Re:GIT sucks on windows

[Anonymous Coward]

If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.

What about Mercurial? (you know, the DVCS that fanbois dis because it's not used by Linus the ultimate cool kid). I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).

P.S. To put a little damper on the flame war that this will ignite, I swear that personally I would give my left kidney to crawl over broken glass for the privilege of reading man pages all night just to be able to do the same thing with Git that I could figure out in 5 minutes with any other version control system. However, other people on my team are very good at what they do (Ph.D.'s working on signal processing) but are not quite as enthusiastic as I about the broken glass.

We switched from SVN to Mercurial at work, for technical folks it hasn't been a problem, but for less technical folks it is. My main gripe with Mercurial is that the tooling sucks. Yes TortoiseHg is okay, but IDE based tooling is lagging badly. Go ahead and use it in Eclipse on Linux for awhile, you'll see what I mean. I gave it a pass at first, SVN tooling really sucked at first too, but their grace period has long since run out. Git won the DVCS war, the vast majority of the people contributing to the tooling are working on it, not Hg.

SVN tooling remains really good. I'm a little gunshy about the branching and reintegration problems we used to encounter, so I've learned to avoid certain behaviors in favor of stuff I know is far less likely to cause problems. I know they said they'd improve it and maybe they have, but my workflow on SVN repos is fine.

Re:GIT sucks on windows

[Anonymous Coward]

Ah, come on, TortoiseHg for the win!

Re:GIT sucks on windows

[ahabswhale]

What's so difficult about doing these things on Windows? It's the same process as OSX or Linux. And why do you need to rebase so much?

Re:GIT sucks on windows

[the_cosmocat]

Perhaps, you could even use GitExtensions ( http://code.google.com/p/gitextensions/ ) which I find is a better GUI on Windows...

Re:GIT sucks on windows

[Microlith]

What about its UI is awful? Is it because it is command line based that makes it awful?

I think the real problem is that people approach Git thinking it's like SVN, and when the SVN way of doing things doesn't work they get frustrated and proclaim it to be awful.

Re:GIT sucks on windows

[Anonymous Coward]

TortoiseGit is a flaming pile...it tries too hard to look like TortoiseSVN, and so it just ends up being confusing. There are a number of alternative gui git clients for windows, of which Sourcetree is my current favorite, but not by much (I don't like it as much as either TortoiseSVN or TortoiseHg).

To the gp, if you're on windows, I'd give mercurial the edge, based on both UI and general mindset. Git is very much a product of linux, and so it makes some assumptions that aren't correct if you're on windows. On the other hand, github is both amazing and unique (bitbucket tried to do the same thing for hg, but it's not nearly as nice a social scene). And if you're trying to develop marketable skills (probably a good idea in our industry), git experience will most likely take you farther than hg experience.

Re:GIT sucks on windows

[Anonymous Coward]

I guess he comes from SVN-land where the history is one line, no actual branches and rebase provides him with that kind of history ?

on the other hand you should never have to ask such a question as "why do you need to rebase so much". It's there, it's a feature of git, there should never be a restriction such as "yeah, you can use it, but not too much". "why do you use that feature" is probably one of the worst oximoron

disclaimer: this AC has switched from subversion to mercurial and git a looooong time ago. Never looking back.

Re:GIT sucks on windows

[loom_weaver]

Fwiw, FogBugz released Kiln Harmony that allows devs to use either git or hg.

http://blog.fogcreek.com/announcing-kiln-harmony-the-future-of-dvcs/

Re:GIT sucks on windows

[ebno-10db]

TortoiseGit is a flaming pile...it tries too hard to look like TortoiseSVN, and so it just ends up being confusing. There are a number of alternative gui git clients for windows, of which Sourcetree is my current favorite, but not by much (I don't like it as much as either TortoiseSVN or TortoiseHg).

To the gp, if you're on windows, I'd give mercurial the edge, based on both UI and general mindset. Git is very much a product of linux, and so it makes some assumptions that aren't correct if you're on windows. On the other hand, github is both amazing and unique (bitbucket tried to do the same thing for hg, but it's not nearly as nice a social scene). And if you're trying to develop marketable skills (probably a good idea in our industry), git experience will most likely take you farther than hg experience.

Thanks for the advice. I'll look into some of the Hg GUI stuff you mention. Unfortunately we're stuck w/ Windows clients as that's what our cross-dev tools run on. I've played w/ Git, including TortoiseGit and came to similar conclusions as you. It seems to me like Hg gets short shrift.

Re:GIT sucks on windows

[Tough Love]

...Having to rebase is tiresome...

Versus Subversion where you *can't* rebase. Instead, just let everything degenerate to the point where contributors habitually build up massive diffs that conflict with every other team member, interspersed with episodes of panicked committing, build breakage and mutual recrimination just before planned release dates. Been there.

Re:GIT sucks on windows

[ebno-10db]

Interesting though that FogBugz originally went w/ Hg instead of Git. Obviously they have to support what their customers want. However, it seems that several outfits (e.g. Google) that really looked at the two originally chose Hg, and have since come to support Git only by popular demand. I'm not convinced that popular demand was driven by anything other than "Git is what the cool kids use, because Linus the ultimate cool kid uses it'.

Re:GIT sucks on windows

[Tough Love]

What about Mercurial?

Mercurial matches Git in functionality and performance, but completely blows it away in terms of usability and elegant design. Without the Linus factor, everybody would be using Mercurial, not Git. I tend to use Mercurial a lot anyway. One weird and useful thing I do with Mercurial is make a Mercurial repository inside a Git repository, to track files I don't want in the Git repo but still want to track and keep in the same directory.

Re:GIT sucks on windows

[adri]

I've seen that happen with git.

git "encourages" developers to share often. It doesn't mean that they will.

Re:GIT sucks on windows

[Dan Ost]

Rebasing is extremely handy when you have multiple branches being developed. Whenever a branch is merged, you rebase the other branches so that the merged feature gets pulled into each branch.

Re:GIT sucks on windows

[Tough Love]

Git is full of appalling bad usability decisions. Like requiring git commit -a, which for Mercurial would just be hg commit as a sane person would expect. Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified. Warts like this are strictly a geek endurance test, to learn where your pain threshold is. If it is sufficiently high then you are cut out to be a Git nerd forever.

Mind you, Git is wonderful compared to Subversion which just can't do the things you need to do.

Re:GIT sucks on windows

[VGPowerlord]

on the other hand you should never have to ask such a question as "why do you need to rebase so much". It's there, it's a feature of git, there should never be a restriction such as "yeah, you can use it, but not too much".

The reason to use rebase is simple:
To avoid clogging up the revision history with those moronic "Merge branch 'master' of [url here]" commit messages.

As I found out the hard way.

Re:GIT sucks on windows

[bobaferret]

We've found that Smart GIT/HG works really well for our GUI repo needs.

Re:GIT sucks on windows

[Anonymous Coward]

Mercurial has some utterly *broken* design choices in it when it comes to symbolic links on non-Linux OSes. Specifically, the software is designed with the absolutely idiotic and wrong mentality of "a symlink has no actual file permissions".

On BSD -- that includes OS X, so don't go picking on FreeBSD -- symbolic links absolutely have their own file permissions (see chmod -h)

Mercurial completely fucks up in this regard, because from what I can tell, they choose to use lstat() all over the place rather than stat(). Naturally this is going to behave different on Linux than on BSD, and the end result are users getting errors like "Permissions denied" when the directory they plan on "checking out into" (i.e. the SVN equivalent being: "svn checkout svn://some/place ./somedir, where ./somedir is a symlink that points to /foo/bar) because ./somedir (the symlink) has permissions 700 while /foo/bar is 755.

I did some reading on this and this is again by design, citing "security concerns". Sure, fine, for symlinks within a repo, that's a problem, I agree. However for the destination directory in a checkout? Wrong. Just wrong wrong wrong.

Use SVN, use git, use Perforce, use CVS, use RCS. Do not use Mercurial. Their authors have tunnel vision.

Re:GIT sucks on windows

[Microlith]

Like requiring git commit -a, which for Mercurial would just be hg commit as a sane person would expect. Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified.

Why can't it be justified? Not every change needs to be committed, I've had running debug changes that have never been committed because they don't need to be, and the staging area lets me ensure only the necessary changes get checked in. It also lets me prevent them from ever being a part of any commit, so I don't have to filter them out later.

Re:GIT sucks on windows

[lennier1]

If you'Re using Windows, just try SourceTree.

Re:GIT sucks on windows

[DrXym]

For a long time the EGit plugin for Eclipse sucked balls but it is at a point now where it's pretty easy to use at least for the day to day workflow. As a general rule though don't mix command line git and Egit on the same project at the same time because it can get confused. I often see msysgit get confused by line endings, regardless of what line ending conversion settings or gitattributes are in the project after Egit has been at the files.

Re:GIT sucks on windows

[M. Baranczak]

Having to rebase is tiresome, especially on windows

git config branch.autosetuprebase always

Or add --global to apply this to your personal settings. I don't understand why they didn't make this the default behavior, but there you have it. (And why "especially on windows"? What's different about doing it on windows?)

Re:GIT sucks on windows

[DrXym]

Can't blame the tool for that. Git makes it easy to merge and that's 90% of the battle.

I have to do periodic merges between CVS branches and I have to set aside several hours to do it thanks to all the tagging that has to go on before and after the merge to ensure it happens properly. The fact it takes so damned long it discourages me from doing it more often.

Re:GIT sucks on windows

[Anonymous Coward]

Git GUI you say?
http://www.sourcetreeapp.com/

(I assume you are on Mac OS or Windows since you said "GUI" after all)

Re:GIT sucks on windows

[Anonymous Coward]

I'm a mercurial user, and I almost exclusively use "hg record" instead of "hg commit", which is similar in concept to the Git staging area. It's hardly useless.

Re:GIT sucks on windows

[greg1104]

Whether you prefer to include all modifications in a commit is a workflow driven decision. I like the way git's default pushes me to review each change once before it goes in. Going through a round of "git status" and reviewing what's staged is a good coding practice when many people are going to consume what you commit. And that's exactly the situation git's defaults are setup to support--an environment where mistakes are going to be consumed by a lot of people.

You seem to feel that your way is the One True Workflow, and everyone who does it some other way is doing it wrong. That's fine, and you should create an environment to make that happen. But you're claiming the default "can't be justified" because you, personally, don't like it. You don't get to claim the UI is bad simply because it's not yours, especially when the behavior you want is actually part of that UI.

Re:GIT sucks on windows

[Anonymous Coward]

> git commit -a

Specifying additional specific command arguments for the common case is bad UI. This is a minor but glaring example.
`git commit` should do the staging of everything automatically and commit. There are so many git shortcuts floating around, you would think someone would improve git itself.

Re:GIT sucks on windows

[larry bagina]

That was my first reaction to git (coming from svn). But if you use a nice GUI tool to commit, not only can you pick and choose your files, you can pick and choose chunks of files or individual lines to commit.

Generally, I make a bunch of changes (often unrelated), then eventually I get around to checking them in. On the command line (git commit -a, svn, etc) I would update everything at once. With a git gui, I can break it up into individual commits. And work in progress, debug code, unrelated changes, etc don't get accidentally committed.

Re:GIT sucks on windows

[Atzanteol]

I thought so as well until I really started using git. Now I *never* accidentally commit my changes to log4j.xml where I turned up debugging while I worked out an issue. It forces me to think about what I'm committing. You may be wonderful and do that automatically (in which case you can create an alias which does it for you) but for us mortals it's quite useful.

Re:GIT sucks on windows

[aristotle-dude]

...Having to rebase is tiresome...

Versus Subversion where you *can't* rebase. Instead, just let everything degenerate to the point where contributors habitually build up massive diffs that conflict with every other team member, interspersed with episodes of panicked committing, build breakage and mutual recrimination just before planned release dates. Been there.

That's not a problem with SVN. That is a problem with developer discipline and the development process used. We do continuous integration builds with unit tests within those builds. Our team members usually check in at the end of every day or every two days if they need to do a major refactor to support new functionality.

Stop using waterfall and working in silos and your problems will go away.

Re:GIT sucks on windows

[gorzek]

SmartGit, Git Extensions, the GitHub for Windows client, and the git functionality built into things like NetBeans all make using git on Windows pretty straightforward.

I've spent the most time using Git Extensions as it seems to support the broadest set of git commands, but I'll grant that it doesn't have the friendliest interface.

Re:GIT sucks on windows

[phantomfive]

Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified.

Don't you like to review your changes before committing them?

Re:GIT sucks on windows

[gorzek]

I don't know what kind of environment you work in, but in my experience you really need something like git's staging area if you are doing any major application work. Most developers are working on multiple things at a time, and they don't want to just commit everything at once, or even every modified part of a given file. Without that, you are forced to either hold off modifying some files, or keeping multiple copies lying around. (Git also supports the latter via stash, if that's your preference.)

Managing this via a command-line interface is excruciating, though. I stick to a GUI for daily work and use the command line only for deeper repo analysis and to feed programs that script git to do something.

Re:GIT sucks on windows

[TemporalBeing]

Git won the DVCS war

True, and SVN won the Centralized VCS wars.

I've used both and recommend them that way - if you want DVCS then use Git, if you want centralized then use SVN. Both are the top in their respective VCS markets. The only issue is if you use Windows - then Git just sucks as it does not integrate well at all, and as others have pointed out TortoiseGit doesn't really resolve that - it's a tooling problem and a problem in the design of Git. (One that could be probably be resolved by moving away from using so many Bash scripts and using a library for all the functionality like SVN does, which is why TSVN is just as first-class a citizen as the SVN command-line tools.)

And while I realize the they are very different - Git just drives me nuts, between things like having to stage files before a commit to it not tracking directory structures until there is something in it. (I like to setup the directory structure prior to putting things in it; often times I know I'll have something there but it may take a while to get to the point where I'll have something to put in it, yet I want the structure in the VCS before I get there.)

Re:GIT sucks on windows

[TemporalBeing]

What about its UI is awful? Is it because it is command line based that makes it awful?

I think the real problem is that people approach Git thinking it's like SVN, and when the SVN way of doing things doesn't work they get frustrated and proclaim it to be awful.

I use SVN, and I've used Git. I realize they're different and I expect differences. Yet, little things like Git not tracking empty directories drive me nuts. A VCS of any kind should be able to store a directory structure without a problem and before files are added to it; yet Git fails that very basic functionality. Staging is a nusance, but on that can be lived with, though I'm sure it makes complications that will itself cause bugs.

On the other hand, Git just doesn't do permissions. So everyone has access to everything. But that's the nature of DVCS tools, and you can only get around that by using a Centralized VCS tool, like SVN.

Re:GIT sucks on windows

[TemporalBeing]

Mind you, Git is wonderful compared to Subversion which just can't do the things you need to do.

And SVN can do stuff that Git can't. Both have their strengths and weaknesses. (storing empty directory structures is one example of something Git cannot do).

Re:GIT sucks on windows

[TheRaven64]

Mercurial is nice for larger projects. For smaller ones, I prefer Fossil, which integrates a bug tracker and wiki into a single, small, statically linked executable. It has scalability problems with large numbers of concurrent users of the same repository, but if you only have a few tens of collaborators it works fine and is trivial to deploy.

Re:GIT sucks on windows

[TemporalBeing]

Like requiring git commit -a, which for Mercurial would just be hg commit as a sane person would expect. Git fans spout a bunch of drivel about "staging area" to justify it, but it can't be justified.

Why can't it be justified? Not every change needs to be committed, I've had running debug changes that have never been committed because they don't need to be, and the staging area lets me ensure only the necessary changes get checked in. It also lets me prevent them from ever being a part of any commit, so I don't have to filter them out later.

Because it means the committed changeset will be different from the changeset on the developer system. So instead of having just changeset A which the VCS sends up, you have changeset A which the VCS knows about and changeset B which is what the developer sees when looking at the file system and what files have changed, and the two are not necessarily the same. If you change a file in changeset B it does not necessarily commute those changes to changeset A without another step. I can very easily see this adding bugs that only get resolved over multiple commits instead of a single commit. Then again, git has the ability to squash commits too, which is probably a result of that.

Re:GIT sucks on windows

[BitZtream]

Everything you use to justify using GIT is an example of doing it wrong.

Re:GIT sucks on windows

[gorzek]

It's not wrong if you're using git to do it. :)

Re:GIT sucks on windows

[Anonymous Coward]

I prefer the nice usable command line interface of svn compared to twisted maze of git. Commit -a is just small piece of the puzzle that feels wrong and complicated.

Re:GIT sucks on windows

[SerpentMage]

No the problem is that git sucks from a usability point of view. It is completely non-intutitive, and heaven forbid anything goes wrong because something is not up to date. I get git, I get the reason why git exists, but it does not mean its better. IMO git needs a revamp in usability. I still continue to use subversion, not because its better, but because I am not spending brain cycles trying to figure out why something is not working properly.

Re:GIT sucks on windows

[Anonymous Coward]

There's also an identical version of SourceTree on OSX (which came first, but they look and work exactly the same so it hardly matters).

Windows users can also use Git Extensions (https://code.google.com/p/gitextensions/) if you prefer something open-source.

Re:GIT sucks on windows

[SerpentMage]

Want to know what sucks about git? Your explanation! I know you are trying to be clear, and trying to be helpful. But it is not helpful. Any sane person will need about 4 runs to actually figure out what you are saying. I understand that what you are describing is probably something that somebody needs, but it is an edge condition since it appears you are the only one who can explain it clearly.

Re:GIT sucks on windows

[ebno-10db]

Whether you prefer to include all modifications in a commit is a workflow driven decision.

That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does. Yes, that's by default, but it means the default adds non-essential steps and complexity. I'm also very careful about checking things before a commit, but I don't appreciate being pushed towards Linus' idiosyncratic way of doing that. I have my own approach. YMMV, but I find the extra step means I'm more likely to make a stupid mistake.

Re:GIT sucks on windows

[csumpi]

> Having to rebase is tiresome, especially on windows.

RTFM. Seriously. You don't need to rebase to update to the latest version. In fact if you are rebasing, you are doing it dead wrong. Just merge the upstream branch with yours.

Also, git on Windows works perfectly. I use it every day with github and my local gitosis server (running on linux).

Re:GIT sucks on windows

[ebno-10db]

Don't you like to review your changes before committing them?

I do, but I don't appreciate being pushed towards Linus' preferred idiosyncratic approach to it. I have my own way of reviewing changes, and a well designed tool doesn't unnecessarily push you towards some idiosyncratic workflow preferred by the tool's author. The staging area reminds me of one of those tools that says "are you you sure you want to do this, you do realize that changes made here are not easily undone, please confirm you want to do that, now, are you absolutely positively cross your heart sure you want to do that?". I find such an approach makes me more likely to screw up.

Re:GIT sucks on windows

[csumpi]

I started with mercurial, and loved it. Git seemed too much trouble, but I found some features that made me switch and never look back:

- named, super fast branching
- merge multiple branches (only two at a time in mercurial)
- speed
- progress indicator on push/pull/clone (maybe this has improved in mercurial, but I used to sit staring at a blinking cursor for minutes wondering when/if the operation will finish)

This is a great comparison article. Nothing wrong with mercurial, but going back would make me miss the things from above.

Re:GIT sucks on windows

[greg1104]

That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does. Yes, that's by default, but it means the default adds non-essential steps and complexity.

All tools push you toward a particular workflow. You're making the same mistake as the person I replied to, where you judge the software by how well it fits your personal workflow preference. If you think this adds complexity you don't want, turn it off and move on; your problem is solved. git cannot change the defaults here to suit everyone. Whatever they pick is going to be a problem for some people, so Linus just picked the one he likes, someone added the alternative, and everyone moved on. And that's the only good way to proceed. All a program like git can do is provide options that meet all the popular workflow choices and then return to getting work done.

Re:GIT sucks on windows

[Tough Love]

Stop using waterfall and working in silos and your problems will go away.

+1 Funny. Spoken well and truly as someone who only knows SVN and its ilk.

Re:GIT sucks on windows

[Tough Love]

SVN consists of mostly weaknesses while Git consists of mostly strengths. Developers are more productive with Git. Seen it many times over. In big SVN shops, most likely you will find the clueful devs using Git frontends to SVN so they don't waste their time fighting with the VCS.

Re:GIT sucks on windows

[Anonymous Coward]

Don't you like to review your changes before committing them?

Absolutely! That's why I always do hg diff (without any more parameters) before committing.

Re:GIT sucks on windows

[Hatta]

If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows.

Sounds like a problem with Windows, not git.

Re:GIT sucks on windows

[gl4ss]

If you live in linux land and love using only command line, then GIT is fine. On the other hand, if you want to grab the latest code, make a change and commit, GIT sucks. It's especially true if you're using Github. Having to rebase is tiresome, especially on windows. The times I've contributed to OSS projects that used GIT, I spent 5 minutes make the code change and 30 minutes rebasing. For comparison, with SVN, I spend 1 minute to do update and 5 minutes to make the code change.

what the fuck you're smoking? especially if you're using github, why the fuck wouldn't you use githubs gui program that works pretty nice with github?

it also happens to be the only metro style program that isn't pure shit. and that's because it's just metro style and not an actual metro program. makes it a bitch to see where the windows borders are, I give that..

Re:GIT sucks on windows

[Anonymous Coward]

Without the Linus factor, everybody would be using Mercurial, not Git.

I really have no idea what you're talking about. I personally don't know of anyone who uses git because Linus does, except the kernel contributors who pretty much have to use what the maintainer uses, and I don't really hear much complaining about git from them anyway. Or do you mean that Linus is more well-known than whoever started hg? Regardless, this "Linus factor" sounds like a sad attempt at rationalization. Maybe the truth is simply that git really is just as good (or better) than hg. Of course, as a good fanboy, you will have a list of talking points, but the fact is they're both based on bitkeeper, they both came out at virtually the same time, they both work almost exaclty the same, and they're both good choices.

Re:GIT sucks on windows

[Anonymous Coward]

That's the point - a good tool shouldn't needlessly push you towards a particular workflow, which is what the staging area does.

And if the default was to commit all changes, it would push you towards a workflow that involves that.

Re:GIT sucks on windows

[TemporalBeing]

SVN consists of mostly weaknesses while Git consists of mostly strengths. Developers are more productive with Git. Seen it many times over. In big SVN shops, most likely you will find the clueful devs using Git frontends to SVN so they don't waste their time fighting with the VCS.

Been in mostly SVN shops, and haven't seen anyone using Git. Seen people using CVS (or PerForce or ClearCase) when they weren't aware of SVN/Git, but haven't seen anyone using Git - just open source projects.

I had one manager that tried to get me to sign off on moving my project from SVN to PerForce or ClearCase (can't remember which) because it was what he was familiar with; it required spending money to do so which I pointed out and that quickly faded.

SVN and Git both have their strengths and weaknesses. And if you need a decentralized system, the Git is certainly for you. It's all a matter of what your needs are - Git isn't for everyone, nor is SVN.

Re:GIT sucks on windows

[Anonymous Coward]

Have you heard of Git Extensions?

https://code.google.com/p/gitextensions/

It's Windows, a Gui, you can get to most things without the command line - even Clove SVN repo, Interactive Rebase, Bisect, etc, the only thing I've needed the command line for was signed tags (and that's not common).

I dabbled with Tortoise Git a while ago and hated it; it tried to arrange everything as if it were SVN, but Git is an entirely different thing with an entirely different approach. Tortoise Git even *renamed* the commands, so when you found out how to do something in Git you had to google *again* to find what that action was called in Tortoise Git. I think it got better a that, but by then I was already put well off Tortoise for any VCS other than SVN.

Re:GIT sucks on windows

[MirAGe01]

git commit -a is not the way to do it. Why not do this instead? git add . git commit "git add ." will commit all changes. You can specify individual directories or files. For example if I have changes in the src and plugins directories I can do "git add src" and only the changes in the src directory are staged. Then when I do "git commit" those staged changes are committed. The purpose of "git commit -a" is to save you a step so you don't have to do the "git add" command.

Re:GIT sucks on windows

[Drinking Bleach]

For a pure open source solution, using a git repository is good enough for the same purpose, Mercurial includes a very mature bidirectional Git importer/exporter (their concepts are all mappable to each other, there shouldn't be any downsides to it). Git is missing the opposite direction, but someone can always step up and allow Mercurial to be cloned from Git.

Re:GIT sucks on windows

[ebno-10db]

Don't you like to review your changes before committing them?

Absolutely! That's why I always do hg diff (without any more parameters) before committing.

I also always do a diff before committing. Plus I build and test, then commit everything I've built. The whole idea of moving only some changes to the staging area and then doing a partial commit sounds like a real invitation to problems.

Re:GIT sucks on windows

[Anonymous Coward]

I have to agree with most of the other posters here.
I really wouldn't want the default behavior to commit every change.
Some files are changed by scripts when running things, or maybe I'm working on something when I notice a bug and fix that, and I only want to commit that fix.
Gits gui might suck, I don't know. I rarely use it. (maybe because it sucks?)

Re:GIT sucks on windows

[Anonymous Coward]

Why was your rebase taking 30 minutes?
At work we use perforce.
I use git for all my local changes, and then when I'm ready I rebase and submit.
I rebase many times a day, and the only time I spent any amount of time on it was when I had changed something in an xls file at the same time as someone else.

Re:GIT sucks on windows

[phantomfive]

Guess you'll have to type -a. It must be painful.

Re:GIT sucks on windows

[Gerektoolhy]

>> they both work almost exaclty the same, and they're both good choices. Alsmost true. Except that git was initially coded with c and Perl, and thus it was just not portable. Mercurial made it right from beginning - it's written in Python and runs very well on all platforms.

Re:GIT sucks on windows

[shentino]

I find that having things opted-in to the commit rather than glomming everything together by default encourages modular commits that area easier to bisect.

Different strokes for different folks

[WuphonsReach]

Whether you use git/mg/etc (distributed VCS) or centralized VCS systems (SVN, etc) has a lot to do with the level of control that you desire/need and how much centralization you desire/need.

For some development projects / communities, where everyone is independent and rarely connected to a central point, the distributed VCS make more sense. The downside is that you have to rely on developers to push their changes to some "master". On the other hand, it means they can work offline / disconnected.

For the less technical users, centralized VCS like SVN makes more sense. As long as you can get them to commit the changes, you're ensured that those changes are now on a server/machine that is getting backed up and taken care of.

Re:Different strokes for different folks

[Anonymous Coward]

Your post is filled with nonsense. I've always used a central repo with git. That repo and all of it's backups could turn into a smoking crater, and we'd still be ok. With SVN, you better hope your backups are solid, because you're borked if you lose them.

Re:Different strokes for different folks

[ebno-10db]

Heretic! Real programmers use Git. Nobody else gets to sit at the cool kids' table.

Re:Different strokes for different folks

[Anonymous Coward]

For the less technical users, centralized VCS like SVN makes more sense. As long as you can get them to commit the changes, you're ensured that those changes are now on a server/machine that is getting backed up and taken care of.

That was one of the things that made me drop SVN as an option. What do you mean I need a server? Do I need a server admin too?

SVN may be fine for projects in a company, that have admins on staff. But for smaller projects where one doesn't have an admin on staff, GIT is much easier.

$ git init

That's it. No server needed, you don't even need to know the root password. And no need to take backups of a server either, the usual backup of $HOME includes the whole repository.

Re:Different strokes for different folks

[mordejai]

I don't know about you, but I usually try to keep "less technical users" away from software development.

Re:Different strokes for different folks

[Anonymous Coward]

...the distributed VCS make more sense. The downside is that you have to rely on developers to push their changes to some "master"...

...SVN makes more sense. As long as you can get them to commit the changes...

I'm not sure what point you are trying to make here. If you can't get your team to regularly update a central server, not only do you have serious management issues, but you have the same problem regardless of what VCS you use. If they do then the benefits in terms of backing up are the same.

Re:Different strokes for different folks

[Anonymous Coward]

SVN can be used as a VCS for other items too, like media or documents. Sometimes you want the less technical users to still get the benefit of version control.

Re:Different strokes for different folks

[Anonymous Coward]

That is all well and good if you have control of who is a software developer and who is not.

Re:Different strokes for different folks

[tlhIngan]

I don't know about you, but I usually try to keep "less technical users" away from software development.

Why? There's a LOT of places where version control is very useful outside of software development.

Keeping track of documents, for example - marketing folks run through a lot of variations of a theme and having a repository of older versions of the document is handy. Because otherwise they're going to do it themselves (you'll find documents with timestamps on them for that reason).

Sysadmins often use VC on their configuration files as well (I've known some to store their Cisco hardware configuration files in VC as well). Serves as a backup (the repos are backed up with the regular source code backup), as well as an "oh shit the switch went down what's the last configuration we have" panic. Instead of hunting through endless wads of files (did I put it here last time? Or is it over there?) you just grab the latest from VC, maybe go back a revision and use that.

Version control is extremely helpful for a lot of things - being able to hold the latest and previous versions of something in one spot is surprisingly helpful for a large number of instances.

Re:Different strokes for different folks

[Anonymous Coward]

I find that using git-svn with a central SVN repository results in a very nice workflow. In my local git repository, I'm free to develop in a nonlinear, exploratory fashion. At logical stopping points, this work gets neatly reconciled with reality in the form of sensical SVN commits. It's the best of both worlds, and allows me to do useful work even on an airplane.

Re:Different strokes for different folks

[Anonymous Coward]

That was one of the things that made me drop SVN as an option. What do you mean I need a server? Do I need a server admin too?

SVN works just fine without setting up a server.
http://www.guyrutenberg.com/2007/10/29/creating-local-svn-repository-home-repository/

Re:Different strokes for different folks

[Anonymous Coward]

How long has it been since you had to merge branches with SVN ?

I've used SVN for years before switching to git but i could never go back.
With SVN it's difficult to even know what you're supposed to merge (ie. at which commit start the changes you're supposed to merge).

SVN just wasn't designed for frequent merging.

Re:Different strokes for different folks

[Qzukk]

Sysadmins often use VC on their configuration files as well

Definitely. etckeeper (can be configured to use one of serveral VC systems) is excellent for this job and I use it so when I do something that breaks the server, rolling back the configuration to a known good state is trivial.

Re:Different strokes for different folks

[Anonymous Coward]

"less technical users" != "version control" :)

Re:Different strokes for different folks

[Anonymous Coward]

Sysadmins often use VC on their configuration files as well

I don't think letting less technical users administrate your systems is a good idea either.

Re:Different strokes for different folks

[osu-neko]

... As long as you can get them to commit the changes, you're ensured that those changes are now on a server/machine that is getting backed up and taken care of.

I solved this problem at my last job by setting up a testing environment that pulled changes from the repository. It helped that the system being worked on was large and complex enough that it would be a pain in the ass to try to set up a local copy on your own machine for testing, so everyone would just use the test server, which, in order to use, required a commit to the development repository so the test server could pull the commit and put it into testing (in fact, this was accomplished in the post-commit script). The SVN server would receive commits from every developer continually through the day, and even the tiny change always had at least one "backup" somewhere.

The only downside to this is commit log pollution, but it wasn't really a problem -- these tiny commits would just have an empty log comment that could be easily ignored, and when things were finally working well, the changes would then be merged into the main branch with a properly documented commit.

Re:Different strokes for different folks

[qwijibo]

Yet less-technical-admins are the inevitable result of outsourcing, so there's a lot of them out there.

Version control for system configuration is a great tool for figuring out what has changed over time. Teaching less technical people how to use basic svn commands is easy. 10-20 minutes of training and a one page doc of the 4 commands they'll ever use is all it takes.

Anything that I didn't document on the cheat sheet is my responsibility. Matching the skill set to the task has provided a lot of benefits over the years, yet I've never had to deal with a corrupted or messy repository.

Re:Different strokes for different folks

[TemporalBeing]

SVN can be used as a VCS for other items too, like media or documents. Sometimes you want the less technical users to still get the benefit of version control.

Especially since you can just set it up as a WebDAV drive for the users on Windows. They won't even know they're using VCS as it just looks like another network share drive.

Re:Different strokes for different folks

[TheRaven64]

If you're a one-man operation, Fossil gives you all of that without the braindead interface and in a much easier to deploy bundle (a single, small, statically linked binary, including a [versioned] wiki and bug tracker). But it's a strawman comparison, because you can also do svnadmin create as a non-root user and then use file:// URLs for accessing the repository.

Re:Different strokes for different folks

[TheRaven64]

You should be asking yourself the question you asked the grandparent. Subversion merging improved a lot with 1.6 and 1.7, and it looks like 1.8 fixes the remaining complaints I had about it.

Re:Different strokes for different folks

[Anonymous Coward]

Why? There's a LOT of places where version control is very useful outside of software development.

I agree and if you are going to be dealing with a lot of binary files, Subversion is definitely a better choice than git because of the cloning issue. Of course, both are revision control software and neither are meant to be a robust content management system, but there's definitely a case for using SVN as a CMS in simpler situations.

Re:Different strokes for different folks

[Anonymous Coward]

But Subversion is nasty. I'm much happier with distributed version control--especially since for my own projects it means I don't have to worry about setting up and maintaining a VC server. Especially considering your less-able users, keeping them from having to maintain a central Subversion repository is a plus.

Actually, I much prefer Mercurial to git. Think about your less-capable users: hg commands are much easier to deal with than the git ones.

Re:Different strokes for different folks

[Anonymous Coward]

Version control can be used as a poor-man's continuous backup, just less automated.
When you look at it that way, centralization makes the most sense.

Re:Different strokes for different folks

[Anonymous Coward]

But I do have control of which software developers have access to my repository, and I don't have to consider the ones who don't have access when deciding which SCM to use.

Re:Different strokes for different folks

[Anonymous Coward]

No, I hate to say it, but decentralized systems make much more sense in every possible scenario I can think of.

When you work on some specific piece, you don't want to actually commit your minor changes to a large repository. And I don't see any possible case where small incremental changes aren't beneficial.

Now when you push the code up, it could be in a larger patch that you've polished, but VCS isn't just about seeing a 1000+ line change patch in the central repository.

For less technical users the difference between centralized and decentralized systems is meaningless, it'll just be a bunch of arcane commands.

Re:Different strokes for different folks

[datavirtue]

As a lone developer I found Mercurial to very easy to setup and use. It is second nature now after a breif tutorial and I have never used any other VCS.

Re:Different strokes for different folks

[datavirtue]

I heard about a developer recently who was trying to pad two digit IP addresses with zeros (10.200.10.1 -> 010.200.010.001). The admin couldn't figure out WTF was wrong until he went onsite and verified the printer configuration. I remarked that he should probably not be developing software--he has ten years of development experience though.

Re:Different strokes for different folks

[datavirtue]

Unless you have Windows 7 which doesn't support WebDAV. True story. Check out the market prices on 3rd party WebDAV clients now.

Re:Different strokes for different folks

[datavirtue]

T-SQL scripts, Websites, documentation in technical fields

Re:Different strokes for different folks

[Anonymous Coward]

You're ignoring the real value that Git brings: fast branching. If someone pushes a branch up to the common remote on Git, I can see what they're doing the next time I fetch. On SVN, I have no knowledge of their branch unless they tell me.

Re:Different strokes for different folks

[Slashdot Parent]

(10.200.10.1 -> 010.200.010.001)

As much as that just made me throw up in my mouth, I've seen such nonsense out in the wild before.

Yuck.

Re:Different strokes for different folks

[WuphonsReach]

We use "FSVS" on the Linux boxes around here. It stores the contents in a SVN repository.

Re:Different strokes for different folks

[Anonymous Coward]

(10.200.10.1 -> 010.200.010.001)

As much as that just made me throw up in my mouth, I've seen such nonsense out in the wild before.

Yuck.

Its called IPV6 2002:f95:dcb2::f95:dcb2 :)

Re:Different strokes for different folks

[Zebedeu]

I've seen this workflow enforced on git-only environments by making the "master" git repository reject merges.
This forces developers to rebase their changes on the top of the master branch before pushing and at least for us it was working quite well.

I'm not familiar with git-svn, but I thought it was a kind of stop-gap solution for SVN devs who didn't want to switch with the project.
I'd be wary of using two source control mechanisms simultaneously as a permanent solution.

Re:Different strokes for different folks

[angel'o'sphere]

More interesting is the question why padding out the digit parts with zeros leads to problems.
I only can imagine that it might be problematic on windows.
Every real OS should have problem with 010.055.067.011

Re:Different strokes for different folks

[angel'o'sphere]

Should have _no_ problem, I ment :)

Nice improvements

[cold fjord]

Going through the article it looks like a nice set of improvements. I expect that subversion users will be pleased with both the current improvements, and what will be built upon them in the future.

Among the useful improvements noted:

One of the area where robustness has been improved is in the storage of metadata. SVN now tracks the moves of working copy items. Stein noted that the harder part is getting the rest of the system to recognize the moves, and that work is ongoing. He explained that from a historical perspective, SVN didn't "move" items per se. Instead, the item was copied to its new location, and deleted from the old.

"This is problematic (for example) because if an edit comes in from the server for that deleted item, then we don't know what to do with it," Stein said. "For a moved item, then we know the edit should probably be applied to wherever the thing was moved."

Re:Nice improvements

[Anonymous Coward]

Kinda weird really.

You should never be applying edits from the server on uncommitted (i.e working copy) items, as it effectively defeats one of the purposes of having version control. Forcing you to do a merge *before* committing is probably the most insane of SVN's many problems.

And somehow git does just fine applying changes to renamed files (and has done for years), despite not actually tracking such in metadata.

But can SVN merge a branch yet?

[cultiv8]

My only complaint of SVN and the reason I moved to git.

Re:But can SVN merge a branch yet?

[Duncan Booth]

Automatic branch merging is listed in the release notes. I have no idea though how well it works.

Re:But can SVN merge a branch yet?

[LizardKing]

It sounds like the proper support for renaming that's new in this release is a step in the right direction. I assume branching is still really copying in Subversion though, which I recall being problematic in earlier versions where you needed to know at what point you'd branched from to do merges.

Re:But can SVN merge a branch yet?

[RaceProUK]

Not used SVN for a few years, but I've merged branches several times with it. Not sure what you're trying to say.

Re:But can SVN merge a branch yet?

[ebno-10db]

Yes! That is the biggest problem with Subversion, and I hope that 1.8 fixes that as promised (although they're only promising partial support right now).

At work one of my side jobs is managing the VC for our small (5 person) dev team. For a small closely knit team centralized VC is fine, but the very limited merge capabilities of svn drive me nuts. It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.

I know I could overcome that problem by switching to Mercurial or Git, and I'd love to, but it's not a good idea with my team. Several of them are very good at what they do (Ph.D.'s in signal processing and detection and estimation) but have little interest in learning what is, for our purposes, the more complicated DVCS approach. Sometimes I feel lucky I got them to use VC at all, and it helps that the svn UI is a lot like the CVS that some of them already knew.

Re:But can SVN merge a branch yet?

[ebno-10db]

Pardon me reposting part of what I wrote above, but I think it explains what he was talking about:

It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.

Re:But can SVN merge a branch yet?

[phantomfive]

The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk.

I hate this version of work......I have some coworkers who always do it. They occasionally forget to merge something back into head, which means they have to revisit the same problem in a few months. If you're going to miss a merge, it's better to miss the merge back into the branch, rather than into head; because as long as it's merged into head, it'll be fixed eventually.

Re:But can SVN merge a branch yet?

[hondo77]

I've been merging to/from branches in svn for years. I did a branch-to-branch merge just the other day. Piece o' cake.

Re:But can SVN merge a branch yet?

[stsp]

It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk.

This limitation has been lifted in 1.8. As long as you use no merge commands more complex than

svn merge ^/branch/to/merge/from

the merge works in either direction and should never flag spurious conflicts caused by changes being applied more than once.

There were ways to work around deleting a reintegrated branch in 1.7, by the way. But the new 1.8 merging works better. Just forget about --reintegrate, don't use any -r or -c options, and you can always merge in either direction without any need for deleting branches.

Re:But can SVN merge a branch yet?

[Anonymous Coward]

Never had issues merging from branch to branch, trunk to branch, branch to trunk with SVN. We do the similar approach of trunk is for development and branches are for releases. Bug fixes can either be applied to the branch or the trunk. If the bug is specific to that release branch, then it doesn't get merged back into trunk.

Re:But can SVN merge a branch yet?

[TemporalBeing]

Pardon me reposting part of what I wrote above, but I think it explains what he was talking about:

It's ok to create a branch (say from trunk), work on the branch, and even update it from trunk, but you're pretty much limited to a one-time reintegration merge from that branch back to trunk. You can't easily go back and forth, choosing to put one new thing from trunk into branch and vice versa. That becomes a serious pain if, for example, you use trunk for new development and a release branch on the side. The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk. Similarly you may fix a bug in trunk and realize you should also merge it into the release. Svn doesn't really let you do that, so I have to tell people to always make the fix in trunk and merge that one change to the release.

Sure you can. You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over. And as of SVN 1.5 it keeps track of those merges so that when you merge other branches (that synced with trunk) or finally reintegrate it back to trunk it knows that those things were properly merged back.

And, nothing is to stop you from deleting a reintegrated branch and recreating it from a fresh copy of trunk using the same name if you really wanted to only do reintegrations.

And honestly, I'm not keep on the idea of not specifying the reintegrate myself, but I'll see how it works.

Re:But can SVN merge a branch yet?

[Anonymous Coward]

The natural way to work is, if a bug is found in the release, fix it in the release branch and then merge that one change back into trunk.

I hate this version of work......I have some coworkers who always do it. They occasionally forget to merge something back into head, which means they have to revisit the same problem in a few months. If you're going to miss a merge, it's better to miss the merge back into the branch, rather than into head; because as long as it's merged into head, it'll be fixed eventually.

I agree, except then you risk differences between the code in the release branch and the deployment.

Re:But can SVN merge a branch yet?

[ebno-10db]

I hate this version of work......I have some coworkers who always do it. They occasionally forget to merge something back into head, which means they have to revisit the same problem in a few months.

I've found that a good way to prevent that from happening again is to summarily execute the offender and hang his or her corpse from the flag pole as a reminder to others.

There's also Murphy's Law corollary that says that no matter what your preferred workflow is, there will come a day when doing it differently is necessary or expedient. For example, trunk may be temporarily unstable, which means you wind up fixing the bug on the branch. Of course trunk is never supposed to be unstable, but there are a lot of things that aren't supposed to happen. A good tool shouldn't keep you from working differently when necessary (which is what at least pre-1.8 svn does, or makes it very difficult to do anyway).

Re:But can SVN merge a branch yet?

[ebno-10db]

Sounds good. Out of curiosity, are you saying these things based on the release notes, or have you tried it with a pre-release version or something?

Re:But can SVN merge a branch yet?

[Anonymous Coward]

SVN has always been capable of that. The merge command takes a start and end revision number, and accepts a single revision number for both.

Re:But can SVN merge a branch yet?

[ebno-10db]

You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over.

Yes, I believe the SVN buzzword for that is cherry picking. I do it all the time to, for example, merge a fix in one rev of the trunk into a release branch. That's not the problem. The difficulty is when sometimes you want to do a cherry picked merge from trunk to branch, and the later do a cherry pick merge from branch into trunk. SVN gets confused about that. I admit I haven't done many experiments in that regard, since I don't want to mess up work in progress. However, it's not part of any workflows in the book, and certainly appears to violate some of the rules. Even if it works sometimes, I wouldn't want to rely on it. The only other possibility I can think of is that my understanding is messed up somehow. Frankly I doubt it, but if it's true I'd be very grateful for a correction.

Re:But can SVN merge a branch yet?

[jrumney]

I agree, except then you risk differences between the code in the release branch and the deployment.

I really don't see how either direction is better than the other in this respect. Either there are differences or there are not. Going from branch to trunk instead of trunk to branch doesn't change that.

Re:But can SVN merge a branch yet?

[Ben Hutchings]

Repeated merges have worked well for a while now (maybe since 1.6?). It's not quite as good at merging as git is, but it works well enough. But I have to agree with the general sentiment against merging from release to devel branches. Merging should be considered an expert-only operation (not expert in version control, but in the code base). Cherry-picking/backporting fixes from devel to release is safer because then you know exactly what you're changing.

Re:But can SVN merge a branch yet?

[Anonymous Coward]

trunk may be temporarily unstable

I don't know why anyone should listen to you for advice on managing workflow.

Re:But can SVN merge a branch yet?

[Kawahee]

I fucked up merging a branch in Subversion (I fucked it up, not Subversion) but the mistake I made isn't really possible in Git since it seems idiomatic (in Git) to merge whole branches, rather than ranges of commits.

I'll emphasise again that it was my fault but when I realised what I'd done I was wishing we'd migrated to Git already instead of putting it off.

Re:But can SVN merge a branch yet?

[TemporalBeing]

You just used targetted merges instead of a reintegration merge - e.g. specify which revisions to merge over.

Yes, I believe the SVN buzzword for that is cherry picking.

Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.

I do it all the time to, for example, merge a fix in one rev of the trunk into a release branch. That's not the problem. The difficulty is when sometimes you want to do a cherry picked merge from trunk to branch, and the later do a cherry pick merge from branch into trunk. SVN gets confused about that. I admit I haven't done many experiments in that regard, since I don't want to mess up work in progress. However, it's not part of any workflows in the book, and certainly appears to violate some of the rules. Even if it works sometimes, I wouldn't want to rely on it. The only other possibility I can think of is that my understanding is messed up somehow. Frankly I doubt it, but if it's true I'd be very grateful for a correction.

I have done that without any issues, as I am sure many on the SVN mailing lists have as well - both before and after the Merge Tracking was added. It's a natural part of the work flow. I can think of no SVN rules that it violates. In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation (see the section Keeping a Branch in Sync Without Merge Tracking), and that is also found in the SVN 1.4 documentation for The Key Concept Behind Merging. True, since Merge Tracking was introduced you typically only do "svn merge ^/project/trunk" into your working copy, but that's to move all changes from the trunk in - which you may not be ready for; and doing a cherry-picked merge is still 100% supported and encouraged when that is what you need to do.

One thing the SVN devs are keen on is giving the developer (or repository administrator) the flexibility to run the VCS as they need to meet the needs of the project(s) hosted in it. There's a lot about best practices, and you'll even find two conflicting best practices as each are targetted at conflicting methods of running a repository (e.g. trunk prestine vs trunk dirty).

Re:But can SVN merge a branch yet?

[ebno-10db]

Yes, I believe the SVN buzzword for that is cherry picking.

Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.

Normally I don't care what buzzwords people use as long as the meaning is clear. However since you make an minor issue of it, I feel free to get in touch with my inner pedant. "Cherrypicking" is the exact term used in SVN. However I spelled it as two words instead of one. Merriam-Webster lists it as a hyphenated word. We must standardize!

In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation

I do that all the time and it's very useful. The problem (or at least the thing I'm unclear about being reliable) is "svn merge -r A:B ^/project/trunk branch1wc/" followed some time later by ""svn merge -r C:D ^/project/branches/branch1 trunkwc/" (C > B). Some would argue that you shouldn't be switching back and forth like that in the direction of selective merges, and generally I agree, but in the real world people sometimes put the fix on the "wrong" branch (whether out of sloppiness or for some good reason) and that back and forth is then difficult to deal with.

Re:But can SVN merge a branch yet?

[TemporalBeing]

Yes, I believe the SVN buzzword for that is cherry picking.

Yes, that is the Git buzzword. I don't think SVN has a buzzword for it.

Normally I don't care what buzzwords people use as long as the meaning is clear. However since you make an minor issue of it, I feel free to get in touch with my inner pedant. "Cherrypicking" is the exact term used in SVN. However I spelled it as two words instead of one. Merriam-Webster lists it as a hyphenated word. We must standardize!

Honestly I don't care; I was more pointing to the fact that I believe it came from Git. I couldn't easily find a reference of the term for the SVN 1.4 docs; but it was there in the 1.5 docs - which would have been well after Git was established, so the SVN Red-Book authors adopted the term; I haven't really seen it used on the SVN mailing lists at all. That's all.

In fact, doing a "svn merge -r X:Y ^/project/trunk" is even part of an example in the latest documentation

I do that all the time and it's very useful. The problem (or at least the thing I'm unclear about being reliable) is "svn merge -r A:B ^/project/trunk branch1wc/" followed some time later by ""svn merge -r C:D ^/project/branches/branch1 trunkwc/" (C > B). Some would argue that you shouldn't be switching back and forth like that in the direction of selective merges, and generally I agree, but in the real world people sometimes put the fix on the "wrong" branch (whether out of sloppiness or for some good reason) and that back and forth is then difficult to deal with.

The SVN Merge Tracking introduced in SVN 1.5 does very well with keeping those things straight, and makes it quite reliable.

The problem prior to SVN 1.5 was that you had to track all the merges yourself and be very careful about how you merged. It wasn't that SVN was incapable of it, just that it was a big PITA to do it and know that you didn't double merge something. SVN 1.5 introduced Merge Tracking which has kept increasing in its smarts since - 1.5 already did the case of change A:B being done in one revision and changeset C:D in another, whether C:D came after A:B (e.g A < B < C < D) or even where it contained A:B within it (e.g C < A < B < D).

I generally don't worry about merges any more; I just do them and verify the result is what I intended - sometimes adding an extra log message in a file, or modifying a version number, and that's really about it.

Of course I almost always do a dry run (test merge) in order to know what to expect; and the only time I have seen where people have gotten into trouble with merges is when they fail to do the Double Merge - e.g Merge from destination to source, then source to Destination - when its all complete (e.g. for the reintegration merge).

Re:But can SVN merge a branch yet?

[angel'o'sphere]

Cherry picking is not a GIT buzzword. The term is well established since decades in various (commercial) version controll systems.

nice size

[Anonymous Coward]

1 TB repository? Are you storing piles of binary files in there? I cant imagine how many lines of code you could fit on that.

Re:nice size

[Anonymous Coward]

just one line of code...but it's a really long line.

Re:nice size

[Anonymous Coward]

... written in Brainfuck.

Re:nice size

[GPLHost-Thomas]

Probably not 1TB, but the whole of the python modules maintained in the team are stored using SVN. That's quite a lot. And Git wouldn't play well with that much. That's 520 packages currently: http://qa.debian.org/developer.php?login=python-modules-team@lists.alioth.debian.org

That being said, the only reason why we still continue to run with SVN, is that nobody is willing to make the effort to switch everything to Git.

Re:nice size

[Anonymous Coward]

1 TB repository? Are you storing piles of binary files in there? I cant imagine how many lines of code you could fit on that.

Why not version the binaries?

Graphics, icons, screenshots, PDFs, multimedia, etc... all sorts of non-code assets go into a typical project.

Versioning binaries (executables) that were built/tested/vadlidated means you've got a "known good version" and associated checksum even if the platform on which you built it ceases to exist. Some guy with a $100K CNC mill or other obscure piece of hardware that's down and needs to reinstall something that, say, only works on DOS?

Version binaries: "Sure, I can give you either the version 1.2.1 that you were running before the machine died on you, or version 1.3.2 that fixes that once-in-10-years bug you're complaining about. We don't support either of these anymore, but if you want to take a chance, it should work as well on 10-year-old hardware tomorrow as it did 10 years ago when we dropped support for DOS."

Version source only: "Current release 1.9.87654 won't compile under anything less than XP, and I'm not going to try to get DOSBOX to rebuild the source from 1.4.* and hope for the best, because even if I were stupid enough to try it, I wouldn't trust the results, and nobody remembers the build environments we used for 1.2 and 1.3"

Re:nice size

[Drinking Bleach]

Why keep that in version control though?

The tried-and-true method of just keeping around stuff like zip/tar.gz/exe files in a directory of every binary released should be fine... never delete the old releases.

Sparse checkouts

[IanCal]

While a little more work than with svn, you can checkout just part of a repository: http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/

Although I'd argue that if this is a common problem then you probably have several sub-projects.

Re:Sparse checkouts

[Slashdot Parent]

Well, I'm glad to know that git now supports sparse checkouts, even if it does so in a convoluted fashion.

However, I have one question: Why would anyone want to check out only part of a repository?

Re:Sparse checkouts

[angel'o'sphere]

Because in the repository are many "projects" and you only want to work on one?

It's GIT for OSS, SVN for Enterprise.

[goruka]

While GIT expresses the distributed development nature of open source projects much better nowadays, SVN fits the workflow of enterprise projects much better:

-SVN has much better visual tools and is simpler to operate
-SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.
-SVN is very friendly for projects with a lot of binary objects (ie videogames)
-SVN allows different people to work on different directories individually, GIT doesn't.
-SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.

They are different systems with different scenarios in mind, comparing them or claiming that GIT is killing SVN is just ignorance.

Re:It's GIT for OSS, SVN for Enterprise.

[LubosD]

-SVN allows different people to work on different directories individually, GIT doesn't.

The idea of Git eludes you. You don't structure Git projects in a giant directory tree.

-SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.

Have you ever heard about Gitolite?

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

Are you middle management by any chance? You seem to have no idea what you're talking about.

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

SVN has much better visual tools and is simpler to operate - like what, tortoisesvn? http://code.google.com/p/tortoisegit/

SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes. - The person responsible for the changes switches back to master and pulls their branch in, and runs tests, rather than just blindly push and hope everyone copes.

SVN is very friendly for projects with a lot of binary objects (ie videogames) - No issue here. Git sucks for keeping changes between binary files. Not sure if SVN is better, but git is bad.

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

Our 100 developer enterprise software team uses git, and it is massively better than SVN IMO.

First off, large repo performance is order of magnitudes better. Git repo clones take 1/4 or less the time vs an SVN checkout.

Pull requests work great for many team projects where developers are not familiar with the entire codebase. The codebase can be split into separate repos with different permissions. When a developer makes a change to part of the code they're not an expert at, they create a pull request and a member of a team who does know that piece of code reviews and merges. This is much easier than passing around patch files like you have to do with an SVN repo with strict permissions. It's also much easier for interns and contractors to work on code, since they can clone the repo and create a pull request to merge their changes without having write access to the repo.

IntelliJ has great GIT bindings, just as good as SVN. It will highlight which lines have been modified since the last commit, I can click on a line to see it's commit message/date, I can resolve conflicts with a gui tool, etc.

Git is a more complicated tool and takes longer to learn, but once you learn it branching, stashing, rebasing make day-to-day development tasks much easier/faster.

Re:It's GIT for OSS, SVN for Enterprise.

[Bill_the_Engineer]

While GIT expresses the distributed development nature of open source projects much better nowadays, SVN fits the workflow of enterprise projects much better:

Actually... git fits the workflow better than svn. I have to manage a project that spans multiple institutions and two continents. Instead of forcing everyone to use VPN while they develop, they only need to use VPN to push to the official repository.

SVN has much better visual tools and is simpler to operate

What? I use SourceTree on OS X and my coworkers on Windows like TortoiseGit. Also there is "git gui"

SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.

What? I don't think you understand how git works.

SVN is very friendly for projects with a lot of binary objects (ie videogames)

Not necessarily. We use both svn and git to manage very large BLOBs and I haven't seen any noticeable differences. I have people that version control gigabytes worth of design documents that are stored in binary format and I haven't heard any complaints from them.

SVN allows different people to work on different directories individually, GIT doesn't.

We used to think this was a big deal, but the advantages that git has over svn more than made up for this.

-SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.

What? First not by default. The most popular method https+ssh does not. You can use Crowd to make it a little easier.

Whereas in git I use gitolite. I manage their public keys and assign privileges based on the public key. Keep the NDA (or more importantly ITAR) in a separate git repository which makes life easier all around and satisfies the regulators too. They weren't too comfortable with trusting the single repository to handle the compartmentation correctly.

They are different systems with different scenarios in mind, comparing them or claiming that GIT is killing SVN is just ignorance.

I operate both SVN and GIT systems. My anecdotal evidence show that most of my projects left SVN and went with GIT due to its distributive nature. We have operational processes in place that eliminates the need for physical enforcement of a centralized repository. As an extra bonus, my co-developers like the ability to check in while they develop and then push the changes once they are confident that it won't break the build on the official repository.

Re:It's GIT for OSS, SVN for Enterprise.

[KingMotley]

Pull requests work great for many team projects where developers are not familiar with the entire codebase. The codebase can be split into separate repos with different permissions. When a developer makes a change to part of the code they're not an expert at, they create a pull request and a member of a team who does know that piece of code reviews and merges. This is much easier than passing around patch files like you have to do with an SVN repo with strict permissions. It's also much easier for interns and contractors to work on code, since they can clone the repo and create a pull request to merge their changes without having write access to the repo.

How is that different from creating a branch for the developer/contractor/intern and only giving them write access to their branch, and when complete having someone else merge their branch back into master after doing any code review?

Re:It's GIT for OSS, SVN for Enterprise.

[TheRaven64]

The idea of Git eludes you. You don't structure Git projects in a giant directory tree.

The first problem here is that you need to decide, up front, what your structure should be. For pretty much any large project that I've worked on, the correct structure is something that's only apparent 5 years after starting, and 5 years later is different. With git, you have to maintain externals if you want to be able to do a single clone and get the whole repository. Atomic commits (you know, the feature that we moved to svn from cvs for) are then very difficult, because you must commit and push in leaf-to-root order in your git repository nest.

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

Hi,

You are making a big statement by saying that.

>-SVN has much better visual tools and is simpler to operate
Try smartgit, it's friendly enough to get you started.

>-SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.
That's one of those "it depends" . If your team cant understand merge commits, rebasing or stashing then yes you have a bigger problem.

>SVN is very friendly for projects with a lot of binary objects (ie videogames)
I dont understand this statement. I guess you must be referring to some sort of performance issue perhaps? a bin is a bin..

>-SVN allows different people to work on different directories individually, GIT doesn't.
Hmm, yes it does actually.
http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/

>-SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.
Hmmm, gitolite + a specific branch could do the work.

>They are different systems with different scenarios in mind, comparing them or claiming that GIT is killing SVN is just ignorance.

Indeed and one is easier than the other one. Good thing you are using source control, that's for sure.

Re:It's GIT for OSS, SVN for Enterprise.

[csumpi]

-SVN has much better visual tools and is simpler to operate

If your employees can't operate git, you should fire them.

-SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.

You can use git the same way, but svn doesn't support the workflow flexibility git does.

-SVN is very friendly for projects with a lot of binary objects (ie videogames)

I have gigabytes of binary stuff in git, no issues.

-SVN allows different people to work on different directories individually, GIT doesn't.

The biggest improvement with distributed source control is that users can work parallel, even on the same files. Try editing the same file on svn, see what happens. On this point, git definitely wins big time.

-SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.

Same as your first point. You need competent people in your workplace. You can do the same with git.

Re:It's GIT for OSS, SVN for Enterprise.

[SoftwareArtist]

I'm sure this will be an unpopular opinion, but I seriously loath git. Its distributed development model is nice for certain types of projects, but aside from that, doing almost anything in git is more complicated and more work than doing the same thing in svn.

I think the fundamental architectural flaw in git is that it insists on a 1:1 correspondence between repositories and working copies. If you want a working copy, you absolutely must have a unique repository to go along with it, and that repository must be on your local disk. You can't have a local working copy based on a remote repository, and you can't have multiple working copies based on the same repository. And of course, each repository comes with its own revision history and its own distinct set of branches. I switch back and forth between several computers over the course of a day, and keeping all those repositories properly in sync with each other is a nightmare.

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

We have operational processes in place that eliminates the need for physical enforcement of a centralized repository.

You sound like the NSA :)

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

-SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.

I haven't used SVN since it kept asking me to choose revision numbers to be merged (which is just insane - shouldn't the VCS be tracking what's merged? It's the //VCS//) - but my main response to this point is: what kind of Enterprise environment doesn't have someone owning HEAD and thus the merges?

-SVN is very friendly for projects with a lot of binary objects (ie videogames)

Not if you want to branch anything; then SVN isn't friendly to your disk usage at all.

-SVN allows different people to work on different directories individually, GIT doesn't.
-SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.

Git does better than this by not even having those things in the same repository.

They are different systems with different scenarios in mind, comparing them or claiming that GIT is killing SVN is just ignorance.

This I mostly agree with though. But I'll add one thing: using SVN, you have to adjust your team's workflow to the SVN model, because you have one VCS server that has to be involved in all versioning.

With Git (or any other distributed VCS, to be fair), you can decide on a workflow and then arrange your repositories to suit. Want team leads reviewing code before distribution to the department? Cake. Want dev, test, QA and prod on different repos *and* track the migration of code between them? Easy. Want each site to have a local repo that sychs overnight? Supported.

Also: have you ever tried to restore a SVN server from a backup? For a team?

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

SVN is very friendly for projects with a lot of binary objects (ie videogames)

Not necessarily. We use both svn and git to manage very large BLOBs and I haven't seen any noticeable differences. I have people that version control gigabytes worth of design documents that are stored in binary format and I haven't heard any complaints from them.

It's a difference between downloading 10GB worth of assets with SVN vs downloading whole 1TB repository with Git.
Additionally, SVN allows you to download only specific files so if you don't need assets you can exclude them.

Another weakness of git is it's lack of rename awareness during merges - something that seems to be fixed in this new version of SVN.
This is important if you use language like Java where file paths correspond to code structure and any refactoring will move files around.

Now, git has a much better foundation and all such issues could be fixed with moderate amount of work. Unfortunately despite frequent requests for things like lazy fetching, no one capable seems interested in implementing it :(

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

It doesn't require as much overhead. Branches in git are local. I can completely isolate my changes from all remotes. I can store local configuration differences in my local. I can rebase my commits and only publish them after I'm sure they are correct.

Git allows me to be selfish and also self-contained. It allows me to hide the mess from the branch or the trunk or the merge and make the lead's life easier without him knowing about any of it.

For competent folks...it's all the difference. I don't have to have someone create me a new branch...I don't have to be granted write access. When the merge time comes, I can say "here's my changes from what you have in your master right now...do you want them or not?".

The commits aren't already there. Think of git as providing a publishing model. I can publish my local changes when they are actually ready, while keeping my own commit history so I can experiment without having to use things like Eclipse's local history. You're spared the details in the repository.

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

It has been implemented. It's called "sparse checkout".

I have no idea what "rename awareness" means. Git tracks the content, not the file name, and is perfectly aware of when you have renamed something.

git log --follow -- filename

should tell you all about that, although Linus says that this was a quick hack developed to please SVN noobs. If you are smarter than Linus feel free to contradict him.

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

It's a nightmare because you suffer from SVN brain damage. git makes it easy for you to create branches exactly so you can work with them and commit without being afraid of destroying them later. It's trivial to reorder, squash and change the commit message of an entire branch`s worth of commits when merging it back.

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

SVN also has the advantage for huge repositories, take the parent's 10GB art repo example.
Whilst it's true you can clone that with GIT using --depth 1 (aka, a shallow clone), there is the risk the transfer gets interrupted, 10GB takes a while.
SVN lets you resume (sort of), whilst git requires you to clone from scratch.

Re:It's GIT for OSS, SVN for Enterprise.

[goruka]

Actually... git fits the workflow better than svn. I have to manage a project that spans multiple institutions and two continents. Instead of forcing everyone to use VPN while they develop, they only need to use VPN to push to the official repository.

Your argument is "Actually, git is better than svn because [insert completely uncommon case that is not the norm]", you can't make a point with an exception to the norm. Most corporate or enterprise scenarios are not like that.

What? I don't think you understand how git works.

No, I don't think you understand how companies work. The most common workflow is update when you arrive and commit when you leave and eventually fix a file and commit it while you are working with something else. Both are difficult to handle with GIT because it involves sending over the whole thing and the complete inability to do the second scenario (send an unrelated simple fix while the rest of the project may not even compile or work).

My anecdotal evidence show that most of my projects left SVN and went with GIT due to its distributive nature.

Your anecdotal evidence, from what you mention, is far from the norm. You said yourself twice it's distributed projects while by far most companies don't do that. Of course GIT is better for that, but it's ignorant to assume that it will work in every other company in the work better than SVN because of that.

Re:It's GIT for OSS, SVN for Enterprise.

[Slashdot Parent]

-SVN has much better visual tools and is simpler to operate

The svn command line is definitely simpler, but for git visual tools, try SourceTree. Awesome tool, but I think it's only free as in beer.

-SVN has a simpler merge policies which are friendlier when there isn't a central person pulling the changes.

I have never had good luck with svn merges. It always seemed to do what I didn't want it to do. Haven't tried under 1.8, though.

That being said, have you used github or bitbucket's pull request tool? I've used bitbucket, and it's frickin' awesome. The pull request workflow supports a full-on code review with back and forth possible, before the final pull is done. Super awesome.

-SVN is very friendly for projects with a lot of binary objects (ie videogames)

I'll take your word for it here. I've never worked with a lot of large binary objects.

-SVN allows different people to work on different directories individually, GIT doesn't.

I don't even know what that means.

-SVN has fine grained permissions, access and authentication controls, very useful when parts of your project (ie, APIs) are under NDA or you don't want them to leak.

I suppose with SVN you can restrict access to a certain directory, and this is not possible with git. With git, you'd need to pull the sensitive API out into its own project and control access to that other project, perhaps deploying the compiled library to a central server.

Re:It's GIT for OSS, SVN for Enterprise.

[Slashdot Parent]

I can kind of see what you're saying, but I have never encountered this in a large project.

On some large projects, the entire project is in one large repository, which git supports.

On other projects, it is broken up into modules with separate repositories, but the artifacts from each module is deployed to an enterprise-wide maven repository. The modules can depend on each other and depend on certain versions of the other modules. With loose coupling between the modules like that, you don't need atomic commits between the modules.

Am I missing something? I've just never been in the position that you describe.

Re:It's GIT for OSS, SVN for Enterprise.

[Slashdot Parent]

How is that different from creating a branch for the developer/contractor/intern and only giving them write access to their branch, and when complete having someone else merge their branch back into master after doing any code review?

Mostly because merging in svn is (was?) broken beyond belief and your plan, while good in theory, just does (did?) not work in practice.

I see that svn 1.8 improves merging, and I hope that's true. That was really my biggest complaint with SVN was that nonlinear development was impossible due to such poor merging capabilities.

Re:It's GIT for OSS, SVN for Enterprise.

[Slashdot Parent]

No, I don't think you understand how companies work. The most common workflow is update when you arrive and commit when you leave and eventually fix a file and commit it while you are working with something else.

I agree that this workflow is common, but it doesn't really help the developer as much as it could.

I don't want to launch into a huge treatise on common git workflows because there are graphical guides out there that illustrate it much more clearly than I could in a slashdot comment. Check out Atlassian's git workflows page, and in particular, look at the Feature Branch workflow and the Gitflow workflow.

Hopefully that will result in an "Aha!" moment for you, but if not, that's cool. You'll get there eventually. :) Most people who give git a serious try wind up preferring it. It does have a learning curve, though. Which is unfortunate. The curve can be flattened quite a bit with one of the graphical tools out there. Try SourceTree. It's a good one, but not open source. It's free as in beer, which some people hate.

Re:It's GIT for OSS, SVN for Enterprise.

[Slashdot Parent]

FYI, SourceTree is on Windows now, too. Just so you know.

And I agree, it's a great tool.

Re:It's GIT for OSS, SVN for Enterprise.

[Slashdot Parent]

doing almost anything in git is more complicated and more work than doing the same thing in svn.

Except for branching/merging, which was hopefully corrected in svn 1.8.

Beyond that, I'm not sure that I totally understand your complaint with respect to repositories and working copies, but I see that you want to keep several computers in sync. I think what might be happening here is that you are not using a central git server, and instead are trying to sync between computers by pushing/pulling between them. Is that correct?

You'd want to use a central git server like the one that comes with it or gitolite or one of the many web-based git hosting applications. Or, more creatively, what you might really want is to sync your repositories/working copies with dropbox or something like it. After all, you're not trying to collaborate with anybody on all of those computers. You just want to be able to work on any one of them. If it were me, I'd probably test out dropbox.

Re:It's GIT for OSS, SVN for Enterprise.

[SoftwareArtist]

No, I'm actually using Github. So there's the main repository for the project, and then I've created my own personal fork, also on Github. And I'd really like to just create a working copy on each computer, all pointing to my personal repository on Github. But I can't. Instead I have to create yet another repository on every computer I work on, and then keep all of them in sync with each other. This just creates extra steps, and extra opportunities to make mistakes.

I can't count how many times I've committed changes on one computer, then gone over to another computer to test them, only to discover I forgot to also do a "git push", so then I have to walk back over to the other office to push them up to Github.

Or I try to do a "git pull", but it fails because I have uncommitted changes, so I have to stash them, then do the pull, the reapply them from the stash. Very very irritating.

And every time you do a "git push" or "git pull", you have to specify the branch. And it's really really easy to accidentally pull changes into the wrong branch, which creates a mess.

Speaking of branches, there's another "feature" that makes all of these problems far worse. (I'm not sure whether this is actually a feature of git, or something specific to Github.) When you send a pull request, you only intend it to refer to a particular set of changes. But it doesn't actually specify them. All it specifies is the branch, and if you commit more changes on that branch before the pull request gets merged, those will get merged too. So you are basically forced to create a new branch for every single change you make, no matter how trivial. If I commit a one line bug fix, I first have to create a new branch for that one line bug fix. Otherwise, there's a risk that whatever I check in after it will get added to the same pull request, even though it's unrelated and not yet ready to be merged.

Working with svn, I only create branches very rarely, perhaps once every few months. There's no need for them the rest of the time. Working with git, you're creating and deleting and merging branches almost continuously.

Re:It's GIT for OSS, SVN for Enterprise.

[TheRaven64]

On some large projects, the entire project is in one large repository, which git supports.

In that case, you have to clone the entire repo, which is fine if you're working on everything or need to build everything, but it is irritating if the project is composed of lots of smaller parts and you want to do some fixing on just a small part. For example, a collection of libraries and applications that use them (and possibly invoke each other).

On other projects, it is broken up into modules with separate repositories, but the artifacts from each module is deployed to an enterprise-wide maven repository. The modules can depend on each other and depend on certain versions of the other modules. With loose coupling between the modules like that, you don't need atomic commits between the modules.

If you modify a library and a consumer of the library, then you want an atomic commit for the changes, especially if it's an internal API that you don't expose outside of the project and so don't need to maintain ABI compatibility for out-of-tree consumers. With svn, you can do this with a single svn commit, even if you've checked out the two components separately. With git, you must commit the library change, then push it, then commit the user change and then update the git revision used for the external and commit that then push those. Or, if neither is a child of the other, you must first commit and push the changes to the program, then you must update the external reference from the repository that includes both and push that. You have to move from leaf to root bumping the externals version to ensure consistency.

If you don't jump through these hoops, then your published repositories can be in an inconsistent, unbuildable, state. It's not a problem if all of the things in separate repositories are sufficiently loosely coupled that you never need an atomic commit spanning multiple repositories, but it's a pain if they aren't. With git, you are always forced to choose between easy atomic commits and sparse checkouts. With svn, you can always do a commit that is atomic across the entire project and you can always check out as small a part as you want.

Re:It's GIT for OSS, SVN for Enterprise.

[Slashdot Parent]

Let me say it again. I think you will be much happier if you use a tool other than git for file synchronization. Git is a version control system. Try some type of sync tool or use a network-attached filesystem, if appropriate. Dropbox seems like an obvious choice because it's fairly cross-platform.

And you are correct about branches being the finest granularity of pull requests. It makes a lot more sense if you are using a common git workflow of doing each unit of work on its own branch. So if you are fixing issue #2773, you would create a branch for that fix. And if you were adding feature #2552, you'd create a branch for that. But you wouldn't do any more work on your branch for "fixing issue #2773" once it's fixed. You'd never make more commits to it. You'd probably just delete it.

I'm not sure how it works on github, but on bitbucket, you can set the pull request to automatically delete the branch once it's accepted. There is no need to keep those little branches around forever.

Re:It's GIT for OSS, SVN for Enterprise.

[Slashdot Parent]

If you modify a library and a consumer of the library, then you want an atomic commit for the changes, especially if it's an internal API that you don't expose outside of the project and so don't need to maintain ABI compatibility for out-of-tree consumers.

In the Java world, I'm just so used to publishing artifacts to Maven repositories that it never really even entered my consciousness that there would be a reason to have atomic commits between modules. When modules depend on other modules, it is always a specific version, and every version of that artifact is always available via Maven.

If you do need atomic commits between modules, then yes, you would have to have a very convoluted workflow with git, if it's even possible at all. But, really, isn't it better to go the loosely-coupled route? What if some code that is outside of your SVN repository uses one of your modules? How do you keep them synchronized?

FYI, git does now support sparse checkouts, but I have never had the occasion to test that feature.

Re:It's GIT for OSS, SVN for Enterprise.

[SoftwareArtist]

Try some type of sync tool or use a network-attached filesystem, if appropriate.

That's exactly my point. With any other version control system, this simply isn't an issue, because all other version control systems are fine with creating multiple working copies on multiple computers that all reference the same remote repository. In fact, synchronizing changes between computers is a large part of what they do. But not git. Suddenly I'm supposed to set up a file sync system to solve a problem that only exists because of an architectural flaw in git.

Of course, that's just a workaround. If you look through git documentation, it will never tell you to do that. It will claim git is a great tool for people who work on multiple computers, and that nothing more is required than a "git push" and "git pull" each time you switch computers... before diving into all the problems that come up and all the things you need to do to work around them. Workarounds that are so painful, you've decided it's easier to just sidestep them and use a completely different tool instead.

Re:It's GIT for OSS, SVN for Enterprise.

[Slashdot Parent]

Well, you should use whatever tool works for you.

I will point out that the need for push/pull is not an architectural flaw. It is the necessary consequence of using a distributed version control system. If you prefer to use a centralized version control system, then you should do so.

I am aware of the git documentation advising users to use push/pull to achieve synchronization between computers, and while that is an OK way to do it, I feel that it lacks some elegance and automation. Basically, you'd need to set up git remotes for all computers that you work on, and when you move from one computer to the next, you'd do a pull from the one that you were just working on previously. Maybe some people work well in this way, but that solution seems a bit fragile to me.

The other option is to push/pull with a centralized server. I don't personally like this option because I don't like to push changes before they're ready to be seen by others. And switching computers doesn't mean that I'm ready to publish my changes. Seems like a misuse of git's workflow to me.

Personally, I prefer to use the right tool for the job, and so I use a version control system to track versions of files, and I use a synchronization tool to synchronize. You are free to shoehorn the wrong tool into your job if that is what makes you happiest and most productive.

Re:It's GIT for OSS, SVN for Enterprise.

[mattack2]

doing almost anything in git is more complicated and more work than doing the same thing in svn.

I'd say the same thing about cvs vs svn. No, cvs was not the first source repository system I used either. If svn really was just "a better cvs", basically a superset, I'd like it. Dealing with the !@$ URLs vs just "cvs tag MYProject-35" and having to tag before I do the build, rather than tag right before submission (based upon my local source copy)..

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

So basically you base your whole premise on your own anecdotal evidence and present it as fact. Also you only attack the first bullet point and from that single argument conclude that SVN is the clear winner... Wow you are a fanboy.

Re:It's GIT for OSS, SVN for Enterprise.

[Bill_the_Engineer]

So your criticizing my assertion that workflows are better served with git than svn is supposed to distract us from the fact that you don't fully understand git? Your original assertion "GIT for OSS, SVN for Enterprise" is an old argument that lost its steam a very long time ago.

Using git doesn't prevent you from having a centralized repository like SVN. In fact, we use it in that manner too. What git does allow is the developers to commit to their local repo while they develop and pushing their changes to the central repository when they feel the code is ready. This allows them to have all the niceties of rollbacks and fine grain logs without the hassle of development branches being formed on the main repo. They can still use branches in git to keep in sync locally, work on a branch as a sub-group on the main repo, or allow a single developer to work on a side item from multiple locations (i.e. take their work with them).

I can use GIT like SVN, but I can't use SVN like GIT.

FYI - I didn't say all corporations have distributed workflows, nor did I say my company's projects are exclusively distributed. I just said MY project was better served by using a distributed repo. The more traditional projects still liked git for the "my co-developers like the ability to check in while they develop and then push the changes once they are confident that it won't break the build on the official repository." Also the project leads like gitolite better for managing access than svn.

Re:It's GIT for OSS, SVN for Enterprise.

[Bill_the_Engineer]

Cool. My coworkers use TortoiseGit because they are already used to TortoiseSvn.

Re:It's GIT for OSS, SVN for Enterprise.

[goruka]

Simple answer, I fully understand git and tried to use mercurial and git in enterprise and failed (been requested to move back to SVN and learned my lesson):

-commit to local has more downsides than upsides, it's more difficult to understand for newcomers, and non tech people that might also be using the repository. It's also not of much use in enterprise because you work with tight release cycles
-merging is more powerful in git, but again, those that don't fully understand it are prone to make a lot of mistakes, which resulted in more man hours to fix.
-SVN can do many things GIT can't, you probably didn't read my original post carefully, but the ability to commit single files or work in subdirectories is a win for when you have a team working together in the same room. It's also perfect for when you want to give someone from the outside access to the repo and only restrict it to a part of the project, yet everything on the server allows you to tag versions precisely. You could try to do this with multiple repositories in GIT, but it gets much more difficult to create branches for single revisions.
-SVN is just better for managing huge repositories that are mostly BLOBs (web, videogames or enterprise multimedia software in my experience) and uses much less space on disk, server and bandwidth.

It's as simple as that, for typical software factory where everyone works in the same building, SVN is simpler to use, mantain and goes straight to the point. GIT is just not meant for it even if you can simulate that environment, so it's not positive in my opinion to consider GIT a jack of all trades, because it's only really good for distributed.

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

Note that your entire post is garbage because you just need to sync one git repo and one private copy. There's no need to have more than one private, so the only thing svn does is add extra complexity here that you don't have with git.

Re:It's GIT for OSS, SVN for Enterprise.

[Anonymous Coward]

No, sorry, you do not "fully understand" git in the slightest, otherwise your posts would be a quarter as long because most of your arguments are complete nonsense.

1TB repository?

[Nutria]

Who has a 1TB repository? Even 200GB is 15 shades of ginormous.

Re:1TB repository?

[jez9999]

Who doesn't store their DVD collection in source control?

Re:1TB repository?

[Xest]

Lots of places really.

Some companies use it for versioning of content as well as just source code and that may mean archiving raw versions of said content such as images, 3D art assets, uncompressed audio and so forth.

Re:1TB repository?

[Anonymous Coward]

I used to work at a game dev house and all the artists would put their photoshop and maya files into the SVN repo. It wasn't quite 1TB, but it was massive. I'm not sure subversion is the best for this, but it's what I inherited, and I can easily see having version control for those types of things be useful.

Re:1TB repository?

[Anonymous Coward]

Our SVN repo is approaching 4GB. All our games assets (graphics/sound/video) are (and have to be) version controlled.

Re:1TB repository?

[Anonymous Coward]

Quite often binary dependencies are stored in SVN aswell. Once you start storing images, soundfiles, video and other blobs the size can grow quite quickly. Storagespace is cheap anyway nowadays, many reasons for keeping that stuff outside of VC don't apply anymore and there are benefits to storing it in there.

Re:1TB repository?

[Anonymous Coward]

On the last games I worked on, a minimum initial sync to build was around 50GB, full sync was over 150GB (MANY different language versions of NIS movies.) I have no idea how big the revision database was but I'm going to guess freakin' huge with over 600000 commits during the project. The BlueArc backing Perforce was bretty large.
Git would explode in a cloud of fail if you tried to do anything like that, in my opinion it's for toy sized projects.
Where I work now (at a semiconductor company) the people calling the shots switched from Perforce to Git and it truly sucks. There's over 400 repositories to build the project managed by a nasty set of shell scripts. What I wouldn't give to have a single place to manage all of the changes.

Re:1TB repository?

[Anonymous Coward]

On the last games I worked on, a minimum initial sync to build was around 50GB, full sync was over 150GB (MANY different language versions of NIS movies.) I have no idea how big the revision database was but I'm going to guess freakin' huge with over 600000 commits during the project. The BlueArc backing Perforce was bretty large.
Git would explode in a cloud of fail if you tried to do anything like that, in my opinion it's for toy sized projects.

Adding a large amount of binary content to a source control system is all sorts of stupid. Get out of the dark ages and use a Maven repository like Nexus to store that crap, then integrate those artifacts into your build process via Ivy/Maven/Gradle/etc.

Re:1TB repository?

[Anonymous Coward]

Only for George Lucas Star Wars revisions...

Re:1TB repository?

[Anonymous Coward]

Additionally some places store the compiled version of the software alongside the source code. For large, complex projects it's necessary to precompile the software to make it quicker to deploy. Keeping it in the repository makes everything much simpler.

Re:1TB repository?

[Anonymous Coward]

That is the problem, Git is a source control system while something like Perforce (and to a lesser extent Subversion) are really version control systems.

Re:1TB repository?

[greg1104]

Lucas doesn't need version control for his Star Wars changes. Once he's got the new one, he throws all of the old versions away.

Re:1TB repository?

[Anonymous Coward]

Who has a 1TB repository? Even 200GB is 15 shades of ginormous.

People who need store and version large binary files, say Autocad files. Which would be everyone who is actually involved in the manufacture of physical products of a non-trivial nature.

Unfortunately producing a physical product in an industrial setting is a alien concept to most of the people here.

Re:1TB repository?

[TechyImmigrant]

Adding a large amount of binary content to a source control system is all sorts of stupid. Get out of the dark ages and use a Maven repository like Nexus to store that crap, then integrate those artifacts into your build process via Ivy/Maven/Gradle/etc.

What makes you think all versionable content is source code?

Re:1TB repository?

[Anonymous Coward]

Who has a 1TB repository?

1: We check in all of our different cross-compilers. This way, when we extract a label, we get 100% of what we need to do a build. For regulatory reasons, we need to be able to re-compile from source and get an exact SHA-1 match -- so for safety, nothing can be left out of the label.

2: We release full SD card images, and we need to keep a history of releases. It's true that we wouldn't strictly need to check those binaries back in to version control. But having a unified filing system sure simplifies things a lot. Version-control labels are a crucial organizing tool for us -- for example, QA puts labels on tested collections of binaries. If we tried to use a simple Windows NAS folder for that, it would be like going back to the stone ages.

3: Different versions of video. Different versions of CAD files. Do I need go on?

You're questioning a 1TB repository? That's your inexperience showing.

Re:1TB repository?

[david_thornley]

Git is for toy-sized projects? It was created for Linux kernel development. That's a toy?

Hg

[LizardKing]

Everyone and their brother seems to have moved to Git

I've seen a lot of proprietary development moving to Mercurial, but haven't heard of anyone moving to Git. The latter seems to be much more popular for Open Source stuff.

Re:Hg

[pmontra]

All the closed source software for customers of mine (usually web apps and related services) was already on git when I took over the projects or has been migrated afterward (usually not my call). The only exception was a 1 GB svn repository of binary files that we don't really need to work much with and didn't make sense to convert. Anyway the two of us are too small a number to make a statistics. Just my two cents anecdote.

But in some environments git has become a de facto standard. Almost any Ruby gem is on github, which makes it easier to install, fork and modify. That means that many people and companies also use it for their private projects because they're accustomed to the tool. They also have desktop clients for Mac and Windows but I have no idea of what they do. I see customers hosting they remote git repositories on bitbucket too and somebody run their own server.

After years of git I can't think of using a pure centralized system anymore. Too limited.

Re:Hg

[zarr]

My 2 cents worth of data confirms your experience. My 3 last employers all moved to git from cvs or svn while i worked there. The first one was developing multi million LOC enterprisy stuff and ended up being bougth by Microsoft, which was ironic, until MS actually started supporting git themselves in tfs'12. How is that for closed sorce adoption? :)

SVN

[thrasherm2]

I've used svn for years. Still do. I've have not used git. Not really on topic, but there's SourceForge Enterprise which is free for up to 5 users (I think?). Good for a very small team of developers. It turns out git has an enterprise edition too http://readwrite.com/2011/11/01/github-launches-enterprise-can#awesm=~o9dDRS2KGzeDLJ . Has anyone used git's enterprise vcs? How is it?

Git is much better for large repos

[Anonymous Coward]

Yeah, but with Git at least you have the option of cloning that 1T repo if you really want to. If you try to checkout a 1T repo with SVN it will take weeks.

Re:Git is much better for large repos

[Duncan Booth]

You are confusing the repo size with the size of a checkout. With Git they are pretty much the same, but with SVN you only checkout the revision and indeed the branch that you actually need. If the repository has been well managed there may not be much in it, but as soon as someone adds binaries to the checkin the repository size is likely to explode. Here's an example: I wanted to play with a particular application environment just to get an idea what it could do. Their main 'kitchen sink' sample program at that time didn't have an up to date zip download, so the only way to get the latest version was to clone the github repository. For some reason they had included generated object files in the repository, so to get the example program it was a multi-GB cloning operation. If it had been in SVN it would have been a few MB total.

Re:Git is much better for large repos

[IanCal]

git clone --depth 1

To add to this, last time I used SVN, it seemed to transfer each file individually which was really slow. Git compresses the files and then transfers everything

easier administration?

[Anonymous Coward]

Git shops typically have many, smaller repositories, while svn shops typically have a single repository, which eases administration, backup, etc.

Eh... I'm not sure backup could be any easier than every developer already (automatically, by design) having the full repository on their own separate machines. I don't know much about modern SVN administration tools, but I'd also be surprised if it's easier than Git, esp. using something like Gitolite, and that's assuming you want to bother with a "central" repository at all.

Both Have Their Purposes

[ideonexus]

I started using Git last year for my personal projects. It's a fantastic platform for coding as a social-network. I love that I can grab code I need from other developers around the world, tweak it, and send it back with a few suggestions. I love that I can follow other projects without having to get involved. Git is awesome.

That being said, we still use SVN for our internal development. The WYSIWYG interface of Tortoise is simply really comprehensive. I realize that Git offers more options, but if those options aren't available with a simple right-click, then I don't have the time for them. Tortoise SVN makes everything readily available, while Git makes me run to the command line too often.

Re:Both Have Their Purposes

[olivier69]

You're confusing git and github...

Re:Both Have Their Purposes

[ameen.ross]

TortoiseGit?

Re:Both Have Their Purposes

[Anonymous Coward]

While not perfect, you might want to take a look at SourceTree, a nice git gui from Atlassian. It's free, it actually looks decent, and does a much better job than the github client of keeping you off the command line. To date, it's my favorite git client.

Re:Both Have Their Purposes

[Anonymous Coward]

I started using Git last year for my personal projects. It's a fantastic platform for coding as a social-network. I love that I can grab code I need from other developers around the world, tweak it, and send it back with a few suggestions. I love that I can follow other projects without having to get involved. Git is awesome.

That being said, we still use SVN for our internal development. The WYSIWYG interface of Tortoise is simply really comprehensive. I realize that Git offers more options, but if those options aren't available with a simple right-click, then I don't have the time for them. Tortoise SVN makes everything readily available, while Git makes me run to the command line too often.

tortoiseGIT. No excuses.

Re:Both Have Their Purposes

[Anonymous Coward]

LOL GP is fail.

Re:Both Have Their Purposes

[ahabswhale]

Do you also like the tree conflicts you get when moving directories around in your project? Those are my favorite thing in SVN. In theory, they've made this better in the new version but I'll believe it when I see it myself. That's something about SVN that just really pisses me off.

Re:Both Have Their Purposes

[Frequency Domain]

For personal use I like Tower, but that's OS X only and costs $. SourceTree, in addition to being free, works on both Windows and OS X so that's what I recommend for my students.

Re:Both Have Their Purposes

[Anonymous Coward]

PROTIP: If you consider mouse menus "simple" and keyboard usage not, then you are not a programmer.

At best, you are an iTard "designer" or Wintard who never got out of the tiny box Windows puts you in.

Seriously: Hand in your geek card right now, and present to the programmer court for execution tomorrow.

Re:Both Have Their Purposes

[Anonymous Coward]

In addition to source tree, several IDEs support git such as XCode, Intellij Idea, Netbeans (with third party plugin), and Eclipse (with plugin).

There are a lot of Gui friendly options for Git these days. It's one of the reasons I went with it over Mercurial.

Re:Both Have Their Purposes

[stsp]

Do you also like the tree conflicts you get when moving directories around in your project? Those are my favorite thing in SVN. In theory, they've made this better in the new version but I'll believe it when I see it myself. That's something about SVN that just really pisses me off.

Tree conflicts are inherent to any version control system, not just Subversion.

People complain about Subversion's tree conflict handling a lot. I believe this is because development work done so far was only about detection of tree conflicts, leaving many users helpless because tree conflicts can be complex and hard to understand and resolve.

The 1.8 release is taking some steps towards the eventual goal of helping users resolve any tree conflicts instead of merely detecting them. If you move a file or directory in Subversion 1.8, and need to update the working copy before committing the rename, and the update receives edits for the renamed file or directory, you'll now see a menu which allows you to apply the incoming changes to the renamed location:

Tree conflict on 'foo.txt'
> local file moved away, incoming file edit upon update
Select: (mc) apply update to move destination, (p) postpone,
(q) quit resolution, (h) help:

This only works for 'svn update', however. It doesn't work for 'svn merge', yet. That's planned for a future release.

Re:Both Have Their Purposes

[gtall]

I use CornerStone for an SVN gui on MacOS, costs about $60. I develop on Linux, and use Eclipse (sigh...) and Subclipse...but only to get stuff in and out. I manage SVN using CornerStone though.

Re:Both Have Their Purposes

[TechyImmigrant]

The solution is not to have a complex tree. Then fixing tree conflicts is easy.

Re:Both Have Their Purposes

[ahabswhale]

It's only an issue for VCSs that don't track transitions. In short, it's a simple design failure. It presumes that such things don't happen, so when they do it craps all over itself. It's really not that complicated of an issue to solve if you actually want to solve it. Sadly, VCSs have tended to ignore the problem. It's really a statement on how barbaric VCSs still are. It's understandable though...there's no money in developing VCSs.

Re:Both Have Their Purposes

[ebno-10db]

That's just working around the limitations of your tool. I use and in many ways I like SVN, but those tree conflicts can drive me nuts. Another problem with SVN is that if you make identical changes to two branches, either in the tree structure (perhaps just deleting a file) or in the source, and you try to merge those branches it complains about conflicts instead of realizing that there is no conflict if the exact same changes were made to both branches. I know you're not supposed to work that way, but sometimes it happens, and it would be nice if the tool dealt with it.

Re:Both Have Their Purposes

[TechyImmigrant]

>That's just working around the limitations of your tool.

It's also working around the limitation of my brain.

Re:Both Have Their Purposes

[Anonymous Coward]

Git Extensions - http://code.google.com/p/gitextensions/

It's awesome. Seriously.

Re:Both Have Their Purposes

[ebno-10db]

It's also working around the limitation of my brain.

If you have a brain, you're in the wrong line of work.

Re:Both Have Their Purposes

[Anonymous Coward]

Thank god for git. Otherwise they would never have gotten around to it.

The biggest advantage for me using git is that I don't need some special repository server running somewhere.
The way svn deals with branches also makes 0 sense to me.
Granted, I've never spent a lot of time with svn.
But 10 minutes of figuring out git was a lot easier for me than 10 minutes of figuring out svn.

Won't use SVN.

[Anonymous Coward]

All SCMs suck, some more than others. I liked CVS despite all its drawbacks. I can't help but dislike SVN despite all its upsides, notably its unbearably smug attitude, and especially its "documentation" drives me up the wall. Git, well, seems to be a reasonably solid bit of software and comes with somewhat usable manpages, despite its treacherous heritage. So we'll use that, reluctantly.

There are a few more alternatives I'd look at before looking at SVN again, in fact. And no apologies for not being sorry about it.

Re:Won't use SVN.

[Anonymous Coward]

And you are complaining about "unbearably smug attitude", with your hipsterish deathgrip on CVS?

Re:Won't use SVN.

[gulikoza]

Exactly. I don't understand however why CVS is so easily forgotten. I still use it on a daily basis.

Sure, I've switched to git for my projects, but CVS is so easy to set up, centralized (it's a plus, when you need that), text files in repository and each file is versioned on it's own (it's a plus, when you need that). One great use I've found is put some software into git, manage patches with stgit, while having each individual patch in a CVS repository for patch history. I wouldn't change that for svn.

Re:Won't use SVN.

[ebno-10db]

All SCMs suck, some more than others. I liked CVS despite all its drawbacks. I can't help but dislike SVN despite all its upsides, notably its unbearably smug attitude, and especially its "documentation" drives me up the wall. Git, well, seems to be a reasonably solid bit of software and comes with somewhat usable manpages, despite its treacherous heritage. So we'll use that, reluctantly.

There are a few more alternatives I'd look at before looking at SVN again, in fact. And no apologies for not being sorry about it.

I'll bite. What's smug about svn? The developers make a version control system that they think is good, but they don't pretend it's The One True VCS. The users on forums, and Mercurial devs/users all likewise. By contrast Git fans, from Linus on down, act like it's the One True VCS and treat anyone who doesn't see the light as only worthy of contempt. I'm considering moving to Git or Mercurial, but I swear it'll be Mercurial just to get away from that friggin' attitude.

Documentation is also one of the strong points of SVN. The online book is fantastic.

Re:Won't use SVN.

[Dog-Cow]

Treacherous heritage?

Re:Won't use SVN.

[ebno-10db]

I don't understand however why CVS is so easily forgotten. I still use it on a daily basis.

It's forgotten only because SVN was intended to be, and is, "CVS done better". It was even created by CVS devs who wanted to start clean to overcome some of CVS's shortcomings, but intentionally and unabashedly looks, feels, and where possible, works like CVS. I've done both CVS (back in the day) and SVN repo setup, and they're both very simple. One reason I chose SVN for some in-house stuff is because the people who already knew CVS could pick it up in a heartbeat.

Re:Won't use SVN.

[Anonymous Coward]

What, having liked CVS makes me a hipster now?

Shoot, now I hafta go upgrade me wardrobe.

Re:Won't use SVN.

[thoth]

I thought he was making a joke on the name of the product: subversion (the act of subverting something, versus the prefix "sub" like a subordinate version). Anyway, I read the comment again and I'm wondering what he meant as well.

Re:Won't use SVN.

[MouseTheLuckyDog]

I have one major problem with SVN but it is a big one.
When creating branches and particularly branches of subprojects, you have to create directories with branch names.
That means that you can only compile the main branch of subprojects unless you modify your build system to take branches into account.

Re:Won't use SVN.

[Anonymous Coward]

As someone who likes to use git, I don't care what others use, as long as it doesn't force me into some difficult situation of manually doing all kinds of things that git automates. (i.e. as long as there is some conversion interface for me to use git with your software, I'm fine.)

Re:Won't use SVN.

[stoploss]

I have one major problem with SVN but it is a big one.
When creating branches and particularly branches of subprojects, you have to create directories with branch names.
That means that you can only compile the main branch of subprojects unless you modify your build system to take branches into account.

Or, you know, you could check out from deeper within the tree. That's something that svn allows that git does not.

So, you setup your svn repo with /trunk/, /branches/, and /tags/, and then your local working copy is just, say, a checkout "svn checkout svn://your.server/svn/yourRepo/branches/foo/ localDevWorkingCopy" which is now rooted in /foo/.

A simple "svn switch" allows you to change over to /trunk/ or /tags/bar2.0 ...

This is similar to the concept of chroot in Linux (et al), but the ability to checkout part of the repo is the reason this can work in svn.

If this doesn't address your issue, then perhaps I misunderstood what you were describing.

Re:Won't use SVN.

[goruka]

It's more like there is a deep hatred against Subversion. I have no idea where does it come from, but if you are old enough you'll remember that there's been a long list of revision control systems that become trendy, with fanboys claiming they were going to "destroy svn".
Arch was first, then Mercurial and now Git. The main difference is that Git became much more popular thanks to the excellent Github, but for enterprise and large projects where a centralized repo works better, SVN or Perforce are still a better solution than any of the distributed ones

time terminology

[Anonymous Coward]

If by "back in the day" you mean "earlier this morning" in regards to CVS? Then yes, I remember, you insensitive clod!

Yes

[Anonymous Coward]

Of course I'll still use git; I don't trust source to databases.

hammer vs. screwdriver

[Anonymous Coward]

My screwdriver is so superior to your hammer! Need proof? Just try to fix a screw with your hammer, duh!
Move on - nothing to see here.

Never seen Git

[Anonymous Coward]

Never seen git. Never cared. Everyone and the dog uses Mercurial here.

Re:Never seen Git

[Anonymous Coward]

Perforce.

Re:Never seen Git

[behrooz0az]

So we live in different caves, because I've never seen mercurial.

Git is auto-backup

[mathimus1863]

For the same reason the summary complains about users having to clone the entire repo, you don't really have to deal with backups: the entire repo is already backed up by every single one of your users. In fact, this is one reason I use git, because I know that I don't have to worry about backing up. I can sync with github, and know that if github disappears, my code history doesn't go with it.

Re:Git is auto-backup

[drinkypoo]

For small repos that's fine, it's a feature. For large repos it's not fine, it's a serious problem. I literally cannot fetch the Android-x86 repo. git won't just finish sending the old stuff if new stuff has appeared since your last attempt to fetch the repo.

This wouldn't be as big a problem if people didn't think that git access was a substitute for a tarball, so that if you just need to build the fucking code you can do so.

Re:Git is auto-backup

[Anonymous Coward]

For small repos that's fine, it's a feature. For large repos it's not fine, it's a serious problem. I literally cannot fetch the Android-x86 repo. git won't just finish sending the old stuff if new stuff has appeared since your last attempt to fetch the repo.

This wouldn't be as big a problem if people didn't think that git access was a substitute for a tarball, so that if you just need to build the fucking code you can do so.

Use 'git clone --depth 1' if you only want the most recent revision. It will allow you to update it from upstream but obviously you won't be able to go back into the history.

Re:Git is auto-backup

[drinkypoo]

Use 'git clone --depth 1' if you only want the most recent revision. It will allow you to update it from upstream but obviously you won't be able to go back into the history.

this is very useful information; thanks. too bad git doesn't do this first, and then fill in the history later. that would make it dramatically more usable for the average human.

Re:Git is auto-backup

[Anonymous Coward]

this is very useful information; thanks. too bad git doesn't do this first, and then fill in the history later. that would make it dramatically more usable for the average human.

Except the "problem" which you're complaining about is a non-issue for the vast majority of git-using humans, let alone average humans.

Re:Git is auto-backup

[Anonymous Coward]

The average human won't be trying to pull down the Android repo...for 99.99% of people the size of repos is not generally a concern they need to worry about...

Re:Git is auto-backup

[drinkypoo]

Except the "problem" which you're complaining about is a non-issue for the vast majority of git-using humans, let alone average humans.

[citation needed]

This might be true if git weren't used in a public-facing context. But it is. I suspect most "users" of git are just people trying to fetch something so they can build it, who don't give a shit about the history.

Re:Git is auto-backup

[Anonymous Coward]

http://www.phoronix.com/scan.php?page=news_item&px=MTMzNTc

Don't be so sure about not needing backups.

Re:Git is auto-backup

[Slashdot Parent]

I've cloned large repositories before. It doesn't take long. Git compresses. Disk space is cheap.

This just seems like a non-problem to me.

bazaar

[pauljlucas]

I've been using bazaar and it's everything subversion is, but better. It's had true renames since I've been using it and it really knows how to merge branches properly (which were the big big problems I've had with subversion).

Re:bazaar

[Anonymous Coward]

I don't write code much these days, but I write a hell of a lot of fiction, and I use bzr and a VPS for versioning and to help me keep it all in sync on multiple devices. Love it.

Re:bazaar

[Anonymous Coward]

hahah your so fucking stupid

Re:bazaar

[Anonymous Coward]

I used bazaar for about a couple of years before switching to git. The main reason being that bazaar (when I used it) would base all of their updates on the latest version of python. Since the clients were on enterprise linux, the users would too often call about an obscure error message telling them to update and when they did bazaar stopped working all together because the updater didn't check to make sure a compatible version of python was available.

Now that python has stabilized, I'm sure that isn't much of a problem now. However the speed improvements given by git makes it very unlikely we would ever give bazaar a second chance.

both actually

[TheCarp]

For personal stuff, or things I intend to share haphazardly or widely, I go git all the way. Git is great for when I need to work disconnected and still keep revisions. Its simple, its fast, its easy to make a quick repo, so quick sometimes I make one for things I wouldn't otherwise, because even if it never gets used again, the overhead of turning a directory into a git repo is trivial.

That said, there are times when i have other requirements. Things that are going to need to be tracked long term, be shared with a defined group in a specific environment, times when even if I leave forever, someone else is going to need to be able to see what I did and maintain it all... for this I use subversion.

For example, lets say I have to muck with apache configs. I can go to /etc/apache and make it a git repo; check everything in as is, then work. Nice and safe and no thinking about whether I will want one repo for all machines with apache that I administer or any of that, its in place, its quick, its low overhead.

Then later, if I find multiple apache instances that i want under control, I can make them all different branches of one repo easily, or... I can wait till I have time to really think about how I want to setup a central repo, and pull everything into that when I am ready, without getting in the way of the changes I need to make right now.

So... both really, depending on both the long and short term requirements and who I need to work with in what mode.

Re:both actually

[WuphonsReach]

You may also want to look at "FSVS" for storing Linux machine configs in SVN. We rely on it heavily and it has some options for doing multiple instances all hanging off a single repo.

Frankly, in 99% of the cases, I just want to know what I changed that borked something, or how I did something 3 years ago and what lines I changed in the config file. So I don't use the multiple machines based off a single repository feature.

I can't even think of enjoying svn ever again...

[Anonymous Coward]

Does SVN still force all my pending changes into one commit? (and one commit message to rule them all?)
Does SVN still force my commits to be immediately visible to everyone else, meaning I can't do commits in smaller steps without risking to expose unfinished and potentially functionality-breaking changes to rest of the team? (essentially meaning I must run with uncommitted change history far longer than would be necessary or comfortable) -- And don't even think of saying "I should just make my own branch then". Branching and merging in SVN is NOT HELPFUL.

I can't in believe that these features wouldn't be a very big boon to everyone doing teamwork, no matter the company structure/size.

Pristine copies

[DrXym]

On the flip side, Subversion stores a pristine copy of every file to avoid a network round trip when doing stuff like diffs. So if you have a 500MB working directory, it's backed by another 500MB worth of pristine copy. A typical Git clone can hold the entire history of the project in less space than that because it is packed down during the clone operation.

But definitely the ability to check out just a few folders or files is an advantage of CVS and Subversion. Git forces everything to be cloned although you can avoid dragging down the entire change history. Submodules are Git's way of decomposing projects into smaller ones and they tend to be hit and miss.

Re:Pristine copies

[Anonymous Coward]

Git also stores a complete copy of every file in the repo, at every revision. Technically. It aggressively compresses and/or deduplicates the data that it stores, however.

It is possible to do a 'sparse checkout' with git; I am sure that SVN has a simpler method. Submodules can indeed be a pain, subtrees are another option.

Re:Pristine copies

[Anonymous Coward]

You clone the repository once. With subversion if you want to check out a different revision you have to connect back and download it all over again but with Git you do not need to do that. Also this checking out folders or files is at best a shot in the dark to find something better than Git. The truth is checking out directories is important if you have one massive subversion repo with every project your company has in it. Git is meant for smaller repos that contain only what its designated for and not like the ASF svn repo with all the different projects in the same repo.

Re:Pristine copies

[DrXym]

I think everyone is aware that CVS and Subversion are centralized and that the pristine copy refers to a snapshot.

But checking out directories is a useful feature and it does no good to deny it. For example the company might use Subversion for documentation storage and someone might only be interested in one folder and Subversion supports that. For documentation and other forms of binary content the whole idea of decentralization is highly questionable since its not like merge tools will make a good job of a spreadsheet or a diagram or even a word doc so the whole staging, pushing and pulling is largely redundant overhead.

For source code or text content it is another matter and Git is clearly a better choice in most scenarios.

SVN sucks on windows

[Jerry Atrick]

SVN is great until it subtly (or no so) corrupts either the db or your working copy. Which on Windows happens a lot because every damn SVN client has enough bugs you need to use multiple tools to get work done. Then use extreme care to stop the buggy POS clients from interacting destructively.

And once it's buggered you have an undecipherable pile of bits. RCS just worked but didn't do much, CVS did more and just worked most of the time. Both were trivially repairable when disaster struck. There are days I miss RCS badly.

Re:SVN sucks on windows

[Matje]

Care to point to specific bugs? We've been using SVN for years and never seen these problems.

Moreover, since SVN is client-server, why would a buggy client cause datacorruption in the database? Are you implying there are major bugs in the svn server?

without backup, your claims are just FUD...

Re:SVN sucks on windows

[ebno-10db]

I've been using/administering svn for about 10 years now, usually w/ a Linux server and Windows clients. I've never had that happen. I'm sure your experience is different, but I've no idea why. I never even had problems with some of the older svn upgrades that automagically upgraded the repository (I faithfully did backups before hand, but never had to use them).

Re:SVN sucks on windows

[Anonymous Coward]

SVN:

* no way to ignore files easily
* no way to branch easily
* mixed-revisions, it's a nightmare

Re:SVN sucks on windows

[ebno-10db]

SVN:

* no way to ignore files easily * no way to branch easily * mixed-revisions, it's a nightmare

Which is completely OT. This thread is about repository corruption. It's typical of the knee-jerk response I see to any talk of anything other than Git though.

Re:SVN sucks on windows

[Anonymous Coward]

I've had trouble with Subversion on Windows, but it was always problems with Windows, like deciding not to start the SVN server, or corrupting the SVN server configuration (or something that caused it not to start or be startable). Always worked on Linux.

Re:SVN sucks on windows

[Tailhook]

Care to point to specific bugs? We've been using SVN for years and never seen these problems.

I've had the same experience. Yet a cow-orker next to me constantly has serious problems with SVN.

They're just reckless. They damage the metadata in their working copies, forget to svn add|move or whatever, do merges wrong and then blame subversion when all that accumulated damage bites them in the ass.

Re:SVN sucks on windows

[Anonymous Coward]

That guy's misuse of SVN is a concern, but far more disturbing is the fact that he seems to be orking cows in the workplace.

Re:SVN sucks on windows

[Anonymous Coward]

I can't speak to corrupting the db but I can say that I've definitely had a few issues with SVN myself. One is with a particular subfolder in a checkout getting corrupted (cannot commit, cannot update and cannot resolve the conflict) and having to delete the entire checkout, which was a few gigs, to fix the single subfolder because removing the folder and updating didn't fix it. Another issue I have is with merging. If i create a branch and add a new file in that new branch, I can never merge that branch again. Vice versa if I created the file in the existing branch. It just fails on tree conflicts. It's miserable and I've spent a lot of time trying to find ways around it. For the amount of files I need to merge daily, I've dedicated a lot of time to learning Git to replace my system. Although it's such a different paradigm I'm left with a lot of other workflow issues to resolve.

Re:SVN sucks on windows

[TemporalBeing]

SVN:

* no way to ignore files easily

See SVN properties - svn:ignore.

* no way to branch easily

See SVN copy - you can do URL to URL, or Working Copy to URL.
Also see SVN switch to change a working copy from one URL to another.

* mixed-revisions, it's a nightmare

Really? Every VCS has Mixed Revisions. Git even more so with its staging area - so you have 2 changesets and therefor two sets of mixed revisions. For SVN, just run Update on the root of the working copy, then commit and voila it's back to a single revision.

Re:SVN sucks on windows

[TemporalBeing]

I've been using/administering svn for about 10 years now, usually w/ a Linux server and Windows clients. I've never had that happen. I'm sure your experience is different, but I've no idea why. I never even had problems with some of the older svn upgrades that automagically upgraded the repository (I faithfully did backups before hand, but never had to use them).

When I first started using SVN back in 2004 there was a lot of talk about repositories being "wedged", which I think was mostly related to the BDB backend that was primarily used at the time (and now with 1.8 deprecated); but I don't think I've ever actually had it happen to me in all that time - using it from 1.2 through 1.7.

Yes, I've screwed up a few working copies, but nothing server side, and nothing that wasn't recoverable.

Re:SVN sucks on windows

[SerpentMage]

eh? Really? I do everything you are saying quite easily. Then again I moved beyond the command line and use GUI tools such Cornerstone, which is AWESOME!

Re:SVN sucks on windows

[Anonymous Coward]

I have had local corruptions (about 1 a year). Usually I see them if you do not let a check out finish for some reason. All I do usually is a the occasional branch/merge/update/commit. Yet somehow my metadata gets corrupt once and awhile. Once it is corrupt dont bother trying to fix it. Just blow it away and check it all out again and start over and use an external merge tool to find the diffs then commit again.

Personally I liked the way sourcesafe worked. Too bad it would corrupt your work if you looked at it funny.

Re:SVN sucks on windows

[Anonymous Coward]

Which on Windows happens a lot because every damn SVN client has enough bugs (...)

Don't use MS Windows for an svn server then. In fact, better not use it for anything that you want to keep uncorrupted for many years like your company's source repository.
I've seen an obscure svn bug caused by MS Windows refusing to check out a SVN repository that contained a directory named "con", because in the MS-DOS filesystem this was a reserved keyword (COPY CON: file). It took ages to find. Maybe MS Windows is more professional these days, I wouldn't know, but.. you have been warned.

In short: MS Windows = CON:

Re:SVN sucks on windows

[Anonymous Coward]

was the subfolder called "con"?

see here: http://en.wikipedia.org/wiki/DOS#Reserved_device_names
(WTF!)

fritsd

Re:SVN sucks on windows

[chrismcb]

Which on Windows happens a lot because every damn SVN client has enough bugs you need to use multiple tools to get work done.

My company has used SVN for the last 5 years, and I've used it personally a tad longer, on windows. Never had a DB corruption, nor heard of anyone having one. While I don't NEED to use multiple tools, I do sometimes, mainly for ease of use. Sometimes the GUI is better, sometimes just using the CLI is better.

BerkeleyDB

[Anonymous Coward]

Every project I have ever heard of ends up dumping BerkeleyDB. Apparently, it's a giant tar pit.

Re:BerkeleyDB

[DrVxD]

Mostly because many of those projects weren't using Berkely for what it was intended for, but had no better solution for their use case - these days, there are several alternatives (SQLite being one of the more popular examples)

Decent comparison

[ameen.ross]

I'll just leave this here so people get to see a comparison that's actually useful.

https://git.wiki.kernel.org/index.php/GitSvnComparison

Re:Decent comparison

[atom1c]

Yeah, that comparison is garbage.

A negative for Git is your obligation to clone the entire repository; however, a positive for Git is your obligation to clone the entire repository so they are treated as a full repository backup. So, it's bad... but let's try to do some PR spin to make it appear good... in the same bloody list.

Git is much faster than Subversion

Really? What a baseless statement. No benchmarks whatsoever!

I would go on, but the list is such garbage that nobody should make reference to it ever again.

Re:Decent comparison

[Just Some Guy]

Git is much faster than Subversion

Really? What a baseless statement. No benchmarks whatsoever!

So you haven't actually used both of them. Got it. I used and advocated SVN for a long time - to the point that my Git-using friends were teasing me about "legacy systems" and all that. I finally caved in one weekend and tried Git, and after about an hour started converting all my personal repos over to use it. It was so much faster (and so much better at merging) that I never looked back after that day.

Git is faster than SVN. Also, steel is stronger than bubblegum and the Space Shuttle is faster than a Cessna. I don't feel the need to run benchmarks or quote figures to "prove" any of those statements.

Re:Decent comparison

[atom1c]

A fresh install (minus bloatware) of anything is typically faster than a bloated version of whatever it is replacing.

With the entire repo already cloned locally with local API hooks, any Git operations better not be impacted by network latency or experience bandwidth issues. If you ran the SVN repos locally and leveraged local hooks (read: w/o Apache + mod_svn + mod_ssl + ldap_authz) then it, too, would operate with lightning speed. It's all relative... and, yeah, obvious.

Also, merging local clones up to a parent repo with Git may experience fewer conflicts, but I don't believe other folks cloning the same parent repo would have the same clone history and binary assets as your own (plus their own) as to exhibit a comprehensive system-wide history of activity. This means the argument for DVCS is simply putting more emphasis on local working copies in exchange for... nothing.

Re:Decent comparison

[verbatim]

The statement is also demonstrably untrue.

You can create a shallow clone of a git repository. There are some limitations, but if you're just interested in the latest and greatest, and are fine with some non-obvious restrictions, you are not obligated to download the entire repository.

Re:Decent comparison

[ameen.ross]

A negative for Git is your obligation to clone the entire repository; however, a positive for Git is your obligation to clone the entire repository so they are treated as a full repository backup. So, it's bad... but let's try to do some PR spin to make it appear good... in the same bloody list.

Well waddayaknow! Who could have thought that different approaches to the same problem can have both advantages and disadvantages? I've always thought there was a holy grail for everything!

Git is much faster than Subversion

Really? What a baseless statement.

Presumably GIT will be faster when the repositories it produces are 30 times smaller than their SVN equivalent. Even when leaving networking out of the equation. I do agree a benchmark would be beneficial to the comparison, but implying that GIT is not faster than SVN, simply because a cute chart is missing, is stretching it.

I would go on,

Please, do go on enlightening us.

but the list is such garbage that nobody should make reference to it ever again.

First off, right there at the top of that page it says it's a work in progress, so naturally there will be issues with it. But it's a stretch to say that the list is garbage. I'd be most interested to see a better alternative if you know one though.

Re:Decent comparison

[atom1c]

Who could have thought that different approaches to the same problem can have both advantages and disadvantages?

The perceived quality of a list is dramatically improved when there are no contradictory interpretations of the same facts. Here's an example of a really retarded way of making both positive AND negative spins off the same underlying fact.

5 FACTS ABOUT ME
"I can" -- Yay, there's a can-do attitude and one of positive ability.
"I can speak" -- Boo, I'd rather you write instead of speak... I don't want to be bothered by too many voices.
"I can speak English" -- Yay, I understand English, too. If you're gonna speak, at least it should be in a language I understand.
"I can speak English badly" -- Boo, that sucks. I won't fully understand what you say when you do speak.
"I can speak English badly sometimes." -- Well, duh. I don't need any evidence, anecdotal or otherwise. I'll just blindly believe that your occasional inability to speak English properly is indeed this "sometimes" occurrence rate.

See? Spinning the same underlying fact to generate both separate advantages and disadvantages is silly and significantly dilutes the quality of this 5 Facts list. The same underlying principle applies to the Git-to-SVN Comparison: there's 1 underlying fact, but it is spun into numerous line-items for the sole purpose of stacking the cards in a thinly-veiled attempt at objectivity. In other words, garbage.

Perforce

[Anonymous Coward]

All you need, and its FREE for small usage..

But Will You Still Use Git?

[cjjjer]

Pretty arrogant of the poster to think that everybody uses Git.

But then of the small sample of developers that I have interacted with on the topic of source control and use Git the majority are Git-Nazis and they are waaaay worse than the TFS-Nazis.

Re:But Will You Still Use Git?

[Anonymous Coward]

But TFS-nazis aren't as bad as RTFA-nazis, so I still don't know where that puts Git-nazis.

Re:But Will You Still Use Git?

[Anonymous Coward]

But some of us are still stuck on VSS.

Re:But Will You Still Use Git?

[Anonymous Coward]

I use git for deploying web applications, since site configuration and customizations can be checked into the local repository. Cool customizations can be cherry-picked up the tree back to the main application code.

Re:But Will You Still Use Git?

[Anonymous Coward]

TFS-Nazis

The Fucking Summary-Nazis?

Speaking another language

[Anonymous Coward]

Every time someone starts talking about version control systems I zone out.

Game programmers who need Art!

[Anonymous Coward]

I worked in game programming several years back, and 1TB was quite reasonable. Branching meant IT would bring everyone a new hard drive to store the new branch on.

IIRC the client for one of the MMOs I worked on was a 20 gig download. The source code that actually went into that... was big, but couldn't possibly have been a gig of raw text before being compiled; the art on the other hand, was sliced, diced, squeezed and compressed to get it down into that small of a download. Art Is Huge. Especially art in the raw forms -- even if the final game art is going to be some horribly compressed format to save space, artists want to record the initial sound files in pristine high bitrate forms, and want to do the initial drawings in zillion-pixel-wide, maximum-color-depth formats, and then compress later. The intro-video that nobody watches alone probably took up more space in the repo than all of our source code files, because it was rendered for impossibly good monitors. So, in our repo, we have both the compressed MP3-low-bitrate voiceovers that go into the game, and also the uncompressed-perfect-form from the recording sessions (just in case we want to recompress to MP3 later so we can have a higher bitrate... or maybe we'll swap to using ogg next year... or just for historical interest? it's a repo, you check stuff in...) And similarly for the textures -- the original photoshop files at maximum size and color depth are gorgeous... and then there's the smooshed version you get on your computer. But we have to store the maxumum size one, because that's the one that we're going to edit if we make a change! And it's version-control, so the repo has this hard-to-compress binary (trust me, photoshop files don't compress nearly as well as python files), possibly in a dozen different versions because all of your art got reviewed and edited as it passed through various layers of management and licencees... And then of course there's video too -- cutscenes and intro video and such.

There's no chance that you could get a repo like that to work on git. We used perforce rather than svn; perforce is (or at least was at the time) the popular tool in the gaming industry for source control (it's expensive, but stable and has good support for massive repos), but I can see lower budget places going for svn. Git just isn't designed for huge repos full of binary blobs.

Re:Game programmers who need Art!

[VortexCortex]

I worked in game programming several years back, and 1TB was quite reasonable. Branching meant IT would bring everyone a new hard drive to store the new branch on.

Meanwhile branching it with git would mean no new hard drive needed. In fact I branch and merge every day with git, that's how I start my work and "save" my progress instead of piling up a huge set of changes and making merges a nightmare.

FTA: '"With Subversion, you can have a 1T repository and check out just a small portion of it, The developers don't need full copies," Stein explained.

If you have 1TB git repo that you can't check out only a portion of then you don't know how to use Git submodules. It's moronic to criticize Git if you don't know how to use it. Further, with symbolic links to the submodules I can have many repository clones target a single sub repository (or vendor branch in SVN speak), and Git gives me the capability to relocate repository locations on either end -- clone or remote.

Git just isn't designed for huge repos full of binary blobs.

I agree with this. The assets are not the engine. You don't need to save every little change to every single asset. I've actually been working on an editing tool suite that uses the diff / patch method of content storage, only performing things like image and audio compression as part of an export process for building the game asset collection. Perforce isn't optimal. We haven't done for assets what we have done for code with revision control. Text is cheap, and never deleting it is acceptable, but with assets we need the ability to Archive and Rebase an asset such that future changes can not be made to past versions -- Limit the window of changes such that merging is still possible, ie, changing an effect at the front of a video or pixels on one side of a texuremap can be merged with changes to the end credits of the video or changes on the other side of a texture map. Things like hue or contrast adjustments can even be encoded if the asset repository management system knows how to do these things. Instead of recording full snapshots of an image you can store a base image and the history of edits to that image to produce the current asset. This way the undo facility can be used when you open an image or video or model. Folks can revise color corrections or insert edits in the asset history, once the asset is at an approved status the base asset can be archived, the history can be collapsed (rebased), and any new edits will create new histories (edits). So much to do, so little time -- Wish I could git clone myself.

In short: Perforce is still dumb about assets -- It's not even as advanced as CVS is when it comes to code. The future will be more like Git -- especially as drive space outpaces asset storage requirements (the same way magnetic tapes outpaced text storage requirements).

Git not good for big assets

[alexp700]

We work on lots of asset rich projects - often the PSDs folder will span many (hundreds!) gigabytes for a small project, and we'll be working on multiple projects at once. The PSDs then often have source imagery and a whole load of clutter collected from clients. SVN is superb at dealing with this scenario, since as a coder I don't fill my machine with sources I don't need - but we need them archived and backed up none the less. This is especially a problem if you're a developer with a fancy small SSD and the guy across the room has 6TB at his disposal for videos ;-)!

Re:Git not good for big assets

[Anonymous Coward]

You might want to take a look at git-annex. It lets you manage large files, and also use backends like S3 for storage.

Open Source

[Anonymous Coward]

Generally speaking, new versions aren't for the attracting of new users, but for the pleasure of existing users (since they are the ones writing the code...).

Hit me baby one more time

[Impy the Impiuos Imp]

We use Microsoft VSS. No, don't hit me!

I get punched in the face several times a day already.

Re:Hit me baby one more time

[DrVxD]

You have my deepest sympathy - for using VSS, at least.

On the other hand, I have no way of knowing if you deserve to get punched in the face several times a day...

Misleading summary

[stsp]

I'm a Subversion developer and would like to clarify this bit of the summary:

Major new features of 1.8 include switching to a new metadata storage engine by default instead of using Berkeley DB, first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name) which will make merges involving renamed files saner, and a slightly simplified branch merging interface.

The "new metadata storage engine" probably refers to FSFS which has been the default repository backend since Subversion 1.2. FSFS has been improved since then, and 1.8 contains some new improvements (such as directory deltification) but does not add a new repository backend. The BDB-based backend is the one from Subversion 1.0 and is rarely used these days.

Subversion 1.8 doesn't contain support for "first-class renames". Renames are still modeled as copy+delete, with special annotations. The working copy is so far the only part of the system which is aware of moves. There are plans to make other subsystems aware of moves in future releases. Also, while tree-conflicts involving local moves can now be auto-resolved after 'svn update', 'svn merge' mostly behaves as it did in 1.7, expect there is no need to use the --reintegrate option and tree conflicts are now flagged if a directory was renamed or deleted on the merge source branch. Whereas Subversion 1.7 would unconditionally perform the deletion in the merge target.

Does svn already support "pager" , or adding "| le

[ctype_007]

Does svn already support "pager" , or adding "| less" after each command is required ? what about "git citool" ? "stash" ? "amend" ? "rebase" ? Personally I prefer native git or "git-svn" in case of svn reps

You miss the POINT! It's not about speed!

[Anonymous Coward]

It's not even a contest!

git is truly decentralized and doesn't have the nonsensical concept of a central "authority". It is build for *humans*. Not for drones serving a master. Humans have webs of trust. And git fits into those. Subversion & co is made for undividuals. Creatures that resemble humans, but have no free will and are actually limbs of a bigger body, controlled by their master / opinion maker.

Re:You miss the POINT! It's not about speed!

[osu-neko]

Spoken like a true brainwashed robot, parroting your propaganda. Meanwhile, real people capable of thinking for themselves understand the concept of using different tools in different situations, and know that sometimes it's better to be centralized, and sometimes better to be decentralized. Both bits of software are made for people trying to solve similar problems, but with different nuances.

Re:You miss the POINT! It's not about speed!

[Kagetsuki]

But you can use a git repo as a central authority just as easily as SVN. In fact that's how most projects are managed. In the case of git however you are not restricted specifically to this. So honestly I can't really think of a situation where the centralized-only architecture of SVN is actually superior.

As someone who kept SVN repos until git came to town I can tell you I've had the centralized SVN repos implode on me before. After the central repos turned into garbage the only real solution was to try and figure out who had the latest code and create new repos from that. That risk alone makes the centralized architecture completely inferior and intolerable to me.

Git Extensions

[Anonymous Coward]

http://code.google.com/p/gitextensions/

Windows only, but all those power Git options become easily viable, including Interactive Rebase and Bisect.

clearcase

[Anonymous Coward]

CC FTW :)

I dont remember much from my cvs days, but having used clearcase for the past 10 years and seeing what git does, I couldnt imagine not using a VCS that does have all the features CC does when you have to manage multiple parts of an overall large project that all combine together in a single build and all across multiple sites over the world.

Re:clearcase

[TechyImmigrant]

I choose not to dig up the memories of using Clearcase. It was the most unreliable, crashy, godawful VCS I've ever used.

Re:clearcase

[Anonymous Coward]

Having used ClearCase myself, all I can say is that it's been more than 5 years and the scars still haven't healed.
There are good features in there, but there are more soul-sucking monstrosities than good features.

Then there's the price (oh god! the price!) and the performance which can only be measured on geological timescales...

Too little, too late

[OrangeTide]

first-class renames (instead of the CVS-era holdover of deleting and recreating with a new name)

Has SVN missed the boat? Basic features that were desirable 10 years ago lead people to use BitKeeper, arch/arX/tla/Bazaar, and eventually Hg, monotone and Git. (I guess some folks were using Darcs too). Now that people have tackled the learning curve and the lack of tools. These days many of these alternatives to CVS and SVN have support in numerous IDEs and desktop environments

It is probably great news for people still using SVN. But why should we keep going in that direction? I also wonder why Perforce is still around too, I still don't find it easy to deal with at work.

and there are 5000 reasons not to use ClearCase

[OrangeTide]

User License: USD $5,180.00

Re:and there are 5000 reasons not to use ClearCase

[Anonymous Coward]

More like 5180 reasons :)

Perforce is free for small-enough user bases

[GodfatherofSoul]

It's enterprise software and we were actually informed by Perforce after maybe 10 years on a license that since our user base is so small we can use it for free. I think the cutoff is based on the number of licenses per server. I've never needed my own personal SCM, but I'd go w/ Perforce if I never needed one.

backwards bugfix

[Chirs]

If you find a bug on a release, you fix it on the trunk, test it on the trunk for a while, then merge it out onto the (supposedly stable) release.

That way if it turns out the fix is bad, you haven't messed up the release more than it already is.

Re:backwards bugfix

[21mhz]

If you find a bug on a release, you fix it on the trunk, test it on the trunk for a while, then merge it out onto the (supposedly stable) release.

This is one of the few things where git's way of revision management actually gets in the way.
You can't simply merge the trunk onto the release branch, because the trunk has all sorts of in-development changes that you don't necessarily want applied to the stable branch. You either have to cherry-pick the fix off the trunk, thus multiplying it in the history. Or, more cleanly IMHO, you base the bugfix branch off the stable branch, and merge it into trunk (all earlier changes reachable from the stable branch should already be reachable from trunk, so you should not get unwanted changes piggybacked this way). After you are happy with how it works in trunk, you can also land the bugfix onto the stable branch (sans the master merge commit), test it there, and release.

SVN is better if you don't know Git

[Tenebrousedge]

I worked in game programming several years back, and 1TB was quite reasonable. Branching meant IT would bring everyone a new hard drive to store the new branch on.

Git just isn't designed for huge repos full of binary blobs.

Apparently neither is Perforce/SVN. More to the point, I am aware of no sound basis for that statement. Git does binary diffs just fine, and compresses the data when reasonable, and stores file deltas where that is more efficient. Cherry-picking a change to a binary file sounds painful, but it's likely that's a stupid idea that would not be tenable in any RCS. If there is some secret limitation to how git stores files, I'd love to hear about it. My suspicion is that this "svn is better for large repos" idea is being promoted by people who have either not used git at all, or do not understand how it works internally.

Re:SVN is better if you don't know Git

[Anonymous Coward]

Git definitely has issues with large files. If it didn't, git annex would never have been written: http://git-annex.branchable.com/

I don't know if newer versions have sorted it out, but git used to load blobs entirely into memory. If a blob is larger than memory, performance suffers. Also, every clone has to have all versions of the file, though they may be delta compressed in the pack file. If you only are interested in one or two versions, storing all of them is just a waste of space. Computing the SHA1 of large files can also take a long time.

Re:SVN is better if you don't know Git

[ebno-10db]

I am aware of no sound basis for that statement.

But have you ever tried what the PP was talking about? There are lots of things that should work, but you can't be sure until you've tried it. He was talking about a 1TB repository, and large binaries often don't compress or diff well (no matter how good your diff engine), so how big would your local Git repository be?

BTW, what he says about Perforce being a good choice for large binaries is something I've heard from a number of knowledgeable people. They all agree Perforce is much better for that than SVN. I don't know about Git, but I wouldn't act confident about it unless you've used it that way.

Re:SVN is better if you don't know Git

[Anonymous Coward]

Git does binary diffs just fine [...] If there is some secret limitation to how git stores files, I'd love to hear about it.

In my experience using Git to store large binary blobs is possible but not optimal.

For example, every time you do a 'git add', you're (simplifying a bit) doing an md5sum on the binary blob. For a large file, that's very time-consuming. And if you have *lots* of files? It's a productivity killer. On top of that, your .git repository is locked at the start of the 'git add', so you can't do the git-add operations in parallel. If you want to do that, you need to write a script to go a git-hash-object -- because that doesn't lock the repository, and then do a git-add.

Git also stores the metadata about a blob (git blob, not binary blob) inside the blob itself, rather than in a sidecar file. This means that once you do an add, you're not storing a file that contains just your binary data, but you're storing a file that contains a bunch of git metadata plus your binary data, with the consequence that checkouts are also more involved than necessary, because the file isn't just copied straight out. And that's another thing -- writing those big files during checkout, applying patches and file deltas? Ugh. Yeah, that's not fast, either.

If your large binary blobs change frequently, but you're not the producer of those files (i.e. you only consume the latest versions of them), then you get all that history stored on your local drive -- there's no facility for just getting, say... the latest versions of a portion of your repository, like you can with SVN, and only having those HEAD versions locally. Sure, there's git-clone --depth, but that comes with a whole bunch of limitations, so I can't make the trade-off between space, and taking a time hit only when I need to go back to pull older versions off the server (a-la svn).

My suspicion is that this "svn is better for large repos" idea is being promoted by people who have either not used git at all, or do not understand how it works internally

My suspicion is that you've never actually tried to use a large git repo full of binary blobs. I spent 8 months under contract for a company, trying to figure out how they could integrate git into a workflow that uses significant quantities of binary data that needed version control. Even a small git repo full of binary blobs was sufficient to demonstrate some of the scalability issues. Would svn have been better? In many ways, yes, but in many other ways, no. Neither was really optimal, but git, at least, was easier to customize. To make git useful for their workflow, I made modifications to git's plumbing, and added new porcelain. In the end, the project was migrated to mercurial, largely because it integrated better into their existing tools, many of which have embedded python interpreters.

Re:SVN is better if you don't know Git

[Bacon Bits]

It's not that git doesn't store files efficiently or is somehow worse at binary diffs than svn. It's that svn allows you to extract a single folder of the source tree, while git requires you to clone the whole repos. If the repos is 1TB of data due to raw media assets, then even if I want to work on plain text C source files I have to clone the whole damn thing with git. With svn, I can just checkout the directory that has the C source files in it. If git means I have to have 1TB of disk space but svn means I can get away with 10MB, then svn is far more flexible with massive repositories which generally implies binary blobs.

Re:SVN is better if you don't know Git

[Anonymous Coward]

Linus himself says so in his Google talk.
http://www.youtube.com/watch?v=4XpnKHJAok8

git is awesome

[Chirs]

especially compared with clearcase....at least from a developer point of view

.svn

[devent]

Have Subversion still those horrible .svn in every single sub-directory?

You know, with Git I can just move/copy the .git directory and have the whole repository.
You know I can just do:
cd /my/usb/stick
git clone file://my/repository
And have all my files.

PS: looks like they try to make svn more like git. The only real problem with git is submodules, but anything else you can do with git. The argument that with git you have more smaller projects, is actually a good thing. Never heart before that modularity is bad. But since your users running away from you, you have to make some arguments*.

* http://ianskerrett.wordpress.com/2013/06/12/eclipse-community-survey-results-for-2013/

The adoption of Git as a developers primary source code management system continues to move forward and at the expense of Subversion. Interestingly, Subversion continues to be the #1 SCM but just barely. If you combine Git and GitHub usage, Subversion leads by only 1.5% points. Next year I am sure Git and GitHub will be #1.

From the survey: Git (+Github) 36%, Svn 38%

Re:.svn

[azav]

With SVN, you can also just copy the directory and it works just fine. Why do you have problems with this? Is something you're doing explicitly ignoring the invisible files on a copy?

Re:.svn

[devent]

Well, of course you can just copy everything.
But you can't just get the repository with Svn, because the repository is divided in those idiotic .svn directories that must be in every thing sub-directory. If you just want the repository you need to download it from the server.

With Git you have your whole repository local on your hard disk containing in one single directory: .git.
I really don't understand who came up with the brilliant idea to pollute everything with the .svn directories.

Re:.svn

[Slashdot Parent]

Have Subversion still those horrible .svn in every single sub-directory?

No. Now, there is now only a single .svn directory, located in the root of your working copy.

Git is fine for independent devs or small OSS.

[aristotle-dude]

Use the best tool for the job. SVN is great for use with continuous integration when using an agile test driven development process. I use git locally on my laptop for versioning of my code so that I can revert changes of my personal projects at home. SVN on something similar is what you should use if you need to have a history that will stand up to audits. Sorry but rebasing does not sound like something you want in a SOX compliant environment. You must have traceability and audit friendly logs of every change made. That include merges between trunk and branch or branch back to trunk.

I would never use something like GIT for enterprise development.

Re:Git is fine for independent devs or small OSS.

[aflag]

Small OSS like linux, GHC and more? What are independent devs? Rebases are done in local repositories to make the changes cleares. If everyone uses it properly the history is actually a LOT easier to audit. You can use software like gerrit to help enforce such things. SVN is worse than git in every sphere. I can't think of a good reason to use it instead of git. If you want to checkout only parts of it, there's git submodules. If you want to add large binary files to your repository, maybe you want to use git-annex. The only reason svn is still used is due to legacy. Migrating to a new VCS may be very expensive.

Re:Git is fine for independent devs or small OSS.

[aristotle-dude]

Small OSS like linux, GHC and more? What are independent devs? Rebases are done in local repositories to make the changes cleares. If everyone uses it properly the history is actually a LOT easier to audit. You can use software like gerrit to help enforce such things. SVN is worse than git in every sphere. I can't think of a good reason to use it instead of git. If you want to checkout only parts of it, there's git submodules. If you want to add large binary files to your repository, maybe you want to use git-annex. The only reason svn is still used is due to legacy. Migrating to a new VCS may be very expensive.

Independent devs would be someone working on an iOS project on their own time with their local machine or the sole developer on a project on github. Git is fine to be used for local versioning not attached to a repo. It integrates well with Xcode and Xamarin Studio. Since I have no intention of "open sourcing" my code, I keep in on my machine locally for the moment.

From your reply, I get the impression that you believe that all of the code that you write is "yours". If you are working for a company, the code is "theirs" which is why it is safer to have a central repository rather than distributed ones. It is an asset of the company and as such, it should be controlled centrally and all builds should be automated. We obviously work in different types of environments. Git would never work in my company.

I still have no idea

[azav]

why git is any better than SVN.

Distributed SCCSes are a really bad idea when one member of your team decides to not play nice with the rest of the team.

Re:I still have no idea

[21mhz]

when one member of your team decides to not play nice with the rest of the team.

If this is the case, you have bigger problems than a possibly poor choice of an SCCS.

With git, it's actually much harder for an asshole to wreak havoc, as the entire project history is cloned between all developers' machines and is cryptographically protected from being altered in ways that are hard to notice.

Re:I still have no idea

[Anonymous Coward]

Distributed SCCSes are a really bad idea when one member of your team decides to not play nice with the rest of the team.

Why would you use SCCS?

Google Trends tells the tale (tldr: svn is dying)

[tutufan]

If you've been around long enough to see a few technologies die off, you'll recognize the hell out of this chart: http://www.google.com/trends/explore?q=git%2Csvn#cat=0-5&q=git%2C%20svn&cmpt=q As for me, svn is one of the few version control systems that actually managed to lose my work (VSS is the other), so I won't miss it. That said, I would pick Subversion over Perforce every day of the week...

SVN? Never again!

[Kagetsuki]

After strugling with SVN and having several repos implode on me before git came around I can honestly say I will not be going back to SVN. Also the fact SVN can't self-host repositories and that you can't just interact between repos on hosts as they are totally shuts it down compared to git.

Also I could care less about speed. If git were taking an hour to deal with repos then maybe - but it doesn't. The biggest bottleneck ever has been bogged down github for a slow connection - git itself doesn't have any real speed issues for me.

*bonus: can SVN handle utf8 properly now? I remember that being a nightmare at one point. git handles it out of box flawlessly and always has.

Mercurial is underrated

[Chris Newton]

What about Mercurial? [...] I'm considering switching from Subversion to something else for my team at work, but the Git UI is awful. I've heard Mercurial is better, including its GUI integration (e.g. Tortoise).

In UI terms, there are respectable GUIs available for both Mercurial and Git these days. I’d say the biggest difference is in the CLI interaction, because the usability of Git is poor even in its native habitat on Linux, and on Windows you're basically stuck with Git Bash, which is a rather glitchy emulation of a Linux shell that IMHO is very irritating to use. Hg is much simpler and less cluttered.

In terms of functionality and the underlying models for how the system works, I’d say there are a few major differences between the Git and Mercurial workflows that you're likely to come across almost immediately. Some are “real” differences. Others look like differences when you first learn the tools, but they’re only consequences of how each tool works by default and you can work the other way if you prefer.

The first is that Git by default does a two-stage commit: you identify the changes you want to commit from your working copy using git add, and then you actually commit them to your local repository with git commit. In Mercurial, the default is commit everything with a single command. However, this is one of those illusory differences, because both systems have alternative commands/options that let you work the other way if you prefer.

The second is that Git and Mercurial (in)famously have different mechanisms for using branches, and here there really are meaningful differences in the underlying model for how things are stored and what you can do. Personally, I intensely dislike Git’s approach where you “forget” which branches things originally happened on or even what those branches were called, because I find the information it discards valuable. However, you’ll have no trouble finding a Git fan to tell you I’m just being silly and obviously the branches-as-moving-tags approach taken by Git is better for other reasons. In this case, there are tools built into Hg these days that basically work the same way as Git’s branches if that suits you, but I’ve yet to find any satisfactory way of getting Git to support history tracking including branches the way Hg does.

Finally, on the subject of rewriting history, in Hg changes are basically permanent once committed, while in Git history is mutable by design using the rebase commands. Again, which is better for you will depend on your own workflow and personal preferences. In theory Git’s view is more flexible, but it’s also one of those issues where it’s a rite of passage to write a blog post about how not to screw up all your colleagues’ repos by rebasing something that was already pushed out to others, so use with care. Hg’s version is less amenable to certain workflows, but it’s also safer.

Finally, I just wanted to mention that whatever anyone tells you about how it’s obviously user error, both Git and Hg have had actual, verifiable, reproducible data loss bugs, even in the past few months. I haven’t checked very recently whether any of the ones I knew about are still unfixed, but definitely make sure you’ve got the latest versions of everything. (And if you’re using Hg, be really careful about cloning a repo on a network server directly and in particular whether you’re getting a truly independent clone or just an improperly-linked version of the original that will corrupt both over time. And if you’re using Git with an external diff tool like Araxis Merge, beware that using a git difftool --dir-diff has been doing funny things when you quit the diff tool and may overwrite any changes you made in your working directory while the tool was open.)

Re:I can't even think of enjoying svn ever again..

[DrVxD]

Does SVN still force all my pending changes into one commit? (and one commit message to rule them all?)

For what it's worth, SVN has never done this - you can specify which files to commit in a given changeset.

Does SVN still force my commits to be immediately visible to everyone else

Not if you don't want it to. You can configure access control such that everyone has their own private branches on the server.

(but despite the fact that neither of these are valid complaints, git is still a much better tool that svn IMO).

Not really a useful comparison

[Anonymous Coward]

This article is not a good comparison IMHO. It was obviously written from the perspective of someone who is a huge Git fan.

> Git is much faster than Subversion
After years of working with both Git and SVN, I have thought about speed of checkout maybe 0 times.

> Subversion allows you to check out just a subtree of a repository; Git requires you to clone the entire repository (including history) and create a working copy that mirrors at least a subset of the items under version control.
This can be very problematic on large repro's, since it requires a lot more disk space and time.

> Git's repositories are much smaller than Subversions (for the Mozilla project, 30x smaller)
Depends on the repo content.

> Git was designed to be fully distributed from the start, allowing each developer to have full local control
Does anyone really require distributed? Its has advantages or a single, but it also has disadvantages.

> Git branches are simpler and less resource heavy than Subversion's
> Git branches carry their entire history
> Merging in Git does not require you to remember the revision you merged from (this benefit was obviated with the release of Subversion 1.5)
> Git provides better auditing of branch and merge events
Branching in Git is marginally better then SVN. Neither is magical or even good.

> Git's repo file formats are simple, so repair is easy and corruption is rare.
I have had corrupt SVN repo's but never a corrupted Git repo. But SVN is easy to fix.

> Backing up Subversion repositories centrally is potentially simpler - since you can choose to distributed folders within a repo in git
This makes no sense.

> Git repository clones act as full repository backups
Two edge sword again.

> Subversion's UI is more mature than Git's
Git's UI sucks, even the good ones.

> Walking through versions is simpler in Subversion because it uses sequential revision numbers (1,2,3,..); Git uses unpredictable SHA-1 hashes. Walking backwards in Git is easy using the "^" syntax, but there is no easy way to walk forward.
This feature is HUGELY helpful in automated build systems.

My 2 cents
Git is much much harder to use for someone who is not a pedal to the metal coder.
I have seen junior coders and artists want to commit suicide after using Git.
I have had a lot more problems merging files in Git then I ever did in SVN.

git than svn

[Anonymous Coward]

I had SVN but gitting is so much more controlling. At git when svnening was not even an option i would git a merge together and combine the pieces when svn would have me checkout the entire version. The versioning control when svnening does not offer the robotness of git where i can for example enter git checkout branchWork1 -- /folder-i-want-to-work-with and work on a small part of a 100tb project then later at the end of the week the slave can merge it all. all in all svn is great

Oh hey, thanks for letting me know!

[neminem]

The post I planned to make: "no, I will still use svn like I have, but unless there's actually a good reason not to, I'll stick with the svn I was already using, because why upgrade just because someone tells you to, without a clear reason why the new version is actually better?"

Finally fixing the messy pseudo-rename component is a darn good reason to upgrade, though. I will let people know (he company I work at exclusively uses svn. I really see no reason to use a distributed versioning system, especially not in the context of an actual whole software company. And Svn is a fine technology. This sounds like actual improvements have been made, though.)

In Soviet Russia

[Roachie]

Subversion will git YOU!!!

SVN simpler than GIT

[echusarcana]

The concepts behind good old CVS were easy to understand. Subversion inherits this legacy while GIT can be conceptual shift for developers. Developers should be wrapping their heads around their code, not trying to understand the abstractions of source control. This is why I like SVN better.

CVS? SCCS!

[SpaghettiPattern]

CVS is very modern compared to SCCS.

Anyways, who in their right mind creates a single repository with 1T of source code? Movie editors perhaps? Will they really need an SCM system?

Too late

[Indigo]

I used to be a huge Subversion cheerleader, but switched to Git everything I could some time ago. Our work repo is Subversion, but using Git day-to-day is well worth the hassle of converting files in and out of another tool to do so.

I was actually considering going back to Subversion full time at work a couple weeks ago, but merging a long-running development branch to trunk was enough to kill that idea. Subversion's merge pretty much shit itself at the get-go. The CM lead insisted on saving the development history on the branch - not worth the effort, but his call. I managed to save history for pre-existing files that were modified. After wasting hours of my (and Google's) time and trying everything short of standing on my head, I finally brute-forced the added and deleted files so I could move on with my life. Lesson learned but day wasted.

Merge is fundamental, and it's completely solid on Git. I'll let someone else sort out whether it works now in Subversion.

Point of View of a gamer

[KVM]

Git is mostly used in Minecraft mods source codes (Github) while SVN is mostly used in Gmod addons because it is more easier to use TortoiseSVN to automatically update the addons folder

If only SVN would fix their rename bug

[Anonymous Coward]

The SVN people might entice me back from git if they would fix Issue 898, which has been open since 2002. After getting bitten by this twice on large checkins, and having to hack the .svn files to get out of it, I'm done with Subversion. Also check out the hostility from the developers in the last comment.

With git, this is not an issue, because you can commit straight renames and moves to your local repo without affecting the central repo, and git keeps perfect track of them.