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
middle.
> 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.
+1
-K
---------------------------------------------------------------------
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