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

Re: svn commit: r32998 - trunk/subversion/libsvn_wc

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 10 Sep 2008 16:45:36 +0200

On Wed, Sep 10, 2008 at 10:31:35AM -0400, C. Michael Pilato wrote:
> Stefan Sperling wrote:
> > But also, think about e.g. what Mercurial does when receiving a diff for
> > a file which was copied -- it applies the diff to all copies (and
> > hence renamed files) as well as the original.
> Does it really? Awesome. (I've been claiming that as the Right Behavior
> for a long time.)

It does, if the sending side does not know about the copy already.
See http://hgbook.red-bean.com/hgbookch5.html#x9-980005.3
and make sure not to miss the section titled
"5.3.2 Why should changes follow copies?"

And keep in mind that 'svn update' == 'hg pull; hg merge' while
reading that -- there's also 'hg update', but that only works when
there are no conflicting changes.
So when they say 'merging', that generally includes our 'updating'.

> > Another application for copied-to information is when graphing the
> > history of a single file forwards in time. It is very cumbersome having
> > follow all branches' HEADS in the repository backwards in time
> > to the root in order to find out on which branches a given file is
> > or was present.
> >
> > So another related use case is asking "on which branches did we already
> > apply the bug fix for file foo.c?" Subversion currently cannot answer this
> > question in a straightforward way.
> Aren't these server-side issues, though?

Yes. But we have to start recording copied-to information somewhere :)

> The versioned filesystem today
> could be tracking copied-to information -- it just doesn't.

I'd be interested in helping make it do that some day.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-10 16:45:27 CEST

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.