> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Wednesday, May 20, 2009 7:01 AM
> To: Bolstridge, Andrew
> Cc: David Weintraub; users_at_subversion.tigris.org
> Subject: Re: Subversion misses (was RE: Subversion vs. StarTeam)
>
>
> I'm a dev and I don't think the branching/tagging facilities are as
> good as they should be. I think that a lot of the merge-tracking
> problems
> we have or have had (e.g. subtree merge-info being created where it's
> not
> needed) are due to an insufficient destination between copies of
> directories and branches and tags. Putting all these concepts together
> under "copy" was fine before merge-tracking, but now it creates
> problems
> because e.g. a directory that is the root of a branch is special and
> Subversion doesn't know that.
Going by my understanding of the underlying architecture of
ClearCase/CVS and Subversion, I don't think that a labeling model will
work for Subversion. Instead of labels, Subversion should focus on
baselines. The following analogies aren't perfect, but hopefully
illustrate my point.
ClearCase and CVS support labels easily because each file is a single
versioned object, and that single versioned object contains *all* of the
history, branches, and labels associated with that object. Whenever you
branch the object, you're just updating the branch information contained
in that object.
Since each versioned object's history is self-contained, it's "easy" to
manipulate that history and/or determine merging. It also makes true
renames easy (you move the file and the history goes with it.) The
downside is that if you want to label 1,000 files, you have to crack
open 1,000 versioned objects and updated each one's label/branch/history
(which is very slow.) The other downside is Evil Twins; how do you
merge two independent objects that do not and cannot share
history/ancestry? Long story short, each individual versioned object
contains its full ancestry and history.
In my limited understanding of Subversion's architecture (feel free to
correct me,) each versioned file in SVN is small, ignorant object (the
object's history is *not* contained within the object.) That means
whenever you create a branch/tag/copy/rename of a file object, you get a
new object, and the old and new objects are completely unaware of each
other (whereas in CVS/ClearCase, creating a branch simply updates the
object's history instead of creating a 2nd object.) The SVN objects are
separated at birth and are unaware that they are related. The
relationship (aka ancestry) is tracked via the revisions and by
directory trees. Long story short, branching/tagging in Subversion is
about creating a whole tree of small ignorant objects, and a forest
object tracks the ancestry between trees of files.
Subversion -> Ancestry is centralized. A forest (the ancestry tracker)
contains trees (directories or sets) of files.
CVS/ClearCase -> Individuals maintain their own ancestry. Each file is
an isolated forest of trees of file revisions.
Plus, the labeling paradigms that most folks are familiar with operate
on an individual file basis. Subversion's atomic check-ins feature
doesn't lend itself to labeling individual files.
Therefore, IMHO, you will "never" be able to implement a traditional
labeling paradigm in SVN. Instead, SVN should pursue a baseline
paradigm, IMHO.
Defining what features are necessary to support a baseline paradigm is
left as an exercise to the reader. (Should checking in a set of files
that span multiple baselines be prohibited?)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2352625
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-21 19:44:04 CEST