Re: Medium-term roadmap: 1.3, 1.4, 1.5.

Greg Hudson <ghudson@MIT.EDU> writes:

> This, all by itself, seems very unpredictable in the case of non-rename
> copies.

Merge is hard, and has lots of corner cases; that's why I wrote "good
enough" in one of my earlier mails.

> If I have a locally-modified file "foo" and I receive an update which
> adds "newfoo" copied from foo, I propagate the local mods, and now have
> them in two places. But if I check in my local mods before the update
> (no conflict), then the modifications are never propagated to newfoo.

Well that's another thing I think should change. If I merge a change
that copies foo.c to bar.c I don't really want the merge to copy bar.c
from the merge source, I want it to copy it from my working copy
source.

$ svnadmin create repo
$ svn mkdir file://`pwd`/repo/trunk
$ svn import Makefile file://`pwd`/repo/trunk/foo
$ svn cp file://`pwd`/repo/trunk file://`pwd`/repo/branch
$ svn cp file://`pwd`/repo/trunk/foo file://`pwd`/repo/trunk/bar
$ svn co file://`pwd`/repo/branch wc
$ svn merge -r3:4 file://`pwd`/repo/trunk wc
A wc/bar

If you look at wc/bar you will see that it's copied from trunk/foo,
I'd prefer the client to be a bit "smarter" and convert that into a
copy from branch/foo.

Now it makes sense to copy local mods, because we are also copying
committed mods.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org