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
Received on 2011-09-23 21:35:51 CEST