On Tue, Jan 16, 2007 at 09:15:55PM -0600, Karl Fogel wrote:
> 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 don't think it's quite that bad - plus we have loads of other issues with
large-scale working copies anyway. (Let's start with optional text bases
if you want to start the laundry list of what's wrong with large WCs.)
I am also very much against losing shareable/severable working copies. So,
I'm largely against binding WC features inside of ~/.subversion etc. But,
that's not on the table yet...or is 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.)
My take is that if it's at the 'right' layer, it's often a lot simpler.
> 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.
I honestly don't see the use case for overlapping changesets yet. Plus, I
think hunk-level selection is so far a very green-field feature that hasn't
been paid much attention yet. I think we're going to have *lots* of issues
if we want to partially commit a file. How do we even know what chunk to
give? Our streams are all binary - but that's often of little benefit to
the user. The user would want to commit the changes on line 10, but not on
line 20. How does that translate? (I don't think it can with svndiff1 on
first glance.)
> 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 think we evolve it at a later time if and when someone wants to support
overlapping change sets. Until then, I'm happy for the feature to stay
as-is. If and when patches emerge, then we deal with it. But, trying to
revert working (and useful) code because it might conflict with something
later (that hasn't even been designed or thought through on-list) seems
like we're putting the cart before the horse. -- justin
---------------------------------------------------------------------
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:49:39 2007