On 1/16/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> You're saying that the argument for factorization "doesn't apply as
> well" to this feature, and therefore we should do any factorization
> *at all*?
Well, not really. That's part of my argument, but not the whole
of it...
> To keep track of changelists, one needs to do some bookkeeping... just
> associate a name with a list of files. You're advocating that every
> single client app create some sort of private database to do this?
> But wait... we already *have* a database of sorts... the entries file!
> It's sitting right there, in front of every app. It's utterly
> trivial to store a label in an svn_entry_t.
>
> So that's exactly the API I wrote: (1) an API to add/remove a
> changelist label from a path (by adding/removing it from the
> underlying svn_entry_t). (2) an API to search the working copy for
> all paths matching a changelist. Basic database functionality,
> nothing more.
And really poor database functionality, from an indexing standpoint.
Even though users almost always deal with changesets by name,
SVN has to reach them backwards: to reconstruct changelist X,
we ask every file if it's in X, instead of asking X what files are in it!
In large working copies, this isn't great... :-)
> 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 --
"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.
(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, no, I don't think we're creating a good foundation for the future. If
we absolutely *must* provide library-level support, I wish we'd do it
in the configuration area code instead of libsvn_wc, so that we could
at least index changesets in a conceptually appropriate way, with both
proper performance and proper semantics.
I'm sorry to sound like such a spoil sport about it. I like the feature,
I just think you may be so close to the particular implementation you
did that its problems don't jump out at you. I hope the two concrete
criticisms above help clarify the point I'm trying to make.
-Karl
---------------------------------------------------------------------
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:36:05 2007