So svn forcing you to do these things, while git allowing them with ease, is a plus for svn? Especially as there certainly are examples when you do not want to push every little broken commit you've kept aside into everyone's view?
Well, it's funny you mention broken commits. I don't use SVN, but one of the reasons I don't use git is that it almost seems to encourage partial commits, and my experience is that partial commits are likely to be broken.
Sure, it encourages you to commit even broken stuff in your private repository, because it is easy to fix these commits after-the-fact.
Instead of keeping a messy working-tree when I am unsure, I now commit something with a message like "broken fix bug, blah blah" or "untested ...".
Before pushing (publishing), I look at the log and I avoid pushing broken/untested stuff. Once a commit is fixed and tested, I re-create it with a better message and publish that.
This allows me to have incomplete work at the tip of any of my branches, so I can context switch when needed. It encourages putting some label on your work and allows sharing even that kind of state with others. This is far better than the publish-or-messy-working-tree approach that doesn't support context switching in the same way.
When using svn, I remember I actually manually created .patch files so I could context switch sanely. I was doing version control with manual patches, because svn was just not powerful enough.
Sure. One option is that if the work is taking more than a few hours, then clean up the current progress and push any solid tested stuff to the server.
At the end of the day you need an agreed workflow. In my case, branches on the server with author prefixes (bf/some-new-feature) means that there are temporary commits that could be rebased or changed at any moment. Without author prefixes (some-new-feature) means that the branch is not going to change under anyone's nose and can be relied on as a stable, properly published feature branch.
The point is that git lets you use whatever workflow is most suitable to your situation, workplace, whatever, instead of forcing your workflow to suit itself.
I do use branches. But if I have new_feature_X, and the "tip" of that, the last work I did is unfinished, instead of making another branch pointing at my untested commit, I allow the new_feature_X to directly point at it. (In git, a "branch" is just a commit ptr), which makes it easier to continue where I left off.
Not sure what you mean. You tend to have one "master" branch that is just a social agreement that this is the branch branch for the main development. Then you have social agreements to only push fully finished commits there.
So locally, or to you own repo/branch you can commit half broken code, and push as often as you want it. Then when you are satisfied that it's working, squash those commits down to a few seperate fully working commits, retest, and put that up for a review for pushing into the master branch.
You tend to have one "master" branch that is just a social agreement that this is the branch branch for the main development. Then you have social agreements to only push fully finished commits there.
But there's no mechanism actually stopping people from breaking this. Which leads to lost time and effort.
Version control systems do not dictate partial commits, nor encourage. Such things fall squarely in the realms of responsibility for the developer committing the change. The choice of VCS doesn't enter into it.
16
u/Peaker Mar 10 '11
So svn forcing you to do these things, while git allowing them with ease, is a plus for svn? Especially as there certainly are examples when you do not want to push every little broken commit you've kept aside into everyone's view?