> So let me ask my question a different way. How can you audit
> all the changes that have gone on in a file if it's been
> copied and returned back to the trunk? I mean, one question I
> always have to ask in a repository is when was this line of
> code changed? How do you even know where all the copies of an
> object are/were?
In order to find the change to a specific line of code: 'svn blame'. Find
the line, note the revision number. "svn log" the file, find the revision
number. If the log message indicates merging, look at the URL and revision
number(s) mentioned in the commit log for the merge to see more detail.
Remember that Subversion repositories suffer ZERO data loss, and even if the
branch is no longer "present" on the HEAD, you can still see it by
specifying revision number.
The above is a way that works well under the current subversion
capabilities. It does require a bit of careful bookkeeping on the part of
the users, especially those who handle the merging. (See also
Under the still-hypothetical merge-tracking support, I suspect one or more
of these steps would become unnecessary.
In the system we've set up here at our office, production code is on the
trunk. Each task (internal, or client-requested) gets its own branch and
must go through a thorough code review at the end of its development cycle,
while it's still in the branch. When it comes time to release the change,
if the trunk is still older than the revision at which the branch was
created, the branch is simply moved on top of the trunk. If the trunk is
newer, the range of changes on the trunk between branch creation and now
gets merged onto the branch, and the branch gets kicked back to regression
testing and needs another code review. So, the upshot is that the
"auditing" of changes is happening constantly and on a task-by-task basis.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Jul 29 22:00:09 2004