Re: preserving branch log messages when merging into trunk

I don't know what problem you're trying to solve here. It sounds like you have
an odd process that this is even an issue.

Each commit into svn should be one logical change. If you are doing multiple
logical changes in the same commit, then I can see unwanted log messages in the
merge for a file. Since each commit is one logical change and may touch more
than one file, seeing the comments on different files for changes in the same
commits isn't that big an issue.

What you're proposing will not be in 1.5, nor do I see a case for it being
implemented in the future.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair_at_orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
Emin.shopper Martinian.shopper wrote:
> I'm curious about whether the following idea makes sense for
> preserving per file logs while still allowing committing of
> changesets:
> 
> 1. Create a new svn property called CHANGELOG for each file. Whenever
> you want to note changes for a particular file, you insert the log
> message at the top of this property for the file.
> 2. Whenever a commit occurs, the log message for the commit
> automatically gets inserted at the top of the CHANGELOG property.
> 3. Tools that want to manage merging, can use the CHANGELOG property
> for per file merge tracking. For example, if a tool is merging files X
> and Y from branch B into trunk, it can get the messages in the
> CHANGELOG for X and add these to the CHANGELOG for X in trunk. It can
> then do the same for Y. Finally, it can commit both X and Y as a
> single changeset possibly with a single log message that applies to
> the whole changeset.
> 
> An important advantage of this over the current behavior is that it
> lets you preserve log messages for each file in a branch. In contrast,
> the current behavior of SVN and svnmerge.py essentially mash all the
> log messages from each file involved in a merge into one gigantic log
> message.
> 
> I think this would be very useful, but I'd like to know what other people think.
> 
> Thanks,
> -Emin
> 
> On Fri, Jan 25, 2008 at 3:46 PM, Emin.shopper Martinian.shopper
> <emin.shopper_at_gmail.com> wrote:
>> On Jan 25, 2008 11:30 AM, Blair Zajac <blair_at_orcaware.com> wrote:
>>  >
>>  > What you're doing will be the same volume of log messages as what I'm suggesting.
>>  >
>>  > With svnmerge.py you won't end up with N*M copies of log messages, where N =
>>  > number of revisions merged into trunk and M = number of files.  You'll only end
>>  > up with N in the merged commit message.
>>
>>  Thanks, I understand that part. I'm not concerned about the volume of
>>  log messages, I'm concerned about the usefulness of log messages.
>>  Specifically, at some point after the merge, I'd like to be able to
>>  look at the log for file XXX and see the commit messages just for XXX
>>  instead of the log messages for every single file that was involved in
>>  the previous merge.
>>
>>
>>  > As practice, also, using per-revision merging is better then
>>  > per-revision-and-per-file merging,
>>
>>  I generally agree except that it either loses the individual log
>>  messages for a file in favor of the per-revision log message or it
>>  bloats the log message for a file with the log message for all the
>>  other files in the merge.
>>
>>
>>  > at least until 1.5, when it can do merge-tracking on the per file basis.
>>
>>  OK, it sounds like the answer is to wait until 1.5 and see if that
>>  improves things.
>>
>>  Thanks for taking the time to respond.
>>
>>  -Emin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org