Why not make svn log and svn commit consistent with svn merge?
From the manual:
$ svn merge --reintegrate http://svn.example.com/repos/calc/branches/my-calc-branch
--- Merging differences between repository URLs into '.':
U button.c
U integer.c
U Makefile
U .
Note that properties are in the second column while the file changes are in the first column. That way, a log, diff or commit could indicate the difference between the type of change. I notice that subclipse does show a graphical difference on commit.
Thank you,
Chuck Holzwarth
Independent IT Consultant
(804) 403-3478 (home)
(804) 305-4040 (cell)
________________________________
From: Stefan Sperling <stsp_at_elego.de>
To: Chuck Holzwarth <chuck_holzwarth_at_yahoo.com>
Cc: users_at_subversion.tigris.org
Sent: Wednesday, February 18, 2009 6:59:41 AM
Subject: Re: Merge report issue in subversion 1.5
On Tue, Feb 17, 2009 at 01:53:31PM -0800, Chuck Holzwarth wrote:
>
> The company where I am working has implemented subversion 1.5.4. There
You should upgrade to 1.5.5 ASAP. I contains some fixes for these problems.
> are a lot of complaints from developers about issues. One of the main
> issues is about merging. I have been looking over their shoulders when
> they merge and the issues are more user interface issues than actual
> functionality issues.
Yes.
> Has anyone considered making the reporting of mergeinfo property
> changes optional or breaking them out into a separate category?
It has been brought up. Using properties to store mergeinfo has
this side effect. If we didn't show it by default, people might end
up not committing it along with their own changes, even though they
should commit it.
I am not aware of any concrete plans to change the way mergeinfo is
stored.
> I watched as a developer merged the trunk to his working branch and saw
> two files change, where the content of the file changed. When the
> commit was queued, it showed many files. All except two of the files
> were where the property changed. I tried with both Tortoise and
> subclipse and was unable to discern the files where the content
> changed from the files where the property changed.
You have accumulated "subtree mergeinfo", or "explicit mergeinfo.
See here for an explanation:
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
You may want all your developers doing merges with Subversion
to read the above, and also this:
http://www.collab.net/community/subversion/articles/merge-info.html
This information could be in a better place, e.g. the Subversion book.
I don't know how much of it is already in the book.
> There are also many times when there are conflicts merging properties.
> The summary at the end of the merge lists the number of conflicts and
> this causes a lot of concern. It should be possible to provide
> statistics broken into file changes and property changes. This will
> probably alleviate some of the resistance.
I'm not sure I understand what kinds of conflicts you are talking about
here. Are you getting conflicts in svn:mergeinfo properties? If so, did
people ever manually edit them? And could you show a specific example
to illustrate your question?
> Also, is it necessary to
> show the files where the properties have changed as part of the
> commit? The developers are not interested in this type of information.
> Would it be possible to add an option to show this information only if
> it is desired? I can see looking at the changes to mergeinfo when
> looking at a commit for debugging during subversion development but
> not for all usage.
Again, if we didn't show it, people might end up not committing
it along with their own changes. It's vital for mergeinfo to be
committed, otherwise merge tracking cannot work, obviously.
> I have used subversion for several years now and with 1.5 I am seeing
> many new errors reported on the client and server.
Try 1.5.5. You are late to the party. Most of your complaints have
already been heard from others and addressed in that release.
In 1.5.5, the rules for creation of explicit mergeinfo have been adjusted
so that less of it gets created in the first place. That's why you might
want to switch to 1.5.5 sooner rather than later. For example,
working-copy-to-working-copy copies do not create explicit mergeinfo
anymore because that causes more problems than it solves.
And possibly clean up some of the explicit mergeinfo you have accumulated.
If the mergeinfo on a file or dir is a real subset of the mergeinfo on
its parent directory, it can be removed. Also, explicit mergeinfo created by
copies, where the source and target of the copy operation are both in the
same branch, can be removed.
Hope this helps,
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1188065
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-18 22:02:16 CET