Thomas Beale wrote:
> Branko Čibej wrote:
>
>> David Weintraub wrote:
>>
>>> So, it seems rather strange that Subversion doesn't understand the
>>> built in concepts of branches and tags. Instead, these items are
>>> merely emulated via pseudo-directories. After all, tags and branches
>>> have been implemented as part of version control systems since RCS
>>> back in 1985.
>>>
>>>
>> Subversion certainly does understand branches and tags. The important
>> feature of branches (and tags -- these are just branches that are
>> never changed after creation) is that they establish a (named)
>> parallel line of development that tracks its ancestry and can expose
>> ancestry information to procedures that need it, e.g., merge.
>>
>> From what I've been able to gather from this thread, people are
>> either upset or confused because directories and branches share the
>> same namespace, whilst most other VC systems in use today have a
>> separate namespace for branches.
>
>
> I don't think anyone is upset or confused. Without wishing to
> antagonise anyone in this discussion, it is quite clear in a formal
> sense that subversion doesn't directly implement the semantics of
> branches and tags; it just approximates them using an existing
> facility. To see that this is true, consider that the concept of a
> 'tag' is not itself a 'parallel branch'; it is the name attached to a
> particular revision of a line of development, either the mainline, or
> some other branch. But it is not implemented in this way - it is
> implemented as a copy of some other part of the repository.
*Sigh*
You're imposing your fairly narrow perception of what tags are. A tag is
a name for a collection of versions (a configuration in SCM-speak).
Those versions can all come from one branch, but that's not a
requirement in general. How it's implemented, and what the name looks
like (in SVN's case, it's an URL), is irrelevant here. And, BTW, in
Subversion you can create a tag that does not correspond to any
committed revision in the repository.
>> But this is in fact just a UI detail. It does not meant that SVN
>> doesn't "support" branches, and it certainly doesn't make SVN's
>> branches second-class objects.
>
>
>
> I disagree; it's not just a UI detail. Subversion's branches are not
> first-class objects; they are simply copies of other parts of the
> filesystem; there is nothing except human process to make sure that
> they are not accidentally abused.
Oh foo. Of course it's a UI detail. Or do you suppose that branches, in
ClearCase, are not conceptually isomorphic to copies (albeit in a
different namespace)?
> There's also a huge benefit in having a single namespace -- namely,
> WebDAV/DeltaV interoperability. We'd have had a lot more trouble
> getting that if we had more than one namespace.
>
> I disagree here as well. Having TRUNK/BRANCHES/TAGS in the directory
> tree is a real nuisance for build scripts.
But your build scripts don't have to know about these things. What's the
difference between saying "Build from this tag" or "Build from this
URL"? None at all.
> It would be easy to make these disappear on the server side, while
> retaining the dav_svn view of things. It's just a matter of how the
> dav_svn apache module is implemented.
Read the WebDAV spec. This has nothing to do with how mod_dav_svn is
implemented.
> If you have a look at some of the other (better) systems, you can see
> that banching and tagging are almost always built-in, not just
> implemented in the file system.
Aargh. "built in" vs. "implemented in the filesystem"? Same difference.
It is simply a question of how your UI represents branches and tags.
BTW, because it lets you define branch and tag namespaces in any way you
want, Subversion's way is _more_ flexible than most other VC systems
I've seen. I think people are just irrationally afraid of this
genericity and flexibility.
Would you feel better if we had a "svn branch" and "svn tag" command?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 12 11:17:20 2005