> 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.
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.
> 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. For that
reason, the (paraphrased) "it's, at most, a post 1.0 issue" strikes me
as Missing The Point.
> -- 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
> WHAT IS REVISION CONTROL?
> [....]
> That's one of the more beautiful definitions I've seen to date.
Thank you.
>> If you want to say that svn is not "a true changeset
>> system", I think the reason would have to do with the
>> not-done-yet history sensitivity features and corresponding
>> delta-patch/merge operators --- not because of the storage
>> manager's general representation strategy.
>Of course, that doesn't mean that adding changeset management
>will not result in modifications to the storaga manager, for
>reasons of efficiency.
Perhaps so, especially if you are correct when you say:
> Subversion doesn't distinguish between "physical" and
> "logical" ancestry.
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.
-t
[*]: A reference to monty python -- not an instance of my unbridled
arrogance -- in case you don't happen to recognize the reference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 10 09:45:30 2002