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
Received on 2008-02-20 16:51:07 CET