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
Received on Mon Nov 3 22:03:11 2003