On Wed, 2009-09-16 at 12:34 +0200, Branko Čibej wrote:
> Julian Foad wrote:
> > Neels Janosch Hofmeyr wrote:
> >
> >> Hi tree-conflicts folks,
> >>
> >> I'd like to poke you guys with this scenario:
> >>
> >
> > Yes, that's what we need. It's where "true renames" support intersects
> > with tree conflicts.
> >
> >
> >
> >> [[[
> >> # fred's WC: copy, edit and remove something in three separate commits.
> >> $ svn copy foo bar ; svn ci
> >> $ $EDITOR bar ; svn ci
> >> $ svn delete foo ; svn ci
> >>
> >
> > The three commits are a distraction from your main point. Let's just say
> > "svn move foo bar; $EDITOR bar; svn ci" for the purposes of this
> > example, to make it clear that Subversion is supposed to recognize this
> > as a "move". In designing "true renames" support we can discuss whether
> > we want Subversion to guess that a sequence of changes like yours above
> > is meant to be a "move".
> >
>
> It shouldn't IMNSHO. The whole point of "true renames" is to preserve
> object identity ... if we allow copy+delete to do that, then we lose the
> ability to do a copy+delete that doesn't preserve object identity.
Yup, absolutely. But for the transition period from "copy + delete" to
"true renames", it could be extremely useful to apply such a "guess" in
situations where it appears clearly meant (yes, that means guessing) and
with user overrides possible. All this is up for discussion in the "true
renames" topic.
> In a slight modification, of this scenario, it could be argued that
> copy+delete in a *single* commit could potentially be converted to a
> move, for compatibility with older clients; but never if they come in
> separate commits.
Yes, that's the sort of thing I'm thinking.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395452
Received on 2009-09-16 12:57:52 CEST