[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: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2003-04-11 22:48:58 CEST

Branko Čibej <brane@xbc.nu> writes:
> I'd agree with this, although note that revision numbers aren't fixed
> width, so your argument about columns doesn't hold. But getting rid of
> the "@" is a good thing.

Oh, I didn't mean that they were fixed width, merely that the
alignment would be better this way (on average) than with paths in the

> I don't entirely agree with this. First of all, you can't determine
> branch relatedness from looking at the path (because of moves and
> renames); you /can/ -- or will be able to once the fs schema changes are
> in -- from the node change key. This might be important for performance
> in large merges.
> I'd really have to read through Bill Tutt's latest description of
> copy/branch semantics and copy ID generation again. Brrrr.

Include both, then: [UUID]:REV[-REV]:[NODECHANGE-KEY]:PATH

But let's not lose that path; people can use it.

> > (And if this was the only purpose of that table, that in itself
> > is no argument for using indices in the property.)
> >
> 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.

> As long as bugs in this feature don't hold up 1.0, as Brian said.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 11 23:32:19 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.