Re: Subversion history: Why was/is tagging/branching implemented as copy?

On Mon, Nov 03, 2003 at 12:50:19PM -0600, kfogel@collab.net wrote:
> > Can someone of the Subversion developer crew please detail
> > on the project decision to implement Subversion tagging
> > and branching as explicit copy? Are there any thoughts or is
> > there any ongoing work to later on implement a sort of
> > "true" tagging and branching?
>
> There are no plans to change it -- we think copies *are* true tagging
> and branching.

I think that is true conceptually. Of course it only works upto a point, and a new line of development doesn't truly copy every file in the repository, and neither does Subversion (which uses copy-on-write semantics with references).

I assume however that the underlying version-archive file still stores ONLY the deltas for a file, and does not actually copy code in the version-archive itself when a file is branched due to parallel development. Is this correct?

Doesn't Perforce use a branching model that is very similar to Subversions, in which it too gives the user the appearance of treating branches as a copy of the codebase?

Could someone on the list elaborate on the differences between the Subversion branching model and the Perforce branching model, saying how they are the same and how they are different?

> > How do you see this topic? Is it just my personal problem,
> > my biasing towards concepts I have grown with (ClearCase-user)?
> > Or, are native tags really a concept that Subversion lacks?
>
> We tried to think of an important difference between tags/branches and
> copies, and couldn't, so we just decided to implement them as copies
> and make it user-visible.

You are in good company. It seems that Accu-Rev (www.accurev.com) also equates "tags" (labels) and branches (development streams) and considers them both to be kinds of streams: labels are "static" streams that do not evolve, and branches are "dynamic" streams that do evolve.

As for presenting them as copies to the user, I think it is conceptually easier for the users I have come across (and I'm no slouch myself when it comes to understanding branches and branching - see acme.bradapp.net). I would liken it to the way we try to draw 3D images on a 2D surface (such as a piece of paper, or a canvas): Theoretically, branches represent a new axis in the "time" dimension of a product or system. It makes sense to a lot of people to simply "physicalize" the mental image of it in their head by representing it as an independently evolving copy of the system. As long is it is still clear that it isn't a true physical copy in every aspect, and there is knowledge that it really isn't storing any redundant copies nor duplicating deltas - I think it is pretty clear to most.

I do think it would be good if a later release of subversion could enforce "static-ness" of a tag, perhaps via some general "lock" mechanism, so that a tag could essentially be a branch that was locked after its initial definition. I think it would be a very useful nicety rather than requiring hooks to do the trick. But I understand that right now there are many more necessities than niceties to be worked on :-)

-- 
Brad Appleton <brad@bradapp.net> www.bradapp.net
  Software CM Patterns (www.scmpatterns.com)
   Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org