>
> > I think you are vastly overestimating the complexity of the existing
> > code. It's nothing more than an extra field in svn_entry_t, and
> > teaching some svn_client_* APIs to filter on that field. The "hard"
> > stuff -- like UI -- already rests squarely at the application level,
> > exactly where you think it should be.
> >
> > (Does the current commandline UI stink? Maybe? Then let's fix the
> > commandline client. Let's encourage TortoiseSVN to do something cool
> > and GUI-like. AFAICT, no client has been hindered here by the
> > existing code, only helped.)
>
> The issue is not that other clients are hindered, nor is it that the
> current library *code* is too complex. The issue is about APIs:
> every time we add something, we're stuck with it, and my instinct
> is that down the road we're going to regret these interfaces --
This is always true. you always regret doing something 5 or 10 years later.
That is why you only guarantee compatibility for as long as you can
stand to maintain the API.
:)
> "regret" in the sense that, as clients figure out what they really
> want from changelists, the APIs we added now will turn out to
> be slightly off from what's needed. Sure, we can add whatever
> the clients need later, and just have some old cruft in our APIs
> that no one uses. Small prices, paid repeatedly, add up, that's all.
This is our choice though. We control the price we pay, and how long we pay it.
>
> (I think your point about the library changes being really tiny cuts
> both ways. If they're small, then the benefits of supplying them
> for all clients can't be that large either.)
>
> Here's another concrete example of where I think the current libsvn_wc
> changes will fall down:
>
> The svn_wc_entry_t 'changelist' field is only meant to hold one changelist
> name. There's no way to compatibly store multiple changelist names
> in .svn/entries right now (so much for a general-purpose database). Yet
> overlapping changesets are surely in the future of this feature, especially
> when hunk-level selection gets implemented! And once people start doing
> stuff like that, even if we *could* keep all the information in .svn/entries, we
> probably wouldn't want to.
So you fix the small design and implementation issues. you don't rip
the whole thing out!
Do you believe this is a feature where there really is some
"laboratory of clients" that are going to try tings differently?
I don't.
Given enough time, I believe they are all going to come up with the
same interface, feature set, and maybe slightly different backends.
So why shouldn't we just short circuit this process and all the user
hassle that will result during the process of that happening?
If i actually believed there was really room for tons of innovation
here, i would probably lean towards your side of the argument. But
every implementation of changelists in a non-distributed VCS (what we
are referring to as changelists) seems to come to the same end so far.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 04:56:34 2007