> On 05/18/2013 08:33 PM, David Chapman wrote:
> > On 5/18/2013 12:01 PM, Zé wrote:
> >> On 05/18/2013 07:16 PM, David Chapman wrote:
> >>>
> >>> You are pretty insistent that there is One True Way to use branches
> >>> in development.
> >>
> >> No, I'm stating that if all a SCM does is track changes made to the
> >> contents of a directory and you rely on changes made to that
> >> directory to emulate branches, then there are some significant
> >> downsides to this approach when compared with SCM systems which do
> >> offer support for branching.
> >
> > You've missed the point. You have a specific definition of branching
> > and do not believe that anything else can be called branching.
>
> You are confused. This discussion is about how subversion lacks any support for
> branching, which is quite obvious to anyone who understands and
> acknowledges that all subversion does is track revision changes to a file system.
> What you are insistingly referring to as branches is nothing more than a copy of
> a particular subdirectory (i.e., the trunk) into another subdirectory (i.e.,
> branches), which is nothing more than a plain recursive directory copy
> operation on a file system. The operation doesn't change its name or nature
> (tag, trunk, simple server-side directory copy) depending on the directories
> which are copied around the repository. Is that so hard for you to understand?
I disagree here. A branch is more than "a plain recursive directory copy operation on a file system." It has ancestry since it is pointed to its parent. This allows for merges from the parent to the branch. Svn log will show the revision history of a file from the branch back up to the parent path. Also blame goes back to the parent history as well. If a branch were "only a copy" then blame would only show, right after the branch, the person that made the branch.
You keep saying "svn doesn't support branches" yet I use branches every day. While there is no way to "list branches" it would be possible. I think the current implementation records the parent path in the branch, but not vice versa... I assume svn doesn't do this because it would be a change to the parent path and the svn design avoids modifying the repository on its own.
>
>
> > In your
> > message to Thorsten Schöning, you said that branch history should be
> > deleted if the branch is deleted. That is fundamentally in opposition
> > to the definition of Subversion, which is meant to retain all of a
> > project's history.
>
> Again, that's wrong. The only thing that leads subversion to track how a
> subdirectory is copied around in the repository is the fact that this is not a
> branching operation: this is nothing more than a plain file system operation.
>
> The point of this whole discussion is that subversion does not support branching,
> and therefore subversion users have to rely on the "let's copy the trunk
> directory somewhere in the repo to simulate tags/branches" hack to make do.
> Instead of relying on this hack, subversion would be significantly improved if it
> actually supported branches. How come you've replied so many times to this
> discussion if you are so oblivious to what has been discussed so far?
>
>
> <snip other misconceptions/>
>
> --
> Zé
Received on 2013-05-21 16:24:32 CEST