[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Sat, 11 May 2013 17:50:46 -0400

On Sat, May 11, 2013 at 1:25 PM, Zé <jose.passes_at_gmx.com> wrote:
> On 05/09/2013 09:35 PM, Branko Čibej wrote:
>> The real problem here is that Subversion does not treat/renames/ as
>> atomic operations.
> I think that the real problem here is that Subversion doesn't support
> branches. The fact is that moving or copying a file or directory around is
> not the semantical equivalent of creating a branch. Therefore, if the same
> operation is used to perform both then one will not be supported as well as
> it could be.

And yet, somehow, it works.

This goes straight back to the origin of Subversion, as "CVS done
right". CVS had a *nightmarish* approach to handling tags and branches
and locking and secure remote access and a dozen other critical
features. It was used because it was very lightweight, easy to learn,
and let people shoot themselves in the foot if they really wanted to
for whatever reason.

Subversion developers ahve, understandably, elected not to enforce
tags/branching/trunk in the software, and let directory structure and
access management serve instead. This has provided enormous
flexibility: I can make a branch of only one small directory of a
trunk, and work with that, and merge it back without having to manage
a whole branch. And I can even weave them together in fascinating ways
with "svn:extern", to make new structures of multiple branches and
tags from multiple repositories.

As soon as you go to a more popular, mandated and hardcoded
"branch/trunk/tags" structure, you lose that flexibility and the
ability to have multiple small components of a repository tagged off
or branched off individually.
Received on 2013-05-11 23:51:18 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.