On 05/18/2013 06:33 PM, Thorsten Schöning wrote:
Guten Tag Zé,
am Samstag, 18. Mai 2013 um 18:24 schrieben Sie:
The only difference between subversion and other SCM systems
is that other systems offer support for labeling and adding useful info
to those revisions, while Subversion doesn't.
Which useful info besides the name, and always present things like a
revision, timestamps, who made the commit etc. is this? And how does
one benefit of those additional info compared to the lack of
structuring of branches and tags those SCMs provide compared to
Subversion?
Subversion doesn't offer tags explicitly. The closest it has is revision
numbers, and the standard course of action is to simulate this feature
by creating a dedicated subdirectory that is used exclusively to store
copies of the trunk whose names are selected to reflect tags.
Having said that, the "let's copy the trunk to a subdirectory" approach
to simulate tags is not a problem, nor is it a shortcoming. People have
emulated tags by storing tar files containing copies of the trunk, and
that works well.
If you are referring to the ad-hoc method of copying the trunk/branch to
a subdirectory then all that you're doing is copying the trunk directory
to another directory in your repository. That may be a convenient hack,
but that isn't exactly support for tagging.
That's not an argument at all, because all one does in other SCMs is
creating branches and tags. What you really should argue is what all
devs think is common sense about branches and tags and why Subversion
doesn't fulfill those requirements.
That has already been repeatedly stated. Again, using the ad-hoc
directory copy/move operations to simulate branches stores all the
changes in the repo's revision history for all eternity, even when
creating short-lived development branches which don't go anywhere and
end up being deleted.
The only thing mentioned until
now is that revision numbers can change in the way subversion handles
branches and tags and that only because Subversion does provide
features, like (re)structuring branches and tags in a hierarchical
way, other SCMs simply doesn't provide.
That's the least of anyone's concern. The issue is that behind those
revision numbers there are real changes made to the repository, which
are eternally kept there and are made available to anyone. If you create
a directory, change some files and delete the directory, and each
operation is individually committed to the repository, each of those
operations are eternally made available in the repository. This means
you can checkout a specific revision that presents you with any of those
changes. If you resort to those operations to emulate development
branches, which is the only way that subversion is able to emulate them,
then you end up storing in your repository revisions that reflect
dead-ends which didn't made their way into the trunk, and those
revisions do have an influence in subsequent revisions committed to the
repository.
Let's put it this way: if that was actually a tag then it could also be
argued that any file system supports branching/tagging.
You ignore the versioning part of Subversion and that it guarantees
the state/history of branches and tags like any other SCM.
You've missed the point. The point was that the suggested ad-hoc way to
emulate tags with subversion is to copy a snapshot of the trunk to a
subdirectory. That doesn't mean that a file system supports tags.
Besides
that, from my understanding filesystems do provide something which
could be argued as support for branches and tags because branches are
simply just work on something based on something other, which is
implemented as copying files and directories, and tags are something
which isn't as worked on as on branches, but is based on something
other, too, and may easily be implemented using copying things around
again and simply don't touch it anymore or e.g. using snapshots, which
would better guarantee an unchanged content.
That's essentially what subversion does, as the only thing it actually
does is track revisions made in a specific directory. It works very
well for a wide range of applications, in some cases better than other
SCM systems, but the lack of support for branches does represent a a
shortcoming.
Zé
