> 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é
