On 1/17/07, Jonathan Gilbert <o2w9gs702@sneakemail.com> wrote:
> Why not change the current API, which does "set changelist for file X to
> Y", into two functions: "add file X to changelist Y" and "remove file X
> from changelist Y"? The current implementation would simply return an error
> when trying to add a file that is already in one changelist to another one,
> but it leaves the door open for changes to the way the data is actually
> stored.
>
> Similarly, while certain operations naturally strobe all of the files
> anyway as part of their normal processing and thus have virtually no
> overhead in asking each file X if it is a part of changelist Y, it's
> certainly true that some operations would like to be able to enumerate the
> files specific to a changelist as quickly as possible. If a function is
> added to the API to "list all files that are part of changelist Y", it can
> be initially implemented as a recursive scan, the way it currently has to
> be done anyway, but then applications that are built using it will
> automatically experience a performance gain if/when the database structure
> is reworked.
>
> By designing the API carefully, the back-end implementation details can be
> completely masked, and the door kept open for changing the implementation
> to better support the end goal feature set. Isn't that one of the main
> goals of putting implementation into a library? :-) (the other one being
> reusability)
I think Jonathan's recommendation is the best course at this point. Let's
rework the API as though we had an ideal database-ish interface for
storing changelist information, and (for now) just implement that API
in libsvn_wc in a somewhat non-optimal way. Unfortunately, when I
say "Let's", I really mean "Someone else please" :-)... I'd like to concentrate
on sparse directories for now. I will, however, watch the new API if
someone does this, and make any comments up front instead of months
later.
Sorry that I didn't say something about this when you were writing the code,
Ben -- I was busy getting settled into a new city and new job and not able
to follow dev@ carefully then. I knew you were working on the feature, but
I didn't have time to look at the actual commits.
To Justin: my sense is that most people are ready to give up on
severable & relocatable (with just 'mv') working copies now, the
costs are starting to outweigh the benefits. But I agree, we don't
need to open that can of worms right now.
To Dan Berlin: Stellation (IIRC) implemented hunk-level changelists.
It's not so blue-sky as all that. As I described, it's a client interface
job for the most part: it could be implemented *today* over Subversion
without changing a line of code and without using any of the new
changelist APIs. Indeed, maybe Subclipse will take that tack eventually.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 23:01:14 2007