Hi, folks.
In March, a previous thread on this subject
(http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&fro
m=644324) suggested that allowing a no-op merge to modify mergeinfo was
a benign change that would only affect users who used automated
scripting.
My experience is that it is a serious issue that becomes a daily or at
least weekly problem for companies that use branches heavily.
*** I think that this issue needs serious attention, and quickly. ***
Here's the scenario:
(FYI, we are currently using the Subversive Eclipse plugin to actually
access Subversion.)
User A creates a branch from the trunk, for a project with 100 files in
it.
User B creates a branch from the trunk, for the same project.
User C changes one file in the trunk.
User A merges from the trunk to the branch, thus creating mergeinfo on
EVERY file in the branch, not just the one file that User C changed.
User A changes 3 files in his branch.
User B changes 4 files in his branch. Probably not even the same files
that user A changed.
User A merges the branch to the trunk (using a two-URL merge to avoid
the problems with "merge -reintegrate" and file renames, as per
http://subversion.tigris.org/issues/show_bug.cgi?id=3128)
User A observes that his commit is modifying each of the 100 files in
the project, even though he only changed 3 files in the branch. Most of
the changes involve only mergeinfo, with no actual content changes. (The
user then complains to me that he can't see the "signal" of his changes
amongst the "noise" of the mergeinfo changes, since both are displayed
as file differences in a Subversive Eclipse commit dialog, and that he
doesn't see why files that haven't changed since they were merged out
are being committed.)
User B tries to merge his branch to the trunk. He also observes that his
change is modifying each of the 100 files in the project, even though he
only changed 3 files in the branch, and that most of the changes involve
only mergeinfo, with no actual content changes. In contrast to what user
A saw, however, user B sees each of these mergeinfo changes as CONFLICTS
with what is currently on the trunk, which he must resolve one at a
time, by either manually merging the mergeinfo himself by hand or by
randomly selecting either the trunk mergeinfo or the branch mergeinfo to
keep, for each such file!
Note that if user B had tried to merge from the trunk to his branch
first, after user A had committed, he would have had the same problem
except that he would have gotten the conflicts in mergeinfo when merging
to his branch instead of merging from the branch to the trunk.
So far after reading discussions relating to bug 2883
(http://subversion.tigris.org/issues/show_bug.cgi?id=2883) and the above
conversation, I am unconvinced that modifying mergeinfo every time
something is merged, regardless of whether anything was actually changed
as a result of the merge, is worth the above problems. This changes what
would be a minor problem (merging mergeinfo for the few files that user
A or user B actually changed) into a major one (dealing with the above
issues on each of the 100 files in the project). At the very least, I
don't think that merging a file whose content has not changed to the
trunk should result in modified mergeinfo. (I can possibly see some
justification for modifying mergeinfo when merging to a feature branch.)
In actual fact in our company, we have 30+ projects, collectively
comprising a LARGE number of files. Every time someone branches a few
projects and then commits them, all of the other developers have to deal
with this issue.
As I hope I've managed to convey in the above, this is a significant,
ongoing problem for us that is severe enough that the complaints of the
users involved are starting to make upper management consider whether
switching from CVS to SVN was a good idea, and whether we should switch
back (probably permanently, since so many people have been burned by
dealing with the Subversion 1.5 merging bugs and this has left a bad
taste in a lot of peoples' mouths).
Please tell me how I can make this work without having users go through
these kinds of frustrations. (Preferably, please make mergeinfo changes
only happen for commits to the trunk that actually DO something to a
file's contents, or please make merging of mergeinfo smarter so spurious
conflicts like this don't happen, and users can actually ignore the
existence of the mergeinfo property as the manual falsely suggests they
can.)
At the least, I think bug #2883 should be reopened.
Thanks in advance for any helpful suggestions.
Derek
Received on 2008-10-30 01:34:54 CET