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

need heuristic to order the application of path elements a'la svn log --xml --verbose

From: B Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Sun, 28 Mar 2010 11:05:50 +0200

svn log --xml --verbose emits <logentry> elements, each of which
contains a number of <path> elements describing the changes made in
that revision:

...
<path
   kind="dir"
   action="A">/trunk/src/com/example/courts/model</path>
<path
   kind="dir"
   action="A">/trunk/src/com/example</path>
<path
   kind="file"
   action="A">/trunk/src/com/example/courts/model/CourtsObject.java</path>
...

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/CourtsObject.java" before we've added
.../example/courts/model".
- 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" {"Foo.java" 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
Received on 2010-03-28 11:06:25 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.