Subversion to enable Git-like features(subversion.wandisco.com)
subversion.wandisco.com
Subversion to enable Git-like features
http://subversion.wandisco.com/component/content/article/1/44.html
27 comments
Yes absolutely - Don't get me wrong, I'm not saying that Subversion is for everyone, of course it's not. However the next release will see considerable improvement for all Subversion users. Who knows, some Git users might even come back ;)
This has to be good news, anything that advances commonly used tools improves software development in general. Whether you like subversion or not.
I think you're better off just using Git.
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.
Its nice to see that subversion as a project is still evolving, but I will continue to use git-svn as my subversion client anyways most likely.
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.
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.
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.
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'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".
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".
It's more fun to spend your free time copying git-svn's features and implementing them in Subversion. Or something.
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.
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.
You don't have to sell git or git-svn to anyone.
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.
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.
It doesn't have to be an either/or. I've been very happy with git-svn as my svn client. It's not git-like, it's actually git.
Git is basically the epitome of why linux will never have significant marketshare on the desktop. Sure, Git is an amazing tool, but its usability is utterly horrific. And Git's most prominent users tend to be extremely sophisticated and intelligent software developers who are able to come to grips with these usability problems quite easily, so their response to those problems tends to be "get over it, git is great, use it anyway, it's not that big a deal, quit whining" which is no better than "let them eat cake".
When people use a computer they want usability, they want a GUI (where relevant), they don't want an ALTAIR front-panel with a bunch of inscrutable toggles and equally inscrutable lights. This is why Mercurial is so popular despite being so similar to Git. Until the Git team accept these problems as real problems and do something about them Git will be relegated to a niche tool and 10 or 20 years down the road when every dev is using DVCS it won't be Git it'll be Mercurial or SVN-DVCS or something new.
When people use a computer they want usability, they want a GUI (where relevant), they don't want an ALTAIR front-panel with a bunch of inscrutable toggles and equally inscrutable lights. This is why Mercurial is so popular despite being so similar to Git. Until the Git team accept these problems as real problems and do something about them Git will be relegated to a niche tool and 10 or 20 years down the road when every dev is using DVCS it won't be Git it'll be Mercurial or SVN-DVCS or something new.
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.
SVN's UI is generally hidden. There's AnkhSVN which is a plugin for Visual Studio, for instance. And one that follows the standard Source Control plugin structure, rather than working in a non-standard way (as the Git one does).
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 pure in their design and construction. This has considerable benefits in some areas (I'm a huge fan of Linux as a server) but leads to a degree of maniacal zealotry in the developer and fan-base which ultimately causes the projects to become self-limiting.
I like Linux. I like Git. I think the technology underpinning both is fantastic. I'd like to see them both succeed. I'm just sad that there are so many zealots peddling the idea that any flaws (and there are many for Linux on the desktop and for Git as a tool for every dev in the world) can be swept under the rug because of the awesomeness of the ideological purity of their construction.
Both Git and Linux are very ideologically pure in their design and construction. This has considerable benefits in some areas (I'm a huge fan of Linux as a server) but leads to a degree of maniacal zealotry in the developer and fan-base which ultimately causes the projects to become self-limiting.
I like Linux. I like Git. I think the technology underpinning both is fantastic. I'd like to see them both succeed. I'm just sad that there are so many zealots peddling the idea that any flaws (and there are many for Linux on the desktop and for Git as a tool for every dev in the world) can be swept under the rug because of the awesomeness of the ideological purity of their construction.
As a technical person, I care about technical merit, not whether or not something is a cash cow for the manufacturer. I use Windows at work, and I watch it waste hours of my own time and my coworkers time. Just yesterday, my friend had some random problem with his roaming profile -- it started taking 25 minutes to log off. We tried various things that the support folks recommended -- the result was a wasted day (costing our employer hundreds of dollars in lost time), and the problem still persists. Maybe reformatting his machine and removing and re-adding the account in AD would fix the problem. The fact is, nobody really knows. Nobody knows why this is happening, and nobody knows how it can be fixed. That's what you pay hundreds of dollars for -- software that is so unmaintainable that even Microsoft can't fix it. At least with Linux, you can read the source code and figure out how to fix something. (I can't think of any problem with Linux that can't be fixed, given time. But there are a lot of Windows problems that can never be fixed.)
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 <some long http URL that has to be exactly right or it fails>". With git, "git checkout <branchname>". To merge a branch, "git merge <branch>". 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.)
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 <some long http URL that has to be exactly right or it fails>". With git, "git checkout <branchname>". To merge a branch, "git merge <branch>". 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.)
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 crazy."
The sad thing is that a lot of this is Microsoft's fault in the first place. They've used their marketshare totally irresponsibly. Failings in the design and implementation of Windows have made users almost universally afraid of tinkering with their computers because of the possibility of breakages, viruses, and other unpleasant consequences.
Windows is #1 because of its marketshare and that's it. There may have been reasons they got to #1 a long time ago, but those are irrelevant now. What's relevant now is that Windows keeps on trucking because any program or component you pick up at the store will work on Windows, because everyone uses Windows, and you wouldn't make any money selling something that Windows can't work with. Everyone knows how to use Windows; they know to click the Start button, to click on the blue E, they know where things are. It's just like the systems they use at work or school.
For most people, the reason they choose Windows is because Windows is everywhere, and that's it. You won't find many people saying that they want to use Windows because they love the concept of the Start button. They use Windows because they know how it works. A few smaller niches use Windows because a program or a set of programs that are important to them run [well] on it. Very, very few use Windows because of Windows itself.
So, uh, now that we're done with that tangent, I think the Linux community recognizes the need for usability. You should read Planet GNOME or Planet KDE more often; there are frequently posts there about usability studies and improvements on their software. They are making strides. It's just that getting cooperation, funding, etc., is an uphill battle when your installed base is under 2%.
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 crazy."
The sad thing is that a lot of this is Microsoft's fault in the first place. They've used their marketshare totally irresponsibly. Failings in the design and implementation of Windows have made users almost universally afraid of tinkering with their computers because of the possibility of breakages, viruses, and other unpleasant consequences.
Windows is #1 because of its marketshare and that's it. There may have been reasons they got to #1 a long time ago, but those are irrelevant now. What's relevant now is that Windows keeps on trucking because any program or component you pick up at the store will work on Windows, because everyone uses Windows, and you wouldn't make any money selling something that Windows can't work with. Everyone knows how to use Windows; they know to click the Start button, to click on the blue E, they know where things are. It's just like the systems they use at work or school.
For most people, the reason they choose Windows is because Windows is everywhere, and that's it. You won't find many people saying that they want to use Windows because they love the concept of the Start button. They use Windows because they know how it works. A few smaller niches use Windows because a program or a set of programs that are important to them run [well] on it. Very, very few use Windows because of Windows itself.
So, uh, now that we're done with that tangent, I think the Linux community recognizes the need for usability. You should read Planet GNOME or Planet KDE more often; there are frequently posts there about usability studies and improvements on their software. They are making strides. It's just that getting cooperation, funding, etc., is an uphill battle when your installed base is under 2%.
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/
Can you tell me what features of Windows compel the normal user to buy it? Compatibility doesn't count because generally people will make their wares compatible with whatever has enough marketshare to seem profitable.
Compatibility and familiarity are features of Windows's ubiquity, not Windows itself. What other reason does one buy Windows?
Compatibility and familiarity are features of Windows's ubiquity, not Windows itself. What other reason does one buy Windows?
I guess you hadn't noticed that git has a very nice gui.
Which do you mean? Git-GUI is not "very nice" by any means. TortoiseGit is decent but a new Git user is hardly guided there (compare that to: http://mercurial.selenic.com/downloads/).
Also, my point wasn't specifically about GUIs per se but about usability overall. Git developers have only very recently, and only very grudgingly it seems, accepted that usability is even a serious concern. Considering that a developer will have an enormous amount of interaction with source control tools (almost as much as with an IDE or build tools in general) usability is obviously a huge factor. Git has a lot of the technical aspects nailed but I would be shocked if it won the current battle for revision control system of the future.
Also, my point wasn't specifically about GUIs per se but about usability overall. Git developers have only very recently, and only very grudgingly it seems, accepted that usability is even a serious concern. Considering that a developer will have an enormous amount of interaction with source control tools (almost as much as with an IDE or build tools in general) usability is obviously a huge factor. Git has a lot of the technical aspects nailed but I would be shocked if it won the current battle for revision control system of the future.
The thing is that git is a developer's tool. It's made for people who are on a commandline anyway, and I don't find it any more difficult to use than SVN or any other VCS I've tried. Most SVN users aren't used to the distributed paradigm, and so they might have a learning curve there, but otherwise most non-trivial SVN operations occur at a CLI too.
I agree that it'd be nice to see Git's functionality bundled up nicely, but that's not an exercise for Git's devs. Git, as one might expect, follows the normal philosophy in UNIX circles: do one thing and do it well. Adding a nice UI is an exercise for someone who wants to do that, and there are many projects attempting to do things like that, see http://git.wiki.kernel.org/index.php/InterfacesFrontendsAndT... .
Linux is the same way. Linux is just a kernel. It's up to others to throw nice GUIs (or any other program) on top of it. This is happening more and more, though I agree it could use more structure and organization. And for the record, I find GNOME much more usable than Windows.
I agree that it'd be nice to see Git's functionality bundled up nicely, but that's not an exercise for Git's devs. Git, as one might expect, follows the normal philosophy in UNIX circles: do one thing and do it well. Adding a nice UI is an exercise for someone who wants to do that, and there are many projects attempting to do things like that, see http://git.wiki.kernel.org/index.php/InterfacesFrontendsAndT... .
Linux is the same way. Linux is just a kernel. It's up to others to throw nice GUIs (or any other program) on top of it. This is happening more and more, though I agree it could use more structure and organization. And for the record, I find GNOME much more usable than Windows.
Anyone here still use SVN? Its been so long I barely remember how to spell it.