[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-04-25 19:23:51 CEST

On Mon, 2005-04-25 at 13:12, Philip Martin wrote:
> > 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.

You seem to have switched tracks from an "svn update" scenario to an
"svn merge" scenario, after previously saying that you were primarily
concerned with "svn update" scenarios before. That's very confusing.

If I try to apply your new proposal to "svn update" scenarios like the
one quoted with "> >" above, I get bizarre consequences. For instance,
when I added editorp.c to subversion/libsvn_ra_svn (copied from
editor.c), it sounds like anyone doing an "svn update" would wind up
with whatever version of editor.c they previously had checked out copied
to editorp.c, which would represent a completely fabricated and
unintended local mod. (I think we can take as axiomatic that a sequence
of only "svn co" and "svn up" operations should never produce a working
copy with local modifications.)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 25 19:26:47 2005

This is an archived mail posted to the Subversion Dev mailing list.