On Sat, Oct 10, 2009 at 01:25:49PM +0200, Daniel Shahaf wrote:
> Julian Foad wrote on Sat, 10 Oct 2009 at 02:24 +0100:
> > Greg Stein wrote:
> > > On Fri, Oct 9, 2009 at 19:35, Julian Foad wrote:
> > > > Daniel Shahaf wrote:
> > > >> Log:
> > > >> Moving a file should preserve its changelist. Add tests to this effect.
> > > >
> > > > In that case, "copy" should preserve the changelist on the copy too. I
> > > > don't know whether it does, just saying.
> > >
> > > I'm not sure that I agree.
> > >
> > > The changelist is associated with the specific node, so (IMO) it
> > > should move along with it.
> > >
> > > I don't see how a copy implies any similar kind of movement or
> > > extension of the changelist.
> > I suppose it depends on what kind of change you are tracking. I was
> > thinking of a whole new file for feature X, and that if I copy it then
> > it's likely that the copy is part of my feature X too. But if I'd just
> > made a small text change in X and then copied it, I'm probably wanting
> > the copy for some completely different purpose.
> It's (IMO) easier for users to remove the changelist if it follows the
> copy than to remember to add it manually else. But I'm not convinced
> either way yet.
There are two possible and valid use cases here, so we should support both.
I agree that keeping changelist info on the copy by default is fine.
But a new flag such as --ignore-changelist for svn 'move' and 'svn copy'
to complement the default behaviour would be nice.
This problem reminds me of my recent work on 'svn diff' -- there are
two ways to diff copied files: against their source, or like a newly
added file. Both use cases occur in practice. Yet for some reason svn only
supported the former use case (and still does for anything but WC->WC diffs
but I hope to fix this soon).
It does not matter what the default behaviour is, but it should at least
be possible for users to tickle the alternative behaviour out of svn easily.
Otherwise it hurts the user experience.
Received on 2009-10-10 13:47:31 CEST