subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From B Smith-Mannschott <>
Subject need heuristic to order the application of path elements a'la svn log --xml --verbose
Date Sun, 28 Mar 2010 09:05:50 GMT
svn log --xml --verbose emits <logentry> elements, each of which
contains a number of <path> elements describing the changes made in
that revision:


My difficulty, is that these path entries seem to come in arbitrary
order, and it's not clear to to me how to efficiently reorder them
such that they may be applied to a graph representing the previous
revision's state to produce the expected state of this revision.

- Top to bottom can't be right because that has us adding
".../example/courts/model" before we have added ".../example".
- Bottom-to-top can't be right because that has us adding
".../model/" before we've added
- Start at the leaves and work up, is wrong for Add.
- Start at the root and work down is wrong for Delete
(Not shown here, but I've seen examples that boil down to this:
<path action="D">/foo/bar"</path>
<path action="D">/foo/bar/baz"</path>

I've run into this question because I'm hacking on a little project in
Clojure which sucks in an svn-log.xml, attempting to replay the
structural changes described by the log into a history of the
repository represented as a vector (indexed by revision number) of
hash-maps. Directories become nested hash maps. Files just map a name
to 'true' (for lack of anything better).

;;; r0
;;; r1
{"trunk" {"src" {"com" {"example" {"" true}}}},
 "tags" {},
 "branches" {}}

My aim, such as it is, is to have a more efficient way than svn ls -R
to know which file names are currently in use in the repository. It's
also just a nice example to hack on.

I've tried a few different approaches, none satisfactory. My most
recent attempt is brute-force recursive backtracking, but this blows
the stack as soon as a revision with a few thousand changes shows up.
Before I invest the time to rewrite things to remove the recursion and
manage the stack explicitly as a list, I'd like to make sure I'm not
Doing It Wrong. Maybe there's some obvious heuristic I'm missing?

// Ben

View raw message