You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Emin.shopper Martinian.shopper" <em...@gmail.com> on 2008/01/24 19:32:18 UTC
preserving branch log messages when merging into trunk
Dear Experts,
Is there a way to preserve branch log messages when merging back into trunk?
Imagine that I make a branch called foo, do lots of commits on lots of
different files in foo, and then want to merge foo back into trunk. It
seems like I have two choices.
(1) Merge each file of foo separately. This is nice because I can use
the per file log messages from foo when merging back into the trunk.
That way further developers on trunk see the log messages from the
branch. The problem is that it loses the concept of the entire
changeset.
(2) Do the merge with a single commit. This is nice because it treats
all the changes as one changeset. But it has the disadvantage of
requiring a single log message for the entire commit.
Ideally, I'd like the advantages of (1) and (2). Is there a good way
to do that?
Thanks,
-Emin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: preserving branch log messages when merging into trunk
Posted by Blair Zajac <bl...@orcaware.com>.
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
<bl...@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
> <em...@gmail.com> wrote:
>> On Jan 25, 2008 11:30 AM, Blair Zajac <bl...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: preserving branch log messages when merging into trunk
Posted by "Emin.shopper Martinian.shopper" <em...@gmail.com>.
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
<em...@gmail.com> wrote:
> On Jan 25, 2008 11:30 AM, Blair Zajac <bl...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: preserving branch log messages when merging into trunk
Posted by "Emin.shopper Martinian.shopper" <em...@gmail.com>.
On Jan 25, 2008 11:30 AM, Blair Zajac <bl...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: preserving branch log messages when merging into trunk
Posted by Blair Zajac <bl...@orcaware.com>.
Emin.shopper Martinian.shopper wrote:
> On Jan 24, 2008 3:03 PM, Blair Zajac <bl...@orcaware.com> wrote:
>>
>> If you use svnmerge.py to manage your merges, for (2), you'll have a single
>> commit with a single log message containing the concatenation of the log
>> messages that went into the merge.
>
> Thanks for pointing that out, but that's not quite what I want.
> Imagine I have hundreds of commits on the branch (after all the whole
> point of the branch is to be able to commit before merging into
> trunk). Then if the log for each file gets merged into one gigantic
> log that gets used for the merge, looking at post-merge logs will be
> extremely painful.
>
> Currently we have a script that pulls out the log messages for each
> file on the branch and separately merges each file with the
> appropriate log messages, but this loses the concept of the whole
> changeset.
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.
With svnmerge.py, you merge whole revisions over, not just single files.
As practice, also, using per-revision merging is better then
per-revision-and-per-file merging, at least until 1.5, when it can do
merge-tracking on the per file basis. If you use svnmerge.py, it'll do
merge-tracking on revisisions
Blair
--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: preserving branch log messages when merging into trunk
Posted by "Emin.shopper Martinian.shopper" <em...@gmail.com>.
On Jan 24, 2008 3:03 PM, Blair Zajac <bl...@orcaware.com> wrote:
>
>
> If you use svnmerge.py to manage your merges, for (2), you'll have a single
> commit with a single log message containing the concatenation of the log
> messages that went into the merge.
Thanks for pointing that out, but that's not quite what I want.
Imagine I have hundreds of commits on the branch (after all the whole
point of the branch is to be able to commit before merging into
trunk). Then if the log for each file gets merged into one gigantic
log that gets used for the merge, looking at post-merge logs will be
extremely painful.
Currently we have a script that pulls out the log messages for each
file on the branch and separately merges each file with the
appropriate log messages, but this loses the concept of the whole
changeset.
Thanks for your response,
-Emin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: preserving branch log messages when merging into trunk
Posted by Blair Zajac <bl...@orcaware.com>.
Emin.shopper Martinian.shopper wrote:
> Dear Experts,
>
> Is there a way to preserve branch log messages when merging back into trunk?
>
> Imagine that I make a branch called foo, do lots of commits on lots of
> different files in foo, and then want to merge foo back into trunk. It
> seems like I have two choices.
>
> (1) Merge each file of foo separately. This is nice because I can use
> the per file log messages from foo when merging back into the trunk.
> That way further developers on trunk see the log messages from the
> branch. The problem is that it loses the concept of the entire
> changeset.
>
> (2) Do the merge with a single commit. This is nice because it treats
> all the changes as one changeset. But it has the disadvantage of
> requiring a single log message for the entire commit.
>
> Ideally, I'd like the advantages of (1) and (2). Is there a good way
> to do that?
If you use svnmerge.py to manage your merges, for (2), you'll have a single
commit with a single log message containing the concatenation of the log
messages that went into the merge.
http://www.orcaware.com/svn/wiki/Svnmerge.py
Regards,
Blair
--
Blair Zajac, Ph.D.
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org