On Tue, 2004-06-01 at 10:10, Julian Foad wrote:
> Probably I am failing to understand something about the meaning of
> the report information and how it interacts with the local
> information.
I'll explain in greater detail than you probably require.
The report communicates the state of the working copy (minus local
mods), which is used as the source of the comparison. It essentially
overlays s_entries, and sometimes t_entries as well.
For example, suppose I have a working copy at rev 5, except that (due to
a prior commit) foo.c is at rev 6. And, due to a switch operation,
bar.c is actually representing a different URL within the repository.
The report operations will look like:
set_path("", 5)
set_path("foo.c", 6)
link_path("bar.c", "other-url", 5)
What we used to do is construct a database transaction representing the
state of the working copy; we'd start with the anchor at rev 5, then
replace the foo.c dirent with rev 6 of that file, and then replace the
bar.c dirent with whatever other-url is at rev 5. Moreover, because
updates preserve switches, we'd also construct a database transaction
representing the target; we'd start with the anchor directory at rev
HEAD, and replace the bar.c dirent with whatever other-url is at rev
HEAD.
What we do now is dynamically overlay the source and target with the
report information (we now behave like "sed" rather than "ed"). We
still make the same comparisons as we would have made with the old code,
but we don't set up source and target transactions to do so.
+ /* Assume that for each report entry there is a corresponding target entry
+ (not sure about this), but not vice versa. */
Well, this is definitely not a good assumption. I don't know if it's
your only problem.
> If we can't get it right, then yes, we don't want a half-solution
> in the long term. What I was thinking is that this is all doable
> and should all be done in the long term, and seeing most output
> sorted now will show us how valuable it is and give us a bit more
> incentive to do the hard cases. I'll do some more work on the
> hard cases later.
I wouldn't be on that. Historically we're pretty good at punting hard
stuff unless it solves a big problem.
(So, -0 on checking in the easy stuff without solving the hard cases.
But not -1.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 2 03:30:25 2004