Earlier quoted context omitted.
They should use git-svn. It lets you still talk to that ugly SVN server and mostly obscures any associated pain. You just use git like normal, and then when you need to push to the SVN server, it's just git svn dcommit, or git svn rebase to pull. SVN doesn't know any different and you're not stuck trying to deal with it.
They should use git-svn. using a new version with a few new features of an existing tool (svn) is always an easier sell than using two new tools (git, git-svn) as well, especially when one (git) has a reputation as being very complex, and the other (git-svn) looks like a hack to glue two different systems together.
Subversion to enable Git-like features
21–28 of 28 posts
Re: Subversion to enable Git-like features
#22Earlier quoted context omitted.
You miss the point. The problem is that you think "Subversion is the Windows of version control" is an insult. Windows is the world's most prevalent desktop operating system, by a huge margin. Windows is responsible for around $4 billion dollars of profit per year for Microsoft. Only a fool dismisses a fact like that as irrelevant, obviously Windows is doing something right. Both Git and Linux are very ideologically…
The only reason Microsoft is on the top is its marketshare. People don't want to know anything about their computers, they just want to watch funny videos and talk to their friends. If you sit someone in front of something that doesn't look like Windows, they flip out. My grandma flips out when we try to show her something on our Linux computers, she says, "Where's your icons? Why does this look different? This is cr…
Re: Subversion to enable Git-like features
#23Earlier quoted context omitted.
The only reason Microsoft is on the top is its marketshare. People don't want to know anything about their computers, they just want to watch funny videos and talk to their friends. If you sit someone in front of something that doesn't look like Windows, they flip out. My grandma flips out when we try to show her something on our Linux computers, she says, "Where's your icons? Why does this look different? This is cr…
Windows is #1 because Windows is #1? There's certainly something to be said for network effect, but this particular line of reasoning seems more suitable to a tautology club meeting - http://www.xkcd.com/703/
Compatibility and familiarity are features of Windows's ubiquity, not Windows itself. What other reason does one buy Windows?
Re: Subversion to enable Git-like features
#24Earlier quoted context omitted.
I think this is mainly aimed at enterprise users where subversion is still very relevant.
They should use git-svn. It lets you still talk to that ugly SVN server and mostly obscures any associated pain. You just use git like normal, and then when you need to push to the SVN server, it's just git svn dcommit, or git svn rebase to pull. SVN doesn't know any different and you're not stuck trying to deal with it.
They haven't really mentioned exactly what will be supported by these changes, but it seems to me that without local branches, offline commits aren't really worth much. The fact that you need 5 svn checkouts to work on 5 different features at once sucks. With git-svn I can work on as many features as I want with different local branches, and they can each be based on different remote branches if needed.
Re: Subversion to enable Git-like features
#25Earlier quoted context omitted.
But Subversion's UI is horrific and its common operations throw away data in many cases. If Git is the Linux of version control systems, Subversion is the Windows of version control, and I don't mean that as a compliment. At least it's possible to get Linux working.
You miss the point. The problem is that you think "Subversion is the Windows of version control" is an insult. Windows is the world's most prevalent desktop operating system, by a huge margin. Windows is responsible for around $4 billion dollars of profit per year for Microsoft. Only a fool dismisses a fact like that as irrelevant, obviously Windows is doing something right. Both Git and Linux are very ideologically…
Back on to the topic of version control, Subversion has a major flaw -- its common operations throw away your data. It deletes your fucking work! That's exactly what a version control system should never do.
Git may have overly-sugary frontends that require a lot of manpage perusal, but one thing it doesn't do is lose your work. (Even "git reset --hard" is relatively safe; just "git checkout HEAD@{0} and it's reversed!)
I don't get how Subversion is simpler, either. Common operations:
To create a repository with Subversion, you have to find some central place to store it, setup permissions, add users, and finally you can import your files. With git it's just "git init; git add .; git commit -m 'initial import'". You can deal with replication later -- right now you can just work.
To checkout a branch with Subversion "svn switch ". With git, "git checkout ". To merge a branch, "git merge ". To push your changes to the server, "git push". To pull changes from the server without losing data in your working copy, "git pull --rebase". (That operation is not possible with Subversion, "svn update" brings your working copy into an inconsistent state that can't be reverted -- it creates a local branch, but without any tools to manage it.)
Anyway, Subversion is not good. Git is comparatively not that bad.
From a software engineering perspective, svn is probably better. But it's a well-engineered bad design. Git is a poorly-engineered good design. Good designs always beat good implementations. (Darcs is a great example of this -- great code quality, bad model. Still better than Subversion on both counts, though, of course.)
Re: Subversion to enable Git-like features
#26Earlier quoted context omitted.
They should use git-svn. using a new version with a few new features of an existing tool (svn) is always an easier sell than using two new tools (git, git-svn) as well, especially when one (git) has a reputation as being very complex, and the other (git-svn) looks like a hack to glue two different systems together.
Well, the thing about git-svn is no one has to know you're using it. The commits look just like they were submitted by SVN. You don't have to sell git or git-svn to anyone. Everyone can keep using SVN, and you can use git, and there would be no issue or problem here at all.
Personally, I would find it more useful to sit around and watch paint peel off my wall. But then again, I didn't write a book about why open source projects should have 100-message-long votes on every line of code to be added to the project... so I clearly don't "get it".
Re: Subversion to enable Git-like features
#27Earlier quoted context omitted.
Well, the thing about git-svn is no one has to know you're using it. The commits look just like they were submitted by SVN. You don't have to sell git or git-svn to anyone. Everyone can keep using SVN, and you can use git, and there would be no issue or problem here at all.
It's more fun to spend your free time copying git-svn's features and implementing them in Subversion. Or something. Personally, I would find it more useful to sit around and watch paint peel off my wall. But then again, I didn't write a book about why open source projects should have 100-message-long votes on every line of code to be added to the project... so I clearly don't "get it".
For most of us, no. For the SVN team, other forces are at work - I'd say familiarity of the code and desire for their baby to stay relevant are big ones.
Re: Subversion to enable Git-like features
#28Earlier quoted context omitted.
They should use git-svn. using a new version with a few new features of an existing tool (svn) is always an easier sell than using two new tools (git, git-svn) as well, especially when one (git) has a reputation as being very complex, and the other (git-svn) looks like a hack to glue two different systems together.
Well, the thing about git-svn is no one has to know you're using it. The commits look just like they were submitted by SVN. You don't have to sell git or git-svn to anyone. Everyone can keep using SVN, and you can use git, and there would be no issue or problem here at all.
It has to be sold to me (or your typical departmental svn user). I do spend time learning new tools, but that time is limited, so I'm less likely to spend it on something that has the potential drawbacks that I raised.
FWIW, yes, I am trying out git on the side. That use of time looks worthwhile.