On Sat, May 11, 2013 at 3:25 PM, Thorsten Schöning
<tschoening_at_am-soft.de> wrote:
>
> I have only little experience with git almost a year ago, but what I
> remember is that git does support tags and branches and neither of
> those could be structured in any way, git only allowed one level for
> tags and branches. That's especially interesting because I've read a
> lot of times that git is better with a large number of branches and
> tags than Subversion, because branches and tags are easier to handle
> in git.
I work with both extensively now. git allows your branches to be
totally local in your working copy, and to easily pull from or push to
multiple external repositories with arbitrary branches. And the
branches and tags are in a consistent relationship to the "master",
with the tags and branches being very cheap to create locally and
deleted locally not have to keep them around forever iin the history.
The tagging structure is, in my opinion, more robust because the local
working copy creates the tag, signs it, an dlocks it down locally.
Tags can't be edited by their very nature, which is a feature that
requires considerable and cautious repository configuration for
Subversion.
git lacks branching and tagging of individual smaller subdirectories.
And the learning curve is noticeably steeper.
> And now please explain why it is better to be unable to structure
> branches and tags in a way one likes or a project needs? And if git is
> suboptimal in this case as well and other SCMs allow hierarchical
> branches and tags, like Subversion, why should this hierarchy be
> anything other or separate than what Subversion provides with its
> files and directories?
There is considerable useful flexibilty for Subversion in having an
arbitrary workflow, perhaps of "devel", "branches", "tags",
"releases", "vendorcode", "submitted-patches", etc. in ways that allow
mixing and merging components that are not part of the classic
trunk/branches/tags structure.
Received on 2013-05-12 00:12:58 CEST