11–20 of 40 posts
Easy when it comes at the cost of features is another way to say it's OK to be ignorant.
It's one thing to make things as easy as they can be.
It's one thing to not complicate things unnecessarily.
But it's a whole'nother thing to make things easy at the cost of features and power.
Anyone can make anything easy if they are allowed to cut enough features.
This is a terrible argument. Easy when it comes at the cost of features is another way to say it's OK to be ignorant. It's one thing to make things as easy as they can be. It's one thing to not complicate things unnecessarily. But it's a whole'nother thing to make things easy at the cost of features and power. Anyone can make anything easy if they are allowed to cut enough features.
"Even designers can use it." Why does everyone assume that designers are stupid luddites who can't wrap their heads around complex systems? UI design is full of nuance and complexity. It's insulting to designers to assume they cannot deal with DVCS.
Because designers, unlike programmers, have much higher standards for tools. They don't jump on a new "ground-breaking" toy every 2 months, just because someone famous had said "this is THE shit - use it". Whenever someone says "even X can use it" about some technology, it usually means that either X is stupid, or X is very busy and has no time to waste on "yet another Y". That said, git can be used in a perfectly ce…
But, this growth industry of training doesn't reach designers, clients, and other non-programmers, because this stuff is just too complicated for them.
"Even designers can use it." Why does everyone assume that designers are stupid luddites who can't wrap their heads around complex systems? UI design is full of nuance and complexity. It's insulting to designers to assume they cannot deal with DVCS.
The issue isn't that designers are stupid, it's that, since they tend to have a better design sense (the good ones, at least!), they're generally less forgiving of ugly, needlessly hacked-together systems than people who spend most of their time immersed in them. Designers are often helpful for a reality check. People should listen to them more! (There is also nothing about DCVSs that necessitates a bad UI, of course…
Huh? Am I the only one who finds Subversion to be very confusing, at the conceptual level, compared to git? All that file-by-file history tracking, just waiting to trip you up when you try to move a file around? The fact that branching in SVN is hopelessly entangled with the concept of copying directories around in some remote repository? Here's the canonical example from the SVN book:
svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Creating a private branch of /calc/trunk."
git clone git://github.com/mechfish/calc
cd calc
git branch my-calc-branch
git checkout my-calc-branch
# ... fiddle around, then when it's time to go back to master ...
git checkout master # note: no need to cd anywhere
git push origin my-calc-branch:refs/heads/my-calc-branch
git config branch.my-calc-branch.remote origin
git config branch.my-calc-branch.merge refs/heads/my-calc-branch
git checkout my-calc-branch
git push
The biggest problem with SVN is that getting started with it is so hard. As a git user, if I have a directory and I want it under version control, I do this:
cd my-directory
git init
git add *
git commit -m "Initial commit"
cd my-directory
git commit -a -m "I committed today"
As an SVN user, you need to find a hosted repository, get admin permission on it, set up the canonical directory structure -- being very careful to heed these words from the SVN book (you did read the SVN book, right?):
While Subversion's flexibility allows you to lay out your repository in any way that you choose, we recommend that you create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies.
... and then import your project, being sure to get it imported into /trunk and not into /trunk's parent. Then you have to check it out -- being sure to check out /trunk, or at least to do all your work in /trunk, lest you screw yourself up or confuse yourself.
So I assume that by "ugly, needlessly hacked-together systems" you mean "systems that make you use the command line". The only reason Subversion seems at all simple to non-geeks (to the extent that it does, which isn't much of an extent) is that the authors of tools like TortoiseSVN and Versions have sweated bucketloads of blood to design beautiful interfaces which hide all this cruft from the end users. DVCS will get there. Give it time.
Earlier quoted context omitted.
The issue isn't that designers are stupid, it's that, since they tend to have a better design sense (the good ones, at least!), they're generally less forgiving of ugly, needlessly hacked-together systems than people who spend most of their time immersed in them. Designers are often helpful for a reality check. People should listen to them more! (There is also nothing about DCVSs that necessitates a bad UI, of course…
they're generally less forgiving of ugly, needlessly hacked-together systems... Huh? Am I the only one who finds Subversion to be very confusing, at the conceptual level, compared to git? All that file-by-file history tracking, just waiting to trip you up when you try to move a file around? The fact that branching in SVN is hopelessly entangled with the concept of copying directories around in some remote repository?…
I use Mercurial, but I don't have any grand illusions about its interface being ideal. It works well enough for me, though. (I don't like svn either; tracking changes on a file-by-file basis isn't usually the right abstraction for the way I work.) DCVSs are relatively new, as somebody else pointed out, and in time they will probably have better interfaces.
In a world without Subversion, Subversion would be built out of Git. In a world without Git, Monotone, Darcs etc. ... well that's where we were 5 years ago, and it sucked.
In a world without Subversion, Subversion would be built out of Git. In a world without Git, Monotone, Darcs etc. ... well that's where we were 5 years ago, and it sucked.
Earlier quoted context omitted.
they're generally less forgiving of ugly, needlessly hacked-together systems... Huh? Am I the only one who finds Subversion to be very confusing, at the conceptual level, compared to git? All that file-by-file history tracking, just waiting to trip you up when you try to move a file around? The fact that branching in SVN is hopelessly entangled with the concept of copying directories around in some remote repository?…
Calm down. :) I never said that subversion's interface is great(?!), I just said that designers often find some tools programmers use ridiculously ugly and unnecessarily complicated. I think they have a valid point, and when programmers write them off, they often lose valuable feedback. (If a relatively simple tool is as annoying to configure as procmail, for example, somebody screwed up badly. IMHO.) I use Mercurial…
Yeah, that must be why so many of them use no version control at all...
I agree that the VCS to use is the one that your designer is willing to use. I just think that there's no reason why designers should necessarily want to use Subversion over a DVCS... except that, as a more mature tool, Subversion has a better selection of interface alternatives and a larger installed base.
"Even designers can use it." Why does everyone assume that designers are stupid luddites who can't wrap their heads around complex systems? UI design is full of nuance and complexity. It's insulting to designers to assume they cannot deal with DVCS.
In a world without Subversion, Subversion would be built out of Git. In a world without Git, Monotone, Darcs etc. ... well that's where we were 5 years ago, and it sucked.
Did it really suck? I was using subversion in a team of around 15, 5 years ago, and all in all it worked pretty well. It was rare that there would be any issue or that subversion got in the way. Maybe git is better... maybe it doesn't matter enough to bother changing. But you have to admit these types of things are more about what is "in fashion" than what is better suited to a particular task. Things go in big cycle…
Git, on the other hand? No problems.