On Thu, Jul 29, 2004 at 10:22:48PM -0500, Ben Collins-Sussman wrote:
> One of two things *must* be true:
>
> 1. the buggy change happened on the trunk, or
>
> 2. the buggy change happened on a branch, then the change was ported
> to the trunk.
>
> When you run 'svn log /trunk/foo.c', you see every change that ever
> happened to the trunk-line of foo.c.
>
> If #1 is true, then the log will include the buggy change.
>
> If #2 is true, then nothing is different: the log will *still* show the
> buggy change. The change will simply have more history behind it,
> history that (if you wish) can trace back to a branch.
In some cases, the log will show nothing more than a whole lot of
successive merges. Obviously if you've put useful information about the
merge in your commit log message, you'll be able to track down where the
actual development happened, and check those logs, but you cannot
(currently) do this automatically.
In other words, you can obtain the "branching history" of an object
automatically, because of the shared history prior to branching, but
you cannot obtain the "merging history" automatically. Of course, the
parallel is not exact, because merging is really a working copy
operation and not a repository operation; you can't do merges
automatically, because usually further changes are needed to make
everything "work" after a merge, even if there aren't any merge
conflicts.
Still, it would be nice to see where the data used in a merge operation
came from logically, even if the physical data present in the file after
the change is not identical to either of the ancestors used in the merge
operation. If I understand correctly, svn 1.1 will be equipped to deal
with this kind of merge tracking.
--
Tristan Seligmann
Software Engineer / Network Administrator
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 30 10:45:33 2004