firstname.lastname@example.org (Peter Selinger) writes:
> Ryan Schmidt wrote:
> > On Sep 27, 2005, at 06:37, Peter Selinger wrote:
> > > Create a directory project1 (revision 1)
> > > In directory project1, create a file file1. (revision 2)
> > > Copy directory project1 to project2 (i.e., make a branch).
> > > (revision 3)
> > > In project 2, rename file1 as file2. (revision 4)
> > > In project 1, make some textual change to file1. (revision 5)
> > >
> > > Now I tried to merge the change from project1 into project2 as
> > > follows:
> > > in an updated working copy of project2:
> > >
> > > svn merge -r4:5 file:///tmp/svnrepos/project1
> > >
> > > I expected that SVN would remember that file1 in project1 corresponds
> > > to file2 in project2, and therefore would merge the change made to
> > > file1 in revision 5 (perhaps the correction of a spelling mistake)
> > > into file2 in project2. However, this is not what happened. Instead, I
> > > just got the message
> > >
> > > Skipped missing target: 'file1'
> > >
> > > So it seems that merge behaves exactly the same as it would have,
> > > e.g., in CVS, i.e., it simply applies a flat patch.
> > >
> > > How can I get SVN to do "the right thing"?
> > Subversion currently does not do what you want in this case. If you
> > rename a file in a branch, and someone makes changes to the original
> > in the trunk, you're going to run into the problem you're running
> > into. There are bugs open for this.
> That is really disappointing. Aside from sound and smoke and numbering
> conventions, this is the *one* area where SVN is supposed to improve
> upon CVS, and again it has been done in an ad-hoc, half-hearted
> way. If text changes can't be tracked after a file rename, then what's
> the point of all these fancy "tree deltas"? What happened to the whole
> idea that a *file* is not the same thing as a *path*? It seems that
> the design was, once again, not thought through carefully.
> If what I suspect is true, this is not a "bug" but a "fundamental
> design flaw". Which is too bad, because it will probably be another 10
> years until someone starts the next major project for version control.
Your statement that this is "the *one* area where SVN is supposed to
improve upon CVS" is simply false. We documented our goals quite
clearly when we started the project, and achieved most of them.
If you'd like to help with merge tracking, check out the issues
database, and (as always) patches welcome.
www.collab.net <> CollabNet | Distributed Development On Demand
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Sep 28 02:28:38 2005