You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Konstantin Kivi <kk...@yandex.ru> on 2009/04/08 10:45:41 UTC
Merge tracking implementation issue.
Merge tracking implementation by means of mergeinfo property is bad.
After one of the files is individually merged, it gets mergeinfo property.
All subsequent merges, even to the head of the branch causes this file's mergeinfo
update, tags file as modified ( in a sense that it has to be commited) and then
include it's name in commit information.
After a short period of time, it's impossible
to make a merge without commiting a whole lot of irrelevant files. It is not possible
to tell from log then, which files were actually modified. This is extremely annoying.
One may argue, that merging individual file is a bad habit. But in that case why there is support
for such functionality? Or why just don't stop encourage this bad practice and outlaw mergeinfo on files?
I personally liked functionality of svnmerge utility. It has some shortcomings, too, like
making conflicts in svnmereg:integrated, but it did its job - provided merge
tracking in a controlled manner.
I understand that this new functionality is supposed to supersede svnmerge. But the way it is
implemented does at least as much harm as good. We at our company end up routinly running scripts
that deletes mergeinfo from files, otherwise it's not possible to work.
I think that the best way to fix this problem without major changes is to make mergeinfo property hidden.
Commands like status, diff, and, most important, log shouldn't show files whose only change is in mergeinfo property unless specifically told to do so by a command line switch.
--
Best Regards , Konstantin Kivi
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1594371
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge tracking implementation issue.
Posted by Greg Troxel <gd...@ir.bbn.com>.
Mark Phippard <ma...@gmail.com> writes:
> The current behavior is not a bug. It was intended to work the way it
> does and people had to go out of their way to write the code to make
> it happen. It is clear, in real world usage that the end result has
> side effects that suck. So work is being done to understand what
> negative results would happen if these properties were not updated and
> then whether those things can be corrected.
>
> Work went into 1.6 and was backported to 1.5.5 and 1.5.6 to reduce the
> creation of subtree mergeinfo, which reduces the problem. Work went
> into merge reintegrate to tolerate subtree mergeinfo, to reduce the
> consequences of having it. Now work is going on to try to minimize
> the cases where it needs to be updated.
FWIW a perspective from a newcomer to svn who is using merging on a big
project:
I started with early 1.5, prior to the fixes above, and we had lots of
subtree mergeinfo from 'svn cp' operations that we're merge related.
svn merge --reintegrate was unusable because of this, and didn't give
useful errors.
With 1.5.5 or later, we aren't getting subtree mergeinfo created, and
--reintegrate is working fine. I am either having no problems at all,
or only very subtle problems with how record-only merges work:
http://svn.haxx.se/users/archive-2009-03/0048.shtml
(I have on my todo list to recheck this and make a real test case.)
I do have to either delete reintegrated branches or do record-only
reverse merges, and it would be nice if somehow merging recorded that
the changeset was a merge from a path so that the record-only reverse
merge wasn't necessary. But it's easy for me to deal with the current
situation.
So, I think the svn team has done a good job sorting out what is a very
complicated situation.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1600150
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge tracking implementation issue.
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Apr 8, 2009 at 12:00 PM, Ruslan Sivak <ru...@vshift.com> wrote:
> I second fixing this issues, although I'm not privy to the merits of
> fixing it the way Konstantin suggests. I expected 1.6 to be better with
> merging, but it seems to have made things worse.
This is absolutely not true in any way. 1.6 has not made this worse.
Perhaps more people are just getting into the issue.
> I see a lot of emails about this on the list recently. Will a developer
> take responsibility and fix this issue once and for all? Is there
> something that we as a community can do to help speed things along?
A developer has:
http://svn.collab.net/repos/svn/branches/subtree-mergeinfo/
The current behavior is not a bug. It was intended to work the way it
does and people had to go out of their way to write the code to make
it happen. It is clear, in real world usage that the end result has
side effects that suck. So work is being done to understand what
negative results would happen if these properties were not updated and
then whether those things can be corrected.
Work went into 1.6 and was backported to 1.5.5 and 1.5.6 to reduce the
creation of subtree mergeinfo, which reduces the problem. Work went
into merge reintegrate to tolerate subtree mergeinfo, to reduce the
consequences of having it. Now work is going on to try to minimize
the cases where it needs to be updated.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1599117
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge tracking implementation issue.
Posted by Ruslan Sivak <ru...@vshift.com>.
Konstantin Kivi wrote:
> Merge tracking implementation by means of mergeinfo property is bad.
>
> After one of the files is individually merged, it gets mergeinfo property.
>
> All subsequent merges, even to the head of the branch causes this file's mergeinfo
> update, tags file as modified ( in a sense that it has to be commited) and then
> include it's name in commit information.
>
> After a short period of time, it's impossible
> to make a merge without commiting a whole lot of irrelevant files. It is not possible
> to tell from log then, which files were actually modified. This is extremely annoying.
>
> One may argue, that merging individual file is a bad habit. But in that case why there is support
> for such functionality? Or why just don't stop encourage this bad practice and outlaw mergeinfo on files?
>
> I personally liked functionality of svnmerge utility. It has some shortcomings, too, like
> making conflicts in svnmereg:integrated, but it did its job - provided merge
> tracking in a controlled manner.
>
> I understand that this new functionality is supposed to supersede svnmerge. But the way it is
> implemented does at least as much harm as good. We at our company end up routinly running scripts
> that deletes mergeinfo from files, otherwise it's not possible to work.
>
> I think that the best way to fix this problem without major changes is to make mergeinfo property hidden.
> Commands like status, diff, and, most important, log shouldn't show files whose only change is in mergeinfo property unless specifically told to do so by a command line switch.
>
>
>
I second fixing this issues, although I'm not privy to the merits of
fixing it the way Konstantin suggests. I expected 1.6 to be better with
merging, but it seems to have made things worse. Yesterday, I did a
merge and a bunch of unchanged files had a bunch of svn:mergeinfo
properties added.
I see a lot of emails about this on the list recently. Will a developer
take responsibility and fix this issue once and for all? Is there
something that we as a community can do to help speed things along?
Russ
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1598432
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Merge tracking implementation issue.
Posted by Carsten Koch <Ca...@web.de>.
On Wed, 2009-04-08 at 14:45 +0400, Konstantin Kivi wrote:
...
> I understand that this new functionality is supposed to supersede svnmerge. But the way it is
> implemented does at least as much harm as good. We at our company end up routinly running scripts
> that deletes mergeinfo from files, otherwise it's not possible to work.
Same here, unfortunately.
We had tried out merge tracking on small examples
and all went well.
After we installed 1.5 and used it for a while,
we got all kinds of strange problems, up to and
including a case where "svn merge --reintegrate"
only merged one of the 2 hunks that were made
at the same time in the same file.
At that point, we created code that deleted
all svn:mergeinfo properties and stopped using
"svn merge --reintegrate".
Carsten.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1600415
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].