Julien Nitard wrote:
No, there is a fundamental difference between svn and git. Let me elaborate.
In svn, by "branch" we just mean a branch of the file tree in the repository. The repository as a whole has a single history which is a linear sequence of revisions. So of course you can make a feature branch, but a commit to that feature branch is really also a commit to all other branches, the trunk and all tags -- and vice versa.
This is just wrong. A commit (or revert) to a branch is a commit to that branch only. And don't tell me that the shared version number is a problem.
Of course I may be wrong. Please help me to clarify: if I checkout branch A (only) and commit a change to it and branch B is not affected along the way, is that because (1) I didn't edit branch B, so naturally it wouldn't be affected, or (2) svn somehow treats edits on branch A as events that are isolated from edits on branch B? The latter would mean that svn could, for example, prevent me from doing the following: checkout the entire /branches directory, make edits on both /branches/A and /brances/B, then commit all changes together in one revision.
If at second thought you don't like your last three commits to the feature branch, you can't just revert history because that might also undo, say, the last twenty commits other people made to trunk. So you always have to manually select which files or subtrees to revert.
You're wrong, again. This is completely possible and even simple. I only have to select (including cherry picking) the commits I want to revert.
So if I checkout branch A (only) and I say "svn revert 2", only the files in branch A will be affected because svn understands that I'm not working on other branches. Is that what you're saying? Yes, basically that means I'm wrong. However I want to ask you how svn is doing this. Personally I think history stays as it is -- say at revision 3 -- but that svn replaces the files in my working directory with those from branch A at revision 2. Next I can edit those files or commit them straight away, which would produce revision 4. A reset in git is different: you undo history rather than retrieving files from an old commit. I'm still inclined to think that if there was such a thing as undoing history in svn, it would always affect the entire repository rather than just your working branch. Note that if I'm right (but again, I might not), git also has a revert operation, which lets you retrieve files from an old commit without affecting history. One final note: if I run "svn help revert", it does seem to need a path as an argument, and it also says it isn't able to restore deleted directories. To me, that seems strictly less powerful than a git reset.
The level of wrongness in this email (at least the quoted part above) is such that it is hard for me to keep calm. I am, admittedly, biased toward SVN. I can accept that DCVS systems like git may improve the workflow on projects like boost, but you're twisting facts. I am currently wondering whether you did that on purpose or not.
Please take my word that I didn't intend to give misinformation. I made an error because I went a little too quickly over the issue and failed to realise that a reset in git is a different beast from a revert in svn. I might have made other errors as well, which would also be unintentional, but that's still open to discussion for as far as I'm concerned.
Sorry if this was too strong, I am not perfect myself and make mistakes too. I would like to keep the discussion in a cordial tone if possible.
It's ok, nothing personal, I like a cordial tone too. -Julian