On Mon, 2002-12-16 at 19:06, Tom Lord wrote:
> 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.
I thought your presentation of the idea was pretty complete. A design
helps to estimate how much effort it would take, and also helps to
clarify that I read what you wrote.
>> * Ignoring the merge history aspects, it feels like window dressing.
> "Feels", huh? Hmmm.
Four days ago, you said, "every week or so some detail goes by on the
svn dev list that strikes me as _wrong_". Is only one of us allowed to
talk about our gut feelings in response to a design idea?
> * 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.
How can a single piece of software be an existence proof of
interoperability?
> 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 referred to revision names as being "friendly names for the
changesets in question." That sounds like information to me.
> * 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.
With revision numbers, you can say that revisions 100-2000 of foo.c have
been merged into bar.c.
With revision names, you might say that revisions feature-foo through
bugfix-bar have been merged into bar.c, but a human will have no idea
whether docfix-baz is in that range or not. Postprocessing of the
history record might provide that information by asking the repository
those changesets came from, but postprocessing of revision numbers can
do the same thing.
Unless arch has magical powers, it can't display the individual
changeset names in a history record without either storing that
information close at hand, or asking for it when it is needed.
> 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.
Earlier today you complained about the "shameful tactic called 'pessimal
reading'", and yet here you are, rewording my argument into a circular
statement by reducing two separate antecedents into the same inspecific
noun ("this"/"it").
I did not say "nobody is planning to implement revision names, so it's
pointless to discuss whether we want revision names." I said, "nobody
is planning to implement merge history soon, and you presented revision
names as a prequisite for merge history, so it's pointless to discuss
whether we would want revision names in a merge history system."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 17 01:58:29 2002