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é
Received on 2013-05-18 20:43:34 CEST