Tom Lord wrote:
> > If I understand what you mean here, Subversion doesn't
> > distinguish between "physical" and "logical" ancestry. But
> > I'm not sure i _do_ understand the difference.
>
>Usually, but not always, they are the same.
>
>Here is my theory. The theory which is mine [*]:
>
>When a programmer commits changes, two things are really going on
>(typically).
>
>First, the programmer is creating a "subsequent revision" in some
>workflow. "Here," the programmer says, "is the latest step in the
>development of our project".
>
>Second, the programmer is describing a coherent change -- a source to
>source transformation -- which might apply equally well to any of a
>potentially large number of loosely related revisions. "Anyone with
>roughly the same source tree I started with," the programmer says,
>"might want to make a change like this."
>
>The former is the logical ancestry path; the latter the physical.
>
Right, gotcha. What you describe as "logical" and "physical" ancestry is
what I like to call predecessors and contributors, respectively.
Contributors are revisions that contributed to a revision's _contents_;
the set of precedessors define how it evolved through time. Most of the
time -- in fact, I'd say all of the time in any practical system --
predecesors (or logical ancestors) are also contributors (physical
ancestors), but the reverse doesn't hold.
Or, to put it simply: the set of physical ancestors is what you'd want
to record as "merge history", while the set of logical ancestors is
"branch history". Correct?
In Subversion-speak, logical ancestors always belong to the same node
(or version-controlled object); physical ancestors may belong to several
(interacting?) nodes.
Hm. You know, we don't even have to invent terminology and notation for
these concepts -- they were invented 40 years ago for describing
particle interactions. We can just use Feynman diagrams. :-)
>In small projects and closed shops, logical ancestry is all that
>matters. In large projects and open source processes, the latter is
>critically important.
>
>
> > And we don't record anything else right now, not even simple merge
> > history. Unfortunarely.
>
>Well, arch records these things -- but doesn't handle divergent
>physical and logical ancestry as well as it should. It does a very
>good job of treating branches as such a divergence -- but if you
>introduce a revision in the middle of a line of development whose
>physical ancestry isn't identical with it's logical ancestry, some of
>the merge operators can get confused. That's a bug.
>
By "not identical", do you mean that physical ancestry does not include
logical ancestors? Because I find it hard to imagine a real-life
situation where this case would be useful.
(Yes, I realize that, for completness' sake, a mathematical model of
revision control has to describe these edge cases; but we dirty
physicists are taught to take a mathematical model, then ignore the
impossible solutions. It makes life much easier.)
> > Ah! I finally understand what you're getting at WRT patch
> > formats! It becomes clear now that you've put it in
> > context. I never could understand why you thought that
> > desigining a general patch format could be the first step --
> > now I understand that you assume that a patch would include
> > _all_ history metadata, not just "copies, moves and context
> > diffs".
>
>
>The metadata is only one aspect of changesets that I wish the svn team
>would focus on. There are other issues, too. One example of an
>"other issue" is the semantics of tree rearrangements during inexact
>patching (patching an original tree that doesn't precisely match the
>original).
>
>Overall, the reason to focus on patch sets is because they are the
>unit of exchange between people working on non-fragmented forks of a
>common source base -- as between upstream and downstream hackers
>(e.g. linux v. cox) or, in the future, peer forks (HP/C vs. IBM
>vs. Suse vs. Red Hat). A project tree is a base revision plus a list
>of patches. Many programmers, especially those working in tactical
>and custodial modes (as opposed to strategic aka exploratory R&D
>modes) produce changesets more often than they produce programs.
>
>
>
> > Of course, the problem still remains that you have to have a
> > pretty complete, generic revision management model upon
> > which to base the patch format
>
>Abstract model, yes. That still leaves tons of room for
>implementation variations. The model ain't, for the most part, a
>fashion statement -- it's largely determined by math.
>
Of course abstract model. I didn't mean to imply otherwise.
> For that
>reason, the (paraphrased) "it's, at most, a post 1.0 issue" strikes me
>as Missing The Point.
>
Actually, what we said was more along the lines of "we don't have time
now, but would love to discuss this post-1.0". But whatever.
> > -- including methods for gracefully downgrading or simulating missing
> > features of the target system.
>
>Or you could take my approach and rag on the relevent development
>teams until they wake up and decide they could use your help to avoid
>producing a target system with missing features. :-) / 2
>
I'm afraid that won't work. Of course it would be "best" if all systems
were full-featured in this respect, but that's not something you can
reasonably expect to achieve. When it comes to real-life projects, all
sorts of factors affect design goals and priorities. For example, I'd be
quite scared if a versionaing file system's design focused on efficient
repository distribution instead of fast FS-related operations.
>I don't claim to be a svn expert. There are some aspects that seem
>clearly wrong to me, mostly apparently resulting from it's goal of
>being CVS-like. I really like the idea of a storage manager that
>looks like a file system with cheap tree cloning -- I'm dubious about
>the particular implementation and constraint of Windows compatibility.
>
>
See, that's one of those "all sorts ot factors": in order for Subversion
to make sense, it has to run on the vast majority of the machines out
there. That automatically includes Unix and Windows (and Mac, but we can
live with requiring OS X, which is Unix anyway).
Although I would hesitate to call Windows compatibility a constraint --
it might well be the other way around :-) (/me dons asbesthos suit)
--
Brane Čibej <brane_at_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
Received on Fri Oct 11 00:00:56 2002