On Wed June 16 2004 06:19 am, kfogel@collab.net wrote:
> "Scott L. Burson" <Scott@solidcore.com> writes:
> > Of course you don't want to be locked into maintaining poorly-thought-out
> > functionality. On the other hand, I don't see how that locking in would
> > happen in this case; my proposal seems to me to be a user interface
> > enhancement, not a change to an API or protocol.
>
> Any part of the user interface is like an API change, in that once we
> add it, we must support it forever (or a very long time, anyway). The
> UI is a protocol. It is the protocol by which users communicate with
> Subversion, in the same way that the network protocols are the way the
> clients interact with servers. Once we support something in the user
> protocol, we can't just drop it later if we decide we don't like it.
"User protocol"? I think that's a bit of a stretch. Users get attached to
functionality; they don't get so attached to the form in which that
functionality is presented -- not nearly as attached, anyway, as code gets to
protocols.
To put that in terms of this discussion, I agree that once Subversion has a
feature that records and reports merge information, it will always need to
have a feature that does that. You couldn't just remove the feature without
replacing it. But you _could_ replace it with something better, even if the
information were presented or accessed in a different way. Users will deal
with that. You could even replace it with something merely equivalent, if,
say, the original implementation turned out to have undesirable implications
for the rest of the code; users may grumble a little if they have to change
their habits and get no benefit in return, but they will still deal with it.
None of this is to say that the initial UI design doesn't matter, and indeed
if anyone has a better idea, please speak up. I just suggested appending the
information to the log message because I thought it would be an easy place to
find it and that this would probably be easy to implement.
> I think this might be easier to talk about if you made a detailed
> proposal. What would the property name be, under exactly what
> circumstances would it be set and on what targets, how exactly would
> it behave w.r.t. the log message, how would it interact with things
> like 'svn commit -m "foo"', and so on?
Fair enough. And it occurs to me that maybe we can meet in the middle here to
some extent. I can certainly see the point of taking the time to design an
internal representation that everyone agrees captures all the information we
can imagine needing for whatever analyses anyone might eventually want to
implement. Given that, perhaps we can agree to move forward with a simple,
easily implemented presentation of that information, and leave the more
elaborate analyses and presentations for the future.
So, let me think about this for a few days and make a more detailed proposal
(suggestions are certainly invited).
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 18 00:38:35 2004