[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [PROPOSAL] Merging Improved

From: Sander Striker <striker_at_apache.org>
Date: 2003-04-12 00:10:49 CEST

> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: Friday, April 11, 2003 10:49 PM

>> No, but clarity is. If we're talking human-readable, imagine trying to
>> compare 40 chars of UUID vs. 1 or 2 chars of index.
> Humans are good at ignoring anything that's fixed width. Some humans
> will learn to recognize certain repository signatures, if we don't get
> in their way...
>>> The more self-contained and repository-independent this
>>> information is, the less trouble we'll have down the road. The
>>> points about dump/load cycles are just one of many problems that
>>> could result if we don't store the information in its most
>>> basic, canonical form, imho.
>> Perhaps. And "premature optimization is the root of all evil," etc. But
>> I'd like to understand the issues better before deciding one way or another.
> Absolutely. If there's some compelling reason to index them in the
> property, then that's fine. All I really meant to say is, let's not
> optimize this just for the sake of space savings.

Ah, but it isn't to save space. It is to prevent a rewrite of all
svn:merged-from properties when a remote repository UUID changes.
Using the indexed method the rewrite to the new UUID would be one row
change in a table...


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 12 00:11:35 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.