You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Joachim Fabini <Jo...@gmx.net> on 2003/11/03 12:23:37 UTC
Subversion history: Why was/is tagging/branching implemented as copy?
Hi,
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?
<imho>
Everything below is written from the user's point of view.
I am sure that there was a specific (fundamental) reason for
the copy-decision. Mostly because tags and branches shield
the repository implementation from the user, which is
highly desirable. I consider svn copy as a repository-specific
detail of tagging/branching implementation that end-users are
most likely not interested in and that they should be shielded
from.
I searched the Subversion archives but did not find any
details related to the decision. What I _did_ find were
some documents and postings that discuss on the "right"
way how to structure a repository, how to copy Subversion
trees in order to "correctly" tag or branch, etc.
Don't you see this, too, as a confirmation of my guess that
versioning as currently implemented by Subversion is the
rather undesirable exposing of implementation matters to
users?
</imho>
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?
Thanks in advance
Best regards
--Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion history: Why was/is tagging/branching implemented
as copy?
Posted by Ben Collins-Sussman <su...@collab.net>.
> 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?
I think you're stuck in cvs-land. A branch/tag is a line of
development. But "line of development" is a pretty vague concept. If
anything, I can make an argument that cvs's implementation of
branches/tags is *less* intuitive than subversion's.
For example, when I tried to explain cvs branching to my wife (who is
not a techie), she got a bit confused. When I explained the subversion
paradigm ("just make a copy"), she understood completely.
When people don't have version control systems, "making copies" is the
natural behavior for maintaining two branches of a document.
So what you're seeing here isn't an accidental screw up: "oops, we
exposed the implementation." It's a deliberate design choice. We're
presenting a specific paradigm to users.
(Now the fact that svn tree-copies take up almost no disk space --
*that's* an implementation detail. :-) )
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion history: Why was/is tagging/branching implemented as copy?
Posted by Brad Appleton <br...@bradapp.net>.
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 <br...@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
Re: Subversion history: Why was/is tagging/branching implemented
as copy?
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>
>>[moving to the dev list, as it more properly belongs there]
>>
>>kfogel@collab.net wrote:
>>
>>
>>
>>>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.
>>>
>>>
>>>
>>>
>>Actually, I _have_ thought of an important (to me, that is) difference
>>between branches and copies, and I brought it up a few times, but it can
>>wait until post-1.0. A difference that would incidentally make history
>>traversing much easier, especially in non-BDB backends -- but it would
>>mean a change in the database schema. :-)
>>
>>
>
>Speak now -- you may just get your chance to change the schema one
>last time before 1.0...
>
>
Oh, no. For one thing, I don't have it entirely thought out myself. For
another, the schema change will probably not be minor (it should address
some inherent performance problems), so it's more likeli in svn-2.0
rather than svn-1.1.
/me fidgets, resisting the temptation
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion history: Why was/is tagging/branching implemented as copy?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> [moving to the dev list, as it more properly belongs there]
>
> kfogel@collab.net wrote:
>
> >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.
> >
> >
> Actually, I _have_ thought of an important (to me, that is) difference
> between branches and copies, and I brought it up a few times, but it can
> wait until post-1.0. A difference that would incidentally make history
> traversing much easier, especially in non-BDB backends -- but it would
> mean a change in the database schema. :-)
Speak now -- you may just get your chance to change the schema one
last time before 1.0...
-- Mike, enslaved by libsvn_fs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion history: Why was/is tagging/branching implemented
as copy?
Posted by Branko Čibej <br...@xbc.nu>.
[moving to the dev list, as it more properly belongs there]
kfogel@collab.net wrote:
>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.
>
>
Actually, I _have_ thought of an important (to me, that is) difference
between branches and copies, and I brought it up a few times, but it can
wait until post-1.0. A difference that would incidentally make history
traversing much easier, especially in non-BDB backends -- but it would
mean a change in the database schema. :-)
Re: Subversion history: Why was/is tagging/branching implemented as copy?
Posted by Daniel Berlin <db...@dberlin.org>.
On Nov 3, 2003, at 10:51 PM, Ben Collins-Sussman wrote:
> On Mon, 2003-11-03 at 21:43, Brian Huddleston wrote:
>
>> We *like* the tag semantic of a read-only snapshot of history, have
>> build
>> and development processes that rely on that semantic and would like
>> that
>> semantic to be enforced by something other than social convention.
>> :-)
>
> So enforce it with an authorization system. Either use a pre-commit
> hook script, or mod_auth_svn, or svnserve's authz system. Allow people
> to create top-level directories in '/tags/', but not do any other write
> commands in there.
Yeah, i don't understand the problem either.
What they've done can emulate the lesser behavior of CVS, but CVS can't
emulate what they've done.
IE it's a superset.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion history: Why was/is tagging/branching implemented
as copy?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mon, 2003-11-03 at 21:43, Brian Huddleston wrote:
> We *like* the tag semantic of a read-only snapshot of history, have build
> and development processes that rely on that semantic and would like that
> semantic to be enforced by something other than social convention. :-)
So enforce it with an authorization system. Either use a pre-commit
hook script, or mod_auth_svn, or svnserve's authz system. Allow people
to create top-level directories in '/tags/', but not do any other write
commands in there.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion history: Why was/is tagging/branching implemented as copy?
Posted by Brian Huddleston <br...@huddleston.net>.
Of course there are quite a few people that think that distinction between
tags and branching actually grew up for a reason and aren't just a product
of years of RCS systems "not thinking about the problem right".
We *like* the tag semantic of a read-only snapshot of history, have build
and development processes that rely on that semantic and would like that
semantic to be enforced by something other than social convention. :-)
*cries softly to himself "I just wanted CVS with directory versioning"*
Brian Huddleston
BetweenMarkets, Inc.
----- Original Message -----
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion history: Why was/is tagging/branching implemented as copy?
Posted by kf...@collab.net.
"Joachim Fabini" <Jo...@gmx.net> writes:
> 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.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion history: Why was/is tagging/branching implemented
as copy?
Posted by Jack Repenning <jr...@collab.net>.
At 1:23 PM +0100 11/3/03, Joachim Fabini wrote:
>Hi,
>
>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?
Well, the developers have spoken, but I'm not sure they actually
answered the question--at least, not in the terms important to a
non-developer ;-)
In fact, Subversion tagging and branching are *not* implemented as
copies. They are modelled at the UI as copies, but what actually
happens is both far cheaper, and far more useful.
The UI choice represents, at least in part, the observation that
folks with no VC system or experience make copies by reflex when they
bump into problems that "we all" know are VC-like. It seems to be a
natural human reflex. In fact, it's annoyingly common even in VC
contexts where much better solutions are available (grumblings from
ten years of ClearCase use). The Subversion implementation was chosen
in large part in order to provide this UI, because of the observation
that "people seem to like it."
The actual Subversion implementation is masterfully hidden, so
thoroughly that it never even comes up in conversations like this
one: Subversion makes a row-insert in a table. The row is largely
"copied" from some existing row, so you might call it "copying," but
it's copying data unknown to the user, from one invisible spot to
another. The rows in question are the database entries that describe
the list of "node-revisions" contained in this revision of this
directory. But it's not a data copy, and it's even more than a mere
file-reference copy, because the history is also linked to the new
location: the original and the new continue to share the same
ancestors--not similar ones copied back until the dawn of time, but
the very same ones. In short, these so-called copies act like
(gasp!) branches and tags.
That version history could be modelled as directory topology
("topology recapitulates ontogeny") is, I grant you, a startling idea
to those of us accustomed to other VC systems. It does require some
rethinking, it does provide some degrees of flexibility that are new.
I don't think that makes it "bad"; actually, I think that was kind of
the goal. If all we wanted was what already existed ... we could
have saved a *lot* of work!
There are some things still missing from the SVN-1.0 implementation
in this area. An implementation with more direct tag and branch
implementation makes it easier to do some things (like browse
*forward* in history). These things are on the post-1.0 to-do list
(check the "post-1.0" issues in the Subversion issues list). If you
find one not there, let us know (as noted at the site, you should
start such a conversation here, not in the bug list, as those pesky
developers may actually already understand the problem you describe,
and have secret knowledge that one of the changes already proposed
actually will provide the behavior you want).
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
f: 650.228.2501
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org