[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: <rassilon_at_lyra.org>
Date: 2003-01-23 01:04:19 CET

 From: Philip Martin [mailto:philip@codematters.co.uk]
 
 Bill Tutt rassilon@lyra.org writes:
 
   Ahh, we do need to store a rename flag after all :) So
   where would the extra path go? In a new renames table? In
   the existing changes table?
  
  Before you figure exactly what data you want to store where
 be sure to
  check out the diff between the #1003 branch and the trunk for the
  libsvn_fs/structure file. It will show you the schema
 changes between
  the two branches.
 
 Eeekk! The nightmare branch, where every file differs.
 Well, at least the important files were automatically corrected.
 
 The issue says it's ready to go, so what's the plan? Is it
 blocking on a review? Is it the schema change that's the
 problem? I don't know enough about the fs code to review it,
 but I guess I can test it.
 

As far as I know noone has reviewed the last set of changes. Cmike
should check it out. The schema change was the big reason the change
wasn't committed to the trunk. (and good thing too, eh? :) )

Here's the list of altered files on the branch though:
subversion/include/svn_fs.h
subversion/libsvn_fs/tree.c
subversion/libsvn_fs/fs.h
subversion/libsvn_fs/txn.h
subversion/libsvn_fs/structure
subversion/libsvn_fs/dag.h
subversion/libsvn_fs/dag.c
subversion/libsvn_fs/bdb/changes-table.c
subversion/libsvn_fs/util/fs_skels.c
subversion/tests/libsvn_fs/fs-test.c
subversion/tests/libsvn_fs/changes-test.c

FYI,
Bill

---------------------------------------------------------------------
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:07:42 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.