Karl Fogel wrote:
>Sander,
>
>I like the proposal! A few comments -- I've read the whole thread up
>to this point, so some of this is really in response to subsequent
>discussion:
>
> 1. Instead of [UUID::]PATH@REV[:REV], how about [UUID]:REV[-REV]:PATH ?
> That way, we keep all the fixed-format stuff up front, and the
> most variant component (the path, which might even contain "@")
> always comes after the second colon. Easier to parse, and also
> probably easier to read when lined up in a column. You may
> laugh, but such things make a difference :-).
>
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.
> Using a hyphen to indicate revision ranges seems more readable,
> and (in this format) would be easier to parse anyway.
>
Oh hah. I'll start putting together a thesaurus of the various colours,
shades and patterns we've painted our bikesheds in on this project. :-)
> 2. Please let's not add levels of indirection :-). No matter how
> smart we try to be, sometimes humans will have to read, and
> perhaps even edit, these properties. So let's use paths, not
> node-ids; and use real UUIDS -- even though they're longer --
> rather than indices into some particular repository's `uuids'
> table.
>
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.
> (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.
> 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.
> 3. Regarding the question of whether to store the property on
> files/dirs unaffected by the merge, my instinct is not to.
>
I agree, but...
> To get a feel for this, I tried reasoning about an extreme case:
> you do a merge and absolutely no files are affected. In that
> case, it would be equally correct to store no properties, or to
> store a property on every file indicating that the merge was
> done. But in the latter case, we'd really be recording the mere
> fact that someone had typed 'svn merge'. The merge would have
> had no real-world consequence at all, and yet all these
> properties would change. This seems inconsistent with other
> Subversion operations, where if they do nothing, then no change
> is recorded in the repository. Also, it would use up space for
> no reason :-).
>
... recording a no-op merge still has valid use cases. I'm not saying we
should do that by default, but we should allow it.
>That's all. Frankly, I'd be +1 on this going in right now, as long as
>it starts out experimental (i.e., a flag to merge, that later can
>become the default).
>
As long as bugs in this feature don't hold up 1.0, as Brian said.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 11 22:44:17 2003