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

Re: [PATCH] Issue 898 atomic rename, implement svn_fs_rename

From: <cmpilato_at_collab.net>
Date: 2003-01-23 04:50:13 CET

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
 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

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.