[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-23 08:22:00 CEST

On Fri, 2005-04-22 at 20:59, Philip Martin wrote:
> I guess it depends what one means by "good". Update could make better
> use of copyfrom information to move local mods within a working copy,
> I suspect merge could do the same. If merge and update were to do
> that then we might be able to handle tree reorganizations in a manner
> that is "good enough" in most cases.

I really think this idea doesn't lead anywhere fruitful.

First, there can be more than one copy of a file. Propagating a local
modification from one place to many places could create a huge mess.

Second, we generally don't have a good idea of why a file was copied.
It could be for a rename, it could be to create a branch, it could be
because the original was a template. So unlike the usual case of
merging modifications made to a file which doesn't move, we don't have a
very sound basis for assuming modifications should be propagated.

Third, when a file is copied (not renamed), the original doesn't stop
being modified. It wouldn't make sense to propagate some of the
modifications (the ones that happened prior to the merge that involved
the copy operation, for instance). But we'd only get copyfrom
information in the one merge which encompasses the copy.

You're not the first person to suggest that copy operations should
create a network of automated change-propagation. But I think it would
wind up being perceived by users as spaghetti.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 23 08:22:58 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.