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.
Stefan
---------------------------------------------------------------------
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