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

Re: Merging and history logs

From: Robert Dailey <rcdailey_at_gmail.com>
Date: Thu, 21 Aug 2008 11:53:07 -0500

On Thu, Aug 21, 2008 at 11:50 AM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> Robert Dailey wrote:
>> Hi everyone,
>>
>> I'm posting this to both the TortoiseSVN developer's mailing list as
>> well as the Subversion users mailing list because I feel this topic is
>> important enough that both communities may wish to express their
>> opinions on the matter.
>>
>> 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
>
> If your server is 1.5.x, it can (and will):
> enable the checkbox "include merged revisions", and the log dialog will
> then show you all the merged revisions too.
>
>> 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). I would then, as a third attempt, have to contact the
>
> You could use the revision graph: it will show you all the branches that
> were created and even in which revision they got removed.

Hah, you see, I figured this was easily solvable and would be
embarrassingly obvious! Thanks Stefan. Still trying to adjust to the
new features in 1.5. Sorry to have wasted everyone's time.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-08-21 18:53:36 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

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