On Fri, 23 Sep 2011 09:41:54 +0000, Thorsten Schöning wrote: ... > I didn't write any commit triggers regarding tags until now, but am > able to use them.
Except that they behave like branches instead of tags. If you check out a tag and then commit into it, there will be exactly no warning. Neither will there be if you accidentally 'create' an existing tag by doing 'svn cp $someting $dest/tags/tagname' which will not even move the tag but rather create a new directory within it. This is all logically sound from the way svn is designed, but it is not exactly what you expect from tags (like, being immutable except when using -f). (Hmm, I should really check whether our commit trigger prevents removing and recreating an entire /tags directory.) ... > The simple difference is, that a commit in SVN is enough. With git the > dev has to commit and the push must be organized somehow, too. Which is a very mixed blessing. On the one hand side new people tend to forget the push. On the other hand side it has the big advantage that you can affort to be wrong in a commit (like, mistyping the commit message or forgetting to add a file, or being wrong about how you only commit the property change in the root but nothing else), and fix that before the push. And, usually as long as you don't push it you can repair any commit, not just the last. Summary: As long as you work on one branch (trunk) and don't care too much for the quality of the individual commits (as opposed to the resulting tree), svn CLI is fine and dandy. Working with branches, however, is cumbersome in a completely unnecessary way. Unfortunately I often find myself in the latter part due to the kind of work I do. Andreas