Jakub Narebski wrote:
In my opinion the update-then-commit workflow CVS and SVN forces on users is one of the more annoying features, forcing the user to resolve conflicts if he/she wants to be up-to-date.
I'm not eager to jump to svn's defense -- there's a reason I'm using git and trying to get my coworkers to do the same -- but how does git allow you to stay up to date without resolving conflicts? Granted that git is smarter about resolving certain kinds of conflicts automatically, but fundamentally if the latest revision you've pulled down (from any kind of version control system) makes a change that conflicts with a local change (whether or not you've committed it locally first) you're going to have to resolve it by hand, yes?
Also, last I checked, git wouldn't let me push into a branch that had revisions I hadn't yet pulled down. Isn't that just another way of enforcing an update-then-commit workflow? If anything, svn wins in that area -- it allows me to commit without updating as long as my change doesn't touch any files that have changed upstream.
One can argue about whether allowing partial commits like that is a good idea, but it's just not true that svn forces you to always update before you commit, and if you're pushing into a branch that other people are also updating, the ability to commit files that didn't change upstream means it is actually *less* insistent on update-then-commit than git is (if you take "commit" to mean "commit-and-push" on the git side as was suggested in the message I replied to originally.)
Unless, of course, I'm misinterpreting you here.
The update-then-commit assumes that you merge on update local modifications with current server version, assuming that ancestor is current local committed version. This makes off-line committing impossible, and makes rare updates (server version advanced by more than one commit) unnecessary hard.
That last point is completely counter to my experience. At my company (where the svn repository is still the official code base) the repository is constantly changing. I'll sometimes let hundreds or even thousands of revisions go by between updates of my svn client. When I'm at a good point to do integration testing and I'm using an svn client instead of a git-svn one, I type "svn up", do roughly the same manual conflict resolution I'd do after a "git pull" that brought down a similar number of new revisions -- often none at all if I'm the only one working on a particular corner of the code base -- and I'm good to go. What's unnecessarily hard about that? How would it be any better in git?
Local commit capability is absolutely a huge win in git, though, and is one of the main features I use to sell people on it internally. No argument there. I just don't like being *forced* to do a local commit when I have no reason to do so other than to satisfy the version control tool. I end up either cluttering my history with dummy revisions or having to type extra commands to get rid of them.
And in particular -- this being the original topic of the thread -- when an svn user sees me doing that, they do not immediately think of the fact that merging between immutable revisions may have some benefits. They see me typing four commands (commit, fetch, rebase, reset) to do the same thing they can do in one command with svn, and conclude that git is harder to use. That some of them choose to use it anyway is a testament to how great git is in other areas.
-Steve - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html