On Nov 17, 2005, at 23:52, Witham, Michael S. NAVAIR wrote:
> I have a question along the lines of this thread: "Merging moved
> files" (http://svn.haxx.se/users/archive-2004-05/0451.shtml)
> I am currently trying to do something similar: a major
> reorganization of our directory structure (5 years of no planning
> and neglect made it a mess!). The problem is that some changes are
> still being done on the main line of development (trunk). I am
> trying to do the reorg in a branch, then rewrite all of our build
> scripts (and etc), then merge the changes back into the trunk.
> Has merging improved in the last year?
Not that I'm aware of.
> An issue raised in the above thread was that the merge used the pre-
> branching version of the file, instead of the evolved trunk
> version. Was this a real problem or just a perceived problem?
> What if another developer renames/moves a file in one of the
> directories that I move?
Try it out in a test repository. Since Subversion does not yet have
real merge tracking, I believe what should happen is that someone's
changes will get marked "unversioned" and the changes will have to be
What Simon didn't appear to have done in that thread you referenced
is merge trunk changes into his branch before attempting to merge his
branch changes into the trunk. AFAIK it's necessary to first get the
reorg branch into such a state that it is the same as the trunk, with
the exception that it contains your additions. That is, there should
not be any work which has been done on trunk but which has not also
been done in the branch. The process of merging the trunk changes to
the branch should cause the behavior about which we're speaking, that
is, that things that conflict with each become unversioned.
> We are just now starting to use Subversion -- finally convinced my
> boss -- but this is a major issue for us.
Yes, it does make things more difficult. Take my above advice with
caution, though, as I've refrained from doing any major reorgs in our
projects for these reasons, so I'm not entirely sure how it will work
(or fail). So try it on a test repository first.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Nov 18 15:12:03 2005