On May 30, kfogel@collab.net wrote:
> Ryan Schmidt <subversion-2005@ryandesign.com> writes:
> > On 29.05.2005, at 07:46, Eli Barzilay wrote:
> > > I was trying out "svn merge" to see how it deals with renames. I did
> > > something like this:
> > >
> > > copy the trunk to a branch
> > > edit a file <f1> on the trunk
> > > rename <f1> to <f2> on the branch
> > > used svn merge on the trunk
> > >
> > > svn merge does show something like
> > >
> > > D <f1>
> > > A <f2>
> > >
> > > but the contents of <f2> does not have any of the changes to <f1>. Is
> > > this the way things are supposed to work? Is there any way to avoid
> > > such mistakes besides telling people to "be careful when renaming"??
> >
> > What I've gathered from previous discussions on this list is that
> > unfortunately yes, this is the way it is right now, and that "true
> > renames", which are planned for Subversion 1-point-something (1.4 or
> > 1.5 maybe) should fix this situation, or at least make it better.
>
> True rename support is only a first step on the road to true merge
> tracking, which is what will solve this. Fixing renames will make
> some things better, but not this.
>
> So yes, you are right, this is the way it is right now...
Fair enough. I didn't realize that this is related to merge tracking
(which seems like many people are waiting for...).
On May 30, Bob Proulx wrote:
> Eli Barzilay wrote:
> > I was trying out "svn merge" to see how it deals with renames. I did
> > something like this:
> >
> > copy the trunk to a branch
> > edit a file <f1> on the trunk
> > rename <f1> to <f2> on the branch
> > used svn merge on the trunk
>
> Exactly what command did you use to merge?
svn merge -r <R1>:<R2> <branch-URL>
with R1 as the revisions when creating the branch, and R2 as the head
revision.
> There are different forms available and I believe will give
> different results in this case. At the moment subversion does not
> have very powerful merge capability and renames are especially
> troublesome. This capability is planned development for the future.
>
> > svn merge does show something like
> >
> > D <f1>
> > A <f2>
> >
> > but the contents of <f2> does not have any of the changes to <f1>. Is
> > this the way things are supposed to work? Is there any way to avoid
> > such mistakes besides telling people to "be careful when renaming"??
>
> You are seeing one of the many complexities that make merging very
> difficult. This is one of those often discussed problems. I was just
> looking over a discussion very similar to your problem on the monotone
> list. You may find it interesting reading.
>
> http://article.gmane.org/gmane.comp.version-control.monotone.devel/3264
I'm probably not aware of something, but the main problem that is
described in that post comes from using an R1 that is earlier than the
branch creation time. (I'm specifically trying to come up with
guidelines for our users that avoid ever applying merges that contain
already applied changes.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 30 19:42:09 2005