On Aug 21, 2008, at 11:45, Robert Dailey wrote:
> To best explain what I have in mind, first let me begin with a
> scenario. Suppose there is a project that is currently in production,
> who's source code is in a subversion repository at
> svn://myserver/repo/project/trunk. All developers working on the
> project mostly work directly from trunk. However, in the case where a
> specific programmer wants to work on a very heavy feature that will
> take a week to complete, he/she makes a branch at
> svn://myserver/repo/project/branches/branch1. During the existence of
> 'branch1', several commits are made. For the purposes of this example,
> let's say there's a hefty list of 200 commits, each with a very
> extensive commit log explaining the purpose for each commit along with
> very explicit details on the changes included in the commit (bug
> fixes, features, refactoring, etc). When the feature is complete, now
> the programmer wants to merge "branch1" back to trunk.
>
> After merging the 200 revisions in the branch back into trunk, the
> programmer is ready to commit those changes. However, the programmer
> is faced with a very difficult task: creating a log message for the
> commit that contains the local modifications that was in the "branch1"
> branch. Ideally, this would be the concatenated list of history logs
> of all the 200 revisions made in the feature branch. However, since
> there is nothing to automate this task, the programmer simply says
> "This commit implements feature X______X ".
>
> A month later, we have progressed much further into the project and
> during that time a cleanup phase of the repository has happened.
> Amongst other things, this cleanup phase includes going through the
> branches for the project and deleting the ones that are no longer
> being used, which were branches for features already implemented and
> merged over. After this cleanup phase has happened, I am curious to
> see what specific changes were made in that new feature that was
> merged in a month ago from "branch1". Well, my first and most typical
> attempt at this is to "show log" on trunk. Well, this really doesn't
> give me much, as I simply see the arbitrary log message that the
> programmer merging in that feature provided that does not explain the
> details of the merge. As a second attempt, I look in the specific
> changes for that checkin, but I see nothing that tells me which
> location in the repository these files were merged from (As this would
> indeed be the case if there were no added or removed files, only
> modified).
The log message for the merge should state the name of the branch it
was merged from. That is, the developer should add this information
to the log message when performing the merge.
> I would then, as a third attempt, have to contact the
> programmer that implemented this feature and merged in the changes and
> ask him/her where the branch is located from which the changes came
> from. Assuming this programmer hasn't gotten hit by a bus, now I have
> another challenge. That branch was deleted a long time ago since it
> was no longer being used, so now I have to show log on "branches" and
> use cute search terms to try to find it again and then, you guessed
> it, I'm faced with doing more "show log" commands through TortoiseSVN.
Instead of deleting the branch, you can move it to an "old branches"
directory, so that it's still out of the way of normal day-to-day
use, but still easily available if you need to check its log. Keeping
the branch in an "old branches" directory takes absolutely no more
disk space than deleting it. If you have many branches, you can make
multiple "old branches" directories, e.g. by year or even by month.
> The point I'm trying to make here is that the process of figuring out
> the details of what happened during a feature branch from the
> perspective of the trunk (the merge target) is very tedious and
> difficult. In the example I previously gave, what I would have been
> really interested in is reading each of the commit log messages for
> each of the 200 commits made during that feature branch without too
> much effort. In other words, I would love for all 200 commit log
> messages in that feature branch to be concatenated and then made
> presentable, so it could be used as the commit log message in "trunk"
> where the entire contents of that feature branch will be committed to.
>
> As far as I know, there is no way to do this. There might be some cute
> hook somewhere that does this, but if so I have not found one. Perhaps
> there is a secret command line argument for this that I don't know
> about either. In the particular project I'm involved in, we have
> programmers that work out of branches on a daily basis (Not just for a
> particular drawn-out feature) and always merge changes to trunk from
> feature branch. So basically, our log message list for trunk is
> nothing more than "Merged in this" and "merged in that". It's very
> unreadable and unmanageable.
Hopefully your developers are writing more useful log messages than
just saying they merged in a branch; hopefully they're also saying
what those changes are meant to accomplish. For example: "Merged in
the bugfix-12345 branch which makes the widget no longer corrupt the
database when frobbed by the gonkulator." Since the branch was
hopefully to fix a single bug or implement a single feature (or set
of closely-related bugs or features) it should be possible to
described the combined change relatively succinctly.
> Until I find out that there is actually already a way of doing this,
> what I'm proposing here is a new feature. I don't care if it is an
> actual C++ implementation or a hook script, but I think it should be
> available to Subversion/TortoiseSVN by default. A feature to
> concatenate all of the log history of a branch that is being merged
> into trunk would be ideal, and would make the trunk a lot more
> readable and useful from the perspective of "show log".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-21 20:33:09 CEST