"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > brian m. carlson (6): > vcs-svn: remove unused prototypes > vcs-svn: rename repo functions to "svn_repo" > setup: expose enumerated repo info > Add structure representing hash algorithm > Integrate hash algorithm support with repo setup > Switch empty tree and blob lookups to use hash abstraction The first two are about very quiescent code that can go in and sail thru 'next' very quickly without problems, I would think. After the third one alone, the discovered format information may not be fully plumbed through (i.e. after setup finishes there is no way for outside callers to peek at the repo_fmt instance that was on stack), but it seems that this is sufficient for the purpose of this step and it looks a very sensible first step., As to patch 4, I tend to agree with the analysis you had in this cover letter--it did make me wonder if we want to have union of hash contenxt structures, for example. But the enumeration of virtual functions looks about right. I wondered if we wanted "binery size" and "hex size" separately, because the latter will always be twice as big as the former as long as the latter's definition is "hex", but that is a minor point. Thanks for starting this. > builtin/am.c | 2 +- > builtin/checkout.c | 2 +- > builtin/diff.c | 2 +- > builtin/pull.c | 2 +- > cache.h | 48 ++++++++++++++++++++++++++++++++++++++++++++---- > diff-lib.c | 2 +- > merge-recursive.c | 2 +- > notes-merge.c | 2 +- > repository.c | 7 +++++++ > repository.h | 5 +++++ > sequencer.c | 6 +++--- > setup.c | 48 +++++++++++++++++++++++++++--------------------- > sha1_file.c | 29 +++++++++++++++++++++++++++++ > submodule.c | 2 +- > vcs-svn/repo_tree.c | 6 +++--- > vcs-svn/repo_tree.h | 13 +++---------- > vcs-svn/svndump.c | 8 ++++---- > 17 files changed, 133 insertions(+), 53 deletions(-)
