I believe there are 2 issues that are combined under "true rename"
support.
There is http://subversion.tigris.org/issues/show_bug.cgi?id=2685 which
is the branch merging problem that you are talking about.
There is also the more general true rename issue which happens even when
you update your workspace and happens to have modified a file that
someone else moved/renamed.
I explained my point of view in an earlier post
http://svn.haxx.se/users/archive-2006-01/0578.shtml
Teams that use agile methodologies will usually refactor very often
(some mercilessly ;-) and will run into these problems a lot more often
than traditional methods. I have used subversion on many agile projects
and I can guarantee you that it happens enough to force the team to
change the way they work (which is not what a tool should be doing): we
usually forbid renames/moves (at the very least of directories) and
schedule these renames/moves off hours after having made sure that
everybody committed all their changes. Not fun to say the least.
As an example, my team is dealing with that very issue right now:
We have 2 active branches: the release branch and trunk. Because of
requirement changes we were forced to start a major codebase
restructuring on the trunk while still providing limited enhancements
and bug fixes on the release branch. Most of the changes were
repackaging, i.e. moving files around.
This ended up meaning that almost EVERY single merge from the branch to
the trunk includes files that have to be merged by hand. To make matters
worse we won't be able to close the release branch for a while due to
the magnitude of the work on the trunk so we will have to deal with this
for several months. I can tell you that some people are so frustrated
that they are talking about going back to clearcase!!!
I believe this is what Chuck is talking about when "thou shalt not lose
code". When files are just moved and not modified, one would expect the
version control system to handle merging these transparently and not
loose changes that happen to be done on a moved file.
More other you would not expect the VCS to not report the cases that
where not properly merged: subversion does not consider move/change case
a conflict and does not fail the associated "update" (as CVS does at
least).
To be fair svnmerge does at least warn the user but it does by issuing a
non threatening "skipping <file>" output message too easily discarded.
Granted the importance of this issue greatly depends on the size of your
team and how often you refactor. However IMHO as agile disciplines are
becoming more mainstream everyday, this will become increasingly
important.
Jacques
-----Original Message-----
From: Les Mikesell [mailto:lesmikesell@gmail.com]
Sent: Thursday, April 12, 2007 5:03 PM
To: Irvine, Chuck R [EQ]
Cc: Morel, Jacques; Karl Fogel; users@subversion.tigris.org
Subject: Re: Subversion 1.5
Irvine, Chuck R [EQ] wrote:
>
> If I had heard that the current implementation of renames can and
> probably will lead to code loss (from the latest revision), my
reaction
> would have been much different. To me, probably the first rule of
source
> code management is "thou shalt not lose code".
No source control mechanism can prevent code loss at the latest revision
if someone commits changes that cause it. What the revision mechanism
provides is a way to get back any older version ever committed.
> At this point we have adopted it as our standard tool, moved
> applications to it, bought 24x7 support, etc, so we are committed and
> will have to figure out how to avoid losing code.
Develop on the trunk and branch for releases. That should make it a
rare case that you ever have to merge refactoring-type development work
back from a branch to the trunk where someone may have concurrently
added things to a file that has been renamed/replaced on the branch.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 13 00:58:16 2007