Philip Martin philip@codematters.co.uk writes:
Branko ÄŒibej brane@xbc.nu writes:
I've just taken another look at the structure. I think we can record
this in the changes table, and we can glean the source and target paths
of the renames with the help of the txn-id stored in the change record.
I was considering having the change record look like
(change ID CHANGE-KIND [OTHER-PATH] TEXT-MOD PROP-MOD)
or
(change ID CHANGE-KIND TEXT-MOD PROP-MOD [OTHER-PATH])
where OTHER-PATH is present if CHANGE-KIND is a rename-add/delete/replace.
Is that sort of thing acceptable?
I'm wondering if this discussion isn't a bit premature. I'm thinking
that we might come up with a more informed approach after we clear the
iz #1003 hurdle. I'm not saying that any of the suggestions thus far
is bad or good -- just that we know that there is a likely to be a
forthcoming major schema change that touches all the areas that would
be touched by this change, too.
For example, I was thinking that we could avoid a schema change for
svn_fs_rename() by using information slots we (will) already have
(after 1003 goes in):
changes table: Add new rename change type.
nodes table: The committed-path tells you what the new path is.
the source-noderev-id points to the previous
incarnation, and that node's committed-path tells you
what the source path was. We know that this isn't a
copy because nothing was added to the copies table.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:08:37 2006