> (a) the (much reduced) performance limitation:
I'm not sure how your hypothetical distributed repository is
going to determine that transactions are non-overlapping more
cheaply than it can settle revision numbers. But you've
admitted this is a small issue.
They can decide in advance by tentatively partioning regions of the
repository among themselves, coordinating synchronously only as a
fallback for txns that span the tentative boundaries.
The performance issue is small for source code managment. It isn't a
small issue for other quite plausible and valuable applications of
FSDB-style technology.
> So, I think that both the intra-repository and global
> revision names for merging purposes should not be based on
> revnum, but on an independent, higher-level namespace.
Well, here's how I think we'd implement this if we were going to:
Already, I think you're off on the wrong foot. The namespace is
useful to tools adjacent to revision control, not just revision
control itself. It is something that can have and plausibly deserves
a "stand alone" design -- independent of revision control technology.
The first question isn't "how do we implement it?", but "what is the
form and function of this namespace? -- what is it exactly?" You
can't really figure out how to implement it until you understand in a
deeper way what it is.
I don't really like this idea because:
* Ignoring the merge history aspects, it feels like window
dressing.
"Feels", huh? Hmmm.
* I don't really buy that smart merging between different pieces
of revision control software is a realistic or desirable goal.
arch is an existence proof that it's realistic. Read the recent
project-administrative messages on gcc list (and think about them) to
begin to get a sense of why it's desirable. Linux kernel development
also provides some relevant development patterns.
And even if it does come about, using numbers doesn't mean we
can't interoperate; it just means that our revision names are
less informative.
That statement makes presumptions about the namespace and how it is
best used that are, if not false, at least completely unsupported.
* You can no longer compress merge history using revision ranges (or
if you do, you lose the benefit of making the merge history
readable).
No, you are mistaken. arch can and does compress merge history while
maintaining a readable record. You can ask, of a combined merge, "what
individuals changes are combined here?". Smart-merging, not just
human readers, make use of that information.
I'm already concerned about the bulk of merge history information given
that we may get stuck storing it for each file.
Well then, that's something to figure out for sure then, isn't it?
At any rate, it's most likely pointless to try to design a merge
history system right now, given that no one is planning to
implement it in the immediate future (as far as I know). So
this conversation probably shouldn't go on too much longer.
In other words: "It isn't worth considering whether or not this is
worth planning for because nobody is currently planning for it."
Interesting.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 17 00:55:25 2002