On 1/16/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> 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'll leave this one alone, because i have very strong views in the
other direction, and it's not on the table yet, afaik.
> 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.)
Well, you can translate it. There is nothing about a binary diff
algorithm or svndiff1 that prevents you from only adding some subset
of changes. In the case above, you simply don't include line 20's
changes (which are at byte whatever of the file to byte whatever else)
in the delta stream.
Effectively, you pre-translate the file to exclude those changes, then delta it.
You can do this on the fly while sending the file to be delta'd,
assuming you have a list of lines you want to exclude.
Though it does require a lot more memory accesses than it did before :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 05:03:32 2007