On 05/11/2013 08:46 PM, Stefan Sperling wrote:
> On Sat, May 11, 2013 at 06:45:03PM +0100, Zé wrote:
>> You are misrepresenting the problem. It doesn't matter if subversion
>> isn't like any other SCM system. The problem is that the effect of
>> copying, renaming or moving a file or directory around, as done by
>> any SCM system, is incompatible with what's expected out of a
>> development branch.
>
> That's a matter of definition.
It isn't. It's pretty straight-forward. If copying directories around
ends up leaving traces on the revision history, which are forever stored
and forever made available in the repo's history, then resorting to this
hack to simulate branches goes against how developers expect a
development branch to work, and is a nuisance to those who have to
manage a repo and/or check its commit history.
> Recall that Subversion was designed to be better CVS. It was not
> designed to be an SCM system that fits anyone's definition of what
> an SCM system is and what kinds of abstractions it should support.
I don't believe any SCM is developed that way. They are, however,
designed to work properly. If creating a transient branch ends up being
eternally stored in a repo's commit history then branching method isn't
working properly.
> CVS had branches on a per-file level. That alone was deemed insuffient,
> so Subversion also has branches on a per-directory level.
No, it doesn't. It offers the ability to copy and move the trunk
directory around, and add that copy to the repository. That's not a
branch. That's a hack intended to make do with what features were
already available to try to simulate a branch.
> It works well
> enough this way for many use cases. But of course, it may not work for
> every use case, and if so people should use a different tool.
You're missing the point. The point is that subversion could be even
better than what it already is if it actually supported branches.
Zé
Received on 2013-05-11 23:50:49 CEST